突破顯存瓶頸：基于 DeepSeek-V3.2-Exp 的 Latent Cache 卸載預取方案設計與模擬驗證

引 言

DeepSeek-V3.2-Exp 所搭載的稀疏化 Attention 計算，在長上下文場景中成功降低了推理延遲。但在 PD 分離架構下，隨著序列長度不斷增長，Decode 階段的吞吐受限問題愈發凸顯。核心癥結在于，Decode 過程中 Latent Cache 規模會隨序列長度呈線性增長，而 GPU 顯存容量有限，這直接導致 Batch Size 難以提升，進而抑制了 Decode 階段的吞吐增長。

基于此，本次百度百舸 AIAK 團隊研究的核心目標是：針對 DeepSeek-V3.2-Exp，通過將 Latent Cache 下放到 CPU 內存，在滿足延遲要求的前提下，提升 Decode 吞吐并顯著降低成本。本報告詳細闡述了我們為達成該目標所開展的系統瓶頸分析，以及最終提出的 Expanded Sparse Server（ESS）方案的設計與實現。

本文的主要貢獻如下：

• 系統性評估了 Latent Cache Offload 策略在 DeepSeek-V3.2-Exp 上的可行性與收益邊界。深入剖析了在稀疏化 Attention 框架下引入卸載 Latent Cache 的可行性、瓶頸來源與潛在收益，明確了不同環境配置與上下文長度條件下的收益上限。

• 提出 ESS（Expanded Sparse Server）系統方案，以卸載 Latent Cache 為核心實現 Decode 吞吐的無損擴展。百度百舸推出的 ESS 是一套面向工業部署的系統化方案，通過解耦 Latent Cache 存儲與計算路徑，實現 Decode 階段吞吐的顯著提升。同時，ESS 能與 MTP、Two-Batch Overlap 等主流優化策略無縫兼容，可作為現有推理系統的增強組件。

• 構建了高保真模擬器，用于評估多種優化策略在真實工業場景下的性能表現。該模擬器能夠精確建模模型計算、通信延遲以及 Offload-Prefetch 開銷，使開發者在系統實現前即可獲得可靠的性能預估，顯著降低工程驗證成本并加速方案迭代。

模擬實驗結果顯示，在 32K 上下文長度下，當 MTP 從 2 提升到 4 時，ESS 方案可實現整體 123.4% 的吞吐提升。其中，53.1% 的提升源于 MTP 提升本身，剩余 70.2% 的性能收益則由 ESS 所實現的 Offload-Prefetch 機制貢獻。

針對超長上下文場景的額外測試結果表明，在 MTP = 2 且上下文長度為 128K 的條件下，ESS 的 Offload-Prefetch 機制能直接帶來高達 123% 的吞吐提升。

問題背景及優化動機

顯存是限制吞吐的主要因素

圖 1 呈現了 32K 上下文下 Batch Size 與 Decode 吞吐的關系（數據由高保真模擬器生成），對應的系統配置如表 1 所示。理論上，隨著 Batch Size 增大，吞吐應持續提升，這是因為 Batch Size 與 GEMM 算子的計算強度（Arithmetic Intensity）密切相關 —— 更大的 Batch Size 能顯著提高 MFU，進而提升整體算力利用率。

圖 1. 吞吐和 Batch Size 之間的關系

表 1. 實驗環境及優化選項

但在當前配置下，GPU 顯存容量成為關鍵瓶頸：Batch Size 最多僅能提升至 52，對應的吞吐僅為 9647 tokens/s。在此情況下，系統無法進一步擴大計算批次，導致吞吐遠低于硬件理論上限。由此可得出結論：顯存容量是限制 Decode 吞吐擴展的主要因素。

這一發現直接凸顯了 Offload-Prefetch 策略的必要性與價值：通過打破 Latent Cache 與 GPU 顯存的綁定關系，系統才能突破現有吞吐上限，進一步釋放計算潛能。

Latent Cache 的訪問具有時間局部性

為緩解顯存壓力且保證精度不受影響，將部分 Latent Cache 卸載至 CPU 是一種具備實際可行性的優化方案。但該方案要實現高效運行，需滿足一個關鍵前提：Latent Cache 的訪問模式應具有良好的局部性（Locality）。

只有當模型在訪問 Latent Cache 時展現出足夠的重復性或鄰近性，才能維持較高的緩存命中率；否則，頻繁的跨 PCIe 訪問會使帶寬成為新的瓶頸，從而抵消 Offloading 帶來的收益。

為驗證 DeepSeek-V3.2-Exp 中的 Latent-Cache 是否具備足夠的局部性，我們從兩個維度對其訪問模式進行評估：

