如何把八台DGX Spark拼成了1TB“显存”怪物

最近半年，"本地部署大模型"这件事明显热闹起来了。讨论的重点已经不再是有没有一块能打的GPU，而是有没有足够大的内存把动辄几百GB的权重塞进去——开源模型一个比一个大，消费级设备的内存天花板却迟迟没动。于是"多机互联"变成了一个绕不开的话题：能不能把两台、三台甚至更多台设备拼起来，凑出一个跑得动大模型的集群？

我们至顶AI实验室在26年年初的时候究过这个方向，拿到了华硕基于英伟达GB10芯片打造的Ascent GX10迷你超算，自己动手做了双机、三机互联的测试——单机128GB共享内存，可以分出100多GB当显存用，支持通过ConnectX-7端口高速串联，但官方教程只写到两台，三台完全是我们自己摸索出来的。

带着同样的好奇，我们也留意到了海外一个更极端的案例：科技博主Alex Ziskind没有止步于两台、三台，直接把设备数量拉到了八台，拼出了一个1TB“显存”的集群。

他自己在视频里的说法是：把八台DGX Spark接成了一个1TB“显存”的集群，因为NVIDIA没有展示怎么连三台以上。整期内容记录了他把四台、后来又扩展到八台NVIDIA DGX Spark连成一个分布式推理集群的全过程——中间换了三批网线才排查到真正的瓶颈，被交换机的隐藏设置坑了一整夜，最后跑起了一个磁盘体积800GB、连512GB内存的Mac Studio都装不下的开源大模型。NVIDIA给出的官方方案只支持恰好两台设备直连，三台或更多的级联并未获得官方支持，这条路上踩过的坑，比跑分本身更值得看。

说明：视频作者没有公开测试用的推理框架版本、模型量化精度是否统一、prompt长度和重复测试次数等细节，下文涉及的性能数据均直接来自视频画面展示的结果，读者在比较不同节点数的成绩时请留意这一点。

官方止步于两台，社区补上了后半段

四台DGX Spark叠在一起，理论上能凑出512GB内存，配合ConnectX-7网卡的高速互联和RDMA（远程直接内存访问），还能实现张量并行——按官方和社区的说法，这种连接方式理论上能做到连接越快、加入的机器越多扩展效率越高，区别于传统以太网集群那种“加机器就变慢”的规律。不过这只是理论卖点，Alex后续的实测数据要复杂得多：有的场景确实吃到了扩展红利，也有预填充速度不升反降、八节点小模型收益有限的情况，具体差异在下文的跑分里能看到。

但NVIDIA的官方文档只覆盖两台设备互连。无论Alex怎么问，官方都不愿意公开四台以上怎么连，这个缺口最终由一位活跃在NVIDIA论坛、代号Yuger的社区成员补上——他写了一套开源脚本，Alex后来的整套集群搭建都建立在这套方案之上。

三批网线，一次“50G诅咒”

要把四台Spark接成网状拓扑，Alex先花1300美元买了一台MikroTik交换机，配上两个400Gb端口，正好能用breakout线缆把四台机器全部接上。SSH互联、ping都没问题，但一测链路速度，只有50Gbps，被线缆卡住了：他手上这批是QSFP28规格，不是以为的QSFP56，两者外观相同，速度却差一倍。

换了一条标注QSFP56的线，还是50G。这次他把Claude拉进排查，得到的判断是：亚马逊listing标注的“QSFP56”，参数细看其实是“400G PAM4转4x100G”，末端接口很可能实际是QSFP28，标注和实物对不上——但Claude自己也可能判断错，卖家也可能夸大参数，唯一能验证的办法是再买一条。第三次他直接找NVIDIA官方合作的线缆商，买了专门标注“for DGX Spark”的线，接上后，还是50G——这一次线本身没有问题，卡点其实出在别的地方。

问题最终出在交换机本身：那个端口被硬编码锁定在50G速率，需要手动改成100G才匹配线缆的实际能力，这个设置是Claude通过SSH登录交换机翻出来的。改完之后，链路速度立刻跳到100Gbps。这里还有一个隐藏细节：每台Spark的两个物理网口，内部又各自拆成两条虚拟接口，每条虚拟接口上限是100Gbps，要跑满一条200Gbps的物理线缆，两条虚拟接口都得单独设成100G，只调物理端口是不够的。

