AI开发者已不再满足于运行单一模型——他们正在并行调度多个模型、串联推理调用，并尝试需要数百GB内存的前沿级架构。NVIDIA DGX Spark的设计初衷是将AI开发能力带到桌面端，而现在用户可以连接更多的Spark节点。
在GTC柏林大会上，NVIDIA宣布正式支持八节点DGX Spark集群，将统一内存扩展至1TB，从而为前沿级模型、多智能体工作负载以及近乎线性的预训练打开了大门——所有这些均可在本地运行。
NVIDIA Sync让集群搭建变得简单。其Cluster Assistant（集群助手）负责处理设置和设备管理工作。NVIDIA Sync对八节点集群的支持将于今年年底前上线。
以下是关于推理、编排和训练随集群规模扩展而变化的基准测试数据。
运行更大、更新的前沿级模型
八节点集群最大的优势在于内存容量。单台DGX Spark提供128GB统一内存；四节点可达512GB；八节点则可达1TB。这一容量使得此前在四节点系统上根本无法启动的一类模型得以运行，其中包括Z.ai推出的完整版GLM 5.3（7530亿参数）模型。
集群的设计目标不仅是容纳这些模型，更在于以交互方式为其提供服务。作为早期示例，我们在八节点集群上运行了GLM 5.3 Flash，测得生成速度约为每秒80个Token（TPS），这一速度足以支撑针对前沿级混合专家模型的本地交互式开发。
完整版GLM 5.3（7530亿参数）检查点可在8×128GB集群上运行，使其成为可本地部署的最大开源模型之一。
借助Spark优化后端实现更快的集合通信
张量并行推理会将相当一部分时间消耗在诸如all-reduce等集合操作上。在采用交换机连接的集群中，我们评估了一种经Spark优化的集合通信后端——RoCEnante，它针对本地AI硬件上典型的张量并行解码场景（小消息、低并发、适中数量的计算节点）降低了集合通信延迟。
该后端实现了一种全交换（all-to-all）机制，随后进行本地归约。每个计算节点将自己的输入共享给其他所有节点，然后在本地完成求和。整个交换与归约过程由单个GPU内核统一协调。
这种方式的主要优势在于减少了通信步骤。环形all-reduce需要经过多轮在相邻节点间传递数据。而该方案直接与所有对等节点交换数据，避免了逐级转发的链条。对于小消息和适中数量的计算节点而言，这可以降低延迟。
但代价是数据传输量增加。每个节点都要将完整输入发送给其他所有节点，并自行完成所有输入的归约。随着消息体量或节点（计算单元）数量的增长，这部分额外流量的开销会逐渐增大，这时环形all-reduce在带宽效率上的优势就会愈发凸显。如果需要支持高并发、更大规模集群或环形拓扑结构，NVIDIA集合通信库（NCCL）的表现会更出色。
实测结果显示，在四节点（NVFP4）配置下，预填充（prefill）吞吐量提升约5%，解码（decode）吞吐量提升约21%；在八节点的非量化模型上，解码吞吐量提升约18%，这与上述延迟与带宽之间的权衡关系相符。该后端已合并至FlashInfer中，若启动测试失败会自动透明回退至NCCL。
该后端仅适用于交换机连接的拓扑结构，因为它依赖于每个节点之间的直接点对点交换。它并非要取代NCCL——NCCL仍是官方支持的默认方案，并且随着集群规模和并发量的增加，依然是更优的选择。最初的一次性all-reduce方案由社区贡献者（Jason Cook/el8）提出。
二、四、八节点：集群规模扩展
低延迟的NVIDIA ConnectX-7网卡以及基于融合以太网的RDMA（RoCE）通信技术，使DGX Spark节点之间能够高效交换张量数据，从而可以通过跨更多节点扩展模型来满足内存容量需求并提升吞吐量。为了独立观察集群扩展行为并排除上下文相关因素的干扰，我们在不使用推测解码/MTP的情况下，对一个稠密的Qwen3.8-27B（NVFP4）模型进行了从一到八节点的基准测试。
测试结果呈现出两个显著特点。首先，解码吞吐量随节点数量增加而大幅提升，从单节点约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.5倍。
当四分之一请求路由至Qwen、其余路由至MiniCPM时，整体吞吐量提升约3.0倍。
路由策略只需一个简单的YAML文件即可配置，NVIDIA提供了一份示例策略作为起点，开发者可以根据自身工作负载调整分流比例和分类器设置。
从零开始预训练：nanochat展现近乎线性的扩展效果
训练过程的表现与推理不同。当每个节点都保存完整的模型副本时，跨节点通信仅需在每一步完成一次梯度同步，因此集群扩展能够实现接近线性的效果。为验证这一点，我们从零开始预训练了一个nanochat模型（约8.965亿参数、20层transformer结构、隐藏层维度1,280，序列长度2,048个Token），并在逐步增加节点时测量训练吞吐量。
八节点配置实现了7.79倍的加速比，效率达到97.4%，这种近乎线性的扩展效果使八节点Spark集群不仅能够胜任大模型的服务任务，同样也是从零开始训练小模型的可靠平台。这也构成了一种自然的渐进式工作流：先在本地完成原型验证和预训练，再随着模型规模增长逐步扩展。
如果想复现这项nanochat预训练实验，或将其应用于自己的模型，完整代码已在GitHub上公开。
开启DGX Spark多系统之旅
八节点DGX Spark集群为你提供了加载前沿级模型所需的内存容量、同时编排多个模型的灵活性，以及从零开始训练小模型的高效能力——所有这些都可以在桌面端完成。
欲了解更多信息，请参阅：
连接多台DGX Spark设备以支持分布式工作负载
通过vLLM在DGX Spark上部署大语言模型服务
查阅模型兼容性指南及Switchyard编排相关资源
立即开始在NVIDIA DGX Spark上构建你的应用。
