在边缘 GPU 上运行 Kimi K2.6（1 万亿参数 MoE）或 GLM 5.2（7440 亿参数 MoE）这样的前沿模型，挑战不在算力，而在内存。KV cache 通常比模型权重更早撑满 GPU 显存，而多租户共享硬件又引入数据安全风险。Cloudflare Workers AI 团队 8 月 3 日公布了三项已投产的优化技术——FP8 KV cache 量化、INT4 权重压缩和 KV cache 完整性检查——构成一个完整的推理优化栈，每一项都有 benchmark 数据支撑，精度损失控制在 1 个百分点以内。
这三项技术共同回答了一个问题：在不牺牲模型质量的前提下，如何让一块 GPU 同时服务更多请求、跑得更快，并且不会串数据。答案的关键不在单项优化，而在 disaggregated prefill/decode 架构如何让不同技术各取所长。
FP8 KV cache：上下文容量翻倍，峰值吞吐提升 41%
大模型推理时，注意力机制的 key 和 value 矩阵被缓存在 GPU 显存中，避免每个新 token 都重复计算整个上下文。这个 KV cache 是推理阶段最大的显存消耗者——对于长上下文模型，它比权重本身更容易先撑爆显存。
Cloudflare 默认使用 BF16（16 位浮点）存储 KV cache。切换到 FP8（e4m3，8 位浮点）后，缓存体积减半。在 Kimi K2.6 的 disaggregated H200 decode 节点上，可容纳的上下文从约 68.6 万 token 扩容到约 137 万 token。
值得注意的是，FP8 量化 KV cache 并不是免费的。因为 attention kernel 需要在读取时将 FP8 值转换回更高精度，单并发场景下 FP8 的 decode 速度（125 tok/s）反而略低于 BF16（137 tok/s）。但 FP8 的真正收益在于并发密度：BF16 在 32 并发时就已耗尽显存，而 FP8 能支撑到 64 并发，达到 2,192 tok/s——比 BF16 的峰值（1,558 tok/s，32 并发）高出约 41%。
精度方面，在 GSM8K、ARC、MMLU、MMLU-Pro 和内部评测套件上，BF16 和 FP8 KV cache 的结果差异均在评测噪声范围内。以 MMLU 为例：BF16 版 89.11，FP8 版 89.04，差距仅 0.07 个百分点。工具调用有效性（92.2% vs 92.6%）同样不可区分。
INT4 权重压缩：decode 加速 55%，prefill 反而变慢
对于 GLM 5.2，Cloudflare 进一步将模型权重从 FP8 压缩到 INT4（4 位整数）。权重 checkpoint 从 705 GB 缩减到 421 GB，缩幅约 40%。在 8 路 tensor parallel 部署中，每 GPU 显存占用从约 88 GB 降至 52 GB，释放的空间足以容纳约 118 万 token 的 KV cache。
这项优化的效果高度依赖推理阶段。Decode（逐 token 生成）是 memory-bound 的——每生成一个 token 都要从显存中流式读取全部权重，因此带宽决定速度。权重减半意味着每次读取的数据量减半，decode 速度显著提升：单并发从 60 tok/s 跃升至 92 tok/s（+55%），64 并发从 1,672 tok/s 提升至 1,933 tok/s（+16%）。并发越低，加速越明显——这对关注首 token 延迟的交互式场景尤为重要。
但 prefill（一次性处理整个输入上下文）是 compute-bound 的。INT4 权重在计算前必须先反量化回更高精度，这一步额外开销使 prefill 速度从约 10,160 tok/s 降至 8,660 tok/s。同样的优化在不同的推理阶段产生了相反的效果。
精度方面，FP8 与 INT4 权重在全部评测基准上差距均小于 0.8 个百分点。MMLU 得分分别为 86.60% 和 86.54%，内部评测 63 题中两者都通过了 62 题。
KV cache 完整性检查：以不到 1% 的代价防串扰
前两项优化的共同效果是让一块 GPU 同时服务更多请求。这放大了另一个风险：在 paged attention 机制下，数百个并发请求共享同一个物理 KV cache，通过页面分配和回收来复用显存。如果页面分配的簿记（bookkeeping）出错，一个请求就可能读到另一个请求的缓存数据——这不是推测性的安全漏洞，而是在当前并发规模下统计意义上的必然事件。
Cloudflare 的方案很直接：每个物理 KV cache 页面附带一个标签（tag），页面每次重新分配时标签变更。服务器记录每个请求期望使用的页面和标签映射，在 decode 操作读取缓存前进行校验。一旦发现不匹配，立即中止受影响请求，而不是让它返回来自错误页面的数据。
这层检查的性能代价极低。在一个中型生产模型的 prefill/decode 分离部署上测试（8,192 token 输入、1,000 token 输出），吞吐量下降 0.38%–0.79%，p95 延迟增加 0.42%–0.80%。即使考虑 95% 置信区间上界，代价也仅约 1%。验证以批量检查方式独立于 attention kernel 运行，避免了 GPU 线程组之间的竞态条件。不启用该检查的部署使用无操作追踪器，零额外开销。
分离架构让优化各取所长
三项优化并非在所有场景下都表现一致：FP8 KV cache 在 decode 中取胜，但 prefill 使用 BF16 更快；INT4 权重在 decode 中大幅加速，但在 prefill 中反而变慢。Cloudflare 的解法是借助 disaggregated prefill/decode 架构——prefill 和 decode 运行在独立的 GPU 池上——为每个阶段独立选择最优配置：
- Prefill 池：BF16 KV cache + FP8 权重，优先保证计算吞吐
- Decode 池：FP8 KV cache + INT4 权重（GLM 5.2），优先保证内存效率和并发密度
这种灵活性只有在推理框架层面支持 disaggregated 部署时才能实现。Cloudflare 选用了开源框架 SGLang，该框架目前驱动着全球超过 40 万块 GPU，每天生成数万亿 token。博文还提到团队与 SGLang 社区保持紧密协作，向上游提交补丁和新特性——这也意味着这些优化最终可能惠及更广泛的开源推理生态。
三组数字背后的问题
Cloudflare 公布的数据全面但不完整。有几项关键信息博文没有涉及。
成本数据缺失。 文中没有给出任何定价信息，也没有说明这些优化为客户带来的单位成本下降幅度。考虑到 Workers AI 采用按推理量付费的 serverless 模式，优化对 Cloudflare 自身毛利率的影响和对客户价格的影响是两个不同的问题，目前都无法评估。
优化覆盖范围不明确。 INT4 权重压缩目前仅针对 GLM 5.2，KV cache 完整性检查仍处于"按部署启用"阶段而非全站默认。文中提到团队正将 FP8 KV cache 推广到更多机型、在 Blackwell 架构上验证 NVFP4 权重、并致力于将完整性检查变为零开销的全站默认——这些仍处于进行中状态。
自研引擎 Infire 与 SGLang 的关系。 Cloudflare 此前公开了自研的 Rust 推理引擎 Infire，用于支持多 GPU、量化等高级特性。但本次博文的所有实验和生产流量均基于 SGLang。Infires 在 Cloudflare 推理栈中的角色是什么，本文没有说明。
尽管如此，这份报告的真正价值不在 Cloudflare 一家公司的工程进展，而在于它展示了开源推理基础设施的成熟度。当 SGLang 这样由社区驱动的框架支撑着 Kimi K2.6 和 GLM 5.2——两个中国团队开发的前沿开源模型——在全球 337 个城市的边缘节点上运行，并且每一项优化都有完整 benchmark 公开时，"开源推理栈能否支撑生产级部署"这个问题已经有了答卷。
Cloudflare 接下来要回答的是：当优化让 GPU 利用率更高时，节省的成本有多少会回到开发者手中。