本文整理自 AICon 上海分享「记忆感知的大模型 KVCache 优化」（演讲者：马腾），通过AI音视频总结工具 Ai好记进行视频转图文整理，以下为精炼整理后的内容。

---

背景：为什么 KVCache 管理成为新瓶颈

大模型推理中，KVCache 一直是个关键概念——它缓存了 Transformer 注意力层的 Key 和 Value 向量，避免重复计算。但随着 Agent 场景普及，KVCache 管理正从「优化项」升级为「核心瓶颈」。

为什么？看看 Agent 的工作负载就明白了。

传统对话场景下，一个用户发一条 prompt，模型生成回复，对话结束，KVCache 随之释放。但 Agent 场景完全不同：

维度	传统推理	Agent 工作负载
交互模式	单轮或少量多轮	上百轮协作
KVCache 生命周期	用完即释放	需要持久化
Prompt 结构	单一的完整 prompt	模块化动态组合（system + tools + history）
前缀共享	按用户隔离	多 Agent 共享
输入输出比	通常 1:1	可能超过 100:1
工作流形式	线性	DAG（有向无环图）

一个典型场景：10 个 Agent 进行 20 轮交互，工作记忆可能达到百万级 Token。每次大模型调用都需要独立处理一遍上下文，重复的 Prefill 计算会带来：

• 显存碎片化：大量缓存在不同时间点产生和释放，碎片严重
• TTFT 极高：极端情况下，无缓存与有缓存的 TTFT 差异可达 136 倍
• 缓存命中率低：MCP 动态加载工具、JSON 序列化不确定性都会导致缓存不命中

KVCache 的重新定位：Agent 的物理工作记忆

一个核心认知转变：KVCache 不仅仅是推理引擎的内部数据结构，它应该被视为 Agent 的「物理工作记忆」。

类比一下：30 年前数据库系统需要自行管理 Buffer Pool，因为操作系统不了解数据库的访问模式。现在 Agent 场景下的 KVCache 管理也面临同样的问题——LLM Serving 不了解 Agent 的工作流特征，需要把 KVCache 管理从 Serving 引擎中独立出来。

Agent 的「工作记忆」由几个部分组成：

组成部分	特点	缓存策略
System Prompt	固定不变	高优先级缓存，全量共享
工具/Skill 定义	半固定，偶尔更新	按版本缓存
多轮对话历史	持续增长	按 session 管理，LRU 淘汰
Agent 间状态	共享且动态	分布式缓存，租约机制

Mooncake 项目架构详解

Mooncake 是一个以 KVCache 为中心的分离式架构，核心思想是让 Prefill 和 Decode 共享一个大的 KVCache 池，支持 PD 解耦。

四大核心模块

1. Transfer Engine（传输引擎）

高性能传输是基础。传输引擎需要支持多种硬件协议：

协议类型	典型延迟	适用场景
NVLink	~0.5μs	单机内 GPU 间通信
RoCE	~3-5μs	跨节点 RDMA 通信
InfiniBand	~1-3μs	高性能跨节点通信
CANN（国产）	取决于硬件	昇腾等国产芯片适配

关键点是「拓扑感知」——传输引擎需要理解底层硬件拓扑，选择最优通信路径。

2. Mooncake P2P（权重分发）

基于传输引擎的模型权重分发系统，采用分布式 P2P 方式加载权重，支持 Kimi Checkpoint Engine 等工具。解决了传统集中式权重分发在大规模集群下的带宽瓶颈。

3. 专家并行（EP）支持

在 MoE（Mixture of Experts）架构下，不同专家模型分布在不同设备上。Mooncake 通过点对点通信支持 EP 并行，并解决了 Process Group 容错问题——为 Torch Distributed 编写专门的 Backend，提供弹性与容错优势。

4. Mooncake Store（KVCache 存储）

分布式跨节点的 KVCache 存储池，支持：

