Tair KVCache 架构与设计深度分析

Tair KVCache 是阿里云面向大语言模型（LLM）推理场景打造的高性能 KVCache 系统，本文深入分析其核心组件 Tair KVCache Manager（简称 Tair KVCM）的架构设计、技术实现和工程实践。随着 Agentic AI 兴起，传统单机分层方案已无法满足新时代的 KVCache 存储需求。Tair KVCache 作为阿里云数据库 Tair 产品能力的延伸，本质上实现了缓存范式的三次跃迁：从 Redis 的“缓存数据 → 减少 I/O”，到 GPU KVCache 的“缓存计算中间态 → 减少重复计算”，再到 Tair KVCache 的“规模化、智能化的注意力状态管理 → 重构大模型推理成本模型”。

1. 项目概述与整体架构

Tair KVCache 是阿里巴巴云面向大语言模型（LLM）推理场景打造的高性能 KVCache 系统。该系统通过 分布式内存池化 和 动态多级缓存 等核心技术，在显著提升推理效率的同时有效降低资源成本。随着 Agentic AI 的兴起，传统的单机分层方案已无法满足新时代的 KVCache 存储需求，特别是在单个会话的轮数和持续时间不断增加、并发会话数提升、会话间模式差异扩大等挑战下，需要构建具备 容量精准评估、动态弹性伸缩、多租户隔离、高可用保障 及 版本协同管理 能力的企业级 KVCache 管理系统。作为系统的核心组件，Tair KVCache Manager 已经开源，为 LLM 推理场景提供统一的 KVCache 元数据管理服务，支持了阿里巴巴集团 RTP-LLM 推理服务加速，并扩展支持到 vLLM、SGLang 等众多开源引擎，兼容 Sparse Attention、Sliding Window Attention 等在内的多种注意力机制。

从整体架构来看，Tair KVCache 采用分层设计模式，主要由两个核心组件构成：Tair KVCache Manager 作为管理中心采用 中心化部署 负责全局元数据管理，而 Tair KVCache Client/Connector 则专注于与各类推理引擎的对接集成。Tair KVCM 以中心化模式部署，由于仅负责 KVCache 的元数据管理，结合 C++ 作为开发语言，依靠 scale up 就可以满足单一推理集群的需求。同时 instance group 的抽象使得使用同一存储的不同 group 也可以很轻松地进行拆分，横向 scale out 以服务不同推理集群。中心化模式使得运维部署大幅简化，同时也避免了将 KVCM 逻辑注入推理容器，规避了可能导致的元数据存储后端（如 Valkey）连接数爆炸等问题。Manager 端 通过精心设计的分层架构实现了功能的清晰划分和高效协作。

┌─────────────────────────────────────────────────────────────┐
│                    Tair KVCache Manager                     │
├─────────────────────────────────────────────────────────────┤
│  Access Layer (Server)  │  Cache Logic (CacheManager)       │
│  - HTTP/gRPC Services   │  - 核心业务逻辑实现                  │
│  - 接口协议处理           │  - 多种匹配逻辑                     │
├─────────────────────────┼───────────────────────────────────┤
│  Storage Management     │  Index Management (MetaIndex)     │
│  (DataStorage)          │  - 元数据持久化                     │
│  - 多存储后端管理         │  - 统一查询控制                     │
│  - 存储状态监控           │  - 批量处理优化                     │
├─────────────────────────┼───────────────────────────────────┤
│  Capacity Management    │  Cache Optimization (Optimizer)   │
│  (Reclaimer & Executor) │  - Trace 回放模拟                  │
│  - 容量控制策略           │  - 驱逐策略分析                     │
│  - 异步删除机制           │  - 性能预测优化                     │
└─────────────────────────────────────────────────────────────┘

1.1 访问层 (Access Layer)

在访问层，系统提供统一的服务接口并同时支持 HTTP 和 gRPC 两种主流协议。MetaService 处理缓存位置查询、实例注册等基础操作，AdminService 负责存储配置、实例组管理及系统监控，而 DebugService 则为集群内部状态的直接操作提供调试支持。为方便隔离，Tair KVCM 对元数据面和管控面做了分离，管控面提供 Storage、Instance Group、Instance 等对象的 CRUD 接口、Account 相关 API 用于权限管理控制、Metrics 相关 API 用于系统可观测性功能；元数据面提供 RegisterInstance 接口用于从元数据面创建 Instance 以简化推理接入流程，以及 GetCacheLocation（获取 KVCache 是否命中及存储位置）、startWriteCache（请求需要写入的 KVCache 及目标写入位置并通知 KVCM 开始写入）、finishWriteCache（上报写入完成）、removeCache&trimCache（KVCache 数据修剪和删除）等核心 API。API 参数设计支持 block_keys 和 token_ids 两种模式，兼容多种推理引擎的同时方便周边系统查询；主要接口均携带完整的前缀信息以便维护前缀元数据。这一层的关键特性包括多端口监听机制（主服务的 RPC 端口和 HTTP 端口，以及管理接口的专用端口）、线程池管理的 IO 服务以及完善的健康检查和集群状态监控功能。

源码实现分析：访问层在 Server 类中实现了多协议支持架构。Server 类维护了多个服务实例，包括 MetaServiceGRpc、AdminServiceGRpc、DebugServiceGRpc 以及相应的 HTTP 服务实现。通过 StartRpcServer() 和 StartHttpServer() 方法分别启动 gRPC 和 HTTP 服务。核心的 MetaServiceImpl 实现了 GetCacheLocation、StartWriteCache 等核心接口，这些接口直接调用 CacheManager 的相应方法来处理业务逻辑。

1.2 缓存逻辑层 (Cache Logic Layer)

缓存逻辑层 作为系统的核心业务引擎，实现了复杂的外部接口和核心功能。该层不仅支持 前缀匹配、滑动窗口匹配 和 KV 匹配 等多种查询逻辑:

