訂閱
糾錯
加入自媒體

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

圖片

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

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

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

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

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

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

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

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

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

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

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

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

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

圖片

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

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

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

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

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

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

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

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

圖片

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

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

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

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

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

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

圖片

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

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

一套流程下來,即使快遞跑得再快(大帶寬),打包、拆包和中間流轉(zhuǎn)的時間(延遲和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ù)牟辉偈潜恐氐?ldquo;數(shù)據(jù)包”,而是包含內(nèi)存地址、操作碼(讀/寫)和緩存狀態(tài)位的“Flit”。同時還需要緩存一致性協(xié)議,通過總線廣播一致性信號,確保所有計算單元看到的信息是相同的。

其次是充當(dāng)“翻譯官”的交換芯片。

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

圖片

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

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

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

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

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

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

第一個場景是模型訓(xùn)練。

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

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

圖片

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

第二個場景是模型推理。

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

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

圖片

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

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

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

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

圖片

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

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

04 寫在最后

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

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

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

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

發(fā)表評論

0條評論,0人參與

請輸入評論內(nèi)容...

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

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

暫無評論

暫無評論

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

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