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 得以实现的方式。