KV 式匹配：给定若干 key，直接返回对应元数据
前缀式匹配：给定若干 key，仅返回符合前缀顺序的元数据。这种匹配模式是推理引擎读取时的主要模式，vLLM/SGLang 均支持按前缀复用 KV Cache
滑动窗口式匹配：给定若干 key 和窗口长度，仅返回最近窗口长度内的元数据。对于使用滑动窗口机制的 KVCache 模式，这种匹配方式有更高的性能

更重要的是采用了创新的 两阶段写入机制 来确保数据可靠性:

第一阶段：写入前调用 StartWriteCache 接口从 Tair KVCM 获取元信息，本地调用不同存储后端的 SDK 进行写入。正在写入的 cache key 会被标记为 writing 状态，在指定超时时间内等待推理引起写入完成，保证相同 key 无法同时写入
第二阶段：写入后调用 FinishWriteCache 接口通知 Tair KVCM 写入完成，服务端将对应写入成功的 key 标记为 serving 状态，同时删除写入失败的 key

该机制通过 WriteLocationManager 组件实现，使用超时队列管理写入会话，确保写入操作的原子性和可靠性。

同时，系统能够基于存储后端的实时可用性等关键指标动态选择最优的存储策略配置，并提供高可用读写支持：Tair KVCM 支持多种存储后端，支持动态切换不同存储后端进行读写，提高可用性；由于 KVCM 能同时对接多种存储后端，对于推理引擎来说可以方便地按需求将数据存储至不同的后端。例如将热数据存储到 TairMemPool，将冷数据存储到 3FS。同时也能保证某个后端挂掉时，cache 服务依然处于可用状态。

源码实现分析：缓存逻辑层的核心实现在 CacheManager 类中。该类定义了 QueryType 枚举来区分不同的查询类型，包括 QT_BATCH_GET、QT_PREFIX_MATCH 和 QT_REVERSE_ROLL_SW_MATCH。GetCacheLocation 方法根据查询类型调用相应的匹配逻辑。两阶段写入机制通过 StartWriteCache 和 FinishWriteCache 方法实现，其中 WriteLocationManager 负责管理写入过程中的状态转换（writing → serving）。DataStorageSelector 负责根据存储后端的实时可用性动态选择最优的存储策略。

1.3 存储管理层 (Storage Management Layer)

存储管理层 负责统筹管理多种异构存储后端，包括 3FS、TairMemPool、Mooncake、NFS 等多种存储系统。TairMemPool 是阿里云 Tair 团队与服务器研发定制计算与芯片系统团队联合打造的高性能 KVCache 内存池方案，该方案通过软硬件协同优化，实现多节点内存统一寻址与全局访问能力，支持多介质/协议接入及 KVCache 专用传输优化，在多网卡环境下网络带宽利用率超 90%，兼具企业级高可用特性，为 TairKVCache 系统提供高可靠存储支撑。存储位置格式统一为 Uri，并支持不同表达方式：内存池是地址、文件系统是路径等。所有存储系统均通过统一的 DataStorageBackend 抽象接口接入，确保上层逻辑无需感知底层差异。解耦性与扩展性较强，上层只需传递 Uri，新增存储类型只需实现接口，无需修改核心逻辑。DataStorageManager 进行多种存储系统的统一管理:

GetAvailableStorage 进行探活检查，健康检查在后台周期性进行以提升性能，并返回所有可用存储实例，提高可用性
支持不同后端存储的动态生命周期管理，RegisterStorage、UnRegisterStorage 对存储实例注册与注销
EnableStorage、DisableStorage 动态开启或关闭某个存储实例的可用状态
Create、Delete、Exist 用于存储实例空间的开辟、释放及有效性的判断

此外，针对无元数据管理能力或元数据性能有限的存储系统 NFS 和 3FS，提供 block 分配能力（分配少量大文件，切成小块使用）。通过统一的接口封装和数据位置描述，该层能够实时监控各存储后端的可用性和存储水位状态，并为上层 CacheManager 提供准确的存储状态信息。

源码实现分析：存储管理层的核心实现在 DataStorageBackend 抽象类中，定义了 Open、Close、Create、Delete、Exist 等核心接口。具体的存储实现包括 hf3fs_backend、mooncake_backend、nfs_backend 等。DataStorageManager 负责统一管理所有存储后端实例，通过 GetAvailableStorage 方法检查存储后端的可用性，RegisterStorage 和 UnRegisterStorage 方法管理存储实例的生命周期。StorageConfig 类定义了存储配置参数，支持不同类型存储的差异化配置。

1.4 索引管理层 (Index Management Layer)

索引管理层 专注于元数据的可靠性和高效访问保障。该层基于外部 KV 存储系统实现元数据持久化，确保在 KVCM 发生故障时元数据的可靠性。LLM KVCache 相较传统 KV 存储有其特殊的业务特征和存储模式:

数据间有前缀依赖性（A,C 和 B,C 中的 C 代表不同数据）
查询模式常为前缀匹配+反向滑动窗口（SWA/Linear）
单 block 内 KVCache 切分模式多样：多样的并行模式和混合注意力方案
多个推理进程同时读写单个 block，TP/PP 并行下多推理进程会同时读/写同一 Block 对应的 KVCache 的不同部分（比如不同的 head），不同部分生命周期绑定，使用时缺一不可

当前存储系统接口面向通用场景设计，直接套用抹去了 LLM 的业务语义和特征，使得底层存储系统难以针对 KVCache 特征进行更深入的优化。为解决这个问题，系统采用 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 大小（默认10000条）、Cache Shard 数量（默认16个分片）。

系统还支持配置分片锁和分批操作，提供高性能和高并发的服务能力。在多线程环境下，元数据操作必须保证强线程安全。然而，全局锁会成为性能瓶颈，而完全无锁又难以实现复杂 Read-Modify-Write 语义。为此，系统采用分片锁（Sharded Locking）+ 批处理对齐的混合策略:

