LLM Gateway 与 Router 与 Inference Provider：架构边界

LLM gateway（网关）、router（路由器）和 inference provider（推理提供商）是模型服务栈中的三个不同层级，混淆它们是团队在构建 AI 产品时最常犯的错误。网关最靠近您的应用程序，负责处理身份验证、标准化和可观测性；路由器决定由哪个模型或提供商处理特定的请求；推理提供商则是实际运行权重并返回 token 的实体。

如果弄错了这个边界，会导致集成变得脆弱：团队硬编码了某个单一提供商的 SDK，几个月后却发现，若要添加回退模型或对比 Claude Sonnet 5、GPT-5.5 和 DeepSeek V4 Flash 之间的成本，意味着必须重写大部分请求处理逻辑。本文将这三个层级区分开来，展示了职责的实际归属，并提供了一个评估各类供应商的决策框架。

核心要点

• 推理提供商运行模型权重并暴露 API（如 OpenAI、Anthropic、Google、DeepSeek 或自托管引擎如 vLLM）；路由器在提供商或模型之间进行请求选择；网关是面向应用程序的层级，统一了跨两者的身份验证、格式化、日志记录和故障转移。
• 路由逻辑（基于成本、延迟或能力的筛选）可以作为独立服务存在，也可以作为网关内部的功能存在；它与网关本身并非同一事物。
• 自托管推理提供商、使用基于 API 的提供商以及使用多提供商网关并非互斥；生产系统通常根据模型和工作负载组合使用这三者。
• 评估供应商时，请询问他们实际运行在哪个层级，因为营销为“路由器”的产品可能仅在它不托管的 OpenAI 兼容端点之间进行路由，而“网关”可能捆绑了您尚不需要的路由及治理功能。

推理提供商的实际职责

推理提供商是拥有模型权重、GPU（或同等加速器）以及底层服务引擎的层级。这包括商业 API 提供商，如 Anthropic (Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5)、OpenAI (GPT-5.5)、Google (Gemini 3.5 Flash)、智谱 (GLM-5.2) 和 DeepSeek (DeepSeek V4 Pro, DeepSeek V4 Flash)，以及对开放权重模型（如 Qwen3.7 Plus, MiniMax M3 或 Kimi K2.7 Code）的自托管部署。

如果您进行自托管，推理提供商层级就是您自己运行的软件。vLLM 的服务文档描述了一个围绕连续批处理和内存高效注意力机制构建的推理引擎，用于大规模服务 LLM 工作负载，这正是位于自托管模型部署之下的组件。运行 vLLM（或类似引擎）意味着您成为了该模型的推理提供商，负责 GPU 容量规划、扩展和正常运行时间，以换取对成本和数据本地化的控制。

如果您使用商业 API，提供商的基础设施和速率限制将成为您的约束。每个提供商都有自己的身份验证方案、请求和响应模式、错误代码以及速率限制行为。这是决定模型质量、上下文窗口和原始延迟的层级。没有任何路由器或网关能改变推理提供商的能力；它们只能改变您访问它的方式。

路由器的职责

路由器是选择传入请求的目标、模型或提供商的决策逻辑。路由可以发生在多个维度上：成本（将简单查询发送给廉价模型，如 DeepSeek V4 Flash 或 Gemini 3.5 Flash，将 Claude Opus 4.8 保留给复杂任务）、延迟（优先选择当前响应最快的提供商）或可用性（如果第一个提供商降级，则故障转移到第二个提供商）。

OpenRouter 关于模型路由的公开说明描述了模型层面的这种模式：对开放权重模型的请求可以在托管相同权重的多个提供商之间进行路由，因此单个逻辑模型调用可以由多个后端中的任何一个来完成。OpenRouter 的提供商选择文档进一步描述了用于表达排序偏好以及排除特定提供商的参数，这是调用者显式表达路由意图而非完全依赖平台的机制。

重要的架构观点是，路由是一种策略，而不是一个独立的产品类别。您可以在应用程序代码中自行实现基本路由（针对任务类型进行简单的 if/else 或错误重试循环），将其作为专用路由层购买，或者将其包含在更广泛的网关中。评估路由能力时，请询问它使用哪些信号（价格、延迟、错误率、模型能力），以及这些信号是可配置的还是固定的。

网关的职责

网关是您的应用程序代码实际交互的层级。它的工作是提供一个统一的接口，无论最终由哪个推理提供商处理请求。网关通常包括：

• 跨提供商的统一请求和响应模式，因此从 GPT-5.5 切换到 Claude Sonnet 5 不需要重写您的解析逻辑。
• 身份验证和密钥管理，使提供商凭据不会散落在应用程序代码中。
• 跨所有正在使用的模型和提供商的日志记录、使用情况跟踪和成本归因。
• 当提供商响应缓慢、受速率限制或返回错误时的故障转移和重试行为。
• 可选地，将路由逻辑作为多个功能中的一个，而不是整个产品。

TokenLab 的模型研究页面编录了各提供商的当前模型，包括前沿模型 (Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5, GPT-5.5, GLM-5.2, Gemini 3.5 Flash)、编码导向模型 (Claude Sonnet 5, Kimi K2.7 Code, DeepSeek V4 Pro, DeepSeek V4 Flash) 以及低成本路由候选模型 (DeepSeek V4 Flash, GLM-5.2, Laguna XS 2.1, Hy3, Qwen3.7 Plus, MiniMax M3)，这是网关用户在决定路由目标时所需的参考资料。请参阅 TokenLab 关于 为什么统一 AI API 网关在 2026 年至关重要 的文章，以更全面地了解统一化问题本身。

