按成本选模型：一套能重复执行的模型选型流程

2026-08-07

一个团队来问我该换哪个模型，理由是”看到某个榜单它排第二”。我问了三个问题：你们的任务是什么、什么算做对了、现在一次任务花多少钱。三个问题全答不上来。这种情况下换模型基本等于抽奖——换完感觉变好了就留着，感觉变差了就换回去，全靠体感，下个月再来一遍。

排行榜解决不了选型问题，原因很简单：它测的不是你的任务。榜单上的题目、评分方式、输入分布，跟你线上真实跑的那批数据几乎没有交集。它能告诉你一个模型大概处在什么档位，但没法回答你真正要问的那个问题——在我的验收标准下，哪个模型的单位任务成本最低。

这篇讲的就是怎么把这个问题变成一个能重复执行的流程。不是”我觉得哪个好”，而是一套下次还能原样再跑一遍、结论可比较的做法。

一、没有验收线的对比，全是各说各话

选型的第一步不是找模型，是写下什么算通过。

我见过太多”对比测试”的结论长这样：A 的回答”更自然”，B “更啰嗦”，C “有时候会跑偏”。这些形容词没法排序，也没法复现——换个人来看，结论就变了。更麻烦的是它没法被推翻：一个月后有人说”我觉得 B 现在挺好的”，你拿不出任何东西反驳。

验收线必须是可量化的，而且要贴着你的实际交付标准。常见的几类：

格式合法率：输出能被 JSON 解析、字段齐全、枚举值在允许集合内。这一类最容易量化，写个校验函数就能自动打分。
准确率 / 命中率：抽取类、分类类任务有标准答案，直接比对。注意标准答案要人工确认过，不能拿另一个模型的输出当标准答案，那是在测两个模型像不像，不是在测对不对。
人工抽检通过率：生成类、改写类任务没有唯一答案，只能人工判。那就把判断标准写成一张评分卡（比如：事实无错误 / 没有编造引用 / 语气符合要求 / 长度在范围内，四项全过才算通过），让不同的人打分能收敛。

验收线还得定一个阈值。“通过率 92%“这个数字本身没意义，得说清楚 90% 以下我们不能上线、95% 以上算超额。有了阈值，后面所有的成本比较才有前提——只在达标的候选之间比成本，不达标的直接出局，再便宜也不看。这一条要守住，否则很容易被”它便宜好多”带着走，最后省下的 API 钱全赔在返工上。

关于测试集怎么搭、评分卡怎么写，我在怎么自己实测一个大模型里展开过，这里不重复。

二、真正的指标是单位任务成本，不是 token 单价

比价的时候大家习惯看单价——每百万 token 多少钱。这个数字有用，但它不是你的成本。你的成本是完成一次业务任务实际花掉多少钱。

基础公式：

单位任务成本 = (平均输入 token × 输入单价 + 平均输出 token × 输出单价) × (1 + 重试率)

这里的重试率指的是自动重试：输出格式非法、内容为空、触发了兜底规则，程序判定后重新调一次。重试是要重新计费的，而且重试时输入 token 通常一分不少（甚至因为要加纠正提示而变多）。

但这个公式还不完整。自动重试几次仍然不过的那部分，最后是人来收拾的。所以完整一点：

千次任务总成本 = 1000 × 单次调用成本 × (1 + 重试率) + 1000 × 人工返工率 × 人工单次成本

下面用一组纯假设的数字做算术演示。这些价格是我随手编的相对值，只是为了把结构讲清楚，不代表任何平台的真实报价——你要算自己的账，必须用你实际拿到的价格代进去。

设：每次任务平均输入 2000 token、输出 500 token。

模型 A（大档）：假设输入 10、输出 30（单位：元 / 百万 token）

单次调用成本 = 2000 ÷ 1,000,000 × 10 + 500 ÷ 1,000,000 × 30 = 0.02 + 0.015 = 0.035 元
假设自动重试率 5%，人工返工率 2%

模型 B（小档，单价刚好便宜 10 倍）：假设输入 1、输出 3

单次调用成本 = 2000 ÷ 1,000,000 × 1 + 500 ÷ 1,000,000 × 3 = 0.002 + 0.0015 = 0.0035 元
假设自动重试率 40%，人工返工率 15%

先只看 API 这一层，每千次任务：

A：1000 × 0.035 × 1.05 = 36.75 元
B：1000 × 0.0035 × 1.40 = 4.9 元

结论有点反直觉：重试率从 5% 涨到 40%，也没能吃掉 10 倍的单价差。B 还是便宜 7.5 倍。所以那句流传很广的”便宜模型重试多了反而更贵”，在只算 token 的口径下，通常不成立——重试率得高到离谱才可能翻盘。

真正吃掉差价的是人。把人工返工加进来，设人工处理一次的折算成本为 H 元：

A 的千次总成本 = 36.75 + 1000 × 2% × H = 36.75 + 20H
B 的千次总成本 = 4.9 + 1000 × 15% × H = 4.9 + 150H

