#模型网关与模型路由

#1. 提出问题

一个内容运营平台上线了多个 AI 功能：标题改写、商品卖点生成、客服回复草稿、合同条款摘要、图片理解和数据分析问答。早期每个功能直接调用一个模型，功能负责自己的 API Key、参数、重试和日志。

半年后问题集中出现：标题改写调用量大，成本失控；合同摘要需要更强模型，延迟却影响审核流程；客服回复偶发超时，没有统一降级；数据分析功能因为模型升级改变了 JSON 格式；财务想知道每个业务线的模型成本，研发只能从散落日志里估算。

这时团队提出“做模型网关”。但网关不是银弹。它需要解决的是生产接入问题，而不是替业务团队决定什么答案是好答案。

网关和路由的核心问题是：当模型不再是单一依赖，而是多供应商、多模型、多任务、多质量等级的生产资源时，如何让接入、选择、降级、观测和成本治理变成统一能力。

#2. 分析问题

模型网关处理的不是单个 AI 任务，而是模型调用链路的工程治理。

网关适合统一处理横切问题：认证、供应商适配、超时、重试、限流、日志、脱敏、成本归因、模型版本、路由配置和降级策略。它不应该吞掉业务语义，也不应该让所有功能只传一个自由文本 prompt，然后期待网关猜出任务风险和质量要求。

收益来自四个方面：

• 可靠性：供应商异常时可以熔断、重试、降级或切换。
• 成本：按功能、租户、模型和调用类型归因，支持预算和配额。
• 质量：支持灰度、A/B、回放和模型升级评估。
• 治理：统一 API Key、日志脱敏、审计和合规策略。

风险也很明显：

• 路由规则过度复杂，业务团队难以理解为什么选了某个模型。
• 网关只做转发，缺少任务标签和评估，无法真的优化质量。
• 降级只看可用性，不看业务后果，把高风险任务降到不合适模型。
• 统一网关成为单点瓶颈，影响所有 AI 功能。
• 日志记录过细，带来隐私和合规风险。

所以，网关的设计前提是业务侧能给出任务类型、质量要求、风险等级和可接受降级范围。

#3. 列举方案

模型接入可以按复杂度逐级升级。

第一层是业务直连单模型。适合原型验证、调用量低、只有一个功能的阶段。它最快，但后续换模型、做观测和成本归因都困难。

第二层是轻量模型客户端。把 API Key、请求格式、错误处理和重试封装成 SDK 或 service。适合单团队、多功能但模型数量少的阶段。

第三层是统一模型访问层。业务侧传入任务类型、模型偏好、预算和超时，访问层统一处理供应商差异、日志和错误码。很多中小团队到这一层已经足够。

第四层是模型网关。网关作为独立服务接收模型请求，统一认证、限流、路由、观测、脱敏和成本归因。适合多团队、多模型、多供应商和高调用量场景。

第五层是规则路由。根据任务类型、租户等级、风险等级、输入长度、模态、语言和预算选择模型。例如“合同摘要必须使用高质量模型”，“标题改写优先低成本模型”，“图片理解走多模态模型”。

第六层是质量 / 成本感知路由。结合历史评估、线上反馈、延迟、价格和供应商健康状态动态选择模型。这里要谨慎，不能只优化成本而忽略业务质量。

第七层是灰度、回放和评估。模型升级前，用真实样本回放比较质量、结构化稳定性、延迟和成本；上线后灰度监控关键指标。

第八层是 Ops 治理。包括预算、配额、告警、审计、密钥轮换、日志脱敏、区域合规、模型版本生命周期和事故复盘。

简单客户端足够的条件是：模型少、功能少、成本可接受、没有跨团队治理需求。prompt 不再足够、直连不再足够的信号是：多个功能重复写接入逻辑、供应商异常影响范围大、成本无法归因、模型升级不可控、需要统一审计或合规。

#4. 决策判断

设计模型网关时，最重要的不是“支持多少供应商”，而是请求契约是否表达了业务意图。一个好的网关请求不应该只有 prompt，还应该包含任务类型、输入规模、风险等级、期望输出格式、超时预算、租户或业务线、是否允许降级等信息。

路由策略通常从确定性规则开始，而不是一开始就做复杂动态路由。可解释的规则更容易上线和复盘：先按任务类型、风险等级和模态选择模型，再根据供应商健康状态和预算做降级。

降级必须有边界。标题改写超时可以降到便宜模型或返回模板；合同摘要、医疗建议、财务解释这类高风险任务不应该自动降到未评估模型，宁可转人工或提示稍后重试。

常见反模式：

• 业务只传 prompt，网关被迫猜任务类型和风险等级。
• 路由只按价格排序，忽略结构化输出稳定性、幻觉率和人工返工成本。
• 把网关当质量保证层，却没有评估集、样本回放和业务反馈。
• 所有错误都重试，导致延迟放大和成本翻倍。
• 日志完整保存用户输入和模型输出，没有脱敏、保留周期和访问控制。
• 模型升级直接全量切换，没有灰度、回放和回滚。

#5. 结论收束

模型网关适合解决生产接入和治理问题：统一模型调用、路由、降级、成本、日志和合规。它不能替代业务侧的场景定义，也不能在没有评估的情况下证明某个模型更好。

最低可上线版本可以是一个统一模型访问层：封装供应商、错误码、超时、重试、日志和成本标签。当调用量、团队数量、供应商数量或合规要求上升，再演进成独立网关和路由系统。

上线前检查项：

• 场景边界：哪些业务功能接入网关，是否有任务类型和风险等级。
• 请求契约：是否包含任务类型、输出格式、超时、预算、租户和降级策略。
• 模型配置：模型名、版本、参数、上下文限制、价格和能力是否可配置。
• 路由规则：是否按任务、风险、模态、输入长度和成本做可解释选择。
• 降级策略：哪些任务允许降级，哪些必须失败、转人工或排队。
• 重试限流：是否有超时、重试上限、退避、熔断和配额。
• 成本归因：是否按业务线、租户、功能、模型和请求类型统计。
• 质量评估：是否有样本集、回放、A/B、灰度和业务反馈。
• 日志合规：是否做脱敏、访问控制、保留周期和审计。
• 运维恢复：供应商异常、模型升级失败、网关故障时是否可回滚。