后台提示有新版模型了，同事说效果更好，但你心里没底：同样的活换过去，账单会涨多少？涨在输出变长、重试变多，还是单价本身？这篇给一套按任务对照的做法，把升级前后的花费摆到同一张表上比，顺带说清哪些任务压根不该跟着换。
后台提示有新版模型了，同事说效果更好，但你心里没底：同样的活换过去，账单会涨多少？涨在输出变长、重试变多，还是单价本身？这篇给一套按任务对照的做法，把升级前后的花费摆到同一张表上比，顺带说清哪些任务压根不该跟着换。
核心思路只有一句：别比总账单，比同一批任务的小计。总账单里混着流量波动、季度活动、缓存命中变化，看不出升级到底动了哪一块。把活固定下来、把口径对齐、把量拆开，差异才归因得清楚。
先搞清楚：换代之后钱为什么会变
换代后花的钱变了，八成不是「单价涨了」四个字能解释的。按量计费下，同样的任务在新模型上可能输出更长、思考过程更啰嗦、失败重试更多，也可能因为缓存命中率变化而反向省钱。这四条来源要分开看，处理方式完全不同。
- 单价口径
- 输入输出定价、缓存折扣、阶梯或倍率的算法，换模型时这些规则经常整套换，不能拿旧口径直接乘
- 输出长度
- 新模型更爱展开解释或先写推理，同样提示词产出的 token 数可能明显变多
- 重试次数
- 格式不合法、截断、超时都会触发重试，一次重试就是一次完整计费
- 缓存命中
- 同一段长提示词复用越多越省，换模型后缓存前缀是否还能命中要看服务方实现
还要注意一个常见误区：同一批任务里混着简单活和难活。换代通常只对难活有明显差异，简单活的成本波动多是噪声。所以平均值不能直接拿来下结论，得按任务类型分开看。先到 /tools/model-cost-calculator 把新旧单价折算成同口径，再谈变化幅度。
选一组能代表你日常的基线任务
没有基线任务，就没有对照。挑任务的原则是覆盖日常流量的主要类型，而不是挑最难或最贵的。一般 5-8 个就够，太少说明不了问题，太多跑起来累且没人维护。
- 短问答类：客服回复、标题生成，输入输出都短，主要看单价和重试率
- 长文总结类：报告摘要、会议纪要，输入长，主要看输入计费和缓存命中
- 结构化抽取类：从文本里提字段、转 JSON，看输出格式合法率和重试次数
- 代码生成类：补函数、写测试，输出偏长且容易触发多轮修正
- 多轮对话类：上下文累积，看每轮新增 token 和整体轮次成本
每个任务必须固定输入素材和提示词，换代前后用同一份。如果顺手把提示词也改了，那比的是提示词而不是模型，结论没法用。给每个任务记三个数：调用次数、输入 token、输出 token，重试单独计一次，别混进成功调用里。
- 定任务清单选出 5-8 个任务，写清每个任务的输入来源和期望输出，落在本地表格里
- 冻住提示词把提示词和参数（温度、最大输出长度等）存成快照，两轮测试都用同一版
- 跑两轮旧模型一轮、新模型一轮，每轮至少覆盖一个有代表性的流量时段，避免只跑深夜低峰
- 对口径到 /usage 看真实用量口径，确认自己记的 token 数和后台统计能对上
对照表怎么填：把「花的钱」拆成能比的列
对照表的价值不在最后那个小计，而在中间几列。小计差多少只是结果，差在量还是差在单价才是能动手改的地方。下面这张表是建议的列结构，实际填的时候新旧各来一份或者新旧并排都行。
| 列名 | 填什么 | 看什么 |
|---|---|---|
| 任务名 | 基线任务里的编号或名称 | 用于分组，别合并成一行 |
| 调用次数 | 该任务测试期的总调用数 | 次数差异大说明流量本身不稳 |
| 输入量 | 输入 token 合计 | 换模型后通常变化不大 |
| 输出量 | 输出 token 合计 | 变化最频繁的一项，重点看 |
| 重试次数 | 失败后重发的次数 | 突然变多要查输出格式约束 |
| 单位成本 | 按当时页面单价折算的结果 | 以 /official-api 为准，别用记忆 |
| 小计 | 该任务总花费 | 差异归因到上面哪几列 |
如果站点有缓存或倍率区别，先在口径上对齐再比，不然数字没有意义。官方单价以 /official-api 当时页面为准，中转价到 /sites 对应站点页核对。任何单价数字都不要凭印象写，过几周就变了。
什么情况下别升、或者只升一部分
升级不是默认动作。有一类任务换代带来的效果提升，在业务上根本感知不到，但成本波动是实打实的，这种就别跟。判断标准很简单：这个任务的输出有没有人在认真看，出了小错会不会有人发现。
| 任务类型 | 有没有必要跟 | 原因 |
|---|---|---|
| 简单分类、关键词抽取 | 通常不跟 | 输出空间小，新旧差距难体现在业务上 |
| 长文总结 | 看场景 | 质量提升可能值得，但输出变长的成本要单独算 |
| 结构化抽取 | 先修格式 | 重试变多往往是提示词约束问题，不是模型问题 |
| 多轮对话 | 半量试 | 上下文成本累积，适合先接一部分流量 |
| 代码生成 | 看验收方式 | 有测试用例兜底时可以试，纯人工验收要算人力 |
对稳定性要求高的线上链路，换代要配套验证和回退方案，参考 /model-upgrade-migration-checklist 的做法。预算卡得紧时，优先在一个任务上试，跑一周真实流量再决定要不要全量切。如果差异主要来自重试变多或输出失控，先查提示词和输出格式约束，别急着换回去，问题很可能不在模型。
决定要换之后，按这个顺序落地
决定换之后，别一次全切。全切之后再出问题，你分不清是模型不行还是流量变了，也回不到干净的对比状态。按下面四步走，每一步都有可验证的输出。
- 灰度新模型只接一部分任务或一部分流量，观察一周账单和失败率，对比基线任务的表
- 设闸把预算告警和单次调用上限配好，防止输出变长导致意外跑飞，告警阈值参考升级前一周的峰值
- 留底保留旧模型的调用配置和一组可回退的提示词快照，写清回退条件是什么
- 复盘一个月后把新旧账单并排看一眼，确认差异方向和当初预估一致；不一致就回去查是哪一列变了
回退条件要提前写死，比如失败率超过某个比例、单任务小计超过预估多少，满足就回退，不要临场拍脑袋。升级前后价格和模型资料都可以到 /official-api 和 /price-watch 核对当时的数字。
下一步把你手上正在跑的任务按上面的表填一遍，拿着新旧小计去 /tools/model-cost-calculator 折算一下，再决定切不切、切多少。→常见问题
升级后账单涨了，是模型变贵了还是我用多了？
先分两件事看：单位 token 的单价有没有变，以及同样任务的 token 消耗量有没有变。多数情况是后者——新模型输出更长或重试更多。把新旧两次的调用次数、输入输出量分别列出来，量涨了就是用法问题，价涨了才是口径问题。
只想知道大方向，不想做完整对照表怎么办？
挑一个你每周都跑的典型任务，新老各跑三次，记下调用次数和肉眼估的输入输出量，换算成金额比一下。样本小但方向够用。注意别拿单个任务的结论推广到全部任务，简单任务和难任务的差异方向经常相反。
换代后效果确实好了，但成本超预算，有折中办法吗？
常见做法是分任务路由：难任务走新模型，简单任务留旧模型，按判断规则切。这样通常能把大部分成本留在低档，同时保住关键任务的效果。代价是维护两套配置，任务边界要写清楚，不然容易切错。
