從一台開箱的 GB10 機器開始

8 月 14 日 Day 1 寫下「2026 年是地端 AI 部署元年」的時候，也順便提供了 AI 相關名詞的懶人包，當天重新把自己的環境重作一次，桌上是一台剛開箱的 DGX Spark、一座空的模型庫。三十天後，機器變成兩台，跑過六款模型（gpt-oss-120b、Qwen3.8-27B、Qwen3.8-Flash-Next、Ornith 1.5 35B-A3B、DeepSeek-V4-Flash、MiniMax-H3）、六個引擎（llama.cpp、Ollama、vLLM、TensorRT-LLM、ds4-server、FreeTokenOllama 底層即 llama.cpp，分開列是因為預設值不同）、三個 agent 框架（dsh、opencode、herdr）、一次微調、一場影片生成對決，停擺過兩次半，發過二十九篇文章，每一篇的數字都能夠對應到當初的情境。

今天把這這些整理製作成一張可複製的藍圖，十一層架構，每層一句話與一個數字，接著是這三十天裡我推翻自己的十個時刻，然後是比結論更該被留意的五個測試陷阱。

藍圖：十一層，每層一句話，一個數字

這十一行是給要照做的人的。每一行的「怎麼做」在對應那天的文章裡，每一個數字的原始檔在 repo 裡（github.com/ivanusto/llm-zhtw-agent-exam 與後續整理的腳本倉庫）。

以及這個給 Gb10 維運用的相關程式 repo，https://github.com/ivanusto/gb10-ops

引擎那一行的數字要多講一句，因為它示範了本篇最後一節的重點。llama.cpp 用 llama-bench 量純運算是 79.8%，那個數字沒有 HTTP 往返、沒有 tokenize、沒有排程器換成 llama-server 走 HTTP、用跟 vLLM 與 TRT-LLM 一模一樣的客戶端打，是 73.2%。兩個數字都是真的，差的那 8% 就是服務機制該有的門檻成本。三方並排的表只能用後者。

十次推翻自己

一個三十天的系列如果從頭到尾都在證明自己是對的，那多半沒有認真測試或運氣好。以下是我被自己測試到的資料推翻的十次，按時間排：

1. Day 10 以為 TensorRT-LLM 兩邊都會贏，實測 prefill 贏 77%、decode 輸給 vLLM，達成率 42.5%。Day 27 隔兩個大版本重跑，42.3%，「跟預設值搏感情」原封不動。
2. Day 11 寫 llama.cpp「沒有可比的武器」，重測發現它有 continuous batching，只是射程短，並發 1 領先、並發 32 剩一半。
3. Day 14 以為 3-bit 是 Portable Computer 的配方，拆開是 FP8 注意力加 NVFP4 MLP 四種格式混合。同一天以為後訓練買到格式紀律（0/10 對 7/10），Day 15 用 50 輪重測推翻，兩款 27B 都是 0/50，沒記錄取樣設定的比數等於沒有量。
4. Day 22 以為 FreeToken 的語意錨點會補上 prefix cache 在工具插入輪的弱點，實測它付 4.68 倍，守方 3.03 倍，弱點被指出來但沒有被補上。
5. Day 24 以為蒸餾的每一步會跟原版一樣貴，profiler 打開發現貴 10%，去噪加速 4.55 不是 5。更意外的是固定成本那一塊：原版 20 步裡有 371 秒是去噪、49 秒是文字編碼加 VAE 解碼加封裝，四步版只剩 74 秒去噪，於是同樣那 49 秒從占比 12% 變成 43%。蒸餾能砍的只有去噪，砍得越乾淨，剩下那塊越難看。
6. Day 25 以為 Unsloth 在 GB10 上有 torchcodec 地雷，實測 98 秒零編譯裝完，坑在別處：page cache 讓 GPU 以為記憶體不夠，模型是多模態架構讓 TRL 把提示詞當圖片。同一天以為編輯規範學會了，把規則從提示詞拿掉再測，違規從 98 個惡化到 143 個，比微調前更糟，規則變成條件反射不是習慣。
7. Day 26 準備寫「低位元量化會吃掉微調差量」，實測 26、26、22，差量完全還在，量化壓縮的是整個矩陣不是矩陣的某個成分。
8. Day 27 以為 TRT-LLM 1.2.1 因驅動版本出局，那是讀標籤讀出來的，實測映像自帶 cuda-compat 跑得起來。同一天發現 Day 12「四位元的繁中稅是英文兩倍」在 DeepSeek 2-bit 上方向相反，結論不會自動外推。
9. Day 28 以為容器記憶體上限能擋住停擺，cgroup 看不到驅動配置的那 100 GiB，只有 nvidia-smi 的 compute-apps 答得出誰在吃。原本設的 8 GiB 告警線在正常服務時就一直亮，實測校準成 6 與 3。
10. Day 29 想給讀者一個「牆插對 GPU 軌」的倍率，量完發現倍率從 7.34 到 2.98，整機功耗是加法不是乘法，24.1 W 基座加 2.55 倍係數，而且 CPU 滿載時模型錯 114%。

