AI 应用系统：网关层 — 多模型路由、故障转移与成本控制

上一篇文章讲到，不管选 API 还是自建，最终都会收敛到一个统一入口。本篇展开网关层：什么是网关、为什么要建、怎么选、以及需要注意什么。

网关层解决了什么问题

AI 网关是一个轻量代理层，位于应用和模型之间，提供统一接入、路由、鉴权、观测和成本控制。

今天没有一个模型在所有维度上最优。GPT-5.5 的指令遵循最好，Kimi K2.6 长上下文能力突出，DeepSeek V4 Flash 性价比最高，Claude Opus 在复杂推理上最强。当项目需要同时使用多个模型时，没有网关层就意味着每一处调用都要硬编码模型提供商、API key、重试逻辑和错误处理。

网关层把这些问题收拢到一个点：

网关不是新概念。OpenRouter 就是一个典型例子：它把几十个模型提供商收拢到一个 OpenAI 兼容的 API 端点，换模型只需要改 model 参数。但 SaaS 网关把数据送到第三方网络，延迟和隐私不可控，调用量大时成本也不划算。所以当项目进入生产阶段，自建网关就成了更务实的选择。

以下讨论围绕自建网关展开。

核心功能

统一 API

所有主流模型提供商已经兼容 OpenAI SDK 格式。网关在此基础上再做一层统一：不管是 DeepSeek 还是 Claude，用同一套客户端配置。新模型接入在网关层是一行配置，调用方零改动。

LiteLLM 100 行代码实现了 100+ 模型的统一接口：

from litellm import completion

response = completion(
    model="claude-sonnet-4.6",  # 统一模型名
    messages=[{"role": "user", "content": "你好"}]
)

加上一个层之后，应用代码不再关心背后是哪个模型。

多模型路由

网关根据请求特征把流量分到不同模型。常见的路由策略：

以 OpenRouter 为例，通过路由头和失败模型参数配置请求分发（Portkey 文档有更完整的路由策略组合）：

client = OpenAI(
    base_url="https://openrouter.ai/api/v1",
    api_key="sk-or-v1-...",
    default_headers={
        "HTTP-Referer": "https://myapp.com",
        "X-Title": "MyApp",
    }
)
# 路由头：优先 DeepSeek Flash，失败时回退 GPT-5.5 Mini
response = client.chat.completions.create(
    model="deepseek/deepseek-chat",
    extra_headers={
        "X-Fallback-Models": "openai/gpt-5.5-mini",
    },
    messages=[{"role": "user", "content": "你好"}]
)

故障转移

模型服务随时可能出问题：API 限流、网络抖动、模型更新导致行为变化。网关的故障转移机制持续探测后端可用性，检测到异常后即时切换。

标准失败链配置：

# Portkey fallback chain
fallback_strategy:
  - provider: deepseek
    model: deepseek-chat
  - provider: openai
    model: gpt-5.5-mini
  - provider: anthropic
    model: claude-haiku-4
  - fallback_behavior: exponential_backoff
    max_retries: 3

配置了失败链后，网关遇到超时或 5xx 错误时会自动尝试备选模型，对调用方无感。

虚拟 key 与鉴权

真实的 API key 不应该散落在代码、环境变量、配置文件里。网关层提供虚拟 key 机制：每个应用或团队分配一个独立 key，网关做真实 key 的映射和替换。

虚拟 key 的价值：

• 隔离：一个 key 泄露不影响其他应用
• 计量：每个虚拟 key 独立计费，成本精确到应用级
• 配额：按 key 设置每日调用上限，防止预算失控
• 吊销：即时生效，不需要更新下游代码

成本控制

API 不是固定成本——调用量决定了账单，而调用量取决于用户行为。网关提供三道防线防止账单爆炸：

1. 预算上限：月度/日度配额，超限自动熔断
2. 模型分级：复杂/昂贵的模型只开放给指定 tier 的请求
3. 缓存：重复的 prompt 命中缓存，零 token 成本

Portkey 的预算告警配置：

