返回 文章 apply CMS 文章

更小、更快、更安全:Cloudflare 如何大规模运行 Kimi 和 GLM

了解 Cloudflare 如何通过三项关键技术优化大型模型推理,提升吞吐量并降低成本。

KV缓存量化模型压缩推理优化
成长分 / 100 84 综合收获、行动、留存与影响

更小、更快、更安全:Cloudflare 如何大规模运行 Kimi 和 GLM
为什么值得读揭示大规模 AI 推理中的内存瓶颈与解决方案

提供量化 KV 缓存和权重压缩的实测数据与精度对比

关键洞察
  1. FP8 KV 缓存使上下文容量翻倍,吞吐量提升 41%,成本降低 30%
  2. INT4 权重压缩使 GLM 5.2 检查点缩小 40%,解码速度提升 55%
  3. KV 缓存完整性检查开销低于 1%,保障共享缓存安全
转成行动

深入阅读

正文与原文对照

原文保真覆盖:全文原文字符:8099

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

Workers AI 在 Cloudflare 数据中心靠近用户的 GPU 上为一些世界上最好的开放模型运行推理。其中两个最强大且要求最高的模型是 Moonshot 的 Kimi K 系列和 Z.ai 的 GLM。它们是大型、长上下文、混合专家模型,使用起来非常棒。但由于内存限制,它们也很难高效服务。

我们之前写过关于如何在 Workers AI 上服务大型模型 以及分离

推理阶段以充分利用每个 GPU 的文章。本文探讨了我们在此基础上叠加的三种技术,以将这些模型装入内存并保持其速度:量化 KV 缓存、压缩模型权重,以及由于这两者都将更多请求打包到共享硬件上,保护这些请求共享的缓存。这些优化使我们能够以更低的成本支持更多客户,且模型精度不变。

__预填充和解码阶段__我们所有的实验和生产流量都在使用 SGLang 运行和基准测试,这是一个开源的推理服务框架。我们发现 SGLang 在市场上提供了最佳性能,并且我们与 SGLang 团队紧密合作,将补丁和新功能上游化,使我们的工作对开源社区可用。

量化 KV 缓存

当模型生成文本时,它会将已处理的每个 token 的注意力键(K)和值(V)存储在称为 KV 缓存的结构中。缓存使模型能够扩展长对话,而无需在每个新 token 上重新读取整个上下文。对于长上下文模型,它增长迅速,通常是 KV 缓存(而不是模型权重)首先填满 GPU 内存。

默认情况下,缓存以 16 位精度(BF16)存储。我们改为以 8 位浮点(FP8,e4m3)存储,这使其大小减半。在 Kimi K2.6 上,这使我们可以容纳在内存中的上下文量从大约 686,000 个 token 增加到约 137 万个,是原来的两倍。

值得精确说明收益来自何处,因为它不是原始速度。量化缓存每个 token 会增加少量工作,因为 FP8 注意力内核必须在读取时转换值。它改变的是我们一次可以保持驻留的请求数量。以下测量是针对 Kimi K2.6 在分离式 H200 部署上的解码,直接比较注意力内核:

---|---|---|

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 缓存无法区分:

---|---|---|

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 权重无法区分:

---|---|---|---|

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 到达得更快。这种效果在低并发时最大,此时每请求延迟最为重要:

---|---|---|---|

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 下维持约每秒 10,160 token 的预填充速度,而在 INT4 下为 8,660。与 KV 缓存一样,分离式设计将这一权衡转化为选择而非妥协:我们在解码时使用 INT4,因为它更优;在预填充时使用 FP8,因为它更优。在我们运行的每个基准测试中,模型精度保持在 FP8 模型的 0.8 个百分点以内,使其质量无法区分。

保护共享的 KV 缓存

上述两种技术都有相同的效果:它们让更多请求同时共享一个 GPU 的内存。这种效率是核心,但也意味着数百个请求正在读写同一物理 KV 缓存的页面。使这变得快速的机制,如分页注意力、连续批处理、缓存重用,都依赖于精确的记账,而在我们的请求量下,即使是十亿分之一错误也会频繁出现。

因此,我们构建了 KV 缓存完整性检查作为防御层。思路很简单:每个物理缓存页面都有一个标签,当页面被重新分配时标签会改变,服务器记录每个请求期望使用的页面和标签。在支持的解码操作从缓存读取之前,会检查这些映射。如果不匹配,受影响的请求将被中止,而不是允许从错误的页面返回数据。

决定安全检查是否发布的问题是它的成本。我们在一个中型生产模型上进行了测量,采用两预填充、两解码配置,输入 8,192 token,输出 1,000 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线程组之间的竞争。该功能按部署启用,默认路径使用无操作跟踪器,没有可测量的开销,因此不需要它的部署无需付出任何代价。

后续计划

高效服务前沿模型是一个不断变化的目标,而这是其背后的持续工作。我们正在将FP8 KV缓存扩展到更多机群,在Blackwell(NVIDIA的GPU架构)上验证NVFP4权重,并致力于使完整性检查能够在任何地方以可忽略的成本保持开启。这些优化将使我们能够以更低的成本和相同的精度继续支持更多客户。

如果你觉得将最好的开放模型压缩到GPU上并为数百万开发者提供服务正是你感兴趣的问题,欢迎加入我们