Cloudflare 三招让大模型在 GPU 上跑得更快、更省、更安全
KV 缓存量化、权重压缩、缓存完整性检查——三项技术让 Kimi K2.6 和 GLM 5.2 在 Workers AI 上高效运行，精度几乎无损。
60 秒版本
Cloudflare 的 Workers AI 团队公布了三种大规模 MoE 模型推理优化技术：FP8 KV 缓存量化、INT4 权重压缩、KV 缓存完整性检查——精度几乎无损。
要点
- FP8 KV 缓存让上下文容量翻倍（68.6 万→137 万 token），64 并发时吞吐提升 41%
- INT4 权重压缩将 GLM 5.2 从 705GB 缩至 421GB，低并发解码速度提升最高 55%
- KV 缓存完整性检查开销低于 1%，防止大规模部署中的数据交叉污染
- 分离式预填充/解码架构是关键——让每项优化用在最合适的地方
结论. 实实在在的效率提升，无精度牺牲。分离式架构是关键——把妥协变成了选择。
问题大模型，更大的内存需求
在 GPU 上跑大型 MoE 模型是个内存难题。模型权重占地方，KV 缓存——存每个 token 注意力键值对的草稿本——占的地方更大。对于 Kimi K2.6 和 GLM 5.2 这类长上下文模型，KV 缓存先填满 GPU 内存，限制了能共享一块 GPU 的请求数量。
Cloudflare 的 Workers AI 团队详细介绍了三种叠加在现有分离式预填充-解码架构之上的优化技术。所有实验基于 SGLang，补丁已回馈开源社区。
技术一KV 缓存量化（FP8）
默认 KV 缓存用 16 位 BF16 精度存储。Cloudflare 换成 8 位 FP8（e4m3），大小减半。Kimi K2.6 的上下文容量从约 68.6 万 token 提升到 约 137 万——翻倍。
代价是 FP8 注意力核需要转换数值，每个请求慢几个百分点。但真正的收益是容量。64 并发时，FP8 达到 每秒 2192 token——比 BF16 峰值 1558 高 41%，每 token 成本低约 30%。
| 并发请求数 | BF16 KV (tok/s) |
|---|---|
| 1 | 137 |
| 8 | 731 |
| 16 | 1,106 |
| 32 | 1,558 |
| 64 | 内存不足 |
由于分离式架构，FP8 只用在解码阶段。预填充是计算密集型的，保留 BF16 以获得更高吞吐。
技术二权重压缩（INT4）
GLM 5.2 的权重从 8 位 FP8 压缩到 4 位 INT4。检查点从 705GB 缩小到 421GB（减少 40%），8 路张量并行部署下每 GPU 内存从约 88GB 降到 52GB，腾出空间容纳约 118 万 token 的 KV 缓存。
| 并发请求数 | GLM FP8 (tok/s) |
|---|---|
| 1 | 60 |
| 8 | 425 |
| 16 | 683 |
| 32 | 994 |
| 64 | 1,672 |
INT4 解码更快，但预填充更慢（INT4 权重需要展开才能做矩阵乘法）。分离式架构下，Cloudflare 解码用 INT4，预填充用 FP8——两全其美。精度与 FP8 相差不超过 0.8 个百分点。
技术三KV 缓存完整性保护
前两项技术让更多请求共享一块 GPU，但也意味着几百个请求在读写同一块物理 KV 缓存。在 Cloudflare 的请求量级下，十亿分之一概率的错误也会频繁出现。
方案：每个物理缓存页分配一个标签，页面重新分配时标签改变。解码操作读取缓存前，服务器检查标签匹配。不匹配则中止该请求，防止数据串到别人那里。
| 并发数 | 吞吐变化 |
|---|---|
| 1 | −0.53% |
| 2 | −0.38% |
| 4 | −0.79% |
| 8 | −0.43% |
开销低于 1%。检查作为独立批处理操作运行，而非融合到注意力核中，避免了 GPU 线程组之间的竞态条件。
下一步扩大覆盖范围
Cloudflare 正将 FP8 KV 缓存推广到更多部署，在 Blackwell 上验证 NVFP4 权重，并努力让完整性检查以可忽略的成本成为默认配置。
这些优化已在生产中运行，让 Cloudflare 以更低成本支持更多客户，且模型精度不变。