導讀

在大型語言模型（LLM）推理中，KVCache 是提升效率的核心機制：通過緩存 Transformer 自注意力層的歷史 Key-Value 對，避免重複計算，顯著降低單次推理開銷。然而，在“智能體式推理”（Agentic Inference）這一新興範式下——模型需持續感知環境、進行多輪決策、自我反思，並協同其他智能體完成複雜任務——傳統 KVCache 機制暴露出三大關鍵瓶頸：

• 狀態膨脹：長上下文交互導致緩存顯存佔用指數級增長；
• 跨輪次持久化缺失：會話狀態難以有效延續，影響推理連貫性；
• 多任務/多智能體間緩存孤立：缺乏共享機制，造成冗餘計算與決策衝突。

為應對上述挑戰，阿里雲 Tair KVCache 團隊與 SGLang 社區、Mooncake 團隊展開深度合作，共同構建了面向智能體推理的下一代緩存基礎設施：顯存 – 內存 – DeepSeek 3FS 的多級 KVCache Offloading 和全局共享（Global Sharing）。在 Novita AI 等真實生產場景中，該方案已實現顯著性能躍升，緩存命中率由 40 % → 80 %，平均 TTFT 降低 56 %，推理 QPS 提升 2 倍。
本系列技術文章將系統性拆解面向智能體推理的KVCache技術演進路徑：

1. 本文｜智能體式推理對 KVCache 的挑戰與 SGLang HiCache 技術深度剖析；
2. 3FS-KVCache 產品化實踐：企業級部署、運維與性能調優最佳實踐；
3. Hybrid Model Support：SGLang 對 Mamba-Transformer 等混合架構模型的支持方案；
4. Tair KVCache Manager：企業級全局 KVCache 管理服務的架構設計與實現；
5. KVCache 仿真分析：高精度的計算和緩存模擬設計與實現；
6. Hierarchical Sparse Attention：分層稀疏注意力框架下的 KV 分層管理與按需加載；
7. 展望：KVCache驅動的軟硬結合演進。

Tair KVCache作為阿里雲數據庫Tair產品能力的延伸，本質是緩存範式的三次躍遷：
🔹 從 Redis 的 “緩存數據 → 減少 I/O”
🔹 到 GPU KVCache 的 “緩存計算中間態 → 減少重複計算”
🔹 再到 Tair KVCache 的 “規模化、智能化的注意力狀態管理 → 重構大模型推理成本模型”它標誌着緩存正從輔助組件升級為 AI 基礎設施層的核心能力——讓“狀態”可存儲、可共享、可調度，支撐智能體時代的規模化推理底座。

1.引言

1.1 自迴歸的代價：KVCache 的誕生

大語言模型的推理本質上是一個自迴歸（Autoregressive）過程：模型逐個生成 token，每一步都需要"回顧"此前已生成的全部上下文。這一機制保證了語義的連貫性，卻也帶來了顯著的計算冗餘。
問題的核心在於 Attention 機制。在生成每個新 token 時，模型需要用當前 token 的 Query（Q）與所有歷史 token 的 Key（K）進行點積運算，計算出注意力權重後，再對歷史 token 的 Value（V）進行加權聚合。然而，歷史 token 對應的 K 和 V 一旦生成便不再改變——如果每次解碼都重新計算它們，將造成大量不必要的重複開銷。

KVCache 正是為解決這一問題而生：在首次計算每個 token 的 K 和 V 後將其緩存，後續生成步驟直接複用，從而避免重複的前向傳播計算。這一優化顯著降低了推理延遲、提升了吞吐效率，已成為現代大語言模型實現高效推理的基礎技術。

1.2 再遇瓶頸："以存代算"破解KVCache的容量挑戰

KVCache在帶來性能收益的同時，也引入了新的瓶頸——存儲容量。
如左圖所示，以 Qwen2-7B 模型為例，在千級 QPS、平均 1K 輸入的在線服務場景下，疊加多輪對話的狀態保持、Prefix Caching（前綴複用）等需求，KVCache 總量隨緩存時長呈線性增長——從秒級的 GB 量級迅速膨脹至天級的 PB 量級，遠超本地顯存乃至主機內存的承載上限。
右圖則揭示了一個關鍵洞察：以存代算。當序列長度超過一定閾值後，從存儲介質中加載已緩存的 KV，其端到端延遲反而低於 GPU 重新執行 Prefill 計算。這為 KVCache Offloading 提供了堅實的理論依據——將低訪問頻次的 KV 狀態從 GPU 顯存逐級卸載至主機內存、甚至通過 RDMA 卸載至遠端分佈式存儲池，既能突破單機容量瓶頸，又能保證加載延遲低於重算開銷。
這一"用存儲換計算"的策略，為長上下文、高併發的 LLM 推理服務提供了兼顧吞吐、延遲與成本的可擴展路徑。

