大规模服务 Kimi 与 GLM：KV 缓存量化、权重压缩与缓存安全
Workers AI 依托 Cloudflare 就近用户的数据中心内的 GPU，为全球顶尖开源模型提供推理服务。其中能力最强、资源需求最高的两款模型，是 Moonshot 的 Kimi K 系列与Z.ai的 GLM。它们均为大参数量、长上下文的混合专家模型，使用体验极佳，但受限于内存，高效部署难度极大。
我们曾撰文介绍过如何在 Workers AI 上部署大模型，以及如何拆分推理的填充（prefill）与解码（decode）阶段，提升单 GPU 的利用率。本文将在此基础上，进一步介绍三种优化技术：KV 缓存量化、模型权重压缩，以及针对多请求共享缓存的保护机制。这些技术可在不损失模型精度的前提下，让模型适配 GPU 内存并保持推理速度，最终帮助我们以更低成本服务更多客户。
我们所有的实验与生产流量，均基于开源推理服务框架SGLang运行并完成基准测试。我们发现，SGLang 是当前市场上性能最优的框架，因此与 SGLang 团队深度合作，将我们的补丁与新特性贡献至上游代码，回馈开源社区。
KV 缓存量化
模型生成文本时，会将已处理过的所有 token 的注意力键（K）与值（V）存储在一个名为 KV 缓存的结构中。借助这一缓存，模型无需在生成新 token 时重新读取全部上下文，就能延续长对话。对于长上下文模型而言，KV 缓存会快速膨胀，通常是它而非模型权重率先占满 GPU 内存。
默认情况下，缓存以 16 位精度（BF16）存储。我们改为使用 8 位浮点格式（FP8，e4m3）存储，将缓存体积压缩至原来的一半。以 Kimi K2.6 为例，内存可容纳的上下文 token 数量从约 68.6 万提升至 137 万，实现翻倍。
需要明确的是，这一优化的核心优势并非原始速度。量化缓存会给每个 token 的处理增加少量计算量，因为 FP8 注意力内核读取时需进行格式转换。真正的提升在于单 GPU 可同时承载的请求数。以下为 Kimi K2.6 在分布式 H200 部署环境下的解码性能数据，直接对比两种注意力内核：
| 并发请求数 | BF16 吞吐量（tokens/秒） | FP8 吞吐量（tokens/秒） |
|---|---|---|
| 1 | 137 | 125 |
| 8 | 731 | 689 |
| 16 | 1,106 | 1,028 |
| 32 | 1,558 | 1,489 |
| 64 | 内存不足 | 2,192 |
在任意并发水平下，BF16 的单 token 处理速度都略快几个百分点。但 BF16 在并发数达到 32 时就会耗尽缓存，无法接收第 33 个请求；而 FP8 可支持到 64 并发，吞吐量达 2192 tokens/秒，比 BF16 的峰值高出约 41%，同时单 token 成本降低约 30%。由于我们将填充与解码阶段拆分为独立资源池，可按需应用优化：填充阶段受算力而非内存限制，因此保留 BF16 缓存以维持稍高的吞吐量。
若量化会改变模型输出结果，上述优化便毫无意义，因此我们开展了验证。在全量测试集上，FP8 与 BF16 缓存的表现难分伯仲：
| 测试集 | BF16 得分 | FP8 得分 |
|---|---|---|
| GSM8K | 94.24 | 94.09 |
| ARC-Easy | 89.06 | 89.14 |
| ARC-Challenge | 66.72 | 67.49 |
| MMLU | 89.11 | 89.04 |
| MMLU-Pro | 80.29 | 79.29 |
| mcxams（内部基准测试） | 61/63 | 61/63 |
| 工具调用有效性 | 92.2% | 92.6% |
模型权重压缩
GPU 内存的另一主要占用项是模型权重。针对 GLM 5.2，我们将权重从 8 位浮点（FP8）压缩至 4 位整数（INT4），且未损失任何精度。模型 checkpoint 体积从 705GB 缩减至 421GB，压缩比约 40%；在 8 路张量并行部署中，单 GPU 内存占用从约 88GB 降至 52GB，同款硬件可额外容纳约 118 万 token 的 KV 缓存。
在全量测试集上，INT4 与 FP8 权重的表现无显著差异：
| 测试集 | 评估指标 | FP8 得分 | INT4 得分 |
|---|---|---|---|
| GSM8K | 完全匹配率 | 94.39% | 93.56% |
| GSM8K | 灵活匹配率 | 94.24% | 93.48% |
| ARC-Easy | 准确率 | 86.62% | 86.15% |
| ARC-Easy | 标准化准确率 | 84.51% | 85.19% |
| ARC-Challenge | 准确率 | 64.93% | 64.85% |
| ARC-Challenge | 标准化准确率 | 67.24% | 66.64% |
| MMLU | 平均准确率 | 86.60% | 86.54% |
| MMLU-Pro | 完全匹配率 | 80.80% | 80.47% |
| mcxams（内部基准测试） | 通过数 | 62/63 | 62/63 |
更小的权重还能加快解码速度，原因很明确：生成每个 token 都需要从 GPU 内存中读取模型权重，因此解码速度受限于内存带宽。数据传输量减少，token 生成自然更快。这一效果在低并发场景下尤为显著——此时单请求延迟是核心关注点：
| 并发请求数 | FP8 吞吐量（tokens/秒） | INT4 吞吐量（tokens/秒） | 提升幅度 |
|---|---|---|---|
| 1 | 60 | 92 | +55% |
| 8 | 425 | 513 | +21% |
| 16 | 683 | 825 | +21% |
| 32 | 994 | 1,267 | +27% |
| 64 | 1,672 | 1,933 | +16% |
填充阶段的表现则有所不同。该阶段受算力限制，且 INT4 权重需先扩展为更高精度才能参与模型计算，额外的转换步骤会拖慢填充速度：GLM 采用 FP8 权重时，填充吞吐量约为 10160 tokens/秒，而 INT4 权重下仅为 8660 tokens/秒。得益于分布式架构，我们无需妥协，可灵活选择：解码阶段用 INT4 以提速，填充阶段用 FP8 以保性能。在所有测试中，INT4 模型的精度与 FP8 模型的差距均在 0.8 个百分点以内，质量表现基本一致。
共享 KV 缓存保护
上述两项技术带来了相同的效果：让更多请求可同时共享单 GPU 内存。这种高效性正是优化的核心目标，但也意味着数百个请求会同时读写同一块物理 KV 缓存的不同页。分页注意力、连续批处理、缓存复用等提升性能的机制，都依赖精准的账目管理；以我们的请求量规模，即便十亿分之一的错误概率，也会导致问题频繁出现。
为此，我们构建了 KV 缓存完整性检查机制作为防护层。逻辑十分简单：为每一块物理缓存页分配一个标签，缓存页重新分配时标签同步更新；服务器记录每个请求预期使用的缓存页及对应标签。在支持的解码操作读取缓存前，系统会核对这些映射关系。一旦发现不匹配，就终止受影响的请求，避免返回错误缓存页的数据。
安全机制能否落地，关键在于其性能开销。我们在中型生产模型上进行了测试，采用 2 填充、2 解码的配置，输入为 8192 token，输出为 1000 token：
| 并发请求数 | 吞吐量变化 | 尾部延迟变化 |
|---|---|---|
| 1 | −0.53% | +0.42% |
| 2 | −0.38% | +0.54% |
| 4 | −0.79% | +0.63% |
| 8 | −0.43% | +0.80% |
该机制对吞吐量和尾部延迟的影响均低于 1%，即便 95% 置信区间的上限也接近 1%。为控制计算开销，我们将验证作为独立批量任务执行，而非融合进注意力内核——后者会引发 GPU 线程组间的竞争。这一机制按部署实例启用，默认采用无操作追踪器，无 measurable 性能损耗，无需该功能的部署实例不会产生任何额外成本。
未来规划
高效部署前沿大模型是一个动态演进的课题，上述工作正是我们持续探索的一部分。我们正将 FP8 KV 缓存推广至更多服务器节点，验证 Blackwell（NVIDIA 新一代 GPU 架构）上的 NVFP4 权重，并致力于实现完整性检查机制的全场景启用，且将其性能开销降至可忽略不计。这些优化将帮助我们继续以更低成本、同等精度服务更多客户。
如果你热衷于研究如何将顶尖开源模型高效部署在 GPU 上，并服务数百万开发者，欢迎加入我们。