1. 推理系統(tǒng)和訓(xùn)練系統(tǒng)的區(qū)別

最簡單的一句話是: 推理系統(tǒng)沒有所謂的DP并行. 背后隱藏的一個(gè)含義是兩個(gè)系統(tǒng)的Workload是完全不一樣的.

1.1 訓(xùn)練系統(tǒng)

到達(dá)速率和服務(wù)速率為確定性分布。

在訓(xùn)練系統(tǒng)中數(shù)據(jù)以Batch的方式到達(dá), 然后計(jì)算時(shí)間也相對(duì)確定, 一方面是因?yàn)閎ackward過程的同步需求, 另一方面是訓(xùn)練語料本身有長短的分布但也做了Padding, 當(dāng)然可以通過一些技術(shù)對(duì)Padding進(jìn)行優(yōu)化提升計(jì)算效率。

1.2 推理系統(tǒng)

到達(dá)速率假設(shè)為泊松分布, 服務(wù)速率受實(shí)現(xiàn)方式和服務(wù)策略影響。

推薦系統(tǒng)請求到達(dá)的分布假設(shè)是一個(gè)泊松分布, 另一方面input token和output token的分布則會(huì)帶來服務(wù)時(shí)間有一個(gè)特定的分布, 簡單的來看按泊松分布算, 或者有長尾的情況,例如Pareto分布.而Prefill-Decoder的方式也會(huì)影響這個(gè)分布, 因此在調(diào)度系統(tǒng)上該如何考慮是一個(gè)更值得深思的問題. 這些問題也是最近一段時(shí)間工作的一個(gè)方向。

1.3 推理系統(tǒng)SLO

對(duì)于不同的用戶而言(例如按照充值程度分金/銀/銅)SLO是不同的, 針對(duì)不同的SLO下的TTFT/TBT的整個(gè)推理系統(tǒng)的優(yōu)先級(jí)調(diào)度和延遲隱藏也有很多可以去做的事情. 另一個(gè)非常重要的工作是對(duì)用戶請求的服務(wù)時(shí)間的預(yù)測。

推理系統(tǒng)的請求和服務(wù)時(shí)間分布相對(duì)于訓(xùn)練系統(tǒng)更加有不確定性, 因此在各個(gè)子系統(tǒng)內(nèi)的調(diào)度編排和Locality的利用上以及時(shí)間/空間折中處理上有著巨大的創(chuàng)新空間.其實(shí)這也是Prefill-Decode/KV-Cache Centric Sched有收益的本質(zhì)原因。

接下來我們分別從軟件系統(tǒng)和硬件系統(tǒng)來談?wù)劇?/p>

2. 軟件架構(gòu)

從軟件架構(gòu)來看, 數(shù)據(jù)和控制平面的分離是一個(gè)非常經(jīng)典的設(shè)計(jì)模式。

2.1 控制面

控制平面主要負(fù)責(zé)一些用戶請求服務(wù)時(shí)間預(yù)測/調(diào)度/集群管理和高可靠/Cache及相關(guān)的分離式內(nèi)存池管理的任務(wù), 這些任務(wù)從架構(gòu)上來看應(yīng)該用通用的CPU進(jìn)行處理。

2.2 數(shù)據(jù)面

數(shù)據(jù)面主要是用于計(jì)算的Prefill Node和Decode Node以及一些彈性內(nèi)存池相關(guān)的數(shù)據(jù)搬移的工作. 從數(shù)據(jù)面來看, 其緩存結(jié)構(gòu)在推薦系統(tǒng)中已經(jīng)有很好的借鑒, 那就是HugeCTR一類的框架中的Hierarchical Parameter Server。

圖片

從Embedding Cache變成了需要在LLM處理KVCache, 但是相應(yīng)的軟件棧和結(jié)構(gòu)還是有區(qū)別的. Embedding TableLookup更多的是Hash Lookup ExatclyMatch. 而在LLM中KVCache的處理是一個(gè)Longest Prefix Match. 因此CPU Memory和SSD的軟件架構(gòu)還需要一些調(diào)整。

2.3 存儲(chǔ)設(shè)計(jì)和內(nèi)存緩沖池

當(dāng)然系統(tǒng)也會(huì)面臨DRAM不夠的問題需要落盤. 然后既要SSD容量大又要高I/O,同時(shí)還要考慮低成本和可運(yùn)維. 因此在SSD前面構(gòu)建一個(gè)分布式的彈性內(nèi)存池應(yīng)該是必須要做的了, 這里有一篇華為《MemServe: Context Caching for Disaggregated LLM Serving with Elastic Memory Pool》[2]。

圖片

