缓存预算不应理解为“尽可能多占用显存”，而应理解为：在既定 SLO 下，为 KV 缓存分配多少资源，以及这些资源能够换来多少时延、吞吐和并发收益。企业真正要优化的不是缓存利用率，而是单位显存投入对 TTFT、ITL、P95/P99 时延和请求成功率的改善。
先把 SLO 转成资源约束
不同业务的预算重点并不相同。在线客服通常更关注 TTFT 和端到端 P95；代码补全更关注首字延迟与 ITL；Agent 工作流需要观察单步时延、任务总时长和失败率；批量推理则可以牺牲单请求时延，优先追求吞吐和单位成本。
容量规划至少要同时估算单请求和峰值并发下的 KV 缓存占用。近似公式为：
M_KV ≈ 2 × L × T × H_KV × D × B
其中，L 是模型层数，T 是请求需要缓存的 Token 数，H_KV 是 KV 头数量，D 是每个头的维度，B 是单个元素的字节数。该结果只能作为理论基线，实际预算还要考虑缓存块粒度、分页管理、前缀共享、精度、并发长度差异和运行时开销。
显存预算应划分为模型权重、运行时空间、KV 缓存和安全余量。安全余量不能被缓存耗尽，否则突发长上下文、动态批处理或临时工作区增长，都会使平均状态下的“可用容量”在峰值时失效，并表现为排队、驱逐、超时甚至 OOM。
用实验决定预算，而不是凭利用率拍板
评估时应建立无缓存、单请求 KV 缓存、前缀缓存、分页式管理和缓存卸载等基线，分别观察 TTFT、ITL、端到端时延、P95/P99、排队时间、显存峰值、缓存命中率和可承载并发。测试负载不能只使用高度重复的长提示词，还要覆盖低重复、中重复和高重复场景，否则会高估前缀缓存收益。
当 Prefill 计算占比较高、稳定长前缀较多，且显存浪费主要来自预分配或碎片时，应优先优化缓存；当模型权重已占据大部分显存、长上下文是刚性需求，或频繁发生缓存驱逐和请求拒绝时，扩容更合理；若缓存优化与扩容仍无法同时满足成本和 SLO，则应调整模型、上下文组织或服务架构。
最终预算应由“缓存命中率—显存峰值—尾延迟—单位成本”共同决定，而不是由单一的显存利用率决定。