具体的架构边界

通过追踪单个请求穿过所有三个层级，可以最直观地看到边界。

1. 您的应用程序向网关端点发送聊天完成请求，指定任务类型或模型偏好。
2. 网关对请求进行身份验证，将其标准化为每个候选提供商预期的模式，并交给路由逻辑。
3. 路由器评估其配置的策略（成本上限、延迟目标或显式提供商顺序）并选择目标，例如通过 Anthropic API 使用 Claude Sonnet 5，或通过 vLLM 服务托管的 DeepSeek V4 Pro 实例。
4. 推理提供商执行模型并返回 token。
5. 网关将响应标准化回一致的形状，并记录结果（延迟、成本、使用的提供商、成功或失败），以供您的 可观测性层 使用。

每个层级都可以独立失败。提供商中断是推理层的问题；错误的路由决策（将长上下文请求发送给上下文窗口较小的模型）是路由器层的问题；不一致的响应模式破坏了您的解析器是网关层的问题。了解哪个层级产生了特定的故障，是使调试变得可控的关键。TokenLab 关于 AI API 可靠性基础设施 的文章更深入地涵盖了跨这些层级的故障隔离。

决策清单

在评估您是否需要网关、路由器、直接提供商集成或某种组合时，请使用此清单。

问题	如果是	如果否
您现在是否调用超过一个模型或提供商，或者预计在 12 个月内会这样做？	您需要网关或路由层，而不是每个提供商的直接 SDK 调用。	直接提供商 SDK 集成在短期内可能足够。
当提供商降级或受速率限制时，您是否需要自动故障转移？	您需要具有健康检查和回退排序的路由器级逻辑。	应用程序代码中的手动重试最初可能是可以接受的。
您是否需要在一个地方查看跨提供商的各模型成本和使用情况？	您需要网关级的日志记录和归因。	提供商原生的仪表板目前可能满足您的需求。
您是否正在自托管任何开放权重模型 (GLM-5.2, DeepSeek V4 Pro, Qwen3.7 Plus, Kimi K2.7 Code)？	您同时也在运营推理提供商层级，需要 vLLM 等服务基础设施。	您可以完全依赖商业 API 提供商。
您是否需要按任务类型进行路由（分类用廉价模型，推理用前沿模型）？	您需要显式的路由器策略，而不仅仅是故障转移。	单个默认模型可能就足够了。

请求形状示例

下面的示例展示了网关式请求的一般形状，它同时表达了首选模型和回退列表，这种模式与 OpenRouter 提供商选择文档中描述的表达路由偏好的方式一致。请将字段名称视为说明性的；在发布前，请根据您所选网关的当前 API 参考验证确切参数。

POST /v1/chat/completions
Content-Type: application/json
Authorization: Bearer <api_key>

{
  "model": "claude-sonnet-5",
  "fallback_models": ["gpt-5.5", "deepseek-v4-flash"],
  "routing_policy": {
    "strategy": "cost_then_latency",
    "max_cost_per_1k_tokens": 0.01
  },
  "messages": [
    {"role": "user", "content": "Summarize the attached incident report."}
  ]
}

在这种形状中，网关拥有请求标准化和响应契约，路由器拥有解释 routing_policy 和 fallback_models 的权限，而最终选择的提供商则负责实际生成补全。在依赖生产环境中的任何特定字段名称之前，请务必根据当前文档确认确切的请求和响应模式。

局限性

来自 OpenRouter 和 vLLM 的公开文档描述的是通用的路由和服务机制，而非普遍保证。确切的延迟、定价和故障转移行为因提供商而异，并会随时间变化，因此请直接根据提供商文档验证当前数据，而不是依赖本文。使用 vLLM 进行自托管会将运营责任（容量规划、扩展、修补）转移到您的团队；它并没有消除基础设施工作，而是重新定位了它。没有任何路由策略可以弥补根本上不匹配的模型选择，例如将需要长上下文推理的任务发送给不适合该任务的模型；路由器配置不能替代根据您的工作负载评估模型能力，这就是为什么维护像 TokenLab 模型研究 这样最新的模型参考资料至关重要的原因。

常见问题解答

网关和路由器是一回事吗？ 不是。路由器是用于选择模型或提供商的决策逻辑；网关是更广泛的面向应用程序的层级，它将路由作为除身份验证、标准化和日志记录之外的一种可能功能包含在内。

我可以既是自己的推理提供商又使用网关吗？ 是的。通过 vLLM 等引擎服务的自托管模型可以位于与商业 API 提供商相同的网关之后，只要网关支持自定义或 OpenAI 兼容的端点即可。

我第一天就需要这三个层级吗？ 不一定。对于早期原型，单提供商直接集成是合理的。一旦您需要故障转移、多模型成本控制或提供商对比，引入带有路由功能的网关就值得投入工程成本。

如果您正在评估首先采用哪个层级，请查看 TokenLab 模型研究页面 上的当前模型选项，并从网关设置开始，这样您就可以逐步添加路由和提供商，而不是预先承诺单一集成。