NVIDIA DGX Spark 八节点集群：本地运行前沿AI模型

AI 开发者不再只是运行单个模型——他们在并行编排多个模型、串联推理调用，并试验需要数百 GB 内存的前沿级架构。NVIDIA DGX Spark 的诞生就是为了把 AI 开发带到桌面上，而现在你可以把更多 Spark 节点连接在一起。

在柏林 GTC 上，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）检查点在 8x 128 GB 集群上运行，使其成为你可以在本地服务的最大开源模型之一。

表 1. 完整 GLM 5.3（nvidia/GLM-5.3-NVFP4）在八节点 DGX Spark 集群上的性能。该模型在 NVFP4 下约为 470 GB，使用 MTP3 在并发一、四和八下测量。预填充按每请求 8K 输入序列长度（ISL）测量。

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

张量并行推理有相当一部分时间花在 all-reduce 等集合操作上。在交换机连接的集群上，我们一直在评估一个 Spark 优化的集合通信后端 RoCEnante，它针对本地 AI 硬件上张量并行解码典型的小消息、低并发、中等 rank 数量模式，降低了集合通信延迟。

该后端实现先进行全对全交换，然后进行本地归约。每个 rank 将其输入与所有其他 rank 共享，然后在本地对输入求和。单个 GPU 内核协调交换和归约。

主要好处是通信步骤更少。环形 all-reduce 通过多轮在相邻 rank 之间传递数据。这种方法直接与所有对等方交换数据，避免了那条转发链。对于小消息和适中的 rank 数量，这可以降低延迟。

代价是更多的数据移动。每个 rank 将其完整输入发送给每个对等方，并自行归约所有输入。随着消息或 rank（节点）数量增长，这种额外流量变得更加昂贵，使得环形 all-reduce 的带宽效率越来越有吸引力。如果你需要支持高并发、更大的集群或环形拓扑，NVIDIA Collective Communications Library（NCCL）会表现更好。

在实践中，我们看到在四个节点（NVFP4）时预填充吞吐量约高 5%，解码吞吐量约高 21%，而在非量化模型的八个节点上解码吞吐量约高 18%，这与上述延迟与带宽的权衡一致。该后端已合并到 FlashInfer 中，如果其启动测试失败，会透明地回退到 NCCL。

该后端仅适用于交换机连接的拓扑，因为它依赖于每个节点之间的直接点对点交换。它不是 NCCL 的替代品，NCCL 仍然是受支持的默认选项，并且随着集群规模和并发增长是更好的选择。原始的一次性 all-reduce 方法由社区（Jason Cook/el8）贡献。

二、四、八：扩展集群

低延迟 NVIDIA ConnectX-7 NIC 和基于融合以太网的 RDMA（RoCE）通信让 DGX Spark 节点能够高效交换张量，因此你可以将模型扩展到更多节点以将其放入内存并提高吞吐量。为了隔离集群扩展行为并消除上下文相关行为，我们在一个到八个节点上对没有投机解码/MTP 的密集 Qwen3.8-27B（NVFP4）模型进行了基准测试：

表 2. NVIDIA/Qwen3.8-27B（NVFP4）跨拓扑扩展，在支持时使用 ROCEnante 后端。使用 llama-benchy 测量，8192 token ISL 和 256 token OSL，并发为 1。扩展相对于相同精度下的单个 Spark。

有两种模式很突出。首先，解码吞吐量随节点数强劲扩展，从单节点约 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 节点），我们得到：

• 当一半请求路由到 Qwen 时，总吞吐量约为仅 Qwen 基线的 ~1.5x。
• 当四分之一请求路由到 Qwen、其余路由到 MiniCPM 时，总吞吐量约为 ~3.0x。

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

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

训练的行为与推理不同。当每个节点持有模型的完整副本时，唯一的跨节点通信是每步一次的梯度同步，因此集群扩展接近线性。为演示这一点，我们从零预训练了一个 nanochat 模型（约 896.5M 参数、20 个 transformer 层、隐藏维度 1,280，序列长度 2,048 个 token），并测量了增加节点时的训练吞吐量。

表 3. Nanochat 预训练吞吐量从一节点到八节点 DGX Spark 的扩展（每步全局批次 524,288 个 token，每 GPU 微批次 32 个序列）。

八节点实现 7.79x 加速，效率达 97.4%，这种近线性扩展使八节点 Spark 集群成为从零训练小型模型的可靠平台，而不仅仅是服务大型模型。它也是一条自然的入门工作流：在本地进行原型设计和预训练，然后随着模型增长而扩展。

要复现 nanochat 预训练实验或将其适配到你自己的模型，完整代码可在 GitHub 上获取。

开始使用多系统 DGX Spark

八节点 DGX Spark 集群为你提供加载前沿级模型所需的内存、同时编排多个模型的灵活性，以及从零训练小型模型的效率，全部在桌面上完成。

要了解更多，请查看：

• 连接多台 DGX Spark 机器以运行分布式工作负载
• 在 DGX Spark 上使用 vLLM 服务 LLM
• 探索模型兼容性指南和 Switchyard 编排资源

立即开始在 NVIDIA DGX Spark 上构建。