多模型 API 聚合平台架构：路由、容灾与治理

为什么需要多模型聚合层

不同 AI 供应商在鉴权方式、请求字段、流式协议、错误码、限流策略和账单单位上存在差异。应用如果直接绑定多个上游，会把供应商差异扩散到每个业务模块。聚合层通过统一的 API 契约隔离变化，使业务代码只关心模型能力和输出。

层级	职责
统一网关	认证、限流、请求校验、版本管理和 OpenAI 兼容协议。
模型目录	维护公共模型 ID、提供商、上下文长度、模态、状态和价格。
路由引擎	将公共模型映射到上游模型，按优先级、健康度和成本选择线路。
适配器	处理供应商字段映射、流式事件转换、图片任务和视频异步任务。
计量计费	记录输入输出 Token、请求次数、生成秒数及价格快照。

路由不能只按静态优先级工作。生产系统应持续记录成功率、首字节延迟、完整响应时间、限流比例和供应商错误率。当主线路在滚动窗口内超过阈值时，系统进入熔断状态，将新请求切换到兼容的备用线路；恢复前使用少量探测流量验证健康度。

故障转移必须保持语义一致。备用模型应支持相同模态、足够的上下文长度和所需工具能力。对于生成类请求，自动重试还要考虑幂等性，避免重复生成或重复扣费。

API Key 应绑定用户、权限范围、允许模型、速率上限和预算。服务端保存 Key 摘要而不是明文，日志中对 Authorization、提示词中的敏感字段和上游密钥进行脱敏。管理员修改模型价格或路由时，应生成配置版本和审计记录，以便追踪线上行为变化。

模型价格应在请求开始时生成价格快照。否则价格更新可能导致同一请求的预估费用与最终费用不一致。

至少需要按用户、模型、上游和状态码聚合请求量、Token、成本、延迟和错误。对于流式接口，还应区分首 Token 延迟和总耗时。容量规划不能只看平均值，应观察峰值并发、长上下文请求、视频任务队列长度和供应商限流窗口。