作者 | 劉侃

審校 | Kitty

前 言

RTP（Real Time Prediction） [1] 平臺是阿里內部一個通用的在線預測平臺，廣泛支持淘天、本地生活、AIDC、菜鳥、大文娛等搜索和推薦業務場景的 DLRM（Deep Learning Recommendation Model）部署。自 2022 年起，RTP 開始探索大規模 GPU-Disaggregation 技術的落地，運用 RDMA 高性能網絡通信構建 GPU-CPU 全分離的分布式推理系統。這項工作在今年被收錄至 NSDI25。借此機會，我想回顧并解讀當年的做的 Ranking 技術，也算是對過去兩年努力的一個交代。

DLRM 模型的特點

鑒于現在 LLM 很火，我們直接用表格對比一下兩者在線部署角度的差異，以便更好地理解問題。如果想了解更多 DLRM 的信息，可以參考原文，或典中典 W&D [2] 以及我們的系統介紹 [3]。

對應算力特點

DLRM 算法工程同學還是很苦逼的，每天被算法同學用槍指著要上線特征、優化模型。而算法工程同學不光要完成功能，滿足延遲需求，自己還要把成本優化下來。（大模型時代，部署工作確實好開展了一點，但更卷了）GPU 或者 CPU 上的優化不是本文討論的重點，假設優化 [4][5] 都做了，到部署環節，還會碰到什么問題？

每個模型資源規格不一樣，本來不是一個問題。反正做 AI 的人可以不懂 K8s，我就申請資源，那你就應該分配給我，CPU、MEM、GPU 在 yaml 里寫好就可以了。但一般來說，我們的機器配置 CPU、MEM 都是成比例的，以阿里云 ECS 機器規格為例，CPU：MEM 幾乎是嚴格的 1:4，對應的一臺物理機上實際硬件其實也是 1:4 的比例，這樣均勻的切才好賣。而如果一個模型的 CPU：MEM 需求比例不是 1:4 的話，或多或少存在浪費情況。

調度其實是在全局范圍解裝箱問題，想把 CPU 或 MEM 的坑填平是需要技巧的。

此時如果我們引入第三個資源維度 GPU。。。

Embedding 表或者 Feature 表太大，我們可以把它切分成多分，用分布式存儲的方式解決，這樣可以調和 CPU MEM 的比例；而 CPU 和 GPU 的比例怎么調和呢，怎樣充分利用好 CPU 和 GPU 呢？這就來到了本篇論文的主題。

DLRM 部署的挑戰

文章在 2.2 Challenges in DLRM Deployment 段給出了兩個 Challenge。

C1: Resource allocation in GPU clusters with high allocation rates.

剛才我們是從樂觀的角度看，調和好各個資源維度之后，資源分配更容易了。反過來想，如果比例不對會怎么樣呢？從單機看，會存在某些維度資源的浪費；從全局看，會出現資源剩余很多但無法分配的現象。每年我們從 1 月到 8 月都生活的很快樂，從 9 月開始備戰大促，大家就會把 K8s 小哥的頭按在鍵盤上擴容機器、騰挪資源。不是他不努力，多樣實例規格導致的碎片太嚴重了。

這是分配效率的問題。

C2: Resource provisioning during seasonal traffic spikes

seasonal 說的就是冬天的雙十一和雙十二，大家過不過節我不知道，反正我們是在公司過節的。如果每年如果只有這兩天很熱鬧的話，剩下 363 天的集群水位都是平淡無奇的，我們就為了 2 天的峰值資源多付了 363 天的錢，這是 100 倍的成本上升。而從日常的角度來看，淘天主要流量來自國內，必然存在著白天的流量高峰和晚上的流量低谷，睡覺的 8 小時機器資源也是空閑的。

削峰填谷是很自然的提升資源利用率的手段。填谷，就是找到那些時效性要求低的任務在低谷期運行就可以了；削峰，就是讓時效性低的任務讓出資源，跑在線時效性高的服務。如果我們討論的是搜推廣 AI 在線服務，在 GPU 上做削峰填谷，很自然地就可以想到用離線訓練任務來共同完成削峰填谷，讓資源在推理和訓練上復用。

傳統搜推廣稀疏 ps-worker 架構的訓練模型，資源需求跟在線服務類似，可以統一到幾種規格上去。而當大家逐漸轉向 dense 和大模型之后，情況發生了變化。現在是 8 卡 A100 無人問津、小紅書上 H200 跳樓甩賣的年代，我們要讓搜推廣模型推理去用高性能訓練卡。假設算法工程同學剛剛把實例規格調成了 32c128g 1xL20，這時候你說我們要用 8xH100 跑推理了，好像一個機架的 CPU 都不夠他用啊。大算力 GPU 讓單實例的計算資源比例調和更難了。