• 層間訪問（Inter-layer Access）：關注不同層之間在相鄰生成步驟中對 Latent Cache 訪問的相似程度。

• 層內訪問（Intra-layer Access）：關注同一層在連續生成步驟中的 Latent Cache 訪問是否穩定一致。

我們分別定義了 Inter-Layer Similarity 與 Intra-Layer Similarity 兩個指標，用于量化上述兩類訪問模式的局部性特征。第 L 層在生成第 t 步時所需的 Top-K 索引集合為 K^{L}_{t}。

公式（1）與公式（2）分別給出了層間相似度與層內相似度的數學定義。兩個指標均基于集合相似度構造，用來刻畫訪問需求與 GPU 中已有緩存之間的重合度 —— 重合度越高，說明局部性越強，越適合 Offload-Prefetch 策略。

基于 LongBench-v2 數據集在 DeepSeek-V3.2-Exp 模型上的實驗結果（見圖 2 與圖 3），我們觀察到層間與層內訪問均呈現出較高的相似度。

圖 2. Inter-Layer Similarity 在不同上下文長度中的統計

圖 3. Intra-Layer Similarity 在不同上下文中的統計

這一現象表明，Latent Cache 的訪問具有良好的局部性特征。因此，將 CPU 內存作為 HBM 的擴展存儲空間仍是一條可行路徑。盡管已有諸多類似工作探索了 CPU–GPU 協同存儲，但在結合 PD 分離架構與 SGLang 推理框架時，我們仍面臨以下特有挑戰：

• 低效的小塊數據拷貝：在 DeepSeek-V3.2-Exp 中，每個 Latent Cache 的大小僅為 656 Byte，且每次訪問的 2048 個 Latent Cache 塊在 Memory Pool 中呈離散分布。這種高度離散的小塊數據訪問模式使得 PCIe 難以形成有效的批量傳輸，顯著降低鏈路帶寬利用率，成為 Offload-Prefetch 類方案的主要瓶頸。

• 大量的 Cache Miss：為提升 Batch Size，需盡可能減少駐留在 GPU 上的 Latent Cache 數量。但縮小 GPU 側的 Latent Cache 會提高 Cache Miss 的發生概率，進而增加 H2D（Host-to-Device）傳輸量。由于這些傳輸無法與計算完全重疊，由此引入的數據傳輸延遲會導致 Decode 階段的吞吐量低于預期。

• 難以隱藏的數據傳輸延遲：在 Decode 階段，可用于掩蓋數據傳輸延遲的計算量不足，無法將傳輸完全隱藏。當大量出現 Cache Miss 時，這些傳輸延遲會暴露到關鍵路徑上，進一步降低推理性能。

ESS 方案設計與分析

如前文所述，卸載–預取（Offload–Prefetch）是近年來廣泛采用的一類無損優化策略，尤其適用于對精度高度敏感的推理場景。因此，我們在設計方案時同樣以卸載為核心思路。

在 DeepSeek-V3.2-Exp 中，Cache 主要由兩部分構成：Indexer Cache 與 Latent Cache。其中，Indexer Cache 用于計算每個 Latent Cache 的重要性，并從中選取最關鍵的 2048 個 Latent Cache 參與計算。根據模型架構分析，Indexer Cache 需要執行全量計算且其占比僅為 16.8%。基于這一事實，我們選擇不對 Indexer Cache 進行卸載，僅對 Latent Cache 部分實施 Offload–Prefetch 優化。圖 4 總結了在 PD 分離模式下卸載與預取的觸發時機。

此外，本小節還圍繞 2.2 小節中提出的關鍵挑戰展開針對性分析，并據此給出相應的優化設計。

圖 4. PD 分離場景中，Latent Cache 卸載預取時機流程圖

小塊數據拷貝

盡管 PCIe 5.0 在單向方向上可提供高達 64 GB/s 的帶寬，為 Offload–Prefetch 類方案帶來了理論上的可行性，但在現代推理框架（如 SGLang）中，這一帶寬往往難以被充分利用。原因在于 SGLang 采用 PagedAttention 管理 Latent Cache，將其劃分為多個頁面存儲，導致頁面之間在物理地址上不連續。進一步地，DeepSeek-V3.2-Exp 引入了更細粒度的稀疏化策略，將換入 / 換出的最小單元縮減到單個 Latent Cache 項。這種高度離散的小塊數據訪問模式會將大帶寬鏈路切割成大量碎片化事務，從而顯著降低實際可用帶寬。

