8节点DGX Spark：装下大模型后的吞吐边界
10 月 22 日，NVIDIA 发布技术博客，介绍 DGX Spark 正式支持八节点集群：统一内存从单节点的 128 GB 扩展到 1 TB，可运行完整的 GLM 5.3（753B）模型。值得现在关注，不只是因为容量跨过了门槛，而是 NVIDIA 首次同时给出了大模型推理、模型路由和小模型训练三类扩展数据，读者可以据此判断“桌面集群”究竟适合做什么。
下文将 NVIDIA 明确公布的测试结果标为官方数据；根据这些数据进行的复算和适用边界分析标为“我的推算”。文中提到的 token 是模型处理文本的计量单位，token per second 即每秒处理的 token 数。
从四节点到八节点：先解决装不下的问题
DGX Spark 单节点提供 128 GB 统一内存。四节点合计 512 GB，八节点合计 1 TB。GLM 5.3 的 NVFP4 版本约为 470 GB，因此能够装入八节点集群，并在表中所列配置下完成推理。
官方测试使用 nvidia/GLM-5.3-NVFP4，并以 MTP3 和 8K 输入序列长度测量预填充。结果显示，单用户解码总吞吐为 31 token/s，并发提升到 4 和 8 后，总吞吐分别增加到 51 和 67 token/s。
这组数据揭示了一个容易忽略的边界：并发升高后，总吞吐确实增加，但每位用户获得的解码吞吐从 31 降至 21，再降至 18 token/s。集群并非凭空增加算力，而是在固定硬件上分配带宽和计算资源。对交互式开发而言，延迟是否稳定往往比总吞吐数字更重要。
早期示例中，GLM 5.3 Flash 在八节点集群上的生成速度约为 80 token/s。这说明大模型已经能够用于本地交互，但不同模型、不同并发条件下的速度不能混为一谈。
扩展效率：八节点并非简单乘以八
NVIDIA 还给出了 Qwen3.8-27B-NVFP4 的扩展曲线。在交换机拓扑、关闭推测解码的条件下，八节点使用 RoCEnante 后，相对单节点取得 4.43 倍加速；未使用该优化时为 3.05 倍。官方将其描述为约 45% 的扩展效率提升。
RoCEnante 是面向 Spark 的集合通信后端。所谓集合通信，是把多张加速卡中的计算结果汇总或同步。张量并行推理会把模型拆到多张卡上，因此必须频繁交换数据。RoCEnante 采用一次 all-to-all 交换，再在本地完成归约，以减少环形 all-reduce 的多轮转发。
可以用下面的脚本复算官方数字：
single_node = 1
eight_nodes = 8
with_rocenante = 4.43
without_rocenante = 3.05
print("有 RoCEnante 的扩展效率:",
with_rocenante / (eight_nodes - single_node))
print("无 RoCEnante 的扩展效率:",
without_rocenante / (eight_nodes - single_node))
print("加速比差距:",
with_rocenante / without_rocenante - 1)按此口径计算，两种方案的扩展效率分别约为 59.1% 和 38.1%，RoCEnante 带来的加速比差距约为 45.3%。这是我的复算，不是 NVIDIA 另行公布的效率指标。
| 场景 | 官方做法或结果 | 常见做法 | 实际影响 |
|---|---|---|---|
| 内存扩展 | 单节点 128 GB，八节点 1 TB | 只比较模型参数量 | 753B 模型能否启动是容量问题 |
| 解码扩展 | 使用 RoCEnante 优化集合通信 | 直接套用 NCCL 环形通信 | 小消息、低并发时通信步骤更少 |
| 并发评估 | 同时看总吞吐与每位用户吞吐 | 只看集群总吞吐 | 高并发下单用户速度可能下降 |
| 模型编排 | Switchyard 在模型池之间路由请求 | 为所有请求固定使用最大模型 | 小模型可承接更多流量 |
| 故障恢复 | 借助自动化工作负载恢复机制 | 任务失败后人工重启 | 降低长时间训练的中断损失 |
RoCEnante 不是所有拓扑的默认答案
RoCEnante 的收益依赖通信路径。它让每个 rank，也就是参与计算的设备，直接与其他设备交换输入，再在本地归约。相较环形 all-reduce 的多轮逐级传递，通信步骤更少；但每个节点都要向所有对等节点发送完整输入，数据移动量更大。
因此，消息更大、参与节点更多、并发更高时，环形方案更节省带宽。NVIDIA 明确指出，面向高并发、更大集群或环形拓扑，NCCL 会表现得更好。RoCEnante 已合入 FlashInfer；如果启动测试失败，会透明回退到 NCCL。
这意味着八节点集群并不是简单选一个“更快通信库”，而是要根据拓扑和负载决定。官方给出的 Switch 拓扑优势，不能直接外推到环状网络。我的边界推算是：RoCEnante 更像低并发桌面推理的专用加速路径，而不是替代 NCCL 的通用升级。
真正能省成本的，是让请求选对模型
除了把一个模型摊到八张卡上，NVIDIA 还展示了 NeMo Switchyard 在同一八节点集群上编排多个模型池的方案。根据 NVIDIA 的另一篇技术说明，Switchyard 可以依据请求特征和模型能力，在模型池之间进行路由。
官方测试显示，当大部分流量转向较小模型时，聚合吞吐最高提升到 3 倍，同时在工具调用基准中保持了与只使用 Qwen 模型相当的质量。这意味着模型路由不是独立于硬件扩展之外的“调度层功能”，而是决定集群能否持续工作的关键环节。
例如，同一个 Agent（能调用工具并执行多步任务的 AI 程序）可能同时产生简单分类、长文总结和复杂代码修改。若全部请求都进入 753B 模型，八节点集群会承担高成本、高延迟路径；若先由小模型处理简单任务，再把困难请求升级到大模型，系统才可能同时改善成本和响应速度。
在 NVIDIA 的 Switchyard GitHub 仓库中，开发者可以查看相关编排实现。官方博客 Route AI Agent Workloads Across Models with NVIDIA NeMo Switchyard 则进一步介绍了模型池路由的设计思路。
训练结果亮眼，但适用模型更窄
NVIDIA 还报告了在八节点上从头预训练 nanochat 模型的结果：取得 7.79 倍加速，扩展效率达到 97.4%。按官方的扩展效率定义，这已经接近线性扩展。
但这个结论不能直接套到 753B 模型。nanochat 属于更小的训练对象，参数规模、通信模式和计算负载与大模型不同。官方同时给出了另一条限制：八节点集群的 NVIDIA Sync 支持计划在当年年底推出；集群助手会负责设置和设备管理，但八节点支持并非发布当天就能完整获得。
因此，现在值得看的是方案和边界已经公开，而不是所有团队今天都能复现全部数字。读者还需等待具体软件版本、模型兼容性和集群支持到位。
适合谁：把“大模型能跑”改成可验证问题
DGX Spark 八节点集群更适合三类工作：本地部署无法装入单节点的大模型；需要持续运行、避免云端数据传输的 Agent 工作负载；以及希望研究分布式推理与模型路由的团队。
如果需求只是个人试用一个中小模型，八节点系统可能过于复杂；如果任务依赖稳定的大规模云端服务，桌面集群仍要面对并发下降、通信拓扑选择和故障恢复成本。我的判断是，最值得采用的采购标准并非“能装下多少参数”，而是三个可复测问题：目标模型在目标并发下，每位用户能获得多少 token/s；停掉一个节点后任务如何恢复；流量能否由模型路由自动分配。
NVIDIA 的技术博客 Running Frontier-Class AI Models Across 8 NVIDIA DGX Spark Nodes 给出了容量、通信、路由和训练四组数据；开发者博客主页 NVIDIA Developer Blog 还收录了分布式故障诊断与自动恢复的配套说明。它们共同指向一个更实际的结论：八节点 Spark 的价值不是把云端规模搬到桌面，而是让大模型推理、多模型编排和小规模实验可以在同一套本地硬件上组成可管理的工作流。
参考来源
评论区
登录后可评论。