數字是需要自己檢查的，不是看數字好看就好喔。

量測方法論的五個陷阱

上面那十次是結論被推翻，但推翻它們的其實是同一件事，也就是測試方法。這一節把三十天裡碰到的問題收斂成 5 件該注意的事，它們比任何一個效能數字都更該留意，因為換一台機器、換一款模型，數字全部作廢，這 5 件事情可能都會對應到。

一、prefix cache 讓「重跑一次確認」變成量快取。 Day 9 同一組 --seed 跑第二趟，prefix cache 命中 99.2%，median TTFT 從 500 ms 掉到 76 ms，「prefill」報出 26,663 t/s。重點在於數字會變好看而不是變錯，所以它不會觸發任何懷疑。解法是每輪提示詞塞不重複的序號或奈秒前綴，把快取打掉再量。

二、跨引擎比 tok/s 之前，先確認 token 是同一種。 llama.cpp 的 GGUF tokenizer 與 HF tokenizer 切出來的 token 數不一定相同，用客戶端的字串長度當分母會直接高估。Day 15 之後所有 decode 數字的分母一律取伺服器自己回報的 completion_tokensDay 27 比 PPL 之前，先確認兩條路徑切出來的 chunk 數完全相同（繁中 142、英文 561、另一組 253），確認過才敢把兩個數字並排。

三、同一個指標要確認你認得它所有的輸出通道。 Day 22 第一版判定首 token 時只看 content 與 tool_calls，而 DeepSeek-V4 在那個負載下把整個輸出預算花在 reasoning_content 上，finish_reason 是 length，從不抵達 content。結果 45 輪裡有 14 輪被記成「沒有 TTFT」，其中 9 輪正是決定勝負的工具收尾輪。用那個子集算出來的倍率是 8.73×，比修正後的 4.68× 誇大了將近一倍。方向是對的，幅度嚴重灌水，而這種錯最難被找到。

四、同一張表裡不要有兩個分母。 Day 13 的 loader 對照表第一版兩列用了不同的統一分母，其中一列的百分比甚至跟它旁邊的絕對值對不上。發現的方法不是重跑，是拿印出來的兩個數字自己相除。任何表格交出去之前，把百分比用同一張表上的絕對值反算一次，這是簡單的的自我稽核。

五、沒有記錄取樣設定的比數等於沒有測試到真實資料。 Day 14 的 0/10 對 7/10 被 Day 15 的 50 輪重測推翻成 0/50。同理，投機解碼的加速倍率只在貪婪解碼成立，引用任何加速數字都要連取樣設定一起報。A/B 計時也一樣要顧慮快取，ComfyUI 固定種子會讓第一趟整個少算，另存 docker logs 撞到檔名會只剩一行錯誤訊息，證據沒了就得重跑。

三個還沒解決的問題

十次推翻自己讀起來像是每個坑最後都有解，那不誠實。三十天結束的此刻，這三個是照做的人一定會撞到、而我還沒有答案的：

熱浸透斷電的根因還是不明。 9 月 1 日那次整台斷電，事後歸納出的紅線是 zone 連續浸透 417 秒，但那是從軌跡倒推的，不是從機制推的。它不留核心日誌、不是 OOM，也沒辦法用降功耗迴避。現在掛著的兩個看門狗（240 秒與 330 秒）做的都是「在它發生之前先中止你的工作」，這只有止血但沒解決問題喔。296 次開機裡有 34 次不安全關機，11%，這個比例正在逐步降低，可能是使用前期較多測試或沒注意到影片生成的時間太長，導致當掉的情況較多，加上放在家裡的書房散熱有限，現在有了開門狗，當掉的情況就少了非常多，因為有在控制。

ds4 的磁碟 KV 沒有淘汰機制。 /var/lib/ds4-kv 現在 49.2 GB、256 個檔，最舊的是 8 月 13 日，還在。Day 28 把它記成待辦，Day 29 又量了一次，根目錄從 38.1 GB 掉到 36 GB，照日均寫入攤平離塞爆還有二十天上下。碟本身的 Percentage Used 是 0%，所以任何看耐寫度的監控都不會叫。這件事同時是效能功能與資料落地點，正待後續追蹤與處理。

