當萬億參數(shù)的多模態(tài)大模型成為一種常態(tài)，AI行業(yè)的“軍備競賽”早已轉向：不再只是卷模型參數(shù)、堆疊服務器，而是深入底層計算架構，開啟了一場“系統(tǒng)級對決”。

“超節(jié)點”由此成為計算產(chǎn)業(yè)的“新寵”。

截止到目前，國內(nèi)已經(jīng)有十多家企業(yè)推出了“超節(jié)點”，動作上卻出現(xiàn)了“變形”：似乎只要把幾十臺服務器塞進一個機柜，用光纖連接在一起，就能貼上“超節(jié)點”標簽，對外宣稱打破了摩爾定律。

在對比多款“超節(jié)點”的技術邏輯后，我們發(fā)現(xiàn)了一個殘酷的技術真相：倘若無法實現(xiàn)“內(nèi)存統(tǒng)一編址”，所謂的“超節(jié)點”多少有些“李鬼冒充李逵”的嫌疑，本質(zhì)上還是傳統(tǒng)服務器的堆疊架構。

01 為什么需要超節(jié)點？根源在于“通信墻”

讓我們先回到原點：為什么在互聯(lián)網(wǎng)時代用了二十多年的Scale Out集群架構，在大模型時代卻行不通了？

中國信通院在幾個月前發(fā)布的《超節(jié)點發(fā)展報告》中已經(jīng)給出了答案，將原因形象地歸納為“三堵墻”：

第一個是通信墻，在大模型訓練場景中，通信頻次隨模型層數(shù)和并行度呈指數(shù)級增長，微秒級的協(xié)議棧延遲在萬億次迭代中累積，將導致計算單元長時間處于等待狀態(tài)，直接限制算力利用率。

第二個是功耗與散熱墻，為了解決延遲和等待，工程師們不得不絞盡腦汁提升算力密度，盡可能在一個機柜里塞更多的計算單元，代價則是恐怖的散熱壓力和供電挑戰(zhàn)。

第三個是復雜度墻，“大力出奇跡”的硬件堆砌，讓集群規(guī)模從千卡推向萬卡乃至十萬卡，但運維復雜度同步提升。在大模型訓練過程中，每隔幾個小時就要處理一次故障。

擺在面前的現(xiàn)實挑戰(zhàn)是，大模型正從單模態(tài)走向全模態(tài)融合，上下文長度達到了兆級、訓練數(shù)據(jù)高達100TB、金融風控等場景的時延要求小于20毫秒……傳統(tǒng)計算架構已經(jīng)是肉眼可見的瓶頸。

想要滿足新的算力需求，打破“通信墻”注定是繞不過的一環(huán)。除了堆疊服務器，是否還有其他路徑呢？

先來梳理下產(chǎn)生“通信墻”的技術原理。

在傳統(tǒng)集群架構中，遵循的是“存算分離”與“節(jié)點互聯(lián)”原則，每一塊GPU都是一座孤島，擁有自己獨立的領地（HBM顯存），并且只聽得懂“本地話”，需要訪問隔壁服務器的數(shù)據(jù)時，必須走一套繁瑣的“外交程序”：

步驟一是數(shù)據(jù)搬移，發(fā)送端將數(shù)據(jù)從HBM拷貝到系統(tǒng)內(nèi)存；

步驟二是協(xié)議封裝，將數(shù)據(jù)切片封裝TCP/IP或RoCE報文頭。

步驟三是網(wǎng)絡傳輸，數(shù)據(jù)包經(jīng)過交換機路由至目標節(jié)點。

步驟四是解包與重組，接收端進行協(xié)議棧解析并剝離報文頭。

步驟五是數(shù)據(jù)寫入，數(shù)據(jù)最終寫入目標設備的內(nèi)存地址。

這個過程的學術名詞是“序列化-網(wǎng)絡傳輸-反序列化”，存在幾毫秒的延遲。在處理網(wǎng)頁請求時，這種延遲不會影響到用戶體驗。但在大模型訓練中，模型被切分成成千上萬塊，每一層神經(jīng)網(wǎng)絡的計算都需要在芯片間進行極高頻次的同步。就像做一道數(shù)學題時，每寫一個數(shù)字都要給隔壁同學打電話確認一下，解題效率可以說“慘不忍睹”。

業(yè)界針對性地提出了“超節(jié)點”的概念，并規(guī)定了三個硬性指標——大帶寬、低時延、內(nèi)存統(tǒng)一編址。

