Agent 协作¶
工作负载画像：Prefix 复用度中高（task 级共享）｜上下文中长｜工具调用打断生成｜多次 LLM 调用构成单任务
特征¶
- 多 agent 间上下文部分共享：同一 task 的不同 step 共享 system prompt + task description
- 工具调用打断生成：每次 tool result 注入都改变 KV 末尾，产生新的 sealed block
- 长链路：单个 task 可能涉及十几次 LLM 调用，每次调用的 prompt 在上一次基础上追加
- 分支-合并模式：多 agent 并行执行后合并结果，KV 有"分叉"的访问结构
关键 KV 问题¶
1. 共享 Prefix 的去重¶
多个 agent 看到的 system prompt + task description 完全相同，但每个 agent 的 trailing 状态略有不同。
- 共享部分（system prompt）：prefix cache 可 100% 命中
- 差异部分（每个 agent 的独立历史）：各自独立，无法共享
- 关键设计：block 粒度要能对齐到 system prompt 的末尾，避免跨 block 污染共享部分
2. 工具调用后的 KV 续接¶
工具调用完成后，tool result 注入 prompt，整段输入改变。能否复用工具调用前的 KV？
- 严格意义上：tool result 改变了 prompt，tool result 之后的所有 token 的 K/V 都与位置编码强绑定，必须重新 prefill
- 实践上可复用的部分：截至工具调用之前的 prefix（包括 system prompt、历史对话、此前的工具调用链）可精确命中
- sealed block 对齐：只有已填满的 block 才能命中 prefix cache；tool result 注入后，末尾未填满的 block 需要重新计算
3. 多 Agent 的 KV 隔离¶
- 不同 agent 的 KV 必须隔离（prompt 结果不能混淆）
- 但 prefix 重叠的部分（system prompt、共享 task context）应当共享同一批 KV block——需要系统支持 ref-counted block 共享
- 多租户场景下还需考虑 cache_salt 隔离，避免不同用户的 agent 共享 KV
工程实证¶
Claude Code 的 KV Cache 工程¶
主站 essay 对 Anthropic 的 prompt caching 接口进行了详细分析，揭示了 Agent 场景的几个关键洞察：
- 90% 的缓存失效来自服务器端路由/驱逐，而非客户端变化——优化应集中在服务端调度而非客户端 prompt 设计
- Cache 价格差 10×：cache read $0.30/MTok vs full input $3/MTok，命中率是 Agent 推理成本的单变量决定性因素
- 缓存失效的诊断粒度：Anthropic 将失效分为 5 类——eviction、ttl_expired、prompt_too_large、rate_limited、usage_capped——每类对应不同优化策略
- Agent list 位置优化：将可用工具列表从 tool description 移至 message attachment，消除了 10.2% 的 cache_creation_tokens
来源：主站 essay Claude Code Context & KV Cache 工程
Mooncake Store 的 Agentic Trace 实测¶
在 610 条真实 agent trace 上，Mooncake Store 的分布式 KV 池实现：
| 指标 | 基线 | Mooncake Store | 倍数 |
|---|---|---|---|
| Cache hit rate | 1.7% | 92.2% | +54× |
| Throughput | 基准 | 3.8× | — |
| P50 TTFT | 基准 | −46× | — |
| 端到端延迟 | 基准 | −8.6× | — |
Agent 场景的跨请求前缀共享远高于最初预期——一旦系统支持分布式 KV 池，收益是阶跃式的。
来源：主站 reading vLLM × Mooncake Store
Agentic 负载的三种退化模式¶
2026 Q1-Q2 的 agentic KVCache 论文群显示，Agent 不是"更长的 chat"，而是状态积累型负载。典型退化模式有三类：
| 退化模式 | 现象 | 代表证据 |
|---|---|---|
| middle-phase thrashing | 大批量 agent 中间阶段 cache 命中率从 90% 崩到 40% 以下，49.1% 端到端延迟来自额外重计算 | CONCUR |
| 存储 I/O 瓶颈 | append 很短、历史 KV 很长，cache-compute 比率升到 22 GB/PFLOP 甚至 117–267 GB/PFLOP | DualPath |
| 结构化量化失配 | tool schema / CoT / obs token 敏感度不同，uniform low-bit 破坏关键语义 | TriAxialKV |
Agent 负载的调度粒度也在变化：CONCUR 用 AIMD 做 agent-level admission control；HexAGenT 把请求建模为在线 DAG；Helium 用查询计划视角消除跨调用冗余；MARS 将 GPU 推理和 CPU 工具执行共同纳入延迟关键路径。这些工作共同说明，KVCache 优化必须与 workflow-level 调度结合。
来源：主站 essay Agentic 推理的性能重构，主站 reading CONCUR：KV Cache 的 AIMD 时刻，主站 reading DualPath，主站 reading TriAxialKV
Regime 交叉：HBM Prefix Cache vs L2 KV Cache¶
LMCache 在 2 张 AMD MI300X 上重放 739 条匿名化 Claude Code agent trace，展示了一个容易被合成 benchmark 遮蔽的结论：L2 KV cache 是否有收益由 working set regime 决定。
| Regime | 推荐策略 | 证据 |
|---|---|---|
| <100K token working set | HBM prefix cache 足够 | 低负载 8 并发 / 32K 上下文时，HBM-PC 完成 52 请求 vs LMCache 25 |
| 100K–250K | 监控 HBM eviction，谨慎启用 L2 | LMCache connector 开销可能抵消收益 |
| 250K–500K | LMCache DRAM tier 必要 | 压力测试平均 TTFT 34.59s vs HBM-PC 102.17s；p95 112.78s vs 240.87s；完成请求数 28 vs 12 |
| >500K | 需要 NVMe / remote L3 | 单靠 DRAM tier 容量不足 |
合成 16K cache-rate benchmark 因为没有制造 HBM 压力，反而显示 LMCache 吞吐低于 HBM-PC 10–17%。因此 Agent KVCache benchmark 必须同时控制 prefix 复用和 HBM 压力。
来源：主站 field-note LMCache 在 AMD MI300X 上的部署实录
工程配置建议¶
| 配置项 | 推荐值 / 策略 | 原因 |
|---|---|---|
| Prefix Cache | 必开 | system prompt + task context 全员共享 |
| Block Size | 16（较细） | 工具调用断点处对齐，避免 sealed block 浪费 |
| 分布式 KV 池 | 推荐（Mooncake Store / LMCache） | 跨实例命中，agent 路由不受限于单副本 |
| Cache-aware routing | 推荐 | 同 task 的多次调用路由到同一副本 |
| cache_salt 隔离 | 多租户场景必开 | 不同用户 agent 的 KV 隔离 |
| Agent-level admission | 高并发 agent 批处理推荐 | 防止 middle-phase thrashing 和 LRU 颠簸 |
| L2/L3 tier | working set >250K token 后启用 | HBM prefix cache 不再能覆盖持续状态 |
关键指标¶
- Task 级 Prefix Cache 命中率：应关注单个 task 内跨调用的累积命中率，而非单次请求命中率
- cache_creation_tokens 占比：越低越好；超过 20% 说明大量 prefix 未命中
- 工具调用后的 TTFT：反映工具注入后重新 prefill 的效率
- 分布式 KV 池命中率：Mooncake Store / LMCache 的跨实例命中率
- middle-phase hit-rate trough：衡量 agent 批处理是否进入 cache thrashing
- sustained working set：决定是否从 HBM prefix cache 切到 L2/L3 tier
关联章节¶
- 共享 KV block 的引用计数机制：Paged KV
- 跨实例 KV 池的工程实现：存储层级
- cache_salt 隔离与路由策略：路由与亲和性
- Agent 评估框架与研究空白：Benchmark 与工具
- Agent 负载下 PD 分离的 I/O 瓶颈：PD 分离
版本历史¶
| 版本 | 日期 | 说明 |
|---|---|---|
| v0.2 | 2026-06-02 | 新增 agentic 负载三种 KV 退化模式、CONCUR/DualPath/TriAxialKV 证据与 LMCache MI300X regime 交叉 |
| v0.1 | 2026-05-14 | 从工作负载总览拆分，保留 Claude Code 与 Mooncake Store 实证数据 |