Cloudflare在官方博客里交了一份关于如何服务大模型的成绩单:通过把KV cache从16位精度压到8位、把GLM的权重从8位压到4位整数,再叠加一层缓存完整性校验,Kimi K2.6在H200上能撑住的上下文从约68.6万token翻倍到137万token,64并发下吞吐达到2192 tok/s,比原来32并发就撑爆显存的BF16方案峰值高出约41%,单位成本降低约30%。整套评测显示,精度损失都在0.8分以内,几乎可以忽略。
这是一份扎实的工程账,但博客里一句轻描淡写的"protecting the cache those requests share"(保护多个请求共享的缓存),恰恰是最该多问一句的地方。
显存是怎么被腾出来的
长上下文、混合专家(MoE)架构的大模型有一个反直觉的瓶颈:真正把显存吃满的往往不是模型权重,而是KV cache——模型记住的每一个token的注意力状态。上下文越长,这块缓存涨得越快,通常比权重本身更早把显存塞满。
Cloudflare的解法是两头一起省。KV cache从BF16量化到FP8,直接减半;GLM的权重从FP8压到INT4,checkpoint从705GB降到421GB,单卡显存占用从约88GB降到52GB,腾出来的空间又能多装下118万token的缓存。因为Cloudflare此前已经把推理拆成prefill(处理输入)和decode(逐字生成)两个独立的资源池,这套量化可以精确用在最该用的地方:decode阶段是显存带宽瓶颈,权重越小读得越快,INT4在低并发下能让GLM提速55%;但prefill是纯计算瓶颈,INT4权重还得先展开成高精度才能参与矩阵运算,这一步反而拖慢了它,GLM的prefill吞吐从FP8的10160 tok/s掉到INT4的8660 tok/s。
"保护共享缓存"这四个字,到底护住了什么
量化和压缩带来的直接后果,是同一块GPU显存能塞进更多请求,数百个请求同时读写同一片物理KV cache。Cloudflare说为此加了一层完整性校验:每块缓存页打标签,重新分配就换标签,读取前先核对映射对不对,不对就直接中止请求。测下来这层校验的开销压在1%以内,听起来很划算。
但这层校验解决的是"读错页"这种工程bug,不是"跨租户偷看"这种安全问题。Cloudflare采用的开源推理框架SGLang,靠的是RadixAttention机制来复用不同请求间相同前缀的缓存——这套复用逻辑本身和数据是BF16还是FP8无关,量化只改变显存占用,不构成租户隔离的边界。如果多个客户的请求共享同一个推理引擎和缓存池,理论上仍存在通过缓存命中延迟推测他人输入内容的旁路风险,除非缓存的键值里显式包含了可信的租户命名空间。
- 提醒.Cloudflare博客通篇没有展开这层隔离具体怎么做,"保护共享缓存"目前更像一个标题,而不是一份可核实的实现说明。
省下来的是显存,没交代清楚的是隔离边界。
41%和55%,谁能替Cloudflare验一遍
再往下看,博客里所有对比数字——41%的吞吐提升、55%的低并发提速、30%的成本下降——全部来自Cloudflare自己的H200机房、自己的SGLang部署、自己选的并发和prompt分布。目前市面上找不到一份变量受控一致的第三方基准,能在相同checkpoint、相同硬件拓扑下,把SGLang、vLLM、TensorRT-LLM在Kimi或GLM上摆到同一张桌子上比一遍。这不是说数字有假,而是这些结论目前只能算内部自证,外部还没法复现。
对正在用Workers AI跑Kimi、GLM的企业客户来说,这批优化确实意味着更低的调用成本,尤其是多租户共享GPU资源的场景。但如果业务对长prompt、高频交互敏感,prefill变慢这笔账也得算进去,不能只看decode侧的漂亮数字。SGLang社区、同业云厂商大概率会跟进类似的量化组合,真正拉开差距的,可能不是谁的吞吐数字更好看,而是谁先把"共享缓存到底怎么隔离"说清楚、并且让人验证得了。