LLM Gateway 新手指南：从首次请求到生产环境

LLM Gateway 新手指南：从首次请求到生产环境

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

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

这篇LLM gateway 新手指南解释了这一层的作用，请求如何穿过它，它与相邻工具有何不同，何时需要它，以及如何在不过度设计的前提下实现第一次网关集成。它还提供了构建还是购买的评分表、分阶段上线计划，以及可衡量的验收标准，帮助你判断网关是否真正创造了业务价值。

2026 年 8 月 4 日更新：本指南现已加入一个前 100 次请求实验室，包含请求信封、三个测试批次、验收台账，以及生产退出标准，并附带 15 分钟快速开始和上线检查清单。

60 秒新手决策

如果一个应用只调用一个提供商、工作负载仍处于实验阶段，并且短暂故障或手动轮换密钥不会影响客户，那么你可能还不需要 LLM 网关。

当以下陈述中有两个或以上为真时，你就应该评估网关：

• 你的应用正在使用，或预计将使用，多个模型提供商；
• 多个服务需要 AI 凭证和使用控制；
• 限流或提供商事故可能中断客户工作流；
• 财务无法将模型支出核对到某个团队、产品或客户；
• 更换模型需要应用部署；
• 你需要共享的允许名单、配额、审计追踪或故障转移策略；
• 开发者正在多个仓库中重复构建相同的提供商适配器。

新手常犯的错误是因为架构图看起来成熟就采用网关。只有当它能消除重复的运维工作，或创建一个你可以衡量的控制能力时，才应该采用它。

什么是 LLM 网关？

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

• 一个用于模型请求的端点；
• 一个身份验证边界；
• 一致的请求和响应契约；
• 集中化的使用记录；
• 决定请求去向的路由规则。

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

这个 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，以及预估成本。

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

15 分钟 LLM 网关快速入门

理解网关最快的方法，是先通过它路由一个非关键请求。使用服务器端测试脚本、明确的模型，以及一个带有明显预期结果的提示词。不要从自动路由或生产代理开始。

步骤 1：记录直接提供商基线

在更改任何内容之前，请从当前的直接调用中保存五项事实：

1. 响应是否满足任务；
2. 总延迟，以及如果是流式传输，则记录首个 token 的耗时；
3. 输入和输出 token 数；
4. 提供商请求 ID 和错误形态；
5. 已接受结果的预估成本。

这能为你提供可比较的具体基准。网关迁移并不是仅仅因为返回了 HTTP 200 就算成功。

步骤 2：更改连接，而不是更改工作负载

对于 OpenAI 兼容的网关，面向应用的更改通常是网关 API 密钥、网关基础 URL，以及受支持的模型标识符。具体的环境变量名称取决于客户端和网关。

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["LLM_GATEWAY_API_KEY"],
    base_url=os.environ["LLM_GATEWAY_BASE_URL"],
)

response = client.chat.completions.create(
    model=os.environ["LLM_GATEWAY_MODEL"],
    messages=[
        {"role": "system", "content": "仅返回有效 JSON。"},
        {"role": "user", "content": "将此工单分类为 billing、bug 或 feature：我被重复扣费了。"},
    ],
    temperature=0,
)

print(response.choices[0].message.content)

将凭据保留在服务器端。切勿将网关主密钥放在浏览器 JavaScript、移动端二进制文件、公开仓库或共享截图中。

步骤 3：比较响应契约

不要只检查文本质量。确认你的应用实际会消费的字段：

• response ID 和 model name；
• finish reason；
• token usage；
• streaming 事件顺序；
• structured output 行为；
• tool-call 标识符和参数；
• HTTP status 和 error body；
• 取消和超时行为。

OpenAI 兼容性减少了迁移工作量，但并不保证每个提供商功能的行为都完全一致。请测试你的代码所依赖的契约。

步骤 4：强制触发一个安全失败

在测试环境中触发一个可预测的失败，例如无效的模型名称、故意设置得极小的超时时间，或开发配额。验证网关会返回一个可追踪的请求 ID，以及一个你的应用可以分类的错误。

不要通过制造失控的生产负载来测试提供商宕机。目标是证明你的应用能够区分认证、限流、超时、上游和校验失败。

步骤 5：使用验收表做出决定

如果网关在任何必需行上失败，在差距修复或明确接受之前，不要将其投入生产。

你的前 100 次网关请求：一个新手实验室

一次成功的首次请求证明了连通性，但不能证明网关已足够安全可用于生产。下一个有价值的里程碑是一组小而可控的100 个代表性请求，用于测试兼容性、可追踪性、故障处理和运行纪律。

