GB10 推理引擎实测三方对比：llama.cpp -np4 vs vLLM vs NVIDIA 官方 NGC 容器

结论先行

我们在同一台 DGX Spark 上，用同一条聊天链路（检索 + 重排 + LLM 生成，走真实 SSE 管线，而不是裸的 decode-only 压测）对三种 GPT-OSS-120B 服务方式做了头对头测试^[1]^[2]：

指标	llama.cpp `-np 4`（A）	vLLM 自建镜像 `vllm-node`（B）	NVIDIA 官方 NGC `vllm:26.01-py3`
c=1 聊天 TTFT p50	14.0s	3.96s（−72%）	9.83s
c=2 聊天 TTFT p50	28.0s	11.27s（−60%）	未测
c=4 聊天 TTFT p50	21.0s	14.74s（−30%）	未测
c=4 聊天 TTFT p95	39.89s	16.54s（−59%）	17.2s（p95）
单流原生解码 tok/s	~45	34.3（未达 ≥45 验收线）	34.3（与 B 完全一致）
c=4 聚合吞吐 tok/s	4.6	5.5	6.0

最终我们保留了自建 vLLM 镜像（vllm-node，vLLM 0.15.2rc1，spark-vllm-docker 社区镜像谱系），而不是英伟达官方 NGC 镜像：单用户首字延迟（TTFT）快 2.5 倍，胜过 NGC 在聚合吞吐上 +9% 的优势^[2]。TTFT 是聊天场景里出现频率最高的用户体感指标，我们按这个优先级做的取舍。

测试方法

三边测试用的是同一条真实链路，而不是各引擎自己的 benchmark 脚本：同一个压测驱动 scripts/load_test_chat.py、同一组并发档位（c=1/2/4）、同一批请求，打到走完整检索 + 重排 + LLM 生成的聊天 SSE 接口上，用真实用户 JWT 认证（早期一次"全挂"的假阳性后来查明是访客限流而非引擎并发问题，换成正式会员 JWT 后复测）^[1]。单流原生解码速度另外单独测（200 token 生成 ×3，engine 层面的纯解码上限，不含检索/重排开销）。三边共用同一套 docker-compose-models.yml 网络别名（gpt-oss-120b），换引擎就是停一个容器、起另一个，后端零代码改动^[2]。

三组数据

A→B 增量（llama.cpp -np4 → vLLM，真实聊天管线，18/18 请求成功、0 错误）^[1]：

并发	TTFT p50 A→B	聚合吞吐 A→B
c=1	14.0s → 3.96s	3.1 → 3.7 tok/s
c=2	28.0s → 11.27s	2.5 → 5.0 tok/s
c=4	21.0s → 14.74s	4.6 → 5.5 tok/s

vLLM 还额外验证了 c=6：8/8 请求成功，TTFT p95 22.4s，聚合吞吐 8.6 tok/s（比 c=4 再涨 56%）；c=8 探测已饱和，吞吐持平在 8.6 tok/s、p95 拉到 44.7s——这就是这台机器上该引擎配置的并发天花板^[1]。相比更早的单槽位（无并发）llama.cpp 基线（聚合吞吐平坦在 2.4–2.7 tok/s），到 c=6 vLLM 已经是 +244% 的量级^[3]。

vLLM 自建镜像 vs NVIDIA 官方 NGC 镜像头对头（同机、同 flag、热缓存）^[2]：单流解码两者完全一致，都是 34.3 tok/s；聊天 c=1 TTFT p50 自建镜像 3.96s、NGC 9.83s（复测确认非缓存假象）；c=4 p95 基本打平（16.5s vs 17.2s）；聚合吞吐 NGC 略高（6.0 vs 5.5 tok/s，+9%）。

为什么会这样

vLLM 在聊天链路上大赢，核心是自动前缀缓存（APC）+ chunked prefill：RAG 场景下每次请求都带着同一段系统提示词和相近的检索上下文，前缀缓存能复用大量已计算的 KV，直接砍掉重复 prefill 的等待时间——这正是 TTFT 大幅下降的来源，而 llama.cpp 的多槽位模式没有这个机制。

但单流解码速度两边打平在 34.3 tok/s，说明瓶颈不在"是不是官方镜像"，而在注意力后端：两个 vLLM 镜像在 gpt-oss 上都只能用 TRITON_ATTN（GB10 上唯一可用的后端），这也证伪了"官方镜像会自带更优注意力实现"的假设。社区流传的 59 tok/s 数字来自一个带额外量化层和定制注意力后端的第三方 fork，并非我们验证过的官方或社区标准镜像可复现的结果^[1]，这里明确标注为社区口径，不作为我们自己的实测结论。

取舍与建议

如果你的场景是高频、多用户、共享系统提示词的聊天/RAG 应用，vLLM + APC + chunked prefill 几乎是必选项——TTFT 的下降是用户能直接感知的。如果你只关心单流原始生成速度（比如批处理、离线摘要），llama.cpp 的 ~45 tok/s 反而更有优势，且部署更轻量。官方 NGC 镜像在聚合吞吐上确实有优势，但如果你的产品是单用户交互为主，2.5 倍的 TTFT 差距比 9% 的吞吐差距重要得多——这也是我们最终没有切到 NGC 镜像的原因。

常见问题

Q: 为什么不直接用 NVIDIA 官方 NGC 镜像，省去自建维护的麻烦？ A: 我们做过正面头对头测试：NGC 聚合吞吐确实高 9%，但单用户 TTFT 慢了 2.5 倍（9.83s vs 3.96s）。TTFT 是我们产品里出现频率最高的体感指标，所以选择保留自建镜像，NGC 镜像留存本地供后续版本更新后复测^[2]。

Q: vLLM 在 GB10 上单流解码为什么只有 34 tok/s，而不是社区说的 59 tok/s？ A: 我们测的两个 vLLM 镜像（自建 + 官方 NGC）在 gpt-oss-120b 上都只能落到 TRITON_ATTN 后端，单流解码完全一致（34.3 tok/s）。59 tok/s 是社区一个带额外量化层和自定义注意力后端的 fork 报告的数字，我们没有在自己的环境里复现过，明确标注为社区口径而非我们的实测结论^[1]。

Q: 这套对比结果可信吗，是不是一次性跑分？ A: 三边测试用的是同一条真实聊天链路、同一套压测脚本、同一组并发档位，vLLM 一侧的结果在窗口 #2（2026-07-25 凌晨）和次日 05:47 的稳定性复查中都得到了一致印证（0 次重启/报错），而不是单次跑分^[1]。

关于 HTZL.AI

HTZL.AI 是四川慧途智联科技有限公司旗下的企业级私有 AI 品牌，专注于"数据不出企业、模型不进云端"的私有化部署路径，是 NVIDIA Inception 会员企业。本文所有数据均来自我们在真实 DGX Spark 生产环境上的工程记录。