在 Offload–Prefetch 類方案中，Latent Cache 會發生頻繁的卸載和預取操作，而 PCIe 帶寬則決定了這一操作的效率。同時考慮到 Latent Cache 屬于小尺寸 Cache，每個 block 為 656 字節。經測試，cudaMemcpyAsync 在這種場景中，H2D 和 D2H 的實際帶寬分別僅為 0.79GB/s 和 0.23G/s。

FlashTrans

為緩解這一問題，我們在系統設計中引入了 UVA，使 GPU 能夠直接訪問 CPU 端的 pinned memory，從而減少經由 PCIe 進行小塊數據傳輸時的管理開銷。基于 UVA，我們設計了 FlashTrans CUDA 算子，其通過地址驅動的按需傳輸機制，避免了頻繁調用 cudaMemcpyAsync 所帶來的調度開銷。FlashTrans 在細粒度、非連續的 Latent Cache 訪問模式下顯著提升了有效帶寬，使得 Offload–Prefetch 在 DeepSeek-V3.2-Exp 中得以切實落地。

經測試，FlashTrans 在 H2D 和 D2H 的性能分別為 37GB/s 和 43GB/s。為確保有效帶寬，對 Latent Cache 的卸載和預取，我們均使用 FlashTrans 進行。

緩存命中保證

較高的緩存命中率能夠顯著降低數據傳輸量。為此，ESS 首先基于 LRU 算法構建換入換出引擎，對推理過程中的 Cache Miss 行為進行了系統性分析。除此之外，我們還提出 LRU-Warmup 用于保障推理初期的低 Cache Miss。

LRU-Warmup

GPU 端 Sparse Memory Pool 的初始狀態對生成早期的性能影響顯著。如圖 5 所示，生成初期會出現大量 Cache Miss，但隨著 Decode 的推進，該現象會快速收斂。

圖 5. Decode 初期 Cache Miss 嚴重 MTP=1，Sparse Memory Ratio=0.2

為降低這一初始階段的額外開銷，我們對 LRU Recording 進行預熱（LRU- Warmup）。具體而言，我們利用 Prefill 階段最后 32 個窗口中所選取的 Top-2K Latent Cache Indices，并依次將其注入 LRU，以構建更符合初始生成需求的緩存狀態。如圖 6 所示，該策略能夠顯著降低 Decode 初期的 Cache Miss 量，從而提升早期推理階段的效率。

圖 6. LRU-Warmup 之后的 Cache Miss 情況

Cache Miss 分析

在第 2.2 節中，我們驗證了 Deepseek-V3.2-Exp 在 Latent Cache 訪問上同時呈現層內與層間的時間局部性。這一特性表明：一旦某個 Latent Cache 在當前步被訪問，其在后續步驟中再次被訪問的概率仍然較高。基于這一觀察，我們采用 LRU 策略對 GPU 端的 Sparse Memory Pool 進行持續更新，使其能夠優先保留未來最可能被需求的 Cache。

圖 7 展示了依據 Intra-Layer Access 構建 Sparse Memory Pool 后，每個 batch 的平均 Cache Miss 數量。我們進一步在不同的 Sparse Memory Ratio 下進行了對比分析，這些結果共同刻畫了在不同顯存預算下可獲得的性能收益邊界。

圖 7. Intra-Layer Cache Miss 情況，MTP=2

為進一步降低 Decoding 期間 Cache Miss 發生率，我們嘗試通過層間預取的方式緩解層內預取的 Cache Miss 壓力。之所以有這樣的思考，是因為我們在層間同樣發現了極高的局部性（如圖 1）。具體而言，我們首先根據 L?1 層的 Top-K Indices 預先從 CPU 中取出對應第 L 層的 Latent Cache。該部分數據傳輸將和 MLP 進行重疊。如此利用層間預取，能有效減少層內 Cache Miss 的發生。具體效果如圖 7 和圖 8 所示。考慮層間預取后，層內命中率計算如公式 3。

其中，I^L 表示第 L 層 Sparse Memory Pool。不過，利用層間預取時，會預取大量無用的 Latent Cache。經統計，在 Sparse Memory Ratio 為 0.2 時，層間預取的 Cache Miss 平均為 663 個每 Batch，最大為 1353 個每 Batch。因此，我們認為盡管層間預取能夠緩解層內預取的 Cache Miss 壓力，但無法真正對端到端加速起到作用。

圖 8. 平均 Cache Miss 情況對比

圖 9. 最大 Cache Miss 情況對比

計算傳輸重疊

