即将开源 | 阿里云Tair KVCache Manager：企业级全局 KVCache 管理服务的架构设计与实现

导读

【重磅】 阿里云 Tair KVCache 团队联合阿里巴巴智能引擎、基础设施与稳定性工程团队即将开源企业级全局 KVCache 管理服务 Tair KVCache Manager，本文详细介绍该服务的架构设计与实现细节。

随着 Agentic AI兴起，以推理引擎为中心的传统单机分层方案已无法满足新时代的 KVCache 存储需求。随着 KVCache 池化存储在大规模 Agent 推理场景中走向落地，需要构建具备容量精准评估、动态弹性伸缩、多租户隔离、高可用保障及版本协同管理能力的企业级 KVCache 管理系统，以支撑PB级存储下的成本效益优化与服务可靠性需求。为了解决这些问题，我们设计并实现了一套专为大模型推理场景服务的全局 KVCache 管理服务，支持了阿里巴巴集团 RTP-LLM推理服务加速，并且扩展支持到 vLLM、SGLang 等众多开源引擎，兼容 Sparse Attention、Sliding Window Attention 等在内的多种注意力机制。

本文将从Agent场景下的KVCache存储需求出发，在之前文章的基础上进一步分析该场景下KVCache存储所面对的挑战，并介绍Tair KVCache Manager针对这些挑战所做的架构设计选择和相关实现。

本系列技术文章将系统性拆解面向智能体推理的 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. KVCache服务的三重升级挑战

1.1 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存储的过紧耦合。

值得庆幸的是，随着高性能网络技术不断演进，智算环境内网络带宽快速增长（单端口从25Gbps快速跃升至200+Gbps），互联规模不断扩大（千卡、万卡甚至跨可用区），互联机型更加多样（eRDMA等已覆盖主流存储机型），让我们拥有了解耦算力资源和KVCache存储的可能性。

以阿里云为例，智算场景下KVCache跨机传输的典型带宽约为20GB/s：EGS 8卡机型对应20GB/s通用网络带宽，灵骏8卡机型对应25GB/s存储带宽（另有200~400GB/s ScaleOut网络带宽）。我们以Deepseek和Qwen3-Coder的典型Prefill吞吐为例进行分析，20G/s带宽均可以满足KVCache跨机传输需求。随着高性能网络的继续演进，我们相信KVCache传输带宽还会进一步扩展，不断降低跨机传输代价。

（DeepSeek Prefill吞吐来自于RTP-LLM复现报告，DeepSeek官方披露中为32.2K。Qwen3-Coder Prefill吞吐为优化后的部署模式下的粗略估计值，单机部署时实测值约为10000 token/s。）

1.1.1 由此外部KVCache存储开始从推理绑定走向全局池化：

结合高性能网络和HiCache等推理引擎内的优化，全局池化让KVCache无法在推理本地VRAM命中的代价大大降低（从远端拉取代价远低于重新Prefill），放宽了亲和性约束。使调度器更轻松地实现高KVCache命中率，进而可以专注于算力调度，实现更高的算力利用率和SLO。

同时基于全局池化的外部KVCache存储，我们可以进一步将外部KVCache存储从推理容器中剥离出来，这将带来以下好处：

让推理容器的扩缩容不再影响KVCache容量和命中率，更自由地弹性伸缩以优化推理成本。
可以为不同Agent场景灵活设置更优的KVCache存储容量，一方面避免存储容量被推理规模限制，另一方面降低存储资源的浪费。
将存储和推理服务从部署层面解耦，有利于简化运维管理，避免互相影响稳定性。
引入3FS等外部存储系统，进一步扩大存储容量，降低存储成本。

当然这种分离并不代表放弃推理主机节点上的存储资源，事实上将这些存储资源统一池化能更充分地利用这些资源，同时还有利于提高存储系统的整体稳定性。

1.2 LLM场景对现有存储系统提出新需求