微調到底能不能取代提示詞，還需要再測試。 Day 25 的編輯規範那一格，資料集裡每一筆的 system prompt 都寫著那三條規則，模型學到的是「看到這組規則就照做」。把規則拿掉再測，違規從 98 個惡化到 143 個。要讓它變成習慣而不是條件反射，資料該怎麼設計，目前還需要再測試與調整。

IFA 之後：這條路接下來往哪走

系列後半正好撞上 IFA，NVIDIA 在那一週發布的東西，幾乎每一件都對這三十天有回應。

128GB 統一記憶體是 AI 工作站基本主流規格了。 Lenovo 與 Acer 的 RTX Spark Windows 機器十月上市，同樣的 128GB 統一記憶體、Windows 原生。Day 2 到 Day 28 量到的所有統一記憶體特性，記憶體可見性的兩極、頻寬決定 decode、功耗是加法不是乘法，會從「一台特殊的 Linux 開發機」變成一整個級距的共同特性。這個系列的實測價值在那之後不會過期，會擴大。

我自己認為微軟近期提出的 AI 開發機 64GB 記憶體這個規格已經不夠了。

地端 agent 正在被產品化。 Perplexity 的 Portable Computer（Day 13）、Hermes Agent 的一鍵地端、NVIDIA 自己的 PAIR，方向一致，都是本地優先、需要時審核外送資訊。Day 13 拆出來的那個「審核式閘門」形狀，Day 29 治理表的第 2 條，正在變成產品的預設值，而不是我自己近年測試和實作的建議，市場的實際需求確實是殊途同歸。這裡要接回藍圖第九層：Day 20 實測 Collie 在還沒配對任何裝置時，寫入閘門是關的，一個 curl 就能把按鍵送進活著的終端機配對一台裝置之後，連 loopback 直連的寫入都會被拒。閘門存在不等於閘門開著，產品化不會自動解決這件事。

開放權重的發行管道所有權變了。 NVIDIA 收購 Hugging Face 是這三十天裡最大的一條產業新聞，對 Day 5 那座建立在 HF 生態上的模型庫，這是供應鏈集中風險的實體化。MANIFEST 裡的來源、雜湊、授權三個欄位，從「整潔的好習慣」升級成「管道變動時能否重建供應鏈的依據」，這件事我在 Day 29 寫進了治理清單第 6 條。

模型本身還在變。 Qwen3.8-Flash-Next 是 Qwen4 的預告（Day 14），51B 的 n-gram embedding 明著替記憶體受限裝置設計，但在統一記憶體上卸載價值歸零，這是 Day 14 與 Day 22 兩次看到的同一件事：為分離式架構設計的聰明，在統一記憶體上會變成空轉。下一代模型的設計會不會開始把統一記憶體當一級目標，是我接下來一年最想看的事，MacStudio 在這部分也會很好用，加上 AMD 也投入了更多資源在統一記憶體的機器，以及 NVIDIA 後續的進展，相信有許多新的變化很值得期待。

給三種讀者的路線

一個人、一台機器：Day 4 整備、Day 7 上線、Day 8 的 llama.cpp、Day 12 選 q8_0、Day 16 的五個問題，一週內能跑到日常可用，不需要碰 llama.cpp 以外的引擎。

一個小團隊、要服務：加上 Day 9 的 vLLM、Day 18 的閘道、Day 19 到 21 的 agent 三部曲、Day 28 的兩層健康檢查與那份監控清單，並發 8 是這台機器服務小團隊的甜蜜點，Day 21 用三個真 agent 實證過。

MSP 或企業導入：Day 5 的模型庫治理、Day 16 的 PII 過濾（記得它預設 fail open，analyzer 一報錯就原文照送）、Day 20 的四個治理檢查點、Day 29 的兩張表與十二條清單，加上一句話：這從來不是二選一，是分流，機敏且可預測的走地端，需要旗艦能力且不機敏的走雲端，分流的閘門要留紀錄。

三句結論，加一句反話

三十天前我問的問題是「這台機器能不能做地端 AI」，三十天後的答案繼續延伸。

能，而且比想像中寬鬆。 27B 的 LoRA 微調 37 分鐘、120B 的 MoE 常駐、雙機合體跑 FP8 的旗艦，這些在 24GB 顯卡的世界要靠各種卸載硬撐，在這裡是舒服的。