B 更划算的条件是 4.9 + 150H < 36.75 + 20H，即 130H < 31.85，解得 H < 0.245 元 / 次。

0.245 元是什么概念？按人力折算 60 元 / 小时算，一分钟 1 元，0.245 元大约相当于 14.7 秒。也就是说：只要每次人工返工要花掉超过 15 秒钟，那 10 倍的单价优势就已经被抹平了。而现实中，人打开一条记录、看懂上下文、改完、确认，很难在 15 秒内完成。

再看反过来的情况。假设你给 B 加了一层机器校验和自动修复（schema 校验 + 字段补全 + 失败降级到大模型之前先自修一次），把人工返工率从 15% 压到 3%：

B 的千次总成本 = 4.9 + 1000 × 3% × H = 4.9 + 30H
条件变成 4.9 + 30H < 36.75 + 20H，即 10H < 31.85，解得 H < 3.185 元 / 次

同样按 60 元 / 小时折算，3.185 元约等于 191 秒，也就是 3 分多钟。人工返工只要不超过 3 分钟，B 就赢。这个区间几乎覆盖了所有常见场景。

这两组算术放在一起，指向同一个工程结论：决定小模型能不能省钱的，不是它便宜多少倍，而是你有没有能力把它的失败挡在人力之前。校验、自修、降级重试这些工程手段，比换模型本身的杠杆大得多。小模型什么时候真的更省钱那篇把这个降档判断讲得更细。

三、评测流程：五步，每步都别偷懒

有了验收线和成本口径，剩下的就是把测试跑得干净。顺序不能乱：

第一步，固定评测集。 从真实业务日志里抽样，不要自己编题。样本量看任务方差，格式抽取类几十条可能就够，开放生成类建议上百条。关键是要覆盖长尾——把你线上那些超长输入、脏数据、缺字段的坏样本按真实比例放进去。只用干净样本测出来的通过率，上线一定崩。抽完之后把这个集合存下来、加版本号，它是你最重要的资产，后面每次复评都靠它。

第二步，固定采样参数与随机种子。 temperature、top_p、max_tokens、system prompt 全部统一，能设随机种子的就设。参数不一致的对比等于没测——你分不清差异是模型带来的还是采样带来的。同一个模型最好跑两遍，看看自身波动有多大，这个波动值就是你判断”两个模型有没有真实差距”的噪声底线。差距小于噪声底线，就当它们没差别。

第三步，同批输入跑所有候选。 同一批样本、同一天、同一套调用代码。不要今天测 A、下周测 B，中间平台侧可能已经调过东西了。并发也压低一点，测试阶段被限流触发的失败会污染你的重试率统计。

第四步，按验收线打分，同时记录 token 消耗。 打分要自动化的尽量自动化，人工的部分至少两个人交叉抽检。token 消耗必须从接口返回的用量字段里读，不要自己估——分词方式不同，估算误差可能很大。同时记下失败样本的具体类型（格式错、内容错、超时、截断），这些分类后面决定你要不要加工程兜底。

第五步，算单位任务成本，排序。 先按验收线筛掉不达标的，剩下的按单位任务成本从低到高排。

结果落到一张表里，长这样：

模型	平台	结论
候选一	平台甲	达标 / 出局
候选二	平台甲
候选二	平台乙
候选三	聚合渠道

注意表里”平台”是单独一列。同一个模型在不同接入渠道下，价格、限速、稳定性可能都不一样，所以同模型不同平台要各占一行，不能合并。多平台多档位的价格摆在一起看比较费劲，模型对比工具可以把参数和价格并排列出来，用来圈定候选名单、少填几列表格，省事不少。

最后一列”结论”别写”还行”，写能行动的话：选它 / 出局（通过率不够）/ 备用（贵但稳）/ 待复测（波动大）。

四、终局不是选一个模型，是分层调度

跑完一轮你会发现一件事：不同请求的难度差别，比不同模型的能力差别还大。同一批任务里，可能七成极其简单，两成中等，一成是硬骨头。用一个模型接全部，等于让最贵的档位去干最简单的活。

所以成熟的做法不是”选一个”，而是给不同难度的请求配不同档位：简单的走小模型，复杂的走大模型，小模型失败的升级到大模型重试一次。前面第二节那笔账里”人工返工率从 15% 压到 3%“，靠的主要就是这个升级重试。

难点在路由判据怎么定。几种常见做法，可靠性差别很大：

按任务类型路由：最可靠。你自己的系统本来就知道这次是”抽取字段”还是”写摘要”，直接按业务类型硬编码档位，零额外成本、零误判。能用这个就优先用这个。
按输入长度路由：次可靠，而且几乎零成本。长输入通常意味着上下文复杂、更容易出错。缺点是长度和难度只是弱相关——短输入里也有难题。适合作为辅助判据。
按检索命中情况路由：RAG 场景很好用。检索到的片段少、相似度低，说明这次上下文支撑不足，直接走大档。这是个客观信号，比让模型自己判断可靠。
按小模型自评置信度路由：最不可靠，慎用。模型对自己错在哪里的判断能力，通常明显弱于它做对这件事的能力——它答错的时候，往往也一样自信。用自评当唯一判据，你会把大量错误当成功放过去。
按输出的可校验信号路由：推荐。schema 校验没过、必填字段缺失、数值超出合理范围、引用的 ID 在库里不存在——这些都是硬信号，判定成本几乎为零，误判率极低。用它触发升级重试，比任何软性置信度都强。

