← 返回 被遗弃的电话交换机控制台,缆线缠绕,被阴天窗户光线照亮,35mm 胶片颗粒

Vercel AI Gateway:路由、故障转移及实际节省成本

一个客户在周四上午 8 点给我打电话。他们的 AI 驱动的文档摘要工具从午夜开始就一直返回 503 错误,因为 OpenAI 的 gpt-4o 端点发生了部分中断。他们的 SaaS 合同价值 4 万英镑/月,他们的企业客户在尖叫。我脑子里只有一个问题:为什么没有人为这个系统构建一个重试到 Anthropic 的故障转移?

那是八个月前。Vercel AI Gateway 是我见过的最接近现成解决方案的东西。但"最接近"这个说法做了很多工作。让我告诉你它实际上做什么、数字是什么样的,以及你在哪里仍然应该保持怀疑。

---

Vercel AI Gateway 实际上是什么

大多数人看到这个名字就会认为它只是一个有一些不错日志记录的代理。它的功能有点更多,但远不如营销文案所暗示的那么多。

从本质上讲,Vercel AI Gateway 位于你的应用代码和多个 LLM 提供商之间:OpenAI、Anthropic、Mistral、Google Gemini 等。你向网关端点发送一个请求。网关决定调用哪个模型/提供商、处理重试、缓存语义响应,并返回结果。你得到一个账单行项目,而不是四个 API 仪表板。

SDK 集成非常简洁。如果你已经在使用 Vercel AI SDK,你只需将提供商导入替换为网关客户端,并传递一个提供商配置。在现有项目上可能需要十五分钟。

它本身不是一个神奇的成本降低工具。节省来自三个特定行为:按成本路由、缓存重复提示,以及在提供商故障后避免冷启动。如果你至少没有从这三个行为中的一个获得价值,网关会增加开销而不带来好处。

---

路由逻辑如何工作

提供商优先级和加权路由

你配置一个提供商列表,带有优先级顺序或权重分布。优先级路由很简单:尝试提供商 A,如果它返回 429 或 5xx,则转到提供商 B。加权路由按百分比分流量,所以你可以说"70% OpenAI,30% Mistral",并在实际流量中测试成本差异,而无需完整迁移。

我在 Seahawk 上一季度为一家媒体公司构建的内容生成工具上使用了加权路由。我们在一个月内以 60% 的速度运行 gpt-4o-mini,对比 40% 的 mistral-medium。当时 Mistral 的每百万令牌成本便宜约 34%,但用于结构化 JSON 提取的输出质量明显较弱。我们最终以 80/20 的比例倾向 OpenAI。关键是:网关使那个 A/B 测试毫不费力。没有它,我们会连接两个单独的 SDK 客户端,并在应用逻辑中管理分流。

故障转移行为

故障转移是头条功能,它的工作原理基本上如宣传的那样。当 OpenAI 返回 5xx 时,网关在我的测试中大约在 800ms 内重试下一个配置的提供商。对于流式响应,情况有点混乱:流可以静默地从故障转移提供商重新启动,如果你在客户端没有正确处理流,你可能会得到重复的开始块。那发生过一次。

一件需要了解的事是:网关不进行语义故障转移。它不知道你的 Anthropic claude-3-5-sonnet 响应可能表达方式与 OpenAI 等效品不同。你有责任在提供商间保持提示兼容性。对于大多数聊天风格的界面来说没问题。对于具有严格模式的结构化输出,在上线前在你的故障转移链中独立测试每个提供商。

---

缓存层:真正的金钱所在之处

这是大多数人低估的部分。Vercel AI Gateway 包括语义缓存,而不仅仅是精确匹配缓存。

精确匹配缓存是基本标准:如果相同的提示字符串两次击中网关,则返回缓存响应。语义缓存走得更远。使用嵌入相似性,它识别"用三句话总结这段落"和"给我这段落的三句话摘要"是相同请求,并提供缓存结果。

对于文档总结项目(那个差点让我客户心脏病发作的项目),在启用语义缓存(余弦相似度阈值为 0.92)后,我们对缓存命中率进行了测量。在两周的生产流量中:缓存命中率达到 41%。在 GPT-4o 上每 1K 输出 token 成本 £0.015,对于每天 200 万输出 token 来说,这笔账并不小。

你可以自己用便签纸算一下:

  1. 每天 2,000,000 个输出 token
  2. 41% 从缓存提供 = 820,000 个 token 不被计费
  3. 按 £0.015/1K 计算,每天节省 £12.30
  4. 一个月下来:大约 £370

对大企业来说不足挂齿。但对于关注利润的独立 SaaS 运营者来说很重要。而这只是一个项目、一个月的数据。

OpenAI 的提示缓存功能现在原生支持前缀缓存,所以对于长系统提示,你已经免费获得了其中一些优势。Vercel 的语义缓存是对其补充,处理用户回合内容的变化。

---

Observability: Better Than Nothing, Not Good Enough Alone

通过网关的每个请求都被记录:延迟、token 计数、使用的提供商、缓存命中/未命中、成本估算。你可以在 Vercel 仪表板中看到这些。显示清晰易读。

但这里有个问题。如果你在运行一个严肃的生产系统,你已经在追踪管道中使用了类似 Datadog、Grafana 或至少 LangSmith 这样的工具。Vercel 仪表板只能给你网关级别的可见性。它无法给你全应用范围的 span 级追踪。你看不到一个特定用户的请求为什么花了 4.2 秒,其中 3.1 秒是在检索步骤中花费的,甚至还没轮到调用 LLM。

