「新模型单价便宜三成，换。」采购报表上这是一行绿色数字，工程例会上却常常演变成两周的救火：老提示词在新模型上输出跑偏、评测分数对不上、下游格式解析成批报错。问题在于，大家习惯把模型切换当成改一行配置，它实际是一次跨系统的迁移。
鼎上娱乐的模型网关后面挂着多家供应商与私有化模型，切过也回退过。这篇把切换成本真正藏在哪里拆开，再给出「什么条件才值得切」的判断框架。
成本第一层：提示词不是即插即用
同一份提示词在不同模型上的行为差异远超想象。指令跟随的严格程度、对格式的服从性、长上下文中段的注意力衰减、拒绝与兜底话术的触发阈值，都跟模型强绑定。原来那句「只输出 JSON」在 A 模型上是保险，在 B 模型上可能诱发更严重的括号丢失。
所以切换的第一笔账是逐条重写与回归调试提示词：模板越多、链路越长，这笔账越贵。把提示词当代码管理——有版本、有对应测试样例——迁移成本才能压下来，这与你怎么管 模型网关 里的配置直接相关。
成本第二层：评测基线要重建
在旧模型上跑出来的分数，不能直接拿来给新模型定成败。阈值、坏例分布、人工抽检的尺度，都锚定在旧模型的行为上。换模型等于换了一把尺子，刻度要重新对齐：同一套题重跑、重新标注坏例、重新校准「可用/不可用」的判断口径。
这笔账最容易被漏掉，也最致命——没有重建的基线，上线后你根本无法回答「新模型到底是更好还是更差」，只能靠抽样感觉。上线前的六个指标 里说的就是这类问题，切换模型时每一个指标都要重测一遍。
成本第三层：下游链路的隐性适配
模型输出的不只是文字，还有一整条下游依赖：解析器的字段假设、RAG 引用标记的格式、审核管道对置信度的阈值、前端对长度与结构的样式约定。新模型「更啰嗦 8%」这种小事，可能让摘要卡片整个溢出、让分段器把一篇拆成三篇。
| 成本层 | 表面账 | 实际账 |
|---|---|---|
| API 单价 | 每千 token 差价 | 通常几周内即可摊清 |
| 提示词迁移 | 改几句提示词 | 按模板数 × 回归轮次计，常以周计 |
| 评测重建 | 重跑一次评测 | 重标注 + 重校准口径，常以周计 |
| 下游适配 | 应该不用动 | 解析、审核、样式的连锁修复 |
什么条件才值得切
- 代际差，不是价格差：新模型在目标任务上有可复现的代际提升（评测集上显著且稳定），单纯便宜 20% 不足以覆盖上面三层成本；
- 有对照环境：能在灰度里让新旧模型同时服务一部分流量，用同一批真实请求对比质量、延迟与成本，而不是「切了再看」；
- 回退是现成的：网关层保留旧模型路由与提示词版本开关，切坏了 5 分钟内可回退，参考立项与验收里「回退机制必须在上线前存在」的同一条要求；
- 量级撑得起迁移：调用规模越大，单价差的绝对金额越能摊薄三层成本；小流量场景省下的钱可能还不够付一周的工程师工资。
四种不该切的信号
- 没有自己的评测集，只凭跑分榜单和演示视频做判断；
- 提示词散落在十几个代码仓里，没有版本管理，改不动也没法回归；
- 下游解析强依赖旧模型的输出怪癖，等于把格式契约写死在某个模型上；
- 供应商合同、数据出境或合规约束还没理清——质量之外的问题一旦爆掉，工程侧无法补救，可对照上线前的合规清单先过一遍。
一句话总结：模型切换的决策不该由采购价目表做出，而该由「代际提升是否可复现、迁移三层成本是否摊得平、回退是否现成」这三个问题做出。把网关、提示词版本和评测基线这三样基础设施先建好，切换才会从一次冒险，变成一个随时可以执行的常规动作——这也是鼎上平台把模型网关与评测体系做成中台能力的原因。