分片锁：将 key 空间按哈希划分为 N 个分片（N 需配置为 2 的幂次方的倍数，默认为32个分片），每个分片维护独立的锁，操作某 key 时仅需要锁定其所属分片即可。注意，为了提高查询性能，查询操作不加锁也不会被锁阻塞
分批操作与锁粒度对齐：MetaIndex 的对外接口均接受批处理操作，为了避免死锁，加锁需要按锁分片粒度升序排序依次加锁。同时，为了避免大批次的操作长期阻塞其他小批次操作，我们需要进行分批，将大批次 keys 分为若干小批次操作，小批次之间的锁分片互不相交，执行完一小批则释放其分片锁，其批次大小受 batch_size 和锁 shard_count 两个配置共同影响。这种按锁粒度自适应对齐批次大小进行增删改的能力，使得 MetaIndex 能够针对不同业务特点通过配置参数实现高并发能力和单批操作吞吐之间的 trade-off 调控

底层存储支持灵活扩展，目前已支持本地存储和远端 Valkey/Redis 存储。通过统一控制元数据查询和更新操作，支持批量处理优化，并采用分片锁等机制确保更新操作的原子性，为整个系统提供了坚实的元数据基础。

源码实现分析：索引管理层的核心实现在 MetaIndexer 类中。该类定义了丰富的接口，包括 Put、Update、ReadModifyWrite、Delete、Get 等。ReadModifyWrite 方法接受 ModifierFunc 函数作为参数，实现线程安全的读改写操作。分片锁机制通过 mutex_shards_ 成员实现，GetShardIndex 方法根据 key 计算分片索引。MetaSearchCache 实现了 LRU 缓存机制，DoGetWithCache 方法优先从缓存获取数据，cache_ 成员管理搜索缓存。BatchMetaData 结构支持批处理操作，MakeBatches 方法将大批量操作拆分为小批次，避免长时间持有锁。

1.5 容量管理层 (Capacity Management Layer)

容量管理层 实现了智能化的缓存回收和资源控制机制。KVCM 中的容量管理分两个维度实现：

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 下的 KVCache 数据的存储使用意图。
水位配置：Instance Group 的配置中还包含了逐出策略，其中一个重要控制项是用量水位配置，以浮点数百分比表示。当某个 Instance Group 的用量达到指定水位，则 KVCM 将开始触发逐出动作，尝试将用量控制在该水位以下。逐出水位配置相当于存储容量的软上限控制：若 Instance Group 针对某一种 Storage Type 的用量超过配置的水位，KVCM 将开始触发针对该 Instance Group 的限于特定 Storage Type 的逐出；若 Instance Group 的整体水位超出，则可能触发该 Instance Group 的所有 Storage Type 的逐出。用量水位以及逐出策略控制是存储后端整体用量管理和提前规划的重要手段，使 KVCache 数据存储池化大规模部署的整个服务生命周期可持续。

存储后端容量维度：后续还将支持为每个具体的存储后端实例单独配置容量管理策略，当某个存储后端的总用量达到上限时停止写入，达到逐出水位时按一定的算法逐出数据，可与 Instance Group 的容量管理结合，更进一步确保存储后端的水位安全。

具体工程实现上，KVCM 通过将删除任务放入后台线程池等工程手段实现删除的异步执行，使得删除性能可扩展以支持较大的部署规模；同时支持 TTL、LRU、LFU 等多种常见逐出模式，可以灵活适配不同的容量管理需求；支持水位与 Quota 在 Runtime 的实时更新；支持结合 Optimizer 模块实现 Instance 级别的逐出参数动态调优；未来还将支持基于前缀的更精准的逐出能力，例如：后缀 block 先于父亲 block 逐出、混合注意力下 Linear 和 Full 的前后缀关联性逐出。该层支持多维度的容量控制策略，能够有效管理 Instance Group 等资源配额，同时通过控制后端存储水位防止资源超限。基于 Quota 和水位的驱逐策略配合 LRU 等多种算法，结合后台线程池实现的异步删除机制，确保了删除操作不会阻塞前台请求且具备良好的性能扩展性。

源码实现分析：容量管理层的核心实现在 CacheReclaimer 类中。该类负责定期检查并移除过期或使用频率较低的缓存条目，基于 LRU、LFU 和 TTL 等策略确定哪些条目需要回收。IsTriggerReclaiming 方法根据实例组的用量百分比和配额阈值判断是否触发回收操作。ReclaimByLRU、ReclaimByLFU、ReclaimByTTL 方法分别实现了不同的驱逐策略。sampling_size_ 和 batching_size_ 成员控制每次回收的样本大小和批量处理大小。ReclaimCron 方法在独立线程中运行定时回收任务，job_state_flag_ 控制任务状态。回收操作通过 SchedulePlanExecutor 异步执行，避免阻塞主线程。

1.6 缓存优化器 (Cache Optimizer)

缓存优化器（Optimizer）作为独立的分析模块，提供了强大的性能分析能力。Optimizer 模块是一个专为 LLM 推理系统 设计的 缓存策略优化分析工具，通过高效模拟重放真实 Trace 数据来深度分析 KVCache 命中率和存储容量消耗模式，并通过分析结果来优化指导 Manager 的容量管理。

该模块构建了基于 Radix Tree 的前缀匹配索引，支持包括 Tair KVCM event 在内的多种格式的真实访问 Trace 数据解析与转换，能够精确模拟 LRU、Random-LRU 等不同驱逐策略下的读写访问模式，不仅计算分析不同容量配置对缓存命中率的影响，还能够深入分析每个 block 的访问时间局部性、访问频率分布等关键指标。模块支持通过参数遍历与重放循环，自动寻找最优存储参数配置，实现存储成本与性能的最佳权衡。同时，模块内置了灵活的缓存层级配置和统一的驱逐策略接口，既支持单一缓存层的精细化分析，也为多层级缓存架构的协同优化预留了扩展接口。

