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