這是利用效率的問題。

總結一下

我們需要解決的幾個問題和路徑

1. 提升分配效率 -> 減少規格數量 ->資源比例歸一化

2. 提升利用效率 -> 削峰填谷 -> 訓推復用資源 -> 推理用大算力 GPU ->資源比例靈活化

DLRM Disaggregation

理想的困難

對于一個 AI 服務來說，我們應該讓他的CPU/MEM 的比例歸一化，讓他的CPU/GPU 比例靈活化。對應論文中 CN（CPU 節點）和 HN（異構計算節點）兩部分，CN 保持 CPU:MEM=1:4，CN:HN 做到任意的 n:m 靈活配比。從前我們有存算分離，現在我們可以發明算算分離！Disaggregation make ALI great again!

算算分離并不難，因為 RTP 系統已經是全圖化的，我們只要把 CPU 子圖和 GPU 子圖切開，分別跑到兩個容器實例，兩邊網絡通信就好了。這個概念很容易實現出來，但實際上我們還要考慮更多問題。

1. 在線服務多引入了一次網絡通信開銷，需要做到足夠低的延遲和錯誤率。

   1. 通信數據量和網絡帶寬分別是多少？

   2. 網絡上的距離多遠，這個固有延遲有多少？

不同場景的 CTR/CVR 模型推理端到端延遲在 20-40ms 左右，如果 DLRM 大量的 Feature 直接通過 TCP RPC 傳輸，幾乎會讓端到端延遲翻倍。這是我們不能接受的。

1. 訓練怎樣把資源釋放給推理，兩邊的約束是怎樣的？

   1. 推理的 GPU 部分 CPU 消耗夠小么，是不是能跑上去很多 GPU 推理 worker，充分利用好訓練單機多卡的算力？

   2. 推理能把訓練 GPU 用起來么？用的夠好么？

假設我們使用的 128c1024g 8GPU 4RNIC(200G) 的訓練節點，平均每個 GPU 可以使用 16c，這個約束要求 CPU 上只能運行控制流，不放做任何模型邏輯。平均每個 GPU 12.5Gbyte/s 的網絡帶寬，而之前 CPU-> GPU 我們使用 PCIE Gen4 有 32Gbyte/s，這個速率夠嗎？從集群角度看，傳統網絡架構下交換機有一定收斂比，網卡容量夠，交換機容量不一定夠。

現實的選擇

推理系統、調度系統、網絡基礎設施分別都要去各自解決一部分問題，4 Prism Design 段落講的很全面。這里主要從推理系統方面展開講講實踐上的選擇。

GPU 和 CPU 的子圖邊界的傳輸需要足夠小，以滿足延遲要求。我們的實現上選擇了傳輸 Feature Concat 后的結果。從傳輸角度上看這其實不是最優的。但在當時的情況下 GPU 上并沒有足夠的空間放 Embedding，而且 CPU 上我們有 Feature + Embedding 的 Fusion 優化，所以選擇了架構調整最簡單的方案。

搜推廣模型大多用不好 GPU，模型不是算力瓶頸的。所以在使用大卡的時候，我們考慮使用 MIG 來進一步提升利用效率，避免大馬拉小車的情況。

通信模型應該足夠簡單，簡化系統復雜度，減少出錯環節（畢竟之前 CPU 和 GPU 在一起的時候可不會出現網絡錯誤導致推理失敗）。最好是 CPU 節點只訪問一次 GPU 節點（GPU 節點是一個無循環依賴的完全獨立子圖）。而這個通信模型也有一定缺點，可能會導致延遲上升（可以仔細思考下為什么？）這個也是從簡化系統角度考慮做的設計選擇。

通信庫方面，雖然 TensorFlow 原生支持了 RDMA，但并不夠 serverless。我們期望能像 Grpc + istio 這樣的組合去用 RDMA。這里我們融合了 ACCL[6] 和 ARPC 這兩個庫，達到了“像普通 TCP 通信一樣用 RDMA”的效果。當然這里還有一些 trick，比如我們同時啟用 RDMA GDR 和 CudaGraph，顯存管理和 Graph 選擇就要求我們打穿整個系統去實現。

除了推理系統外，調度系統需要做到充分的拓撲感知，讓通信路徑足夠短；網絡架構方面，需要提供一個充分大能自由 RDMA 的網絡域。這里面需要每個層次在一起 co-design。如果網絡的設計是 pod 里混合 GPU/CPU 機型，調度會期望把一個推理服務的 CPU 和 GPU 節點都調度到一起，最小化推理延遲，但這樣的設計會導致訓練高帶寬區域范圍縮小；如果網絡的設計更傾向于訓練，跨 pod 做 RDMA 通信對網絡來說是不小的挑戰。這方面我不是專家，更多的信息可以參考 HPN[7] 。