影響端到端性能的另一項關鍵策略是計算與通信的重疊。基于對 SGLang 現有實現的系統性拆解與分析，我們設計了 Dual-Attention (DA) Overlap 和 DualBatch-Attention (DBA) Overlap 兩種方案，以最大化計算過程與數據傳輸之間的重疊程度，從而進一步提升整體吞吐。

Overlap 作用分析

圖 10 展示了在未采用 Overlap 策略時推理過程的完整 timeline。圖中，H2D 表示對 Missed Latent Cache 的獲取。此外，還包含一段較小的 D2H 操作，用于將當前 step 新生成的 Latent Cache 寫回 CPU 端的 Total Memory Pool。

在不啟用 Overlap 的情況下，這兩類數據傳輸均必須等待 Indexer 計算完成后才能啟動，而后續的 Attention 計算又必須在所有傳輸結束后才能繼續執行。這樣的嚴格依賴使得不同階段無法并行，最終構成一條完全串行的執行鏈路，從而顯著限制了整體吞吐。

Overlap 策略

• Without Overlap：該模式對應當前 SGLang 的默認實現，不包含任何計算與通信的重疊。在此模式下，GPU 在等待 H2D 數據拷貝期間處于 idle 狀態，導致整體吞吐率顯著低于硬件可達上限。

• DA Overlap：在 Deepseek-V3.2-Exp 的 SGLang 實現中，Attention 由兩個階段構成：forward_prepare 與 forward_core。其中，forward_prepare 又可進一步拆分為 PreAttn 與 Indexer 兩部分。Indexer 表示 Indexer 本身以及所有依賴其結果的計算，PreAttn 則包含與 Indexer 無依賴關系的操作，例如 q_b_proj、bmm、copy_pe、rotary_embedding 等。為提升計算與 H2D 預取之間的重疊度，我們首先將 PreAttn 從 forward_prepare 中抽離，并推遲到 Indexer 完成之后再執行。然而，PreAttn 本身的計算量不足以完全隱藏 Latent Cache 的預取開銷。為進一步增強重疊能力，SparseMLA 被劃分為兩個子階段：Attn0 與 Attn1。Attn0 直接使用當前 GPU 中已存在的 Latent Cache 進行計算。Attn1 等待 H2D 預取完成后，使用新拷貝上來的 Latent Cache 繼續計算。最終將兩部分結果進行合并。由于 Attn0 可與 H2D 傳輸并行執行，因此能夠有效隱藏數據拷貝延遲，顯著提升整體 Overlap 程度。

• DBA Overlap：由于 Attention 的計算量在上下文長度超過 2K 之后基本保持穩定，這使得 Dual-Attn 在長上下文場景中的重疊效果有限。為進一步提升重疊空間，我們提出了 DualBatch-Attention (DBA) Overlap。DBA 在 Dual-Attn 的基礎上，將 Indexer 沿 Batch 維度劃分為兩部分，使得約一半的 Indexer 計算能夠參與 Overlap。這樣不僅擴大了可被隱藏的計算量，也使得在長上下文下仍能保持充分的計算通信重疊，從而提升端到端吞吐。

圖 10. 不同 Overlap 方案對比

更具體而言，在 DBA Overlap 中，我們主要將 mqa_logits 與 Top-K 兩部分納入可重疊計算的范圍。之所以選擇這兩部分，是因為它們的計算強度在 Batch Size 降低時并不會隨之顯著下降，從而能夠有效抵消 Batch 切分所帶來的性能損失，提高整體的重疊效率。圖 10 展示了 DA Overlap 與 DBA Overlap 在實際執行過程中的 timeline 對比。

Layerwise Overlap 策略

如圖 7 所示，不同層之間的 Cache Miss 行為存在顯著差異，尤其是在 Sparse Memory Ratio 較小時。例如，當 Sparse Memory Ratio 為 0.2 時，每個 batch 的 Cache Miss 數量從 16.66 到 605 不等。如此大的波動性說明單一的 Overlap 策略無法高效適配所有層。

如圖 11 所示，我們評估了三種 Overlap 策略在不同 Cache Miss Count 下的性能退化情況。在 DBA Overlap 策略中，Indexer 的計算成本會隨著上下文長度線性增長，使其能夠在長上下文場景中有效隱藏 Latent-Cache 的傳輸延遲。因此，當 Cache Miss Count 達到 512 時，DBA 由于有足夠的 overlap 空間依然能夠保持較高的效率。而在 Cache Miss 較低的情況下，DA Overlap 更具優勢，因為它能夠在不引入 Indexer 劃分開銷的前提下完全隱藏數據傳輸延遲。

圖 11. 不同 Overlap 策略的性能損耗，雙流 + MTP=2，請求長度 128K，Batch Size=160，帶寬為 37GB/s

