Cloudflare公开Kimi、GLM部署细节：三层优化让大模型少占GPU、速度还更快

Cloudflare通过KV缓存量化、模型权重压缩和缓存完整性检查，在更少GPU上部署Kimi与GLM的新闻概念图 — Cloudflare公开了在 Workers AI 上高效部署 Kimi 与 GLM 的三层优化：压缩缓存、压缩权重，并给共享缓存加上安全校验。图片由AI生成。

大模型部署最贵的地方，往往不是“让它回答一次问题”，而是让成千上万个人同时提问时，模型仍然能稳定、快速、低成本地回答。

8月3日，Cloudflare Developers 在 X 上介绍了一篇新的技术拆解：Moonshot 的 Kimi 系列和 Z.ai 的 GLM 系列属于能力很强的开源模型，但它们同时拥有超长上下文、混合专家结构和巨大的参数规模，最难的不是把模型下载下来，而是把它们长期、批量地跑在 GPU 上。Cloudflare 的做法不是重新训练一个更小的模型，而是从推理过程的内存使用入手，把三层优化叠加起来：量化 KV Cache、压缩模型权重，并为共享缓存增加完整性检查。

Cloudflare 表示，这些优化让 Workers AI 能在不改变模型准确性的前提下，服务更多客户、降低成本。下面把这套部署原理拆成普通人也能看懂的版本。

先理解：大模型回答问题时，GPU到底在忙什么

可以把一次大模型请求想象成“读完题目，再逐字写答案”。在技术上，它大致分为两个阶段：

Prefill（预填充）：模型一次性阅读用户的提示词、历史对话和文档，把这些输入转成后续生成答案需要的中间信息。
Decode（解码）：模型开始一个 token、一个 token 地生成答案。每生成一个新 token，都要参考前面已经读过和写过的内容。

普通用户看到的是一个“发送问题—收到回答”的动作，GPU看到的却是两种完全不同的工作：Prefill 更像集中做一次大计算，Decode 更像不断从显存里取数据、写回数据。把这两个阶段混在同一批 GPU 上处理，会让一边等待另一边，效率很差。

Cloudflare此前已经在 Workers AI 中采用了把 Prefill 和 Decode 分开的部署思路。这次的关键，是根据两种阶段的不同特点，给它们选择不同的压缩方式：Prefill 优先保留计算速度，Decode 优先节省显存和内存带宽。

第一层：把 KV Cache 从“高清”改成“轻量版”

KV Cache到底是什么

模型读过一段长文本后，不可能每生成一个字都把整段对话重新读一遍。它会把每个 token 在注意力机制中产生的中间结果保存下来，这个存储区域叫 KV Cache，其中 K 是 Key，V 是 Value。

可以把它理解成会议记录：模型已经读过的内容被整理成一摞索引卡，后面写答案时直接翻索引卡，而不是把整场会议重新播放。上下文越长、并发请求越多，索引卡就越多，最后最先把 GPU 显存塞满的，常常不是模型权重，而是 KV Cache。

Cloudflare怎么压缩

默认情况下，KV Cache 使用 BF16，也就是每个数用16位保存。Cloudflare把它改成 FP8，每个数只用8位，缓存体积大约减半。以 Kimi K2.6 为例，能同时放进显存的上下文规模，从约 68.6 万 token 提升到约 137 万 token。

这里有一个容易被误读的地方：FP8 并不是在任何情况下都让单个请求更快。读取 FP8 缓存时，GPU需要做一次转换，所以在相同并发量下，BF16 每 token 的速度反而略高。但 FP8 让显存能容纳更多请求，这才是云服务商最关心的收益。

Cloudflare在 H200 的分离式部署测试中观察到：

BF16 在 32 个并发请求后就会耗尽缓存，无法继续接纳第 33 个请求；
FP8 可以继续扩展到 64 个并发请求，峰值达到每秒约 2,192 token；
相比 BF16 的峰值，FP8 的吞吐量约高 41%，每 token 成本约低 30%；
Prefill 仍然使用 BF16，因为这个阶段更受计算能力限制，而不是缓存容量限制。

这就是“部署优化”与“模型优化”的区别：模型本身没有变聪明，Cloudflare只是让同一块显存同时服务更多人。

第二层：把 GLM 5.2 的模型权重从 705 GB 压到 421 GB

KV Cache 是运行过程中不断增长的临时数据，模型权重则是模型本身的“长期库存”。每生成一个 token，Decode 阶段都要反复从 GPU 显存中读取这些权重。模型越大，需要搬运的数据就越多，GPU很可能不是算不过来，而是等数据搬过来。

Cloudflare针对 GLM 5.2 做了另一种压缩：把 FP8 权重转换成 INT4。FP8 仍然是浮点数，INT4 则用4位整数保存参数。结果是，模型检查点从约 705 GB 缩小到约 421 GB，减少约 40%。在 8 路张量并行部署中，单块 GPU 的权重占用也从约 88 GB 降到约 52 GB，并额外留下约 118 万 token 的 KV Cache 空间。

为什么权重变小会让生成更快？因为 Decode 阶段的瓶颈往往是显存带宽：每生成一个 token，都要把大量权重从显存读进计算单元。需要搬运的字节数少了，等待时间就缩短了。Cloudflare的 GLM 测试显示，在一个并发请求下，INT4 的吞吐相对 FP8 提升约 55%；在 8、16、32 和 64 个并发请求下，提升幅度分别约为 21%、21%、27% 和 16%。

