更小、更快、更安全：大规模运行Kimi和GLM

# 更小、更快、更安全：大规模运行 Kimi 和 GLM 来源：https://blog.cloudflare.com/smaller-faster-safer-models/ Workers AI 在 Cloudflare 数据中心靠近用户的 GPU 上，为世界上一些最优秀的开源模型运行推理。其中功能最强大、要求也最高的两个模型是 Moonshot 的 Kimi K 系列和 [Z.ai](http://z.ai/) 的 GLM。它们是大型、长上下文、混合专家模型，使用体验非常好。但受内存限制，要高效地服务它们也非常困难。 我们之前已经写过如何在 [Workers AI 上服务大型模型](https://blog.cloudflare.com/workers-ai-large-models/)，以及如何将推理的[预填充和解码阶段分开](https://blog.cloudflare.com/high-performance-llms/)，从而从每块 GPU 中榨取更多性能。本文介绍在此基础之上叠加的三项技术，目的是将这些模型装入内存并保持快速：量化 KV 缓存、压缩模型权重，以及——由于这两项技术都会让更多请求共享同一硬件——保护这些请求共享的缓存。这些优化使我们能够以更低的成本支持更多客户，且模型精度不变。 所有实验和生产流量均使用 [SGLang](https://github.com/sgl-project/sglang) 运行并进行基准测试，SGLang 是一个开源推理服务框架。我们发现 SGLang 在市场上提供了最佳性能，并且我们与 SGLang 团队密切合作，将补丁和新功能贡献到上游，使我们的工作可供开源社区使用。 ## 量化 KV 缓存 当模型生成文本时，它会将已处理的每个 token 的注意力键（K）和值（V）存储在一个称为 KV 缓存的结构中。缓存使模型能够扩展长对话，而无需在每次生成新 token 时重新读取整个上下文。对于长上下文模型，它增长很快，通常最先填满 GPU 内存的是 KV 缓存，而不是模型权重。 默认情况下，缓存以 16 位精度（BF16）存储。我们改用 8 位浮点数（FP8, e4m3）存储，大小减半。在 Kimi K2.6 上，这使内存中可以容纳的上下文从大约 68.6 万个 token 提高到约 137 万个 token，容量翻倍。 值得准确说明好处来自哪里，因为它不是原始速度。量化缓存每个 token 会增加少量工作，因为 FP8 注意力内核在读取值时必须转换值。它改变的是我们一次能够驻留在内存中的请求数量。以下测量针对的是在分离式 H200 部署上进行的 Kimi K2.6 解码，直接比较注意力内核： | 并发请求数 | BF16 KV 缓存（tok/s） | FP8 KV 缓存（tok/s） | | --- | --- | --- | | 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，达到每秒 2,192 个 token，比 BF16 的峰值高出约 41%，每个 token 的成本降低约 30%。由于我们将预填充和解码作为独立的池运行，我们可以把这技术应用到最有帮助的地方：预填充受计算限制而非内存限制，因此我们在那里保留 BF16 缓存，并保持其略高的吞吐量。 如果它改变了模型的答案，这一切就都无关紧要了，所以我们进行了检查。在整个评估套件中，FP8 和 BF16 缓存没有可区分的差异： | 基准测试 | BF16 KV | FP8 KV | | --- | --- | --- | | 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% | ## 压缩模型权重 KV 缓存是对 GPU 内存的一种需求；模型权重则是另一种。对于 GLM 5.2，我们将权重从 8 位浮点数压缩到 4 位整数（INT4），且精度没有损失。检查点从 705 GB 缩小到 421 GB，约减少 40%；在 8 路张量并行部署中，每 GPU 内存从大约 88 GB 降至 52 GB，这为在同一硬件上留下大约 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 就能更早到达。这种效果在低并发时最明显，此时每请求延迟最为重要： | 并发请求数 | GLM FP8