另一個(gè)業(yè)務(wù)場景是DeepSeek會(huì)將用戶的上下文落盤到SSD中并保存24小時(shí). 那么相應(yīng)的軟件架構(gòu)應(yīng)該就很好構(gòu)建了。

我們可以通過Trie樹或者TreeBitMap的算法來構(gòu)建整個(gè)查詢樹。

當(dāng)訪問到一個(gè)葉子后, 即記錄該葉子對(duì)應(yīng)的KVCache所在的內(nèi)存的節(jié)點(diǎn)ID和指針并放入處理List, 以便以后進(jìn)行異步的DMA/RDMA. 這些在用戶請求到達(dá)后即可進(jìn)行異步執(zhí)行處理并在隊(duì)列適當(dāng)?shù)臅r(shí)候由調(diào)度器控制執(zhí)行相應(yīng)Prefill Node GPU VRAM的Prefetch。

Trie樹也可以根據(jù)input token做一些并行化的處理方式, 例如通過一致性Hash針對(duì)前幾個(gè)Token將workload分散到不同的CPU服務(wù)器上. 而這些服務(wù)器又可以構(gòu)建成一個(gè)很大規(guī)模的彈性內(nèi)存池。

對(duì)于彈性內(nèi)存層的Cache Evict可以按照LRU的方式進(jìn)行, 落盤的時(shí)候還需要考慮一些KVCache生命周期的問題. 落盤后也需要對(duì)Trie樹進(jìn)行更新將其相應(yīng)的葉子節(jié)點(diǎn)指針更新到指向某個(gè)文件的特定的塊。

談到落盤,可以借鑒類似于LSM的方式合并壓縮后落入磁盤, 并且還可以根據(jù)實(shí)際情況進(jìn)行冷溫?zé)岱謱? 因此對(duì)于存儲(chǔ)落盤到SSD的場景, 個(gè)人并不是很喜歡在GPU實(shí)例上的本地SSD, 損壞后維修帶來的業(yè)務(wù)影響還是有的, 另一方面可能還會(huì)帶來一些workload偏斜的影響, 因此可能更傾向于一種分布式并行存儲(chǔ)的方式。

當(dāng)然這里還有一個(gè)不同的地方是對(duì)于長時(shí)間沒有更新的block也需要定期的進(jìn)行GC, 例如按照DeepSeek保留24h的做法, 可以對(duì)超過24h的數(shù)據(jù)刪除并在Trie樹上剪枝更新。

3. 硬件架構(gòu)

3.1三網(wǎng)融合的推理系統(tǒng)

黃大年茶思屋最近也有一篇《英偉達(dá)、谷歌、Meta等5大巨頭Scale-up超節(jié)點(diǎn)規(guī)模大比拼，揭示未來AI網(wǎng)絡(luò)最優(yōu)解》[3]. 個(gè)人對(duì)這種不根據(jù)workload來談互聯(lián)的分析持懷疑態(tài)度, 但是有些結(jié)論是正確的. 其中最重要的一點(diǎn)就是“三網(wǎng)合一”即文章中的觀點(diǎn)。

當(dāng)前的AI網(wǎng)絡(luò)是三個(gè)獨(dú)立網(wǎng)：前端存儲(chǔ)網(wǎng)VPC（以太）、后端參數(shù)面（IB、RoCE2）和超節(jié)點(diǎn)（NVLink，HCCS）。三個(gè)網(wǎng)長期共存不合理的，一定會(huì)融合。

當(dāng)然這個(gè)問題在方博士的文章中也有提及:

現(xiàn)在分離式架構(gòu)都是用GPU訓(xùn)練集群做推理，節(jié)點(diǎn)內(nèi)NVLink互聯(lián)，節(jié)點(diǎn)間用IB或ROCE的RDMA互聯(lián)。這種配置分離式架構(gòu)完全是浪費(fèi)，好比李云龍攻打平安縣城，章明星稱之為富裕仗。

有幾個(gè)難題:

3.2 FrontEnd: CPU實(shí)例和GPU實(shí)例耦合

在這樣的一個(gè)推理系統(tǒng)中, NVL72-GB200是一個(gè)非常不錯(cuò)的方案, ScaleUP規(guī)模大, 而CPU又直接和GPU有C2C的帶寬, 這樣控制面和彈性內(nèi)存池的設(shè)計(jì)難度會(huì)小不少.另一個(gè)問題是泊松分布到達(dá)下GPU的調(diào)度的問題,這個(gè)涉及一些GPU本身SIMT硬件架構(gòu)的缺陷, 就不展開了。

