LLM Gateway：一站式入口，连接多个模型的入门指南

LLM 网关是位于你的应用与一个或多个 AI 模型提供方之间的控制层。你的应用不再分别直接连接每个提供方，而是将请求发送到网关。网关随后对请求进行身份验证，应用策略，选择模型或上游连接，转发调用，并记录结果。

这听起来像是普通的 API 管道工作，但它解决了一个在真实 AI 产品中很快就会出现的问题：第一个模型集成很简单；第五个就不简单了。每个提供方都可能带来一组新的密钥、SDK、请求格式、限流策略、错误形式、使用情况页面和账单。

这篇LLM 网关入门指南将解释这一层的作用，请求如何在其中流转，它与相邻工具有何不同，何时需要它，以及如何在不过度设计的前提下实现第一次网关集成。

什么是 LLM 网关？

LLM 网关，也称为LLM API 网关或AI 网关，为应用访问 AI 模型提供一个稳定的接口。最简单的形式下，它提供：

• 用于模型请求的单一入口；
• 单一的认证边界；
• 一致的请求与响应契约；
• 集中化的使用记录；
• 决定请求去向的路由规则。

功能更强的网关还可以强制执行预算，限制允许使用的模型，处理有限次数的重试，在等价路由之间进行故障切换，附加请求 ID，规范化错误，并输出延迟、token 和成本遥测数据。

这篇 LLM 网关入门指南中的重要概念是职责分离。你的产品代码应该描述它需要完成的工作；网关应该处理提供方访问、路由策略和运行控制。

Application
    │
    │ one authenticated request
    ▼
LLM gateway
    ├── policy and quota check
    ├── model or route selection
    ├── provider request
    ├── retry or safe fallback
    └── usage and error record
             │
             ├── Provider A / Model 1
             ├── Provider B / Model 2
             └── Provider C / Model 3

为什么不直接调用每个模型提供方？

直接集成通常是正确的起点。如果一个原型只使用一个模型、流量很低，而且不需要共享控制，那么引入网关可能带来的复杂面比价值更多。

当应用需要多个提供方，或者必须在生产环境中可靠运行时，这种权衡就会改变。

网关不会让提供商之间的差异消失。模型仍然可能具有不同的能力、上下文限制、工具 schema、流式传输行为、安全策略和定价。一个好的网关会让这些差异变得显式且可管理，而不是假装每个模型都可以互换。

LLM 网关如何工作：分步说明

1. 应用发送一个请求

应用调用一个稳定的基础 URL，并提供网关凭证。对于 OpenAI 兼容的网关，现有的 OpenAI 客户端可能只需要不同的 base_url、API 密钥和模型标识符。

2. 网关对其进行身份验证和授权

网关会验证调用方的项目、环境、用户或工作负载。然后，它可以在任何上游支出发生之前检查白名单、配额、预算或最大 token 策略。

3. 路由规则选择目标

请求可能会指定一个精确模型。它也可能使用团队管理的别名，例如 support-fast。或者，它可能进入一个会考虑能力、健康状况、区域、延迟或成本的路由策略。

在初始实现中，建议优先使用显式模型选择或简单别名。动态路由很有用，但应当在你拥有评估数据和可观测性之后再引入。

4. 网关只翻译它能够保留的内容

有些网关会在多个提供商之间暴露一个 OpenAI 兼容的契约。网关会将字段映射到所选提供商的 API，并在可能的情况下对响应进行标准化。

兼容性是有边界的。在切换模型之前，请测试结构化输出、工具调用、图像、流式传输、结束原因、token 计量以及错误行为。“兼容”应当意味着你的必需契约已经通过测试，而不仅仅是请求返回了 HTTP 200。

5. 网关处理运行策略

网关可以设置超时、遵循重试预算、暂停不健康的路由，或选择回退方案。重试必须有上限。回退必须保留任务契约。对于会产生工具副作用或部分流式输出的请求，可能需要停止并对账的流程，而不是自动重放。

如需更深入的生产设计，请参考模型回退策略操作手册和LLM 速率限制指南。

6. 网关记录发生了什么

有用的记录包括请求 ID、应用、环境、请求的模型、解析后的提供商和模型、延迟、状态、重试次数、输入和输出 token，以及估算成本。

默认情况下，不要记录原始提示词和响应。记录支持运维的元数据，并将内容日志记录视为一个单独的安全与隐私决策。

LLM 网关的七项核心职责

1. 提供商抽象

网关在应用代码与提供商 API 之间创建一个稳定边界。这减少了重复集成，也让迁移更容易测试。

2. 身份验证与密钥管理

