模型迁移类比数据库迁移：如何在不破坏生产环境的情况下安全切换 LLM 供应商

当你的团队决定从 Claude 3.5 Sonnet 升级到 Claude 3.7，或者从 OpenAI 迁移到自托管的 Llama 部署时，直觉通常是将其视为一次库升级：更改 API 密钥，更新模型名称字符串，进行快速的健全性检查，然后发布。这种直觉是错误的，那些遵循这一做法的团队会在第二周的凌晨 2 点发现原因——当时客服代理开始以完全不同的格式生成响应：技术上有效，语义上却是灾难性的。

切换 LLM 提供商或模型版本在结构上与数据库模式迁移（database schema migration）完全相同。两者都涉及更改系统中应用其余部分具有隐式契约的行为。两者可能在第一天看起来没问题，但在第十天发生灾难性的失败。两者都需要双重运行（dual-running）、金丝雀发布（canary deployment）、回滚标准和迁移方案（migration playbook）——而不是修改配置后发一条 Slack 消息。

为什么“直接更换 API 密钥”会在第二周失败

简单模型更换在第一周引发的失败通常显而易见。提示词格式不兼容会立即显现：Claude 要求显式的 max_tokens 参数和独立的 system 字段；OpenAI 以不同的方式嵌入配置；Gemini 的 API 则以另一种方式构建内容。工具/函数调用（Tool/function calling）架构各异——OpenAI 使用 parameters 键，Anthropic 使用 input_schema——任何依赖结构化工具调用的工作流都会出现明显的崩溃。

但第二周的失败才是职业生涯的终结者。它们包括：

隐性输出漂移（Silent output drift）。 新模型生成的响应通过了语法验证，符合预期的 JSON 模式，且乍看之下很合理——但语调会发生微妙变化，边缘输入的拒绝率增加，或者改变了结构化输出字段中的值分布。你的评估（evals）显示准确率为 94%。但你的用户体验到的却是另一回事。

分词（Tokenization）惊喜。 不同的模型分词方式不同。对于相同的英文文本，Claude 产生的 token 可能比 GPT-4 多 5–15%，对于某些内容模式甚至多出 2–3 倍。如果你的成本预测、速率限制预算和上下文窗口计算是基于旧模型的分词器校准的，那么每个假设都会同时破裂。计算 token 的 bug 特别致命，因为它们会同时影响成本和正确性。

重试逻辑不匹配。 提供商实现速率限制的方式各不相同。指数退避（exponential backoff）参数、特定的错误代码、发出限流信号的标头格式——所有这些都是特定于提供商的。针对 OpenAI 响应封包优化的重试逻辑会错误处理 Anthropic 的错误代码，导致请求被静默丢弃或引发不必要的 429 风暴。

提供商端更新导致的行为漂移。 即使你没有更改任何内容，API 端点下的模型也可能发生变化。提供商会更新模型权重和解码参数，而不宣布破坏性变更。2025 年 OpenAI GPT-4o 的奉承倾向（sycophancy）事件是一个典型的公开案例：权重更新改变了生产环境中的模型行为，而这种改变随着时间的推移才变得可见。研究表明，91% 的生产环境 LLM 在部署后的 90 天内会经历可衡量的行为漂移，从性能下降开始到收到第一个用户投诉平均有 14–18 天的延迟。

迁移方案：像对待数据库模式变更一样对待它

数据库迁移的比喻是精确的，而非隐喻。当你迁移数据库模式时，你不会立即切换生产流量——你会并行运行旧架构和新架构，验证新架构是否生成等效数据，使用功能标志（feature flags）路由特定用户群，并维护回滚程序。LLM 迁移需要同样的纪律。

第一阶段：影子模式（100% 流量，零用户影响）

在任何用户看到新模型之前，将 100% 的生产流量同时路由到两个模型。当前模型为用户提供服务；新模型在后台异步接收相同的输入。

捕获带有元数据的两种响应：延迟、token 数量、时间戳，以及任何指示质量的下游信号（任务完成情况、用户满意度事件、下游系统行为）。运行一到两周——时间要长到足以覆盖你的全部输入分布，包括每周只出现几次的长尾异常查询，而这些正是模型出现分歧的边缘案例。

成本是真实的：在这一阶段，影子流量大约会使你的 LLM 支出翻倍。为此做好预算。另一种选择是从用户投诉中发现生产环境中的行为差异，那样的代价更高。

使用 LLM-as-Judge（以模型为评判者）的方法大规模比较影子输出与生产输出。即使是中等流量，人工审查也是不可行的。建立一个比较流水线，标记出两个模型在相同输入上产生语义差异答案的情况——这些就是需要人工审查的候选案例。

第 2 阶段：金丝雀部署 (5% → 25% → 50% → 100%)

在阴影模式（Shadow Mode）验证后，分阶段将新模型引入真实用户流量。

从 5% 的流量开始，通过特性标志（Feature Flag）或在 API 网关处进行路由。在每次增加比例前，至少监测 4-6 小时。在每个阶段需要关注的指标包括：

• 延迟：p50、p95 和 p99。模型在尾部延迟方面存在显著差异，而 p99 的退化通常只在真实的并发模式下才会显现。
• Token 使用量：你消耗的 Token 是否比预测多出 20%？如果是，说明你的成本模型有误，在继续之前你需要弄清楚原因。
• 错误率：结构化输出 Schema 验证失败、工具调用（Tool Call）错误、响应格式错误。
• 语义质量：抽取 2-5% 的响应，使用你在第 1 阶段建立的 LLM-as-Judge 方案进行自动质量评分。
• 业务指标：下游转化事件、任务完成信号、支持工单量。这些指标会有数小时或数天的滞后，但它们才是衡量效果的最终事实。