通过统一的 Trace 数据结构和高效的 Trace 处理机制，Optimizer 模块能够准确还原真实业务场景下的缓存行为，提供稳定且快速的性能分析。更进一步，Optimizer 模块通过灵活的架构设计，支持与 GPU 推理性能模型（算力画像）进行深度集成，能够基于缓存命中率对 pref ill 阶段计算量的减少效果进行量化建模，将 KVCache 带来的延迟改善（如 TTFT 优化）和吞吐量提升直接映射到 GPU 资源利用效率的提升上，进而量化为 GPU 节点数量缩减和运营成本节约的具体优化建议，为智能推理系统资源调度和成本优化提供数据驱动的决策依据。

该模块能够通过 Trace 数据回放来模拟真实的缓存读写操作，支持 LRU、RandomLRU 和 LeafAwareLRU 等多种驱逐策略的模拟对比，提供缓存命中率的实时统计分析，并通过 Radix Tree 索引结构可视化等工具帮助深入理解系统行为。

源码实现分析：缓存优化器的核心实现在 OptimizerManager 类中（参考 README.md 架构描述）。OptEvictionManager 负责管理多种驱逐策略，包括 LRU、RandomLRU 和 LeafAwareLRU。OptIndexerManager 基于 Radix Tree 实现前缀匹配索引。OptimizerRunner 负责 Trace 数据的回放执行。驱逐策略接口通过统一的基类设计支持多种算法扩展，HitAnalysis 模块负责命中率统计分析。Trace 转换器支持多种格式（Publisher Log、Qwen Bailian 等），通过 TraceConverter 实现不同格式的解析和标准化。

2. 高可用与容错机制

为确保系统在生产环境中的稳定运行，Tair KVCache 实现了完善的高可用设计。

2.1 主备选举机制

系统采用基于分布式锁的主备选举机制来实现节点间的协调，通过 Redis 或 etcd 等分布式协调服务来维护集群状态。在典型的三节点部署场景中，各节点根据预设的选举策略竞争成为主节点，一旦获得锁的节点将承担主要服务职责，其他节点则作为备用节点随时准备接管服务。Tair KVCM 结合 3FS Master 等工作，可以仅使用 TCP 和推理引擎及后端存储进行交互，并不强依赖 RDMA 环境。对于 RDMA 环境内仅有 GPU 机型的场景，可以将 KVCM 部署在 RDMA 环境外的其他机型上，规避 GPU 机型故障率过高的问题。在通过 Tair KVCM 获取到 KVCache 的存储位置后，推理引擎内的 Connector 将直接读写后端存储，KVCache 数据流完全绕过 Tair KVCM，降低了 KVCache 读写延迟和对 Tair KVCM 的带宽需求。

源码实现分析：主备选举机制在 Server 类中实现，通过 LeaderElector 和 DistributedLockBackend 组件协调节点状态。CreateLeaderElector 方法创建选举器，OnBecomeLeader 和 OnNoLongerLeader 回调函数处理角色变更。kLeaderLockKey 定义了分布式锁的键名 _TAIR_KVCM_LEADER_KEY。当节点成为领导者时，它会初始化 CacheManager 并开始提供服务；当不再是领导者时，会执行清理操作 DoCleanup()。

┌─────────────────┐    ┌─────────────────┐    ┌─────────────────┐
│   Node A        │    │   Node B        │    │   Node C        │
│  (Candidate)    │    │  (Leader)       │    │  (Follower)     │
└─────────────────┘    └─────────────────┘    └─────────────────┘
         │                       │                       │
         │     Acquire Lock      │                       │
         └───────────────────────┼───────────────────────┘
                                 │
                    ┌─────────────────────────┐
                    │   Distributed Lock      │
                    │   (Redis/etcd)          │
                    └─────────────────────────┘

在配置层面，系统提供了灵活的参数调整能力来适应不同的部署场景。主节点租约时间（lease_ms）和选主逻辑循环间隔（loop_interval_ms）等关键参数可以根据单节点或多节点部署模式进行差异化配置，确保在各种网络环境下都能实现快速可靠的故障切换。

2.2 故障恢复机制

故障恢复机制是高可用设计的重要组成部分。当发生主备切换时，系统能够通过外部存储系统快速恢复元数据，同时清理未完成的写入操作状态，确保缓存状态在切换后保持一致性。这种设计使得系统能够在分钟级时间内完成故障恢复，最大程度减少服务中断时间。

3. 配置管理与部署

Tair KVCache 采用灵活的多层次配置体系来满足不同环境的部署需求。系统支持配置文件、启动参数和环境变量三种配置方式，按照优先级顺序进行覆盖：环境变量具有最高优先级，其次是启动时通过 --env 参数指定的配置，最后是配置文件中的基础参数。这种设计既保证了配置的灵活性，又确保了生产环境配置的可管理性。在 Agent 场景 下，随着会话模式的变化，系统需要具备 动态弹性伸缩、多租户隔离、高可用保障 及 版本协同管理 能力，以支撑 PB 级存储下的成本效益优化与服务可靠性需求。

3.1 服务配置

在服务配置方面，系统提供了详细的端口管理机制，包括主服务的 RPC 端口（6381）和 HTTP 端口（6382），以及管理接口的专用端口（6491/6492）。线程配置允许根据实际硬件资源调整 IO 服务线程数（默认2个线程），而存储相关的配置则通过 URI 方式指定注册存储和分布式锁服务的连接信息。

# 端口配置
kvcm.service.rpc_port=6381
kvcm.service.http_port=6382
kvcm.service.admin_rpc_port=6491
kvcm.service.admin_http_port=6492

# 线程配置
kvcm.service.io_thread_num=2

# 存储配置
kvcm.registry_storage.uri=redis://127.0.0.1:6379
kvcm.distributed_lock.uri=redis://127.0.0.1:6379

3.2 系统基本概念

缓存配置则更加复杂和精细，需要定义存储配置、实例组配置以及缓存策略等多个维度。系统基本概念 包括管控面概念和数据面概念：

管控面概念：