插曲

當時整個系統開發測試聯調完，我感覺問題不大，很穩。大家上線把，下次周會可以不用叫我了。確實上線也很順利，繼續擴容吧。

結果雙十一壓測的時候網絡延遲異常飆高，所有人一臉懵逼。單機維度、交換機維度，各個指標拉出來大家看了幾天，沒什么眉目，日常狀態和單獨壓測都穩如狗。人都搖齊了，項目室里除了思路啥都有。

碰到這種 bug 只能連蒙帶猜，影響網絡通信的還有什么呢？RDMA 只有 RTP 一個進程在用，總不能是 TCP 跟他打架把，但 TCP 流量帶寬很低啊。于是我拿起壓測工具做了一些違背祖宗的操作。最終定論是打開 QoS 情況下 TCP PPS 較高時（其實也沒有很高）TCP 會嚴重影響 RDMA 通信。我們只能關閉 QoS，這個 BUG 報給網卡廠商確認了。

Cons

5.4 Prism at Scale: Production Deployment 這一節概述了整個系統生產化部署中獲得的收益。

CX6 網卡的成本可能是個問題。特別在傳統單機單卡的服務器上，可能插的不是 100G 網卡，還是上一代的千兆網卡，硬件條件上無法做 Disaggregation。而在歷史機器上插新卡難度近似登天。

如果是買 ECS 的老鐵，云服務商給你的不是一張完整的 CX6 網卡，帶寬上有問題。另外云廠商給的也不一定是商卡，是否支持 RDMA可能也是個問題。

如果要訓推復用的話，訓練和推理機器必須放在一個能 RDMA 的網絡域下。最開始機房規劃的時候沒有做這個打算，后面很難做調整；另外網絡規模是有上限的，在大模型時代，大家都是大卡，要怎樣做機房計算和網絡規劃呢？其實這不光是服務器基礎設施的問題，也是 AI 算法工程要理解的問題，只有聯合設計才能最終實現高效的異構計算資源使用。

我們進一步考慮聯合設計，如果這個集群的設計目標是支持大規模預訓練任務，那就不存在潮汐性質，自然也難跟推理復用。訓推一體的設計不適合大規模預訓練任務，除非可以接受只在某些“大促節點”短暫地停掉任務。如果這個集群的設計目標是支持混合型任務，這些任務或資源量有限的，或是周期性的，如大模型的 CT/SFT、中等規模多媒體模型的訓練、搜推廣稀疏模型 ODL、數據清洗打標等，這些都適合訓推一體的設計。

到更根本的問題上來，訓推一體整體資源利用率優化帶來的資源單價下降，是否能覆蓋集群設計的額外成本（網卡、交換機等）？或者更抽象意義地看，我們的所有工作投入（人力資源 + 物理資源）是否換來了正向的全局收益？我們不斷觀測，但始終難以量化。

另外，高密度計算的爆炸半徑也是個問題。一張 H100 壞了，可能代表原來 8 個單卡 A10 實例宕機；一臺訓練機器的內存 ECC 錯誤，就是原來 64 個 A10 實例要遷移；那一個機柜散熱有問題。。。

這是一般性問題和解法么?

一般來說，我們全盤接受論文的設定，就能按照論文的思路，逐步得到一個相似的結果。但是這個設定是否正確呢？對應論文提出的方法論是否通用呢？

如果是習慣使用云廠商 ECS 的廠子，可能已經早就已經被規格化蹂躪過了，在自己的業務特點下有一套成熟的適配方法論，努力湊，努力調和，并且可能會選擇浪費一些 CPU，力求達到最佳的 GPU 使用率。Disaggregation 是一個理想，但不是一個必然選擇。

如果你有自建機房、租用機房，以裸金屬方式用服務器的話，那就有很大機會通過 Disaggregation 來解決資源利用率的問題。但廠子需要有相當的資源體量，才值得把 Disaggregation 落地。不過這里退一步講，就算不做訓推一體，只在推理上做 Disaggregation，也能提升資源利用率。

那所有模型都要做 Disaggregation 么？Graph Compiler 并不能在所有情況下都做的足夠好，延遲可能不達標，甚至 Compile 不出來；而對于創新性的算法實驗來說，資源效率并不是一個問題。我們需要根據模型和場景，見仁見智。

到 LLM 的一點思考

從 Ranking 轉行大模型也兩年了，算算時間這似乎是一篇遺作 [在嗎]。在大模型上， Disaggregation 還在繼續，Prefill/Decode 分離早早就開始爛大街了。PD 分離這種 Disaggregation 的出發點跟 DLRM 并不一致，它追求 1. 降低 Prefill 對 Decode 階段的延遲影響，從而 2. 提高 Decode BatchSize 提升資源利用率，也就進一步 3. 提升吞吐降低成本。