应用向网关进行身份验证，而提供商凭据则保留在其后。这可以减少分散在代码仓库和部署环境中的上游密钥数量。它并不能消除轮换、作用域控制、脱敏和事件响应的需要。请遵循专门的安全 API 密钥管理指南。

3. 模型路由

路由可以简单到“将这个别名发送到这个模型”。更高级的策略可以使用能力、健康状态、延迟、区域或成本。保持决策可解释：每个请求都应记录选择该路由的原因。

4. 可靠性控制

网关可以集中管理超时、重试预算、熔断器、健康检查和安全回退。集中化可防止每个应用团队都发明一套不同的故障策略。

5. 限流协调

提供商通常会按时间限制请求和 token 数量。网关可以协调并发、队列、退避和路由容量，而不是让多个服务盲目争抢同一个上游配额。

6. 可观测性与成本分摊

网关能看到每个请求，因此它是附加一致遥测数据的天然位置。测量的不应只是原始 token 成本。应跟踪已接受任务率、延迟、重试次数以及每个已接受任务的成本，这样一个便宜但不可靠的路由就不会显得高效。

AI API 成本优化指南解释了如何基于工作负载结果而不仅仅是标价来比较路由。

7. 策略与治理

团队可以使用网关来限制模型、设置预算、限制 token 使用量、分离开发和生产密钥，并创建可供审计的使用记录。随着更多应用和代理共享同一模型访问层，这些控制会变得越来越有用。

LLM 网关与类似工具

初学者常常把“网关”、“路由器”、“编排框架”和“反向代理”混为一谈。它们有重叠，但并不相同。

你可以把这些层组合起来。智能体框架可能会调用 LLM gateway。网关内部可能使用路由器。反向代理也可能位于网关前面，用于网络控制。

什么时候需要 LLM Gateway？

将这份 LLM gateway 入门指南作为决策测试。当以下陈述中有两条或更多为真时，就值得评估一个网关：

• 你支持多个模型供应商。
• 多个服务或智能体需要访问模型。
• 不同环境中重复配置了供应商密钥。
• 团队无法回答是哪一个应用产生了某笔费用。
• 不同代码库的限流处理方式不一致。
• 供应商故障或降级路由中断了关键工作流。
• 你需要模型白名单、配额或环境级预算。
• 切换模型需要反复修改 SDK 或部署。
• 运维需要在应用层和供应商层之间共享一个请求 ID。

如果你目前只有一个低风险原型、一个供应商、一个负责人，并且没有生产环境的可靠性或治理要求，那么你可能还不需要网关。可以先直接接入，但请将供应商调用放在一个小型应用适配器后面，这样未来迁移时就能更可控。

面向初学者的实施方法：五个实用步骤

步骤 1：编写任务契约

选择一个真实工作负载，例如总结支持工单或从发票中提取字段。定义：

• 必需的输入和输出；
• 可接受的延迟；
• 验证规则；
• 是否需要流式输出；
• 工具是否可能产生副作用；
• 什么算作可接受的结果。

这份契约决定回退是否安全，以及另一种模型是否真的等价。

步骤 2：选择稳定的客户端接口

如果你的应用已经使用 OpenAI 兼容的 SDK，那么兼容的网关可以减少迁移工作量。例如，Flatkey 文档中提供了一个兼容 OpenAI 的 base URL：https://router.flatkey.ai/v1。

curl -X POST "https://router.flatkey.ai/v1/chat/completions" \
  -H "Authorization: Bearer $FLATKEY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "your-model",
    "messages": [
      {"role": "user", "content": "用通俗英语解释这个错误。"}
    ]
  }'

使用密钥管理器或服务器端环境变量来保存密钥。切勿将其打包到浏览器或移动客户端代码中。

步骤 3：从显式路由开始

将工作负载路由到一个经过测试的模型。如果你希望应用保持独立性，可以在配置中将内部别名映射到该模型。在拥有可重复的评估集之前，避免使用不透明的“最便宜模型”或“最佳模型”路由器。

步骤 4：添加最小可用遥测

记录：

• 网关请求 ID；
• 工作负载和环境；
• 请求的别名；
• 解析得到的提供商和模型；
• 状态和延迟；
• 重试和回退次数；
• 输入和输出 token；
• 预估成本；
• 验证结果。

这些信息足以排查最初的生产问题，并在之后比较不同方案。

步骤 5：添加一个有边界的故障策略

先为瞬时故障设置超时和少量重试预算。只有在验证备用路径也能通过同一任务契约之后，再添加回退。对于流式或带副作用的工具调用，定义应用如何检测部分完成并协调状态。

常见初学者错误

把每个模型都视为可互换