• 多级透明存储：DRAM 热数据 + 磁盘冷数据
• 哈希 Key + 租约机制：高效的多读操作，可保持一致性
• 自动迁移：根据访问频率在存储层级间动态调整

PD 分离的两种模式

模式	流程	优势	劣势
直传模式	Prefill 节点将 KVCache 直传给 Decode 节点	延迟最低	需要 Prefill 和 Decode 紧密耦合
中心化存储模式	Prefill 节点存入 Store，Decode 节点读取	调度灵活，支持异步	多一跳存储延迟

Agent 感知的 KVCache 优化技术

Mooncake 项目还探索了几个前沿方向：

HiCache：跨存储层级的前缀匹配

传统缓存策略只做精确匹配，但 Agent 场景下经常出现「接近但不完全一致」的前缀需求。HiCache 的思路是：在 DRAM 和 SSD 两级存储间自动迁移最可能被复用的前缀缓存块，并在缺失时尝试「近似匹配」以节省部分计算。

TokenCake：Agent 工作流的时空分析

这是最有意思的一个方向。把 Agent 的工作流 DAG 纳入缓存管理策略：

• 时间维度：预测工具调用耗时，提前将等待中的 Agent 的 KVCache 卸载到 CPU
• 空间维度：分析 Agent 间的依赖关系，动态划分共享缓存和私有缓存，减少冲突

比如一个 Agent 在等外部 API 返回结果时（可能耗时数秒到数分钟），这段时间 KVCache 在 GPU 上闲置，TokenCake 会将其卸载到 CPU 内存，等结果回来再重新加载。

工作流即查询计划

更激进的想法：把 Agent 工作流类比为数据库的查询计划，系统可以提前分析 DAG 结构，预测哪些 KVCache 段会被复用、复用多久、需要什么级别的访问延迟，然后做出最优的缓存调度决策。

未来：Agent 协议需要支持缓存语义

当前 A2A（Agent-to-Agent）和 MCP（Model Context Protocol）等 Agent 协议缺乏对缓存语义的支持。未来的协议演进需要考虑：

• session_id：会话标识，关联同一工作流的所有缓存
• prefix_hash：前缀哈希，用于快速匹配缓存的上下文
• ttl：缓存的生存时间
• expected_tool_duration：预计工具调用耗时，辅助调度决策

只有协议层支持这些字段，上层应用才能向下层基础设施传递缓存提示信息，大幅提高缓存命中率。

总结思考

KVCache 从推理引擎的内部缓存升级为 Agent 的物理工作记忆，是整个 AI 基础设施的重要演进方向。Mooncake 项目的实践表明：

1. 存储层需要从 Serving 引擎中独立出来，提供统一管理
2. Agent 工作流的 DAG 特征为缓存调度提供了优化空间
3. 协议层需要配合演进，才能实现端到端的效率优化

对于使用大模型做 Agent 应用的团队来说，理解 KVCache 的底层工作原理和前沿优化方案，有助于更好地设计应用架构和评估推理成本。

---

FAQ

Q：KVCache 优化对普通 AI 应用开发者有什么实际价值？
A：直接影响响应速度和成本。优化的 KVCache 管理可以减少 50% 以上的 TTFT，对用户体验影响显著。

Q：Mooncake 是否支持国产芯片？
A：是。项目已适配昇腾、摩尔线程、寒武纪等国产硬件，通过 CANN 等协议对接。

Q：KVCache 持久化会带来安全隐患吗？
A：会。缓存了多轮对话内容的 KVCache 如果泄露，可能包含敏感信息。需要在存储层实施访问控制和加密。

---

以上内容由AI音视频总结工具 Ai好记 转录整理。
Ai好记 是一款音视频转图文笔记的AI学习助手，支持解析B站、抖音、小宇宙等平台链接及本地、网盘音视频文件，转录后自动生成精华速览、思维导图和结构化笔记，帮助你把几小时的视频内容变成可搜索、可复习的图文笔记。