这个实验室是刻意设计得很简单的。它不需要动态路由、复杂的评估平台，或大规模生产迁移。它提供的证据足以让初学者决定是继续推进、修复某个具体缺口，还是回到直接使用提供商的路径。

从请求信封开始

在发送流量之前，先定义随每个请求一起传递、或出现在对应网关记录中的元数据。一个最小请求信封可以像这样：

{
  "request_id": "gw_test_0001",
  "environment": "staging",
  "workload": "support_ticket_classification",
  "requested_route": "ticket-classifier-v1",
  "customer_tier": "internal-test",
  "contains_sensitive_data": false,
  "timeout_ms": 12000,
  "max_attempts": 2,
  "evaluation_case_id": "ticket_014"
}

你的网关可能会使用请求头、标签、元数据字段或服务器端上下文，而不是这段完全相同的 JSON。关键在于，应用、网关和评估记录共享一个稳定的请求身份。

不要在路由标签中放入原始密钥、完整提示词、个人数据或机密客户文本。保持运维元数据与内容分离。如果工作负载包含敏感数据，请记录其分类并应用相应的日志策略，而不是把内容复制到可观测性字段中。

批次 1：40 个正常请求

使用 40 个具有代表性的输入，这些输入应当能够在主路径上成功。包含简单、典型和边界案例，而不是重复同一个演示提示词。

对每个请求，记录：

• 输出是否通过了任务特定验证；
• 网关和上游请求 ID；
• 请求的别名以及解析到的提供商/模型；
• 总延迟以及首个 token 的时间（如适用）；
• 输入和输出 token 数（如可用）；
• 重试或回退次数；
• 估算成本；
• 最终处理结果：接受、拒绝或人工复核。

目标不是拿到完美分数。目标是发现失败是否可见、是否能解释。一个带有完整追踪记录的被拒绝输出，比一个看起来合理但没有路由或用量记录的输出更有价值。

批次 2：30 个契约边缘请求

接下来的 30 个请求用于覆盖你的应用所依赖的确切特性。可从以下内容中选择：

• 接近你已批准输入上限的长上下文；
• 严格的 JSON 或受 schema 约束的输出；
• 流式开始、取消和完成；
• 带有有效和无效参数的工具调用；
• 如果工作负载使用图片、音频或文档输入，也包括这些；
• 多语言提示词；
• 空请求、格式错误请求或超大请求；
• 应当被应用策略拒绝的内容。

不要假设 OpenAI-compatible 端点会让每一种边缘行为都完全相同。只有当你的应用能够正确消费响应，并且在不悄悄破坏工作流的情况下对不支持的行为进行分类时，网关才算通过这一批测试。

批次 3：30 个受控失败请求

使用非生产环境测试有界故障行为。包含以下安全案例，例如：

1. 无效的模型或路由名称；
2. 缺失或已撤销的开发凭证；
3. 故意设得很小的超时时间；
4. 开发配额或速率限制条件；
5. 一次模拟的可重试上游错误；
6. 一个与任务契约故意不兼容的备用候选项。

最后一种情况很重要。网关不应仅仅因为另一个模型可用就进行重路由。如果备用路由无法保留结构化输出、工具行为、数据策略或质量要求，正确做法是停止并返回已分类错误。

如需更深入的故障策略，请使用 模型回退策略工作流操作手册 和 LLM 速率限制指南。

保持每个请求一行的验收台账

你可以先从电子表格或数据库表开始。在你真正理解这些案例之前，避免使用会隐藏底层案例的仪表盘。

在完成 100 次请求后，至少计算四项汇总指标：

accepted completion rate = accepted results / total requests

trace coverage = requests with complete route and request IDs / total requests

retry amplification = total upstream attempts / total gateway requests

cost per accepted result = total estimated cost / accepted results

不要只根据原始请求价格来比较网关。一个低价但验证失败、触发重复尝试或需要人工修复的请求，可能比一个价格更高但能正确完成任务的请求更昂贵。

使用明确的生产退出标准

在实验开始之前，将每项标准标记为必需、可选或不适用。然后用证据而不是热情来做决定。

使用以下三种结果之一：

• Go：所有必需标准都通过；将一个低风险工作负载迁移到小规模金丝雀环境。
• Fix：网关可行，但某个明确的兼容性、遥测、安全或故障策略缺口阻止其进入生产。
• Stop：该层增加了风险或运维工作，却没有解决当前可衡量的问题。

只有当有人负责该决策、证据已保存且回滚路径仍然可用时，实验室才算完成。这会把“我们连接到了一个 LLM gateway”转化为可重复的工程结果。

LLM Gateway 的七项核心工作

