這張綜合評測表的意義

過去四天，同一顆 gpt-oss-120b 在同一台 DGX Spark 上被三個引擎輪流跑過一遍：llama.cpp（Day 8）、vLLM（Day 9）、TensorRT-LLM（Day 10），今天彙整成一份簡單的總表，同場加映一位神秘嘉賓。

怕有人看不懂，測試部分是會比較複雜一點，所以先稍微講一下規則，這份綜合評測的價值不在表格，在於對齊的測試紀律。
已經對齊的：包括模型與量化相同（MXFP4）、上下文 32768、批次上限 32、chunked prefill 切塊 2048、同一套 vllm bench serve、每級換 seed、級間冷卻 120 秒。*
沒對齊的誠實攤開*：如 vLLM 的 KV 跑 fp8，TRT-LLM 被 FMHA 擋著只能 bf16，KV 容量因此差 17.5 倍，同時處理 32 那級 TRT-LLM 有三成請求在排隊。

總表一：單請求效能

關鍵測試資料呈現三個不同故事

prefill 是 TRT-LLM 的天下，提示詞越長贏越多，它是唯一從 pp2048 到 pp8192 不降反升的引擎，編譯最佳化在算力受限的場景是真材實料。
decode 是 llama.cpp 的天下，幾乎兩倍，單請求路徑上它具備接著 273GB/s 的硬體頻寬在跑，另外兩個推論引擎因為身上背著服務機制的固定成本無處攤提，這部分跑不快。
達成率比 t/s 誠實，它把機器的物理上限當分母，這套驗算法換任何硬體、任何模型都能接續應用。

如果簡單歸納，llama.cpp 這欄是 llama-bench 的純運算成績，換成 llama-server 走 HTTP、用與另外兩位相同的客戶端打，decode 是 55.64 t/s，差的 8% 就是服務機制的最低消費，下一張表用的是後者，所以我們用同一把量尺才能做比較。

總表二：同時處理吞吐

（1 到 32 的放大倍率，llama.cpp 1.86 倍、vLLM 4.20 倍、TRT-LLM 3.94 倍。llama.cpp 在同時處理 16 與 32 各有 3 筆連線中斷，完成率 61/64，另外兩位五級全滿。完整五級資料請本文末段附表。）

表格一目了然，所以結論我用簡短的對照方式說明。

第一，llama.cpp 有武器，但射程很短。 Day 9 我寫過它「沒有可比的武器」，雖然是不夠精確的描述，但是它有 -np 32 -cb 的 continuous batching，這次真的開著跑完全程。同時處理 1 它以 36.4 反而領先，同時處理 32 卻只放大 1.86 倍被拉開到剩一半。服務引擎與推論引擎的差別主要是平行批次處理時能撐多寬。

第二，兩個服務引擎的總吞吐四級平手（比值 0.91 到 1.02），進行批次處理之後瓶頸從算力換成頻寬，頻寬是硬體給的，prefill 快 77% 的威風在批次處理世界直接蒸發。

第三，尾端延遲不是平手。 同時處理 32 時 TRT-LLM 的 P99 是 vLLM 的近兩倍，原因在 KV 只吞得下 22 筆、剩下 10 筆罰站，fp8 用不了加上滑動窗沒實作，所以只能等排隊，拖慢整體速度。

如果按照我們之前講的實務標準，在提供給多人服務時，每人生成不低於閱讀速度、尾端等待不超過四秒，在這樣的條件下，llama.cpp 的服務上限落在同時處理 1 到 4，根本走不到 8，不適合多人用。另外兩個服務引擎則給出同一個答案，甜蜜點是同時處理 8，要更大就需要更好的算力，或者是任務調整過，這類適合多人使用的推論引擎，在一台 GB10 上的總吞吐約 80 t/s、每人 10 到 12 t/s。兩個彼此沒串供的引擎量出同一個數字，第三個引擎從反面畫出這條線在哪裡斷掉，這是機器的物理常數，不是引擎的個性。所以當我們要和老闆或客戶報告容量規劃時，按照類似的邏輯來推敲回去，要買多台還是更大的機器才能服務全公司的人，把概念說明給決策者參考。

總表三：維運面向

跑分表有的人看了會很開心或興奮，但下面這張表決定你半夜會不會被叫起來。

每 token KV 成本那行是三個引擎真正可比的數字，差距 3.54 倍全部來自兩個決定，KV 要不要 fp8，以及認不認 gpt-oss 的 sliding_window=128。TRT-LLM 兩個都沒有。它就緒比 vLLM 快近一倍值得加分，但「要求 32K 被默默改成 18,912」的行為，代表它需要一個會讀啟動日誌的管理者。選引擎跟選同事一樣，能力重要，好不好相處也重要。

同場加映：Ollama，最簡單的地端 AI 無腦路線

這節紀律等級較低（單輪、無冷卻、模型檔來源不同），不進正式總表，只回答一個樸素的問題，實際用 Ollama 的人比另外三個引擎加起來還多，需要支付怎樣的成本和處理呢? 我用同一套客戶端去打它的端點，刻意一個參數都不調，因為 Ollama 的本體主要是看它的預設值設定而已。

