最近半年，"本地部署大模型"這件事明顯熱鬧起來了。討論的重點已經不再是有沒有一塊能打的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後來的整套集群搭建都建立在這套方案之上。
要把四台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同步到每台機器上。
八節點上，小模型的短板暴露得更明顯：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實驗室在做雙機、三機互聯時，花在網路調試上的時間，往往比跑分本身還多。
