智能体需要大语言模型提供支持。几周前，我们宣布了 Workers AI 正式进军大型开源模型托管领域，例如托管了 Moonshot 旗下的 Kimi K2.5 模型。自此以后，我们已将 Kimi K2.5 模型的运行速度提高了三倍，并在处理过程中不断增加更多支持的模型。这些模型一直是我们本周发布的许多智能体产品、框架和工具的基石。
托管 AI 模型是一项有趣的挑战：需要在软件与极其昂贵的硬件之间找到微妙的平衡。Cloudflare 擅长通过巧妙的软件工程，最大限度地提高硬件效率。本文将深入探讨我们如何为运行超大型语言模型奠定基础。
正如我们在之前的 Kimi K2.5 博客文章中所述，我们使用多种硬件配置来为模型提供最佳服务。许多硬件配置都取决于用户发送给模型的输入和输出大小。例如，如果您使用模型来撰写同人文，则可能会给它几个简短的提示词（输入词元），同时要求它生成多页内容（输出词元）。
相反，如果您运行的是摘要任务，则可能会发送数十万个输入词元，但只生成一份包含几千个输出词元的简短摘要。面对这些截然相反的用例，您必须做出选择：调整模型配置以加快其处理输入词元的速度，还是加快其生成输出词元的速度？
我们在 Workers AI 上发布支持的大语言模型时，就知道了大多数用例会用于智能体。使用智能体，需要发送大量输入词元。它首先以内容较长的系统提示词开始，所有工具和 MCP。随着用户发出第一个提示词，上下文会不断扩展。用户发出的每个新提示词都会向模型发送一个请求，其中包含之前输入的所有内容：包括用户提示词、助手消息、生成的代码等。对于 Workers AI，这意味着我们必须重点关注两件事：快速处理输入词元与快速调用工具。
我们用于提高性能和效率的硬件配置之一是解耦预填充。处理 LLM 请求分为两个阶段：一是预填充，处理输入词元并填充 KV 缓存；二是解码，生成输出词元。预填充通常受计算资源限制，而解码则受内存资源限制。这意味着每个阶段使用的 GPU 部分各不相同，而且由于预填充总是在解码之前完成，因此。这两个阶段会相互阻碍。最终，这意味着如果我们在单台计算机上同时执行预填充与解码，就无法有效地利用所有 GPU 的算力。
采用预填充与解码解耦方法，为每个阶段运行单独的推理服务器。首先，向预填充阶段发送请求，该阶段执行预填充并将其存储在 KV 缓存中。然后，向解码服务器发送相同的请求，其中包含如何从预填充服务器传输 KV 缓存并开始解码的信息。这种方法会带来诸多优势，因为它支持独立调整服务器以适应其各自的角色，根据输入或输出密集型流量进行扩展，甚至可以在异构硬件上运行。
需要一个相对复杂的负载均衡器来实现这种架构。除了如上所述的请求路由之外，它还必须重写解码服务器的响应（包括基于 SSE 的流式传输），以添加来自预填充服务器的信息，例如缓存的令牌。更复杂的是，不同的推理服务器需要不同的信息来启动 KV 缓存传输。我们扩展了这种架构，以实施基于词元的负载均衡。架构中存在一个预填充与解码端点池，负载均衡器会估算正在传输到池里每个端点的预填充或解码词元数量，并尝试均匀分配此类负载。
在我们的公共模型发布后，我们的输入/输出模式再次发生了巨大变化。我们花时间分析了新的使用模式，然后调整了配置以适配客户的用例。
下图展示了在请求量增加的情况下，使用相同数量的 GPU，将流量传输到新的已解耦 PD 架构之后，p90 首个词元延迟降低的情况。我们发现，长尾延迟方差显著改善。
同样，每个词元的 p90 时间从方差较大的约 100 毫秒降至 20-30 毫秒，词元间延迟降低了 3 倍。
由于智能体用例通常具有较长的上下文，因此，我们优化来实现高效的提示词缓存，以避免每次都重新计算输入张量。我们利用名为 x-session-affinity 的标头，帮助请求路由到之前具有已计算的输入张量的正确区域。我们曾在 Workers AI 上托管和运行大型 LLM 的原始博客文章中对此进行了详细介绍。我们将会话亲和请求头添加到 OpenCode 等常用智能体框架，并在其中观察到总吞吐量显著提升。用户提示词缓存方面的微小差异，可能会导致运行模型所需的额外 GPU 数量显著增加。虽然我们内部已经实现了 KV 缓存感知路由，但也依赖客户端发送 x-session-affinity 来明确说明提示词缓存。我们通过提供缓存的词元折扣，激励用户使用此标头。我们强烈建议用户利用提示词缓存，加快推理速度并降低成本。
我们与使用频率最高的内部用户合作，推广使用此标头。结果，在高峰时段的输入词元缓存命中率从 60%提高到 80%。这显著提高了我们能够处理的请求吞吐量，同时也改善了交互式或时间敏感型会话（例如 OpenCode 或 AI 代码审查）的性能。
由于我们现在为更大的模型提供服务，一个实例可能跨越多个 GPU。这意味着我们必须找到一种高效的方法，在多个 GPU 之间共享 KV 缓存。KV 缓存用于存储所有预填充输入张量（会话中提示词的结果），它最初存储在 GPU 的显存 (VRAM) 中。每个 GPU 的 VRAM 容量是固定的，但如果模型实例需要多个 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 VRAM 之外，并利用 NVMe 存储。这会延长会话在缓存中的存活时间，提高缓存命中率，让我们能够处理更多流量，以及为用户提供更好的性能。
LLM 的工作原理是基于前一个词元来推测序列中的后一个词元。在简单实现中，模型只能预测接下来 n 个词元，但实际上，我们可以让它在模型的单次前向传播中预测接下来 n+1、n+2…… 个词元。这种热门的技术被称为推测解码，我们在之前一篇关于 Workers AI 的文章中进行了详细介绍。
在推测解码中，我们利用一个较小的 LLM（草稿模型）来生成一些候选词元，供目标模型从中选择。然后，目标模型只需在一次前向传播中，从少量候选词元中进行选择。验证这些词元比使用更大的目标模型来生成词元的速度更快，计算成本更低。但输出质量依然能够得到保证，因为目标模型最终必须接受或拒绝草稿词元。
在智能体用例中，推测解码的优势尤为突出，因为模型需要生成大量的工具调用和结构化输出。工具调用在很大程度上是可预测的：您知道它会包含名称、描述，并且被封装在 JSON 格式的容器中。
为了在 Kimi K2.5 模型中实现这一点，我们利用了 NVIDIA 的 EAGLE-3 (Extrapolation Algorithm for Greater Language-model Efficiency) 草稿模型。用于调整推测解码的参数之一，是未来要生成的词元数量。因此，我们能够提高每秒词元吞吐量，同时实现高质量推理。
正如我们在 2025 年生日周期间宣布的那样，Cloudflare 拥有一款专有推理引擎 Infire，它可以加快机器学习模型的运行速度。Infire 是用 Rust 语言编写的推理引擎，旨在支持 Cloudflare 应对在其全球分布式网络环境中进行推理时面对的各种独特挑战。我们扩展了 Infire 对即将运行的新型大语言模型的支持，这意味着我们需要开发一些新功能才能达成目标。
Kimi K2.5 等大语言模型拥有超过 1 万亿个参数，这些参数大约需要 560GB 存储空间。一个常规 H100 的 VRAM 大约是 80GB，而模型权重需要加载到 GPU 内存中才能运行。也就是说，像 Kimi K2.5 这样的模型至少需要 8 个 H100 才能将模型加载到内存中并运行，这还不包括 KV 缓存（其中包括上下文窗口）所需的额外 VRAM。
自从我们最初发布 Infire 以来，我们不得不添加多 GPU 支持，使推理引擎能够以管道并行或张量并行模式在多个 GPU 上运行，也支持专家并行。
对于管道并行，Infire 会尝试适当地实现管道各个阶段的负载均衡，防止某个阶段的 GPU 在其他阶段执行时出现等待状态。另一方面，对于张量并行，Infire 进行优化以减少跨 GPU 通信，从而尽可能提高处理速度。对于大多数模型而言，同时使用管道并行和张量并行可以实现吞吐量与延迟的最佳平衡。
虽然 Infire 的 GPU 内存开销已经远低于 vLLM，但我们仍进行了进一步优化，显著降低了激活等内部状态所需的内存。目前，Infire 只需要两个 H200 GPU 就能够运行 Llama 4 Scout，同时剩余超过 56 GiB 容量用于 KV 缓存，足以存储超过 120 万个词元。Infire 也能够在 8 个 H100 GPU（没错，就是 H100）上运行 Kimi K2.5，同时剩余超过 30 GiB 容量用于 KV-缓存。在这两种情况下，甚至是一开始启动 vLLM 时就可能会遇到问题。
在添加多 GPU 支持的同时，我们发现了进一步提高启动速度（缩短启动时间）的机会。即使是对于 Kimi K2.5 等大模型，Infire 也能在 20 秒内开始处理请求。加载时间仅受硬盘速度的限制。
投资 Cloudflare 专有推理引擎让我们能够最大限度地利用硬件，在没有资源限制的情况下，将每秒处理词元的吞吐量提高 20%，同时让我们能够使用低端硬件来运行最新模型，而这在以前完全不可行。
机器学习社区每周都会涌现出新技术、新研究成果和新模型。Cloudflare 不断优化技术栈，旨在为客户提供优质、高性能的推理服务，同时确保我们的 GPU 高效运行。如果您认为这些挑战很有吸引力，欢迎加入我们，我们正在招聘！