Cloudflare 公开了在 Workers AI 上部署 Kimi K2.6 和 GLM 5.2 的三项优化：把解码阶段的 KV Cache 从 BF16 压到 FP8、把 GLM 权重从 FP8 压到 INT4，并为共享缓存加入完整性标签。所有实验和生产流量均运行在开源推理框架 SGLang 上。

一句话结论：量化不是把所有数据统一压成更低位数；Cloudflare 的收益来自先把预填充和解码拆开，再分别选择吞吐、显存和计算成本最合适的精度。

KV Cache 保存模型已经处理过的注意力键和值，长上下文越长，占用越大。Cloudflare 把 Kimi K2.6 解码缓存从 BF16 改成 FP8 后，可驻留上下文从约 68.6 万 token 增加到 137 万。单个并发档位下 BF16 反而快几个百分点，但它在 32 个并发请求后耗尽缓存，FP8 可以继续到 64 个并发。

在 Cloudflare 的 H200 解码测试中，FP8 最高达到每秒 2192 token，比 BF16 峰值高约 41%，每 token 成本低约 30%。这里的提升来自容纳更多并发，不是每个请求都自动快 41%。其公开评测里，两种缓存精度在 GSM8K、MMLU 和工具调用等指标上接近，但这些仍是公司自己的测试套件。

GLM 5.2 的权重量化又是另一笔账。INT4 把检查点从 705GB 缩到 421GB，八路张量并行时单卡权重占用从约 88GB 降至 52GB。解码阶段每生成一个 token 都要读取大量权重，因此 INT4 在低并发下最高快 55%。

但预填充是计算密集型，INT4 还要在乘法前展开，吞吐反而从每秒约 10160 token 降到 8660。Cloudflare 的做法是预填充保留 FP8，解码使用 INT4。问题不在“INT4 好不好”，而在工作负载在哪个阶段受限。

更多请求共享同一块物理缓存也扩大了隔离风险。Cloudflare 为每个缓存页增加随重新分配变化的标签，读取前核对请求预期映射；不匹配就终止请求。公开测试称吞吐和 P95 延迟开销都低于 1%，但该检查目前按部署启用，并非所有路径默认开启。

关键事实

• Kimi 优化：FP8 KV Cache 将可驻留上下文从约 68.6 万增至 137 万 token
• GLM 优化：INT4 将权重检查点从 705GB 压至 421GB
• 阶段差异：INT4 提高解码速度，却降低 GLM 的预填充吞吐
• 隔离措施：缓存页标签检查的公开测试开销低于 1%

OC 判断

这篇工程稿最有价值的结论不是“低精度不掉点”，而是量化必须和推理阶段一起设计。任何团队复用这些数字前，都应重测自己的上下文长度、并发、首 token 延迟和评测集，不能把云厂商结果当成模型的通用属性。

为什么重要

• 对开发者：优化推理前要区分预填充和解码瓶颈，单看总 token/s 会掩盖真实延迟。
• 对模型厂商：开放权重能让服务商针对硬件重新量化和组合运行策略。
• 对企业：更低成本来自更高共享密度，缓存隔离和请求审计也必须同步加强。

参考来源

• Cloudflare: Smaller, faster, safer models
• SGLang documentation
• Moonshot AI Kimi
• Z.ai GLM