同一模型部署在不同在线服务中，KV缓存的最佳容量并不相同。大模型在线服务的KV缓存容量规划，关键不是把缓存设到最大，而是根据请求长度、同时运行的序列数和服务目标，决定资源该留给谁。交互聊天优先保障响应速度，长文档问答更在意上下文驻留，批量生成则通常更看重整体吞吐。
先算清每个令牌占多少缓存
对常见的自回归Transformer，单个序列每个令牌的KV缓存可粗略估为：2 × 层数 × KV头数 × 每头维度 × 每个数值占用字节数。前面的2分别对应键和值。实际占用还会受模型结构、缓存数据类型、张量并行切分及运行时内存管理影响，不能只看模型参数规模。
总需求可按活跃序列的令牌数求和，再加上运行时开销和安全余量。估算时使用高峰期的实际输入与输出长度分布，不要简单拿最大上下文长度乘请求数；只有请求确实同时运行并持有缓存时，才会共同占用这部分空间。大模型在线服务的KV缓存容量规划应以压测观测到的峰值为校正依据。
五类场景，五种取舍
1. 多轮交互聊天：把容量留给活跃会话
短消息请求本身占用较少，但会话并发和历史轮数可能持续增加。若目标是稳定的首 token 时延，可限制单轮输出上限，并为活跃会话设置合理的上下文窗口；会话结束或长时间空闲后释放缓存。代价是历史被截断时，模型可利用的信息也会减少。适合按高峰并发而不是注册用户总数来规划。
2. 长文档问答：控制长序列对并发的挤压
将整份长文档直接放入提示词，会使单个请求占用远高于普通聊天的缓存，少量长请求就可能挤压其他用户。可先用检索选出相关段落，再限制拼接后的上下文长度；如果业务必须保留长上下文，就应降低允许的同时运行数，并监控长短请求相互影响。这里的取舍是上下文完整度与并发能力。
3. 代码助手：利用共享前缀，但避免缓存无效内容
代码补全请求可能反复带有相同的系统指令或项目约定。前缀缓存可复用完全一致的提示词前缀，减少重复计算；但它不等于永久保存整个代码库，也不会让不同前缀自动共享缓存。应将稳定指令放在前部、动态代码放在后部，并按租户或项目边界管理缓存，避免跨用户复用不当。提示词频繁变化时，复用收益会下降。
4. 批量生成：用并发换吞吐，同时设定准入上限
摘要生成、内容改写等任务常可容忍排队，连续批处理能让多个序列共同运行，提高设备利用率；但活跃序列越多，KV缓存占用通常越大。可先设置最大运行序列数和输入、输出令牌上限，再观察排队时间、吞吐量及缓存不足导致的请求等待或中断。不要让尚未开始计算的排队请求提前占住全部缓存。
5. 带工具调用的智能体：谨慎决定是否保留中间状态
智能体可能先生成工具调用，再等待数据库查询或外部服务返回。若等待期间仍保留模型序列，缓存会被长时间占用；若释放后重新构造提示词，则要承担再次预填充的计算成本。工具响应快、会话连续性要求高时，可优先评估保留活跃状态；等待时间长、并发压力大时，释放后重建往往更利于周转。两种方式应通过真实工具延迟和请求量对比。
按可执行步骤落地容量规划
- 采样请求。统计不同场景的输入长度、输出长度、会话持续时间和高峰并发，区分短请求与长请求。
- 估算单序列占用。依据模型层数、KV头数、头维度和缓存精度计算理论值，再通过所用推理框架的运行数据核对。
- 设定准入规则。配置最大上下文、最大运行序列数及排队策略；长请求可单独限流，避免少数请求耗尽缓存。
- 逐步压测。从保守并发开始增加负载，同时记录缓存占用、首 token 时延、吞吐和请求失败情况。预留余量的比例应随负载波动和运行时开销调整，并非固定常数。
- 复核复用收益。若使用 vLLM 等支持分页式KV管理的推理框架，应结合具体版本检查缓存块、前缀复用和驱逐行为；应用侧的Redis缓存与模型内部KV缓存用途不同，不能互相替代。
最终，大模型在线服务的KV缓存容量规划应由场景决定：交互服务保时延，长上下文服务控单请求占用，批量服务用排队换吞吐。先按真实负载估算，再通过压测调整并发、上下文和驱逐策略，比单纯增加缓存更可靠。
常见问题
KV缓存会随输出增长吗？
会。自回归生成过程中，新产生的令牌通常也要保存对应的键和值，因此输出上限会影响序列最终占用。
降低缓存精度一定能扩大并发吗？
不一定。较低精度可能减少缓存占用，但是否支持、精度影响及速度变化取决于模型、硬件和推理框架，应在目标负载下验证。
前缀缓存适合所有请求吗？
不适合。只有提示词前缀相同且复用机会足够时才更有价值；频繁变化的提示词会降低命中机会，还需考虑缓存管理成本。
容量不足时先加设备还是限流？
先判断瓶颈：若峰值并发由少数超长请求造成，可先限制上下文或分级准入；若常态负载已超过单机能力，再评估增加设备或调整部署方式。
