Cloudflare揭秘：如何用量化技术在有限GPU内存上高效运行Kimi和GLM

当全球开发者涌入Workers AI平台调用Kimi和GLM等前沿开源模型时，Cloudflare的GPU基础设施面临着一个棘手的挑战：这些大型混合专家（MoE）模型对GPU内存的渴求远超普通模型。一篇在HN上获得156个赞的技术博客详细披露了Cloudflare如何在不断增长的流量下，用三项关键技术实现"更小、更快、更安全"的推理服务。

Cloudflare使用的是开源的SGLang推理框架，团队发现其性能在市场上领先，并与SGLang团队紧密合作向上游提交补丁。

KV缓存量化：从16位到8位，并发量翻倍

第 一个优化针对KV缓存。模型生成文本时需要存储每个已处理token的注意力键值对（KV缓存），长上下文场景下KV缓存往往比模型权重更快填满GPU显存。Cloudflare将默认的16位精度（BF16）降到8位浮点（FP8），缓存大小直接减半。

实测数据显示，Kimi K2.6在H200 GPU上解码时，BF16缓存在32个并发请求后即耗尽内存，峰值吞吐为1558 tok/s；而FP8缓存可持续扩展到64个并发，吞吐达到2192 tok/s，比BF16峰值高出41%，每token成本降低约30%。关键的是，在GSM8K、MMLU等评测基准上，FP8与BF16的准确率差异在各个指标上均不超过1个百分点，可以被视为完全等价。

权重压缩：GLM 5.2瘦身40%，低并发场景提速55%

对于GLM 5.2，Cloudflare将模型权重从FP8压缩到INT4精度，模型检查点从705GB减至421GB，减少了约40%的显存占用。在低并发场景（单请求）下，解码速度从60 tok/s跃升至92 tok/s，提升了55%；64并发时也从1672 tok/s提升到1933 tok/s。

压缩带来的速度提升有其清晰的物理原因：解码阶段的瓶颈是显存带宽而非算力，每生成一个token都需要从显存中读取模型权重数据。传输的数据越少，每个token到达得越快。

Cloudflare的"分离式架构"（disaggregated）让这些优化可以各自发挥所长：计算密集的预填充阶段保持FP8精度，而显存带宽密集的解码阶段使用INT4权重，两者各得其所。

KV缓存完整性校验：防止高并发下的"串台"

量化压缩会在同一GPU上塞进更多并发请求，这意味着数百个请求同时读写同一个物理KV缓存。在这种规模下，即使是十亿分之一的错误也会频繁出现。Cloudflare构建了KV缓存完整性校验作为防御层——每个物理缓存页带有标签，请求使用前先验证匹配，若不匹配则中止当前请求，防止返回错误页面的数据。

这项安全检查的开销极低：吞吐量下降不到1%，尾部延迟增加也在1%以内。Cloudflare正努力将其做成可以全场景默认开启的零成本保护。