Cloudflare优化大语言模型基础设施以提升速度与效率
Cloudflare AI··作者 Vlad Krasnov
关键信息
预填充-解码分离将输入处理（预填充）与输出生成（解码）分配到不同服务器上，可独立调优各阶段以提高GPU利用率，并应对如代理类提示等多样化负载。
资讯摘要
Cloudflare通过软件优化和硬件配置改进，在其Workers AI平台上提升了大语言模型的性能。他们特别通过预填充-解码分离技术使Kimi K2.5模型提速3倍，即将输入标记处理与输出标记生成分配给不同的服务器。这使得GPU资源利用更高效，因为预填充阶段计算密集而解码阶段内存密集。
系统还包含一个基于token感知的负载均衡器，可根据当前工作负载智能路由请求并确保KV缓存跨阶段传输。这些优化对依赖长上下文窗口和频繁工具调用的代理类应用至关重要。
资讯正文
构建运行超大规模语言模型的基础
一个智能体需要由大型语言模型驱动。几周前，我们宣布Workers AI正式进入托管大型开源模型（如Moonshot的Kimi K2.5）的领域。自那以来，我们已将Kimi K2.5的速度提升了3倍，并正在开发更多模型。这些模型已成为我们本周推出的一系列代理产品、工具包和工具的核心支撑。
托管AI模型是一项极具挑战性的任务：它要求在软件和极其昂贵的硬件之间取得微妙的平衡。在Cloudflare，我们擅长通过精巧的软件工程榨干硬件的每一丝效率。本文将深入探讨我们如何为运行超大规模语言模型奠定基础。
硬件配置
正如我们在上一篇关于Kimi K2.5的博客中提到的，我们使用多种硬件配置来最优地服务不同模型。许多硬件配置的选择取决于用户发送给模型的输入和输出大小。例如，如果你用模型写粉丝小说，可能会给出几个小提示（输入标记），同时要求生成大量内容（输出标记）。
相反，如果你在执行摘要任务，可能会输入数十万甚至更多的输入标记，但只生成几千个输出标记的小型摘要。面对这两种截然不同的使用场景，你必须做出选择——你是应该优化模型配置以更快处理输入标记，还是更快生成输出标记？
当我们首次在Workers AI上部署大型语言模型时，我们就知道大多数使用场景都将用于智能体。对于智能体而言，你会发送大量的输入标记：一开始是系统提示、所有工具和MCPs；随着第一个用户提示的到来，上下文不断增长。用户的每一次新提示都会向模型发送请求，其中包括此前的所有内容——之前的所有用户提示、助手回复、生成的代码等。对Workers AI来说，这意味着我们必须专注于两点：快速处理输入标记，以及快速调用工具。
预填充解码（PD）拆分
我们用来提升性能和效率的一种硬件配置是拆分预填充阶段。处理LLM请求分为两个阶段：预填充阶段处理输入标记并填充KV缓存，解码阶段生成输出标记。预填充通常是计算密集型的，而解码则是内存密集型的。这意味着每个阶段使用的GPU部件不同，且由于预填充总是先于解码执行，这两个阶段会相互阻塞。最终结果是，如果我们把预填充和解码都放在同一台机器上执行，就无法高效利用全部GPU算力。
通过预填充解码分离架构，每个阶段都会运行独立的推理服务器。首先，请求被发送到预填充阶段，该阶段执行预填充并将结果存储在KV缓存中。随后，同一请求会被发送到解码服务器，并附带从预填充服务器传输KV缓存的信息，从而开始解码过程。这种设计具有多项优势：它允许服务器根据各自承担的角色进行独立调优，按需扩展以应对输入密集型或输出密集型流量，并且甚至可以在异构硬件上运行。
这种架构需要一个相对复杂的负载均衡器来实现。除了如上所述路由请求外，它还必须重写解码服务器的响应（包括流式SSE），将来自预填充服务器的信息（例如缓存的标记）嵌入其中。更复杂的是，不同的推理服务器需要不同信息才能启动KV缓存传输。为此，我们扩展了系统以实现基于标记的负载均衡：即维护一个预填充和解码端点池，负载均衡器会估算每个端点池中的预填充或解码标记数量，并尝试均匀分配负载。
在我们公开模型发布之后，我们的输入/输出模式再次发生显著变化。我们花时间分析了新的使用模式，并据此调整配置，使其更好地适配客户的实际用例。
下图展示了我们在将流量切换到新的PD分离架构后，p90首次标记耗时的变化情况——尽管请求量增加，但使用的GPU数量保持不变。我们可以明显看到尾部延迟方差得到了大幅改善。
同样，每标记的p90耗时从约100毫秒、波动较大，降低至20-30毫秒，实现了三倍于之前的标记间延迟优化。
提示词缓存
由于代理类应用场景通常涉及长上下文，我们特别优化了提示词缓存机制，以避免每次交互都重新计算输入张量。我们利用了一个名为x-session-affinity的HTTP头部，帮助请求路由到曾处理过相关输入张量的区域。我们在最初关于在Workers AI上部署大型语言模型的博客文章中详细介绍了这一点。我们在像OpenCode这样的流行代理框架中添加了会话亲和性头部，观察到整体吞吐量显著提升。用户提示词缓存的微小差异可能最终导致所需GPU数量成倍增长。虽然我们内部已实现KV感知路由，但仍依赖客户端显式发送x-session-affinity头部来明确启用提示词缓存。我们通过提供缓存标记折扣的方式鼓励用户使用该头部。我们强烈建议用户利用提示词缓存，以获得更快的推理速度和更低的定价成本。
我们与最活跃的内部用户合作推广该头部的使用，结果在高峰期输入标记缓存命中率从60%提升至80%。这不仅显著提升了我们能处理的请求吞吐量，也为OpenCode或AI代码审查等交互性强或对时效敏感的场景提供了更好的性能体验。
随着我们开始部署更大的模型，单个实例可能会跨越多个GPU。这意味着我们必须找到一种高效的方法，让KV缓存能够在多个GPU之间共享。KV缓存用于存储预填充阶段（即会话中提示词的结果）的所有输入张量，最初存储在某个GPU的显存（VRAM）中。每个GPU都有固定的显存容量，但如果模型实例需要多个GPU，就必须有一种方式让KV缓存跨GPU分布并相互通信。为了实现这一点，我们在Kimi项目中采用了Moonshot AI开发的Mooncake Transfer Engine和Mooncake Store。
Mooncake的Transfer Engine是一个高性能数据传输框架，它支持多种远程直接内存访问（RDMA）协议，如NVLink和NVMe over Fabric，从而实现无需CPU参与的内存到内存直接传输。这显著提升了多GPU机器间的数据传输速度，尤其在多GPU和多节点配置下对大模型运行至关重要。
当与LMCache或SGLang HiCache配合使用时，缓存可以在集群中的所有节点间共享，使得一个预填充节点能够识别并重用之前请求中由其他节点预填充的缓存内容。这消除了集群内对会话感知路由的需求，使流量负载更加均衡。此外，Mooncake Store还能将缓存扩展至GPU显存之外，利用NVMe存储空间。这延长了会话在缓存中的保留时间，提高了缓存命中率，从而让我们能处理更多流量，并为用户提供更优性能。
推测解码（Speculative Decoding）
大型语言模型通过预测序列中下一个标记来工作，基于前面已有的标记。如果采用朴素实现方式，模型只能预测接下来的一个token，但我们实际上可以让它在一个前向传播中预测接下来的n+1、n+2……个token。这种广受欢迎的技术被称为推测解码，我们曾在Workers AI的另一篇文章中详细讨论过。
推测解码借助一个较小的语言模型（称为草稿模型）生成若干候选token供目标模型选择。目标模型只需在一次前向传播中从少量候选token中做出决策即可。验证这些token比使用更大规模的目标模型直接生成它们更快、计算成本更低，同时质量仍能得到保障，因为最终决定权仍在目标模型手中——它可以接受或拒绝草稿token。
在代理型应用场景中，推测解码尤为突出，因为这类场景要求模型频繁生成工具调用和结构化输出。例如，工具调用通常具有高度可预测性：你知道其中必然包含名称、描述字段，并且封装在JSON格式中。
为了在Kimi K2.5中实现这一功能，我们采用了NVIDIA的EAGLE-3（用于提升语言模型效率的外推算法）作为草稿模型。调整推测解码的关键参数包括一次性生成未来token的数量。因此，我们在保持高质量推理的同时，实现了每秒生成token数量的显著提升。
作为我们在2025年生日周宣布的内容，Cloudflare拥有一个专有的推理引擎Infire，能够使机器学习模型运行得更快。Infire是用Rust编写的一个推理引擎，旨在应对Cloudflare在全球分布式网络中面临的独特推理挑战。我们已扩展了Infire对这类新型大语言模型的支持，这意味着我们必须构建一些新功能才能让这一切正常工作。
多GPU支持
像Kimi K2.5这样的大语言模型参数量超过1万亿，大约需要560GB的模型权重。一台典型的H100显卡约有80GB显存，而模型权重必须加载到GPU内存中才能运行。这意味着像Kimi K2.5这样的模型至少需要8张H100显卡才能将模型载入内存并运行——这甚至还没有计算KV缓存所需的额外显存，而KV缓存包含了你的上下文窗口。
自Infire最初发布以来，我们增加了对多GPU的支持，允许推理引擎在多个GPU上以流水线并行或张量并行模式运行，并且还支持专家并行。
对于流水线并行，Infire会尝试合理分配流水线各阶段的任务负载，防止某些GPU阶段因其他阶段执行而空转。而对于张量并行，Infire则优化跨GPU通信，使其尽可能快。对于大多数模型来说，同时使用流水线并行和张量并行能提供最佳的吞吐量与延迟平衡。
更低的内存开销
尽管Infire已经比vLLM具有更低的GPU内存占用率，我们进一步优化了它，压缩了内部状态（如激活值）所需的内存。目前，Infire可以在仅两台H200 GPU上运行Llama 4 Scout，还能保留超过56 GiB用于KV缓存，足以支持超过120万token的上下文长度。Infire同样能在8张H100 GPU上运行Kimi K2.5（没错，就是H100），并且仍保留超过30 GiB用于KV缓存。在这两种情况下，你甚至可能连vLLM都无法成功启动。
更快的冷启动速度
在增加多GPU支持的过程中，我们还发现了进一步提升启动时间的机会。即使是最庞大的模型，比如Kimi K2.5，Infire也能在不到20秒内开始处理请求。加载时间仅受硬盘读取速度限制。
最大化硬件性能以提升吞吐量
投资于我们的专有推理引擎，让我们能够通过优化硬件利用率实现更高的吞吐量：在无约束系统中，每秒可达到比之前高出最多20%的token数；同时也让我们可以使用较低端的硬件来运行最新的模型，而此前这是完全不可行的。
旅程尚未结束
机器学习社区每周都会推出新技术、研究和模型。我们持续优化技术栈，以便为客户提供高质量、高性能的推理服务，同时高效地利用我们的GPU资源。如果你觉得这些挑战很有趣——我们正在招聘！
来源与参考
收录于 2026-04-17