四节点跑分：生成变快了，预填充却变慢了

排查完速率问题，用较小的Qwen 3 4B（完整BF16）测试，速率从50G升到100G之后，token生成速度只提升了7%，Alex自己都说这更像误差；但预填充（prompt processing）速度反而慢了19%，属于完全出乎意料的结果。Claude给出的解释是：生成阶段依赖频繁的小规模all-reduce通信，对链路延迟更敏感，所以变快有直接帮助；预填充变慢的原因则不明确。

单节点、双节点、四节点的完整对比更能说明趋势：单台生成23 tokens/s，两台35，四台的预填充在两节点时就已冲到接近8000 tokens/s的高点，之后反而没有线性增长。他随后用延迟测试补了一刀：一号Spark和二号Spark经交换机中转，延迟3微秒；把两台机器直接背靠背连接、绕开交换机，延迟降到2微秒左右。他把这个数字和苹果Mac Studio集群做了对比，后者延迟大约4到5微秒——DGX Spark加RDMA在延迟上明显占优，但延迟对小模型的影响有限，真正的差距要等模型变大才会显现。换成Qwen 3 VL 32B之后，单节点3.58 tokens/s，两节点6.14，四节点11.36，扩展比例总算符合预期。

扩到八台，先撞上端口不够用

尝到甜头后，Alex把书桌上另外三台设备也拉了进来：两台戴尔GB10、一台MSI Edge Expert、一台华硕Ascent GX10，凑够八台。但手上那台交换机只有两个400Gb端口，四台已经占满，要接八台必须再添一台。恰好MikroTik这时发布了带四个400Gb端口的新交换机，他提前下单换上——新交换机能同时支撑四台或八台DGX Spark组成集群，噪音不小，但至少还能放在桌面上忍受。

配置工作也翻倍复杂：给全部QSFP接口重新分配IP，把八台机器的netplan统一改成支持9000字节MTU的jumbo frames，再重建一遍SSH无密码网状互联——八台机器两两互联，去掉自连的情况，一共56条连接，全靠Claude批量处理完成，模型文件也用rsync同步到每台机器上。

真正需要八台的，是800GB级别的怪物模型

八节点上，小模型的短板暴露得更明显：Qwen 3 4B连续跑了两次，生成速度分别是64和61 tokens/s，比四节点快了约10 tokens/s，性价比很低；换成32B模型，每台机器内存占用冲到109GB左右，生成速度却只有16.5 tokens/s，相比四节点接近12 tokens/s的提升幅度并不算大。

真正的用武之地留给了专门为它准备的怪物——Qwen 3.5的397B参数（激活17B）版本，完整版磁盘体积约800GB，连512GB内存的Mac Studio都装不下。分片到八台机器耗时约7分钟，构建计算图再花3分钟，最终跑出24 tokens/s的生成速度。他又追加测了体积约600GB的Kimi K2，加载耗时约15分钟，单台机器内存一度冲到115GB，最终生成速度13.35 tokens/s。Alex的原话是，这两个模型四台机器根本跑不动。需要说明的是，视频里他测试的节点数只有4台和8台两档，中间的5到7台并没有实际验证，所以严格来说，能确认的是“四台容量不够、八台能跑起来”，还不足以证明八台就是运行这两个模型的最低门槛。

至顶AI实验室洞察

这场折腾能验证的东西，其实比标题看起来要窄一些。它没有证明"多机互联"本身有多大普适价值——从头到尾的数据都在说明，小模型上集群，通信开销吃掉了大半收益，四台变八台，提升往往只有一成左右，谈不上划算。它真正证明的是一件更具体的事：当模型大到单台设备装不下时，哪怕只是笨拙地堆机器、靠社区脚本硬连，也能把原本跑不了的东西跑起来，跑出的24 tokens/s、13.35 tokens/s不算快，但从"能不能跑"变成了"能跑多快"。

对想动手复刻的人，更值得记住的结论可能是：真正卡住进度的从来不是网线本身，而是链路两端的配置——交换机端口速率、虚拟接口拆分、jumbo frames、SSH网状这些细节，官方文档基本不会写，得靠社区方案和逐步排查去补。这也是为什么我们至顶AI实验室在做双机、三机互联时，花在网络调试上的时间，往往比跑分本身还多。