Cloudflare Workers AI 的正确用法：围绕产品边缘做轻量推理

Workers AI 通常被拿来和其他模型提供商做比较——比的是哪家模型的质量更好。但这种比较什么都说明不了，因为 Workers AI 的竞争力根本不在模型质量上。读懂平台自身的约束条件，一个具体而合理的定位就自然浮现出来了。

本文的论点很明确：Workers AI 值得用于产品主推理周围的那些模型调用，而不是主推理本身。分类、嵌入、路由、内容审核、提取、日志行摘要——这些调用频繁、小巧、对延迟敏感、对质量容忍度高。而对于那种用户会直接看到并据此评判你的调用，理由就弱得多了。

这不是在留退路，而是平台三个有据可查的事实的推论：如何访问、如何计费、如何限流。三个因素指向同一个方向。

优势在于共置，而非质量

从 Worker 向外部提供商发起模型调用，是一个出站 HTTPS 请求：要经过 DNS、TLS、往返到提供商所在的区域，还要管理一个需要存储、轮换和安全保护的密钥。Workers AI 的调用则是一个 binding。

// wrangler.jsonc
{ "ai": { "binding": "AI" } }

const response = await env.AI.run("@cf/meta/llama-3.1-8b-instruct", {
  prompt: "What is the origin of the phrase Hello, World",
});

这段代码里没有基础 URL，没有 Authorization 头，因此也根本没有提供商密钥——这删掉了 secrets 页面所述的一整类工作，也删掉了一整类故障隐患。Cloudflare 将 Workers AI 描述为在其全球网络的 serverless GPU 上运行机器学习模型。

其意义在于减少了往返次数，这与 Smart Placement 页面的论证相互叠加。一个检索 pipeline 要对查询进行嵌入、在 Vectorize 中搜索，然后调用前沿模型来生成答案——如果嵌入是外部调用则有三次网络跳数，不是外部调用则只有两次。当嵌入调用是一个 binding 而非一次互联网往返，你就从每次查询中去掉了一个跳数——而且嵌入恰恰是那种较小模型伤害你最少的调用，因为你是在向量之间做比较，而不是把文字展示给一个人。

Neuron 改变了哪些调用值得做

Cloudflare 用 neuron 来计费 Workers AI，它将 neuron 描述为跨模型衡量 AI 输出的一种方式，代表执行一个请求所需的 GPU 计算量。文档显示每天免费 10,000 个 neuron，超出部分每 1,000 个 $0.011，底层还有按模型单价在 neuron 计费之上叠加的定价。

定价和每日免费配额恰恰是供应商最可能调整的数字；这些是撰写时的记录值。Cloudflare, Workers AI pricing

有趣的特性不是那个标题数字，而是没有按请求计费的下限。没有最低收费，没有每个 key 的开销，能力放在那里不用也不花钱。这就改变了哪些调用能在成本审查中存活下来。"在我们决定把这个输入发给哪个昂贵的模型之前，先对它做个分类"——这类调用的价值是真实存在的，但比较有限，它只有在相对于它所守护的调用成本极低时才有意义。"检查这个文档是否变化到值得重新嵌入"同理，或者"这条支持消息是否在范围内"也是。

在昂贵调用前放置廉价的守卫调用，这种模式只有在守卫真正便宜时才有效。这是一个关于计费结构的论点，而非质量论点——这是 Workers AI 最强有力的论据。

限流描述了预期的工作负载

Cloudflare 发布了 Workers AI 的每任务限流，如果你把它当作一份平台意图声明来读，会发现它们异常翔实。文档记录的限流包括：文本嵌入每分钟 3,000 请求，图像分类每分钟 3,000 请求，文本分类每分钟 2,000 请求，摘要每分钟 1,500 请求，文本生成每分钟 300 请求。平台提供的前沿模型记录为每账户每模型每分钟 20 请求，或通过预付费 AI Gateway 积分升至 50 请求。

看这个分布。嵌入和分类允许的速率是文本生成的十倍，而前沿模型允许的速率只有文本生成的十五分之一。这是在告诉你它是为哪类调用构建的。如果你的设计是让 Workers AI 在规模下服务每一个面向用户的补全，每分钟 300 的文本生成上限就是你会撞到的一堵墙；如果你的设计是让它做嵌入、分类和过滤，你就处于配额所划定的形态之内。

对于吞吐量而非延迟，有一个对应的释放阀：Cloudflare 文档记录了一个异步 Batch API，它将一批推理请求排队并返回一个带有 queued 状态的 request_id 供轮询，将其描述为保证请求最终会被履行，而不是在容量不足时返回错误。这是重新索引任务的正确工具，而对于任何有人在等待的场景则是错误的——这再次回到了本文反复到达的同一个分界点。

论点的边界

对这一主张的局限性保持诚实，才使其有价值。上述推理在三个地方不成立：

产品的主要答案。如果模型输出是用户付费购买的东西，模型选择就主导了这个页面上所有其他考量。共置节省几十毫秒；更好的答案价值永远高于这个节省。

长上下文和重度工具使用。携带大型对话记录并调用大量工具的 Agent 循环，正是前沿模型优势最大的地方，也是一个较小的开放模型会以难以从评估集中发现的方式退化的地方。

供应商集中化。将计算、存储、向量搜索和推理放在一个提供商上，既是移动部件的真实减少，也是关联故障的真实增加。这笔交易无论哪边都合理，但应该是有意识做出的——灾难恢复方案才是仔细权衡的地方。

以上都不反对这个平台。它支持的是边界：Workers AI 用于那些频繁、小巧且与答案相邻的调用；答案本身用别的方式。

这样的拆分意味着双供应商架构，而双供应商意味着两种响应格式、两种流式传输格式、两种限流约定，以及在一套代码库中需要处理的两套故障模式。这种规范化正是 Multigrid 这类 LLM gateway 所做的事，也是本文建议的切实代价——在接受之前值得坦诚掂量。