Workers AI 上线 Kimi K2.5，智能体成本直降 77%

我们正致力于让 Cloudflare 成为构建和部署智能体（Agent）的最佳平台。可靠的智能体不能仅靠提示词（Prompt），它们需要一个由底层原语构成的强大、协调的基础设施。

Cloudflare 多年来一直在构建这些原语：用于状态持久化的 Durable Objects、用于长时间运行任务的 Workflows，以及用于安全执行的 Dynamic Workers 或 Sandbox 容器。像 Agents SDK 这样强大的抽象，旨在帮助你在 Cloudflare 开发者平台之上构建智能体。

但这些原语只提供了执行环境。智能体仍然需要一个能够驱动它的模型。

从今天起，Workers AI 正式进入大模型领域。我们的 AI 推理平台现在提供前沿的开源模型。我们首先在 Workers AI 上发布了 Moonshot AI 的 Kimi K2.5 模型。该模型拥有完整的 256k 上下文窗口（Context Window），支持多轮工具调用（Tool Use）、视觉输入和结构化输出，非常适合各种智能体任务。通过将前沿规模的模型直接引入 Cloudflare 开发者平台，我们得以在单一、统一的平台上运行整个智能体生命周期。

智能体的核心是驱动它的 AI 模型，这个模型需要足够智能，具备高推理能力和大上下文窗口。Workers AI 现在可以运行这些模型了。

性价比甜点

过去几周，我们一直在测试 Kimi K2.5 作为内部开发工具的引擎。在 OpenCode 环境中，Cloudflare 工程师使用 Kimi 作为处理智能体编码任务的日常工具。我们还将该模型集成到了自动化代码审查流水线中；你可以通过我们在 Cloudflare GitHub 仓库上的公共代码审查智能体 Bonk 看到实际效果。在生产环境中，该模型已被证明是大型专有模型的一种快速、高效的替代方案，且没有牺牲质量。

提供 Kimi K2.5 服务最初是一项实验，但在评估了模型的性能和成本效益后，它迅速变得至关重要。举一个例子：我们有一个对 Cloudflare 代码库进行安全审查的智能体。这个智能体每天处理超过 70 亿个 Token，使用 Kimi 后，它在一个代码库中就发现了超过 15 个已确认的问题。粗略计算一下，如果我们使用中档专有模型运行这个智能体，仅这一个用例、一个代码库，每年就要花费 240 万美元。而使用 Kimi K2.5 运行这个智能体的成本只是这个数字的一小部分：我们仅通过切换到 Workers AI 就将成本削减了 77%。

随着 AI 采用率的提高，我们不仅看到了工程团队运作方式的根本性转变，也看到了个人运作方式的转变。人们拥有像 OpenClaw 这样 24/7 运行的个人智能体变得越来越普遍。推理量正在飙升。

个人智能体和编码智能体的这种新增长意味着，成本不再是次要考虑因素；它已成为规模化扩展的主要障碍。当每个员工都有多个智能体每小时处理数十万个 Token 时，使用专有模型的成本计算就变得不可行了。企业将寻求转向开源模型，这些模型提供前沿水平的推理能力，却没有专有模型的价格标签。Workers AI 旨在促进这一转变，提供从个人智能体的无服务器端点到为整个组织的自主智能体提供动力的专用实例等一切服务。

大模型推理栈

Workers AI 自两年前推出以来就一直提供模型服务，包括 LLM，但我们历史上优先考虑的是较小的模型。部分原因是，有一段时间，开源 LLM 远远落后于前沿模型实验室的模型。随着 Kimi K2.5 等模型的出现，这种情况发生了变化，但要服务这种超大型 LLM，我们必须对推理栈进行更改。我们想与你分享一些幕后工作，以支持像 Kimi 这样的模型。

我们一直在为 Kimi K2.5 开发自定义内核，以优化我们服务模型的方式，该模型构建在我们专有的 Infire 推理引擎之上。自定义内核提高了模型的性能和 GPU 利用率，释放了如果你只是开箱即用地运行模型就无法获得的增益。还有多种技术和硬件配置可以用来服务大模型。开发者通常结合使用数据、张量和专家并行化技术来优化模型性能。像解耦预填充这样的策略也很重要，即将预填充和生成阶段分离到不同的机器上，以获得更好的吞吐量或更高的 GPU 利用率。实施这些技术并将其整合到推理栈中，需要大量的专业经验才能做好。

Workers AI 已经在服务技术方面进行了实验，以在 Kimi K2.5 上实现出色的吞吐量。很多优化在你自行托管开源模型时并不是开箱即用的。使用 Workers AI 这样的平台的好处是，你不需要成为机器学习工程师、DevOps 专家或站点可靠性工程师（SRE）来进行托管所需的优化：我们已经完成了困难的部分，你只需要调用一个 API。

不止于模型——针对智能体工作负载的平台改进

与此发布同步，我们还改进了平台，并发布了几个新功能来帮助你构建更好的智能体。

前缀缓存与缓存 Token 指标

当你使用智能体时，很可能会发送大量输入 Token 作为上下文的一部分：这可能是详细的系统提示词、工具定义、MCP 服务器工具或整个代码库。输入可以大到模型上下文窗口的极限，理论上，你可以发送包含近 256k 输入 Token 的请求。这需要处理很多 Token。

当 LLM 处理请求时，请求被分解为两个阶段：预填充阶段处理输入 Token，输出阶段生成输出 Token。这些阶段通常是顺序进行的，输入 Token 必须被完全处理后才能生成输出 Token。这意味着有时在模型进行预填充时，GPU 没有得到充分利用。

