一万亿参数的模型，Cloudflare 是怎么跑起来的

fliter
3 阅读8分钟

原文：Building the foundation for running extra-large language models
发布时间：2026 年 4 月 16 日
作者：Michelle Chen、Kevin Flansburg、Vlad Krasnov

先说结论

前段时间，Cloudflare 宣布 Workers AI 正式支持托管超大规模开源模型，其中包括月之暗面的 Kimi K2.5。上线之后，他们在保持 GPU 数量不变的情况下，把 Kimi K2.5 的推理速度提高了 3 倍。

这篇文章是他们的工程复盘，讲的是：为了让一个超过 1 万亿参数的模型在生产环境里跑得又快又稳，他们到底做了哪些事情。

内容涉及硬件配置、缓存策略、跨 GPU 通信，以及他们自研的推理引擎 Infire。技术细节较多，但逻辑并不难跟。

为什么 Agent 场景对推理基础设施的要求更高

要理解这些优化的背景，先要理解他们主要服务的是什么场景——Agent（智能体）应用。

和普通问答不同，Agent 的每一轮对话都要把整个上下文打包发给模型：系统提示、工具列表、历史消息、已生成的代码……随着对话轮次增加，输入 Token 的数量会持续膨胀。

这带来两个核心诉求：快速处理大量输入 Token，以及快速生成工具调用指令。这两点直接决定了后面所有优化的方向。

硬件配置层面的四项优化

一、Prefill 与 Decode 分离部署

LLM 的推理请求在内部分为两个阶段：

  • Prefill（预填充）：处理输入 Token，填充 KV Cache，计算密集型
  • Decode（解码）：逐个生成输出 Token，内存带宽密集型

两个阶段对 GPU 资源的消耗方式完全不同。如果把它们跑在同一台机器上，两个阶段会互相阻塞，导致 GPU 的不同部分轮流空转。

Cloudflare 的解法是把两个阶段拆到不同的服务器上独立运行。请求先发给 Prefill 服务器完成输入处理，再转发给 Decode 服务器，同时把 KV Cache 从 Prefill 服务器迁移过来开始生成。这样两类服务器可以各自针对自己的工作负载独立调优，也可以根据业务流量（输入重还是输出重）独立扩容，甚至可以运行在不同规格的硬件上。

实际效果很明显。切换到分离架构后，在请求量反而增加的情况下，p90 首 Token 时延大幅下降；Token 间隔时延（每生成一个 Token 的等待时间）从 ~100ms 降到了 20–30ms，整体提速约 3 倍。

这套架构的难点在于负载均衡器的实现——它需要感知每个节点当前在飞行中的 Prefill Token 数和 Decode Token 数，把流量尽量均摊，同时还要重写 SSE 流式响应，把两个阶段的信息拼合给客户端。

二、Prompt 缓存与会话亲和路由

Agent 场景有个固有特点：同一个对话的多轮请求，前面的大段内容几乎是重复的。每次都重新计算这些 Token 的向量是一种纯粹的浪费。

Cloudflare 通过一个叫 x-session-affinity 的请求头实现会话亲和路由——带上这个头的请求，会被优先路由到之前已经计算过相同输入的节点，直接复用缓存的 KV 值，跳过 Prefill 计算。

他们还把这个头集成到了 OpenCode 等常用 Agent 框架里。对接完成后，高峰时段的缓存命中率从 60% 提升到了 80%。这个数字看起来不大，但对于 GPU 利用率来说影响显著——缓存命中率的小幅提升，等效于节省了相当数量的 GPU 算力。

作为激励，Cloudflare 对命中缓存的 Token 提供折扣定价。

三、跨 GPU 的 KV Cache 共享

Kimi K2.5 有超过 1 万亿个参数，模型权重文件约 560GB。一张 H100 只有 80GB 显存，光加载模型权重就需要至少 8 张 H100，还没算 KV Cache 占用的空间。

多 GPU 部署带来了一个新问题：KV Cache 天然分布在不同 GPU 的显存里，节点之间怎么高效共享和传输？

Cloudflare 选择了月之暗面开源的 Mooncake 技术栈，分两层解决这个问题：

Mooncake Transfer Engine 是一个高性能数据传输框架，支持 NVLink 和 NVMe over Fabric 等 RDMA 协议，可以实现 GPU 显存之间的直接传输，完全绕开 CPU，大幅降低跨节点 KV Cache 迁移的开销。