1.3 爆發的長文本：Agentic Inference 的興起

從 OpenRouter 最近發佈的報告上指出，"當前，LLM 在實際生產中的應用正經歷一場根本性轉變：從單輪文本補全，轉向多步驟、工具集成、強推理驅動的工作流。我們將這一轉變稱為“智能體式推理”（agentic inference）的興起——即模型不再僅用於生成文本，而是被部署為能夠主動規劃、調用工具、並在延展上下文中持續交互的“行動者”。其中最關鍵的包含序列長度分佈的變化，以及編程類應用場景如何推動整體複雜性提升"。

1.3.1 上下文窗口極大延長（Long Context Explosion）

AI Agent 需要記憶長期、跨輪次、多任務的上下文，例如：多輪工具調用的完整 trace、用户歷史偏好與行為日誌、多文檔協同分析（如合同+財報+郵件）多智能體協作中的 shared memory。 這使得上下文長度從傳統 chat 的幾百~幾千 tokens，躍升至數萬乃至百萬 tokens。在這個場景下因為KVCache 大小與上下文長度呈線性增長，推理服務很容易碰到顯存容量的擴展瓶頸。

1.3.2 編程類應用場景

編程類應用Agent 通常以 “思考-行動-觀察”循環運行，每輪新增少量 token（如工具調用結果），但需保留全部歷史 KV 以維持狀態一致性。傳統一次性推理KVCache生命週期為單次請求，在Agent 推理場景KVCache生命週期為整個會話甚至數小時。要求 KVCache 持久駐留、支持增量 append，而非每次重算。
編程的交互更接近“人–人”對話節奏，用户容忍延遲更低（目標：<500 ms 端到端）。無 KVCache 時，每生成一個 token 需重算全部歷史O(n²) 複雜度；有 KVCache → O(n) → 對超長上下文至關重要。並且隨着輪次的增長上下文長度的變化，避免重複計算節省成本也是當前應用最為關注的要點。
一個 Agent 實例常需併發處理多個用户/子任務，而不同任務可能共享部分上下文（如同一用户的不同 query 共享 profile，多個子 Agent 共享環境狀態，prompt template 或 system instruction 複用）需要通過 KVCache 共享/複用機制（如 prefix caching、cross-request reuse），可大幅降低重複計算與內存佔用。

1.4 突破顯存牆：Hierarchical KVCache（HiCache）的破解之道

針對智能體式推理碰到上下文窗口極大延長，持續交互與流式推理，多任務併發與共享緩存，實時性要求提升的諸多挑戰。
SGLang HiCache 構建了一套分級（Hierarchical）的 KVCache 管理體系，將 GPU 顯存、主機內存、本地磁盤乃至遠端分佈式存儲（如 3FS）統一納入緩存層次結構。通過智能的熱度感知調度與異步預取機制，HiCache 能夠在容量受限的顯存中保留高頻訪問的"熱"數據，同時將"冷"數據透明地卸載至更大容量的下層存儲，在請求到來前及時加載回顯存參與計算。這一設計使得 SGLang 推理系統得以突破單機硬件的物理邊界，以近乎線性的方式擴展有效緩存容量，真正釋放"以存代算"的潛力。另一方面，實現高效的 KVCache Offloading，離不開一套高性能的底層存儲系統。3FS（Fire-Flyer File System） 是 DeepSeek 開源的分佈式文件系統，專為 AI 大模型訓練與推理場景設計，具備以下核心特性：

• 存算分離架構：計算與存儲解耦，便於獨立擴展；
• 極致吞吐性能：結合 RDMA 網絡與 NVMe SSD，在 180 節點集羣中可達 6.6 TiB/s 讀取帶寬；
• 強一致性保障：基於 CRAQ 鏈式複製協議，兼顧一致性與高可用；
• 靈活的訪問接口：提供 POSIX 兼容的 FUSE 客户端與高性能 USRBIO 接口，兼顧易用性與極致性能。Tair KVCache團隊將 3FS 集成至 SGLang HiCache 體系，為 KVCache 提供高帶寬、低延遲的 Offloading 通道，同時實現跨節點的全局緩存複用能力。

2.從“複用”到“分層”的演進：SGLang PrefixCache介紹

Radix Tree & HIRadixTree 深度介紹：

2.1 Prefix RadixTree：前綴複用的藝術