1. 提供商抽象

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

2. 身份验证和密钥管理

应用向网关进行身份验证，而提供商凭据保留在网关后面。这可以减少跨仓库和部署环境分发的上游密钥数量。但这并不意味着不再需要轮换、范围控制、脱敏和事件响应。请参阅专门的 安全 API 密钥管理指南。

3. 模型路由

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

4. 可靠性控制

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

5. 速率限制协调

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

6. 可观测性和成本分摊

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

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

7. 策略与治理

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

LLM 网关与类似工具

初学者常常将“gateway”、“router”、“orchestration framework”和“reverse proxy”混用。它们有重叠，但并不相同。

你可以组合这些层。一个代理框架可能会调用 LLM 网关。网关内部可能会使用路由器。为了网络控制，一个反向代理也可能位于网关前面。

什么时候你需要一个 LLM 网关？

将这份 LLM 网关新手指南用作决策测试。当以下陈述中有两条或以上为真时，网关就值得评估：

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

如果你现在只有一个低风险原型、一个提供商、一个负责人，并且没有生产环境的可靠性或治理需求，那么你也许还不需要网关。可以先直接访问，但请把提供商调用放在一个小型应用适配层之后，这样未来迁移才可控。

自建还是购买一个 LLM 网关：实用评分表

最重要的业务评估问题不是网关是否有用，而是你们团队应该负责哪些部分。你可以自建网关、采用托管服务、运行开源代理，或者将它们组合使用。

不要从功能清单中做选择，而要使用加权评分卡。将每个选项按 1 到 5 分评分，再乘以权重，最后比较总分。下面的权重只是起点，不是普遍适用的规则。

当控制本身就是产品时，选择自建

当路由行为是核心竞争优势、法规要求一种现有服务无法满足的部署模式，或者你的流量规模足以支撑专门的平台团队时，自建是合理的。但“自建”不只是转发 HTTP 请求。它意味着你要负责身份验证、提供商适配器、模式差异、流式传输、错误规范化、配额、可观测性、发布管理、安全审查和事故响应。

当访问和运维不构成差异化时，选择购买

当目标是更快接入多个提供商、统一计费和凭证，或为多个应用提供共享控制平面时，托管网关通常更合适。评估时仍应包含退出路径。将网关置于应用适配器之后，保留模型能力测试，并避免在整个产品代码中嵌入特定提供商的假设。

当你能够运维时，使用开源方案

开源网关或代理可以提供灵活性和代码可见性，但自托管会把可用性、扩缩容、升级、遥测存储和安全补丁工作转移给你的团队。比较总的运维责任，而不仅仅是软件许可证。

LLM 网关的四阶段上线流程

安全的上线应一次验证一层。不要一开始就在所有工作负载上启用动态成本路由。

第 1 阶段：兼容性影子测试

在不改变生产行为的前提下，将一组具有代表性的评估集通过候选网关发送。验证请求字段、响应、流式传输、工具调用、结构化输出、使用量字段和错误。记录每一处不匹配。如果应用契约发生变化，单纯的 HTTP 成功响应还不够。

退出条件：网关能够通过工作负载所需的功能和质量检查，且没有无法解释的契约丢失。

阶段 2：一个低风险工作负载

将一个可回滚、非关键的工作负载迁移到一个明确的模型路由上。在添加重试或回退之前，保留之前直接访问提供商的路径作为回滚方案。添加请求 ID 和已解析路由遥测后，再引入重试或回退。

退出条件：团队能够解释每一个失败请求，核对使用量，并且无需代码发布即可回滚。

阶段 3：可靠性策略

添加有上限的超时、重试分类，以及针对你实际观察到的某种故障模式的一个经过测试的回退方案。不要仅仅因为两个模型都能接受相似的 JSON，就在它们之间进行回退。备用路由必须满足相同的工作负载契约。

如需更深入的恢复设计，请参考 model fallback strategy playbook 和 LLM rate limits guide。

退出条件：故障演练表明，重试和回退能够提高被接受的完成率，同时不会导致重复副作用、失控的延迟或不可控的开销。

阶段 4：共享生产控制平面

只有在首个工作负载拥有稳定的度量后，才继续扩展。添加租户配额、模型允许列表、环境隔离、预算告警，以及一套记录在案的路由变更流程。审查谁可以修改策略，以及这些变更如何被审计。

退出条件：多个应用可以使用该网关，而不会丢失成本归因、事件追踪性、安全边界或回滚控制。

新手错误映射：重试、改路由，还是停止？

网关的可靠性，与其说取决于回退模型的数量，不如说取决于是否能针对每一种故障做出正确决策。可将这个简化映射作为起点。