仅当所有指标都在可接受范围内时，才进入下一个增量阶段。增量时间表可以根据你观察到的情况压缩或扩展——如果在 5% 的流量下运行 6 小时一切正常，推进到 25% 是合理的。如果 p99 延迟比基准高出 40%，你应该停止并调查原因，然后再继续。

在开始前建立回滚触发条件

回滚标准必须在迁移开始前定义，而不是在出现问题之后。在事件发生那一刻再来定义会导致“动机性推理”——团队往往不愿回滚，因为这感觉像是承认失败。

需要立即回滚的阈值：

• 错误率超过请求总数的 5%（基准值 <1%）
• p99 延迟增加超过 200ms
• 语义质量评分下降超过 5 个百分点
• 工具调用准确率下降超过 10%
• 单次请求成本比预测增加超过 20%

需要暂停发布并调查后再继续的阈值：

• 任何指标向错误方向变动，即使尚未达到回滚阈值
• 面向用户的支持工单增加超过 15%
• 针对特定输入类型，拒绝率（Refusal Rate）的变化超过 5%（无论增加还是减少）

将这些指标编码为自动报警。如果需要人工发现指标并手动评估是否构成问题，你的回滚速度将慢 4-6 小时。

工具调用问题：Agent 工作流中 Schema 差异的叠加效应

对于运行 Agent 系统的团队来说，不同供应商之间工具/函数调用（Tool/Function Calling）Schema 的差异是迁移中风险最高的环节。

OpenAI 使用 type: "function" 包装器和 parameters 对象来构造函数调用。Anthropic 使用更扁平的结构，直接用 input_schema 指定参数定义。Mistral 完全效仿了 OpenAI 的格式。Gemini 则使用了另一种 Schema。这些差异并非表面文章——它们需要不同的代码路径、不同的验证逻辑和不同的错误处理。

更糟的是，一些看起来像模型错误的边界情况实际上是 Schema 交互漏洞。在启用扩展思考（Extended Thinking）时，将 Claude 的 tool_choice 设置为 "any" 会返回 API 错误——这种行为在 OpenAI 的 API 中没有对应项，且只会在触发它的特定功能组合下才会在生产环境中显现。

对于重度依赖 Agent 的系统，最安全的方法是实现一个供应商抽象层，在边界处对工具 Schema 进行归一化，而不是在整个代码库中直接使用特定供应商的 SDK 调用。这虽然增加了前期复杂性，但会显著降低未来迁移的成本。

构建捕捉行为偏移的回归测试套件

标准的准确度基准测试不足以验证迁移。模型在你的评估集上可能得分相同，但在生产环境输入的实际分布中却表现出明显不同的行为。

构建一个涵盖以下内容的回归套件：

格式稳定性：对于系统依赖的每个结构化输出 Schema，测试新模型是否产生相同的结构——包括可选字段、null 处理，以及像空数组与缺失数组这样的边界情况。

行为不变性：识别那些当前模型以特定方式表现的输入，你的应用程序可能依赖这种方式——在抽象意义上这未必“正确”，但与下游系统的构建方式一致。迁移最常在这些不变性上出现故障。

拒绝覆盖范围：测试当前模型拒绝边界附近的代表性输入样本。不同模型在划定这些界限时存在显著差异，如果迁移导致某类输入的拒绝率增加或减少，可能会破坏用户流程，且看起来像是模型错误而非迁移回归。

已知失败模式：当前模型发生过的任何生产事故——格式不匹配、字段幻觉、多轮对话的一致性失败——都应成为回归测试案例。新模型通常有不同的失败模式，但你要确保它们不会继承旧模型的已知问题。

在 CI 中针对当前模型和候选模型运行此套件。除非回归套件在所有不变性上显示出一致的行为，否则迁移不应进入阴影模式。

数据库迁移比喻对所有权的启示

在运作良好的工程组织中，数据库迁移由特定团队负责，在进入生产环境前需经过评审，并以分段环境（staging）的成功运行作为门槛，同时还要有记录在案的回滚程序。同样的纪律也需要应用到 LLM 迁移中。

所有权问题至关重要：谁来批准模型迁移？谁来验证回归测试套件（regression suite）？谁来监控金丝雀指标（canary metrics）？谁有权启动回滚？

在大多数团队中，这些问题都没有答案，因为 LLM 迁移仍被视为配置更改，而非工程变更。其失效模式是可预见的：迁移往往是投机性的，监控是临时性的，而回滚决策——如果真的发生了——也会因所有权不明而延迟。

将流程规范化。模型迁移应当需要一份迁移文档（等同于数据库迁移文件），其中明确说明当前版本和目标版本、回滚程序、监控计划以及成功标准。在批准全量发布前，应审查影子模式（shadow mode）的结果和金丝雀指标。这不是官僚主义——这正是数据库变更早已要求的严谨性，将其一致地应用到一类具有同等风险的新型系统组件上。

两周原则

如果你的迁移计划不包含为期两周的迁移后观察期，那么它就没有完成。大多数由模型变更引起的生产事故不会在最初的 48 小时内显现。它们通常出现在以下情况：

• 出现了影子流量（shadow traffic）中未曾体现的异常输入类型
• 下游系统遇到了其设计时未曾考虑处理的输出变体
• 累积的行为漂移（behavioral drift）达到了使聚合指标发生显著变化的程度
• 仅每周或每两周出现一次的用户行为模式触发了边界情况（edge case）

在整个两周的观察期内，保持回滚能力的可用性并经过测试。能够回滚一个已经“完成”了十天的模型迁移，是让迁移风险从一开始就变得可接受的保险单。

切换 LLM 是披着配置更改外衣的真实工程风险。请以此标准对待它。