Storage：一套存储系统，有独立的存储配置（连接地址等），支持多种不同存储类型，如 NFS、3FS、TairMemPool、Mooncake 等，允许不同的 Instance Group 和 Instance 共享同一 Storage
Instance Group：同 Group 内所有 Instance 共享一套配额，每个 Group 可以单独配置可用的 Storage 列表，常见用途包括：对应一个业务团队（团队内的多个模型共享存储配额）、对应一个模型（模型的多个版本共享存储配额）、为重要模型单独配置 Instance Group（保证独占存储资源）、多个长尾模型共用一个 Instance Group（共享存储资源的同时满足个别模型的突发容量需求）
Instance：一个 KVCache 实例，仅单个 Instance 内部会复用 KVCache（需要互相复用 KVCache 的推理实例应当配置为使用同一个 Instance）。跨 Instance 不复用 KVCache。对应的模型和 KVCache 配置（比如 fp8/bf16，block_size 等）唯一且不变，属于且仅属于一个 Instance Group，无需单独配置容量配额，使用所属的 Instance Group 的配额

数据面概念：

Block：一段定长的连续 Token 组成 1 个 Block。单个 block 的对应 token ids 数量在 Instance 初始化时指定。用户传入的 token id 序列会被切分为多个 block。有前缀依赖关系。自身 Token 序列相同但前缀不一致的两个 block 是不同的。每个 block 可以有多个 CacheLocation：对应多个存储位置/层级
CacheLocation：单个 block 的一个存储位置。单个 CacheLocation 内的所有数据必须全部位于同一种存储类型（type）。状态包括：writing → serving → deleting。writing：KVCache 正在写入，不可服务。暂时无需再次写入。serving：已写入完成，可正常读取。deleting：正在删除中，不可读取
LocationSpec：单个 CacheLocation 的一部分数据。组织存储位置格式统一为 URI，但允许不同表达方式：对于内存池可能是地址。对于文件系统可能是文件路径。对于 KV 存储可能是 Key。统一了格式，同时避免了强制映射到地址偏移或 KV 等导致的底层位置语义错位。在 uri 中记录 size 以简化容量统计。通过 blkid+size 支持单个存储位置（如单个 3fs 文件）内的分块存储。spec name 允许用户配置：灵活支持不同的 TP、PP、混合注意力。允许 Location 内仅有部分 Spec：混合注意力场景下很多 block 不需要存储线性注意力

通过以上抽象，将存储、配额和实例解耦，允许灵活控制 KVCache 存储方式和容量，便于统一管理大量 KVCache 实例。在 Instance Group 上配置容量配额，避免了为 Instance 单独配置存储容量，简化了业务侧的接入流程，也便于模型版本切换时的容量转移。基于以上抽象，既满足了推理引擎的 KVCache 查询需求（混合注意力的复合匹配等），也在 Tair KVCM 内保留了 LLM 的相关业务特征和语义：多 Block 间的前缀关系，同 Location 多 Spec 的关联关系等。由于感知并保留了 LLM 相关特征，Tair KVCM 还可以针对 KVCache 存储场景实现更多优化，如：通过前缀对请求进行更细致的分类，针对性调整逐出策略。利用前缀依赖的数据关系，避免后缀的无效存储。为线性注意力选择最需要保留的 Block，在不牺牲命中率的情况下优化存储容量等。从底层存储视角看，降低了接入的复杂度（不需要了解任何推理概念，完全透明），同时还可以获取到提炼并翻译后的存储特征（存储对象间的生命周期关联等），为后续更进一步的优化和专用存储系统的开发留出了充足空间。

源码实现分析：系统基本概念在代码中有直接对应的实现。StorageConfig 类定义了存储配置，包括类型、全局唯一名称和存储规格参数。InstanceGroup 类管理实例组，包含配额配置和可用存储列表。InstanceInfo 类表示单个实例，包含模型配置和块大小等信息。CacheLocation 类定义了缓存位置，包含 URI、状态和位置规格信息。LocationSpecInfo 结构体描述位置规格，支持不同 TP、PP 配置和混合注意力场景。DataStorageUri 定义了统一的 URI 格式，支持不同存储类型的地址表示。

3.3 存储与实例组配置

存储配置中需要指定存储类型、全局唯一名称和具体的存储规格参数，而实例组配置则涉及存储候选列表、容量配额和缓存回收策略等关键参数。这种分层的配置设计使得系统能够适应从小规模测试到大规模生产环境的各种部署场景。

{
    "storage_config": {
        "type": "file",
        "global_unique_name": "nfs_01",
        "storage_spec": {
            "root_path": "/tmp/nfs/",
            "key_count_per_file": 8
        }
    },
    "instance_group": {
        "name": "default",
        "storage_candidates": ["nfs_01"],
        "quota": {
            "capacity": 30000000000,
            "quota_config": [
                {"storage_type": "file", "capacity": 10000000000}
            ]
        },
        "cache_config": {
            "reclaim_strategy": {
                "reclaim_policy": 1,
                "trigger_strategy": {"used_percentage": 0.8},
                "delay_before_delete_ms": 1000
            }
        }
    }
}

3.4 部署方式

部署方式上，系统推荐使用容器化部署以确保环境的一致性和部署的便捷性。通过简单的 Docker 命令即可启动服务，并支持通过环境变量灵活调整配置参数。对于开发和测试环境，也可以直接通过 Bazel 构建系统从源码启动，为开发者提供了便利的调试环境。

4. 监控体系与运维支持

为保障系统在生产环境中的稳定运行，Tair KVCache 构建了完善的监控体系和运维支持机制。

4.1 指标监控体系

系统的指标监控体系采用分层设计，提供 Counter 计数器和 Gauge 仪表盘两种核心指标类型，分别用于跟踪请求数量、错误计数等累积型数据和当前状态值、资源水位等瞬时型数据。监控维度覆盖从请求级别到实例级别再到系统级别的全栈监控，确保运维人员能够从不同视角全面了解系统运行状态。

4.2 日志系统

日志系统采用多层次架构设计，将不同类型的日志进行分离管理。访问日志记录所有客户端请求的详细信息，指标日志专门记录系统性能数据，事件发布日志跟踪重要的系统事件，而系统日志则提供全面的运行时信息。这种分类管理方式既便于问题定位，也支持不同场景下的日志分析需求。

