用 cost-per-success 做模型选型评测

用 cost-per-success 做模型选型评测

一、Benchmark 为什么越来越不够用

做模型选型时，我们习惯性打开榜单：MMLU、GPQA、LiveBench、Arena 分数高谁就赢。但落到真实业务里，这套打法经常翻车。原因至少有三，而且每一个都和钱直接相关。

第一，基准是静态的，业务是动态的。榜单上的题固定不变，模型厂商会针对它们反复优化，分数自然越刷越高；而你生产环境里的工单、你用户的提问、你内部的合同文本，从来不在任何公开榜上。用一个被厂商「练过」的题集来选「你没练过」的场景，结论天然失真。

第二，基准只报「能力」不报「成本」。一个九十五分的旗舰模型，单价可能是八十分模型的好几倍甚至十倍。如果你的任务其实八十分就够用，硬上旗舰就是纯浪费。更关键的是，基准不报「稳定性」------平均分高，不代表每条都高，某些长尾请求可能直接失败，而失败一次对你就是一次客诉、一次工单升级。

第三，基准不报「时延」和「可控性」。有些场景慢两秒比贵两块钱更致命，但这两者都不是 benchmark 的衡量对象。我见过团队按榜单选了最强模型，上线后却发现 p99 时延超标、成本失控，最后又悄悄切回便宜模型，白折腾一轮。

举个真实的例子：某团队按公开榜单选了当时排名第一的模型做工单分类，榜单准确率标着百分之九十二，上线后实测只有百分之七十八。原因很简单，榜单用的是干净短句，而真实工单夹杂口语、错别字和超长上下文，模型直接破防。这就是典型的「榜上强」不等于「活好干」------你不该为一道跟你业务无关的题付溢价。

所以业内开始换一把尺子：cost-per-success（每次成功成本）。它能把「能力、价格、稳定性」拧成一个数字，直接回答老板最关心的问题------「这个模型，干完这批活，到底花多少钱」。本文给你一套可落地的评测框架和脚本，以及一组可以直接抄的踩坑清单。

二、cost-per-success 到底是什么

定义很朴素，朴素到很多人一开始会忽略它的威力：

cost_per_success = 总花费 / 成功次数
成功 = 模型输出满足你定义的「通过标准」

举一个具体的例子。假设你要跑一千条客服意图分类任务：旗舰模型每条零点零一元、成功率百分之九十九，那每次成功成本约零点零一零一元；经济模型每条零点零零一元、成功率百分之九十，每次成功成本约零点零一一元------后者便宜近十倍，尽管榜单分数更低。Hugging Face 在 2026 年 10 月的实测也给出类似结论：按「每次成功成本」算，部分低价模型的性价比反而超过高价旗舰（例如某低价模型零点一二七美元一次成功，某旗舰零点二七六美元一次成功但 pass@1 仅百分之六十七）。这正是 benchmark 看不到的维度，因为 benchmark 只在乎「对了几题」，不在乎「每对一题花了多少」。

关键在「成功」的定义必须来自你的业务，而不是第三方题库。比如分类任务的成功等于命中标准标签且无格式错误；代码任务的成功等于单元测试通过；摘要任务的成功等于人工或强模型打分达到某阈值。定义不同，同一模型的 cost-per-success 可以差出好几倍，所以这一步不能偷懒。

三、先定义你的「成功标准」

没有标准，cost-per-success 就是空谈。给三类常见任务各举一个可落地的标准：

• 分类 / 抽取 ：输出必须能被 json.loads 解析，且关键字段值在白名单内。比如意图分类输出 {"intent":"refund"}，refund 必须在你预定义的意图集合里，多一个少一个都不算过。
• 代码生成：生成的代码能过你给定的 pytest 用例。抛异常或断言不过即不成功，不能只看「看起来像代码」。
• 开放问答：用一个强模型做裁判（LLM-as-judge），按 rubric 给分，达到四分及以上才算成功。注意裁判模型本身也要计入成本，否则会低估经济模型（它更常需要复核）。

把「成功标准」写成一个纯函数 is_success(prompt, output) -> bool，后面所有统计都依赖它，避免主观摇摆。这个函数越客观，你的选型结论越能服人。

四、可复现评测脚本

