一、项目背景

我们支撑某省级国资集团的内部大模型平台项目。这家客户的业务系统很多——OA 智能问答、合同审查、报表生成、代码辅助，还有面向一线员工的客服助手。早期他们只接了一家商用大模型 API，结果遇到几次供应商侧限流和区域性抖动，下游十几个业务系统集体变慢，工单爆了。客户痛定思痛，决定"不把鸡蛋放一个篮子里"：同时接入多家大模型供应商，包括开源自托管集群（我们基于自研 AI 私有化部署底座搭的 vLLM 推理集群）和两到三家商用 API。

但多供应商直接暴露给业务方是不现实的——每个后端协议细节、鉴权方式、模型名、错误码都不一样，业务系统改造成本高，且一旦某家出问题，业务方自己写切换逻辑既不专业也不可控。于是我们引入自研的 AI 网关作为统一入口：业务系统只调网关一个地址，供应商的差异、路由、降级、限流全部由网关屏蔽。这也是把网关的"统一接入、智能路由、限流熔断、计量配额"核心能力真正用在了生产流量上。

二、落地场景

业务系统调用链被收敛成一条：应用 → AI 网关（统一 OpenAI 风格 REST 接口）→ 多模型后端。网关内部分层运作：接入层做协议归一与鉴权；路由层按"模型能力画像 + 实时成本 + 延迟 + 配额"把请求分到最合适的后端；编排层处理多模型串联/回退；计量层对每次调用的 token、耗时、费用统一记账；管控台配置路由策略与限流熔断；可观测层盯调用链与延迟分布。

典型的运行画面是：简单 FAQ 类请求被路由到低成本小模型（自托管集群里的轻量实例），复杂推理类请求才上大模型（商用 API 或自托管的大参数量实例）。某天下午，一家商用 API 突然把错误率顶到阈值以上，网关在秒级内把该供应商的流量切到备用后端，并给仍然命中的少量超时请求返回兜底话术，下游业务系统几乎没有感知。事后看监控，这次故障期间整体请求成功率仍保持在高位。

三、关键技术挑战与解决思路

① 协议归一，屏蔽后端差异。 各家后端接口长得都不一样：有的走私有 JSON，有的贴近 OpenAI 风格但字段命名有出入，鉴权一个是 Bearer 一个是签名头。我们在接入层做了一套协议适配层，对外统一暴露 OpenAI 风格的 /v1/chat/completions，对内按后端类型做请求转换与响应回填，错误码也归一成网关内部码。业务方从此只认一套接口，后端换供应商、换版本都不用动业务代码。

② 路由策略，按成本画像分发。 我们在路由层维护一张"模型能力画像表"：每类后端标注擅长任务（简单问答/长文生成/代码/复杂推理）、单 token 成本、典型延迟、当前配额水位。路由不是简单轮询，而是"小模型承接简单问答、大模型承接复杂推理"，并叠加成本约束——在能力满足的前提下优先走低成本的可用后端。画像表可热更新，新供应商接入只改配置。

③ 降级与熔断，超时/错误率触发切流。 这是稳定性的核心。我们对每个后端配置了超时阈值与错误率滑动窗口：连续 N 次超时或错误率超过阈值，熔断器打开，该后端被暂时摘流，请求按编排层的回退策略转给备用后端；若全部后端不可用，返回网关托底的标准化降级响应（而非裸超时抛错给业务）。熔断半开探测机制会在一段时间后放少量流量探活，恢复后自动回流。

④ 限流，令牌桶按租户/接口 QPS。 网关在接入层之后做限流，采用令牌桶算法，维度是"租户 + 接口 + 模型"。不同业务系统配额不同，防止某一个系统把整池算力打满拖垮其他人。更重要的是，网关的限流信号反向驱动底座的弹性扩缩容——当自托管集群侧的排队与限流命中率上升，调度层自动拉起更多推理实例，形成"算力—流量联动闭环"，而不是各自为政。

⑤ 灰度，路由权重做模型版本灰度。 新模型版本上线不能一把梭。我们在路由策略里支持权重配置，比如新版本先承接 5% 流量，观察延迟、错误率与人工抽检满意度，逐步提到 20%、50%，最后全量；期间任何指标恶化都可一键把权重调回旧版本。这与底座侧的模型版本管理天然对齐。

四、效果数据

脱敏示意，内部一致口径：

• 供应商故障期间请求成功率：模拟某商用 API 完全不可用的故障演练中，网关自动切流后整体请求成功率保持在约 99.2%（少量复杂请求进入兜底）。
• 降级切换耗时：从熔断器探测到完成切流，约 1.5–3 s 内生效，下游业务系统未出现大面积超时堆积。
• 成本下降比例：通过"小模型承接简单请求 + 自托管承接稳定基线流量"的路由分层，月度大模型调用总成本相较"全量走商用 API"下降约 35%–45%。
• P99 延迟：在路由分层与限流保护下，网关侧 P99 端到端延迟从改造前的约 4.8 s 降至约 2.1 s（含后端推理，不含极端降级场景）。
• 限流保护成效：上线后未发生单租户打满导致的全局雪崩，自托管集群通过联动扩缩容把排队延迟稳定在可控区间。

案例片段（已脱敏）：路由策略配置片段（YAML，已脱敏）yaml routes:  - name: simple-qa    match: { intent: faq, max_tokens: 512 }    backends: [selfhost-small-7b]      # 低成本小模型优先    cost_weight: 0.9  - name: complex-reason    match: { intent: reasoning }    backends: [vendor-pro-x, selfhost-large-34b]    fallback: vendor-pro-x             # 主备顺序 circuit_breaker:  errors_threshold: 0.5                # 错误率超 50% 摘流  window: 30s  half_open_probe: 5%

案例片段（已脱敏）：降级切换日志片段（已脱敏）14:02:11 [route] backend=vendor-pro-x err_rate=0.61 window=30s -> BREAK_OPEN 14:02:11 [fallback] reroute 218 reqs -> selfhost-large-34b 14:02:14 [fallback] reroute 6 reqs -> gateway_degrade_reply (all-backends-busy) 14:02:41 [probe] vendor-pro-x half_open probe ok, recover 5% traffic 14:03:02 [route] vendor-pro-x fully recovered, traffic restored

五、可复用经验总结

1. 网关先做路由，再做计量。 路由决定了请求去哪、成本花在哪，是稳定性和成本的总闸门；计量是事后看清账目的手段，但不能反过来决定架构优先级。先让流量分得对，再谈算得清。
2. 降级要有兜底，而非裸超时。 后端挂了不能把超时报错直接甩给业务，网关必须有一层标准化降级响应（兜底话术/缓存结果/简化答案）。用户感知到的"还能用"比"报错快"重要得多。
3. 限流是防护，也是调度信号。 限流不只是拦流量，它的命中数据应反向驱动底座扩缩容，让算力跟着流量走，而不是算力与流量各算各的。
4. 多供应商的价值是冗余，不是廉价。 接入多家不是为了一味压价，而是为了任何一家抖动能秒级切走。路由分层顺带降本，但稳定性才是第一目标。
5. 灰度用权重，而非开关。 模型/路由策略上线用百分比权重灰度，配合熔断与监控，出事能秒回退，比"全量切换 + 事后救火"稳得多。

结语：AI 网关在一个多供应商、多业务系统的大模型平台里，扮演的是"交通指挥 + 保险丝 + 记账员"的复合角色。把接入、路由、降级、限流、计量这五件事做扎实，业务系统才能真正把大模型当成"随时可用、掉了有人顶"的基础设施，而不是天天提心吊胆的脆弱依赖。