2026-05-01

DGX Spark 上 vLLM vs llama.cpp vs Ollama — 該用哪個推論堆疊

GB10 推論堆疊決策指南：vLLM 適合 MoE+高並發，llama.cpp 適合 MXFP4 提示與單使用者，Ollama 適合零設定開發。包含 NVFP4 tok/s 比較。

三個推論堆疊主導了 DGX Spark 的部署：vLLM、llama.cpp 和 Ollama。它們在 GB10 的 SM121 架構上有明顯不同的取捨。

快速比較

	vLLM	llama.cpp	Ollama
NVFP4 支援	✅（cu130-nightly）	✅（PR #22196）	⚠️ 透過 llama.cpp 後端
MoE 模型	✅ 最佳	✅ 良好	✅ 良好
多使用者並發	✅ 優秀	⚠️ 有限	⚠️ 有限
MTP 投機解碼	✅	❌	❌
設置複雜度	高	中	低
OpenAI 相容 API	✅	✅（llama-server）	✅

單使用者吞吐量：Qwen3.6-35B-A3B

堆疊	量化	單使用者 tok/s
vLLM（FP8，無 MTP）	FP8	28–33
vLLM（NVFP4，無 MTP）	NVFP4	~42
vLLM（NVFP4 + MTP-1）	NVFP4	55.9
llama.cpp（NVFP4）	NVFP4	~38
llama.cpp（MXFP4）	MXFP4	~43
Ollama（預設 Q4）	Q4_K_M	~24

搭配 MTP-1 的 vLLM 以大幅優勢贏得單使用者吞吐量，但 55.9 tok/s 需要 cu130-nightly 容器和明確的 --moe-backend=flashinfer_cutlass 旗標。沒有這些設定，vLLM 的表現會低於 llama.cpp。

並發：vLLM 的絕對優勢

c=32 並發使用者下，vLLM 的連續批次處理和分頁 KV-cache 發揮了關鍵作用：

堆疊	c=32 總 tok/s
vLLM（NVFP4 + MTP）	433
llama.cpp（llama-server，NVFP4）	~95
Ollama	~60

選用時機

選 vLLM 的情況：

運行 MoE 模型（Qwen3、Mixtral），flashinfer_cutlass 後端比 TRITON-only 多出 30% 效能
服務多個並發使用者（>4）
需要投機解碼（MTP）降低延遲
需要 Prometheus 指標和開箱即用的 OpenAI 相容 API

選 llama.cpp 的情況：

需要 MXFP4 精度（最高提示吞吐量，vLLM 尚未支援）
在沒有 Docker 的情況下建立本地開發環境
運行尚無 NVFP4 上傳的模型（本地量化）
追求最小依賴 — 一個二進位檔，無需 Python 環境

選 Ollama 的情況：

原型開發或只有開發者使用的工作負載
需要 GUI 前端（Open WebUI、Continue.dev）
運行較小模型（≤14B）時開銷不重要

TRITON-only 陷阱

在 SM121 上，vLLM 的 FP8 MoE 是 TRITON-only — FLASHINFER、CUTLASS 和 DEEPGEMM 無法用於 FP8。這就是為什麼未調校的 vLLM FP8 表現不佳。NVFP4 透過明確旗標取得 flashinfer_cutlass，這是 55.9 tok/s 得以實現的方式。