大模型 API 供应商切换：从被动应对到主动架构设计

## 一个行业信号

最近一家头部科技公司因为供应商策略调整，需要在 7 天内完成全集团从某个海外大模型到国产模型的紧急切换。20 多万员工，从代码开发到长文本分析再到多模态 Agent，全部迁移。

这不仅是某一个企业的个案。从去年至今，多家海外大模型供应商相继收紧了对中国企业的服务政策。对于没有自研大模型兜底的技术团队来说，收到一封封号邮件之后再开始找替代方案，代价远不止改几行 API 地址。

> 持有 5 个供应商的 Key 和「随时能切走」是两回事。切换成本不在注册环节，在集成深度。

---

## 切换成本拆解：为什么两周算顺利的

大多数技术团队调模型的方式是：代码里硬编码 `api.openai.com` 或 `api.anthropic.com`，Key 从环境变量读取，请求直发供应商服务器。

这套架构的切换成本集中在三个层面：

**Prompt 适配层**。不同模型对同一段提示词的输出结构、语气、粒度差异显著。为当前模型调试数十轮的 Prompt 模板，在新模型上需要重新验证。这不是自动评测工具跑一遍就能过的。

**参数兼容层**。各家厂商有独有参数——Anthropic 的 `thinking` 字段、特定的 stop sequence 格式。这些参数硬编码在业务逻辑里，切模型意味着改代码。

**监控对接层**。告警规则、token 统计、返回头解析，这些基础设施按特定供应商格式搭建，切换后整套监控体系需要重新适配。

测试、上线、验证全套走下来，两周算顺利的。而供应商的通知不会提前两周发给你。

---

## 架构反思：你的代码到底应该认识谁

问题的本质是：业务代码和模型供应商之间是**硬连接**。解耦的方式，是在中间加一个路由层。

核心设计：用「逻辑模型」替代「物理模型」，让业务代码不关心请求最终发给谁。

```python

# 之前：业务代码直连供应商

client = openai.OpenAI(api_key=os.environ["OPENAI_KEY"])

response = client.chat.completions.create(model="gpt-5", messages=[...])

# 之后：通过路由层调用

response = router.call(

logical_model="code_generation",

messages=[...]

)

```

路由层维护一张逻辑模型到物理模型的映射表：

| 逻辑模型 | 当前供应商 | 备用供应商 |

|---------|-----------|-----------|

| code_generation | claude-sonnet-4 | deepseek-coder |

| long_context | claude-opus | qwen-max |

| general_chat | gpt-5 | deepseek-v3 |

当供应商不可用，管理员在控制面改一条映射，业务侧完全无感知。

---

## 从「选对供应商」到「不绑定供应商」

技术选型的惯性思维是选一个最好的供应商——看 benchmark、比价格、测延迟。但面对供应商政策的不确定性，「最好」不如「可替换」。

实践中可以从四个方面落地：

1. **统一调用入口**：业务代码不直接依赖任何供应商 SDK，所有模型调用通过统一接口

2. **逻辑模型抽象**：用业务语义（代码生成、长文本分析、推理）替代物理模型名

3. **路由可配置**：映射关系外部化，支持运行时切换，无需重启服务

4. **凭证集中管理**：API Key 统一管理、轮换、审计，不散落在各业务环境变量里

这种架构在日常运行时几乎不增加额外开销，但在供应商断供那天，它的价值是几周的开发和测试时间。

---

小结

供应商可靠性不是选型 checklist 里的加分项，而是需要架构层面考虑的容错设计。不是让你今天就把当前模型换掉，是让你下次写调用代码的时候，在中间留一层。

留了这一层，切换是改配置的事。没留，切换是改代码的事。而时间窗口，没人会提前通知你。","createTime":1783396768,"ext":{"closeTextLink":0,"comment_ban":0,"description":"","focusRead":0},"favNum":0,"html":"","isOriginal":0,"likeNum":0,