一、核心能力与技术指标 (Key Capabilities)
| 评测指标 | 交付标准 |
|---|---|
| 协议兼容 | OpenAI Chat Completions 规范为基线，兼容主流供应商 |
| 支持模型数 | 50+ 主流模型，持续跟进新版本 |
| 网关附加延迟 | 单次转发 P95 < 200ms |
| 服务可用性 | 99.9% |
| 故障自动切换 | 连续失败 3 次或错误率 > 5% 触发降级 |
| 计量粒度 | 按业务线 / 模型 / 任务类型三维拆账 |
二、与传统直连方式的对比矩阵 (Architecture Comparison)
| 维度 | 业务直连多家供应商 | 统一中转站 |
|---|---|---|
| 接入成本 | 每接一家改一次业务代码 | 业务侧只对接一套接口 |
| 密钥管理 | Key 散落在各业务线 | 密钥集中于网关，不下发业务侧 |
| 降级策略 | 各业务线自行实现，策略不一致 | 网关统一配置，全局生效 |
| 成本归集 | 只能看供应商总账单 | 可按业务线与任务拆分 |
| 版本变更 | 供应商下线版本即线上事故 | 网关层改配置，业务无感 |
| 模型替换 | 需重新开发与回归测试 | 按能力标签切换路由 |
三、路由与降级规范 (Routing & Fallback)
网关路由采用「能力标签」而非固定模型名。业务侧只声明需求特征，例如：上下文长度 ≥ 32K、支持函数调用、支持流式输出、中文能力优先。网关依据标签匹配候选模型池，并按成本优先级排序。
降级链路需满足三个条件才算合格：
- 同能力可替代：备用模型必须满足原请求的能力标签，否则降级即降质。
- 状态可知：熔断状态、当前路由目标、降级次数需可实时观测。
- 可回路：主供应商恢复后按退避策略逐步回切，避免流量瞬时回灌造成二次故障。
四、计量与成本归集 (Metering & Cost Allocation)
成本失控通常不是单价问题，而是归集问题。网关需记录每次调用的以下字段：业务标识、模型标识、输入 token 数、输出 token 数、缓存命中情况、响应时长、所属任务类型。
基于这些字段可回答三个关键问题：哪条业务线在烧钱、哪类任务对模型能力要求被高估、哪个环节存在重复调用。实践中，仅通过任务分类路由（把长文本摘要类请求从高配模型迁至经济型模型），即可在不影响效果的前提下将推理成本下降 40% - 70%。
五、部署形态与选型建议 (Deployment Options)
| 部署形态 | 适用场景 | 数据流向 |
|---|---|---|
| 公有云托管网关 | 中小团队、快速上线 | 请求经第三方网关转发 |
| 企业私有化部署 | 数据敏感、需内网审计 | 请求在企业内网完成路由 |
| 混合模式 | 通用请求走托管，敏感业务走私有 | 按业务分级路由 |
选型判断标准只有一条：若明天主力供应商涨价 50%，能否在一小时内完成流量迁移。能做到则架构健康，做不到则所谓多模型只是名义保险。
六、常见实施误区 (Common Pitfalls)
| 误区 | 后果 |
|---|---|
| 只做协议转换，不做能力标签 | 换模型时效果漂移，需人工逐个回归 |
| 密钥直接下发到业务侧 | 泄露风险高，且无法统一吊销 |
| 用调用次数而非 token 计量 | 长文本任务成本被严重低估 |
| 硬编码模型版本号 | 供应商下线版本时触发线上故障 |
| 网关自身无监控 | 故障时无法区分是供应商问题还是网关问题 |