为什么直连三方模型 API 在企业中不可行?
直连方式存在几个严重缺陷:各个项目组重复申请 Key 导致费用失控、单一供应商宕机时缺乏无缝容灾能力、员工误操作可能将高价值内部源码直接发送给公共模型。
AI Gateway 的五大核心能力组件
- 智能多模型路由与熔断:当主力模型(如 Claude 3.5 Sonnet)出现 5xx 错误或限流时,网关在 100ms 内自动平滑重试降级至 DeepSeek-V3 或 GPT-4o;
- 统一 MCP 权限代理:所有针对企业内部数据库或生产集群的 MCP 请求必须经过网关的 RBAC 鉴权与审计日志打标;
- 租户配额与 Token 实时记账:按部门、项目与员工维度统计 Token 消耗并实施软硬配额告警;
- 企业合规与敏感词防火墙:在双向数据流中实时过滤内部 IP、密钥与涉密商业机密。
落地示例:分三阶段收敛直连调用
第一阶段是盘点。把散落在各仓库的模型端点与工具端点列成清单,标注调用方、月度 Token 量级、是否携带内部数据。仅这一步就能暴露重复申请 Key 的问题。
第二阶段是旁路接入。网关先以透明代理模式部署,只做转发、日志与计量,不改任何业务代码,观察一到两周,确认审计字段完整后再启用配额与路由策略。
第三阶段才真正切流。按团队灰度,客户端只需把 Base URL 指向网关,模型名与请求参数保持不变。路由与策略建议写成配置纳入版本管理:
# 示意结构,实际字段名以所选网关产品的规范为准
listeners:
- path: /v1/chat/completions
upstreams:
- name: primary # 主力模型
weight: 80
- name: fallback # 兜底模型
weight: 20
policies:
- token-quota # 按租户记账
- outbound-redaction # 出站脱敏
集中式网关与直连的取舍对比
| 决策点 | 集中式网关 | SDK 直连加本地重试 |
|---|---|---|
| 密钥管理 | 单点托管,轮换成本低 | 分散在各仓库,泄漏面大 |
| 故障切换 | 统一降级策略,秒级生效 | 每个团队各自实现 |
| 成本可见性 | 天然聚合到部门维度 | 需额外埋点统计 |
| 请求延迟 | 多一跳转发 | 无额外开销 |
| 运维投入 | 需要平台团队长期维护 | 几乎为零 |
通常的判据是:调用方超过三个团队,或者存在生产数据出站风险时,治理收益会盖过那一跳延迟;只有一个实验脚本时,直连更划算。
上线前必须做的四项验证
注入上游 5xx 与超时,确认降级链路真的生效而不是只写在配置里;用超长上下文触发配额,确认返回的是明确限流错误而非静默截断;从审计日志反查一次调用的入站出站内容是否已被脱敏;月底把网关统计量与供应商账单对账,偏差要能逐项解释。四项全过才适合继续扩大接入范围。
常见故障速查
| 现象 | 原因 | 处理 |
|---|---|---|
| 降级后回答风格漂移 | 兜底模型未复用同一套提示模板 | 在网关侧统一注入并做回归比对 |
| MCP 调用被随机拒绝 | 工具名单与角色权限不同步 | 以注册表为唯一事实源刷新策略 |
| 配额告警明显滞后 | 记账走异步批量落库 | 改为同步计数或缩短聚合周期 |
| 流式输出中途断连 | 网关空闲超时短于任务时长 | 调大读超时并保留心跳帧 |
| 网关统计与账单不符 | 未计入重试与工具回传 Token | 把重试次数与工具结果一并记账 |
小结
判断网关是否真的落地,不看有没有部署,而看三个可验证的问题:任一模型供应商今天故障,业务能否不发版继续运行;任意一次工具调用能否在审计里追到具体的人和用途;月底账单能否拆到部门粒度。三问都为"是",架构才算成立。想先摸清团队在用什么模型与工具,可以从 /mcp 与 /blog 目录开始整理清单,再决定网关要拦什么。