2026 年 10 月 22 日
作者： Arvind Gopalakrishnan, Eugene Rakhmatulin, Manini Sharma 和 Prerit Rodney
讨论 (0)
AI 生成的摘要
- NVIDIA DGX Spark 现已支持官方八节点集群，统一内存扩展至 1 TB，并可在本地运行前沿级模型，例如来自 Z.ai 的完整 GLM 5.3（753B）。
- 一个名为 RoCEnante 的 Spark 优化集合通信后端，可降低交换机连接集群上张量并行解码的 all-reduce 延迟，在八节点上实现 4.43 倍解码加速，而未使用该后端时为 3.05 倍。
- 基准数据显示，使用 Qwen3.8-27B（NVFP4）时，解码吞吐从单节点约每秒 12 个 token 扩展到八节点每秒 52 个 token；交换机拓扑支持灵活的工作负载划分，环形拓扑则提供高性价比的四节点推理。
- NVIDIA NeMo Switchyard 在共享的八节点集群上于模型池之间路由请求，在工具使用基准测试中达到与仅使用 Qwen 时相当的质量，同时在大部分流量转向较小模型时将总吞吐量提升至多 3 倍。
- 在八节点上从头预训练 nanochat 模型实现了 7.79 倍加速，扩展效率达 97.4%，表明小型模型在桌面上可达到接近线性的训练性能。
后续步骤
- 探索 连接多台 DGX Spark 机器以处理分布式工作负载 ，搭建多节点集群。
- 使用 跨 DGX Spark 的 vLLM 进行分布式推理来部署 LLM。
- 查阅 模型兼容性指南和 Switchyard 编排资源 ，了解多模型路由。
AI 开发者不再只是运行单个模型——他们正在并行编排多个模型、串联推理调用，并试验需要数百 GB 内存的前沿级架构。 NVIDIA DGX Spark 的初衷是将 AI 开发带到桌面上，而现在你可以将更多 Spark 节点连接在一起。
在 GTC Berlin 上，NVIDIA 宣布正式支持八节点 DGX Spark 集群，将统一内存扩展至 1 TB，为前沿级模型、多智能体工作负载和接近线性的预训练打开了大门——所有这些都在本地运行。
NVIDIA Sync 让集群搭建变得简单。其 Cluster Assistant 负责设置和设备管理。NVIDIA Sync 对八节点集群的支持将于今年年底前推出。
继续阅读，了解随着集群扩展，推理、编排和训练如何扩展的基准数据。
运行更大、更新的前沿级模型
八节点集群的最大优势在于内存。单台 DGX Spark 提供 128 GB 统一内存；四个节点达到 512 GB；八个节点达到 1 TB。这一容量为之前无法在四节点系统上启动的一类模型打开了大门，包括来自 Z.ai 的完整 GLM 5.3（753B）模型。
除了容纳这些模型之外，该集群还设计用于交互式地服务它们。作为一个早期示例，我们在八节点集群上运行了 GLM 5.3 Flash，测得生成速度约为每秒 80 个 token（TPS），适合针对前沿级混合专家模型进行交互式本地开发。
完整的 GLM 5.3（753B）检查点可在 8×128 GB 集群上运行，使其成为可在本地部署的最大开源模型之一。
| 并发数 | 预填充，总每秒 token 数（TPS） | 预填充，每用户（TPS） | 解码，总计（TPS） | 解码，每用户（TPS） |
| 1 | 1,600 | 1,600 | 31 | 31 |
| 4 | 1,600 | 750 | 51 | 21 |
| 8 | 1,600 | 473 | 67 | 18 |
使用 Spark 优化后端实现更快的集合通信
张量并行推理有相当一部分时间花在 all-reduce 等集合操作上。在交换机连接的集群上，我们一直在评估一个 Spark 优化的集合通信后端 RoCEnante，它可降低本地 AI 硬件上张量并行解码所典型的小消息、低并发、中等 rank 数量模式下的集合通信延迟。
该后端实现先进行全对全交换，然后进行本地归约。每个 rank 将其输入共享给其他所有 rank，然后在本地将输入相加。单个 GPU 内核协调交换和归约。
主要优势在于通信步骤更少。环形 all-reduce 通过多轮在相邻 rank 之间传递数据。这种方法直接与所有对等节点交换数据，避免了这种转发链。对于小消息和适中的 rank 数量，这可以降低延迟。
代价是数据移动更多。每个 rank 将其完整输入发送给每个对等节点，并自行归约所有输入。随着消息或 rank 数量（节点）增长，这种额外流量会变得更加昂贵，使得环形 all-reduce 的带宽效率越来越有吸引力。如果你需要支持高并发、更大的集群或环形拓扑，NVIDIA 集合通信库（NCCL）会表现更好。
在实践中，我们看到在四节点（NVFP4）上预填充吞吐量约高 5%、解码吞吐量约高 21%，在八节点上非量化模型的解码吞吐量约高 18%，这与上述延迟与带宽的权衡一致。该后端已合并到 FlashInfer 中，如果其启动测试失败，会透明地回退到 NCCL。
该后端仅适用于交换机连接的拓扑，因为它依赖每个节点之间的直接点对点交换。它并非 NCCL 的替代品，NCCL 仍是受支持的默认选项，并且随着集群规模和并发度的增长是更好的选择。最初的一次性 all-reduce 方法由社区贡献（Jason Cook/el8）。
二、四、八：扩展集群
低延迟 NVIDIA ConnectX-7 网卡 以及基于融合以太网的 RDMA（RoCE）通信，让 DGX Spark 节点能够高效交换张量，因此你可以将模型扩展到更多节点，以将其装入内存并提升吞吐量。为了隔离集群扩展行为并消除依赖上下文的因素，我们在 1 到 8 个节点上对未使用推测解码/MTP 的稠密 Qwen3.8-27B（NVFP4）模型进行了基准测试：
| Spark 节点数量 | 拓扑 | 预填充（TPS） | 预填充扩展 | 解码（TPS） | 解码扩展 |
| 1 | — | 2,635 | 1.00x | 11.86 | 1.00x |
| 2 | 直连 | 3,285 | 1.25x | 21.71 | 1.838x |
| 4 | 物理环 | 4,446 | 1.69x | 32.82 | 2.77x |
| 4 | 交换机（ROCEnante） | 4,556 | 1.73x | 36.34 | 3.06x |
| 8 | 物理环 | 4,962 | 1.88x | 40.11 | 3.38x |
| 8 | 交换机（ROCEnante） | 5,105 | 1.94x | 52.58 | 4.43x |
有两种模式尤为突出。首先，解码吞吐量随节点数量强劲扩展，从单节点的约 12 TPS 提升到八节点的 52 TPS。
其次，最佳拓扑取决于工作负载：当单个模型分布到所有节点时，物理环可提供出色的解码吞吐量。一旦你希望将集群拆分为独立分组，或运行需要节点间直接任意对任意连接的工作负载，就需要交换机。
要自行尝试， 本网络指南 从双节点配置开始，逐步扩展，带你完成集群设置。
无交换机环拓扑与设置简便性
并非每个集群都需要交换机。DGX Spark 节点可以直接以环状连接在一起，这降低了成本并简化了设置——对爱好者和小型部署来说是一个有吸引力的选择。
在四节点 DGX Spark 部署中，NCCL 默认对张量并行通信采用基于环的算法，使无交换机环拓扑能够与流量模式完美契合，并以更低成本提供令人印象深刻的吞吐量。如表 2 所示，四节点环在此工作负载的预填充和解码吞吐量方面表现良好。
随着规模扩大或用途专门化，情况会发生变化：
- 八节点或拆分分配： 如果你想把集群拆分为例如两组四节点，环无法表达这种拓扑；你需要交换机。
- 全对全和传统 HPC 工作负载： 任何依赖点对点模式（例如基于 MPI 的集群）的工作负载都需要交换机；环会付出跳数惩罚。
- 优化的集合通信后端： 上述经 Spark 优化的后端要求每个节点之间直接点对点连接，因此仅适用于交换式配置。
简而言之：当你想要最简单、成本最低的四节点推理设备时，选择无交换机环拓扑；当你需要扩展到八节点、拆分集群，或运行环拓扑无法满足的通信模式时，选择交换机。
使用 Switchyard 进行多模型编排
并非每个请求都需要你最大的模型。在共享的八节点集群上，将简单请求路由到小型、快速的模型，并将较大的模型保留给困难请求，可以显著提高总体吞吐量。
NVIDIA NeMo Switchyard 使这一方案切实可行：一个轻量级分类器检查每个请求（或会话）并将其路由到相应的模型池，负载均衡器则在副本之间分配流量。由于这种布局将八个节点拆分为独立的模型池，Switchyard 运行在交换机连接的集群上，从而提供跨副本路由请求所需的任意对任意连接。
在我们的原型中，我们使用 OpenBMB 的 MiniCPM5 2B 作为分类器和简单任务的执行模型，并使用 Qwen3.8 Flash Next 处理复杂任务。在标准加困难工具使用基准测试中，路由智能体在质量上匹配了仅使用 Qwen 的配置，同时释放了集群容量。
在 92 个用例的工具使用基准测试（包括困难用例）中，路由智能体得分为 91/100，与仅使用 Qwen 的配置持平。
由于每个副本的 MiniCPM 每秒处理的请求数约为 Qwen 的一个数量级，将部分流量转移到较小的模型可提高整个集群的吞吐量上限。在八个节点上分配三个 Qwen 副本（每个占用两个 Spark 节点）和两个 MiniCPM 副本（每个占用一个 Spark 节点），我们得到：
- 约 1.5 倍 当一半请求路由到 Qwen 时，总体吞吐量相对于仅使用 Qwen 的基线。
- 约 3.0 倍 当四分之一请求路由到 Qwen、其余路由到 MiniCPM 时的总体吞吐量。
路由策略是一个简单的 YAML 文件，NVIDIA 提供了示例策略作为起点；开发者可以根据自己的工作负载调整分流比例和分类器。
从头开始预训练：使用 nanochat 实现近线性扩展
训练的行为与推理不同。当每个节点持有模型的完整副本时，唯一的跨节点通信是每步一次的梯度同步，因此集群扩展接近线性。为进行演示，我们从零开始预训练了一个 nanochat 模型（约 8.965 亿参数、20 个 transformer 层、隐藏维度 1,280，序列长度 2,048 个 token），并在增加节点时测量训练吞吐量。
| 节点 | TPS | 加速比 | 扩展效率 |
| 1 | 8,741 | 1.00 倍 | 100.0% |
| 2 | 17,202 | 1.97 倍 | 98.4% |
| 4 | 33,640 | 3.85 倍 | 96.2% |
| 8 | 68,079 | 7.79 倍 | 97.4% |
八个节点实现了 7.79 倍加速和 97.4% 的效率，这种近乎线性的扩展使八节点 Spark 集群成为从头训练小型模型的可靠平台，而不仅仅是服务大型模型。它也是一条自然的入门工作流：先在本地进行原型设计和预训练，然后随着模型增长而扩展。
要复现 nanochat 预训练实验或将其适配到你自己的模型，完整代码可在 GitHub.
上获取。开始使用多系统 DGX Spark
八节点 DGX Spark 集群为你提供加载前沿级模型所需的内存、同时编排多个模型的灵活性，以及从头训练小型模型的效率，而这一切都放在桌面上。
要了解更多，请查看：
讨论 (0)标签
智能体 AI / 生成式 AI | 开发者工具与技术 | 通用 | NeMo | 中级技术 | 基准测试 | AI 智能体 | AI 推理 | ConnectX | DGX Spark | GTC Berlin 2026 | LLM关于作者
关于 Arvind Gopalakrishnan
Arvind Gopalakrishnan 是 NVIDIA 的系统软件总监，领导 NVIDIA DGX Spark 和 NVIDIA DGX Station 上 GPU 本地 AI 平台的软件工程工作。他专注于这些平台上的软件工程，涵盖推理性能、多节点互连架构、模型支持、平台稳定性、认证和发布就绪——并与产品、固件和硬件团队紧密合作。凭借涵盖 GPU 驱动、平台和 NVIDIA 软件栈的深厚系统级技术功底，Arvind 将亲力亲为的工程领导力与跨职能影响力相结合，以协调团队并推动整个技术栈的执行。 查看 Arvind Gopalakrishnan 的所有文章
关于 Eugene Rakhmatulin
Eugene Rakhmatulin 是 NVIDIA 的首席软件工程师，专注于本地 AI 解决方案。他是 spark-vllm-docker 的创建者，这是一个开源项目，可简化使用 vLLM 在 NVIDIA DGX Spark 上部署和运行大型语言模型，同时支持单机系统和集群。凭借在软件开发、系统架构和技术领导方面三十年的经验，他曾在初创公司、非营利组织和跨国公司构建软件平台并领导工程团队。 查看 Eugene Rakhmatulin 的所有文章
关于 Manini Sharma
Manini Sharma 是 NVIDIA 的高级产品经理，负责 NVIDIA RTX Spark 台式机和 DGX Spark。她拥有超过二十年的经验，涵盖产品管理、产品营销和软件工程，曾主导多款旗舰芯片和平台产品从概念走向市场。她将深厚的技术功底与商业战略相结合，推动产品增长，并交付能引起开发者和客户共鸣的平台。 查看 Manini Sharma 的所有文章
关于 Prerit Rodney
Prerit Rodney 是 NVIDIA 的高级软件工程师，专注于本地 AI 系统以及 NVIDIA DGX Spark、DGX Station 和 RTX 上的体验。他拥有为不同生态系统设计和开发操作系统及应用软件的背景。他曾主导多个技术项目，并在多个领域提升了系统和运营效率。 查看 Prerit Rodney 的所有文章