为什么用网关而不是直连各家 API
企业内往往同时存在：业务系统里的 Chat 调用、RAG 流水线、Copilot 插件、批处理任务。若每个团队各自申请厂商 Key，会出现：
- 密钥分散、轮换困难
- 无法按部门 / 项目核算费用
- 模型下线或限流时缺乏统一降级
OpenAI 兼容网关的价值，是把「协议层」稳定下来：base_url 与 /v1/chat/completions 不变，上游可切换多家模型或本地推理服务，应用代码无需分叉。
接入拓扑
Client (SDK / LangChain / 自研)
| Authorization: Bearer <portal_key>
v
Platform 模型网关
| 路由 / 限流 / 日志
+-> 商用 API（按模型名路由）
+-> 本地推理（可选）
推荐做法：
- 在门户为应用或环境创建独立 Key，绑定用户分组与额度，避免个人 Key 共用。
- 客户端仅配置网关
base_url，不要硬编码厂商域名。 - 在运营中台开启模型调用日志，按 Key、模型、时间维度聚合 token 与费用。
路由策略设计
| 策略 | 适用场景 | 注意点 |
|---|---|---|
| 按模型名静态路由 | 场景固定、延迟敏感 | 需监控上游可用性 |
| 按标签 / 分组路由 | 多租户、多部门 | 分组与 IAM 对齐 |
| 降级链 | 核心流程不能中断 | 定义可接受的质量下限 |
| 批处理走低价模型 | 摘要、分类、抽取 | 与交互式对话分 Key |
避免「默认全走旗舰模型」：交互式问答与离线批处理应使用不同路由与配额。
观测与排错
生产环境建议至少采集：
- 请求 ID、Key ID、模型、首 token 延迟、总耗时
- 输入 / 输出 token（不含原文时可记录 hash 或长度）
- 上游 HTTP 状态与错误码
常见问题对照：
| 现象 | 可能原因 | 处理方向 |
|---|---|---|
| 401 | Key 失效或分组未授权该模型 | 检查分组策略与模型白名单 |
| 429 | TPM / RPM 触顶 | 调整限流、拆分 Key 或走队列 |
| 空响应或截断 | 上游超时、上下文超长 | 检查 max_tokens 与路由目标健康 |
| 费用突增 | 循环调用或批任务未限流 | 按 Key 设日预算与告警 |
安全基线
- Key 不得写入前端或移动客户端；仅服务端持有。
- 日志中禁止输出完整 prompt / completion（合规场景可只存元数据）。
- 定期轮换 Key，离职与项目结项时回收分组权限。
延伸阅读
网关侧接口语义与示例见官网 模型接入文档。Arena 能力榜单可作为选型参考，但生产路由仍应结合自家评测集与成本模型做验证。
本文描述的是平台侧通用实践；具体配额、计费与本地模型对接方式以贵司合同与部署版本为准。