下面这个脚本对接 OpenAI 兼容接口，跑多个模型、算成功率与每次成功成本。直接抄：

import json, time, os
from openai import OpenAI

# 你的任务集：每条是 (输入, 期望通过判定)
TASKS = json.load(open("tasks.json"))  # [{"prompt": "...", "gold": "refund"}, ...]

# 候选模型与单价（每千输入/输出 token 美元，按你的实际账单填）
MODELS = {
    "economy": {"name": "econ-model", "in": 0.01, "out": 0.03},
    "flagship": {"name": "flag-model", "in": 0.10, "out": 0.30},
}
client = OpenAI(base_url="https://api.yours.com/v1", api_key=os.environ["KEY"])

def is_success(prompt, output, gold):
    # 分类任务：输出必须是合法 JSON 且 intent==gold
    try:
        obj = json.loads(output)
        return obj.get("intent") == gold
    except Exception:
        return False

def run(model_key):
    cfg = MODELS[model_key]
    cost, ok, n = 0.0, 0, 0
    for t in TASKS:
        r = client.chat.completions.create(
            model=cfg["name"],
            messages=[{"role":"user","content": t["prompt"]}],
            temperature=0, max_tokens=256,
        )
        usage = r.usage
        cost += usage.prompt_tokens/1000*cfg["in"] + usage.completion_tokens/1000*cfg["out"]
        n += 1
        if is_success(t["prompt"], r.choices[0].message.content, t["gold"]):
            ok += 1
    rate = ok / n
    cps = cost / ok if ok else float("inf")
    return {"model": model_key, "n": n, "success_rate": round(rate,4),
            "total_cost": round(cost,4), "cost_per_success": round(cps,6)}

for k in MODELS:
    print(run(k))

跑完你会得到类似：

{'model':'economy','success_rate':0.90,'cost_per_success':0.0011}
{'model':'flagship','success_rate':0.99,'cost_per_success':0.0101}

结论一目了然：如果百分之九十成功率对你的业务够用，经济模型每次成功便宜近十倍；只有长尾场景才值得切旗舰。这种账，榜单永远算不出来。

五、把评测接进 CI：每次发版自动跑

光跑一次不够，选型应该是持续动作。建议把上面的脚本接进你的 CI：每次模型供应商调价、或你切换底座时，自动跑一遍固定任务集，把 cost-per-success 写进看板。这样你能第一时间发现「某模型悄咪咪涨价但分数没变」或「新版本分数涨了但成功率掉了」。我们团队的做法是维护一份永远不删的 tasks.json，三百条覆盖核心场景，每周自动跑，历史曲线直接挂内部大盘。三个月下来，省下的冤枉钱远超搭这套流程的成本。

六、进阶：给「成功」加置信区间

单次跑一百条可能有运气成分。建议每模型跑 ≥ 三百条 并做 bootstrap 置信区间，避免拿噪声当结论。比如用两百次重采样算 cost-per-success 的百分之九十五区间，若两个模型区间重叠严重，就别急着下「谁更省」的结论，先加样本量。

另外要固定「匹配成本」：不同模型 prompt 写法不同会影响成功率，评测时用同一套 prompt 模板，只换模型名，否则比的是「prompt 工程」不是「模型本身」。比如都加一句「只输出 JSON，不要解释」，再比结果才公平。还有缓存：开了 prompt 缓存的模型首 token 贵、后续便宜，评测里若大量重复前缀，成本结构会失真，建议关缓存或单独报。

七、工程取舍

• 裁判模型要不要算钱：LLM-as-judge 模式里，裁判调用也是成本，必须并进分母，否则会低估经济模型（它更常需要复核）。
• 成功率阈值卡哪：卡太严（≥5/5）会抬高 cost-per-success，卡太松（≥3/5）又放过劣质输出。比如客服场景错一次就客诉，阈值就要定高。
• 缓存命中要单列：前缀缓存会扭曲单条成本，必须单独统计或关闭后评测。
• 别只看均值：长尾任务里均值掩盖方差，要同时报 P90 成本与最低成功率，防止「平均很省、偶尔暴贵」。
• 任务集要随业务长肉：三个月前的任务集代表不了现在的流量，定期补真实样本，否则评测会慢慢失真。