4.3 健康检查机制

健康检查机制为系统运维提供了重要的保障工具。通过标准化的健康检查接口，运维人员可以实时监控服务状态、查询集群信息、监控 Leader 节点状态以及查看当前配置参数。这些接口不仅支持人工检查，也能够与自动化运维系统集成，实现故障的快速发现和处理。

5. 性能优化与扩展性

Tair KVCache 在性能优化方面采用了多项先进技术来确保系统能够满足大规模 LLM 推理场景的严苛性能要求。

5.1 并发控制优化

在并发控制层面，系统通过分片锁机制有效减少锁竞争，采用读写锁提升并发读取性能，并在热点路径上运用无锁数据结构来最大化吞吐量。这些优化措施使得系统能够在高并发场景下保持稳定的响应性能。随着高性能网络技术不断演进，智算环境内网络带宽快速增长（单端口从 25Gbps 快速跃升至 200+Gbps），互联规模不断扩大（千卡、万卡甚至跨可用区），互联机型更加多样（eRDMA 等已覆盖主流存储机型），使得解耦算力资源和 KVCache 存储成为可能。以阿里云为例，智算场景下 KVCache 跨机传输的典型带宽约为 20GB/s：EGS 8 卡机型对应 20GB/s 通用网络带宽，灵骏 8 卡机型对应 25GB/s 存储带宽（另有 200~400GB/s ScaleOut 网络带宽）。20G/s 带宽均可以满足 KVCache 跨机传输需求。随着高性能网络的继续演进，KVCache 传输带宽还会进一步扩展，不断降低跨机传输代价。

源码实现分析：并发控制优化在多个层面实现。在 MetaIndexer 类中，mutex_shards_ 成员实现了分片锁机制，通过 GetShardIndex 方法将 key 映射到不同的锁分片，减少锁竞争。ScopedBatchLock 类确保批量操作的原子性。BatchMetaData 结构体和 MakeBatches 方法实现了批处理优化，将大批量操作分解为小批次，避免长时间持有锁。batch_key_size_ 配置参数控制批次大小，平衡并发性能和单批吞吐量。

5.2 内存管理优化

内存管理方面，系统实现了智能化的内存使用策略。通过 LRU 缓存机制有效减少内存占用，利用对象池技术避免频繁的内存分配和释放操作，同时实施内存水位控制来防止 Out of Memory 错误的发生。这种多层次的内存管理策略既保证了系统的高性能运行，又确保了内存使用的安全性和稳定性。

5.3 异步处理机制

异步处理是系统性能优化的另一个重要维度。通过异步删除机制，系统能够将耗时的删除操作从关键路径上移除，避免阻塞前台请求处理。批量处理优化进一步提升了系统的处理效率，而背压控制机制则有效防止系统在高负载情况下出现过载问题，确保服务的持续可用性。

6. 安全与扩展性设计

6.1 插件化架构设计

在扩展性设计方面，Tair KVCache 采用了插件化架构来支持系统的灵活扩展。存储后端的插件化设计提供了统一的接口规范，使得新的存储类型能够通过动态加载的方式集成到系统中，配合策略模式实现灵活的配置管理。驱逐策略的插件化同样采用工厂模式，不仅支持自定义驱逐算法的开发，还允许在运行时进行策略切换，为不同场景下的性能优化提供了便利。Tair KVCache Manager 的设计初衷便是考虑到大规模部署的需求，提供覆盖 KVCache 全生命周期的企业级管理能力，如：模型上线前的 ROI 评估和高收益场景筛选，模型在线服务过程中的可观测和高可用等。

源码实现分析：插件化架构在多个层面实现。存储后端通过 DataStorageBackend 抽象基类实现插件化，具体存储类型如 hf3fs_backend、mooncake_backend、nfs_backend 等继承该基类。DataStorageBackendFactory 使用工厂模式创建不同类型的存储后端实例。驱逐策略通过统一的接口设计支持多种算法扩展，CacheReclaimer 类支持 LRU、LFU、TTL 等多种驱逐策略。MetaStorageBackend 抽象类实现了元数据存储的插件化，有 MetaLocalBackend 和 MetaRedisBackend 等具体实现。这种设计使得新功能可以轻松集成到系统中，无需修改核心逻辑。

6.2 微服务化架构

微服务化架构进一步增强了系统的可扩展性。通过将管理服务、缓存服务和监控服务进行独立部署，系统能够根据实际负载情况进行弹性扩展。这种服务拆分方式不仅提高了系统的可维护性，也为云原生部署提供了良好的支持。基于全局池化的外部 KVCache 存储，系统可以进一步将外部 KVCache 存储从推理容器中剥离出来，带来了诸多好处：让推理容器的扩缩容不再影响 KVCache 容量和命中率，更自由地弹性伸缩以优化推理成本；可以为不同 Agent 场景灵活设置更优的 KVCache 存储容量，一方面避免存储容量被推理规模限制，另一方面降低存储资源的浪费；将存储和推理服务从部署层面解耦，有利于简化运维管理，避免互相影响稳定性；引入 3FS 等外部存储系统，进一步扩大存储容量，降低存储成本。

6.3 安全设计

安全设计是企业级系统不可或缺的重要组成部分。Tair KVCache 建立了完善的访问控制体系，通过用户账户管理、角色权限控制和操作审计日志等机制确保系统的访问安全。数据安全方面，系统支持 TLS 加密传输来保护数据在传输过程中的安全性，通过身份认证机制验证用户身份，并实施数据完整性校验来防止数据被篡改。在部署运维方面，系统需要评估 KVCache 容量需求、外部 KVCache 存储的收益和 ROI，从大量存量推理服务中找出收益最明显的一部分；在运行中，需要可观测能力，及时感知系统水位变化，结合线上实际需求持续调优存储容量配置；同时需要高可用和高可靠性解决方案，避免元数据服务或存储系统故障导致推理服务异常；针对部分重要模型服务，严格保障充足的 KVCache 资源，而且针对长尾模型服务，尽可能共享存储资源，减少容量配置工作量；当切换模型版本时，保障新旧模型 KVCache 隔离，同时跟随新旧版本的推理流量变化柔性调整 KVCache 容量比例。

