模型下线、改名、涨价了怎么办？一套版本迁移的应对预案
大模型这个领域，一个型号活半年就算长寿。把模型名硬编码在业务代码里、把预算建在当前价格上、把提示词调到只对某一个版本有效——这三件事迟早会在某个周一早上一起爆发。
这篇给一套预案。相关的排查经验可以对照站内的 DeepSeek 别名失效 404那篇实际案例。
变化通常有四种形态
一、直接下线。 老型号停止服务，调用返回模型不存在的错误。通常有公告期，但公告不一定推送到你眼前。
二、别名指向变更。 你用的是一个「最新版」类的别名，厂商把它指向了新版本。调用不会失败，但行为变了——输出风格、格式遵守程度、token 消耗都可能变化。这种最危险，因为没有任何报错。
三、价格调整。 单价上调、免费额度缩减、折扣政策变化、峰谷定价上线。账单会告诉你，但通常晚了一个月。
四、参数或能力变更。 某个参数被弃用、上下文上限调整、结构化输出的行为变化。表现为偶发的解析失败或行为异常。
早发现：三个低成本的监控点
一、把模型名和版本记进每条调用日志。 出问题时能立刻回答「什么时候开始变的」。这一条几乎零成本，但没做的话事后完全无从查起。
二、监控输出特征的漂移。 不需要复杂方案：记录平均输出 token 数、结构化输出的一次成功率、平均耗时。这三个数突然变化，往往意味着底层模型换了。
三、订阅厂商的变更公告。 状态页、变更日志、开发者邮件列表。指定一个人负责看，别指望所有人都会看。
降耦合：三个工程习惯
一、模型名走配置，不进代码。 业务代码里用语义别名（「快模型」「强模型」「视觉模型」），配置层映射到具体型号。换型号时改配置发布，不用改代码。
二、慎用「最新版」别名。 别名的好处是自动升级，坏处也是自动升级——你无法控制它什么时候变。生产环境建议钉死具体版本号，主动升级；实验环境可以用别名跟进新版本。
三、保留一条备用链路。 至少接通两家，平时按权重分流或只做健康检查。某家出问题时切换是配置改动而不是紧急开发。做法见多家 API 统一封装。
迁移时的回归测试该测什么
不要只测「能不能调通」。至少覆盖这五项：
一、输出格式稳定性。 用同一批样本跑，统计结构化输出的一次成功率。这是最容易退化的一项。
二、内容质量。 二三十条真实样本人工盲评。别只看平均质量，重点看最差的那几条变没变差——用户投诉来自尾部而不是均值。
三、token 消耗变化。 新模型的分词器可能不同，同样的输入 token 数会变，成本要重算。用 token 计算器对比，再代进月成本估算器。
四、延迟。 首 token 时间和总耗时。新版本更强不代表更快，交互场景里这一项直接影响体验。
五、限流额度。 新型号的 RPM/TPM 额度可能和老型号不同，并发配置要重调。见 RPM 和 TPM 是什么。
灰度切换的节奏
第一步，影子流量。 新模型接收复制的请求但不返回给用户，只记录结果做对比。成本是双份，但风险为零，适合关键链路。
第二步，小比例灰度。 百分之几的真实流量走新模型，盯住上面五项指标和用户反馈。
第三步，逐步放量。 每次翻倍，每档观察足够长的时间跨过一个完整的业务周期（至少覆盖工作日和周末）。
第四步，保留回滚开关。 全量之后别急着删掉老配置，留一两周。回滚能力比什么都重要。
价格调整的应对
收到调价公告后按顺序做三件事：
一、重算预算。 用新单价把月成本估算器重跑一遍，看影响有多大。别凭感觉判断「涨了一点点」。
二、先做结构优化再考虑换家。 压缩输入、提高缓存命中率、简单任务分流——这些通常能吃掉相当一部分涨幅，而且没有迁移风险。见大模型 API 降本十招。
三、算清迁移的净收益。 换家省下的钱要能覆盖 prompt 重调、格式重验、效果回归的工时。差距不到两成通常不值得动。
维护一批「回归样本」是核心资产
上面所有的迁移动作都依赖一件事：你手上有一批能随时跑的真实样本。没有它，任何变更你都只能凭感觉判断「好像没变差」。
这批样本不需要很大，二三十条到一两百条足够，但要满足三个条件：
一、来自真实流量。 从线上日志里抽，不要自己编。编出来的样本往往过于规整，测不出真实问题。
二、覆盖分布而不只是典型情况。 要包含最长的、最短的、格式最奇怪的、多语言混排的、以及历史上出过问题的那几条。尾部样本比典型样本更能暴露差异。
三、有明确的评判标准。 结构化输出可以自动校验；开放式输出需要人工评，那就把评判维度写下来（相关性、格式、语气、有没有编造），让不同的人评出来结果可比。
有了这批样本，模型换代、提示改版、厂商切换都从「赌一把」变成「跑一遍看数据」。这是所有 AI 工程实践里投入产出比最高的基础设施之一。
变更来临时的一份行动清单
收到下线或调价公告后，按顺序做：
- 确认影响面：搜代码和配置，列出所有用到该型号的调用点。
- 确认时间线：公告的截止日期，倒排你的迁移计划。
- 选替代型号：优先同厂商的后继版本（迁移成本最低），其次才考虑换家。
- 跑回归样本：五项指标（格式、质量、token、延迟、额度）逐项对比。
- 算成本变化：新单价代进月成本估算器。
- 灰度切换：小比例放量、观察、逐步放大。
- 保留回滚：老配置留两周再删。
七步里最容易被跳过的是第 4 步和第 7 步——前者导致上线后才发现质量退化，后者导致出问题时无法快速止损。
一句总结
把「模型会变」当成常态设计，而不是当成意外处理。模型名走配置、留一条备用链路、有一批回归样本随时能跑——这三件事做好，任何一次变更都从紧急事故降级成一次例行发布。
三个高频问题
问：用「最新版」别名是不是更省事？ 短期省事，长期是风险——它会在你不知道的时候变。生产建议钉死版本，主动升级。
问：厂商说新版本完全兼容，还需要回归吗？ 需要。兼容指的是接口协议，不保证输出行为一致。输出风格、格式遵守度、token 消耗都可能变。
问：老模型下线前有多长缓冲期？ 各家不同，且可能调整。不要把计划建在缓冲期上，收到公告就开始准备。