在 LLM 推理服務中，重複計算相同的文本前綴是一個巨大的性能浪費。
設想這樣一個場景：在阿里雲的企業級 AI 助手服務中，所有用户請求都以相同的系統提示詞（System Prompt）開頭——可能是上千 token 的角色設定與規則説明。傳統的 KVCache 機制以請求為單位獨立管理，即便這些前綴完全相同，每個請求仍需重新執行一遍 Prefill 計算，造成大量冗餘開銷。
SGLang 的 RadixTree 正是為解決這一痛點而生。RadixTree（基數樹）是一種高效的前綴檢索數據結構，SGLang 利用它來管理和索引所有已緩存的 token 序列。當新請求到達時，系統在 RadixTree 中檢索其 token 序列，找到與已緩存序列的最長公共前綴，直接複用對應的 KVCache，僅對剩餘的新增 token 執行 Prefill 計算。
這一優化在以下場景中效果尤為顯著：

• 共享系統提示詞：大量請求複用相同的 System Prompt；
• 多輪對話：同一會話的後續輪次天然共享歷史上下文；
• AI Coding：代碼補全場景中，同一文件的多次請求共享大量代碼上下文；
  通過前綴複用，RadixTree 可將 SGLang Prefill 階段的計算量降低數倍乃至數十倍，顯著提升吞吐並降低首 Token 延遲（TTFT）。

2.2 HIRadixTree：突破顯存邊界的分層緩存

RadixTree 解決了"如何複用"的問題，但並未解決"能緩存多少"的問題—— KVCache 仍受限於 GPU 顯存容量。
隨着 Agentic AI、長文檔問答、代碼倉庫級理解等任務的興起，請求上下文長度持續增長，緩存容量直接決定了命中率，進而影響系統吞吐與響應延遲。單張 GPU ～100GB 的顯存，在面對海量併發長上下文請求時捉襟見肘。
為此，我們在 SGLang 中設計並實現了 HIRadixTree（Hierarchical RadixTree，下文簡稱 HiCache）-- 一套分層級的 KVCache 管理機制，將原本侷限於 GPU 顯存的 RadixTree 擴展為三層存儲架構：

其核心工作機制如下：

• 自動卸載（Offload）：系統根據訪問熱度將高頻 KVCache 異步卸載至 CPU 內存；隨後進一步持久化至本地磁盤或遠程分佈式存儲（如 3FS）；
• 智能預取（Prefetch）：當請求命中遠端緩存時，系統在實際計算前異步預取所需 KV 數據至 GPU 顯存，最大程度隱藏 I/O 延遲；
• 熱度感知驅逐（Eviction）：結合 LRU 等策略，優先保留高頻訪問的"熱"數據於顯存，確保緩存命中率最大化；通過這一分層設計，原本僅有 40GB 顯存的 GPU 可藉助 CPU 內存擴展至 200GB+ 的有效緩存容量，進一步結合存儲層可支持 TB 級別的超長上下文緩存。HIRadixTree 在保持 RadixTree 高效前綴檢索能力的同時，真正實現了近乎無限的 KVCache 容量擴展，為長上下文、高併發的 LLM 推理服務提供了堅實的基礎設施支撐。

3.如何讓遠端存儲像本地顯存一樣快：HiCache 架構詳解

本節中將會詳細介紹 HiCache 體系中的技術細節。

3.1 系統架構設計

模塊功能説明：

• HiRadixTree：GPU/CPU 雙層前綴緩存樹結構，原生支持 KVCache 在 GPU 與 CPU 之間的自動同步
• Storage Backend：可插拔的存儲後端抽象層，當前已集成 3FS、Mooncake、NIXL 等後端實現。通過統一接口封裝 batch_get / batch_set / batch_exists 等操作，支持零拷貝數據傳輸，兼顧高吞吐與低延遲
• Global KVManager：提供分佈式文件系統（FS）的元數據統一管理服務，具備高效的元數據組織、查詢與協調能力，為全局 KVCache 提供一致性管理
• 3FS Global Storage: DeepSeek 開源的高性能分佈式文件系統，採用存算分離架構，結合 RDMA 網絡優化與 NVMe SSD，提供 TiB/s 級別的聚合讀取帶寬，作為 HiCache 的持久化存儲底座。

3.2 KVCache 流水線預取與計算重疊

在原始調度模式下，請求從入隊到首 Token 生成需要經歷"等待 → 前綴匹配 → 顯存分配 → Prefill 計算"全流程，其中 KVCache 僅存在於 GPU 顯存。HiCache 模式通過引入三層存儲架構與異步流水線，實現了兩個關鍵優化：
1. 預取與等待並行：