budget:
  monthly_limit: 1000  # USD
  alert_at:
    - 50%   # 用满 50% 发通知
    - 80%
    - 100%  # 告警但不熔断
  hard_limit: 1100     # 硬上限，超过即熔断

缓存方面，常见的策略是语义缓存：两次 prompt 在语义上足够接近时直接返回缓存结果。这在大规模客服、文档问答场景下效果显著——命中率做到 30-50%，对应 30-50% 的 token 成本节省。

主流网关方案对比

选择建议

new-api 是国内社区最流行的自建网关方案。提供 Web 管理后台、用户/渠道管理、按量计费、日志追踪，一个 key 聚合 DeepSeek、通义千问、智谱、OpenAI 等多种渠道。MIT 许可证，Go 语言实现，部署简单。适合国内团队自建，特别是需要给多用户分发额度并统计用量的场景。

Bifrost 主打高性能和易用性。提供 Web UI 配置、自适应负载均衡、语义缓存、预算管理、OIDC 用户同步。Go 实现，5000 RPS 下额外延迟低于 100µs，支持 23+ 模型提供商和 MCP 协议。适合对延迟敏感、需要企业级治理功能的中大型项目。

Portkey 适合需要精致成本控制的中大型项目。支持自托管部署，提供虚拟 key、实时配额、缓存——已经像一个完整的成本控制平台了，不只是网关。

LiteLLM 适合需要深度定制的场景。开源、Python 原生、支持 100+ 模型。缺点是需要自己维护和部署，多做一步运维工作。

Kong 如果在已有 Kong 基础设施的团队中使用，多几台推理节点只是多加一个 upstream 的事。但只为了 AI 网关去部署一套 Kong，投入产出比太低。

网关层的陷阱

额外的延迟

网关每增加一跳就会增加 10-50ms 的延迟。在低延迟场景（实时语音、流式渲染）中，网关引入的延迟可能比模型响应时间还刺眼。

解法：物理上靠近模型端点部署网关，或者在延迟敏感的场景绕过网关直连。

单点故障

网关本身就是中心化的。网关挂了，所有模型调用都不可用。

解法：多区域部署 + DNS 负载均衡。网关无状态，水平扩展成本不高。关键业务场景下可以配置本地 failover 策略，网关检测到自身异常时直连模型。

复杂度转移

网关让应用层变简单了，但网关本身是需要维护的。自建网关意味着要处理配置管理、版本升级、性能调优、监控告警。

网关层的边界

网关不是编排。网关只做路由、鉴权、观测、成本控制四件事。如果需要在多个 Agent 之间协调任务、维护对话上下文、做任务拆解分发——那是编排层的职责。

这个区分很重要。把编排逻辑塞进网关会让两个层的职责混淆，网关变得又重又不可控。网关应该是无状态的，所有状态应该在编排层或应用层维护。

再次强调落地路径

第一篇的四层架构里，有一个务实的建议：网关层通常值得提前考虑——部署成本低且后续大概率用得上。

一组实际数据可以说明（基于笔者团队在多个项目中的实测统计，不代表所有场景）：当一个调用量日均 10 万次的项目从单模型切换到双模型时，网关层的价值体现在几个方面。故障转移每年能覆盖数次到十几次不同程度的中断；虚拟 key 能让问题定位时间从小时级缩短到分钟级；模型分流使月成本降低 30-70%（三个数字对应不同切换策略）。而这一切只需要往代码路径上加一个跳板，不改变架构、不增加运维。

网关层可能是整个 AI 架构里投入产出比最高的基础设施。与模型层的 token 价格议价不同，网关带来的是结构化省钱——在不降低服务质量的前提下减少浪费。

下一篇讲编排层，讨论什么时候需要 Agent 协作、什么时候不需要，以及常见的编排陷阱。

参考

• Bifrost — 高性能 AI 网关，Go 实现，<100µs 开销
• OpenRouter 文档
• new-api — 开源 AI 网关，Go 实现，带管理后台
• Portkey 文档
• LiteLLM
• Kong AI Gateway
• Portkey 路由策略：条件路由、负载均衡与故障转移