但 INT4 也不是全场景胜出。Prefill 属于计算密集型任务，INT4 权重需要先展开才能参与矩阵运算，反而会拖慢预填充：Cloudflare测得 FP8 约为每秒 10,160 token，INT4 约为每秒 8,660 token。

因此，Cloudflare没有强行给整个系统使用同一种格式，而是采用“分阶段选格式”：Decode 用 INT4，Prefill 用 FP8。这样既能减少生成答案时的数据搬运，又不牺牲读入长提示词时的计算效率。Cloudflare称，在其测试集上，INT4 与 FP8 的结果差异不超过0.8个百分点，整体质量被认为难以区分。

第三层：请求越多，越要防止缓存“串台”

前两层优化会让更多请求共享同一块 GPU 的物理显存。这是效率的来源，也是新的风险：不同用户的 KV Cache 被切成许多页面（page），由连续批处理和缓存复用机制共同管理。如果系统在高并发时把请求 A 的页面误当成请求 B 的页面，模型可能读取到别人的上下文。

Cloudflare为此加入了 KV Cache 完整性检查。它的思路很像仓库给每个货架贴上“货架编号＋本轮使用标签”：每个物理缓存页面重新分配时，标签就会变化；请求会记录自己预计使用哪些页面、对应哪些标签；Decode 读取前，服务器先检查两份记录是否一致。如果不一致，就中止受影响的请求，而不是让模型继续读取可能错误的内容。

这不是对模型回答内容的安全审查，而是对“模型正在读取哪块内存”的底层校验。它防的是缓存管理错误、页面复用错误和并发条件竞争，目标是避免速度优化变成数据隔离事故。

更重要的是，这层安全检查并没有明显抵消前面的性能收益。Cloudflare在一个包含两个 Prefill、两个 Decode、8,192 token 输入和1,000 token 输出的生产配置上测试，完整性检查带来的吞吐下降不到1%，p95 尾延迟增加也不到1%。他们把校验做成独立的批处理检查，而不是直接塞进注意力内核，以避免不同 GPU 线程组之间出现竞态。

把三层技术串起来：一次请求是怎样跑完的

用简化流程表示，一次请求大致会经历下面几步：

请求进入 Workers AI：路由层把请求送到有容量的模型实例，尽量靠近用户所在区域。
Prefill 读取输入：模型用更适合计算的精度处理提示词；历史内容产生的中间结果写入 KV Cache。
缓存分页和复用：KV Cache 被切成页面，多个请求可以共享同一块 GPU 的显存空间；重复前缀还可以直接命中已有缓存。
Decode 生成回答：模型使用更省显存的缓存和权重格式，持续读取页面并生成 token。
每次读取前做完整性检查：系统确认请求拿到的是自己预期的页面和标签；发现不一致就终止请求。
返回结果并回收页面：请求结束后，缓存页面重新分配给下一批请求，同时更新页面标签。

这套架构的核心不是“把所有东西都压缩到最低”，而是把不同瓶颈拆开处理：上下文太占内存，就压缩 KV Cache；生成阶段搬运权重太慢，就压缩模型权重；共享越激进，隔离风险越高，就给缓存加完整性检查；读入提示词和生成答案表现不同，就让 Prefill 和 Decode 使用不同配置。

为什么这对普通用户有意义

普通用户不会看到 FP8、INT4 或 KV Cache 这些名词，但会感受到三个结果。

更少排队：一块 GPU 能同时容纳更多请求，突发流量下更不容易因为显存不足拒绝请求。
更低成本：同样的硬件可以服务更多 token，云平台有机会降低单位调用成本，或把节省下来的容量用于扩大模型选择。
更长上下文：缓存占用下降后，模型可以在同一次对话里保留更多历史内容，长文档和代码分析更容易持续进行。

但这不等于所有平台都会自动得到同样的效果。量化格式、GPU型号、推理框架、并发量和请求长度都会改变结果。Cloudflare的数字来自特定的 Kimi、GLM、SGLang 和 GPU 配置，不能直接当成任何本地电脑或任何云服务的通用承诺。

Cloudflare真正的创新：把“模型能力”变成“可运营的基础设施”

过去，开源模型的竞争经常被简化成参数规模、榜单分数和上下文长度；但当模型进入生产环境，真正的难题变成了另一组问题：一块 GPU 能服务多少人？冷启动要等多久？长上下文会不会把显存吃光？不同用户的缓存会不会串台？单位 token 需要花多少钱？

Cloudflare这次公开的不是一个新模型，而是一套把模型变成公共服务的工程方法。它没有宣称“量化后完全没有代价”，反而把代价拆开：FP8 缓存牺牲一点单请求 token 速度，换取更高并发；INT4 权重让 Decode 更快，却让 Prefill 变慢；完整性检查消耗不到1%的性能，换来共享缓存的隔离保障。

这也是为什么 Cloudflare 说 Kimi 和 GLM “难以高效服务”：难点不在模型能不能运行，而在能不能在真实流量、真实成本和真实安全要求下长期运行。下一步，Cloudflare还在验证 Blackwell GPU 上的 NVFP4 权重，并扩大 FP8 KV Cache 的部署范围。对用户来说，这场竞争最终会体现为更快的首 token、更少的排队、更长的上下文和更稳定的价格。

资料来源

-=||=-收藏赞 (0)