评估大模型在线服务的KV缓存容量规划，不能只看模型能处理多长的上下文，还要看高峰时有多少请求同时驻留、每个请求实际占用多少缓存，以及服务是否满足延迟目标。容量增加可以减少因缓存不足造成的排队或请求受限，但并不意味着并发会按相同比例增长。
先算清每个令牌的缓存成本
自回归生成时，系统会为已处理的输入令牌和已生成的令牌保存键、值张量。常见的估算公式是：每令牌缓存字节数≈2×层数×KV头数×每头维度×每元素字节数。系数2代表键和值；实际分配还可能受到缓存块、对齐方式和运行时实现影响。
以一个假设配置为例：32层、8个KV头、每头维度128，使用BF16（每元素2字节）。估算结果为每令牌约128KiB；若一个请求当前共占用8,000个令牌，缓存约为1GiB。这里的配置只用于展示计算方法，不代表某个具体模型。若模型采用不同注意力结构、精度或上下文长度，结果会相应变化。
请求占用应按实际输入与已生成内容计算，而不是直接拿用户填写的最大上下文长度代替。对输入长度和输出长度波动较大的业务，建议用压测日志统计平均值与高分位数，避免平均数低估高峰需求。
从缓存预算推算并发，而不是承诺固定倍数
可用于KV缓存的显存，约等于设备显存减去模型权重、运行时工作区、临时张量和安全余量。再用这部分预算除以单个请求的驻留缓存，就能得到理论并发上限。它只是容量上限估算：实际吞吐还受计算能力、调度方式、输入长度和延迟服务目标影响。
例如，按上述假设，每个请求平均驻留约1GiB，若经测量可分配给缓存的预算为24GiB，粗略上限约为24个同等请求。真实服务还要给长度较大的请求、缓存分配开销和其他运行任务留空间，因此应以压测结果而非这个除法值作为上线依据。提高缓存预算可能提升可驻留请求数；如果瓶颈已经转为计算或网络，增加缓存就不会带来同等幅度的吞吐提升。
在线服务的评估步骤
- 建立输入分布：从脱敏后的请求统计中整理输入令牌数、输出长度、并发峰值和请求到达速率；区分短问答、长文档等真实负载类型。
- 核对可用显存：在目标模型、精度和推理框架下启动服务，记录权重与运行时占用，确定缓存预算，并预留安全空间。显存水位需结合设备和框架观察，不宜把理论总显存全部分给缓存。
- 分档压测：固定模型、硬件、采样参数和请求样本，逐步增加并发。每档记录吞吐、首令牌延迟、生成速度、排队情况、缓存占用及错误率；同时测试短请求与长请求混合的负载。
- 按服务目标确定配置：若缓存不足时出现请求等待或无法接纳，可在不突破显存余量的前提下提高缓存容量；若首令牌延迟已超目标，先检查排队、预填充耗时和计算利用率，避免只扩缓存。
- 复测变更：调整最大缓存、最大批次或连续批处理相关参数后，重复相同负载测试。比较满足延迟与错误率要求时的稳定吞吐，而非只比较瞬时峰值。
配置取舍：容量、长度与延迟
容量设得偏小，长请求可能更早触及限制，缓存压力也可能导致排队；设得过大，则会挤占模型运行所需的其他显存，降低稳定性。连续批处理可以让不同请求动态加入或离开批次，提高设备利用率，但它不会减少每个活跃令牌本身需要保存的KV数据。
因此，大模型在线服务的KV缓存容量规划应围绕目标负载和延迟SLO制定。短请求占多数时，平均驻留长度可能较低；长上下文请求较多时，单请求成本会显著增加。更有效的做法是先测真实请求分布，再为高峰和长度波动留出余量，而不是仅凭模型支持的最大上下文长度定容量。
常见问题
缓存容量增加一倍，并发也会增加一倍吗？
只有在缓存确实是主要瓶颈、请求长度相近且其他资源充足时，理论容量上限才可能接近同比变化；实际可服务并发还受计算和延迟限制。
应该按平均请求长度还是最长长度规划？
平均值适合初步估算；上线容量应结合长度分布和高分位请求测试。若业务要求接纳超长请求，还要单独验证它们对其他请求的影响。
显存还有空余，为什么并发没有提升？
瓶颈可能在预填充计算、生成速度、调度、网络或延迟目标。应查看分阶段指标和压测曲线，确认缓存是否真正限制请求接纳。
