在边缘 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 完整性检查——并给出了相应测试数据。在所测模型与基准上，量化前后的得分差异控制在 1 个百分点以内。
三项技术分别减少缓存占用、压缩权重，并检查请求是否读到了正确的缓存。Cloudflare 还将输入处理与逐词生成分配到不同 GPU 池，让两个阶段分别采用适合的配置。
缓存改用 FP8 后，测试中的并发容量翻倍
大模型推理时，注意力机制的 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%）同样不可区分。
压缩 GLM 权重后，生成变快、处理输入变慢
对于 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%）。并发越低，加速越明显——这对关注持续输出速度的交互式场景尤为重要。
但 prefill（一次性处理整个输入上下文）是 compute-bound 的。INT4 权重在计算前必须先反量化回更高精度，这一步额外开销使 prefill 速度从约 10,160 tok/s 降至 8,660 tok/s。同样的优化在不同的推理阶段产生了相反的效果。
精度方面，FP8 与 INT4 权重在全部评测基准上差距均小于 0.8 个百分点。MMLU 得分分别为 86.60% 和 86.54%，内部评测 63 题中两者都通过了 62 题。
读取缓存前校验标签，发现请求错用页面就中止
前两项优化的共同效果是让一块 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 社区保持紧密协作，向上游提交补丁和新特性——这也意味着这些优化最终可能惠及更广泛的开源推理生态。
客户能省多少钱、哪些部署已启用，仍待说明
这些测试还不足以回答所有部署问题。有几项关键信息博文没有涉及。
成本数据缺失。 文中没有给出任何定价信息，也没有说明这些优化为客户带来的单位成本下降幅度。考虑到 Workers AI 采用按推理量付费的 serverless 模式，优化对 Cloudflare 自身毛利率的影响和对客户价格的影响是两个不同的问题，目前都无法评估。
优化覆盖范围不明确。 INT4 权重压缩目前仅针对 GLM 5.2，KV cache 完整性检查仍处于"按部署启用"阶段而非全站默认。文中提到团队正将 FP8 KV cache 推广到更多机型、在 Blackwell 架构上验证 NVFP4 权重、并致力于将完整性检查变为零开销的全站默认——这些仍处于进行中状态。
自研引擎 Infire 与 SGLang 的关系。 Cloudflare 此前公开了自研的 Rust 推理引擎 Infire，用于支持多 GPU、量化等高级特性。但本次博文的所有实验和生产流量均基于 SGLang。Infire 在 Cloudflare 推理系统中的角色是什么，本文没有说明。
Cloudflare 的生产实践为开源推理框架提供了一个具体案例：以 SGLang 为基础运行 Kimi K2.6 和 GLM 5.2，并公开部分优化测试。公司业务覆盖全球 337 个城市，但这不等于上述模型或每项优化已经覆盖所有节点；实际部署范围仍需与前述说明区分。
Cloudflare 接下来要回答的是：当优化让 GPU 利用率更高时，节省的成本有多少会回到开发者手中。