前兩個概念不難理解，簡單來說就是路修寬點（大帶寬），車跑快點（低時延），最核心、最難實現(xiàn)的恰恰是“內(nèi)存統(tǒng)一編址”：目標是構建一個全局唯一的虛擬地址空間，集群內(nèi)所有芯片的內(nèi)存資源被映射成一張巨大的地圖，不管數(shù)據(jù)是在自己的顯存里，還是在隔壁機柜的內(nèi)存里，對于計算單元來說，只是一個地址的區(qū)別。

同樣是做一道數(shù)學題時，不用給隔壁同學“打電話”，而是直接“伸手”拿數(shù)據(jù)。“序列化與反序列化”開銷被消除了，“通信墻”不復存在，算力利用率也就有了提升空間。

02 內(nèi)存統(tǒng)一編址難在哪？通信語義“代差”

既然“內(nèi)存統(tǒng)一編址”被證實是正確路徑，為什么市面上的某些“超節(jié)點”，依然停留在服務器堆疊？

不單單是工程能力的差距，還在于“通信語義”的代際差，涉及到通信協(xié)議、數(shù)據(jù)所有權和訪問方式。

目前有兩種主流的通信方式。

一種是面向分布式協(xié)作的消息語義，通常由發(fā)送和接收操作體現(xiàn)，工作方式像“寄快遞”。

假設要傳遞一本書，得先把書打包封箱（構建數(shù)據(jù)包）、填寫快遞單寫上對方的地址和電話（IP地址、端口）、叫快遞員送到物流中心（交換機）、對方收到快遞后拆箱拿出書（解包）、最后對方還得回復“收到了”（ACK確認）。

一套流程下來，即使快遞跑得再快（大帶寬），打包、拆包和中間流轉的時間（延遲和CPU開銷）也是省不掉的。

另一種是面向并行計算的內(nèi)存語義，通常由加載和存儲指令體現(xiàn)，工作方式像“從書架上拿書”。

同樣是傳遞一本書，直接走到公共書架旁，伸手拿下來（Load指令），并在看完后放回去（Store指令）。沒有打包，沒有填單子，沒有“中間商賺差價”，效率上的提升不言而喻。

諸如TCP/IP、InfiniBand、RoCE v2等支持消息語義，也是通信墻存在的直接誘因，但靈衢、NVLink等協(xié)議已經(jīng)支持內(nèi)存語義。既然如此，為什么“偽超節(jié)點”仍然做不到內(nèi)存統(tǒng)一編址呢？

因為內(nèi)存語義的皇冠明珠是“緩存一致性”：如果節(jié)點A修改了共享內(nèi)存地址0x1000的數(shù)據(jù)，而節(jié)點B的L2緩存中存有該地址的副本，必須確保節(jié)點B的副本立即失效或更新。

想要實現(xiàn)“內(nèi)存語義”，必須滿足兩個條件：

首先是通信協(xié)議和緩存一致性。

通信協(xié)議傳輸?shù)牟辉偈潜恐氐摹皵?shù)據(jù)包”，而是包含內(nèi)存地址、操作碼（讀/寫）和緩存狀態(tài)位的“Flit”。同時還需要緩存一致性協(xié)議，通過總線廣播一致性信號，確保所有計算單元看到的信息是相同的。

其次是充當“翻譯官”的交換芯片。

交換芯片扮演了“翻譯官”的角色，讓CPU、NPU/GPU等設備在統(tǒng)一的協(xié)議下互聯(lián)互通，整合為一個統(tǒng)一的全局地址空間，不管數(shù)據(jù)存在哪塊內(nèi)存里，都只有一個“全局地址”，CPU、NPU/GPU之間可以直接通過地址訪問。

無法滿足上述條件的“偽超節(jié)點”，大多采用的是PCIe+RoCE協(xié)議互聯(lián)方案，屬于典型的“大字吸睛、小字免責”。

RoCE跨服務器內(nèi)存訪問需要RDMA，不支持統(tǒng)一內(nèi)存語義、缺乏硬件級的緩存一致性，依然需要網(wǎng)卡、隊列、門鈴機制來觸發(fā)傳輸，本質(zhì)上還是在“寄快遞”，只是快遞員跑得快了一點。而PCIe的理論帶寬單lane為64GB/s，比超節(jié)點的帶寬要求低了一個數(shù)量級。

結果就是，以“超節(jié)點”的名義宣傳，卻不支持內(nèi)存統(tǒng)一編址，無法做到全局的內(nèi)存池化以及AI處理器之間的內(nèi)存語義訪問。集群只能實現(xiàn)“板卡級”的內(nèi)存共享（比如單機內(nèi)8張卡互通），一旦跨出了服務器節(jié)點，所有訪存都需要通過消息語義通信，在優(yōu)化上存在明顯瓶頸。