一句话概括：优先用客观可校验的信号做路由，把模型的主观自评放在最后，或者干脆不用。

分层做完之后，你的成本结构会变成”大部分请求很便宜 + 小部分请求贵”，整体单位成本往往能降到只用大模型的一个零头。更多降本手段（缓存、prompt 瘦身、批处理）在大模型 API 成本优化里有系统的整理。

五、换模型的隐性成本，必须摊进去算

看到更便宜的就换，这个策略听起来理性，实际很少划算。因为换模型不只是改个 model 参数。

prompt 要重调。 不同模型对指令的理解习惯不一样，同一段 prompt 换个模型，输出风格、遵循程度都会变。你原来那套精雕细琢过的提示词，大概率要重新调一轮才能回到原来的通过率。

输出格式可能变。 尤其是 JSON 输出、工具调用、多轮状态这些地方，字段命名习惯、转义方式、边界行为都可能有差异。你下游的解析代码、校验规则、兜底逻辑都得重新验一遍。

评测要重跑。 不重跑就是盲换。重跑就意味着又一轮打分工时。

灰度和回滚要做。 直接全量切换是在拿线上赌博，正经做法是小流量灰度、盯几天指标、留好回滚开关。这部分是纯工程时间。

把这些算进去，一次模型迁移的一次性成本可能相当于好几个月的 API 差价。判断方法很直接：估算迁移的一次性成本，除以每月省下的钱，得到回本周期。回本周期超过三到六个月的，我一般建议不动——因为这段时间里价格和模型很可能又变了，你会陷入永远在迁移的状态。

反过来，如果新方案不只是便宜，还能带来通过率提升或者延迟改善，那账就要重算，这时候迁移往往值得。

六、多久重评一次

模型在变，价格在变，你自己的输入分布也在变。一次测完永远有效是不存在的。但也不能天天测，那成本自己就把自己吃了。

我的建议是定期 + 触发式两条腿：

定期：每季度一次。 用存好的评测集，把当前在用的模型和一到两个候选跑一遍，更新那张表。一个季度这个节奏，既能跟上大的变化，又不至于把人耗死。
触发式：三类情况立刻重评。 一是你在用的档位价格有明显变动；二是你的业务输入分布发生了变化（接了新客户、新品类、新语种）；三是线上通过率或返工量出现持续下滑——这通常说明输入漂移了，不一定是模型变了。

能做到低成本重复，前提只有一个：评测集和打分脚本要留着，而且要能一键跑完。第一次搭这套东西是有成本的，但它的价值在于第二次、第三次几乎零成本。很多团队每次选型都从零开始攒样本、临时找人打分，所以每次都痛，痛到最后干脆不测了，退回到看榜单和拍脑袋。

顺便说一句：评测集要跟着业务一起长。每次线上出现新的失败模式，就把那条样本补进集合里。跑上一年，这个集合本身就成了你最了解自己业务的那份资产。

七、不知道限速和真实价格时，怎么稳妥起步

有个现实问题：你在正式接入之前，很多数值是拿不到的——具体限速多少、并发上限多少、实际计费口径怎么算，各平台各不相同，以官方文档和控制台的说明为准。这时候别猜，用一套保守流程就能安全起步：

低并发起步，先跑通再加压；打开完整的用量和错误日志，用真实返回的用量字段统计而不是估算；重试统一走指数退避加抖动，别写死固定间隔；先用几百条样本跑出你自己的单位任务成本，再决定要不要放量。这套流程的好处是，不管平台侧的数值是多少，你都是先观测后决策，不会因为一个猜错的假设把预算烧掉。

自查清单

上线前把这几条过一遍：

验收线写下来了吗？是可量化的指标加明确阈值，不是形容词？
评测集是从真实日志抽的吗？坏样本、长尾样本按真实比例放进去了吗？存了版本号吗？
所有候选是同一批输入、同一套采样参数、同一天跑的吗？
token 消耗是从接口返回的用量字段读的，不是自己估的吗？
单位任务成本算进了重试率和人工返工率吗？只在达标的候选之间比价了吗？
路由判据用的是客观可校验信号（任务类型、schema 校验、检索命中），而不是模型自评置信度吗？
换模型的一次性成本（重调 prompt、重跑评测、灰度回滚）摊进回本周期算过了吗？
评测集和打分脚本存在能一键复跑的地方了吗？下个季度谁来跑，定人了吗？

圈定候选名单时，把各档模型的参数和价格并排列出来最省事：模型对比工具。