即将开源 | 阿里云Tair KVCache Manager：企业级全局 KVCache 管理服务的架构设计与实现
阿
Tair KVCache团队约 22 分钟
Tair KVCache团队约 22 分钟【重磅】 阿里云 Tair KVCache 团队联合阿里巴巴智能引擎、基础设施与稳定性工程团队 即将开源企业级全局 KVCache 管理服务 Tair KVCache Manager ，本文详细介绍该服务的架构设计与实现细节。 随着 Agentic AI 兴起，以推理引擎为中心的传统单机分层方案已无法满足新时代的 KVCache 存储需求。随着 KVCache 池化存储在大规模 Agent 推理场景中走向落地，需要构建具备容量精准评估、动态弹性伸缩、多租户隔离、高可用保障及版本协同管理能力的企业级 KVCache 管理系统，以支撑PB级存储下的成本效益优化与服务可靠性需求。为了解决这些问题，我们 设计并实现了一套专为大模型推理场景服务的全局 KVCache 管理服务， 支持了阿里巴巴集团 RTP-LLM [1]推理服务加速 ，并且扩展支持到 vLLM、SGLang 等众多开源引擎，兼容 Sparse Attention 、 Sliding Window Attention 等 在内的 多种注意力机制 [2]。 本文将从Agent场景下的KVCache存储需求出发，在之前文章的基础上进一步分析该场景下KVCache存储所面对的挑战，并介绍Tair KVCache Manager针对这些挑战所做的架构设计选择和相关实现。 本系列技术文章将系统性拆解面向智能体推理的 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 基础设施层的核心能力 ——让“状态”可存储、可共享、可调度，支撑智能体时代的规模化推理底座。KVCache服务的三重升级挑战 Agent兴起重塑KVCache存储范式 Agent 的兴起不仅拉长了推理会话上下文，也让会话模式发生了明显变化。这些变化对传统单机分层+亲和性调度方案提出了严峻挑战： 1. 单个会话的轮数和持续时间不断增加： 相较于传统短时间、低频的交互模式（如单轮或少数几轮即结束的请求），Agent 会话往往贯穿任务全生命周期，包含多轮推理请求，持续时间显著延长。这种“长生命周期”特性使得调度对象事实上从“请求”转变为“会话”（虽然可能仍以请求为粒度进行调度），调度器需在数十分钟甚至更长的时间窗口内努力维持 KVCache 和计算的亲和性。 2. 并发会话数进一步提升： 随着 Vibe Coding 等范式普及，以及高延迟工具和复杂 MCP（如代码编译执行、数仓查询等）的广泛集成，单个 Agent 会话中 LLM 推理时长占比持续下降，等待非推理环节的时间显著增加。为维持推理集群的高利用率，系统需要更多并发会话以“填满”算力间隙。这也显著增加了调度器的调度难度。 3. 会话间的模式差异扩大： 不同 Agent 任务在上下文规模、推理频次、工具调用模式和延迟敏感度上差异显著（例如，一个代码评审Agent可能频繁小轮次交互，而数据分析Agent则倾向少轮次、大上下文推理），导致固定的算力和存储配比难以满足不同场景的差异化需求。 以上几点导致传统模式下调度难度不断增大，KVCache命中率和算力SLO调度目标的冲突日益尖锐。例如当请求量升高时，调度器需要进行更多的会话迁移以保证SLO，进而导致 KVCache 命中率下降；这又会进一步推高 Prefill 算力需求，导致 Prefill负载非线性增长 甚至雪崩。 这也使得单机分层方案虽然打破VRAM的限制，进一步扩展了KVCache容量，但却依然难以完全满足Agent场景下的KVCache存储需求。为了进一步解决该问题，我们需要直面该架构下的根本问题： 算力资源与KVCache存储的过紧耦合 。
- TP/PP并行下多推理进程会同时读/写同一Block对应的KVCache的不同部分（比如不同的head）;
- 不同部分生命周期绑定，使用时缺一不可。
在这样的背景下， 阿里云 Tair 与阿里巴巴智能引擎、基础设施与稳定性工程团队 联合共建了面向大模型KVCache的企业级管理服务产品Tair KVCache Manager（以下简称Tair KVCM）。 系统通过以下设计解决上述问题： 1. 中心化管理KVCache元数据信息，实现跨推理实例的全局KVCache池化共享。显著提升Agent等长上下文场景下的推理性能。 2. 对LLM KVCache语义进行合理抽象，解耦推理引擎和存储系统。简化接入难度的同时为存储系统保留充足的优化空间。 3. 设计之初便考虑到大规模部署的需求，提供覆盖KVCache全生命周期的企业级管理能力，如：模型上线前的ROI评估和高收益场景筛选，模型在线服务过程中的可观测和高可用等等。 最终实现在保持低成本的同时，显著减少GPU计算资源消耗，提升推理在线服务质量。 文章后续部分将对系统中的基本概念和架构设计做详细介绍。 系统基本概念
管控面概念
- 有独立的存储配置（连接地址等等）
- 支持多种不同存储类型，如NFS、3FS、TairMemPool、Mooncake等
- 允许不同的Instance Group和Instance共享同一Storage
- 同Group内所有Instance共享一套配额
- 每个Group可以单独配置可用的Storage列表
- 常见用途：
- 对应一个业务团队，团队内的多个模型共享存储配额
- 对应一个模型，模型的多个版本共享存储配额
- 为重要模型单独配置Instance Group，保证独占存储资源
- 多个长尾模型共用一个Instance Group，共享存储资源的同时满足个别模型的突发容量需求
- 仅单个Instance内部会复用KVCache（需要互相复用KVCache的推理实例应当配置为使用同一个Instance）。跨Instance不复用KVCache。
- 对应的模型和KVCache配置（比如fp8/bf16，block_size等）唯一且不变
- 属于且仅属于一个Instance Group。
- 无需单独配置容量配额，使用所属的Instance Group的配额。
数据面概念
- 单个block的对应token ids数量在Instance初始化时指定。用户传入的token id序列会被切分为多个block。
- 有前缀依赖关系。自身Token序列相同但前缀不一致的两个block是不同的。
- 每个block可以有多个CacheLocation：对应多个存储位置/层级。
- 单个CacheLocation内的所有数据必须全部位于同一种存储类型（type）。
- 状态：writing-》serving-》deleting
- writing：KVCache正在写入，不可服务。暂时无需再次写入。
- serving：已写入完成，可正常读取。
- deleting：正在删除中，不可读取。
- 组织存储位置格式统一为URI，但允许不同表达方式：
- 对于内存池可能是地址。对于文件系统可能是文件路径。对于KV存储可能是Key。
- 统一了格式，同时避免了强制映射到地址偏移或KV等导致的底层位置语义错位。
- 在uri中记录size以简化容量统计。
- 通过blkid+size支持单个存储位置（如单个3fs文件）内的分块存储。
- spec name允许用户配置：灵活支持不同的TP、PP、混合注意力。
- 允许Location内仅有部分Spec：混合注意力场景下很多block不需要存储线性注意力
- 管理接口：
- Storage、Instance Group、Instance等对象的CRUD接口；
- Account相关API用于权限管理控制；
- Metrics相关API用于系统可观测性功能；
-
元数据接口：
- RegisterInstance：用于从元数据面创建Instance，简化推理接入流程；
- 元数据相关主要API：
- GetCacheLocation：获取KVCache是否命中及存储位置；
- startWriteCache：请求需要写入的KVCache及目标写入位置并通知KVCM开始写入；
- finishWriteCache：上报写入完成；
- removeCache&trimCache：KVCache数据修剪和删除；
- API参数设计：
- 支持block_keys和token_ids两种模式，兼容多种推理引擎的同时方便周边系统查询；
- 主要接口均携带完整的前缀信息以便维护前缀元数据；
Manager
接入层（Server）
1. 同时提供http和grpc接口，方便不同推理引擎接入。 2. 依托C++下的RDMA生态，如果有极低延迟需求，也可实现RDMA甚至GPU Direct接入。读写模块（CacheManager）
1. 多种匹配模式支持。推理引擎读取KVCache元数据时，支持多种匹配模式：- KV式匹配：给定若干key，直接返回对应元数据；
- 前缀式匹配：给定若干key，仅返回符合前缀顺序的元数据。这种匹配模式是推理引擎读取时的主要模式，vLLM/SGLang均支持按前缀复用KV Cache；
- 滑动窗口式匹配：给定若干key和窗口长度，仅返回最近窗口长度内的元数据。对于使用滑动窗口机制的KVCache模式，这种匹配方式有更高的性能；
- 写入前调用 StartWriteCache 接口从Tair KVCM获取元信息，本地调用不同存储后端的sdk进行写入。正在写入的cache key会被标记为 writing 状态，在指定超时时间内等待推理引起写入完成，保证相同key无法同时写入；
- 写入后调用 FinishWriteCache 接口通知Tair KVCM写入完成，服务端将对应写入成功的key标记为serving状态，同时删除写入失败的key。
- Tair KVCM支持多种存储后端（详见下面「存储管理」部分），支持动态切换不同存储后端进行读写，提高可用性；
- 由于KVCM能同时对接多种存储后端，对于推理引擎来说可以方便地按需求将数据存储至不同的后端。例如将热数据存储到TairMemPool，将冷数据存储到3FS。同时也能保证某个后端挂掉时，cache服务依然处于可用状态。
存储管理（DataStorage）
1. 兼容多种存储系统- 不同的存储系统有独立的存储配置。
- 支持3FS、TairMemPool、Mooncake、NFS等多种存储系统，同一个Storage可以被不同的InstanceGroup和Instance共享。
- 存储位置格式统一为Uri，并支持不同表达方式：内存池是地址、文件系统是路径等。
- 所有存储系统均通过统一的 DataStorageBackend 抽象接口接入，确保上层逻辑无需感知底层差异。 解耦性与扩展性较强，上层只需传递Uri，新增存储类型只需实现接口，无需修改核心逻辑。
- GetAvailableStorage进行探活检查，健康检查在后台周期性进行以提升性能，并返回所有可用存储实例，提高可用性。
- 支持不同后端存储的动态生命周期管理，RegisterStorage、UnRegisterStorage对存储实例注册与注销。
- EnableStorage、DisableStoarge动态开启或关闭某个存储实例的可用状态。
- Create、Delete、Exist用于存储实例空间的开辟、释放及有效性的判断。
- 针对无元数据管理能力或元数据性能有限的存储系统NFS和3FS，提供block分配能力（分配少量大文件，切成小块使用）。
索引管理（ MetaIndex ）
1. 使用KV系统存储元数据- KV系统易于获取且生态成熟，开源社区和云服务市场提供了大量高可用、高性能的KV存储解决方案，可拓展性和可用性高。如Valkey、Redis等以内存为主、支持持久化的高性能KV引擎，如基于LSM-Tree结构的Rocksdb，适合写密集型负载。
- 在项目早期阶段，团队资源有限，直接使用外部高可用与持久化的能力，能够有效降低初期系统复杂度和开发成本。
- 元数据同样适用KV存储，与上层Cache的KV语义统一，方便对外接口的设计和实现
- 支持针对KV Cache元数据的Put、Delete、Update、Get接口，对外提供增删改查能力。
- 支持ReadModifyWrite接口，提供可自定义Modifier的线程安全更新。
- 在高并发场景下，如多个推理请求同时更新同一模型的KV Cache元数据信息，简单的读改写容易产生状态不一致的问题，故MetaIndex提供了原生支持的读改写原子操作接口。
- ReadModifyWrite(keys, ModifierFunc)，外部可以通过自定义ModifierFunc函数处理增改删三种操作，提供了灵活且线程安全的读改写能力。
- 该接口内将对指定keys加分片锁，查询keys，用户通过自定义ModifierFunc函数，基于查询结果指定删除、修改和写入操作，最后由MetaIndex验证并执行相应操作。
- 支持Scan、RandomSample接口，支持获取存储和缓存容量等接口
- 随着缓存规模增长，系统必须具备对Instance粒度的元数据存储实施有效的容量管理（如 LRU逐出），为这些容量管理的逐出策略提供相关数据信息并指定已逐出的key。
- 使用LRU Cache作为元数据存储的search cache，减少查询I/O，降低高命中场景下的延迟。
- SearchCache位于数据访问逻辑之上，查询Value时都会优先尝试本地的LRU Cache，如果存在Cache，将不会参与后续包含I/O开销的查询
- 新的KV查询，将查询结果插入到SearchCache中；所有写操作（如Put、Delete、Update）在成功提交到底层存储后，会同步失效对应缓存项
- 可以配置LRU Cache参数，调节Search Cache能力，如Cache大小、Cache Shard数量
- 支持配置分片锁和分批操作，提供高性能和高并发的服务能力
- 在多线程环境下，元数据操作必须保证强线程安全。然而，全局锁会成为性能瓶颈，而完全无锁又难以实现复杂Read-Modify-Write语义。为此，系统采用分片锁（Sharded Locking）+批处理对齐的混合策略。
- 分片锁：将key空间按哈希划分为N个分片（N需配置为2的幂次方的倍数），每个分片维护独立的锁，操作某key时仅需要锁定其所属分片即可。注意，为了提高查询性能，查询操作不加锁也不会被锁阻塞。
- 分批操作与锁粒度对齐：MetaIndex的对外接口均接受批处理操作，为了避免死锁，加锁需要按锁分片粒度升序排序依次加锁。同时，为了避免大批次的操作长期阻塞其他小批次操作，我们需要进行分批，将大批次keys分为若干小批次操作，小批次之间的锁分片互不相交，执行完一小批则释放其分片锁，其批次大小受batch_size和锁shard_count两个配置共同影响。这种按锁粒度自适应对齐批次大小进行增删改的能力，使得MetaIndex能够针对不同业务特点通过配置参数实现高并发能力和单批操作吞吐之间的trade-off调控。
- 底层存储支持灵活扩展，目前已支持本地存储和远端Valkey/Redis存储
容量管理（Reclaimer & Executor）
-
Instance Group维度：
- Quota配置：
- Instance Group可配置一个总Quota，以及针对每种存储类型配置一个Quota。例如：总Quota = 100T，TairMemPool Quota = 1T，3FS Quota = 99T。
-
Quota配置用于Instance Group的存储容量的硬上限控制：若某个Instance Group的总用量超出配置的总Quota上限，则KVCM将停止为该Instance Group分配写入地址；若Instance Group下的某种存储类型的用量超过对应的Quota上限，则KVCM将停止为该Instance Group往该种类型的存储后端分配写入地址，转而尝试其他类型的可用存储后端。
- 通过控制总用量和分存储类型用量上限，可更明确管理Instance Group下的KVCach e数据的存储 使用意图。
-
水位配置：
- Instance Group的配置中还包含了逐出策略，其中一个重要控制项是用量水位配置，以浮点数百分比表示。当某个Instance Group的用量达到指定水位，则KVCM将开始触发逐出动作，尝试将用量控制在该水位以下。
- 逐出水位配置相当于存储容量的软上限控制：若Instance Group针对某一种Storage Type的用量超过配置的水位，KVCM将开始触发针对该 Instance Group的限于特定Storage Type的逐出；若Instance Group的整体水位超出，则可能触发该Instance Group的所有Storage Type的逐出。
- 用量水位以及逐出策略控制是存储后端整体用量管理和提前规划的重要手段，使KVCache数据存储池化大规模部署的整个服务生命周期可持续。
- 存储后端容量维度：
- 后续还将支持为每个具体的存储后端实例单独配置容量管理策略，当某个存储后端的总用量达到上限时停止写入，达到逐出水位时按一定的算法逐出数据，可与Instance Group的容量管理结合，更进一步确保存储后端的水位安全。
Optimizer
Optimizer 模块是一个专为 LLM 推理系统设计的缓存策略优化分析工具，通过高效模拟重放真实 Trace 数据来深度分析 KVCache 命中率和存储容量消耗模式，并通过分析结果来优化指导 Manager 的容量管理。 该模块构建了基于 Radix Tree 的前缀匹配索引，支持包括 Tair KVCM event 在内的多种格式的真实访问 Trace 数据解析与转换，能够精确模拟 LRU、Random-LRU 等不同驱逐策略下的读写访问模式，不仅计算分析不同容量配置对缓存命中率的影响，还能够深入分析每个 block 的访问时间局部性、访问频率分布等关键指标。模块支持通过参数遍历与重放循环，自动寻找最优存储参数配置，实现存储成本与性能的最佳权衡。同时，模块内置了灵活的缓存层级配置和统一的驱逐策略接口，既支持单一缓存层的精细化分析，也为多层级缓存架构的协同优化预留了扩展接口。 通过统一的 Trace 数据结构和高效的 Trace 处理机制，Optimizer 模块能够准确还原真实业务场景下的缓存行为，提供稳定且快速的性能分析。效果 如图所示，图1的动 态分析能够实时追踪缓存容量使用与命中率的协同变化；而图2清晰描绘了不同驱逐策略在不同缓存容量配置下的 KVCache 命中率收益，从而测试不同驱逐策略的性能变化以及指导最优容量配置。- 线下私有环境：线下环境自持主机使得KVCM在命中率以外出现了更多的优化目标。需要为该类场景设计更多针对性的逐出算法来进行优化。
- 超节点：该类系统中GPU通过ScaleUp网络访问内存池的带宽已经大于通过PCIE访问CPU内存的带宽，对用于存储KVCache的内存进行统一池化管理顺理成章。我们将协助实现超节点内KVCache的存储管理，充分发挥超节点的性能优势。