2026-06-08 — 次浏览

为何 DGX Spark 的 GB10 解码只有 23 tok/s、预填却达 1,884 tok/s：一份带宽预算拆解

对 vLLM 2026 年 6 月 DGX Spark 部署的验证拆解：120B NVFP4 MoE 模型解码约 23 tok/s，但预填达约 1,884 tok/s，而 GB10 的 273 GB/s 内存带宽解释了这个落差。

发布了什么

2026 年 6 月 1 日，vLLM 项目发表了一篇深入剖析，探讨如何在单台 NVIDIA DGX Spark（即 GB10 Grace Blackwell 桌上型机箱）上运行大型语言模型，而它做了多数「初体验」帖子略过的一件事：它报告了一个实际部署完整的延迟—吞吐量形貌，而不是单一个亮眼数字。受测模型是 Nemotron-3-Super-120B-A12B-NVFP4——一个量化为 NVFP4 的 120B 参数混合专家（MoE）检查点，每个 token 大约启用 10-15B 参数，并在机箱 128 GB 的 CPU+GPU 统一内存池内以 131,072-token 的最大上下文提供服务。

这单一配置是一个清晰的教学案例，说明本地 Blackwell 推理实际上如何运作，因为它把推理请求的两个阶段分了开来——预填（读取你的提示）与解码（一次写出一个 token 的答案）——并显示它们落在完全不同的性能曲线上。

数字，以及它们属于哪个阶段

以下是 vLLM 帖子针对该部署所报告的数字，加上它们所受限的 GB10 硬件上限（出自 NVIDIA 对该芯片的发布细节），以及一份补足批处理全貌的社区并发研究。

指标	数字	来源
解码吞吐量（单一流）	22.7–23.7 tok/s	vLLM, Nemotron-3-Super-120B-A12B-NVFP4
预填，短判官调用（58-token 提示）	~140 tok/s, TTFT 0.42 s	vLLM
预填，中等提示（1,834 tokens）	1,636 tok/s, TTFT 1.12 s	vLLM
预填，长提示（7,234 tokens）	~1,884 tok/s, TTFT 3.85 s	vLLM
测试的最大上下文	131,072 tokens	vLLM
演示流量下的 KV 缓存使用率	低于 30%	vLLM
GB10 内存带宽	273–301 GB/s	The Register（GB10 细节）
GB10 内存	128 GB LPDDR5x, 256-bit 总线, 9,400 MT/s	The Register
GB10 FP4 峰值算力	~1 petaFLOP	The Register

从上到下读这张表，故事自己就写出来了。长提示的预填以 1,600-1,900 tok/s 运行——超过解码速率的 70 倍。无论提示多长，解码都以约 23 tok/s 缓慢爬行。vLLM 作者指出解码「仍受启用参数量所形塑」，并在各种提示大小下维持平坦。那种平坦正是线索所在。

机制：解码受带宽限制，预填受算力限制

自回归解码每次前向传递生成一个 token。对每个 token，引擎必须把模型的启用权重从内存流式传输到 Tensor Cores。以约 12B 个各约 0.5 字节的启用 NVFP4 参数计算，这大约是每个 token 6 GB 的权重读取（外加少量 KV 缓存读取）。在 GB10 约 273 GB/s 的下限下，6 GB 约需 22 ms，理论上把你上限压在接近 45 tok/s，而一旦加上 KV 读取、MoE 路由与框架开销，就落在约 23 tok/s。约 1 PFLOP 的 FP4 算力在解码期间几乎闲置——Tensor Cores 大部分时间都在等内存。这就是为何不论你的提示是 58 个 token 还是 7,234 个，解码速度几乎不变：每个 token 的权重读取是相同的。

预填正好相反。它把每个提示 token 并行处理成一次大型矩阵乘法，因此它饱和的是 FP4 Tensor Cores 而非内存总线。这就是为何预填能达到四位数的 tok/s，以及为何 TTFT 随提示长度扩展、而解码不会。

MoE 设计正是让 120B 模型在此能用得起来的关键。一个 NVFP4 的稠密 120B 模型每个 token 将需要约 60 GB 的权重读取，并以个位数低值解码。通过每个 token 只启用约 12B 参数，MoE 把每个 token 的带宽账单砍掉约 5 倍——以充裕的统一内存容量（你存储全部 120B 参数）换取稀缺的内存带宽（你每步只读取 12B）。这就是本地 Blackwell 推理的核心设计动作：容量便宜，带宽才是预算。

批处理改变了算式

单一流解码看起来很慢，但另一份并发基准测试（Dendro Logic，2026 年 4 月 22 日）显示了当你批处理时会发生什么。在单台 DGX Spark 上，Nemotron Super 49B v1.5 NVFP4 从单一流的 5.79 tok/s 总量，提升到 32 流的 161.90 tok/s 与 256 流的 695.11 tok/s——总量增益达 120 倍——而每序列速度则从 5.79 降到 2.85 tok/s。OpenAI 的 gpt-oss 120B（MXFP4）呈现相同形貌：单一流 33.53 tok/s，提升到 256 流时总量 862.84 tok/s。该帖子的描述很精确：「内存带宽是你花用的预算……当你同时运行两个流时，你花用相同的带宽预算去读取相同的权重，而两个流都拿到结果。」你只加载一次权重，并把那次读取摊分到整个批次，因此总吞吐量会持续攀升，直到 KV 缓存内存或算力最终饱和为止。

软件堆栈一直是另一个杠杆。NVIDIA 于 2026 年 1 月 5 日报告，在 Qwen-235B 上 NVFP4 加上推测式解码相较 FP8 带来最高 2.6 倍的增益，NVFP4 把内存用量削减约 40%，而 llama.cpp 的更新为 MoE 模型平均增添 35% 的提升——全都在同一块硅片上。

实务笔记

如果是我要在这类机箱上部署一个助手或代理循环，我会停止把单一流解码当作「速度」来引述，而改为围绕这两条曲线来设计。对于交互式单一用户，约 23 tok/s 用于聊天还行，但用于长篇生成就很痛苦，所以我会倚重推测式解码并让输出保持简短。对于任何要服务多于一位调用者的情况——小团队、批量摘要工作、为许多候选评分的 LLM 判官管线——我会以 16-32 的并发运行，并把机箱当作吞吐量引擎，因为那正是带宽预算真正回本之处（上面数据中的 45 至 162 tok/s 总量）。我会默认采用 NVFP4 MoE 检查点，把模型尺寸调到让启用参数能舒适地容进带宽预算内，而非把总参数量拉满，而且在信任任何人的头条 tok/s 之前——包括我自己的——我会针对我自己的提示长度分布分别对预填与解码做基准测试。

被忽略的角度

人人都在对解码 tok/s 做基准测试；几乎没有人针对代理循环去编列预填的预算。一个在每一步都重读一份不断增长的 7K-token 草稿纸的代理式工作流，每一轮都要付出约 3.85 秒的 TTFT，而在一个 20 步的循环中，那笔预填成本可能会压过实际生成。在一台受带宽限制的机箱上，提示缓存与 KV 重用并不是一个锦上添花的优化——它们是「可用的本地代理」与「把大部分挂钟时间花在重读自己上下文的代理」之间的差别。让 120B 模型得以加载的统一内存设计，正是让被浪费的预填变得昂贵的同一个设计，因为没有多余的带宽可以把它藏在背后。