NVIDIA用双DGX Station部署GLM-5.3，vLLM吞吐达607.8 tok/s

摘要：NVIDIA展示了通过vLLM在两台DGX Station上部署GLM-5.3的推理方案，报告吞吐量达到607.8 tok/s。该案例的核心价值不只是刷新单次吞吐数字，而是说明超大模型在多节点场景下可通过张量并行、连续批处理与高效KV Cache管理提升资源利用率。不过，现有采集信息未给出输入/输出长度、并发量、首Token延迟、量化设置及完整硬件配置，607.8 tok/s更接近特定工作负载下的系统级结果，而非可脱离条件比较的模型能力指标。

---

双DGX Station承载GLM-5.3，vLLM报告607.8 tok/s吞吐

NVIDIA通过vLLM在两台DGX Station上服务GLM-5.3，公开案例给出的系统吞吐为607.8 tok/s。吞吐量属于端到端推理指标：对于每个请求，生成速度可近似写成

[ R_{\text{per-user}} = \frac{N_{\text{output}}}{T_{\text{TTFT}}+T_{\text{decode}}} ]

其中，(T_{\text{TTFT}})是首Token延迟，(T_{\text{decode}})是后续解码时间。对批量服务而言，调度器会同时推进多个请求，因此整体吞吐通常远高于单请求速度。607.8 tok/s究竟代表单流生成速度、聚合输出速度，还是包含输入阶段的计算口径，必须结合完整配置确认。

这项部署的重点是把高权重模型拆到多个工作站，而不是单纯增加单卡显存。vLLM的连续批处理可在请求完成时立即接纳新请求，减少GPU因等待整个静态批次结束而产生的空闲；分页式KV Cache则将缓存块动态分配给不同序列，降低传统连续缓存预留带来的显存碎片。

多节点张量并行如何工作

对于权重无法完整装入单台DGX Station的GLM-5.3，多卡部署通常依赖Tensor Parallelism。模型矩阵按行或列切分：若权重矩阵(W)按列拆为(W_1,\ldots,W_k)，则前向计算可写为

[ y = \sum_{i=1}^{k} xW_i ]

每张GPU只计算部分输出，再通过高速互联执行All-Reduce或Reduce-Scatter，以形成完整层结果。这种方式可以容纳更大模型并提高批量吞吐，但每个解码步骤仍需跨节点同步。

代价也十分明确：

• 通信开销：权重切分越细，跨节点交换越频繁，延迟和带宽压力越高。
• 显存约束：除模型权重外，还要为激活、运行时工作区和KV Cache留出空间。
• 故障域扩大：一个节点或互联链路异常，可能拖慢乃至中断整个模型副本。
• 扩展非线性：增加第二台工作站未必带来同等比例的吞吐提升，同步与串行区段会限制扩展效率。

吞吐、延迟与显存不能只看一个数字

607.8 tok/s对离线生成、批量代码补全和大规模数据处理很有吸引力，但对交互式聊天并非唯一指标。高并发服务至少还要同时观察：

1. 首Token延迟，尤其是长提示词下的prefill时间；
2. 单请求解码速度与端到端P95/P99延迟；
3. 输入、输出Token比例；
4. KV Cache占用和可支持的最大并发数；
5. 不同batch size下的GPU利用率。

KV Cache的粗略显存成本可表示为

[ M_{\text{KV}} \approx 2 \times L \times H_{\text{kv}} \times N_{\text{tokens}} \times S ]

其中，(L)为层数，(H_{\text{kv}})为K/V头总维度，(N_{\text{tokens}})为缓存Token数，(S)为每个元素字节数。启用GQA或MLA式压缩可降低(H_{\text{kv}})，但节省比例取决于模型具体实现，不能由框架名称直接推断。

vLLM的PagedAttention通过固定大小block管理KV Cache，避免按最大序列长度连续预留内存。不过，它仍无法消除真实活跃Token本身带来的容量需求；并发拉高后，系统可能转向抢占、重计算或降低缓存命中率，这些都会反映在尾延迟中。

官方部署结果应如何解读

这一数字来自NVIDIA工程博客，具有较高的一手配置价值，但仍是厂商侧测试。阅读时还应确认以下信息：

• 607.8 tok/s按输入Token、输出Token还是二者合计计算；
• 是否包含视觉编码器、网络传输和请求调度开销；
• 使用何种张量并行规模、量化格式与算子内核；
• batch size、输入长度和输出长度分布；
• 对比方案是否使用相同硬件、精度和请求负载；
• 是否报告TTFT、P95/P99延迟及稳定运行数据。

尤其需要避免把聚合吞吐等同于单用户体验。单机多流测试可能获得极高tokens/s，但某个请求的响应速度仍会被长队列和跨节点同步限制。

开发者落地建议

对于希望在多台DGX Station或类似GPU工作站上部署大模型团队，建议按以下顺序验证：

1. 先固定服务SLO：明确TTFT、每用户tokens/s、最大并发和P99延迟，而非只追求总吞吐。
2. 验证通信拓扑：检查节点间互联带宽、延迟和NUMA放置，避免让权重切分或 collectives 落在慢速链路上。
3. 压测KV Cache：分别测试短提示、高上下文及混合长度流量，观察preemption、缓存命中和显存碎片。
4. 比较并行粒度：增加节点不一定线性加速，应对比张量并行、数据并行和流水线并行组合。
5. 保留单节点降级路径：多节点服务需要处理节点故障、模型重载和流量排空。
6. 复现完整工作负载：使用真实提示词与输出长度回放，而非以极短输入和固定输出制造过度有利的结果。

vLLM为这类部署提供了成熟的批处理、缓存和并行机制，但实际收益仍取决于模型结构、量化、GPU互联与服务流量。该案例证明了双DGX Station承载GLM-5.3的可行性，也为多工作站大模型服务提供了吞吐参考；它尚不足以单独证明真实生产环境中的延迟、成本或扩展效率。

---

消息来源：Hacker News AI Feed (2026-11-14)

—— 完 ——

主题标签： #NVIDIA 关注 #DGX Station 关注 #vLLM 关注 #GLM-5.3 关注 #张量并行 关注