呈現的結果是 decode 39.24 t/s（llama.cpp 調校版 55.64），同時處理 8 總吞吐 27.3 t/s 且 P99 高達 34 秒，後者是因為 OLLAMA_NUM_PARALLEL 預設為 1，八個人在排一個窗口，那不是平行批次測試，變成排隊測試了。

decode 少掉的 29% 效能是誰拿走的？直覺會說「你沒調校 Ollama」，直覺是錯的。如果我們把變因一個一個換：

最後一列是重點，調校旗標只值 0.1%，Ollama 該調的其實都調對了（它預設就給 -ub 2048），官方處理好的效益是花在兩個你看不見也調不動的地方：官方那顆權重的注意力層是 BF16，我測試用的是 q8_0（品質換速度的取捨，該模型的下載頁不會寫），以及它的執行檔不是為 sm_121 原生編譯的。你能對 Ollama 做的最佳化只有換權重或換 binary，而等你把兩件事做完，你已經在跑 llama.cpp 了，llama.cpp 的效率和執行方便度也很高，值得你嘗試，而不是跟風只用 Ollama。

所以結論不是「Ollama 慢，別用」。39.24 t/s 仍是閱讀速度的三倍，體感是順的，對還沒決定要不要認真玩的人，29% 遠比幾小時的 cmake 便宜。對 Mac 平台來說， Ollama 也是最方便部署的，裝好之後，只要下 ollama 模型名稱就可以跑可以拉取下載，內建 MLX 加速，適合選有調整過 MLX 最佳化的模型給 Mac 平台用。但是 GB10 上面的話，就不要用 Ollama 了，請改用 llama.cpp 或 vLLM 吧，以花費時間和效益來說，這兩個是很值得的。

那 AI 代理人該用哪個

這題剛好也有人寫信來問，我原本這系列文章後面會提到，不過目前先講好了，這也是近期大家討論較多的話題。由於 agent 的工作負載跟聊天完全不同，而它正是 2026 年地端部署最熱的理由。opencode 這類 coding agent 與 hermes agents 這類多代理框架，我自己實測感受到的特徵是三件事，首先是系統提示加工具清單動輒數千 token 甚至上萬、每一輪都把累積的上下文重送一次、以及子代理與平行工具呼叫天生就是同時處理。

翻譯成今天看過的上方表格語言，agent 負載是 prefill 重、前綴重複率極高、同時處理需求真實存在的組合。用這三個條件過濾：

TRT-LLM 的 prefill 快 77% 看似天選，但 48,480 token 的 KV 池，一個 32K 的 agent session 就吃掉三分之二，多代理直接排隊，出局。
llama.cpp 單代理輕度使用可以，但 agent 一開平行工具呼叫就撞上同時處理 4 的天花板，而且它的前綴快取是單 slot 思維。
vLLM 的三個特質正好全中：849,942 token 的 KV 池裝得下多個代理的長上下文、自動 prefix caching 讓每輪重送的前綴不用重算（agent 場景這功能的價值遠大於聊天）、同時處理 8 的甜蜜點對應的正是一個主代理帶幾個子代理的真實形狀。

所以我的答案很簡單，代理人平台，選 vLLM。單人偶爾跑跑 agent，llama.cpp 也行，但只要你的 agent 會開分身，就請直上 vLLM。這是由今天的測試資料做完整推導的判斷，不是 agent 實測，後續文章會有地端模型接上 agent 框架時，用真實的 agent 工作負載回來驗證這個推論，合先敘明。

選型結論

一個人用，llama.cpp，decode 幾乎兩倍是每天打字都感受得到的差距，2 分 50 秒編完。
只是想先試試看，裝 Ollama，一行指令就有，等你開始在意那 29% 再回來編譯不遲。
服務一群人或跑 AI 代理人，vLLM，同時處理 8 的甜蜜點、最大的 KV 池、prefix caching、最不會捅你的預設值。
長提示詞的批次工作才考慮 TensorRT-LLM，RAG 檢索、整份文件摘要、程式碼庫一次性分析，prefill 快 77% 是實打實的，前提是願意付跟預設值搏感情的學費。

貫穿兩週我們會領悟到，這台機器的算力足夠讓 prefill 分出高下，頻寬則讓所有引擎的 decode 與同時處理殊途同歸。 選引擎，本質上是判斷你的工作負載落在算力側還是頻寬側，這個概念或方法比表裡任何數字都實用。

明天預告

引擎定了，下一個變數是量化。Day 12 拆解 GGUF、MXFP4、AWQ、FP8 差在哪、這台機器上怎麼選。實測平台以 llama.cpp 為主，它的量化階梯最完整、又內建品質量測工具，safetensors 系的 FP8 與 NVFP4 則用 vLLM 補上。今天同場加映提到的事情也會在那一篇收尾，兩款都叫 MXFP4 的檔案，注意力層一個 BF16 一個 q8_0，decode 就差 19%的原因。「量化格式」，是很特別的存在，也是在這個記憶體大缺，記憶體昂貴的時代中，我們一定要了解的四個字。

我們 Day 12 見囉。

附表：同時處理完整五級數據（總吞吐 t/s ／ P99 TTFT）

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 模型