03 超節(jié)點有何價值？大模型的完美“搭子”

可能有不少人會問，費這么大勁搞“內(nèi)存統(tǒng)一編址”，到底有什么用，僅僅是為了技術上的“潔癖”嗎？

先說結論：內(nèi)存統(tǒng)一編址絕非“屠龍之技”，在大模型訓練和推理的實戰(zhàn)中，已經(jīng)被證實存在巨大收益。

第一個場景是模型訓練。

在訓練萬億參數(shù)的超大模型時，HBM容量往往是首要瓶頸。一張卡80GB顯存，塞進模型參數(shù)和中間狀態(tài)后，往往所剩無幾。

當顯存不夠時，傳統(tǒng)的做法是“Swap to CPU”——利用PCIe把數(shù)據(jù)搬到CPU的內(nèi)存里暫存。但存在一個大問題：PCIe的帶寬太低了，而且需要CPU參與拷貝。數(shù)據(jù)搬來搬去的時間，比GPU計算的時間還長，訓練速度大幅下降。

在真正的超節(jié)點架構下，CPU的內(nèi)存（DDR）和NPU的顯存（HBM）都在同一個地址空間里，可以采用“以存代算”的策略精細管理內(nèi)存：將暫時不用的數(shù)據(jù)或權重offload到CPU內(nèi)存上，需要的時候通過“大帶寬&低時延”的能力快速拉回片上內(nèi)存激活，NPU的利用率可以提升10%以上。

第二個場景是模型推理。

在多輪對話中，每輪對話都需要Put和Get，Put將KV數(shù)據(jù)存入內(nèi)存池，Get從內(nèi)存池取KV數(shù)據(jù)，需要更大的KV Cache空間進行頻繁的數(shù)據(jù)存儲。

傳統(tǒng)集群的KV Cache通常是綁定在單張卡的顯存上的，如果用戶問了一個超長的問題，節(jié)點A的顯存被KV Cache撐爆了，附近的節(jié)點B即使顯存空著，沒有內(nèi)存統(tǒng)一編址也無法借用，必須把任務重新調(diào)度、重新計算。

有了內(nèi)存統(tǒng)一編址，就可以實現(xiàn)KV Cache的全局池化，并支持Prefix Cache復用（前綴緩存）。比如“System Prompt”通常是固定的，只需要在全局內(nèi)存里存一份，所有節(jié)點都可以通過“一存多取”的方式直接讀取。在PreFix Cache命中率100%時，集群的吞吐性能可以提升3倍。

第三個場景是推薦系統(tǒng)。

搜索、廣告、推薦是互聯(lián)網(wǎng)的“搖錢樹”，依賴超大規(guī)模的Embedding表。由于Embedding表通常遠超單機內(nèi)存，必須分片存儲在不同服務器上。

在推理過程中，模型需要頻繁地從Host側（CPU內(nèi)存）或遠端Device側拉取特定的特征向量。如果是RoCE等“寄快遞”的方式處理小包，光是打包拆包的開銷就占了大頭，導致嚴重的門鈴效應，延遲居高不下。

而利用內(nèi)存統(tǒng)一編址，配合硬件級的內(nèi)存?zhèn)鬏斠�，計算單元可以直接向遠端內(nèi)存發(fā)起讀取指令，自動處理數(shù)據(jù)的搬運。當?shù)谝粋�向量還在路上時，第二個請求已經(jīng)發(fā)出了，極大地降低了通信延遲，提升端到端的推薦效率，有望實現(xiàn)最小化開銷。

不夸張地說，“大帶寬、低時延、內(nèi)存統(tǒng)一編址”三大能力相互協(xié)同，才能真正實現(xiàn)讓集群像一臺計算機一樣工作，才能實現(xiàn)真正的超節(jié)點，才是大模型訓練與推理的完美“搭子”，才是AGI時代算力基礎設施進化的必然方向。缺少“內(nèi)存統(tǒng)一編址”能力，終歸只是在蹭“超節(jié)點”的流量。

04 寫在最后

當我們拆開“超節(jié)點”的層層偽裝，可以看到AI基礎設施的競爭已經(jīng)從單純的堆砌硬件，上升到了體系結構的競爭。

“內(nèi)存統(tǒng)一編址”這個聽起來晦澀難懂的技術名詞，某種程度上等同于通往下一代計算范式的入場券：作為“One NPU/GPU”的必備能力，打破了物理服務器的圍墻，讓成千上萬顆芯片的“靈魂”融為一體。而那些仍然停留在“服務器暴力堆疊”的產(chǎn)品，終將被淹沒在摩爾定律失效的洪流中。