Mooncake Store 则把 KV Cache 的存储范围从 GPU 显存扩展到了 NVMe 固态硬盘。这意味着缓存可以存放更多、更久，命中率进一步提升，也不再需要严格的会话亲和路由——即使请求被路由到不同节点，也能找到之前缓存的 KV 值。

四、投机解码：让大模型"抄小模型的答案"

LLM 的标准生成方式是每次只预测下一个 Token，串行执行，效率有上限。

投机解码（Speculative Decoding）用一种聪明的方式绕过了这个限制：先用一个轻量级的**草稿模型（Draft Model）**一次性预测若干候选 Token，再让目标大模型在单次前向传播中统一验证这批候选 Token——接受就直接用，拒绝就重新生成。

验证的计算量远小于生成，所以整体吞吐量显著提升，而输出质量不变，因为最终决定权始终在大模型手里。

这个技术在 Agent 场景里特别有效。Agent 频繁调用工具，工具调用的格式高度结构化——固定的 JSON 外壳、固定的字段名——草稿模型对这类有规律的内容预测准确率很高，大量候选 Token 都能被大模型直接采纳。

Cloudflare 为 Kimi K2.5 搭配了 NVIDIA 的 EAGLE-3 草稿模型，在保证质量的前提下进一步压低了 Token 生成时延。

自研推理引擎 Infire

除了硬件配置层面的优化，Cloudflare 还在用自己研发的推理引擎 Infire，这是一个用 Rust 写的推理框架，专门针对 Cloudflare 全球分布式网络的特点设计。

为了支持 Kimi K2.5 这类超大模型，他们对 Infire 做了几项关键升级：

多 GPU 并行：Infire 同时支持流水线并行（Pipeline Parallelism）、张量并行（Tensor Parallelism）和专家并行（Expert Parallelism）。大部分情况下，同时使用前两者的组合能在吞吐量和时延之间取得最好的平衡。流水线并行会主动做负载均衡，避免某一阶段的 GPU 空等；张量并行则专注于减少 GPU 之间的通信开销。

更低的显存占用：Infire 本身的内存开销就比 vLLM 低，这次他们进一步收紧了激活值等内部状态的内存用量。具体数字是：Llama 4 Scout 只需要 2 张 H200 就能运行，且 KV Cache 还剩超过 56GB 可用空间；Kimi K2.5 在 8 张 H100 上运行后，KV Cache 仍有 30GB 以上的余量。相比之下，同样的配置 vLLM 甚至连启动都很困难。

极快的冷启动：即便是 Kimi K2.5 这样的超大模型，Infire 也能在 20 秒内完成启动并开始响应请求，瓶颈只在磁盘读取速度上。

整体吞吐量提升：在资源不受限的系统上，Infire 比主流推理框架高出约 20% 的 Token 生成速度，同时也让一些原本跑不动的模型在低端硬件上成为可能。

几点值得关注的地方

这篇博客有几个细节，读完觉得值得单独提一下：

第一，PD 分离架构的负载均衡难度被低估了。很多团队知道 Prefill 和 Decode 的资源特性不同，但真正在生产环境里做分离，流量调度、响应重写、SSE 流的拼接都是非常细致的工程工作，不是简单拆两台机器就能解决的。

第二，缓存命中率的边际价值非常高。从 60% 到 80% 听起来只提升了 20 个百分点，但对于 GPU 这种昂贵且稀缺的资源来说，这意味着同等硬件能服务更多请求，或者同等请求量需要更少的 GPU。在规模化的推理服务里，这个数字直接影响运营成本。

第三，投机解码在结构化输出场景里的收益远超通用场景。Agent 工具调用、JSON Schema 约束输出这类场景，草稿模型的预测准确率远高于自然语言生成，效果提升更明显。

小结

把一个万亿参数的模型跑到生产可用的状态，远不是堆 GPU 这么简单。从 Prefill/Decode 分离，到跨节点 KV Cache 共享，再到投机解码和自研引擎，每一层优化都是在软件和硬件之间反复权衡的结果。

Cloudflare 的优势在于，他们本来就是一家以工程效率见长的基础设施公司，用软件压榨硬件性能是他们的老本行。这套针对超大模型的技术栈，也是他们在 AI 推理这条路上越走越深的一个缩影。

参考链接

avatar
文章
阅读
粉丝