原文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 推理这条路上越走越深的一个缩影。参考链接原文https://blog.cloudflare.com/high-performance-llms/Workers AI 大模型首发博文https://blog.cloudflare.com/workers-ai-large-models/Infire 推理引擎介绍https://blog.cloudflare.com/cloudflares-most-efficient-ai-inference-engine/Prompt Caching 文档https://developers.cloudflare.com/workers-ai/features/prompt-caching/Mooncake Transfer Enginehttps://github.com/kvcache-ai/Mooncake