AI Gateway Architecture2026年6月22日Big Y

用于多提供商路由和故障转移的 LLM API 网关架构图

使用这张 LLM API 网关架构图来梳理客户端应用、策略检查、路由、提供商故障转移、配额、计费、日志和 Flatkey 配置。

一个LLM API gateway 是应用代码与多个模型提供商之间的控制平面。一个有用的架构不只是一个代理 URL。它必须对调用方进行身份验证，映射模型，应用策略，选择上游路由，强制配额，记录使用情况，计算成本，并决定当提供商失败时会发生什么。

本指南为平台工程师提供一个用于多提供商路由和故障转移的实用LLM API gateway 架构图。它使用来自 Vercel 和 Pydantic 的公开网关模式作为类别参考，然后将 Flatkey 相关声明限制在当前公开证据范围内：一个 API key、位于 https://router.flatkey.ai/v1 的 OpenAI 兼容路由器端点、清晰的定价、统一计费、用于 key、使用情况和路由的仪表板、自动切换以及负载均衡。

本指南的目标是在生产流量依赖它之前，帮助你审查设计。将这张图用作你自己的网关、供应商评估或 Flatkey 预发布测试的检查清单。

LLM API gateway architecture diagram for multi-provider routing and failover — LLM API gateway 的参考架构，用于在多个提供商之间路由模型流量、记录使用情况，并在不对未确认的 SLA 或延迟作出假设的情况下处理故障转移。

LLM API 网关架构图

该图展示了从客户端应用到上游模型提供商的请求路径。架构的中心是 LLM API gateway。围绕它的是用于确保路由安全运行的策略服务：key scope、model mapping、route class、quota ledger、billing、logs、health checks 和 fallback rules。

层	职责	设计问题
客户端应用	发送聊天、responses、image、video、agent 或 tool 请求。	哪些 SDK 和端点格式必须继续正常工作？
网关端点	通过稳定的 base URL 和 API key 接收请求。	应用是否可以仅通过更改 key、base URL 或 provider config 来迁移？
认证和 key scope	识别调用方、团队、应用、环境以及允许的 model set。	能否将 staging、production 和 customer 流量分离？
策略引擎	应用 model mapping、route class、budget、quota 和 fallback rules。	策略是否解释了为什么请求可以或不可以使用某条 route？
路由器	选择上游提供商、account、model 或备用路径。	路由是否基于已批准的策略，而不是隐藏的 magic？
健康检查和故障转移	跟踪提供商错误、超时、重试、fallback 和 stop conditions。	哪些故障应该重试、切换、排队或 fail closed？
日志、配额和计费	记录 model、route、status、token 或 media units、cost、owner 和 key。	工程和财务能否在事故后追踪一条请求？
上游提供商	通过 provider-native 或兼容的 APIs 提供所选模型。	每种 traffic class 允许哪些提供商？

请求如何通过网关传递

生产环境的 LLM API 网关 应该让请求路径易于解释。如果你的团队无法画出这条路径，那么在故障或账单审查期间，你大概率也无法排查这条路径。

客户端发送请求。 应用使用模型名称、端点、消息或媒体输入，以及应用 API 密钥来调用网关。
网关验证密钥。 该密钥映射到所有者、环境、配额、允许的模型集合和日志策略。
策略引擎对流量进行分类。 请求会被标记为客户聊天、后台任务、评估、媒体生成、编码工具流量或其他路由类别。
路由器选择候选路径。 它会检查模型映射、提供商可用性、允许的上游账户、成本策略、配额状态，以及任何已配置的优先级或权重。
网关发送上游请求。 根据提供商和端点的不同，这可能会保留 OpenAI 兼容的请求结构，或使用提供商原生协议。
响应会在可能时进行规范化。 网关向客户端返回预期的响应结构、错误、流或作业引用。
请求会被记录。 日志会捕获路由、模型、状态、延迟、使用量、成本估算、密钥和所有者，以便团队进行调试和费用对账。

这就是为什么 OpenAI 兼容 API 迁移这一步只是架构的一部分。更改基础 URL 只能把流量送到网关。生产就绪还取决于之后的策略、路由、配额、计费、日志以及故障转移行为。

路由策略先于故障转移

最常见的架构错误，是把故障转移当作普适的好事。LLM API 网关不应机械地将每个失败请求重试到每个提供商。它应先判断备份路径是否允许用于该流量类别。

公开的网关文档说明了这种区分为何重要。Pydantic 记录了路由组，其中提供商可以具有优先级、权重和活动状态，从而允许在提供相同模型的提供商之间进行故障转移，或在同优先级成员之间进行负载均衡。Vercel 将 AI Gateway 定位于路由、计费、可观测性、多模型，以及带有回退的提供商/模型路由。这些模式是有用的参考，但你的生产策略仍必须定义什么对你的工作负载是可接受的。

