# KV Cache 分层在什么场景下没用？

> KV Cache 分层的收益来自缓存命中。短对话、低并发、上下文从不重复、瓶颈在输出阶段，这四类负载收益有限。本文说明原因和自查方法。

网页地址: https://vuke.top/insights/when-kv-cache-tiering-does-not-help · 更新于 2026 年 11 月 12 日

发布于: 2026-11-12

**问题**: KV Cache 分层存储加速在哪些场景下没有效果？

**结论**: 缓存很少被命中的时候。短对话、低并发、每次请求的上下文都不重复的负载里，会话很少被逐出显存，逐出后也很少再回来，外置的 KV Cache 层没有多少内容可以读回，收益有限。瓶颈在输出阶段的负载同样受益不大。

## 收益是从哪里来的

KV Cache 分层只做一件事：会话的 KV Cache 被逐出显存之后，下次请求到来时把它读回来，省掉重新预填充。每命中一次，省一次预填充；没有命中，就什么也没省。

我们报告里的大幅收益，是在长上下文冷恢复负载下测得的：480B 模型、并发 16 时，整段重算的 TTFT p50 是 149.5 s [R2](https://vuke.top/evidence/R2)。这类负载恰好是命中价值最高的情形，不代表所有负载。

## 四类收益有限的负载

如果你的业务主要是下面这几种，在采购之前要格外谨慎。

- 短对话：上下文很短，预填充本身只要很少时间，读回省不下多少。
- 低并发：显存放得下所有活跃会话，几乎没有逐出，也就没有需要读回的缓存。
- 上下文从不重复：例如批量处理各不相同的文档，每个请求都是新的输入，没有可以复用的前缀。
- 瓶颈在输出阶段：输出很长、首 token 延迟只占总耗时一小部分的任务，决定体验的是每个 token 的生成速度，那取决于算力。

## 怎么判断自己属于哪一种

不需要猜，从线上日志里可以数出来。

- 会话的上下文长度分布：长上下文占多大比例。
- 会话的返回间隔：用户隔多久发下一轮，这段时间里它的缓存还在不在显存。
- 显存里 KV Cache 的逐出频率：逐出越频繁，潜在的命中越多。
- 首 token 延迟在总耗时里的占比：占比越高，优化它越有价值。

## 我们的建议

如果上面几项指标显示你的负载以长会话、多轮、高并发为主，这一层很可能值得做；如果不是，把预算花在别处更合适。

拿不准的时候，先用自己的负载做一次小规模联测，并把通过条件提前写下来。测出来没用，就在那里停下。这比任何一方的推测都可靠。

## 相关问题

### Agent 和代码助手这类负载属于哪一种？

通常属于收益明显的一类。它们的上下文长、轮次多，会话被逐出后再回来的情况很常见，正是缓存命中价值高的场景。具体能提升多少，仍然要用自己的会话分布实测。

## 相关实测报告

- [R2](https://vuke.top/evidence/R2) · FX100 KV Cache 性能测试报告（480B · TP8 长上下文） (AMD Instinct MI308X × 8 · ROCm 7.2)

## 外部参考资料

- [Efficient Memory Management for Large Language Model Serving with PagedAttention](https://arxiv.org/abs/2309.06180) · arXiv (SOSP '23). vLLM 的 PagedAttention 显存管理与 KV Cache 分页的设计动机
- [SGLang: Efficient Execution of Structured Language Model Programs](https://arxiv.org/abs/2312.07104) · arXiv (NeurIPS '24). 多轮对话与共享前缀场景下，前缀复用为什么有效