6.4 部署运维

在部署运维方面，Tair KVCache 提供了灵活的部署选项。推荐使用容器化部署方式，通过简单的 Docker 命令配合环境变量即可快速启动服务。对于开发和测试环境，也支持通过 Bazel 构建系统直接从源码启动，为开发调试提供了便利。系统预置了标准的配置文件，包括服务配置文件 package/etc/default_server_config.conf 和日志配置文件 package/etc/default_logger_config.conf，为快速部署提供了基础保障。随着部署规模的扩大，需要不断加强对大规模部署下暴露出的痛点，持续增强相关企业级能力，提供更全面的管理能力。面对更多样的部署环境，系统也需要支持线下私有环境和超节点等不同场景，为不同场景设计针对性的优化方案。

7. 技术特色与创新价值

Tair KVCache Manager 作为面向 LLM 推理场景的企业级 KVCache 管理系统，在技术实现上体现了显著的创新价值。系统的核心技术优势在于：

中心化管理 KVCache 元数据信息，实现跨推理实例的全局 KVCache 池化共享。显著提升 Agent 等长上下文场景下的推理性能
对 LLM KVCache 语义进行合理抽象，解耦推理引擎和存储系统。简化接入难度的同时为存储系统保留充足的优化空间
设计之初便考虑到大规模部署的需求，提供覆盖 KVCache 全生命周期的企业级管理能力，如：模型上线前的 ROI 评估和高收益场景筛选，模型在线服务过程中的可观测和高可用等等

最终实现在保持低成本的同时，显著减少 GPU 计算资源消耗，提升推理在线服务质量。系统通过动态存储选择机制根据实时状态选择最优存储后端，并采用多维度容量控制策略确保资源的高效利用，同时支持多种精确的驱逐算法来适配不同的业务场景需求。

7.1 创新设计

在创新设计方面，系统的两阶段写入机制确保了写入操作的原子性和可靠性，分层索引结构通过 Radix Tree 等高效索引技术显著提升了查询性能。Optimizer 仿真优化工具的引入使得策略预评估和参数优化成为可能，而插件化架构则为系统的扩展性提供了坚实基础，支持新功能的快速集成。系统通过将删除任务放入后台线程池等工程手段实现删除的异步执行，使得删除性能可扩展以支持较大的部署规模；同时支持 TTL、LRU、LFU 等多种常见逐出模式，可以灵活适配不同的容量管理需求；支持水位与 Quota 在 Runtime 的实时更新；支持结合 Optimizer 模块实现 Instance 级别的逐出参数动态调优。

7.2 性能表现

从性能表现来看，系统在高并发处理能力、低延迟响应、高可用性保障以及弹性扩展支持等方面都达到了企业级标准。微秒级的查询响应时间、99.9%以上的服务可用性，以及对水平和垂直扩展的良好支持，使得该系统能够满足大规模生产环境的严苛要求。随着高性能网络的继续演进，KVCache 传输带宽还会进一步扩展，不断降低跨机传输代价。结合高性能网络和 HiCache 等推理引擎内的优化，全局池化让 KVCache 无法在推理本地 VRAM 命中的代价大大降低（从远端拉取代价远低于重新 Prefill），放宽了亲和性约束。使调度器更轻松地实现高 KVCache 命中率，进而可以专注于算力调度，实现更高的算力利用率和 SLO。

8. 总结与展望

Tair KVCache Manager 作为面向 LLM 推理场景的企业级 KVCache 管理系统，通过精心的架构设计和技术创新，成功构建了一个高性能、高可用、易扩展的分布式缓存管理解决方案。系统采用分层解耦的设计理念，结合插件化架构和智能优化策略，在满足大模型推理场景严苛性能需求的同时，为大规模生产环境部署提供了可靠的基础设施保障。系统通过以下设计解决 Agent 时代面临的挑战：中心化管理 KVCache 元数据信息，实现跨推理实例的全局 KVCache 池化共享，显著提升 Agent 等长上下文场景下的推理性能；对 LLM KVCache 语义进行合理抽象，解耦推理引擎和存储系统，简化接入难度的同时为存储系统保留充足的优化空间；设计之初便考虑到大规模部署的需求，提供覆盖 KVCache 全生命周期的企业级管理能力。

8.1 系统核心价值

该系统的核心价值不仅体现在技术实现的先进性上，更在于其完整的工程化实践。从高可用的主备选举机制到精细化的容量管理策略，从多层次的监控体系到灵活的配置管理，每一个设计决策都体现了对生产环境稳定运行的深度思考。Optimizer 等分析工具的引入，更是将系统的可运维性和可优化性提升到了新的高度。系统构建了一个专注于 LLM 语义适配和存储管理的元数据管理层，该层不替代底层存储，而是作为元数据管理器，向上对推理引擎暴露符合 LLM 语义的原生接口，向下将操作映射为对底层存储的高效调用，同时将提炼并转译后的存储特征提供给底层存储。这种添加抽象层的方式可以兼顾落地速度与长期演进——短期可快速利用现有存储系统支持大容量 KVCache 池化存储，中长期则为专用存储系统明确优化目标与接口边界，实现平滑演进。

核心实现回顾：整个系统通过模块化的架构设计实现了高度的可维护性和可扩展性。CacheManager 作为核心协调者，整合了 MetaIndexerManager、DataStorageManager、CacheReclaimer 等多个组件。Server 层提供统一的服务接口，通过 MetaServiceImpl、AdminServiceImpl、DebugServiceImpl 实现具体的业务逻辑。MetricsRegistry 提供了完整的监控体系，支持多层次的指标收集。EventManager 实现了事件发布机制，支持系统的可观测性。这种设计确保了系统的高可用性、可监控性和可维护性，为生产环境的稳定运行提供了坚实基础。

