Kimi 与 GLM 大模型推理的显存优化实践

背景

Kimi K 系列和 GLM 都属于能力较强、资源需求也很高的开放模型。它们通常具备长上下文和混合专家（MoE）架构，在推理服务中最主要的挑战之一是 GPU 显存。

在大规模部署这类模型时，优化目标并不只是让单个请求更快，还包括：

• 在同一批 GPU 上容纳更多并发请求；
• 降低每个 token 的服务成本；
• 在优化显存和吞吐的同时，保持模型输出质量不受明显影响；
• 在共享缓存场景下避免请求之间的数据混淆。

相关实践主要围绕三类技术展开：KV Cache 量化、模型权重压缩，以及共享 KV Cache 的完整性检查。

1. KV Cache 量化：用 FP8 扩大上下文容量

模型生成文本时，会把已经处理过 token 的 attention keys 和 values 存在 KV Cache 中。KV Cache 让模型能够继续长对话，而不需要每生成一个 token 就重新读取全部上下文。

对于长上下文模型来说，KV Cache 增长非常快。很多时候，最先占满 GPU 显存的不是模型权重，而是 KV Cache。

默认情况下，KV Cache 通常以 16 位精度 BF16 存储。实践中将其改为 8 位浮点 FP8（e4m3）后，缓存大小可以减半。

以 Kimi K2.6 为例：

• BF16 KV Cache 可在显存中容纳约 68.6 万 token；
• FP8 KV Cache 可提升到约 137 万 token；
• 上下文容量约提升一倍。

需要注意的是，FP8 KV Cache 的收益并不是来自单 token 计算速度提升。相反，FP8 attention kernel 在读取缓存时需要做数值转换，因此单个并发水平下 BF16 每 token 速度会略快一些。

真正的收益在于：FP8 能让更多请求同时驻留在显存中。

在 Kimi K2.6 的解码测试中，BF16 在 32 个并发请求时已经用尽缓存，无法继续接纳第 33 个请求；FP8 则可以扩展到 64 个并发请求，并达到 2,192 tokens/s，约比 BF16 的峰值高 41%，每 token 成本约降低 30%。

由于推理被拆分为 prefill 和 decode 两个阶段，不同阶段可以采用不同策略：

• prefill 阶段主要受计算限制，因此继续使用 BF16，保持更高吞吐；
• decode 阶段更受显存和缓存容量影响，因此使用 FP8 KV Cache。

评测结果显示，在相关评估套件中，FP8 KV Cache 与 BF16 KV Cache 的模型输出质量没有可区分差异。

2. 模型权重压缩：GLM 5.2 从 FP8 到 INT4

除了 KV Cache，模型权重本身也是显存占用大户。

在 GLM 5.2 的部署中，模型权重从 8 位浮点压缩到 4 位整数 INT4。结果包括：

• checkpoint 从 705 GB 缩小到 421 GB，约减少 40%；
• 在 8 路张量并行部署中，每张 GPU 的权重显存占用从约 88 GB 降至约 52 GB；
• 相同硬件上可为 KV Cache 留出约 118 万 token 的空间。

评测显示，INT4 权重与 FP8 权重在评估套件中表现不可区分。

权重压缩对 decode 阶段尤其有利。生成每个 token 时，都需要从 GPU 显存中读取模型权重，因此 decode 速度往往受显存带宽限制。权重越小，需要搬运的数据越少，每个 token 生成也就越快。

这种收益在低并发场景下更明显，因为此时单请求延迟更关键。

但 prefill 阶段表现不同。prefill 通常是计算受限，而 INT4 权重在参与矩阵计算前需要解压回更高精度，这一步会引入额外开销。因此在 GLM 5.2 上：

• FP8 prefill 吞吐约为 10,160 tokens/s；
• INT4 prefill 吞吐约为 8,660 tokens/s。

因此更合理的部署方式是：

• decode 使用 INT4，获得更高速度和更低显存占用；
• prefill 使用 FP8，保持更高计算吞吐。

在相关基准测试中，INT4 模型与 FP8 模型的表现差异均在 0.8 分以内，质量被认为不可区分。

3. 共享 KV Cache 的完整性检查

KV Cache 量化和权重压缩都会让更多请求共享同一块 GPU 显存。这提升了效率，但也带来新的安全和可靠性问题。

在高并发推理中，paged attention、continuous batching、cache reuse 等机制都依赖精确的缓存页管理。大量请求同时读写同一物理 KV Cache，如果页映射或复用过程出现极小概率错误，也可能导致某个请求读取到错误缓存页中的数据。

为降低这种风险，可以在 KV Cache 上增加完整性检查层。

基本思路是：

1. 每个物理缓存页都有一个 tag；
2. 当缓存页被重新分配时，tag 会发生变化；
3. 服务端记录每个请求预期使用的缓存页和对应 tag；
4. 在受支持的 decode 操作读取缓存前，检查页映射是否匹配；
5. 如果发现不一致，则中止受影响请求，而不是返回来自错误缓存页的数据。

这类安全检查能否上线，关键在于开销。

在一个中等规模生产模型上，以 2 个 prefill、2 个 decode 配置，输入 8,192 token、输出 1,000 token 的测试中，完整性检查对吞吐和尾延迟的影响都低于 1%，95% 置信区间上界也接近 1%。

实现上，验证作为独立批量检查执行，而不是融合进 attention kernel，以避免 GPU 线程组之间产生竞态。该功能可以按部署启用；默认路径使用 no-op tracker，因此不需要该检查的部署不会承担可测量开销。

4. 小结

这组优化体现了大模型推理服务中的一个核心思路：不同阶段的瓶颈不同，应采用分阶段、分资源的优化策略。

• KV Cache 使用 FP8，主要解决长上下文和高并发下的显存瓶颈；
• GLM 5.2 decode 阶段使用 INT4 权重，减少显存带宽压力；
• prefill 阶段继续使用更适合计算吞吐的 FP8 或 BF16；
• 在更多请求共享缓存的同时，引入 KV Cache 完整性检查，降低跨请求数据混淆风险。

后续方向包括在更多部署中扩展 FP8 KV Cache、验证 Blackwell 架构上的 NVFP4 权重，并进一步降低完整性检查的成本。