八、踩坑清单

1. 拿榜单分当代替评测：别人的题不等于你的活，上线才发现旗舰并不值那个价。
2. 成功标准写成「包含某关键词」：太松，把明显错的回答也判过，cost-per-success 虚低。
3. 单价写错数量级：把「每百万 token」当「每千 token」填，成本全错位。比如零点零一每百万写成零点零一每千，算出贵一千倍。
4. 样本量太小：只跑二十条就下结论，区间宽到没意义，纯属误导自己。
5. 混用不同 prompt：A 模型加了 few-shot、B 模型没加，比出来的差异是工程不是模型。
6. 忘了把裁判成本计入分母：只看生成成本，结果经济模型看似更省，实际加上复核反而更贵。
7. 任务集一成不变：半年不更新，评测变成自娱自乐，选型结论早就过时。

九、辩证：cost-per-success 也有盲区

它虽比 benchmark 贴地，但不是终极真理。第一，成功标准本身有偏差 ：你定义的「通过」未必等于「用户满意」，标准定错，省下的钱可能换来差评。第二，它不衡量 latency ：某些场景（实时对话）慢两秒比贵两块钱更致命，而 cost-per-success 完全不反映时延。第三，长期能力演进被忽略 ：今天便宜的经济模型，下个版本可能被反超，选型要定期重评而非一选定终身。第四，它假设成功可程序化判定 ，但很多创意类、开放式任务根本没法写成 is_success，这类只能靠人工抽檢兜底。所以实务里我建议三张表一起看：cost-per-success（省钱）、P90 时延（体验）、成功率分布（质量），按业务权重加权，而不是单看一把尺子。

九之一、一份可直接用的选型报告模板

当你跑完评测，真正要拿去说服技术负责人或老板时，别只甩一个数字。我们在内部用一份固定模板，三栏对照，谁都能一眼看懂：

第一栏写「场景与成功标准」：这条任务是什么、成功怎么判定、样本量多少。没人会为一个没说清标准的数买单，先讲清标准，后面的数字才有意义。

第二栏写「三个模型的 cost-per-success 与成功率」：用表格列出经济模型、主力模型、旗舰模型各自的成功率、总花费、每次成功成本，并标注置信区间。重点标出「贵多少倍」和「成功率差几个点」，让决策者自己权衡，而不是你替他拍板。

第三栏写「推荐与理由」：基于你的业务对错误的容忍度，给出明确建议------比如「日常流量走经济模型，置信度低于阈值的长尾请求自动升级旗舰」。这份报告跑一次可以复用一个月，每月更新一次任务集即可，边际成本极低。

把选型从「我觉得」变成「数说了算」，是这套方法最大的价值。它也让后续的成本复盘有了抓手：下个季度回头看，你能清楚知道自己到底省了多少、又在哪里多花了。这种可审计、可复现的选型，远比一次性的榜单截图值钱。

九之二、不要掉进「平均成功成本」的陷阱

cost-per-success 是个平均值，平均值最会骗人。假设你的任务里百分之九十是简单样本、百分之十是硬骨头，经济模型在简单样本上成功率百分之百、硬骨头上只有百分之五十，旗舰在两个区间都是百分之九十九。算总账经济模型可能更便宜，但那百分之十的硬骨头如果恰恰是你的高价值客户，省下的钱可能还不够赔一次事故。所以报告里一定要把「分区间的成功率」拆出来看，不能只看一条汇总线。

十、动手题

1. 你的业务里「一次成功」该怎么定义？
2. 如果经济模型成功率百分之九十、旗舰百分之九十九，但旗舰贵十倍，你会怎么切流量？
3. 你现在的模型选型还在看 benchmark 吗？

欢迎在评论区贴一下你的通过标准、聊聊你踩过的榜单选型坑。

数据与事件来源：

• 来源：Hugging Face 2026-10 模型成本分析（cost-per-success：低价模型 0.127 美元/成功，旗舰 0.276 美元/成功、pass@1 67%）
• 来源：Artificial Analysis Coding Agent Index 榜单（2026-10-02，各模型单任务中位成本披露）
• 来源：OpenAI 兼容接口 chat.completions 用量字段（prompt_tokens / completion_tokens）计费口径说明