在KVCache全局池化后，大量现有存储系统被用于外部KVCache的存储，常见的有：文件存储、KV存储、内存池、对象存储等等，均有各自的接口。基于现有接口快速实现全局KVCache池化存储的同时也遇到了一些问题。

LLM KVCache相较传统KV存储有其特殊的业务特征和存储模式：

数据间有前缀依赖性。（A,C和B,C中的C代表不同数据）;
查询模式常为前缀匹配+反向滑动窗口（SWA/Linear）;
单block内KVCache切分模式多样：多样的并行模式和混合注意力方案;
多个推理进程同时读写单个block;

- TP/PP并行下多推理进程会同时读/写同一Block对应的KVCache的不同部分（比如不同的head）;
- 不同部分生命周期绑定，使用时缺一不可。

当前存储系统接口面向通用场景设计，直接套用抹去了LLM的业务语义和特征，使得底层存储系统难以针对KVCache特征进行更深入的优化。典型问题如：为了方便多进程同时写入，将单Block拆分为多个Key，但多Key逐出时间并不一致，导致部分Key被逐出后剩余Key虽然占用存储容量但无法提供命中，浪费存储资源。

部分存储系统的元数据性能不足，难以在短时间内完成大量元数据查询:

以block_size=64为例，64K上下文就需要查询1K个block的元数据，判断存在性并读取相关信息。而且64K token对应的KVCache传输仅需要不到1秒，查询元数据的耗时影响就更加明显。同时单个block的KVCache大小在个位数MB级别，百TB的存储就需要支撑亿级block的管理。大部分针对HPC场景设计的存储系统主要侧重于优化读写带宽，对如此海量block下的大规模元数据查询支持有限。

改造现有存储系统或重新做一套存储系统工程量都较大：

高性能分布式存储系统本身具有较高的复杂性。同时由于存量业务场景的接口通用性诉求，和存储系统固有的高稳定性和可靠性要求，不论是为现有存储系统增加LLM相关的能力，还是重新针对LLM场景研发一套存储系统，都需要很多的研发资源和时间，而且如果使用多套存储系统，则每套系统都要进行相关开发。

因此需要尽可能复用现有工程资源，以尽快满足迫切的KVCache的存储需求。同时也为针对LLM场景的专用存储系统先行明确实际需求和负载模式，使其可以有更完备的信息和充裕的时间来完成设计和开发，协助其更好的满足KVCache需求。

结合以上问题，构建一个专注于LLM语义适配和存储管理的元数据管理层成为了一条务实可行的路径：

该层不替代底层存储，而是作为元数据管理器，向上对推理引擎暴露符合 LLM 语义的原生接口，向下将操作映射为对底层存储的高效调用，同时将提炼并转译后的存储特征提供给底层存储。这种添加抽象层的方式可以兼顾落地速度与长期演进------短期可快速利用现有存储系统支持大容量KVCache池化存储，中长期则为专用存储系统明确优化目标与接口边界，实现平滑演进。

1.3 规模部署要求管理系统提供新能力

随着推理引擎的支持和KVCache存储系统的完善，池化KVCache开始从小范围试验走向规模部署。当数PB的后端存储开始支撑多种Agent模型的KVCache存储，各类企业级管理能力的需求随之出现。

在推理服务启用外部KVCache存储前，需要评估KVCache容量需求 、外部KVCache存储的收益和ROI ，从大量存量推理服务中找出收益最明显的一部分。

在运行中，需要可观测能力 ，及时感知系统水位变化，结合线上实际需求持续调优存储容量配置 。同时需要高可用和高可靠解决方案，避免元数据服务或存储系统故障导致推理服务异常。

针对部分重要模型服务，严格保障充足的KVCache资源。而且针对长尾模型服务，尽可能共享存储资源，减少容量配置工作量。

当切换模型版本时，保障新旧模型KVCache隔离 ，同时跟随新旧版本的推理流量变化柔性调整KVCache容量比例。

随着部署规模的扩大，诸如此类的需求不断出现，对KVCache管理系统的企业级能力提出了更高的要求。

