機器之心編輯部
「DeepSeek V4 來了論文！」這樣的訊息是不是已經聽煩了？
我們也是論文。
不過 DeepSeek V4 雖然遲遲未發，但今天我們等來了其與清華、北大合作撰寫的一篇新論文論文。
總結來說，這篇新論文介紹了一個名為「DualPath」的創新推理系統，專門針對智慧體工作負載下的大語言模型（LLM）推理效能進行最佳化論文。具體來講，透過引入「雙路徑 KV-Cache 載入」機制，解決了在預填充 - 解碼（PD）分離架構下，KV-Cache 讀取負載不平衡的問題。
該推理系統帶來了顯著效果：在離線推理場景中實現了 1.87 倍的吞吐量提升，線上服務場景下實現了 1.96 倍的服務吞吐量提升論文。
論文標題：DualPath: Breaking the Storage Bandwidth Bottleneck in Agentic LLM Inference
arXiv 地址論文：
我們知道，如今智慧體已經成為主流 AI 開發正規化論文。但是，智慧體正規化下出現了全新的瓶頸，即儲存頻寬。
展開全文
在多輪互動的智慧體場景中，上下文資訊會隨輪次迅速累積，導致其呈現出 「長上下文、短追加」 的特徵論文。研究指出，這類負載的 KV-Cache 命中率通常高於 95%。這意味著系統效能的決定性因素已不再是純粹的計算能力，而是從儲存中載入 KV-Cache 的效率。
在現有的預填充 - 解碼分離（PD-disaggregated）架構中，所有的儲存 I/O 壓力都集中在預填充引擎（PE）的儲存網絡卡上，而解碼引擎（DE）的儲存頻寬則被閒置論文。這種頻寬利用的極度不平衡，成為了限制系統吞吐量的核心障礙。
針對這一痛點論文，DualPath 重新設計了資料載入路徑，核心創新在於引入了儲存到解碼（Storage-to-Decode）路徑，包括以下兩個特徵：
一方面是雙路並行論文。KV-Cache 不僅可以直接讀入預填充引擎，還可以先載入到解碼引擎，隨後透過高頻寬 RDMA 計算網路高效傳輸至預填充引擎。
另一方面是頻寬資源池化：透過動態分配兩條路徑的負載，DualPath 成功將叢集中所有引擎的儲存網絡卡聚合為一個 全域性容量池，徹底打破了單節點 I/O 的限制論文。
另外，為了確保大規模資料傳輸不干擾延遲極其敏感型的模型推理任務，DualPath 還採用了以下兩項關鍵技術：
一是以計算網絡卡（CNIC）為中心的流量管理：系統將所有 GPU 相關的流量（包括本地記憶體複製）統一透過計算網絡卡進行管理，同時利用網路的服務質量（QoS）機制，將推理通訊設為高優先順序，確保載入 KV-Cache 的流量僅利用閒置頻寬，不影響延遲 SLO論文。
二是自適應請求排程：排程器即時監控各引擎的磁碟讀取佇列長度和計算負載，動態決定每個請求的最優路徑論文。同時，透過計算配額機制最佳化引擎內排程，最大限度減少 GPU 執行過程中的氣泡。
研究團隊在包含 1152 個 GPU 的大規模生產叢集上對 DualPath 進行了評估，並驗證了離線與線上服務場景下吞吐量的顯著提升論文。
接下來解析 DualPath 系統細節論文。
DualPath 系統概覽
為了打破 Prefill 側儲存 I/O 的瓶頸，DeepSeek 提出了一種雙路徑載入架構，重新設計了在 Prefill–Decode 解耦（PD-disaggregated）推理架構中 KV-Cache 的讀取方式論文。傳統做法是所有 KV-Cache 都從儲存直接讀入 Prefill 側 GPU，導致 Prefill 側儲存網絡卡成為單點瓶頸。DualPath 則在此基礎上增加了一條新的載入路徑，從而緩解這一不平衡問題。
DualPath 仍然建立在兩項已有技術之上論文：
（1）P/D 解耦（PD Disaggregation）論文，將 prompt 處理與 decode 處理分離，以提高整體效率；
（2）Layerwise Prefill，透過按層載入 KV-Cache，避免了 LayerKV 和 PrefillOnly 指出的 Prefill 引擎上的 HBM 視訊記憶體瓶頸問題，從而提升 GPU 利用率論文。
DualPath 整個系統由三部分組成論文：
推理引擎（Inference Engines）論文。每個引擎管理一張 GPU。引擎分為兩類：用於執行 prefill 的 Prefill Engine（PE），以及用於執行 decode 的 Decode Engine（DE）。
流量管理器（Traffic Manager）論文。每個引擎內部都包含一個流量管理器，負責：（1）主機與裝置之間的記憶體複製（H2D 與 D2H）；（2）PE 與 DE 之間的 KV-Cache 傳輸；（3）透過儲存網絡卡進行 KV-Cache 的讀寫操作。DeepSeek 採用以 CNIC 為中心的流量管理方案，以防止 KV-Cache 相關流量干擾模型推理過程中的通訊。
請求排程器（Request Scheduler）論文。一箇中心化排程器，負責接收客戶端請求並將其分配到不同引擎。同時，它還負責在兩條載入路徑之間動態分配資料流量（如圖 4 所示）。
雙路徑載入（Dual-Path Loading）
傳統系統中，KV-Cache 只能從儲存直接讀入 Prefill 引擎，因此所有儲存頻寬壓力都集中在 Prefill 側，形成單點瓶頸論文。DualPath 在此基礎上增加了一條新的載入路徑：KV-Cache 可以先從儲存讀入 Decode 引擎，再透過高速 RDMA 計算網路傳回 Prefill 引擎。這樣，系統就可以同時利用 Prefill 和 Decode 兩側的儲存網絡卡頻寬，而不是隻依賴 Prefill 一側，從而消除頻寬不均衡問題。
為了實現雙路徑載入，DualPath 在每個 Prefill Engine（PE）和 Decode Engine（DE）上分配少量 DRAM 作為緩衝區，分別稱為 PE buffer 和 DE buffer論文。
Prefill 側讀取路徑論文。首先，將命中 token 的 KV-Cache 從持久化儲存中讀取到 PE buffer（如圖 4a 中標註 1 和 2）。在某一注意力層開始計算之前，該層對應的 KV-Cache 會從 PE buffer 傳輸到 PE 的 HBM（3 和 4），用於計算未命中（cache-miss）的 prompt token 的 KV-Cache。隨後，命中和未命中 token 的所有 KV-Cache 都會被傳輸到 DE buffer，以組成完整的 prompt KV-Cache（ 5–7）。步驟 3–7 的流程會重複 n_layer 次。在 prefill 前向計算過程中，資料傳輸與計算是重疊執行的。
預填充 DE 讀取路徑論文。首先，命中 token 的 KV-Caches 會被讀取到 DE 緩衝區中（如圖 4b 中的標籤 1 和 2 ）。在 PE 預填充期間，相應層的 KV-Cache 會從 DE 緩衝區中讀取，這同樣與計算過程相重疊（ 3-5）。此過程會重複 n_layer 次。當每一層的計算完成後，只有缺失 token 的 KV-Caches 會被傳輸到 DE 緩衝區，並與現有的命中 token KV-Cache 進行合併。
解碼階段論文。在 DE 緩衝區接收到完整的提示 KV-Cache（包括透過 PE 讀取路徑載入的 KV-Cache 以及新追加 token 的 KV-Cache）後，解碼階段正式開始。DE 首先分配 HBM 並執行主機到裝置（H2D）傳輸（如圖 4a 中的標籤 8 和 9；圖 4b 中的標籤 6 和 7 ），隨後在開始解碼前釋放 CPU 記憶體。
DE 緩衝區的設計雖然給 DRAM 和 CNIC 帶來了額外的頻寬壓力（因為增加了一次額外的 H2D 複製），這本可以透過 GPU Direct RDMA 直接繞過來避免論文。然而，由於在此類智慧體場景下生成的長度通常較短，首 token 延遲在整個端到端請求時間中佔據了不可忽視的比例。引入 DE 緩衝區有助於減少 GPU 記憶體佔用。在解碼過程中，每當累積一個完整的 token 塊（例如 64 個 token）時，系統會立即將其持久化到磁碟中。
不同的資料塊佈局論文。DualPath 採用了兩種不同的資料塊佈局：完整塊和層級塊，它們分別包含所有層的資訊和單個層的資訊。對於所有與儲存系統的互動，均採用完整塊。在 PE 讀取的情況下，KV-Cache 載入到 PE HBM 以及傳輸到 DE 緩衝區的過程是以層級流式方式進行的，兩者都使用層級塊。同樣地，對於 DE 讀取路徑，從 DE 緩衝區到 PE HBM 的傳輸也使用層級塊。
無瓶頸（Bottleneck-Free）分析
比例（預填充 / 解碼比例）下證明了，該系統可以完全打滿所有儲存網絡卡（NIC）的頻寬，且不會引入計算網絡卡或 DRAM 的瓶頸論文。
假設 PCIe 拓撲配置良好（即每一對 GPU - NIC 都位於同一個 PCIe 交換機下）、任務排程負載均衡、計算網路無擁塞，且儲存讀取頻寬得到了充分利用論文。
首先是 PE CNIC 頻寬分析論文。對於 PE CNIC，由於存在迴環流量（即不經過交換機的 H2D 和 D2H 複製），因此無論讀或寫操作，PCIe 側的總流量始終大於或等於交換機方向的流量。因此，只需要計算 PCIe 側的壓力。讀取操作包括 PE 路徑 (3) 和 (5)，其在所有配對上的總流量為：
其次是 DRAM 壓力分析論文。DRAM 是半雙工的，因此將讀取和寫入壓力相加。對於 PE 記憶體，其壓力為 2sB，這通常不會超過記憶體頻寬。對於 DE 記憶體，遵循上述類似的分析，可以得出其壓力為 (3 + 2P / D) Bs。要求 DE 記憶體壓力小於或等於 M，得到如下：
更多公式請參考原論文論文。
實際挑戰
雙路徑架構從根本上重新定向了資料移動方式：KV-Cache 既可以直接從儲存載入到預填充引擎，也可以透過解碼引擎間接載入 論文。透過這種方式，系統聚合了所有引擎的儲存頻寬，從而打破了預填充側的 I/O 瓶頸 。然而，在實際系統中實現這一高層設計引入了三個相互關聯的挑戰 。
一是細粒度資料傳輸論文。層級執行正規化雖然對於克服 HBM 容量限制至關重要，但它會將 KV-Cache 碎片化為海量的細粒度資料塊。為了實現吞吐量增益，在儲存、主機 DRAM 和 GPU HBM 之間傳輸這些海量的細粒度資料塊時，必須確保產生極低的開銷，並與計算任務無縫重疊。
二是流量隔離論文。DualPath 中複雜的資料路徑在計算網路和 PCIe 鏈路上都引入了額外的 KV-Cache 傳輸流量。一個主要的顧慮是，這些流量可能會干擾模型執行中至關重要的、對延遲敏感的現有集合通訊操作 —— 例如專家並行中的 AllToAll，以及張量 / 上下文並行中的 ReduceScatter 和 AllGather。由於這些集合通訊直接決定了端到端的推理延遲，因此在不降低模型推理效能的前提下利用空閒 I/O 頻寬是一個關鍵挑戰。
三是動態負載均衡論文。由於採用了兩種不同的 KV-Cache 載入路徑，系統必須及時決定每個請求使用哪條路徑。過於簡單的策略可能會導致某條路徑過載，從而重新產生原始瓶頸。流量排程器必須即時平衡多個因素：儲存網絡卡佇列長度、GPU 上的計算負載以及請求的工作負載特性。
評估結果
在評估部分，論文核心任務只有一個：證明 DualPath 在真實 agent 工作負載下，確實能解決儲存頻寬瓶頸，並帶來穩定、可擴充套件的效能提升論文。
論文在自研推理框架上實現 DualPath，核心改動約 5000 行程式碼論文。底層使用 FlashMLA、DeepGEMM、DeepEP 等高效能運算元，儲存後端採用 3FS 分散式儲存。
評測模型包括：DS 660B（MoE + 稀疏注意力）、DS 27B（縮小版實驗模型），Qwen 32B（稠密模型）論文。
離線批次推理
這一部分模擬 RL rollout 場景：n 個 agent 同時啟動，測整體完成時間（JCT）論文。
不同 Agent 批次規模與最大 Agent 長度（MAL）的影響論文。 隨著批次規模增大以及 MAL 變長，DualPath 的優勢更加明顯。圖 7 展示了在不同 batch size 與 MAL 組合下的 JCT 表現。SGL (MC) 出現錯誤，未能完成部分大規模配置（圖中 token 為 N/A）。在 DS 660B 模型上，DualPath 相比 Basic 最高實現了 1.87× 的加速，並展現出接近 Oracle 的效能，這表明 KV-cache 的 I/O 開銷基本被消除。在 DS 27B 上，DualPath 相比 Basic 最高提升 1.78×，但由於 1P1D 架構下儲存頻寬受限，其效能仍比 Oracle 慢 1.09–1.85×（見圖 8）。對於 Qwen 32B，趨勢與 DS 27B 類似。
不同追加長度（Append Length）與生成長度（Generation Length）的影響論文。如圖 9 所示，隨著追加長度增加，Basic 的效能逐漸接近 DualPath 和 Oracle，而 DualPath 與 Oracle 的效能變化較小，這表明系統瓶頸始終主要來自 GPU 計算壓力。與 Basic 相比，DualPath 在不同追加規模下實現了 1.82–1.99× 的加速。生成長度擴充套件時的趨勢類似。
Online Serving（線上推理服務）
線上服務實驗部分則模擬真實生產環境下 agent 按泊松分佈持續到達的場景，設定 TTFT ≤ 4 秒、TPOT ≤ 50 毫秒為服務等級目標論文。結果表明，DualPath 顯著提高系統可承載的到達率上限：在 DS 27B 上提升 1.67 倍，在 DS 660B 上提升 2.25 倍。
與此同時，DualPath 的 TTST 與 Basic 基本持平，TPOT 也未引入額外解碼開銷，說明其最佳化集中在 KV-Cache 讀取與排隊階段，而不會影響解碼階段效率論文。更重要的是，在負載升高時，DualPath 能保持 TTFT 結構穩定，而 Basic 的排隊時間會因儲存頻寬不足迅速上升，成為延遲惡化的主要來源。
最後，論文還做了大量消融實驗，感興趣的讀者，可以參考原論文，檢視更多內容論文。