• 請求入隊時即觸發 prefetch_from_storage，在等待調度期間，後台線程已將 Storage 中命中的 KV 數據異步加載至 Host 內存，有效利用排隊等待的"空閒"時間；
• Scheduler 調度到請求時根據調度策略終止請求prefetch/跳過請求調度。支持的調度策略：
• Best_effort：盡力而為，當調度到請求r時，如果r仍在prefetch則終止r，調度進入推理；
• Timeout：基於預計耗時終止請求，當調度到請求r時，如果r仍在prefetch且耗時超過預定義閾值則終止r，否則跳過r的調度本輪不進行推理；
• Wait_complete：prefetch 完所有kvcache才進入推理調度，否則跳過。
• 加載與計算 Overlap：當請求被調度執行時，Host → GPU 的 KV 加載通過獨立 CUDA Stream 逐層進行（load_to_device_per_layer），模型前向計算可在第 i 層 KV 就緒後立即開始，無需等待全部層加載完成，實現計算與傳輸的流水線重疊。
  這一設計將原本阻塞的 I/O 開銷隱藏於調度等待與 GPU 計算之中，在顯著擴展有效緩存容量的同時，最大程度降低了對首 Token 延遲（TTFT）的影響。

3.3 基於Page/Layer佈局變換的零拷貝傳輸

HiCache 採用零拷貝（Zero-Copy） 技術實現 KVCache 的高效跨層傳輸。
在數據佈局上：

• 遠端存儲按 Page 組織，每個 Page 有一個獨立的 Prefix Hash Key 用於檢索
• Host 內存採用 Page-first 佈局（[2, size, layer_num, head_num, head_dim]），使得同一 Page 內所有 Layer 的數據物理連續；
• GPU 顯存則採用 Layer-first 佈局（[2, layer_num, size, head_num, head_dim]），便於按層訪問
• 在傳統 Layer-first 佈局（[2, layer_num, size, ...]）下，同一 Page 的 KV 數據分散在各 Layer 的不同內存區域，寫入存儲前必須先執行 .flatten().contiguous() 將數據拷貝重組為連續塊。而 Page-first 佈局（[2, size, layer_num, ...]）將 size 維度前置，使得同一 Page 內所有 Layer 的數據在內存中物理連續，可直接寫入存儲或從存儲讀取，無需額外的數據重組拷貝
  傳輸路徑上:
• Storage → Host 採用 Page-wise 粒度，通過 3FS libusrbio 等用户態 I/O 庫將數據直接寫入 Host KV Pool，繞過內核緩衝區；
• Host → GPU 則採用 Layer-wise 粒度，通過獨立 CUDA Stream 逐層傳輸，使得模型前向計算可以在第 i 層數據就緒後立即開始，實現計算與傳輸的流水線重疊。這一設計在最大化存儲帶寬利用的同時，將數據加載延遲有效隱藏於 GPU 計算之中。
• Page-first 佈局在 Host 層充當"橋樑"，既滿足存儲層的 Page 連續性要求，又通過轉置支持 GPU 層的 Layer 訪問模式，以一次佈局轉換換取傳輸路徑上的零拷貝收益。

3.4 Prefill與Decode分離架構的集成

目前，SGLang 的 PD（Prefill/Decode）分離架構已與 HiCache 實現無縫集成，KVCache 的全生命週期管理流程如下：

1. 高速直傳：Prefill 與 Decode 節點之間通過 GDR（GPU Direct RDMA）高速通道實現 KVCache 的零拷貝直接傳輸
2. Prefill 跨實例複用：支持 Prefill 啓用 HiCache，實現 KVCache 的異步 Offload 與 Prefetching及跨實例的 KVCache 複用
3. Decode 節點輕量緩存控制：出於歷史兼容性考慮，Decode 節點默認關閉 HiCache；為此新增輕量級組件 DecodeOffloadManager，專門負責異步 Offloading 操作。在多輪對話場景中，Prefill 節點可直接複用 Decode 節點已生成的 KVCache，避免重複計算，從而在 PD 分離架構下達成與非分離部署同等的緩存效率與性能表現。

3.5性能實戰 (3FS Backend)

4.後續工作預告

4.1 HiCache Roadmap

4.1.1 Roadmap