在多轮对话中，当你发送新的提示词时，客户端也会将之前所有的提示词、工具和会话上下文发送给模型。连续请求之间的增量通常只是几行新的输入；所有其他上下文已经在之前的请求中经过了预填充阶段。这就是前缀缓存发挥作用的地方。我们不必对整个请求进行预填充，而是可以缓存来自先前请求的输入张量，只对新输入 Token 进行预填充。这节省了预填充阶段的大量时间和计算，意味着更快的首 Token 时间（TTFT）和更高的每秒 Token 吞吐量（TPS），因为你不会被预填充阻塞。

Workers AI 一直都有前缀缓存，但现在我们将缓存 Token 作为一个使用指标展示出来，并且与输入 Token 相比，对缓存 Token 提供折扣。（定价可以在模型页面上找到。）我们还为你提供了新的技术，以提高前缀缓存命中率，从而降低成本。

为了路由到相同的模型实例并利用前缀缓存，我们使用了一个新的 x-session-affinity 请求头。当你发送这个请求头时，你将提高缓存命中率，从而获得更多的缓存 Token，进而实现更快的 TTFT、TPS 和更低的推理成本。

你可以像下面这样传递新的请求头，每个会话或每个智能体使用一个唯一的字符串。像 OpenCode 这样的客户端已经自动实现了这一点。我们的 Agents SDK 入门模板也已经为你设置好了相关的代码。

curl -X POST \
"https://api.cloudflare.com/client/v4/accounts/{ACCOUNT_ID}/ai/run/@cf/moonshotai/kimi-k2.5" \
  -H "Authorization: Bearer {API_TOKEN}" \
  -H "Content-Type: application/json" \
  -H "x-session-affinity: ses_12345678" \
  -d '{
    "messages": [
      {
        "role": "system",
        "content": "You are a helpful assistant."
      },
      {
        "role": "user",
        "content": "What is prefix caching and why does it matter?"
      }
    ],
    "max_tokens": 2400,
    "stream": true
  }'

重新设计的异步 API

无服务器推理真的很难。采用按 Token 付费的业务模式，在单个请求基础上更便宜，因为你不需要为整个 GPU 来服务你的请求。但这有一个权衡：你必须应对其他人的流量和容量限制，并且没有严格的保证你的请求会被处理。这并非 Workers AI 独有——考虑到频繁出现的提供商过载和服务中断的新闻报道，这显然是所有无服务器模型提供商都面临的情况。虽然我们始终努力服务你的请求，并内置了自动扩展和重新平衡功能，但存在一些硬性限制（比如硬件），使得这成为一个挑战。

对于会超过同步速率限制的请求量，你可以提交批量推理以异步方式完成。我们正在引入一个经过改进的异步 API，这意味着对于异步用例，你不会遇到“容量不足”的错误，并且推理将在某个时间点持久地执行。我们的异步 API 看起来更像弹性处理而不是批处理 API，只要我们的模型实例有剩余容量，我们就会处理异步队列中的请求。通过内部测试，我们的异步请求通常在 5 分钟内执行，但这将取决于实时流量的情况。随着我们将 Kimi 推向公众，我们将相应地调整扩展策略，但异步 API 是确保你在持久工作流中不会遇到容量错误的最佳方式。这对于非实时用例（如代码扫描智能体或研究智能体）来说是完美的。

Workers AI 以前就有异步 API，但我们最近彻底改造了底层系统。我们现在依赖于一个基于拉取的系统，而不是历史上基于推送的系统，这允许我们一有容量就拉取排队的请求。我们还增加了更好的控制来调整异步请求的吞吐量，实时监控 GPU 利用率，并在利用率低时拉入异步请求，以便关键的同步请求获得优先权，同时仍能高效处理异步请求。

要使用异步 API，你可以像下面这样发送请求。我们还有一种方法来设置事件通知，这样你就可以知道推理何时完成，而不必轮询请求状态。

// (1.) 将请求推入队列
// 传递 queueRequest: true
let res = await env.AI.run("@cf/moonshotai/kimi-k2.5", {
  "requests": [{
    "messages": [{
      "role": "user",
      "content": "Tell me a joke"
    }]
  }, {
    "messages": [{
      "role": "user",
      "content": "Explain the Pythagoras theorem"
    }]
  }, ...{<add more requests in a batch>} ];
}, {
  queueRequest: true,
});


// (2.) 获取请求 ID
let request_id;
if(res && res.request_id){
  request_id = res.request_id;
}
// (3.) 轮询状态
let res = await env.AI.run("@cf/moonshotai/kimi-k2.5", {
  request_id: request_id
});

if(res && res.status === "queued" || res.status === "running") {
 // 通过再次轮询重试
 ...
}
else 
 return Response.json(res); // 这将包含最终完成的响应

立即试用

立即开始在 Workers AI 上使用 Kimi K2.5。你可以阅读我们的开发者文档，了解模型信息和定价，以及如何利用通过会话亲和性请求头实现的提示词缓存和异步 API。Agents SDK 入门模板现在也默认使用 Kimi K2.5 作为其模型。你也可以通过 Opencode 连接到 Workers AI 上的 Kimi K2.5。要体验实时演示，请在我们的 playground 中尝试。

如果你对围绕无服务器推理、机器学习优化和 GPU 基础设施的这些问题感兴趣——我们正在招聘！