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

最簡(jiǎn)單的一句話是: 推理系統(tǒng)沒(méi)有所謂的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過(guò)程的同步需求, 另一方面是訓(xùn)練語(yǔ)料本身有長(zhǎng)短的分布但也做了Padding, 當(dāng)然可以通過(guò)一些技術(shù)對(duì)Padding進(jìn)行優(yōu)化提升計(jì)算效率。

1.2 推理系統(tǒng)

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

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

1.3 推理系統(tǒng)SLO

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

推理系統(tǒng)的請(qǐ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ì)原因。

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

2. 軟件架構(gòu)

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

2.1 控制面

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

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

數(shù)據(jù)面主要是用于計(jì)算的Prefill Node和Decode Node以及一些彈性內(nèi)存池相關(guān)的數(shù)據(jù)搬移的工作. 從數(shù)據(jù)面來(lái)看, 其緩存結(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不夠的問(wèn)題需要落盤. 然后既要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ù)場(chǎng)景是DeepSeek會(huì)將用戶的上下文落盤到SSD中并保存24小時(shí). 那么相應(yīng)的軟件架構(gòu)應(yīng)該就很好構(gòu)建了。

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

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

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

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

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

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

3. 硬件架構(gòu)

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

黃大年茶思屋最近也有一篇《英偉達(dá)、谷歌、Meta等5大巨頭Scale-up超節(jié)點(diǎn)規(guī)模大比拼，揭示未來(lái)AI網(wǎng)絡(luò)最優(yōu)解》[3]. 個(gè)人對(duì)這種不根據(jù)workload來(lái)談互聯(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)長(zhǎng)期共存不合理的，一定會(huì)融合。

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

現(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è)問(wèn)題是泊松分布到達(dá)下GPU的調(diào)度的問(wèn)題,這個(gè)涉及一些GPU本身SIMT硬件架構(gòu)的缺陷, 就不展開(kāi)了。

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

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

圖片

我們注意到Google Vertex AI很早就通過(guò)一些閑置的CPU實(shí)例和GPU混布來(lái)構(gòu)建, 并且通過(guò)CPU實(shí)例來(lái)做參數(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èn)題還需要避免網(wǎng)絡(luò)上hash沖突帶來(lái)的利用率降低的問(wèn)題。

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

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

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

3.5 彈性和成本視角

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

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

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

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

圖片

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

圖片

這樣不就好了?

圖片

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

圖片

參考資料

[1]LLM分離式推理可能帶來(lái)的軟硬件變革的迷思: 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ī)模大比拼，揭示未來(lái)AI網(wǎng)絡(luò)最優(yōu)解: https://mp.weixin.qq.com/s/5Oq6H1VBd3G2CTGwXtjq8A