1. 为什么要用 cost-per-success 重新审视模型评测做模型选型评测这件事我一直觉得行业内有个指标被严重低估了就是 cost-per-success直译过来是“单次成功成本”。这个词在海外团队的工作流里已经很常见但国内技术社区聊得还不多。很多人选模型还在比 benchmark 分数、比推理速度却忽略了真正该问的问题跑通一条业务链路平均每成功一次到底要花多少钱。先说清楚它解决什么问题。假设你有两个模型A 便宜但准确率低B 贵但准确率高。只看准确率B 肯定赢只看价格A 肯定赢。但业务方真正关心的是“花出去的钱换回来了多少有效结果”。如果一个便宜模型在 70% 的情况下能给出可用的输出每次成本 0.01 元而贵模型 95% 的情况下都可用每次成本 0.05 元那么前者的单次成功成本是 0.014 元后者是 0.053 元。前者反而更划算——前提是你愿意接受那 30% 的失败率带来的后续处理成本。这个权衡就是 cost-per-success 存在的意义。这篇文章适合谁看适合正在做 LLM 应用落地、需要在多个模型之间做技术选型的人尤其是负责 prompt 评测、成本治理、API 接入的工程师和团队负责人。我不打算讲太多理论会直接把我踩过的坑、试过的方法、调整过的参数全部摊开来。我自己是在一个模拟项目 X 里被逼着认真对待这个指标的。当时团队要上线一个批量信息抽取功能候选模型有三四个每个都宣称自己“效果不错”。如果只看人工抽检的准确率贵的那个模型确实领先但差距其实没有大到必须加钱的地步。后来我把所有开销拉通算了一遍——API 费用、失败重试的费用、人工复核的成本——才意识到按“单次成功成本”算结论完全变了。这也是我写这篇文章的初衷把一套可执行、可复现的评测流程分享出来帮你在做模型选型时少走弯路。这个指标本质上把三个维度捏在了一起模型质量、推理成本、业务对失败的容忍度。它不是要替代准确率或延迟这类基础指标而是把它们统一到一个业务语言里。接下来我会从指标拆解、评测集构建、实操流程、常见问题四个角度展开每一步都会给出可以直接照抄的做法。2. 核心指标拆解成本怎么算成功怎么定义2.1 成本侧不是只有 API 单价那么简单很多人一听到 cost-per-success 就以为只是算 API 调用单价这是最常见的误解。API 单价只是最表层的一部分。真正把成本拉通至少要包含下面几项。第一项是推理成本。对于按 token 计费的模型就是输入 token 数乘以输入单价加上输出 token 数乘以输出单价。但这里有个容易忽略的细节不同模型的输入输出定价可能差异巨大而且有的平台对缓存命中还有折扣忽略这些会直接导致估算偏差。在模拟项目 X 里我见过某个模型输入便宜得惊人但输出价格是另一个模型的几倍而抽取类任务往往输出 token 占比很高最后总成本根本没有优势。第二项是失败重试成本。模型返回的结果如果是空、是乱码、或者是不可解析的格式业务脚本通常会自动重试一次甚至多次。每次重试都会消耗 token这些消耗在预算报表里不显眼但累积起来很可观。我在评测时会把“一次任务平均触发几次重试”这个参数单列出来计入总成本。第三项是人工复核成本。如果你做的是金融、医疗这类要求高可靠性的场景机器输出的结果大概率还需要人工抽检或全检。这里的人工时间也需要折算成钱。即便不是全检为了评估模型质量而做的抽检本身也是成本只不过它发生在评测期间而不是生产环境里。我建议把它分开记录方便后期优化。我常用的总成本公式长这样总成本 调用次数 × (输入 token 数 × 输入单价 输出 token 数 × 输出单价) 重试次数 × 平均单次重试成本 人工复核工时 × 时薪折算这个公式没有把固定成本算进去比如评测脚本的开发时间、测试环境的维护成本因为这些属于基础设施投入不随模型选型变化。如果你想让数字更精确也可以把 prompt 调优的人力成本摊进每一次调用里但一般情况下没必要那么精细。2.2 成功侧业务定义比 LLM-as-Judge 更重要cost-per-success 的难点其实不在 cost而在 success。什么是“成功”不同任务有完全不同的答案。拿分类任务举例只要输出符合预设标签就算成功拿抽取任务举例关键实体必须全部命中、格式必须严格合法拿开放性生成举例成功与否往往需要人工判断甚至需要业务方亲自参与定义标准。在模拟项目 X 的第一个版本里我们用了比较偷懒的标准只要模型返回的 JSON 能解析就算成功。结果评测出来的 cost-per-success 很低看起来很美但实际上返回里有很多“看似合法、实则错误”的抽取结果比如把时间字段提取成了地点信息。这个教训告诉我成功定义必须落在业务结果层不能落在格式层。好的成功判定标准应该具备三个特点可自动化能通过代码、规则或结构化比对来判断减少人工成本与业务目标对齐业务系统真正依赖什么评测就判断什么有明确的失败分类能区分“格式错误”“内容错误”“语义错误”“拒答”这样后续才能针对性优化 prompt我建议把成功标准写成一个打分表。满分 1.0只要核心字段全部正确且格式合法就算 1.0核心字段部分正确给 0.5比如 5 个字段抽取对了 3 个完全不可用给 0。这样算出来的 cost-per-success 更有弹性也更能反映模型在真实场景下的表现差异。3. 评测集设计与场景覆盖别让一个小数据集决定你未来几个月的成本3.1 评测集的数据来源与采样策略评测集是整个 cost-per-success 评测流程的基石。数据太少模型之间的差距可能压根不明显数据太偏得出的结论用在生产环境就会翻车。我一般建议评测集至少覆盖 200 条真实业务输入而且必须要有标签或人工复核过的标准答案。如果业务本身就冷启动没有历史标注数据那就退而求其次从已上线的规则系统中抽取结果或者让标注团队先快速打一批启动数据。数据来源上要做分层采样。如果你的任务按消息类型分 A、B、C 三种每种类型实际占比是 70%、20%、10%那评测集也应该按这个比例来采而不是均匀分布。以模拟项目 X 为例我们当时要做的是把用户工单里的“问题类型”“紧急程度”“涉及产品”抽出来如果不做分层而是随机从历史工单里抽 300 条因为“问题类型”为“其他”的样本特别多最终评测结果就会偏向那种简单样本完全反映不出模型的真实能力。还要加一点对抗样本。所谓对抗样本就是那些正常情况下最让模型犯难的输入比如长文本、混合语言、手写体 OCR 结果、带误导信息的输入、空字段占位符等。这些样本数量不需要多占总量的 10% 左右就够但必须存在。因为它们能暴露低端模型真正的短板。我当时会在同一个评测集上跑三个模型前两轮结果基本接近差距就是在对抗样本那一小批上拉开的。如果不做对抗样本会误以为便宜模型和贵模型差不多从而选择一个在真实场景中频繁崩溃的模型。3.2 评测集的标注与动态维护标注是评测集里最肉疼的部分。300 条数据如果全部重新标注按单条 2 分钟算一个人也得干一整天。所以我的建议是先让模型输出再做人工校对而不是从零开始纯人工标注。这样可以节省一半以上的时间。这种“人工校对模型输出”的做法还能顺带检查一下历史系统的输出质量一举两得。评测集不是静态的。大模型迭代快prompt 也在不断调数据集如果一直不变会出现一个很微妙的问题模型可能已经在评测集上过拟合了。这里的过拟合不是传统机器学习意义上的参数过拟合而是某种“评测集记忆效应”——模型或 prompt 在反复调试中对特定样本产生了偏向。这种偏向会让评测结果虚高但放回真实场景就失效。我习惯每两周做一次评测集增量扩充每次增加 30 到 50 条新鲜样本并手动剔除那些质量问题数据。这个做法让 cost-per-success 指标长期保持可信度而不是沦为一个数字游戏。3.3 评测集大小与置信度计算评测集大小直接影响结果的可靠性。300 条数据看起来不少但如果成功率的差异只在 3 个百分点以内统计学上根本无法判定两个模型谁更强。这里有一个简单的估算方法假设成功率 p0.9样本量 n300那么 95% 置信区间大约是 p ± 1.96 × sqrt(p(1-p)/n)算出来是 ±0.034也就是 ±3.4 个百分点。两个模型成功率差距在 3 个点以内结论基本是“无法区分”。所以如果你的评测集只有 50 条就别指望能准确区分“成功 45 条”和“成功 47 条”之间的差别。真实业务里模型之间的差距往往比想象中小这时候要么扩大评测集要么引入更精细的成功评分体系让区分度从“成功/失败”变成 0 到 1 之间的连续值。我在实操中会把成功率细粒度化比如按字段得分加权平均用这种方式提高统计辨识度。4. 从单次成本到成功成本手把手搭建评测流程4.1 明确评测流程的五步框架专门做一次 cost-per-success 评测不一定需要一个多么复杂的平台。我用一个脚本加一张电子表格就能跑通整个流程关键在于步骤要完整。下面是我跑过多轮评测后固定下来的五步法供你参考。第一步定义业务场景与成功标准。写清楚“通过模型输出的哪个字段业务系统能完成什么操作”然后据此确定打分规则。第二步搭建评测集。按业务分层采样加上对抗样本完成标注或校对。第三步跑模型推理。在统一环境下保持同一套 prompt只换模型记录 token 用量、耗时、输出结果。第四步判定成功并计算成本。对每条输出打分同时把 token 成本、重试成本、人工复核成本全部折算进去。第五步汇总对比做决策。计算每个模型的 cost-per-success、成功率、平均成本、失败后重试成本形成选型建议。这个五步流程看起来不复杂但每一步都有不少细节。下面我重点展开第三步和第四步因为这两步直接决定了评测数据的可信度。4.2 模型推理时的环境控制跑评测时最怕变量不统一。一个常见错误是测试 A 模型时用的是 prompt 版本 v1测试 B 模型时 prompt 被顺手调整成了 v2结果评测出来的差异根本不知道是模型带来的还是 prompt 带来的。所以正规做法是同一个任务、同一套 prompt、同一个温度参数只改模型名称。如果某个模型对 prompt 格式特别挑剔可以在评测前做单独记录但仍要在相同基础 prompt 上跑一轮“公平赛”。有的模型平台还有各自的默认参数比如 temperature 是 0.7 或者 1.0top_p 是 0.9 或者 1.0。这些参数会直接影响输出的随机性从而影响成功判定结果。评测时我一般把温度固定为 0如果平台不允许 0就用一个较低值如 0.1并记录下来防止后期换模型时因为参数不一致导致结果失真。还要注意并发问题。评测脚本如果用并发请求来提高速度实际上会在不同模型间引入隐藏变量某些平台并发高时延迟增加甚至可能触发限流导致输出截断或重试进而影响成功率和成本。我在模拟项目 X 的评测里吃过这个亏后来强制让每个模型每批次只跑 10 个并发并且记录了最高延迟时间和 95% 延迟分位数用来辅助判断生产环境下的延迟成本。4.3 成本核算的具体演示为了让你更直观地理解 cost-per-success 的计算过程我模拟一个具体场景。假设我们要评测 300 条工单抽取任务候选模型有两个模型 A 和模型 B。价格和表现如下模型 A输入单价 0.002 元/千 token输出单价 0.006 元/千 token平均每条输入 800 token输出 200 token成功率 85%其中失败重试率 30%每次重试同样消耗 token重试一次后的成功率为 40%。模型 B输入单价 0.005 元/千 token输出单价 0.02 元/千 token平均每条输入 800 token输出 220 token成功率 95%失败重试率 10%重试一次后的成功率为 60%。先算模型 A 的单次推理成本0.002 × 800 / 1000 0.006 × 200 / 1000 0.0016 0.0012 0.0028 元那 300 条直接全部跑一次的成本是 0.84 元。但因为有 30% 的失败重试45 条会触发重试每条重试额外花费同样的 0.0028 元45 × 0.0028 0.126 元。最终成功条数255 18 273。总成本 0.966 元cost-per-success 约为 0.0035 元。再看模型 B 的单次推理成本0.005 × 800 / 1000 0.02 × 220 / 1000 0.004 0.0044 0.0084 元重新跑一遍的成本是 2.52 元。失败率 5%15 条触发重试每条重试成本同样 0.0084 元15 × 0.0084 0.126 元。成功条数285 9 294。总成本 2.646 元cost-per-success 约为 0.009 元。从 cost-per-success 角度看模型 A 大约是模型 B 的三分之一。但别急着选 A因为上面的计算还没有考虑人工复核成本。如果业务要求 100% 正确输出A 有 27 条失败每一条都需要人工介入修复B 只有 6 条。假设人工修复一条需要 0.1 元A 的总成本要再加 2.7 元B 加 0.6 元最终 A 的 cost-per-success 是 0.013 元B 是 0.011 元。结论直接反转。这就是 cost-per-success 和单纯看 API 单价最大的不同它会逼你把后处理的账也算进去算完才发现便宜模型可能并没有真正便宜。4.4 成功率之外的辅助指标P50 延迟与失败分布cost-per-success 是核心决策指标但我不建议只看这一个数。辅助指标至少还要看两个一个是延迟分布一个是失败分布。延迟分布用 P50 和 P95 两个值就够了。P50 代表一般情况下的响应速度P95 代表最差情况下的体验。如果两个模型的 cost-per-success 差不多P95 延迟短的那个通常更适合生产环境因为长尾延迟会带来超时、重试、排队等一系列连锁反应这些反应最终又会反馈到成本里。失败分布要看失败类型是不是集中在某类样本上。如果失败全部发生在对抗样本或长尾样本上处理起来会比较危险因为这种失败在生产环境里几乎不可预知。如果失败均匀分布在普通样本上反而更好优化——调整 prompt 或加 few-shot 示例能快速见效。在模拟项目 X 的评测里我们发现模型 A 的失败样本里有 70% 都是“混合语言输入”后来单独给这类样本加了预处理逻辑成功率立刻提高成本也顺势下降。5. 模型选型评测中我踩过的坑和对应的排查思路5.1 评测集太小的坑怎么判断才算“够”有一段时间为了赶项目进度我们只用 60 条测试数据跑了一轮评测结果临时选了一个便宜模型上线。上线后真实成功率比评测结果低了整整 10 个百分点排查了很久才发现是评测集太小且恰好偏简单。从那以后我定了一个规矩任何选型评测少于 150 条数据不做决策如果业务更复杂建议 300 条起步。判断“够不够”的方法除了用置信区间估算还有一个更实操的手段把评测集切分成“普通样本”和“对抗样本”两部分来看如果两部分模型表现的差距稳定说明评测集样本量已经能反映出稳定的模型水平如果每一轮跑的结果波动都很大比如同一模型成功率忽高忽低那大概率是样本量不足。5.2 成功标准的主观性怎么从评分表里挤掉水分成功标准如果只靠“我看一下结果觉得行就行”成本核算必然失真。因为不同评估者会觉得“行”的标准不一样。为了尽量挤掉水分我建议做两件事一是把评分标准量化。核心字段必须全部吻合才给满分每个字段都给权重比如“问题类型”权重 0.4、“涉及产品”权重 0.3、“紧急程度”权重 0.3。模型输出和标准答案完全一致得 1.0漏了一个字段按权重扣分完全偏离得 0。这样我就有了可计算的分数而非“好”“坏”两个模糊字眼。二是让两个人同时评估同一批样本做一致性校验。人工评估本来就是有噪声的两个人的标准有差异很正常但如果差异大到总分相差超过 0.2说明评分标准还写得太含糊需要继续拆细。这种做法不完美但能把主观性控制在一个可以接受的区间内。5.3 价格波动与缓存命中如何让成本对比更公平模型价格不是一成不变的。有些平台会在一定时间段内调整价格有的还会习惯性用“首月优惠”“限时折扣”来吸引用户。评测时要特别注意价格永远以“当前的正式商用价格”为准而不是拿优惠价格去算成本。我曾经在评测时用了一个平台的新用户体验券算出来的 cost-per-success 非常诱人但项目真正上线之后成本直接翻倍。缓存命中也是一个隐形变量。很多平台对输入前缀做缓存如果评测脚本反复使用相同的前缀 prompt会得到缓存折扣价从而低估实际成本。为了评测公平我会故意在每条输入前加一个随机变化的用户 ID 占位变量把缓存的影响消除或者分别在“有缓存”和“无缓存”两种模式下记录成本然后按照生产环境中可能的缓存命中率做折算。5.4 随机性与可复现性怎么判断两次答案的不同不是bug大模型输出有随机性即便温度设为 0某些平台仍可能因为负载均衡或模型版本不同给出不一样的结果。评测中最让人头疼的就是模型表现一会儿高一会儿低不知道是模型本身的问题还是随机波动。我的排查思路是当成功率出现明显波动时对同一批数据至少跑 3 轮观察波动范围。如果 3 轮结果的成功率波动超过 5 个百分点说明模型随机性太大不适合做高稳定性业务。这种情况下需要检查是不是温度参数没设对、或者是网络超时导致半截输出被判断为成功/失败。自动脚本里我会打印每次调用的 HTTP 状态码和响应长度方便定位这类问题。6. 进阶玩法把 cost-per-success 变成动态监控指标6.1 从一次性评测变成线上定期巡检如果团队有稳定的评测集完全可以把这个流程从“选型时跑一次”升级为“每周自动跑一次”用来监控已上线模型的健康度。尤其在生产环境中模型版本被平台悄悄升级、某个预设参数被改动、或者输入分布发生偏移都会导致 cost-per-success 明显上升。一旦这个数字超过预设阈值就触发告警让负责人介入调查。我实践下来的做法是每周日凌晨通过定时任务跑一遍 300 条数据的完整评测把得到的 cost-per-success 和成功率、P95 延迟汇总到一张表里。连续 3 轮对比如果都呈上升趋势即使还没有超过阈值也会主动去排查一下原因而不是等到线上出现异常再处理。6.2 多任务加权不同业务线的 cost-per-success 怎么汇总一个公司往往有不止一个模型场景。内容审核做一个评测智能客服做一个评测信息抽取又做一个评测。不同任务的“成功”定义不同成本结构也不同简单加总没有意义。我建议用业务比例加权来汇总假设内容审核占业务量的 60%智能客服占 40%那整体 cost-per-success 内容审核的 cost-per-success × 0.6 智能客服的 cost-per-success × 0.4。这个加权的价值在于它可以帮助评估“使用同一个大模型统一处理所有任务”是否比“不同任务用不同模型”更经济。有些场景会用分开的模型各自达到最优的 cost-per-success但维护成本上升有些场景用一个大模型虽然单项不是最优但统一维护和缓存命中率更高总账反而划算。这个决策用加权的 cost-per-success 来衡量比凭感觉判断靠谱得多。6.3 联动 prompt 优化以 cost-per-success 为核心指标迭代prompt 优化的目标也应该围绕 cost-per-success而不是单纯提升准确率。举个例子在二元分类任务中加上一段 few-shot 示例准确率从 90% 提升到了 93%但输出 token 数量增加了 40%。算下来成本上升成功率的提升又不足以抵消成本这种情况下优化后的 prompt 反而更差。如果不看 cost-per-success只看准确率很容易做出反向优化。我自己一般会记录每一个 prompt 版本的 cost-per-success建立一条“优化曲线”。曲线右移代表效果提升但成本增加曲线下移代表在更低的成本下取得了更好的效果。只有当成本侧和效果侧同时优化或者单侧改善而另一侧不劣化的时候我才会确认这一版 prompt 优化是有效的。7. 评测报告的呈现方式与决策建议7.1 单页报告该有的几个模块评测做完后需要给团队或上级一个直观的呈现而不是丢出一堆原始数据。我的建议是单页报告包含四个模块就够了评测说明评测集规模、采样方式、成功判定标准成本对比表每个模型的总成本、成功率、cost-per-success、重试率、延迟分位数细分场景分析普通样本与对抗样本的分别表现各失败类型的占比推荐结论基于 cost-per-success 和风险分析给出“建议优先”“可以考虑”“不建议”三个档位的结论并附上原因7.2 一张对比表说清楚问题我在模拟项目 X 的评测报告里做过下面这样一张表效果非常好指标模型 A模型 B模型 C成功率86%93%95%每次推理成本元0.00280.00630.0084失败重试率30%18%10%重试后累计成功率92%95%98%人工复核成本元/条0.0350.0180.008加权总成本元21.912.69.4cost-per-success元0.01020.00710.0055看完表的第一个感觉是模型 C 最划算因为它的 cost-per-success 最低。但我们在报告下面还会写一行字如果业务量达不到一定规模选 C 的绝对成本优势可能不足以覆盖团队切换 SDK、更新配置文件、重写部分适配逻辑的成本。也就是说最终决策还要考虑迁移成本不能完全只看 cost-per-success。8. 从评测到长期监控一些个人心得做模型选型评测这几年我有一个很深的体会指标本身不会替你决策但它能帮你把模糊的争论变成清晰的对比。以前团队里争论“A 模型效果好B 模型便宜”永远吵不出结果因为比较维度不在一个平面上。自从大家都用 cost-per-success 说话讨论就变得非常高效——每个模型的优劣变成了可量化的数值争议自然就少了。还有一个实用的技巧是每次评测把原始结果存一份快照包括模型版本号、评测脚本版本、prompt 版本号。因为同样的模型今天和三个月后的版本可能完全不同。如果没有这些快照机器上只会留下“当时跑过一次结果找不到了”的尴尬记录。我在模拟项目 X 里吃过这个亏后来养成了把评测元信息写进结果的表头或文件名的习惯。最后再分享一个小建议不要一开始就追求完美的评测体系。第一次做评测哪怕只拿 100 条数据、用简单的“JSON 可解析”作为成功标准先跑通整个流程。跑通之后再逐步增加对抗样本、细化评分规则、加入人工复核成本。评测体系的完善是迭代出来的不是一蹴而就的。只要 cost-per-success 这个核心指标能从数字上反映出模型之间的真实差距这个体系就已经在为你创造价值了。