而對(duì)于國內(nèi)非Grace-B/H的大概只能通過RDMA將彈性內(nèi)存池和GPU連接了, 因此需要VPC上跑超大規(guī)模RDMA并且完全商用的, 現(xiàn)階段全球能做的大概也就只有AWS SRD/Google Falcon和阿里云eRDMA. 而同時(shí)在這個(gè)網(wǎng)絡(luò)上又要兼顧Prefill Node之間的SP并行帶來的alltoall incast的影響, 對(duì)于其它很多客戶而言, 包括英偉達(dá)自己都是有很大挑戰(zhàn)的。

為什么需要呢, 從另一個(gè)角度來看,現(xiàn)在的Prefill/Decoder的轉(zhuǎn)移其實(shí)都是在8卡PCIe連接的同服務(wù)器的CPU上,然后再通過Messenger轉(zhuǎn)發(fā)到另一個(gè)Decoder實(shí)例, 并通過Async Load加載. 也就是說CPU的算力和內(nèi)存空間和GPU是綁定的, 外置的CPU服務(wù)器如果可以直接GDR訪問GPU顯存來做異步的調(diào)度和prefix lookup整個(gè)的性價(jià)比還應(yīng)該有所提升。

圖片

我們注意到Google Vertex AI很早就通過一些閑置的CPU實(shí)例和GPU混布來構(gòu)建, 并且通過CPU實(shí)例來做參數(shù)服務(wù)器,當(dāng)然還有一個(gè)是Cerebas的Swarm-X/Memory-X架構(gòu)。

圖片

另外Enfabrica也有一些機(jī)會(huì),難怪NV也投資了。

3.3 ScaleOut: Prefill-Decode M:N的部署

即章明星老師提到的異構(gòu)分離式架構(gòu), 需要在H800/A800和H20之間構(gòu)建很高的Bi-Section帶寬, 同時(shí)考慮到組網(wǎng)規(guī)模的問題還需要避免網(wǎng)絡(luò)上hash沖突帶來的利用率降低的問題。

3.4 ScaleUP: 是否還需要Load/Store ?

針對(duì)推理系統(tǒng)來看, ScaleUP主要用于TP/SP并行,例如模型規(guī)模大了或者算力無法滿足SLO時(shí)或負(fù)載均衡的考慮帶來的并行策略. 細(xì)粒度的Load/Store訪存似乎并不需要,因此Eth-X這樣的方案或許也就夠用了.當(dāng)然還有一些優(yōu)化方式,例如英偉達(dá)的GPS/PROACT/Fine-PACK的處理方式等.  當(dāng)然另一方面有現(xiàn)成的NVLink用用也挺好的. 等待UALink似乎又要考慮一些問題, 例如BRCM Altas4的single vendor供應(yīng)的問題和InfityFabric這些IP的成熟度, 當(dāng)前的國產(chǎn)GPU廠商可能面臨二選一的決策, 但是還是請先考慮是否還需要Load/Store over Scale-UP Link。

這個(gè)問題的答案取決于業(yè)務(wù)部署模式的考慮,成本的衡量,彈性的重要程度,是否訓(xùn)推一體,生態(tài)的兼容程度等. 未來多模態(tài)的業(yè)務(wù)場景也是一個(gè)變數(shù)。

3.5 彈性和成本視角

方博士也提到了一個(gè)問題Prefill和Decode Instance彈性擴(kuò)縮容。

因?yàn)镻refill和Decode各自子集群網(wǎng)絡(luò)互聯(lián)可以用以太網(wǎng)，沒準(zhǔn)也可以根據(jù)負(fù)載彈性擴(kuò)容Memory Pool和計(jì)算設(shè)備和存儲(chǔ)。

其實(shí)最終都是在成本上打算盤, 以后的服務(wù)就是按照Token印錢, 印刷機(jī)的成本, 推理流量的峰谷帶來的彈性供給, 都是值得考慮的問題。

當(dāng)然具體的方案就不展開寫了...幾年前就探索過的工作。

圖片

本質(zhì)的難題當(dāng)時(shí)也講清楚了,內(nèi)存的兩個(gè)墻。

圖片

這樣不就好了?

圖片

當(dāng)然還有一些隨路計(jì)算的東西,BRCM INCA/ NV SHARP也行, 網(wǎng)卡做Reduction/all-gather也行, 都是幾年前全做好的

圖片

參考資料

[1]LLM分離式推理可能帶來的軟硬件變革的迷思: https://zhuanlan.zhihu.com/p/707199343

[2]MemServe: Context Caching for Disaggregated LLM Serving with Elastic Memory Pool: https://arxiv.org/abs/2406.17565

[3]英偉達(dá)、谷歌、Meta等5大巨頭Scale-up超節(jié)點(diǎn)規(guī)模大比拼，揭示未來AI網(wǎng)絡(luò)最優(yōu)解: https://mp.weixin.qq.com/s/5Oq6H1VBd3G2CTGwXtjq8A