8.2 未来发展

作为开源项目，Tair KVCache 为整个行业树立了优秀的技术标杆，不仅推动了 LLM 推理基础设施的标准化进程，也为相关领域的技术创新提供了宝贵的实践经验。随着大模型技术的快速发展，系统将继续在以下方面演进：

支持更全面的 LLM 缓存场景：随着多模态模型能力的提升，多轮会话需求也在增多，需要进一步完善 LLM KVCache 接口多模态支持；针对 encoder cache 和类似 VLCache 的上下文无关 KVCache 场景，添加传统 KV 语义接口
完善主流推理引擎和后端存储的支持：通过和推理引擎社区的合作，使更多推理引擎能够获得原生的支持能力，同时进一步优化传输性能；适配更多后端存储系统，满足更多不同场景下的 KVCache 存储需求
进一步加强仿真和缓存分析能力，优化存储算法：增强推理联合仿真能力，优化逐出算法，提高命中率，降低推理成本；探索更符合 LLM KVCache 场景需求的数据分层算法
不断增强企业级能力：对大规模部署下暴露出的痛点，持续增强相关企业级能力，提供更全面的管理能力

9. Tair KVCache 与 LMCache 对比分析

作为两大主流的 LLM KVCache 管理系统，Tair KVCache 和 LMCache 在架构设计理念上各有特色，分别代表了中心化管理和嵌入式集成两种不同的技术路线。

9.1 架构模式对比

维度	Tair KVCache	LMCache
部署架构	中心化架构：独立的 KVCM 管理服务 + 推理引擎连接器	嵌入式架构：作为推理引擎插件直接集成
元数据管理	外部服务：KVCM 作为独立进程管理全局元数据	分布式控制：缓存控制器 + Worker 模式
数据流向	推理引擎 → KVCM（元数据）→ 存储后端（数据）	推理引擎 → LMCache（集成）→ 多级存储
扩展性	通过 KVCM 水平扩展以支持多个推理集群	通过 Workers 水平扩展，每个实例独立运行

9.2 存储架构对比

Tair KVCache 采用统一的存储后端抽象层设计，而 LMCache 则构建了更为精细的四级存储分层体系。

特性	Tair KVCache	LMCache
存储层级	两级架构：内存池 (TairMemPool) + 持久化存储 (3FS/NFS)	四级架构：L1 (内存) → L2 (P2P) → L3 (磁盘) → L4 (远程)
内存管理	统一内存池管理，支持多节点内存统一寻址	多种内存后端：LocalCPU/PD/P2P，支持 NUMA 优化
持久化支持	3FS 文件系统、Mooncake 分布式存储	GDS、Nixl、LocalDisk、Remote Backend 多种选择
共享机制	中心化存储共享，支持跨实例复用	P2P 直连共享 + 中心化共享双重模式

9.3 核心功能对比

两者在缓存策略、共享机制和性能优化方面展现了不同的技术取向和应用场景适配能力。

功能	Tair KVCache	LMCache
前缀匹配	✅ 支持 KV 式、前缀式、滑动窗口式匹配	✅ 支持前缀缓存，更灵活的非前缀复用 (CacheBlend)
容量管理	Instance Group 配额 + 水位控制 + 多种驱逐策略	LRU/LFU/TTL 多策略 + 分层存储自动提升
高可用	主备选举 + 故障恢复 + 存储后端健康检查	软状态架构 + 快速重建 + HealthMonitor
性能优化	两阶段写入机制 + 异步删除 + 分片锁优化	Write-All 全写 + Waterfall 瀑布检索 + 异步 I/O

9.4 适用场景对比

Tair KVCache 在企业级应用场景中表现出色，特别适合需要统一管控的大规模部署环境。它通过中心化的 KVCM 服务提供全局元数据管理，能够有效支撑多集群环境下的协同工作，同时满足对存储后端强一致性的严格要求。对于已经部署了 Tair 或 MemPool 基础设施的阿里云用户来说，Tair KVCache 能够实现无缝集成和深度优化。

相比之下，LMCache 在灵活性和性能优化方面更具优势。它非常适合单机或小规模集群的部署需求，能够针对特定硬件环境进行极致的性能调优。LMCache 对异构硬件的良好支持使其能够在多种存储后端间灵活切换，这种特性使其在开源社区和学术研究场景中广受欢迎。

9.5 技术特色对比

Tair KVCache 的核心竞争力体现在其企业级特性和生态整合能力上。通过中心化的元数据管理机制，系统提供了全局统一的视图和管控能力，这在大规模生产环境中至关重要。与阿里云生态的深度整合，特别是与 Tair 数据库和 Mooncake 存储系统的无缝对接，为用户提供了完整的解决方案。其完善的配额管理体系和监控告警机制，配合 TairMemPool 的软硬件协同优化，确保了企业级应用的稳定性和可靠性。

LMCache 则在性能极致化和架构灵活性方面独树一帜。系统采用多级存储架构配合零拷贝技术和异步流水线处理，实现了业界领先的性能表现。其插件化的设计理念使得新存储后端的扩展变得简单直接，而活跃的开源社区和完善的文档体系为用户提供了强大的支持。特别值得一提的是，LMCache 在 RAG 场景优化（CacheBlend）和 KVCache 压缩传输（CacheGen）等高级特性方面展现了技术创新的前沿水平。

9.6 总结

这两个系统体现了截然不同的设计哲学：Tair KVCache 专注于企业级的中心化管理模式，通过统一的架构确保系统的可控性和一致性；而 LMCache 则追求高性能分布式架构，在灵活性和极致性能优化上不断突破。实际选择时需要综合考虑部署规模、性能需求、硬件环境以及团队的技术栈偏好等多个因素。

值得注意的是，两种方案在实际应用中完全可以互补共存。一种理想的混合部署策略是：利用 LMCache 处理本地的高性能缓存需求，同时通过 Tair KVCache 实现跨集群的统一管理和资源调度，最终构建一个层次化的 KVCache 解决方案，充分发挥两种架构的优势。