從資源角度看，LLM PD Disaggregation 和 DLRM Disaggregation 的思路是一致的。DLRM Disaggregation 的出發點是資源規格統一，目標是提高 GPU 和 CPU 的利用率；而 LLM PD Disaggregation 的出發點是計算模式統一，目標是提高算力單元（TensorCore）和訪存（HBM）的利用率。

但兩者都存在一些硬傷。DLRM 中，GPU 肯定不能單獨使用，必須搭配一定 CPU 做控制流邏輯。這部分的 CPU 必須被優化的足夠少，我們才可能訓練機器上啟動足夠多的實例用滿 GPU。LLM PD Disaggregation 也類似，Prefill 雖然是算力瓶頸，但也要搭配一定的帶寬；Decode 雖然是訪存瓶頸，但肯定也要吃一些算力，這里的問題就比 DLRM 更復雜了。

Prefill 的 GPU 選型相對簡單，L20/H20 這兩個卡選，肯定用 L20 做 Prefill 而不是 H20。Decode 上我們應該怎樣選型呢？這個討論就比較復雜了，跟模型大小、模型結構都有關系。雖然我們內部已經大規模落地了 PD 分離系統，但在這方面我們的實踐經驗遠沒有當初在 DLRM 上豐富，等領悟更多了再來寫一篇文章扒一扒。

還有一個思路，既然 H20 卡在做具體任務的時候資源有冗余，那么我們是不是能夠在軟件或者硬件層面上將一張大卡切分為“算力卡”和“帶寬卡”，做單卡上 PD 分離。純粹 CUDA 軟件層面做顯然是不靠譜的，顯存在 HBM 上是打散分配的，不同任務有帶寬爭搶；硬件層面上，MIG 并不支持非均勻切分，這條路也并不可行。除非用一些高級的奇技淫巧。

結 語

其實 Disaggregation 還有一個好處，它自然地劃分出不同 workload ，幫助你有針對性地觀測、分析、優化。

其實 Disaggregation 還有一個好處，它減少了對訓練和推理機型的差異化要求。在極致狀態下我們只需要 CPU 和 GPU 兩種服務器機型，那機型設計、原料供應等等都歸一化了。不過現實沒有這么美好啦，十萬卡 H100 只在夢里，大家還是有啥能用就用啥吧 。

其實 Disaggregation 還有一個隱藏前提，就是通信資源是接近無限、或者是容易被編排組合的。當通信不夠用的時候，設想一下，引入 Disaggregation 反而讓資源分配難度升維了。但我們的通信真的是無限的么？

感謝論文各位作者，以及背后默默支持的同學們。也大家來關注我們校招和社招崗位：

• 機器學習系統工程師

• 阿里控股 - 大模型推理系統工程師 -LLM

• 阿里控股 - 算子及編譯優化工程師 -AI Infra

引用

[1] 深度預測平臺 RTP 介紹 https://developer.aliyun.com/article/674182

[2] Wide & Deep Learning for Recommender Systems https://arxiv.org/abs/1606.07792

[3]【AI.OS】深入解讀阿里開源系統全圖化引擎 https://blog.csdn.net/tianshuai1111/article/details/136275123

[4] 大規模深度學習預測場景下 codegen 的思考與應用 https://developer.aliyun.com/article/674175

[5] 推薦場景 GPU 優化的探索與實踐：CUDA Graph 與多流并行的比較與分析 https://zhuanlan.zhihu.com/p/715493347?utm_psn=1852498280795213824

[6] ACCL: Architecting Highly Scalable Distributed Training Systems With Highly Efficient Collective Communication Library https://ieeexplore.ieee.org/document/9462480

[7] Alibaba HPN: A Data Center Network for Large Language Model Training.https://ennanzhai.github.io/pub/sigcomm24-hpn.pdf

作者介紹

劉侃，2014 年加入阿里巴巴，經歷過 問天 搜索引擎開發，負責過 RankService/RTP 系統，在機器學習系統、編譯優化等方向有一定經驗。目前是阿里巴巴智能引擎大模型推理系統負責人。

會議推薦

在 AI 大模型重塑軟件開發的時代，我們如何把握變革？如何突破技術邊界？4 月 10-12 日，QCon 全球軟件開發大會· 北京站 邀你共赴 3 天沉浸式學習之約，跳出「技術繭房」，探索前沿科技的無限可能。

本次大會將匯聚頂尖技術專家、創新實踐者，共同探討多行業 AI 落地應用，分享一手實踐經驗，深度參與 DeepSeek 主題圓桌，洞見未來趨勢。