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

“超節點”由此成為計算產業的“新寵”。

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

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

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

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

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

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

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

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

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

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

先來梳理下產生“通信墻”的技術原理。

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

步驟一是數據搬移，發送端將數據從HBM拷貝到系統內存；

步驟二是協議封裝，將數據切片封裝TCP/IP或RoCE報文頭。

步驟三是網絡傳輸，數據包經過交換機路由至目標節點。

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

步驟五是數據寫入，數據最終寫入目標設備的內存地址。

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

業界針對性地提出了“超節點”的概念，并規定了三個硬性指標——大帶寬、低時延、內存統一編址。

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

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

02 內存統一編址難在哪？通信語義“代差”

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

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

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

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

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

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

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

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

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

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

想要實現“內存語義”，必須滿足兩個條件：

首先是通信協議和緩存一致性。

通信協議傳輸的不再是笨重的“數據包”，而是包含內存地址、操作碼（讀/寫）和緩存狀態位的“Flit”。同時還需要緩存一致性協議，通過總線廣播一致性信號，確保所有計算單元看到的信息是相同的。

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

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

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

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

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

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

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

先說結論：內存統一編址絕非“屠龍之技”，在大模型訓練和推理的實戰中，已經被證實存在巨大收益。

第一個場景是模型訓練。

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

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

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

第二個場景是模型推理。

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

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

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

第三個場景是推薦系統。

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

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

而利用內存統一編址，配合硬件級的內存傳輸引擎，計算單元可以直接向遠端內存發起讀取指令，自動處理數據的搬運。當第一個向量還在路上時，第二個請求已經發出了，極大地降低了通信延遲，提升端到端的推薦效率，有望實現最小化開銷。

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

04 寫在最后

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

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