訂閱
糾錯
加入自媒體

拆開“超節(jié)點”的偽裝:沒有內存統(tǒng)一編址,仍是服務器堆疊

2026-02-02 16:17
Alter聊IT
關注

圖片

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

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

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

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

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

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

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

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

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

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

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

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

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

圖片

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

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

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

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

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

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

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

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

圖片

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

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

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

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

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

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

圖片

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

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

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

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

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

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

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

想要實現(xiàn)“內存語義”,必須滿足兩個條件:

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

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

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

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

圖片

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

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

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

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

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

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

第一個場景是模型訓練。

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

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

圖片

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

第二個場景是模型推理。

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

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

圖片

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

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

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

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

圖片

而利用內存統(tǒng)一編址,配合硬件級的內存?zhèn)鬏斠妫嬎銌卧梢灾苯酉蜻h端內存發(fā)起讀取指令,自動處理數(shù)據(jù)的搬運。當?shù)谝粋向量還在路上時,第二個請求已經發(fā)出了,極大地降低了通信延遲,提升端到端的推薦效率,有望實現(xiàn)最小化開銷。

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

04 寫在最后

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

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

       原文標題 : 拆開“超節(jié)點”的偽裝:沒有內存統(tǒng)一編址,仍是服務器堆疊

聲明: 本文由入駐維科號的作者撰寫,觀點僅代表作者本人,不代表OFweek立場。如有侵權或其他問題,請聯(lián)系舉報。

發(fā)表評論

0條評論,0人參與

請輸入評論內容...

請輸入評論/評論長度6~500個字

您提交的評論過于頻繁,請輸入驗證碼繼續(xù)

暫無評論

暫無評論

    人工智能 獵頭職位 更多
    掃碼關注公眾號
    OFweek人工智能網(wǎng)
    獲取更多精彩內容
    文章糾錯
    x
    *文字標題:
    *糾錯內容:
    聯(lián)系郵箱:
    *驗 證 碼:

    粵公網(wǎng)安備 44030502002758號