SGLang HiCache 項目仍在積極建設中，未來將圍繞以下方向持續演進，歡迎社區共建：
🔹 深度集成 EPD 架構：支持 Embedding Node 與 Prefill Node 之間通過 HiCache 高效傳輸 Embedding Cache
🔹 支持 Sparse Attention：適配 DeepSeekV32 等模型
🔹 支持 Hybrid 模型：適配支持 Mamba、SWA 等 Hybrid Model
🔹 更智能的調度策略：基於 band usage、error_rate 等實時指標，動態調控 backup/prefetch 速率，提升緩存效率與資源利用率
🔹 完善可觀測性體系：豐富監控指標，提供更全面、細粒度的性能洞察，助力問題診斷與調

4.1.2 Hierarchical Sparse Attention

隨着上下文長度持續增長，稀疏注意力（Sparse Attention） 成為提升長文本推理效率的重要技術路徑——通過僅選取對當前預測關鍵的少量 token 參與注意力計算，在幾乎不損失精度的前提下大幅降低計算開銷。DeepSeek 提出的 NSA（Native Sparse Attention） 即為這一方向的代表性工作。
然而，現有稀疏化方案仍需在 GPU 顯存中保留全量 KVCache，長上下文場景下的顯存瓶頸依然存在。為此，我們正在 SGLang 中構建分層稀疏注意力框架，結合 HiCache 實現 KVCache 的分層卸載與按需加載，僅在 GPU 中保留需要的 Topk KVCache，從而突破顯存容量限制，顯著提升可支持的 Batch Size 與系統吞吐。

4.2 3FS 產品化方案

3FS 作為專為 AI 場景設計的高性能分佈式文件系統，其部署與運維需兼顧靈活易用、高可用與彈性擴展等能力。
在部署實踐中，阿里雲服務器研發存儲團隊開源的 3FS Operator，通過 Kubernetes 原生能力提供了完整的雲原生化解決方案

• 聲明式部署與容器化管理：基於 Kubernetes 的自定義資源+控制器能力，實現 3FS 集羣的容器化部署，支持自建物理機集羣、阿里雲 ACK 等多種環境
• 無感知存儲接入：基於Webhook機制動態注入Fuse Client容器，對用户業務容器完全透明
• 故障自愈與彈性擴縮容：Operator 持續監控組件狀態，自動替換故障副本，實現滾動升級與彈性擴容；通過 Headless Service + DNS 解析解決 Mgmtd Pod IP 變化問題，保障主備節點無縫切換
• 租户資源隔離：支持在同一 Kubernetes 集羣中部署多套 3FS 集羣，結合阿里雲 VPC 子網劃分與安全組策略，實現跨業務場景的管控資源複用與網絡安全隔離

4.3 Hybrid Models Support

隨着混合架構模型（全注意力層+線性注意力層）在長上下文大語言模型服務場景的加速普及，SGLang通過創新內存管理與調度機制，在保持推理能力的同時顯著降低顯存佔用與計算延遲。該設計有效解決了線性注意力狀態不可回滾與傳統優化機制的衝突，核心能力包括：

• 分層內存架構：隔離管理 KVCache（Token 粒度）與 SSM 狀態（請求粒度），分別管理不同注意力層的緩存，支持根據實際負載預定義不同緩存池比例
• 彈性顯存調度：基於 CUDA 虛擬內存技術實現KV/SSM雙池動態伸縮，實現固定總顯存下的資源利用率最大化
• 混合前綴緩存：擴展RadixTree支持KV/SSM雙緩存生命週期管理，實現無算子修改的前綴複用與淘汰
• 推測解碼適配：通過狀態快照槽位機制兼容EAGLE-Tree等加速方案，支持Top-K >1場景
• PD 架構擴展：新增獨立狀態傳輸通道，簡化新型混合模型集成

4.4 Tair KVCache Manager

面對多樣的推理引擎和後端存儲系統，Tair KVCache將其中共同的KVCache全局管理需求抽取，提供了統一的全局KVCache管理系統 Tair KVCache Manager：

• 提供全局外部KVCache管理能力。實現KVCache跨機複用。
• 通過統一的接口和傳輸庫支持 SGLang、vLLM、RTP-LLM、TensorRT-LLM 等主流推理引擎的接入。
• 支持使用包括 3FS 在內的多種存儲系統。通過一致的存儲元數據抽象對異構存儲系統進行封裝，顯著降低了不同推理引擎以及不同存儲系統接入的複雜度與開發成本。
• 提供多租Quota管理、高可靠、可觀測等企業級能力。
• 針對如何確定特定業務和場景下全局KVCache池化收益的難題，KVCache Manager提供了算力和緩存仿真能力，可以基於真實業務Trace計算命中率和算力節約量。同時提供了配置尋優功能，幫助用户調整存儲配置，實現最佳ROI。