AI 网关如何统一管理模型调用？

AI Gateway（AI 网关）是应用与模型供应商或自建模型之间的统一治理层：对外提供一套接口，对内适配不同模型，并把认证、路由、限流、成本与观测等横切能力从业务代码中抽离出来。

传统 API 网关擅长认证、限流和路由，但面对多厂商协议差异、Token 计量与语义级安全检测时，还需要针对 AI 请求补齐模型适配和细粒度治理。 掘金热榜上的文章《为什么越来越多人用 AI Gateway？》也提出了这个问题。当调用范围扩展到多厂商、多业务线、多环境或多租户，SDK/API 变更、密钥保存、超时重试、费用统计与容灾逻辑会散落在各个服务，形成调用逻辑碎片化、成本难以归集和容灾能力缺失。

在统一接入模式下，客户端只依赖网关约定的请求与响应结构、模型别名和标准错误码。模型适配器在内部封装 OpenAI、Anthropic 或自建模型的 SDK/HTTP、参数格式、协议差异，以及同步或流式调用方式。切换底层模型或供应商时，业务通常只需调整模型别名或策略配置，不必重写调用、重试和流式处理代码。

网关内部可按请求路径分为 API 与认证层、路由与策略引擎、处理流水线与缓存队列、模型适配器、响应后处理、观测审计层和管理面板。API 层确认租户与权限；策略层输出目标模型、缓存及容灾决策；流水线负责校验、脱敏、Prompt 模板和后处理；适配器归一化上游协议；观测层记录日志、指标、追踪与成本。认证失败直接拒绝，上游异常先归一化，再由策略层决定重试、降级或终止。

客户端携带网关令牌和用户 ID 发起请求。网关生成或接收 request_id，完成鉴权并确定租户后，依次执行输入校验、脱敏或内容审查、Prompt 模板填充、缓存判断和模型路由；适配器随后以同步或流式方式调用上游。响应返回后，网关进行过滤与格式化，同时写入 Token、成本、日志和审计记录，最后把结果或标准错误返回客户端。用户 ID 可以作为业务上下文，但不能替代网关凭证，审计记录还应保存实际使用的模型与路由结果。

路由规则可以按任务、成本、延迟和质量选择模型，并支持多模型并行或串联。并行调用适合投票、融合，串联适合前后处理；超时、重试和降级模型则应配置明确的次数、预算与触发条件，避免故障期间重复计费或无限制降级。额外串联步骤会增加延迟，额外模型调用也会增加 Token 消耗，因此不能把所有策略默认开启。

上游 API Key 由网关集中保管，客户端只持有作用域受限的网关凭证；权限可以细分到模型、租户和业务用途，并隔离不同客户。完整密钥不得写入日志或返回响应，排查时只保留脱敏标识；密钥轮换与停用也通过统一管理入口执行。

限流不能只看请求数。一次长文档生成可能比一次简短问答消耗更多 Token，因此配额既要覆盖请求速率、输入输出 Token 和并发数，也要按模型、客户和租户切分。规则不应写死通用阈值，而应依据业务预算与实时用量配置；超限后可以拒绝、降级到低成本模型或触发预算告警。流式调用可先预留估算额度，结束后再按实际 Token 结算。

每次调用至少记录 request_id、tenant_id、客户或项目、实际模型、路由原因、输入与输出 Token、延迟、结果状态，以及重试和降级情况，再依据模型单价换算费用。这样既能汇总某个租户、应用或模型的消耗，也能解释费用为何上升；预算接近上限时触发告警，异常增量则可以先限流或停用对应策略。

定位请求变慢、变贵或失败时，应使用 request_id 贯穿网关日志、指标、分布式追踪和审计记录。指标至少覆盖延迟、失败率、Token 与费用，追踪则区分鉴权、排队、路由、上游调用和后处理耗时，同时记录最终选中的模型及路由原因。质量采样可以辅助判断响应效果是否下降，敏感输入必须按规则脱敏，并明确数据留存期限。

Prompt 管理、批量合并、语义缓存，以及 RAG、数据库和工具调用更适合作为处理流水线或插件逐步接入，不宜全部放进核心链路。网关核心应先保证认证、路由、调用、计量和审计能够独立运行。每增加一个串联步骤都会增加延迟，每增加一个并行模型都会增加调用量，因此需要先根据实际瓶颈决定哪些能力进入同步路径。

最小可用版本可按以下顺序落地：

1. 先统一接入和基础观测：上线统一 API、模型适配器、网关凭证与密钥隔离，同时记录请求、Token、延迟和失败信息，并打通日志与追踪。
2. 再开启治理和容灾：配置任务、成本、延迟与质量路由，随后加入超时、重试、降级、租户配额和预算告警。
3. 最后按实际瓶颈加入缓存、Prompt、RAG 或工具调用，并把网关自身新增延迟与水平扩展能力纳入验收；若在目标流量下达不到验收指标，就先不进入下一阶段。