但速度不夠快，而且它會當掉。 273 GB/s 的頻寬讓密集 27B 的 BF16 只有 4.66 t/s，統一記憶體沒有 OOM 例外只有整台停擺，熱浸透會讓看門狗中止你的渲染。它的每一個限制都測試得出來，而測出來之後大部分都有對策。用量化版的模型就會很快較實用，如 DeepSeek V4 Flash，現在終於又多了更好用的 DeepSeek V4.1 Flash 了。

值不值，取決於你為什麼要它。 以 token 計價，我這套回不了本。但如果你需要處理的資料、模型和程式碼、文本等，儘量不能離開這個房間到雲端處理的話，添購第二台 Spark 跑雙機是需要的入場成本。

最後補一句反話，因為推薦名單如果沒有排除項就不是推薦名單。

這台機器不該買給三種人：一是追求純文字 decode 速度的，密集 27B 在 8 位元只有 7.93 t/s，同樣的錢在雲端買得到快得多的體驗。
二是用量撐不到成本攤平線的，那條線在 7.7 倍日常用量，撐不到就是在買保險不是在省錢，那要用保險的邏輯評估。
三是需要旗艦推理能力而資料又不機敏的，地端的天花板由記憶體決定，那個天花板的能力，現在仍低於旗艦模型之下。但最近剛出的 DeepSeek V4.1 FLash，其效果很讓人期待，可以多嘗試一下。

接下來還有 Day 31 番外篇喔，敬請期待。

Day 1｜為什麼 2026 年是地端 AI 部署元年：系列規劃與硬體總覽
Day 2｜DGX Spark GB10 深度解析：128GB 統一記憶體到底解決了什麼問題
Day 3｜網路與儲存規劃：10GbE 骨幹、雙 Spark 直連與 NFS 集中模型庫
Day 4｜開箱之後：DGX OS 初始環境建置與 CUDA、Docker 生態確認
Day 5｜NFS 模型庫實戰：下載工具、權限設計與版本管理
Day 6｜llama.cpp、vLLM、TensorRT-LLM 、Ollama、DS4 與 Unsloth 的定位與取捨
Day 7｜第一個模型上線：gpt-oss-120b 從模型庫到 API 的完整流程
Day 8｜llama.cpp 實測：先定量尺與 SOP
Day 9｜vLLM 實測：官方容器、同時處理吞吐曲線，與剛出爐的新模型 Ornith 1.5
Day 10｜TensorRT-LLM 實測：我花了一個下午，跟它的預設值搏感情
Day 11｜地端 AI 三大推論引擎綜合評測，同場加映神秘嘉賓
Day 12｜量化格式解析：「4-bit」兩個字，古今多少事 ? 都付笑談中
Day 13｜Perplexity 把整套 Agent 搬上 DGX Spark：地端元年的官方背書
Day 14｜Qwen3.8-27B 與 Flash-Next 加碼實測：地端模型世代對決與落地評估
Day 15｜Ornith 1.5 實測：為 AI agent 而生的 35B-A3B
Day 16｜模型選型方法論：五個問題幫你跳脫排行榜迷失，找到適合自己任務用的 AI 模型
Day 17｜ds4 深度解析：Redis 之父只為一種模型造了一個引擎
Day 18｜OpenAI 相容 API 層：地端 AI 多模型常駐好助手
Day 19｜地端 agent 框架總覽：它們到底對你的端點做了什麼呢?
Day 20｜DeepSeek Harness 實戰：21 萬款星的外掛式 harness 接上地端
Day 21｜herdr 是地端 AI 同時跑多個 AI agent 的最佳解
Day 22｜語意錨點對上 prefix cache，FreeToken VS vLLM，以及三個關於統一記憶體的教訓
Day 23｜ComfyUI 部署與 NFS 模型庫整合：把集中管理的哲學帶進生圖世界
Day 24｜MiniMax-H3 地端影片生成：h3-ui 與四步蒸餾版的三段對決
Day 25｜Unsloth 微調實戰：教一款模型用繁體中文思考，並遵守台灣的編輯規範
Day 26｜微調的最後一哩路：合併、轉檔、量化、上線
Day 27｜雙 DGX Spark GB10 合體與分工合作的部署與實測
Day 28｜雙NVIDIA DGX Spark GB10 維運篇
Day 29｜成本與治理：地端 AI 到底值不值得，是否能進客戶環境?
Day 30｜三十天製作了一張可複製的地端 AI 藍圖
Day 31｜NVIDIA PAIR：合體與分工合作之外，第三種用法值不值得付 Ollama 稅