2026-06-07 — 次浏览
vLLM 官方 DGX Spark 指南：为何 120B NVFP4 模型解码仅约 23 tok/s，以及这对带宽受限的本地推理带来什么启示
2026 年 6 月 1 日，vLLM 项目发布了在 NVIDIA DGX Spark（GB10 Grace Blackwell、sm_121、128 GB 统一内存）上运行 vLLM 的官方指南。通过 vllm/vllm-openai:cu130-nightly 容器服务 Nemotron-3-Super-120B-A12B-NVFP4，报告解码速度 22.7-23.7 tok/s、预填充最高约 1,884 tok/s、TTFT 为
发布了什么
2026 年 6 月 1 日，vLLM 项目发布了在 NVIDIA DGX Spark 上运行 vLLM 的官方分步指南。DGX Spark 是桌边型 GB10 Grace Blackwell 机器，配备 128 GB 统一 LPDDR5X 内存与消费级 Blackwell 的 sm_121 计算能力。与大多数「我把它开机起来了」的论坛帖子不同，这篇文章将经过测试的部署配方与真实的本地评估结合，因此也可作为思考单机推理经济性的参考。
主打的工作负载是 Nemotron-3-Super-120B-A12B-NVFP4：总计 120B 参数，在混合专家（MoE）架构中每个 token 约激活 12B，量化为 NVFP4。这个组合正是整个练习的重点。一个 BF16 的 120B 稠密模型根本放不下，但一个约 12B 激活参数的 NVFP4 MoE 能轻松容纳于 128 GB 中，且每个 token 只需流式传输其权重的一小部分。
报告中的数字
通过 vllm/vllm-openai:cu130-nightly 容器（CUDA 13）服务，搭配 --gpu-memory-utilization 0.85、--max-model-len 131072 与 --max-num-seqs 4，该文测得：
| 指标 | 报告范围 |
|---|---|
| 解码吞吐量 | 22.7-23.7 tok/s |
| 预填充吞吐量 | ~140 tok/s（58-tok 提示）至 ~1,884 tok/s（7,234-tok 提示） |
| 首 token 时间 | 0.42 s（短）至 ~3.85 s（长） |
| KV 缓存使用率 | 单用户低于 5%；小批次低于 30% |
有两点特别突出。第一，KV 缓存占用极小，因此 128 GB 几乎全部用于权重而非上下文。第二，预填充随提示长度扩展，而解码无论如何都维持在约 23 tok/s 的平稳状态。那条平稳的解码曲线正是关键线索。
为何解码是平的：带宽，而非算力
结构性的启示就在内存总线。GB10 通过 256-bit LPDDR5X 接口（8,533 MT/s）以 273 GB/s 移动数据 — 约比 H100 的 ~3.35 TB/s HBM3 慢 12 倍。自回归解码每个 token 读取一次激活权重，因此在低批次下，张量核心大多闲置等待内存。独立拆解报告也直白地指出同一点：在 273 GB/s 下，无论投入多少算力，35 GB 的模型理论上最高仅能达到约 7.8 tok/s。
这也是为何 NVFP4 在此比在数据中心卡上更重要。将权重从 16 bytes/param（BF16）削减至约 4.5 bytes/param，能将每个 token 移动的字节数减半，这在带宽受限的机器上能将解码吞吐量大约翻倍。生态系中流传的一项比较显示，同样的 Nemotron 3 Super 在 NVFP4 版本下约为 38 tok/s，而在 Q4_K_M GGUF 下约为 19.5 tok/s — 同一个模型，变量在于格式与内核路径。（vLLM 文章自身的 ~23 tok/s 反映其特定的 131K 上下文配置与容器，因此应将跨来源数字视为方向性指标，而非完全对等的比较。）
实务框架
该文对其适用范围坦率得令人耳目一新：DGX Spark「最好视为本地单用户或小批次推理目标」。它刻意运行 --max-num-seqs 4；将并发度推得更高会牺牲延迟，因为你受限的是带宽而非算力。通过 ConnectX 结构的多 Spark 配置虽被提及，但本文明确未予评估。
统一内存架构是低调的促成者。由于 CPU 与 GPU 共享一个物理 128 GB 池，权重与 KV 缓存无需通过 PCIe 进行 cudaMemcpy 往返即可常驻 — 相较 HBM 你损失了原始带宽，但省下了复制的成本，而这正是让 120B 级模型能在桌机上运行的关键。
从业者注记： 若你要为 100-130B 的 NVFP4 MoE 规划单机本地服务器，请以约 20-40 tok/s 解码与较低的 max-num-seqs 来设定预期，而非数据中心级吞吐量。请验证你实际要运行的容器／CUDA 组合（此处官方路径为 cu130-nightly 镜像与特定于模型的推理解析器）；在不同上下文、量化内核或服务栈下发布的解码速率不会干净地转移，而光是初始权重加载就可能耗时 10-15 分钟。
未被充分考量的角度： 几乎每个 DGX Spark 基准测试的标题都是单流解码数字，这会美化 MoE 模型 — 每个 token 只有约 10% 的参数会移动。真正能预测这台机器是否适合小团队使用的指标，是在真实 KV 占用下的并发解码。在 KV 缓存使用率低于 5% 时，系统几乎没有动用其最弱的资源；有趣（且大多未被发布）的问题，是当你在 273 GB/s 总线上提高批次时的吞吐量与延迟曲线，因为那正是一台桌边统一内存机器要么撑得住数名同时使用者、要么崩塌为严格的单人工具的分水岭。