有上限的这个词很重要。每个工作流都需要最大重试次数、总时间预算和终止状态。否则，网关可能把一次提供方事故变成重复的工具操作、失控的成本，以及更大规模的中断。

要深入实现，请使用 模型回退策略操作手册。

如何衡量网关是否在正常工作

网关成功与否，并不在于连接了多少提供方，而在于是否提升了可接受的结果和运营控制能力。

在迁移前建立基线。然后比较相同的工作负载、评估集、流量分段和时间窗口。如果质量下降、延迟增加，或成本更难对账，那么更低的表面 token 价格并不代表网关成功。

关于成本分析，请继续阅读AI API 成本优化指南。如需更完整的遥测方案，请使用AI 可观测性实施清单。

新手实施：五个实用步骤

步骤 1：编写任务契约

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

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

该契约决定了回退是否安全，以及另一个模型是否 वास्तव上等效。

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

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

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": "Explain this error in plain English."}
    ]
  }'

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

步骤 3：从显式路由开始

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

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

记录：

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

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

步骤 5：添加一条有边界的失败策略

先为瞬时故障设置超时和少量重试预算。只有在确认备用路径通过相同的任务契约后，才添加回退。对于流式传输或会产生副作用的工具调用，请定义应用如何检测部分完成并协调状态。

您使用 LLM 网关的第一周

采用为期七天的上线计划，而不是一次性迁移所有应用。

第 1 天：盘点一个工作负载

写下当前的提供方、模型、SDK、凭据、所需功能、流量、延迟预算、数据敏感性以及回滚负责人。

第 2 天：运行兼容性测试

通过直连路径和网关路径发送具有代表性的提示。若工作负载会用到长输入、结构化输出、流式传输、工具以及预期错误案例，也一并纳入测试。

第 3 天：添加请求标识和使用记录

确认应用会存储网关请求 ID，并且能够将其关联到模型、提供方路由、延迟、token 数、重试次数和验证结果，同时默认不记录敏感内容。

第 4 天：定义失败策略

将错误分类为停止、重试、等价故障转移、跨模型回退和人工复核。设置总重试预算和延迟预算。

第 5 天：发送一个小规模生产金丝雀流量

使用一个低风险工作负载，并且只分配刻意设得很小的流量份额。保留直连路径可用。比较已接受完成率、p95 延迟和每个已接受结果的成本。

第 6 天：审查安全与支出控制

分离开发和生产凭据，限制允许的模型，设置配额，并确认谁可以查看或更改路由策略。使用安全 API 密钥管理指南获取更完整的控制检查清单。

第 7 天：做出继续、修复或停止的决定

• 继续：所需的契约检查全部通过，且金丝雀测试达到其验收阈值。
• 修复：架构是合理的，但有一个可衡量的缺口阻碍扩展。
• 停止：网关带来了运营风险或成本，而当前并没有相应的控制收益。

记录决定和下次复审日期。受控停止总比没有测量过的迁移更好。

常见新手错误

把每个模型都当成可互换的

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

先路由，后测量

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

对每个错误都重试

认证错误、无效请求、预算耗尽和不支持的功能都不是暂时性问题。只对以后可能成功的错误重试，并在适当情况下使用带抖动的指数退避。

默认记录敏感内容

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

隐藏解析后的路由

如果应用请求的是别名，请记录实际使用的提供方和模型。否则，事故、质量回退和成本变化就会变得难以解释。

衡量价格而不是结果

更低的 token 价格并不保证更低的工作负载成本。把验证失败和重试也纳入成本计算。

Flatkey 如何契合网关模式

Flatkey 提供一个统一的模型和工具访问层，只需一个密钥、共享的使用记录，以及一个与 OpenAI 兼容的模型端点。对于现有的兼容客户端，迁移路径是更改 base 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 兼容端点，并且支持你的应用所使用的功能即可。先更改基础 URL 和凭证，然后测试完整的工作负载契约，而不要假设它天然完全兼容。

网关是单点故障吗？

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

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

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

在迁移生产流量之前我应该测试什么？

测试精确的工作负载契约：流式输出、结构化输出、工具、媒体输入、上下文限制、错误行为、超时处理、使用字段以及输出质量。然后使用低风险金丝雀发布，并保留直接回滚路径，对比已接受完成率、p95 延迟以及每个已接受结果的成本，相对于网关之前的基线。

简单的心智模型

这份 LLM 网关新手指南 的最简版本是：

你的应用请求 AI 工作。网关决定请求是否允许、应该路由到哪里、故障应如何处理，以及需要记录什么。

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

来源

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