所以我把网关内置的可观测性当作第一道筛选:问题是在 LLM 调用级别还是别处?对于更深层的分析,我仍然导出到专业追踪工具。

一个值得了解的具体数据:根据我在欧盟地区部署上的测量,网关平均每个请求增加约 15-30 毫秒延迟。对于实时语音或低于 100 毫秒的 UX 需求,这很重要。对于异步文档处理,就无关紧要了。

---

实际运行成本是多少

Vercel AI Gateway 包含在 Pro 计划及更高计划中(撰写本文时为 £17/月)。Vercel 不收取按请求计费。你仍然直接支付底层提供商的 token 成本。

隐性成本来自运维:你现在在推理路径中多了一个 Vercel 依赖。如果 Vercel 的边缘网络出问题,你的 LLM 调用就会失败,不管 OpenAI 是否完全正常。我在过去六个月里见过一次这种情况,Vercel 边缘网络在欧盟西部地区大约 12 分钟的部分中断。对大多数应用来说这是可以接受的。但对于任何有 SLA 承诺(以"九"来衡量)的应用,需要考虑这一点。

还有数据驻留的问题。你的提示和完成通过 Vercel 的基础设施。对大多数消费应用:无关紧要。对于医疗、金融或任何涉及 GDPR 敏感个人数据的场景:在传输任何内容前先仔细阅读数据处理协议。我就曾告诉过两个金融科技客户完全跳过网关,改为在应用中处理路由。

---

何时使用、何时跳过

我直言不讳,因为 AI 工具周围的开发者营销往往言过其实。

在以下情况下使用 Vercel AI Gateway:

  • 你已在 Vercel 上且使用 AI SDK(零额外摩擦)
  • 你有多提供商策略,想要故障转移但不想写重试逻辑
  • 你的应用有足够多的重复或语义相似提示,让缓存产生回报
  • 你想要成本仪表板但不想设置单独的提供商计费集成

跳过它或仔细考虑如果:

  • 你有严格的数据驻留要求(GDPR、HIPAA)
  • 你需要低于50毫秒的总推理延迟,每一跳都很关键
  • 你运行在非Vercel基础设施上,添加他们的边缘计算反而增加了复杂性
  • 你的提示词变化极大,语义缓存命中率几乎为零

回到2022年,我们为伦敦市一家律师事务所在自托管栈上构建了法律文件分析工具。即使当时Vercel AI Gateway已经存在,它也会被直接排除在外。这些提示包含特权客户信息,该公司的IT合规团队绝不会批准使用第三方代理。我们在大约四小时内自己搭建了提供商抽象层。它通过简单的优先级队列处理跨两个提供商的故障转移。不算花哨。完全足够。

---

实用设置(简略版)

如果你已决定这对你的项目合适,这是我遵循的步骤:

  1. 在Vercel项目设置的"AI"标签页下启用网关
  2. 安装或更新 ai @ai-sdk/openai(以及任何其他需要的提供商包)到最新版本
  3. 将直接提供商客户端实例化替换为来自 @vercel/ai-gateway 的网关客户端(查阅官方文档了解确切的导入路径,因为它已经变过一次)
  4. 在网关配置对象中按优先级顺序定义你的提供商列表
  5. 设置语义缓存相似度阈值:我从0.90开始,根据一周流量后观察到的命中率进行调整
  6. 部署到预发布环境并有意触发提供商故障以验证故障转移链按预期工作
  7. 在得出结论前监控前两周的缓存命中率和延迟p95

就这样。真的没那么复杂。

---

FAQ

Vercel AI Gateway支持流式响应吗?

是的,流式传输通过网关工作。唯一的问题是流式传输中途的故障转移:如果主要提供商在流式响应期间宕机,网关将在下一个提供商上重试,但流会重新启动。根据你的客户端UI如何处理部分内容,这可能导致明显的闪烁或第一句重复。在部署前在UI中明确测试。

我可以在不使用Vercel AI SDK的情况下使用Vercel AI Gateway吗?

技术上你可以通过HTTP直接访问网关端点,但SDK集成才是使其人性化的地方。没有SDK你需要自己编写围绕网关URL的fetch封装、自己管理流、手动处理重试。那样的话你还不如自己搭建提供商抽象层。网关的价值在实践中与SDK紧密耦合。

语义缓存如何处理敏感或个性化数据?

不会自动处理。如果你发送的提示包含用户特定数据(名字、账户号、会话上下文),缓存将尝试匹配语义相似的提示,无论该数据在用户间是否不同。这可能在个性化工作流中导致不正确的缓存命中。你应该要么对这些路由禁用语义缓存,要么包含用户作用域的缓存键(如果网关在你的计划层支持的话)。

如果Vercel宕机,我的请求会怎样?

会失败。网关在关键路径上。如果你需要真正的多云弹性,你应该在应用层有一个断路器,可以完全绕过网关并直接访问提供商。在任何真正关乎正常运行时间的应用中,我都会将提供商SDK客户端初始化作为备用方案。

---

诚实的总结:Vercel AI Gateway 是一个构建得很好的基础设施,在 Vercel 原生 AI 堆栈中占有一席之地。它不会彻底改变你的单位经济学,但在合适的工作负载上 35-40% 的缓存命中率加上自动故障转移,相比手工配置一切是真正的运营改进。只是在你投入之前,要清楚它不能做什么。早上 8 点接到惊慌失措的客户电话才发现你的假设有问题,这是最糟糕的。

← 返回