流量类别	主要路由规则	故障转移规则
面向客户的聊天	仅使用已批准的模型家族和提供商。	仅切换到已批准的等效项，或返回受控错误。
后台摘要生成	当质量要求稳定时，优先考虑成本和吞吐量。	如果输出质量仍可接受，则重试、排队，或使用更低成本且已批准的模型。
评估与基准测试	保持模型标识稳定。	关闭式失败；隐藏回退会使结果难以比较。
媒体生成	遵守端点形态、作业生命周期、媒体策略和预算。	除非替代模型具有相同且已批准的输出契约，否则关闭式失败。
代理工作流	遵守工具支持、上下文限制、数据边界和审计需求。	仅在工具行为和数据处理仍然有效时才回退。

Flatkey 的公开文案称，它通过自动切换和负载均衡来路由多个上游账户。可将其作为产品起点，然后定义你的哪些流量类别可以自动切换，哪些必须关闭式失败。

故障切换需要一个停止条件

每个LLM API 网关故障切换设计都需要一个停止条件。没有这个条件，格式错误的请求可能会演变成一连串重复的无效调用、重复支出、混乱的日志以及不一致的用户行为。

一个实用的失败阶梯如下：

在上游之前拒绝：对于无效认证、被禁止的模型、超出配额、不支持的端点或缺少必需参数，直接失败并关闭。
重试相同路径：仅当错误很可能是暂时性时重试，例如网络超时或选定的上游 5xx。
切换相同合同：只有在其他账户、区域或提供商路径提供相同的已批准模型合同时，才使用它们。
使用已批准的备份：仅当产品、质量、合规和预算负责人批准该备份时，才切换到另一个模型。
排队或降级：当即时回退会很昂贵或有风险时，延迟非紧急工作。
返回受控错误：当策略表明不再存在安全路径时停止。

AI API 负载均衡和故障切换指南对这一点有更详细的说明。在架构评审中，关键问题是每一次转换是否都是明确且可观察的。

配额、计费和日志是请求路径的一部分

模型流量的计费方式与普通 HTTP 流量不同。单个 LLM API 网关 可能需要对输入 token、输出 token、缓存 token、推理 token、图像单元、视频时长、工具调用、重试以及特定提供商的配额单元进行计费。若把计费和配额当作夜间报表处理，网关就无法在当下阻止失控的使用量。

将配额和计费尽量靠近路由策略：

在转发高成本请求之前，检查调用方剩余预算。
当支出限制很重要时，对缺少定价数据的路由进行阻止或警告。
记录所选模型、端点族、上游路由、密钥、所有者、状态和使用单位。
在日志中将重试和回退调用分开，这样单个用户请求就不会掩盖多次提供商尝试。
让预发布和生产密钥作为不同的成本中心可见。
导出足够的数据供财务、支持和事件复盘使用。

Flatkey 当前的公开定位包括清晰定价、统一计费、用量可见性、配额限制，以及一个用于密钥、用量和路由的仪表板。其发布日的定价 API 快照返回了 656 行模型数据，并支持 OpenAI-compatible、OpenAI Responses、Anthropic、Gemini、图像生成和视频生成流量的端点元数据。请将其视为有时效性的证据，然后在实时的定价页面上核实你的具体模型和单位。

Flatkey 在此架构中的位置

Flatkey 旨在通过一个密钥减少提供商账户蔓延。在这个 LLM API gateway 架构中，Flatkey 对应托管网关端点、提供商访问层、仪表板、使用/计费层以及路由层。

一个谨慎的 Flatkey 预发布测试应如下所示：

在 Flatkey 仪表板中创建一个非生产密钥。
将一个客户端指向 https://router.flatkey.ai/v1。
针对您需要的端点系列运行一个已知可用的请求。
确认该请求出现在使用日志中，并包含模型、状态、单位和成本证据。
查看所选模型和计费单位的实时定价页面。
定义哪些流量类别可以使用自动切换或负载均衡。
运行一次安全的失败测试，或者记录为什么在预发布环境中不允许进行失败模拟。

请不要仅根据本文推断正常运行时间 SLA、延迟保证、确切的路由算法或保证的提供商可用性。该架构告诉您需要验证什么；您的预发布证据告诉您某个具体上线是否已经准备就绪。

实施检查清单

在将生产流量通过 LLM API 网关 之前，请确保架构已具备以下控制措施：

检查项	通过条件
基础 URL 和 SDK 迁移	至少有一条预发布请求使用预期的 SDK 或客户端通过网关成功。
模型与端点映射	每个生产端点族都已分配经过批准的模型、协议和负责人。
密钥范围	在需要时，密钥按应用、环境、团队或客户进行隔离。
路由策略	流量类别定义了允许的主路由和备用路由。
故障切换停止条件	网关知道何时重试、切换、排队以及安全失败。
配额和预算检查	限制可以在昂贵流量到达上游提供商之前将其停止或加以约束。
日志和可观测性	请求、路由、模型、负责人、状态、用量和成本证据在事后都可以审查。
回滚	如果网关部署失败，应用可以恢复到先前的提供商配置。