AI网关的设计与应用：API层集成AI的实践指南
深入讨论AI网关的必要性和实现方法，帮助开发者理解在API层引入AI的架构考量。对系统设计和技术选型有直接指导价值。
完整中文译文
在从事 2 年的 Apache APISIX API 网关工作之前，我对 API 网关基本一无所知。只有通过与它们共事，我才理解了它们的价值所在。解耦客户端和服务器解锁了很多可能性：把身份验证移到 API 网关、API 安全防护、去重 API 请求等等。
在这篇文章中，我想说明相同的模式如何应用到 AI。
AI 网关的工作方式类似。它们在 AI 客户端和其 LLM 后端之间代理请求和响应。同样地，它也能解锁很多改进：
AI 管理：单一的控制面板来管理多个 AI 模型和提供商，简化了集成和不同服务间切换的复杂性。
合规和治理：在一个地方执行安全、数据隐私和合规要求。
成本控制：智能路由、语义缓存和预算管理。
避免锁定：客户端依赖于一个受控的抽象层；网关管理服务器 API 更新，甚至迁移到新提供商。
可扩展性和可靠性：支持自动故障转移和负载均衡。
可观测性：还用说吗？
我很喜欢 Claude Code；它太棒了，我的体验远超预期。但它有一个问题：Anthropic 是一家美国公司，受《爱国者法案》约束。根据设计，Anthropic 必须遵守任何美国政府访问我全部数据的请求。作为非美国公民，我没有权利反对。我甚至没有权利被告知。
另一方面，Mistral AI 是一家欧盟公司。我听说了很多关于它的好评，尤其是 devstral：
今天我们推出 Devstral，我们用于软件工程任务的智能型 LLM。Devstral 是由 Mistral AI 和 All Hands AI 的合作开发而成，在 SWE-Bench Verified 上的表现远超所有开源模型。我们在 Apache 2.0 许可证下发布 Devstral。
如果我可以使用 Claude Code 但把调用路由到 devstral，那就太棒了。AI 网关是完美的方案。
可用的 AI 网关
如果你需要一个 AI 网关，请务必尽职调查。因为这是探索性的工作，我做的搜索相当浅尝，不是深度研究。这些是浮出水面的产品。
LiteLLM：LiteLLM 是一个开源库，它给你一个统一的接口来调用 100+ 个 LLM——OpenAI、Anthropic、Vertex AI、Bedrock 等等——使用 OpenAI 格式。
- 使用相同的 completion() 接口调用任何提供商——无需为每个都重新学习 API
- 不管你使用哪个提供商或模型，输出格式一致
- 通过路由器内置跨多个部署的重试/回退逻辑
- 自托管的 LLM 网关（代理）带有虚拟密钥、成本追踪和管理 UI
Bifrost：Bifrost 是一个高性能 AI 网关，统一访问 20+ 个提供商——OpenAI、Anthropic、AWS Bedrock、Google Vertex、Azure 等等——通过一个统一的 API。以零配置在数秒内部署，获得自动故障转移、负载均衡、语义缓存和企业级治理。在每秒 5,000 个请求的持续基准测试中，Bifrost 每个请求仅增加 11 µs 的开销。
OpenRouter：OpenRouter 提供一个统一的 API，让你通过一个单一端点访问数百个 AI 模型，同时自动处理回退并选择最具成本效益的选项。使用你偏好的 SDK 或框架仅需几行代码就可以开始。
我选择 Bifrost 有几个原因。它是自托管的，接近底层（它用 Go 编写），通过 npx 的快速开始非常简单。它也可以通过 Docker 镜像获得。它有一个 UI，这对探索功能很有帮助。最后，它内置了可观测性。
Bifrost 5 分钟快速开始
启动 Bifrost 只需一条命令：
npx -y @maximhq/bifrost
菜单的第一项显示遥测仪表板。这非常有用。
第一步是为 Mistral 创建一个模型提供商。进入 Models → Model Providers。然后点击 + Add New Provider。最后，选择 + Add new key 并相应地填充字段。你应该已经事先生成了 Mistral API 密钥。
第二步是创建一个路由规则，使得针对 Anthropic 任何模型的 Claude Code 请求转向 Mistral。进入 Models → Routing Rules。点击 + New rule，然后在打开的菜单中，点击 + Add Target。
将所有其他字段留空。
在启动 Claude Code 之前，导出以下环境变量：
export ANTHROPIC_BASE_URL=http://localhost:8080/anthropic (1)
export ANTHROPIC_AUTH_TOKEN=sk-dummy (2)
现在应该只需启动 Claude Code 并开始使用。不幸的是，它失败了。
❯ hello
⎿ API Error: 422 {"type":"error","error":{"type":"api_error","message":"provider API error (status 422)"}}
失败总是很好的机会来更好地理解一个解决方案。在提供商上，点击 Edit Provider Config。设置 Debugging 标签的开关。
然后，在 Observability → LLM Logs 中，选择失败的请求。找到名为 Raw Response from Mistral 的部分。它看起来像这样：
{
"object": "error",
"message": {
"detail": [
{
"type": "enum",
"loc": [
"body",
"reasoning_effort"
],
"msg": "Input should be 'none' or 'high'",
"input": "medium",
"ctx": {
"expected": "'none' or 'high'" (1)
}
}
]
},
"type": "invalid_request_error",
"param": null,
"code": null,
"raw_status_code": 422
}
此时，我已经找到了问题所在。我提交了一个 bug 报告。反馈在不到一小时内回来，修复尝试在几周内完成。它仍然不起作用，但我找到了一个变通方法。
export CLAUDE_CODE_DISABLE_THINKING=1
Extended thinking 是 Claude 在响应前执行的推理。在支持自适应推理的模型上，努力级别是控制思考量的主要参数；下面的设置打开或关闭思考，并控制它如何显示。
此时，它起作用了，但代价是缺少更高级的推理。
上述做法对个人设置很好，但在企业设置中，你很少会看到这种方法，即使有的话。然而，你经常会看到的是每月支出限额。这种情况有两个问题：
用户必须能够追踪他们的使用情况。没有精确的追踪，他们冒着太早消耗过多 token 的风险。
如果你超支，你就会被卡住，直到计数器重置，这通常发生在下个月初。问我怎么知道的。
AI 网关一般而言，特别是 Bifrost，提供了很多选项来处理这两个问题。我将把计量搁置一旁，本文重点关注使用本身。AI 网关可以做几件事来帮助管理预算。
设置每日上限。在一天的最后半小时内被限制，比在月底被限制超过一天要好。
使用特定模型的重定向请求到其他模型。你可以用它来防止用户使用昂贵的模型。在撰写本文时，Claude Opus token 的成本至少是 Claude Sonnet 的 5 倍。
超预算时降级模型。一旦用户超过特定预算，将请求重定向到更便宜的模型。
超预算时重定向到自托管模型。
这些只是你可以实现的几个用例。
在本节中，我想演示最后一项。在企业设置中，你可以在云实例上托管回退，甚至自托管。在本文的背景下，我将自己限制在如果超过设定限制就回退到本地 llama-server。
第一步是定义支出限制。进入之前定义的 Mistral 提供商。在 Governance 标签中设置限制。这是我为演示目的将每日上限设置为 100,000 个 token 的地方。
第二步是添加一个 Llama Server 提供商。它的类型是 custom。
API Structure：基础是 OpenAI，因为 llama-server 是兼容的。记住将允许的请求类型限制在模型实际能做的事情。对于我的模型，它是 Chat Completion 和 Chat Completion Stream。
Network：将 Base URL 设置为 http://localhost:<port>。因为 Bifrost 绑定在端口 8080，我在 8081 上运行 llama-server。
第三步也是最后一步是向现有路由规则添加回退。
使用设置的较低 token 数，你会在一两个请求后达到上限。
在下一个请求中，Bifrost 将：
评估条件
防止请求到达 Mistral
并改为将其发送到备用 Llama 服务器。
Bifrost 记录两个请求，第一个到 Mistral AI，第二个到 Llama。这是一个样本：
AI 网关是一个很好的架构改进。Bifrost 在纸面上看起来很棒，仪表板似乎相当全面。
不幸的是，一个 Bifrost bug 目前阻止了我的 extended thinking 的实现。我希望维护者能快速修复它，这样我就可以真正进一步探索 AI 网关。
但是，当它工作时，我将能够利用 Claude Code 的惊人客户端与我选择的 LLM，包括 Devstral。