緊跟Kimi K2.6,推一篇有點腦洞的論文,來自月之暗面(Moonshot AI)和清華大學的最新聯合研究
一句話說清楚:這論文在搞什么?
把 Prefill(預填充)變成一種跨數據中心的云服務。
聽起來有點抽象?我換個說法:以前大模型推理的 Prefill 和 Decode 兩個階段必須待在同一個機房里,因為中間傳輸的 KVCache 太大了,跨機房根本搬不動
而這篇論文說,新一代混合注意力模型的 KVCache 縮小了十幾倍甚至幾十倍,我們可以把 Prefill 拆出去、放到另一個機房的高算力集群上跑,然后用普通以太網把 KVCache 傳回來做 Decode
這個架構叫做Prefill-as-a-Service(PrfaaS),實測吞吐量比同構 PD 部署高 54%,比樸素異構方案高 32%
![]()
地址 arxiv.org/abs/2604.15039 為什么要搞跨數據中心?
先說背景
PD 分離(Prefill-Decode Disaggregation)已經是大規模 LLM 推理的標準范式了
Moonshot AI 自家的 Mooncake 系統就是這個方向的先行者,后來跟 vLLM、SGLang、Dynamo 都做了深度合作,把 KVCache 當成 vip 來管理
PD 分離的原理很簡單:Prefill 是計算密集型的,Decode 是內存帶寬密集型的,兩者對硬件的需求完全不同
理論上,我們應該用算力強的芯片專門跑 Prefill,用帶寬大的芯片專門跑 Decode——這就是所謂的異構推理
但現實很骨感,問題出在 KVCache 傳輸上
下圖展示了傳統單集群 PD 推理(左)和 PrfaaS 跨數據中心推理(右)的對比:
![]()
傳統PD架構 vs PrfaaS架構
在傳統的 Dense Attention 模型里,一個 32K token 的請求,單個 MiniMax-M2.5 實例產生的 KVCache 傳輸速率高達約 60 Gbps。這什么概念?一臺機器的跨數據中心以太網帶寬都扛不住。所以 Prefill 和 Decode 必須共享同一個高帶寬 RDMA 網絡,被死死綁在同一個機房里
下圖展示了 MiniMax-M2.5 在不同輸入長度下的 KV 吞吐量,可以看到帶寬需求有多恐怖:
![]()
MiniMax-M2.5 KV吞吐量
這就導致了一個尷尬局面:你想搞異構推理?可以,但你得把不同類型的芯片塞進同一個 RDMA 集群里。這在運維上極其僵化——你連 Prefill 和 Decode 的硬件比例都沒法靈活調整
混合注意力模型改變了游戲規則
這篇論文指出了一個關鍵的轉折點:新一代的混合注意力架構,正在從根本上改變 KVCache 的大小
什么是混合注意力?簡單說就是在模型里只保留少量的全注意力層(Full Attention),大部分層用線性注意力(Linear Attention)或滑動窗口注意力(SWA)替代。這些層產生的 KVCache 大小是固定的,不會隨輸入長度線性增長
論文里列出了一組最新的混合注意力模型:
模型
架構比例
KV 吞吐量@32K
MiniMax-M2.5(Dense)
全 GQA
~60 Gbps
Qwen3-235B(Dense)
全 MLA
~33 Gbps
Qwen3.5-397B
3:1 線性:全注意力
~8 GbpsMiMo-V2-Flash
5:1 SWA:全注意力
~4.7 GbpsRing-2.5-1T
7:1 線性:全注意力
更低
看到了嗎?從 60 Gbps 直接降到 4.7 Gbps,降了 13 倍!Ring-2.5-1T 更是靠 MLA + 7:1 混合比例實現了約36 倍的 KV 內存節省。
這個數量級的變化意味著:KVCache 終于可以用普通以太網跨數據中心傳了。
但是!光靠模型架構還不夠
論文強調得很清楚:實際工作負載是突發的,請求長度嚴重不均,前綴緩存分布不平衡,跨集群帶寬還會波動。如果傻乎乎地把所有 Prefill 都扔到遠端集群,照樣會擁塞、排隊、利用率低下
模型讓跨數據中心傳輸變得"可能",但要讓它"實用",還需要系統層面的精心設計
PrfaaS 的核心設計
PrfaaS 的架構相當優雅,核心思想是 **"選擇性卸載"**——只把值得的請求送到遠端。
下圖是 PrfaaS-PD 的部署拓撲:
![]()
PrfaaS-PD 架構部署圖
整個系統分為三個子系統:
1. 計算子系統
PrfaaS 集群:高算力硬件(如 H200),專門處理長上下文 Prefill
本地 PD 集群:常規硬件(如 H20),負責短請求的 Prefill + 所有請求的 Decode
2. 網絡子系統
集群內部:RDMA 高帶寬互聯
集群之間:普通以太網(VPC 對等連接或專線)
3. 存儲子系統:混合前綴緩存池
這個設計很巧妙。混合注意力模型里有兩種不同的 KVCache:
線性注意力層的遞歸狀態:大小固定,只能精確匹配復用
全注意力層的 KVCache:隨長度線性增長,支持前綴部分匹配
PrfaaS 把這兩類 KVCache 分組管理,但共享底層的內存池。緩存塊分為兩類:前綴緩存塊(可跨請求復用)和傳輸緩存塊(傳完即丟)。全局 KVCache 管理器維護所有集群的緩存元數據,調度器據此決定請求路由。
關鍵調度策略:雙時間尺度調度
這是論文最硬核的部分。PrfaaS 的調度器分兩個層面運作:
短期調度:帶寬感知 + 緩存感知路由
設一個長度閾值t,請求的增量 Prefill 長度(去掉緩存命中的前綴后)超過t的,發到 PrfaaS 集群;不超過的,留在本地 PD 集群處理。
為什么這樣做?因為短請求的 Prefill 通常是內存瓶頸(不是計算瓶頸),送到高算力集群反而浪費;而且短請求的 KV 吞吐量相對更高,會更快吃滿跨集群帶寬。
調度器還會實時監控 PrfaaS 集群的出口鏈路利用率和隊列深度:
帶寬緊張時:各集群的前綴緩存獨立評估,盡量減少跨集群傳輸
帶寬充裕時:全局最優緩存匹配,甚至允許跨集群緩存遷移
長期調度:流量驅動的資源再分配
本地 PD 集群內的 Prefill/Decode 實例比例可以動態調整。當流量模式變化時,調度器會重新計算最優的Np/Nd比例和路由閾值t。
實驗結果:54% 吞吐量提升
論文用內部一個 1T 參數的混合架構模型(基于 Kimi Linear 架構,3:1 KDA:MLA 層比例)做了案例研究。
硬件配置:
PrfaaS 集群:32 個 H200 GPU(高算力,專跑長上下文 Prefill)
本地 PD 集群:64 個 H20 GPU(常規 PD 模式,800 Gbps RDMA)
跨集群帶寬:約 100 Gbps VPC 網絡
對比基線:96 個 H20 GPU 的同構 PD 集群
工作負載:
輸入長度:截斷對數正態分布,均值約 27K tokens,范圍 128~128K
輸出長度:固定 1024 tokens
SLO:40 tokens/s
下圖展示了最優參數搜索過程——找到最佳的 Prefill/Decode 分配比和路由閾值:
![]()
參數搜索過程
路由閾值搜索
最優配置:
路由閾值 t = 19.4K tokens
本地 PD 集群:3 個 Prefill 實例 + 5 個 Decode 實例
約 50% 的請求(長請求)被卸載到 PrfaaS 集群
核心結果:
指標
PrfaaS-PD
同構 PD
樸素異構 PD
吞吐量提升
基準
低 54%
低 32%
P90 TTFT
基準
高 64%
跨集群帶寬消耗
13 Gbps
不適用
更高
最讓我驚艷的數字:PrfaaS 集群的平均出口帶寬僅 13 Gbps,只占 100 Gbps 以太網鏈路的 13%。這說明混合注意力模型的 KVCache 跨數據中心傳輸不僅可行,而且還有巨大的余量!
而樸素異構方案(不做選擇性卸載,所有 Prefill 都扔到 H200)只提升了 16% 吞吐量,被 PrfaaS-PD 的 54% 遠遠甩在身后。這充分說明了調度策略的重要性——光有異構硬件不夠,得有聰明的調度。
對未來的影響
這篇論文背后的信號非常明確:
1. 模型架構正在重塑推理系統設計
Kimi Linear、Qwen3.5、MiMo-V2-Flash、Ring-2.5-1T……新一代模型幾乎都在走混合注意力路線。KVCache 的急劇縮小,讓跨數據中心推理從"不可能"變成了"值得優化"。
2. 硬件專用化趨勢加速
NVIDIA 的 Rubin CPX 專攻 Prefill 吞吐,Groq 的 LPU 專攻 Decode 帶寬,Taalas HC1 主打超高內存帶寬。PrfaaS 架構讓這些異構硬件可以各自獨立部署、獨立擴縮容,不用硬塞進同一個 RDMA 集群。
3. 大規模部署的成本優化空間巨大
論文指出,即使是萬卡級別的部署,PrfaaS 集群的跨數據中心帶寬需求也就在 Tbps 量級,現代數據中心完全能承載。這意味著企業可以在算力便宜的地方部署 Prefill 集群,在離用戶近的地方部署 Decode 集群。
總結
這篇論文的核心洞察其實很簡單:下一代模型的 KVCache 夠小了,小到可以跨數據中心傳輸了。但光"夠小"還不行,還需要選擇性卸載、帶寬感知調度、緩存感知路由這一套系統設計配合。模型架構和系統設計雙管齊下,才能讓跨數據中心的異構推理真正落地。
作為 Mooncake 的延續之作,這篇論文繼續體現了 Moonshot AI 在推理系統領域的深厚積累。而且論文明確提到了跟 vLLM、SGLang 的合作,說明這些想法很可能會逐步落地到開源推理框架中。
制作不易,如果這篇文章覺得對你有用,可否點個關注。給我個三連擊:點贊、轉發和在看。若可以再給我加個,謝謝你看我的文章,我們下篇再見!
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.