在 8 个 NVIDIA DGX Spark 节点上运行前沿 AI 模型

AI 开发者不再只是运行单个模型，而是并行编排多个模型、关联推理调用，以及尝试需要数百 GB 内存的前沿架构。NVIDIA DGX Spark 旨在将 AI 开发引入桌面，现在您可以将更多 Spark 节点连接在一起。

在 GTC 柏林大会上，NVIDIA 宣布正式支持 8 节点 DGX Spark 集群，将统一内存扩展至 1 TB，并为前沿模型、多智能体工作负载和近线性预训练敞开了大门，所有这些都在本地运行。

NVIDIA Sync可轻松实现集群。其集群助手负责设置和设备管理。NVIDIA Sync将于今年年底推出对 8 节点集群的支持。

继续阅读以获取基准测试数据，了解推理、编排和训练如何随着集群的发展而扩展。

运行更大、更新的前沿级模型

8 节点集群的最大优势是内存。单个 DGX Spark 可提供 128 GB 的统一显存；四个节点达到 512 GB；八个节点达到 1 TB。这种容量为以前无法在四节点系统上启动的模型打开了大门，其中包括 Z.ai 的完整 GLM 5.3 (753B) 模型。

除了简单地拟合这些模型外，集群还旨在以交互方式为它们提供服务。作为早期示例，我们在一个 8 节点集群上运行 GLM 5.3 Flash，并测得每秒生成大约 80 个 token (TPS) ，适用于前沿混合专家模型的交互式本地开发。

完整的 GLM 5.3 (753B) 检查点在 8x 128 GB 集群上运行，这使其成为可以在本地提供服务的最大开放模型之一。

使用 Spark 优化的后端实现更快速的集合

张量并行推理将有意义的一部分时间用于聚合运算，例如 all-reduce。在交换机连接的集群上，我们一直在评估 Spark 优化的集合后端 RoCEnante，它可以降低本地 AI 硬件上张量并行解码的典型小消息、低并发、适度秩计数模式的集合延迟。

此后端实现了 all-to-all 交换，然后是局部归约。每个秩与其他每个秩共享其输入，然后在本地添加输入。单个 GPU 内核负责协调交换和归约。

其主要优势在于通信步骤更少。Ring all-reduce 会在多个回合中在相邻秩之间传递数据。这种方法直接与所有对等方交换数据，从而避免转发链。对于小消息和少量 rank，这可以降低延迟。

权衡取舍的是更多的数据移动。每个秩将其全部输入发送给每个节点，并减少所有输入本身。随着消息或 rank (节点) 数量的增加，这种额外的流量变得更加昂贵，使得 ring all-reduce 的带宽效率变得越来越有吸引力。如果您需要支持高并发、更大的集群或环形拓扑，NVIDIA 集合通信库 (NCCL) 的性能会更好。

在实践中，我们发现在非量化模型中，4 个节点的预填充和解码吞吐量分别高出约 5% 和 21% (NVFP4) ，8 个节点的解码吞吐量高出约 18%，这与上述延迟与带宽权衡一致。后端合并到 FlashInfer 中，如果启动测试失败，则会透明地回退到 NCCL。

后端仅适用于交换机连接的拓扑，因为它依赖于每个节点之间的直接点对点交换。它不能取代 NCCL，后者仍然是受支持的默认设置，并且随着集群大小和并发性的增长，是更好的选择。最初的 one-shot all-reduce 方法由社区提供 ( Jason Cook/el8) 。

二、四、八：扩展集群

低延迟的 NVIDIA ConnectX-7 网卡 和 RDMA on Converged Ethernet (RoCE) 通信使 DGX Spark 节点能够高效交换张量，因此您可以在更多节点上扩展模型，使其适合显存并提高吞吐量。为隔离集群扩展行为并消除上下文相关行为，我们对密集 Qwen3.8-27B (NVFP4) 模型进行了基准测试，而无需跨 1 至 8 个节点进行预测解码/ MTP：

两种模式比较突出。首先，解码吞吐量会随着节点数量的增加而大幅增长，从单个节点上的约 12 TPS 扩展到 8 个节点上的 52 TPS。

其次，最佳拓扑取决于工作负载：物理环可为分布在所有节点上的单个模型提供出色的解码吞吐量。如果您想将集群拆分成独立的组，或者运行需要节点之间直接进行任意连接的工作负载，则需要交换机。

为了亲自尝试，本网络指南介绍了集群设置，从双节点配置开始，然后纵向扩展。