2. Tair KVCache Manager 应运而生

在这样的背景下，阿里云 Tair 与阿里巴巴智能引擎、基础设施与稳定性工程团队联合共建了面向大模型KVCache的企业级管理服务产品Tair KVCache Manager（以下简称Tair KVCM）。系统通过以下设计解决上述问题：

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

最终实现在保持低成本的同时，显著减少GPU计算资源消耗，提升推理在线服务质量。

文章后续部分将对系统中的基本概念和架构设计做详细介绍。

2.1 系统基本概念

2.1.1 管控面概念

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的配额。

通过以上抽象，将存储、配额和实例解耦，允许灵活控制KVCache存储方式和容量，便于统一管理大量KVCache实例。在Instance Group上配置容量配额，避免了为Instance单独配置存储容量，简化了业务侧的接入流程，也便于模型版本切换时的容量转移。

2.1.2 数据面概念

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查询需求（混合注意力的复合匹配等等），也在Tair KVCM内保留了LLM的相关业务特征和语义：多Block间的前缀关系，同Location多Spec的关联关系等等。由于感知并保留了LLM相关特征，Tair KVCM还可以针对KVCache存储场景实现更多优化，如：通过前缀对请求进行更细致的分类，针对性调整逐出策略。利用前缀依赖的数据关系，避免后缀的无效存储。为线性注意力选择最需要保留的Block，在不牺牲命中率的情况下优化存储容量等等。

从底层存储视角看，降低了接入的复杂度（不需要了解任何推理概念，完全透明），同时还可以获取到提炼并翻译后的存储特征（存储对象间的生命周期关联等等），为后续更进一步的优化和专用存储系统的开发留出了充足空间。

2.2 部署模式和服务接口

Tair KVCM以中心化模式部署。由于仅负责KVCache的元数据管理，结合C++作为开发语言，依靠scale up就可以满足单一推理集群的需求。同时instance group的抽象使得使用同一存储的不同的group也可以很轻松地进行拆分，横向scale out以服务不同推理集群。中心化模式使得运维部署大幅简化，同时也避免了将KVCM逻辑注入推理容器，规避了可能导致的元数据存储后端（如Valkey）连接数爆炸等问题。

同时结合3FS Master等工作，Tair KVCM可以仅使用TCP和推理引擎及后端存储进行交互，并不依赖强依赖RDMA环境。对于RDMA环境内仅有GPU机型的场景，可以将KVCM部署在RDMA环境外的其他机型上，规避GPU机型故障率过高的问题。

在通过Tair KVCM获取到KVCache的存储位置后，推理引擎内的Connector将直接读写后端存储，KVCache数据流完全绕过Tair KVCM，降低了KVCache读写延迟和对Tair KVCM的带宽需求。

为方便隔离，Tair KVCM对元数据面和管控面做了分离，这里列举其中一部分关键接口。

管理接口：

- 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两种模式，兼容多种推理引擎的同时方便周边系统查询；
- 主要接口均携带完整的前缀信息以便维护前缀元数据；

2.3 系统架构

2.3.1 Manager

接入层（Server）

同时提供http和grpc接口，方便不同推理引擎接入。
依托C++下的RDMA生态，如果有极低延迟需求，也可实现RDMA甚至GPU Direct接入。

读写模块（CacheManager）

多种匹配模式支持。推理引擎读取KVCache元数据时，支持多种匹配模式：

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

两阶段写入机制。推理引擎写入KVCache时，基于如下的两阶段写入机制：

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

高可用读写支持：

Tair KVCM支持多种存储后端（详见下面「存储管理」部分），支持动态切换不同存储后端进行读写，提高可用性；
由于KVCM能同时对接多种存储后端，对于推理引擎来说可以方便地按需求将数据存储至不同的后端。例如将热数据存储到TairMemPool，将冷数据存储到3FS。同时也能保证某个后端挂掉时，cache服务依然处于可用状态。

存储管理（DataStorage）