我們認為，Overlap 策略的選擇主要由兩個因素決定：Cache Miss 情況和上下文長度。

首先，我們觀察到在不同的上下文長度下，各層的 Cache Miss 沿 LayerID 的分布趨勢具有高度一致性（如圖 12 所示）。因此，我們可以通過預先測試，識別出在推理過程中最容易產生大量 Cache Miss 的關鍵層。

然后，在相同的 Sparse Memory Ratio 下，不同上下文長度所表現出的總體 Cache Miss 水平并不一致。因此，需要通過測試確定在何種 Cache Miss 閾值下應切換至 DBA 策略。

圖 12. 不同上下文情況不同層的 Cache Miss 對比，MTP=2，Sparse Memory Ratio=0.2

不同上下文長度下的可擴展性

如圖 13 所示，隨著上下文長度的增加，當 Sparse Memory Ratio ≥ 0.2 時，平均 Cache Miss 維持在相對穩定的水平。需要特別指出的是，在 32K 上下文條件下，當 Sparse Memory Ratio 較小時會出現最嚴重的 Cache Miss。

這主要是因為 GPU Buffer 過小，導致頻繁的換入換出操作，從而顯著增加了 Miss 發生的概率。同時如圖 11 所示，我們發現 Cache Miss 過大時，現有方案無法很好地隱藏數據傳輸延遲，進而造成數百 us 的單層延遲。

因此，我們建議將 Sparse Memory Pool Size 最小配置為 6.4K 個 Slots，這樣能夠保證平均 Cache Miss 在 200 以下，確保數據傳輸延遲能夠被有效 Overlap 起來。

同時，圖 13 也表明，在相同的 Sparse Memory Ratio 下，平均 Cache Miss 隨上下文長度增加而進一步下降。這意味著更長的上下文能夠使用更小的 Sparse Memory Ratio，獲得更大的 Batchsize 提升，進而獲取更大的吞吐收益。

圖 13. 不同長度上下文情況， 平均 Cache Miss 統計

模擬驗證

模擬器

AIAK 團隊基于內部自研的高仿真模擬器進行了性能評估。該模擬器的元數據來源于真實機器的運行結果，并通過線性插值補全未覆蓋的數據點。同時，根據實際的計算流與傳輸流構建完整的執行框架，并納入了 MTP、雙流等系統優化機制的影響。

得益于該模擬器的高精度建模，我們能夠在不依賴大量真實實驗的情況下，準確預估大模型的推理性能，從而顯著降低方案驗證的成本。

端到端性能評估

在本實驗中，我們評估了 32K 上下文條件下，不同 MTP 值和接受率下的性能表現，同時將其他所有配置保持與表 1 一致。根據模擬器輸出的吞吐和 OPTS 結果（表 2），可以看到：MTP = 2 能夠帶來 69.4% 的端到端吞吐提升；當 MTP = 4 且接受率為 3.4 時，端到端吞吐提升為 45.8%。

我們進一步在 MTP = 2、接受率為 1.7 的配置下，對 128K 的超長上下文進行了評測。由于在該上下文長度下 Batch Size 相對較小，因此我們在實驗中關閉了 Two-Batch Overlap 優化。如圖 9 所示，更長的上下文長度使系統能夠在較低的 Sparse Memory Ratio 下運行。最終結果如表 2 所示，當 Sparse Memory Ratio 為 0.1 時，端到端吞吐獲得了 123% 的性能提升。

表 2. 端到端性能評估

結論與展望

ESS 作為一種在精度無損前提下提升 Batch Size 的工程化方案，其核心的 Offload–Prefetch 機制已在諸多大模型推理場景中得到驗證與廣泛應用。

百度百舸 AIAK 團隊針對 DeepSeek-V3.2-Exp 在 SGLang 中的推理路徑，量身設計并模擬驗證了適配該模型的 Offload 策略。實驗結果充分證明了 Offload–Prefetch 機制在該模型中的可行性與顯著性能潛力，為后續系統優化奠定了堅實基礎。

未來，AIAK 團隊不僅計劃將 ESS 方案在實際框架中落地，還將進一步拓展其適用邊界 —— 依托其對 KV Cache 存儲與計算路徑的解耦設計、高效的數據傳輸優化及靈活的緩存管理機制，將 ESS 方案擴展至更多采用 KV Cache 動態壓縮方案的大模型中。同時，團隊還將探索 ESS 與 SnapKV 等有損壓縮方法的融合應用，持續突破推理吞吐瓶頸，為各類大模型的高效部署提供更具通用性的優化方案。