无交换环形拓扑和设置简便性

并非每个集群都需要交换机。DGX Spark 节点可以直接连接在一起，从而降低成本并简化设置，这对于发烧友和小型部署来说是一个很有吸引力的选择。

在 4 节点 DGX Spark 部署中，NCCL 默认采用基于环的算法进行张量并行通信，从而使无交换环形拓扑与流量完美匹配，并以更低的成本提供惊人的吞吐量。如表 2 所示，四节点环在此工作负载的预填充和解码吞吐量方面表现出色。

画面会随着您的扩展或专门化而发生变化：

• 8 个节点或拆分分配：如果您想将集群拆分成两组 (每组 4 个) ，则圆环无法表示该拓扑；您需要一个交换机。
• 多对多和传统的 HPC 工作负载：任何依赖于点对点模式的工作 (例如，基于 MPI 的集群) 都需要一个交换机；一个圆环会产生跳跃损失。
• 优化的集合后端：上述 Spark 优化后端需要每个节点之间的直接点对点连接，因此仅适用于交换配置。

简而言之：当您需要最简单、成本最低的四节点推理箱时，请选择无交换环；当您需要扩展到八个节点、拆分集群或运行环无法提供的通信模式时，请选择交换机。

使用 Switchyard 进行多模型编排

并非每个请求都需要您的最大模型。在共享的 8 节点集群上，您可以将简单的请求路由到快速的小型模型，并为困难的模型保留更大的模型，从而获得更多的聚合吞吐量。

NVIDIA NeMo Switchyard实现了这一点：轻量级分类器会检查每个请求 (或会话) 并将其路由到相应的模型池，负载均衡器则会在副本之间分配流量。由于这种布局将 8 个节点拆分为独立的模型池，Switchyard在交换机连接的集群上运行，该集群提供跨副本路由请求所需的任意连接。

在原型中，我们使用 OpenBMB 的 MiniCPM5 2B 作为简单任务的分类器和执行模型，并使用 Qwen3.8 Flash Next 作为复杂任务的分类器和执行模型。在标准加硬工具使用基准测试中，路由代理与仅 Qwen 配置的质量相匹配，同时释放集群上的容量。

在 92 个案例的工具使用基准测试 (包括硬案例) 中，路由代理的得分为 91/ 100，与仅 Qwen 的配置相匹配。

由于 MiniCPM 每秒大约比每个副本的 Qwen 多一个数量级，因此将部分流量转移到较小的模型会提高整个集群的吞吐量上限。在八个节点上分配三个 Qwen 副本 (每个节点有两个 Spark 节点) 和两个 MiniCPM 副本 (每个节点有一个 Spark) ，我们得到：

• 当一半的请求通过 Qwen 时，总吞吐量约为仅使用 Qwen 的基准的 1.5 倍。
• 约3.0倍总吞吐量当四分之一的请求通过 Qwen，其余请求通过 MiniCPM 时。

路由策略是一个简单的 YAML 文件，NVIDIA 提供示例策略作为起点；开发者可以根据自己的工作负载调整拆分和分类器。

从头开始预训练：使用 nanochat 实现近线性扩展

训练的行为不同于推理。当每个节点持有模型的完整副本时，唯一的跨节点通信是每步梯度同步一次，因此集群的扩展接近线性。为了演示，我们从头开始预训练了一个 nanochat 模型 (大约 8.965 亿个参数、20 个转换器层、隐藏维度 1280 和 2048 个token序列) ，并测量了添加节点时的训练吞吐量。

8 个节点可将速度提升至原来的 7.79 倍，效率为 97.4%，这种近乎线性的扩展使 8 个节点的 Spark 集群成为一个可靠的平台，不仅可以服务大型模型，还可以从头开始训练小型模型。这也是一种自然的上工作流：在本地进行原型设计和预训练，然后随着模型的增长横向扩展。

如需重现 nanochat 预训练实验或使其适应您自己的模型，请在 GitHub 上获取完整代码。

开始使用多系统 DGX Spark

8 节点 DGX Spark 集群可提供用于加载前沿模型的内存、一次编排多个模型的灵活性，以及从头开始训练小型模型的效率，所有这些都在桌面上进行。

如需了解详情，请查看：

• 连接多台 DGX Spark 计算机以处理分布式工作负载
• 在 DGX Spark 中使用 vLLM 服务 LLM
• 探索模型兼容性指南和交换机场编排资源

立即开始基于 NVIDIA DGX Spark 进行构建。