大模型在线服务的KV缓存容量规划，关键不是把显存尽量塞满，也不是给每个请求都按最大上下文分配空间，而是估算高峰期同时驻留的缓存令牌数。容量太小会频繁排队或中断生成；容量过大则挤占模型权重和运行时空间，增加显存投入，却未必提高吞吐。
先算每个令牌需要多少缓存
自回归模型会为各层保存注意力键和值。未量化时，可用下式估算单个令牌的KV缓存字节数：
每令牌字节数 ≈ 2 × 层数 × KV头数 × 单头维度 × 每元素字节数
公式中的“2”对应键和值；BF16或FP16通常按每元素2字节计算。以一个假设配置为例：32层、8个KV头、单头维度128、BF16缓存，每令牌约占128 KiB。单个请求若有8,192个令牌驻留，缓存约需1 GiB；32,768个令牌则约需4 GiB。这里的令牌包括已处理的输入和已经生成的内容，不等同于用户填写的最大上下文长度。
这是未计入块管理、对齐和实现差异的理论估算。分组查询注意力（GQA）使用的KV头数少于查询头数，计算时应取KV头数；多卡切分、缓存量化及推理引擎的分配方式也会改变单卡占用。最终数值应以部署配置和服务指标核对。
从请求分布推算高峰容量
实际需求取决于同时在服务的请求，而非单个请求的上限。若请求平均驻留令牌数为L，同时活动请求数为N，可先估算N×L，再乘以每令牌缓存量。更稳妥的做法是按输入长度、生成长度和并发分别查看高分位数，避免平均值掩盖长上下文请求。
例如，上述假设配置下，若高峰时有24个请求、每个平均驻留约8,000个令牌，基础缓存需求约为24 GiB。此估算不代表应直接预留24 GiB：还需计入运行时开销，并确认权重、计算工作区和其他进程能够在同一张卡上共存。使用连续批处理时，请求会动态加入和退出，缓存占用随活动令牌数变化；突发流量也可能让短时峰值高于日常均值。
显存预留要看整卡预算
可用显存不是设备标称容量本身。先减去模型权重、运行时工作区、通信缓冲区以及操作系统或其他进程占用，再为波动和显存碎片保留余量，剩下的才是缓存预算。余量可从可用显存的约10%—20%作为初始试算区间；这不是固定标准，长上下文、并发波动大或工作区变化明显时，应留得更宽。
KV缓存与权重的取舍也不能只看利用率。权重决定模型能否加载，缓存则影响可同时容纳的请求数和上下文长度。若服务以短请求为主，限制单请求最大令牌数通常比配置极大缓存更有效；若长文请求确实常见，则需要据其并发比例增加容量，或按长度分组调度。前缀缓存能复用相同前缀的计算结果，但是否节省空间、节省多少，取决于命中率、保留策略和引擎实现，不应预先当作确定收益。
按步骤校准容量
- 记录输入和输出长度。从服务日志统计请求长度分布、生成长度及高峰并发；区分普通请求与长上下文请求，不只看平均值。
- 按模型配置计算基线。确认层数、KV头数、头维度和缓存精度，估算每令牌占用；再按高峰活动令牌数换算容量。
- 核对整卡预算。用实际运行时的显存占用减去权重、工作区等固定开销，设置缓存上限并保留余量。vLLM等推理引擎的缓存管理参数和统计口径可能不同，应对照所用版本的文档与指标。
- 逐级压测并观察。从较低并发开始增加负载，记录缓存使用率、排队、请求失败、生成吞吐和显存峰值；测试长短请求混合，而非只测同一长度。
- 根据瓶颈调整。若缓存耗尽而计算资源尚有空间，可增加缓存预算或限制长请求；若显存紧张但缓存长期空闲，应下调上限。每次只调整一项，复测并保留回退配置。
常见问题
能否直接把最大上下文长度乘以并发数？
可以作为极端上界的粗略估算，但通常会高估需求。更合适的是用真实长度分布和高峰活动请求计算，同时为突发留出余量。
缓存占用率越高，服务越好吗？
不一定。高占用可能提高显存利用率，也可能让新请求等待或在波动时触顶。应结合吞吐、排队、失败率和显存峰值判断。
缓存量化后可以按比例减少显存吗？
理论上元素位宽降低会减少数据本身占用，但量化格式、缩放参数和实现开销会影响实际节省量；应以引擎实测为准。
结论：用负载校准，而非一次拍定
大模型在线服务的KV缓存容量规划，应从模型结构算出每令牌成本，再结合高峰活动令牌数与整卡预算确定初值，最后用长短请求混合压测校准。预留量不是越大越保险：让缓存覆盖目标负载，同时避免挤压权重和运行时空间，才是更可控的显存投入。
