在大型语言模型（LLM）推理中，KVCache 是提升效率的核心机制：通过缓存 Transformer 自注意力层的历史 Key-Value 对，避免重复计算，显著降低单次推理开销。然而，在“智能体式推理”（Agentic Inference）这一新兴范式下——模型需持续感知环境、进行多轮决策、自我反思，并协同其他智能体完成复杂任务——传统 KVCache 机制暴露出三大瓶颈：
状态膨胀：长上下文交互导致缓存显存占用指数级增长；
跨轮次持久化缺失：会话状态难以延续，影响推理连贯性；
多任务/多智能体间缓存孤立：缺乏共享机制，造成冗余计算与决策冲突。
为应对上述挑战，阿里云 Tair KVCache 团队与 SGLang 社区、Mooncake 团队展开深度合作，构建了面向智能体推理的下一代缓存基础设施：基于显存 – 内存 – DeepSeek 3FS 的多级 KVCache 卸载（Offloading）与全局共享（Global Sharing）。在 Novita AI 等真实生产场景中，该方案实现缓存命中率从 40% 提升至 80%，平均首 Token 延迟（TTFT）降低 56%，推理 QPS 提升 2 倍。
本系列技术文章将系统拆解面向智能体推理的 KVCache 技术演进路径：
- 本文｜智能体式推理对 KVCache 的挑战与 SGLang HiCache 技术深度剖析；
- 3FS-KVCache 产品化实践：企业级部署、运维与性能调优最佳实践；
- Hybrid Model Support：SGLang 对 Mamba-Transformer 等混合架构模型的支持方案；
- Tair KVCache Manager：企业级全局 KVCache 管理服务的架构设计与实现；
- KVCache 仿真分析：高精度的计算和缓存模拟设计与实现；
- Hierarchical Sparse Attention：分层稀疏注意力框架下的 KV 分层管理与按需加载；
- 展望：KVCache 驱动的软硬结合演进。
Tair KVCache 作为阿里云数据库 Tair 产品能力的延伸，标志着缓存范式的三次跃迁：
🔹 从 Redis 的“缓存数据 → 减少 I/O”
🔹 到 GPU KVCache 的“缓存计算中间态 → 减少重复计算”
🔹 再到 Tair KVCache 的“规模化、智能化的注意力状态管理 → 重构大模型推理成本模型”
缓存正从辅助组件升级为 AI 基础设施层的核心能力——让“状态”可存储、可共享、可调度，支撑智能体时代的规模化推理底座。
一、引言
1.1 自回归的代价：KVCache 的诞生
大语言模型的推理本质上是自回归过程：逐个生成 token，每一步均需回顾此前全部上下文。Attention 机制要求用当前 Query 与所有历史 Key 进行点积运算，再对 Value 加权聚合。由于历史 K/V 不变，若每次重新计算将带来巨大冗余。
KVCache 正是为此而生：首次计算后缓存 K/V，后续直接复用，避免重复前向传播，已成为高效推理的基础技术。
1.2 再遇瓶颈："以存代算"破解 KVCache 的容量挑战
KVCache 在提升性能的同时也带来存储压力。以 Qwen2-7B 模型为例，在千级 QPS、平均 1K 输入的在线服务中，叠加多轮对话与 Prefix Caching 需求，KVCache 总量随时间呈线性增长，从秒级 GB 膨胀至天级 PB，远超本地显存或内存承载能力。
关键洞察在于：“以存代算”。当序列长度超过阈值，从存储介质加载已缓存 KV 的延迟低于 GPU 重算 Prefill。这为 KVCache Offloading 提供理论依据——将低频访问的 KV 状态卸载至主机内存或远端分布式存储（如 3FS），既能突破容量瓶颈，又能控制延迟。
该策略为长上下文、高并发 LLM 推理提供了兼顾吞吐、延迟与成本的可扩展路径。
1.3 爆发的长文本：Agentic Inference 的兴起
据 OpenRouter 报告指出，LLM 应用正经历根本性转变：从单轮补全转向多步骤、工具集成、强推理驱动的工作流，即“智能体式推理”（Agentic Inference）。其核心特征包括上下文长度激增及编程类应用推动复杂性上升。
1.3.1 上下文窗口极大延长（Long Context Explosion）
AI Agent 需记忆长期、跨轮次、多任务上下文，如多轮工具调用 trace、用户行为日志、多文档协同分析或多智能体协作中的共享记忆。上下文长度从数百~数千 tokens 扩展至数万乃至百万级别，导致 KVCache 显存占用迅速逼近硬件极限。
1.3.2 编程类应用场景
编程类 Agent 通常运行“思考-行动-观察”循环，每轮新增少量 token，但需保留全部历史 KV 以维持状态一致性。传统 KVCache 生命周期限于单次请求，而在 Agent 场景下需跨越整个会话甚至数小时，要求支持持久驻留与增量追加。
此类交互接近“人–人”对话节奏，用户对延迟敏感（目标 <500ms）。无 KVCache 时每步计算复杂度为 O(n²)，有 KVCache 可降至 O(n)，对超长上下文至关重要。同时，避免重复计算也成为降本关键。
一个 Agent 实例常需并发处理多个用户或子任务，不同任务可能共享部分上下文（如同一用户的 profile、共享 prompt template 或 system instruction），亟需 KVCache 共享机制（如 prefix caching、cross-request reuse）以减少重复计算与内存占用。
1.4 突破显存墙：Hierarchical KVCache（HiCache）的破解之道
针对智能体式推理面临的上下文延长、持续交互、多任务并发与实时性提升等挑战，SGLang HiCache 构建了分级（Hierarchical）KVCache 管理体系，整合 GPU 显存、主机内存、本地磁盘与远端分布式存储（如 3FS），形成统一缓存层次结构。
通过热度感知调度与异步预取机制，HiCache 在显存中保留高频访问的“热”数据，将“冷”数据透明卸载至下层存储，并在请求前预加载回显存参与计算。该设计使推理系统突破单机物理边界，近乎线性扩展有效缓存容量，充分释放“以存代算”潜力。
高性能底层存储系统是实现高效 Offloading 的基础。DeepSeek 开源的 3FS（Fire-Flyer File System）专为 AI 训推场景设计，具备以下特性：
- 存算分离架构：计算与存储解耦，便于独立扩展；
- 极致吞吐性能：结合 RDMA 与 NVMe SSD，在 180 节点集群中可达 6.6 TiB/s 读取带宽；
- 强一致性保障：基于 CRAQ 链式复制协议，兼顾一致性与高可用；
- 灵活接口：提供 POSIX 兼容 FUSE 客户端与高性能 USRBIO 接口，兼顾易用性与性能。
Tair KVCache 团队将 3FS 集成至 SGLang HiCache，为 KVCache 提供高带宽、低延迟的 Offloading 通道，并实现跨节点全局缓存复用。
二、从“复用”到“分层”的演进：SGLang PrefixCache 介绍
2.1 Prefix RadixTree：前缀复用的艺术
在 LLM 推理中，重复计算相同前缀造成巨大浪费。例如，阿里云企业级 AI 助手中所有请求均以相同系统提示词开头（可达上千 tokens），传统 KVCache 按请求独立管理，导致大量冗余 Prefill 计算。
SGLang 的 RadixTree 正为解决此问题而设计。RadixTree 是一种高效前缀检索数据结构，用于索引已缓存的 token 序列。新请求到达时，系统查找最长公共前缀，复用对应 KVCache，仅对新增部分执行 Prefill。
该优化在以下场景尤为显著：
- 共享系统提示词：大量请求复用相同 System Prompt；
- 多轮对话：后续轮次天然共享历史上下文；
- AI 编程：代码补全中同一文件多次请求共享大量上下文。
通过前缀复用，RadixTree 可将 Prefill 阶段计算量降低数倍至数十倍，显著提升吞吐并降低 TTFT。
2.2 HIRadixTree：突破显存边界的分层缓存
RadixTree 解决了“如何复用”，但未解决“能缓存多少”——仍受限于 GPU 显存容量。随着 Agentic AI、长文档问答等任务发展，上下文持续增长，缓存容量直接影响命中率、吞吐与延迟。
SGLang 设计并实现 HIRadixTree（简称 HiCache），构建三层存储架构：
核心机制包括：
- 自动卸载（Offload）：根据热度将 KV 异步卸载至 CPU 内存，进一步持久化至本地或远程存储（如 3FS）；
- 智能预取（Prefetch）：请求命中远端缓存时，异步预取至 GPU 显存，隐藏 I/O 延迟；
- 热度感知驱逐（Eviction）：结合 LRU 等策略，优先保留“热”数据于显存，最大化命中率。
通过该设计，40GB 显存 GPU 可借助 CPU 内存扩展至 200GB+ 有效容量，结合存储层支持 TB 级缓存。HiCache 在保持 RadixTree 高效检索能力的同时，实现近乎无限的 KVCache 扩展，支撑长上下文、高并发推理。
三、如何让远端存储像本地显存一样快：HiCache 架构详解
3.1 系统架构设计
- HiRadixTree：GPU/CPU 双层前缀缓存树，原生支持 KVCache 自动同步；
- Storage Backend：可插拔存储后端抽象层，已集成 3FS、Mooncake、NIXL，支持 batch_get / batch_set / batch_exists，兼容零拷贝传输；
- Global KVManager：提供分布式文件系统的元数据统一管理，确保全局一致性；
- 3FS Global Storage：DeepSeek 开源高性能分布式文件系统，采用存算分离 + RDMA + NVMe SSD，提供 TiB/s 级聚合读带宽，作为持久化存储底座。
3.2 KVCache 流水线预取与计算重叠
HiCache 通过三层存储与异步流水线实现两大优化：
1. 预取与等待并行：
- 请求入队即触发 prefetch_from_storage，后台线程在排队期间异步加载 KV 至 Host 内存，利用空闲时间；
- Scheduler 支持多种调度策略：
- Best_effort：尽力而为，prefetch 中断后立即调度；
- Timeout：超时则中断，否则跳过本轮调度；
- Wait_complete：必须完成 prefetch 才进入推理。
2. 加载与计算 Overlap：
- Host → GPU 加载通过独立 CUDA Stream 逐层进行（load_to_device_per_layer）；
- 模型可在第 i 层 KV 就绪后立即开始计算，无需等待全部加载完成，实现流水线重叠。
该设计将阻塞 I/O 隐藏于调度与计算中，在扩展容量的同时最小化对 TTFT 的影响。
3.3 基于 Page/Layer 布局变换的零拷贝传输
HiCache 采用零拷贝技术实现高效跨层传输：
- 远端存储按 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, ...]），便于按层访问；
- Page-first 布局避免了传统 Layer-first 下的数据重组拷贝，可直接写入/读取存储。
传输路径：
- Storage → Host：Page-wise 粒度，通过 3FS libusrbio 用户态 I/O 库直写 Host KV Pool，绕过内核缓冲；
- Host → GPU：Layer-wise 粒度，通过独立 CUDA Stream 逐层传输，实现计算与传输重叠；
- Page-first 在 Host 层充当“桥梁”，一次布局转换换取全程零拷贝收益。
3.4 Prefill 与 Decode 分离架构的集成
SGLang PD（Prefill/Decode）分离架构已与 HiCache 无缝集成，KVCache 全生命周期管理如下：
- 高速直传：Prefill 与 Decode 节点通过 GDR（GPU Direct RDMA）实现 KVCache 零拷贝传输；
- Prefill 跨实例复用：Prefill 启用 HiCache，支持异步 Offload、Prefetch 及跨实例复用；
- Decode 节点轻量控制：默认关闭 HiCache，新增
DecodeOffloadManager组件负责异步卸载；Prefill 节点可复用 Decode 已生成的 KVCache，避免重复计算，实现与非分离部署同等性能。
性能实战 (3FS Backend)
四、后续工作预告
4.1 HiCache Roadmap
4.1.1 Roadmap
SGLang HiCache 持续演进方向：
- 深度集成 EPD 架构：支持 Embedding Node 与 Prefill Node 间通过 HiCache 高效传输 Embedding Cache；
- 支持 Sparse Attention：适配 DeepSeekV32 等模型；
- 支持 Hybrid 模型：适配 Mamba、SWA 等混合架构；
- 更智能调度策略：基于 band usage、error_rate 等指标动态调控 backup/prefetch 速率；
- 完善可观测性体系：提供细粒度监控与诊断能力。
4.1.2 Hierarchical Sparse Attention
稀疏注意力（Sparse Attention）通过仅选取关键 token 参与计算，显著降低长文本推理开销。但现有方案仍需在显存保留全量 KVCache，显存瓶颈犹存。
SGLang 正构建分层稀疏注意力框架，结合 HiCache 实现 KVCache 分层卸载与按需加载，仅在 GPU 保留 Topk KVCache，突破显存限制，提升 Batch Size 与系统吞吐。
4.2 3FS 产品化方案
3FS 面向 AI 场景设计，其部署需兼顾易用性、高可用与弹性扩展。阿里云开源的 3FS Operator 提供云原生解决方案：
- 声明式部署与容器化管理：基于 Kubernetes CRD 实现 3FS 集群容器化部署，支持物理机、ACK 等多种环境；
- 无感知存储接入：通过 Webhook 动态注入 Fuse Client 容器，对业务透明；
- 故障自愈与弹性扩缩容：Operator 监控状态，自动替换故障副本，支持滚动升级；通过 Headless Service + DNS 解决 Mgmtd IP 变化问题；
- 租户资源隔离：支持在同一 Kubernetes 集群部署多套 3FS，结合 VPC 与安全组实现网络隔离。
4.3 Hybrid Models Support
混合架构模型（全注意力 + 线性注意力）在长上下文场景加速普及。SGLang 通过创新内存管理与调度机制，在降低显存占用与延迟的同时保持推理能力：
- 分层内存架构：隔离管理 KVCache（Token 粒度）与 SSM 状态（请求粒度），支持预定义缓存池比例；
- 弹性显存调度：基于 CUDA 虚拟内存实现双池动态伸缩，最大化资源利用率；
- 混合前缀缓存：扩展 RadixTree 支持 KV/SSM 双缓存生命周期管理，实现无算子修改的复用与淘汰；
- 推测解码适配：通过状态快照槽位兼容 EAGLE-Tree 等加速方案，支持 Top-K >1；
- PD 架构扩展：新增独立状态传输通道，简化新型混合模型集成。
4.4 Tair KVCache Manager
面对多样推理引擎与存储系统，Tair KVCache Manager 提供统一全局 KVCache 管理服务：
- 实现 KVCache 跨机复用，提供全局外部缓存管理能力；
- 支持 SGLang、vLLM、RTP-LLM、TensorRT-LLM 等主流推理引擎接入；
- 封装 3FS 等异构存储系统，降低接入复杂度；
- 提供多租户 Quota 管理、高可靠、可观测等企业级能力；
- 内置算力与缓存仿真能力，基于真实业务 Trace 计算命中率与算力节约量，并提供配置寻优功能，助力用户实现最佳 ROI。