即使请求语法已经标准化，能力和输出行为仍然不同。请针对你的工作负载实际使用的具体功能进行测试。

先路由，后测量

没有评估数据的动态路由会把决策逻辑移到黑盒中。先建立基线，再引入可衡量的策略。

对每个错误都重试

认证错误、无效请求、预算耗尽以及不支持的功能都不是瞬时故障。只对以后可能成功的错误进行重试，并在适当时使用带抖动的指数退避。

默认记录敏感内容

提示词可能包含客户、源代码或业务数据。请将元数据可观测性与内容保留分开。

隐藏解析后的路由

如果应用请求的是别名，请记录实际使用的提供商和模型。否则，事故、质量回归和成本变化都将很难解释。

只衡量价格，不衡量结果

更低的 token 价格并不意味着更低的工作负载成本。请在成本计算中纳入验证失败和重试。

Flatkey 如何契合网关模式

Flatkey 提供统一的模型和工具访问层，具备一个密钥、共享使用记录以及一个与 OpenAI 兼容的模型端点。对于已有兼容客户端的情况，迁移路径是更改基础 URL、使用 Flatkey 密钥、选择受支持的模型，并测试工作负载契约。

当你希望减少各提供商账号的分散管理，而又不想自己构建和运营聚合层时，Flatkey 就会变得相关。如果你是在评估这种设计，而不是寻找入门概览，请阅读详细的 AI API 网关架构指南。如果你已经准备好迁移客户端，请使用 OpenAI 兼容 API 网关清单。

探索 Flatkey 模型，查看文档，或者在你准备好测试真实工作负载时创建 API 密钥。

LLM Gateway 入门指南检查清单

在通过 LLM 网关发送生产流量之前，请确认：

• [ ] 一个工作负载契约已定义成功标准。
• [ ] 应用使用的是服务端网关凭证。
• [ ] 所选模型已通过具有代表性的测试。
• [ ] 如果使用了结构化输出、工具和流式传输，已对其进行测试。
• [ ] 超时和可重试错误已明确定义。
• [ ] 回退策略保持了工作负载契约。
• [ ] 每个请求都会获得可追踪的请求 ID。
• [ ] 已记录解析出的提供商和模型。
• [ ] 已衡量 token、延迟、重试、验证和成本。
• [ ] 开发和生产配额已分离。
• [ ] 原始内容日志记录已禁用，或由明确的策略管理。
• [ ] 已记录直接回滚路径。

常见问题

LLM 网关和 API 网关是一样的吗？

它是面向 AI 模型流量的专用 API 网关。它可以提供身份验证和速率限制等标准 API 网关功能，以及感知模型的路由、token 用量、AI 特定错误归一化和契约感知回退。

LLM 网关会托管这些模型吗？

不一定。有些网关路由到外部提供商，有些与推理基础设施集成，还有些同时支持两者。应询问推理发生在哪里、哪个提供商实际提供每个模型，以及这条路径在使用记录中如何体现。

LLM 网关能降低成本吗？

它可以通过集中使用数据、应用配额、减少重复集成并支持可衡量的路由变更来帮助降本。但节省并不是自动发生的。应比较每个被接受任务的成本，包括重试和质量失败。

我可以将 LLM 网关与 OpenAI SDK 一起使用吗？

可以，前提是该网关提供 OpenAI 兼容的端点，并支持你的应用所使用的功能。更改 base URL 和凭证，然后测试完整的工作负载契约，而不要想当然地认为它完全兼容。

网关会成为单点故障吗？

有可能。应评估其部署架构、健康检查、上游故障切换、超时行为、可观测性、服务承诺以及回滚路径。集中控制会提升运维杠杆，因此网关本身必须被视为生产基础设施。

初创公司应该自建还是购买 LLM 网关？

当网关行为是核心差异化能力、你需要特殊的部署约束，或团队具备运维能力时，选择自建。当主要目标是更快接入、更少的提供商集成、统一使用情况和共享控制时，选择购买。小团队也可以先直连，若提供商调用已通过适配器隔离，之后再迁移。

简单心智模型

这份 LLM gateway 入门指南 最简洁的版本是：

你的应用请求 AI 工作。网关决定请求是否允许、应该转到哪里、失败应如何处理，以及应记录什么。

从一个工作负载、一个稳定接口、显式路由、最低可行遥测和一项有边界的故障策略开始。只有在你能够衡量质量、延迟、可靠性和成本之后，再添加更复杂的路由。

来源

• Flatkey 文档
• Flatkey 产品概览
• Cloudflare AI Gateway 文档
• Azure API Management 生成式 AI 网关功能
• LiteLLM 代理文档