兼容多种存储系统

不同的存储系统有独立的存储配置。
支持3FS、TairMemPool、Mooncake、NFS等多种存储系统，同一个Storage可以被不同的InstanceGroup和Instance共享。
存储位置格式统一为Uri，并支持不同表达方式：内存池是地址、文件系统是路径等。
所有存储系统均通过统一的 DataStorageBackend 抽象接口接入，确保上层逻辑无需感知底层差异。解耦性与扩展性较强，上层只需传递Uri，新增存储类型只需实现接口，无需修改核心逻辑。

DataStorageManager进行多种存储系统的统一管理

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

其他特性

针对无元数据管理能力或元数据性能有限的存储系统NFS和3FS，提供block分配能力（分配少量大文件，切成小块使用）。

TairMemPool介绍：TairMemPool是阿里云Tair团队与服务器研发定制计算与芯片系统团队联合打造的高性能KVCache内存池方案。该方案通过软硬件协同优化，实现多节点内存统一寻址与全局访问能力，支持多介质/协议接入及KVCache专用传输优化，在多网卡环境下网络带宽利用率超90%，兼具企业级高可用特性，为TairKVCache系统提供高可靠存储支撑。

索引管理（MetaIndex）

使用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）

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的前后缀关联性逐出。

2.3.2 Optimizer

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

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

通过统一的 Trace 数据结构和高效的 Trace 处理机制，Optimizer 模块能够准确还原真实业务场景下的缓存行为，提供稳定且快速的性能分析。效果如图所示，图1的动态分析能够实时追踪缓存容量使用与命中率的协同变化；而图2清晰描绘了不同驱逐策略在不同缓存容量配置下的 KVCache 命中率收益，从而测试不同驱逐策略的性能变化以及指导最优容量配置。

（示例trace来源）

更进一步，Optimizer 模块通过灵活的架构设计，支持与 GPU 推理性能模型（算力画像）进行深度集成，能够基于缓存命中率对prefill阶段计算量的减少效果进行量化建模，将 KVCache 带来的延迟改善（如TTFT优化）和吞吐量提升直接映射到 GPU 资源利用效率的提升上，进而量化为 GPU 节点数量缩减和运营成本节约的具体优化建议，为智能推理系统资源调度和成本优化提供数据驱动的决策依据。具体细节将在后续文章中详细介绍。

3. 未来工作

3.1 支持更全面的LLM缓存场景

随着多模态模型能力的提升，多轮会话需求也在增多，需要进一步完善LLM KVCache接口多模态支持。

针对encoder cache和类似VLCache的上下文无关KVCache场景，添加传统KV语义接口。

面对更多样的部署环境，也有很多工作：

线下私有环境：线下环境自持主机使得KVCM在命中率以外出现了更多的优化目标。需要为该类场景设计更多针对性的逐出算法来进行优化。
超节点：该类系统中GPU通过ScaleUp网络访问内存池的带宽已经大于通过PCIE访问CPU内存的带宽，对用于存储KVCache的内存进行统一池化管理顺理成章。我们将协助实现超节点内KVCache的存储管理，充分发挥超节点的性能优势。

3.2 完善主流推理引擎和后端存储的支持

通过和推理引擎社区的合作，使更多推理引擎能够获得原生的支持能力。同时进一步优化传输性能。

适配更多后端存储系统，满足更多不同场景下的KVCache存储需求。

3.3 进一步加强仿真和缓存分析能力，优化存储算法

增强推理联合仿真能力。优化逐出算法，提高命中率，降低推理成本。

此外现有分层算法大多基于冷热等传统数据特征，并不完全适合LLM KVCache场景下的数据分层需求。需要结合LLM的访问特征，探索更符合该场景需求的数据分层算法。

3.4 不断增强企业级能力

对大规模部署下暴露出的痛点，持续增强相关企业级能力，提供更全面的管理能力。

4. 了解更多

欢迎搜索钉钉群号：109765011301入群与技术专家交流！