去年我們組接到一個非?，F(xiàn)實的任務(wù)評估十萬億參數(shù)大模型的訓(xùn)練與推理到底怎么落地。一開始大家的思路特別樸素——卡不夠就加卡集群從幾百張擴到幾千張總行了吧。但真正把顯存賬、通信賬、時間賬一起攤到桌面上之后我發(fā)現(xiàn)事情遠(yuǎn)不是堆機器那么簡單。十萬億模型訓(xùn)推真正卡的不是某一個環(huán)節(jié)而是算力、存儲、通信三堵墻同時堵在面前而且它們還會互相放大。這篇文章想沿著這條線拆解三堵墻的成因再說說超節(jié)點架構(gòu)為什么被看作十萬億大模型訓(xùn)推的最優(yōu)解。全文不綁定某個具體廠商產(chǎn)品只談技術(shù)和實踐思路適合正在做大模型基礎(chǔ)設(shè)施選型、或者想搞清楚超節(jié)點到底解決了什么的同學(xué)參考。1. 十萬億參數(shù)不是一個更大號的問題三堵墻在賬本里是怎么出現(xiàn)的1.1 先算一筆顯存賬十萬億參數(shù)的物理體積有多大Scaling Law普及之后模型參數(shù)從1B、7B、70B一路漲到405B、1T現(xiàn)在全行業(yè)開始認(rèn)真討論10^13這個量級也就是我們常說的十萬億參數(shù)。很多人覺得十萬億不過是幾萬億的線性外推多買幾臺機器、多攢幾張卡就行。但先拿最樸素的BF16精度算一筆賬你馬上會發(fā)現(xiàn)事情不太對。十萬億參數(shù)的稠密模型光權(quán)重一項就需要10^13 × 2字節(jié) 20TB的存儲空間。訓(xùn)練過程中還要保存梯度跟權(quán)重同體積又是20TB加上AdamW優(yōu)化器通常要保存的一階動量、二階動量和主權(quán)重副本訓(xùn)練狀態(tài)往少了說也要60TB到100TB。當(dāng)前主流AI加速卡的單卡顯存大約在192GB這個量級——也就是說哪怕只放權(quán)重都要100張卡以上算上訓(xùn)練狀態(tài)和激活值500張卡以上的顯存池只是起步門檻。這個賬算完傳統(tǒng)的單機8卡加模型并行的套路基本失效。千億模型可以在一臺服務(wù)器里靠張量并行硬扛十萬億模型光靠往機柜里堆卡只會把通信墻越頂越高。我之前看到過一個項目組最初方案是直接下單兩千張卡后來讓運營的同學(xué)把顯存賬攤開算了算才發(fā)現(xiàn)光顯存容量這塊就已經(jīng)讓網(wǎng)絡(luò)和調(diào)度預(yù)算吃緊了。沒有先算賬就直接擴集群是不少團隊踩過的第一個坑。1.2 三堵墻互相放大的死循環(huán)為什么加機器反而更慢更麻煩的是算力、存儲、通信這三堵墻不是各自為政而是互相咬死。存儲墻逼你把模型切到更多卡上——顯存不夠只能多卡分片分片越細(xì)卡與卡之間要同步的數(shù)據(jù)量越大通信墻就越厚。通信墻變厚之后計算單元大量時間在等數(shù)據(jù)算力墻自然收緊。這就是為什么很多千卡集群跑大模型時實測算力利用率不到50%——不是芯片算力不夠是通信在拖后腿。這個死循環(huán)決定了十萬億大模型訓(xùn)推不能靠單純堆機器解。你加一個節(jié)點顯存是變多了但跨節(jié)點通信的開銷指數(shù)級上升尤其張量并行這種每個Transformer層都要做一兩次All-Reduce的高頻通信節(jié)點越多、距離越遠(yuǎn)、延遲越離譜最終人多不一定好辦事甚至因為協(xié)調(diào)成本過高變得更慢。所以真正要回答的問題是什么樣的架構(gòu)能把三堵墻一次性推倒而不是一面墻一面墻去鑿洞。2. 拆開三堵墻傳統(tǒng)集群在大模型訓(xùn)推中的三個真實瓶頸2.1 算力墻的真兇是等待不是計算很多人提算力墻第一反應(yīng)是單卡性能不夠。事實上當(dāng)前主流AI加速卡的理論算力已經(jīng)非常高單卡已經(jīng)不是最主要的天花板。真正的瓶頸在于集群規(guī)模變大之后計算單元的空轉(zhuǎn)比例急劇上升。在千卡集群上訓(xùn)練萬億級模型張量并行一旦跨服務(wù)器每個Batch要完成大量集合通信網(wǎng)絡(luò)時延哪怕只有幾百微秒乘上每個Batch內(nèi)的同步次數(shù)再乘上每天幾百萬步的累積等待時間就非常驚人了。我在一個中等規(guī)模集群上做過統(tǒng)計當(dāng)并行策略從單機切換到跨機后一個Transformer層的計算時間從大約200微秒漲到接近500微秒多出來的300微秒基本都在等通信。整個訓(xùn)練周期里這類等待反復(fù)疊加直接吃掉三成以上的算力。這也是為什么超節(jié)點要把物理距離壓縮到板卡之間——集合通信時延從網(wǎng)絡(luò)級變成芯片互聯(lián)級計算管線才有可能保持飽滿。說白了算力不是被用光的是被等掉的。2.2 存儲墻顯存容量的增長遠(yuǎn)遠(yuǎn)追不上參數(shù)規(guī)模存儲墻的根源非常直白模型參數(shù)的增長速度遠(yuǎn)超單卡顯存容量的增長速度。過去幾年AI加速卡的顯存從40GB、80GB一路漲到192GB已經(jīng)算是非?？斓牡俣瓤赡Ｐ蛥?shù)從千萬級躥到十萬億級中間差的倍數(shù)大得沒邊。一個像剪刀一樣張開的缺口導(dǎo)致模型越來越依賴分布式顯存而分布式帶來的通信代價又正好喂肥了通信墻。存儲墻其實還有第二個維度帶寬。顯存帶寬決定了計算單元能多快把數(shù)據(jù)吃到嘴里模型越大權(quán)重和中間激活的讀取量越大。如果單卡算力翻倍而顯存帶寬沒有同比例增長計算單元再強也會被數(shù)據(jù)供給卡住。我在實際調(diào)參時感受特別深小模型看不出來一旦模型到了億級參數(shù)顯存帶寬不足的癥狀非常明顯——算力曲線始終拉不滿每一輪都在等數(shù)據(jù)搬運。超節(jié)點之所以能緩解存儲墻不只是因為把顯存容量做大了更是因為把帶寬和容量的擴展方式從跨網(wǎng)絡(luò)變成了節(jié)點內(nèi)總線數(shù)據(jù)供給的延遲和抖動都小了一個量級。2.3 通信墻普通組網(wǎng)撐不起All-to-All的流量大模型訓(xùn)練里常見三類通信張量并行的All-Reduce屬于高頻小包通信MoE架構(gòu)中的All-to-All屬于中頻大流量通信數(shù)據(jù)并行的梯度同步屬于固定周期的全量同步。十萬億模型幾乎同時踩中這三類而且每類的流量都大得驚人。傳統(tǒng)數(shù)據(jù)中心組網(wǎng)是為通用互聯(lián)網(wǎng)流量設(shè)計的東西向、南北向都要照顧可大模型訓(xùn)練是極端的集中式場景——幾百GB甚至幾TB的數(shù)據(jù)要在幾百上千張卡之間同時交換。哪怕使用了高性能RDMA網(wǎng)絡(luò)跨節(jié)點通信的物理距離和交換跳數(shù)也擺在那里。網(wǎng)卡再快也改變不了數(shù)據(jù)要繞路、要排隊、要經(jīng)過多跳轉(zhuǎn)發(fā)的事實。所以通信墻最麻煩的地方在于物理限制光在光纖里跑一米就要5納秒跨機柜、跨機房繞上幾圈延遲就上來了。超節(jié)點做的事情非常本質(zhì)——把最需要高帶寬低延遲同步的那批卡物理上放進同一個框里從根上砍掉繞路這件事。3. 超節(jié)點的破局邏輯把最貴的通信距離壓縮到一張卡之間3.1 超節(jié)點到底改變了什么從服務(wù)器拼網(wǎng)絡(luò)到一張超級大卡超節(jié)點的核心思想是把幾十到幾百張AI加速卡通過極高帶寬、極低時延的私有互聯(lián)協(xié)議整合成一個邏輯上的超級大卡。對上層軟件來說它不再是一群需要靠網(wǎng)絡(luò)拼接的服務(wù)器而是一臺擁有超大顯存、超多計算核心的單一設(shè)備。這一步轉(zhuǎn)變直接改變的是整個系統(tǒng)的設(shè)計出發(fā)點。打個不太嚴(yán)謹(jǐn)?shù)菀桌斫獾谋确絺鹘y(tǒng)集群像一群獨立辦公室傳文件要靠走廊來來回回跑超節(jié)點把所有同事搬進同一個大開間面對面?zhèn)魑募呃染嚯x被壓縮到一臂之內(nèi)。關(guān)鍵不是多了一個房間而是最貴的通信成本被結(jié)構(gòu)性降下來了。我見過有團隊用一套幾百卡規(guī)模的超節(jié)點跑原本需要數(shù)千卡集群才敢碰的任務(wù)配合合理的并行策略收斂時間和穩(wěn)定性反而更優(yōu)。原因是TP、EP這類高頻通信被鎖在節(jié)點內(nèi)部走的是TB/s級的互聯(lián)帶寬而不是跨機房的常規(guī)網(wǎng)絡(luò)。通信短板一補原來的很多調(diào)度妥協(xié)和計算浪費也跟著消掉了。3.2 顯存池化與統(tǒng)一編址軟件視角下的一塊大顯存存儲墻的解法在超節(jié)點里具象化為顯存池化和統(tǒng)一編址。每張卡原本獨立的顯存在節(jié)點內(nèi)變成一個整體的、可被軟件靈活調(diào)度的池子。模型切分時你不再需要斤斤計較哪張卡多放了幾GB至少邏輯上編程模型面對的是一塊超大容量的顯存。對做模型并行的人來說這幾乎是夢寐以求的體驗——不用再摳摳搜搜地算每張卡的余量。這對推理尤其重要。十萬億模型權(quán)重在20TB往上放在超節(jié)點的顯存池里可以整份常駐推理時不用頻繁從外部存儲重新加載延遲和抖動都穩(wěn)很多。服務(wù)框架調(diào)度KV Cache也像調(diào)度普通顯存一樣順手相比傳統(tǒng)實例固定綁卡的方式寬松得多。不過統(tǒng)一編址不意味著免費跨卡訪問的帶寬、延遲依然存在軟件如果不感知物理拓?fù)湫阅苷諛哟蛘?。這也是為什么超節(jié)點方案總會綁定深度定制的編譯器、集合通信庫和調(diào)度器——軟硬件協(xié)同設(shè)計才是超節(jié)點真正能落地、能兌現(xiàn)性能的秘密。3.3 全互聯(lián)與集合通信的質(zhì)變從毫秒級到微秒級通信墻的打破靠的是節(jié)點內(nèi)全互聯(lián)帶來的高帶寬和超低延遲。相比普通集群跨節(jié)點集合通信動輒幾十微秒、上百微秒的耗時超節(jié)點內(nèi)部通常可以做到微秒級的消息延遲帶寬高出至少一個數(shù)量級而且所有卡都在同一個物理域里不需要經(jīng)過外部交換芯片中轉(zhuǎn)。這個數(shù)字差距直接決定了并行策略可以做多細(xì)。我做過一組很簡單的對照組測試傳統(tǒng)機架上做TP8的All-Reduce每次大概幾十微秒同樣的操作放到超節(jié)點內(nèi)部耗時降到個位數(shù)微秒。單看一次操作好像無所謂但每個Transformer層都要做一兩次十萬億模型訓(xùn)練一路積攢下來節(jié)省的總時間非?？捎^。通信墻被推倒之后算力墻的緊張感也會同步緩解——計算單元的空等變少了芯片真實利用率自然上去了。4. 訓(xùn)推一體的工程實踐并行策略、調(diào)度與擴展4.1 訓(xùn)練場景TP、PP、DP、EP各就各位超節(jié)點只是提供了一個更好的物理底座具體能不能跑滿還要看并行策略放得對不對。我的核心經(jīng)驗可以濃縮成十六個字高頻高帶寬留節(jié)點內(nèi)低頻低帶寬放節(jié)點間。千萬別把并行策略里的每一種手段都當(dāng)成可以隨意擺放的積木通信成本不同擺放位置必須對癥。舉個例子假設(shè)超節(jié)點內(nèi)有384張卡訓(xùn)練一個萬億級MoE模型一種比較合理的切法是TP8、EP64、PP6、DP128。TP8意味著同一組卡協(xié)作完成注意力層的張量切分EP64意味著各專家在64張卡之間做All-to-All這些都是高頻通信放在節(jié)點內(nèi)部最合適PP6把網(wǎng)絡(luò)層切成6段流水線傳輸放節(jié)點間氣泡用micro-batch填平DP128只做周期性的梯度全量同步放在節(jié)點間也夠用。如果把TP或EP錯誤地擴展到跨超節(jié)點通信立刻回到網(wǎng)絡(luò)級超節(jié)點等于白買。這一點在規(guī)劃集群時就要定死不能等到跑起來了再改。4.2 推理場景預(yù)填充、解碼與KV Cache的顯存博弈推理跟訓(xùn)練的資源需求是完全不同的。十萬億模型推理權(quán)重加載是首要矛盾——模型被分散在多臺機器上每次請求都要做跨機張量并行節(jié)點間通信用一次疼一次。超節(jié)點的價值在于讓整份權(quán)重常駐顯存池預(yù)填充階段單個請求可以同時利用幾百張卡的并行算力把首Token時延壓到很低。對在線推理業(yè)務(wù)來說首Token時延直接關(guān)系到用戶體驗這一點上超節(jié)點的高帶寬起了大作用。解碼階段則要應(yīng)對KV Cache的膨脹。自回歸解碼每一步計算量不大但延遲敏感并發(fā)請求一多KV Cache的顯存占用飛速上漲。超節(jié)點的顯存池在這里立了大功可以大方地給每個并發(fā)請求分配足量KV Cache空間同時用節(jié)點內(nèi)低延遲互聯(lián)加速解碼。而且預(yù)填充和解碼的計算特征不同訓(xùn)練時的并行配置不能直接照搬。我習(xí)慣的做法是預(yù)填充階段用大TP解碼階段換小TP、提高數(shù)據(jù)并行度靠動態(tài)資源調(diào)整讓同一套硬件在不重啟服務(wù)的情況下平滑切換。這套方式在傳統(tǒng)集群上做會束手束腳在超節(jié)點上則從容很多。4.3 從單超節(jié)點到多超節(jié)點節(jié)點間通信怎么降級十萬億模型的需求大概率會超過單個超節(jié)點能承載的規(guī)模實際落地時多個超節(jié)點組成更大集群是常態(tài)。核心原則還是那句把通信最密集的計算鎖在單超節(jié)點內(nèi)部節(jié)點間只承擔(dān)中低頻通信。用一張表來對比節(jié)點內(nèi)和節(jié)點間的差異會更直觀對比維度超節(jié)點內(nèi)部超節(jié)點之間通信帶寬TB/s級別數(shù)百Gb/s級別典型時延微秒級幾十微秒級主要承擔(dān)通信TP、EP等高頻同步DP梯度全局同步、PP流水傳輸集合通信開銷極低可近似忽略必須控制頻次和消息量兩者差著一個數(shù)量級因此做分布式切分時模型并行度最好不超過單超節(jié)點能夠承載的卡數(shù)。只要主通信路徑不出節(jié)點擴展到幾倍規(guī)模時吞吐效率依然可以維持得很漂亮。萬一貪心把TP擴展到跨超節(jié)點性能大概率斷崖式下跌。這條經(jīng)驗對任何要建大模型集群的團隊都很有參考價值別拿生產(chǎn)集群去試錯。5. 把超節(jié)點搬進機房的真實坎可靠性、軟件棧與成本5.1 故障域變大了單卡故障不再是小事件超節(jié)點把很多卡綁成一個邏輯大卡好處集中風(fēng)險也集中。普通集群一塊卡壞了影響的是一臺8卡服務(wù)器里的一部分負(fù)載換卡方便超節(jié)點里一塊卡亞健康可能拖累整組卡的集合通信故障域從單個節(jié)點直接擴散到整個超級節(jié)點。這一點如果不提前想清楚上線之后會非常被動。應(yīng)對思路有三條一是實時亞健康檢測任何卡在集合通信中出現(xiàn)一次延遲異常立即標(biāo)記并隔離不要等它反復(fù)出問題二是更細(xì)粒度的即時檢查點讓故障后的恢復(fù)只回放到最近的安全點避免大范圍重算三是在拓?fù)渖项A(yù)留冗余路徑關(guān)鍵位置能快速切換。我們團隊在超節(jié)點上踩過幾次坑之后形成了先檢測后調(diào)度的固定紀(jì)律——寧可臨時降一點規(guī)模也不讓有問題的卡攪亂整個通信域。穩(wěn)定性的優(yōu)先級在超節(jié)點場景里比普通集群高得多。5.2 軟件棧要重新對齊并行庫、編譯器、調(diào)度器都得跟手硬件架構(gòu)變了最費勁的不是遷移環(huán)境而是整套軟件棧。傳統(tǒng)MPI式集合通信庫是為服務(wù)器間網(wǎng)絡(luò)優(yōu)化的直接搬到超節(jié)點不一定發(fā)揮得出極限性能。要跑滿節(jié)點內(nèi)的高帶寬需要重新設(shè)計通信拓?fù)洹?yōu)化遠(yuǎn)端內(nèi)存訪問路徑甚至重新編譯算子讓底層代碼感知到所有卡都在同一個框里。這不是換個驅(qū)動版本就能解決的問題。很多團隊低估了這個工作量。我見過某項目組把舊集群的訓(xùn)練腳本原樣搬到超節(jié)點上性能反而比原來還低因為舊代碼大量面向遠(yuǎn)端網(wǎng)絡(luò)優(yōu)化根本走不上新的高帶寬低延遲路徑。反過來只要把集合通信庫優(yōu)先調(diào)度到節(jié)點內(nèi)互聯(lián)再針對超節(jié)點拓?fù)渥鏊阕尤诤虾惋@存布局優(yōu)化性能差距很快就會拉開。所以選擇超節(jié)點方案時千萬別忽略軟件適配這部分人力和時間預(yù)算它不是可選項是必選項。5.3 成本賬與選型建議什么時候超節(jié)點方案真正劃算最后說點現(xiàn)實問題錢。超節(jié)點的高帶寬互聯(lián)、大顯存池、一體化機柜硬件成本明顯高于普通集群。但省下來的東西也很明確訓(xùn)練時間、通信等待、運維成本和調(diào)優(yōu)成本。如果團隊天天在跟通信瓶頸斗智斗勇超節(jié)點的隱性回報可能早就覆蓋了硬件差價。我在評估方案時習(xí)慣算單位Token的訓(xùn)推成本而不是看單卡價格。單卡便宜但整體效率低最后總賬未必好看。個人建議如果訓(xùn)練的模型超過千億級別且有訓(xùn)推一體的長期需求超節(jié)點方向非常值得認(rèn)真評估如果只是幾十億參數(shù)的常規(guī)模型或者業(yè)務(wù)場景比較單純傳統(tǒng)集群在成本上依然有優(yōu)勢。另外要留意選型不是拍腦袋決定至少拿一兩個真實模型在小規(guī)模超節(jié)點上做基準(zhǔn)測試再把結(jié)果外推到目標(biāo)規(guī)模比任何廠商白皮書都靠譜。做了這么久超節(jié)點相關(guān)實踐我最大的體會是十萬億大模型訓(xùn)推的最優(yōu)解不是某一個硬件詞匯而是整個系統(tǒng)設(shè)計思路的轉(zhuǎn)變——從用網(wǎng)絡(luò)拼服務(wù)器轉(zhuǎn)向用互聯(lián)造超級大卡。硬件把三堵墻的物理距離壓短了剩下的路還得靠我們自己走并行策略、調(diào)度策略、容錯設(shè)計都要重新對齊到新架構(gòu)上。這條路沒有捷徑但一旦走通性價比遠(yuǎn)不是傳統(tǒng)堆卡路線能比的。如果各位也在做類似的選型決策歡迎帶著具體場景來聊——很多坎兒真的只有踩過才知道深淺。