挑大模型的新标准：从跑分到 Token ROI
9 月前后一周之内七家厂商同时发新模型，榜单还没看完价格已经变了。比拼单点能力之外，“每百万 Token 花出去能换来多少实际产出”正在成为选型的第一指标。
今年我在一个项目里把大模型调用成本砍掉了将近七成，效果却没有明显下降。同事问我是不是换了什么神秘模型，答案很无聊：我只是停止追跑分，开始算账。过去选模型，大家盯着公开榜单的某一列数字，谁的分数高就上谁。但当你真把模型塞进生产流水线，会发现那些分数和你每天烧掉的钱、以及用户实际拿到的结果，常常对不上号。
这背后的落差，不是榜单造假，而是榜单和你的真实任务之间隔着三层失真：题目不一样、评测口径不一样、数据甚至可能已经进了训练集。公开跑分是一张参考答案，不是你钱包的预言。我花过不少冤枉钱追所谓的"最强模型"，最后发现它在我的具体任务上既不稳也不省，那次教训让我彻底换了选型思路。
这篇文章想讲清一件事：2026 年挑模型，核心指标不该是"它有多强"，而是"单位成本下它把我的活做成了什么样"。我把这个指标叫 Token ROI，下面展开。
这篇文章想讲清一件事：2026 年挑模型，核心指标不该是"它有多强"，而是"单位成本下它把我的活做成了什么样"。我把这个指标叫 Token ROI，下面展开。在讲方法前先泼盆冷水：ROI 思维不性感，它没有"换上最强模型"那种爽感，但它能让你的项目活得更久。很多 AI 应用死得不是因为技术差，而是因为账单先一步追上收入。把选型从玄学变成算账，是这一年我给团队带来最实际的改变。
公开跑分为什么失灵
先说刷榜。榜单驱动优化的世界里，模型方有充分动机针对评测集做定向调优，哪怕只是把评测题的变体塞进后训练数据。这种"教学大纲式"的优化，能让分数涨得漂亮，却不一定提升你在真实业务里的体感。我见过一个模型在某一硬核推理榜上领先，结果给它写内部工单分类，输出格式乱得一塌糊涂。榜单一时爽，上线火葬场。
再说任务错配。多数榜单是综合分，混合了数学、代码、常识、长文理解。但你的应用可能只用到其中一块。一个综合分中等、但代码能力强的模型，对"自动修 bug"这个场景可能远比综合分更高的通用模型好用。拿综合分选模型，就像用"全能运动员总分"去挑百米选手，总分高的人百米未必快。我的建议是，看榜单也要看分项，且只信和你任务同构的那几项。
最隐蔽的是数据污染。热门评测集被反复训练、反复泄漏，模型可能在训练阶段就"见过"原题。这会让分数虚高，而你线上遇到的全是没见过的题。污染越严重的榜单，越不能作为选型依据。一个判断技巧：如果某个模型在公开榜高得反常、但在你拿内部真实数据做的盲测里表现平庸，污染嫌疑就很大。别被那串漂亮数字带节奏。
结论很直白：榜单告诉你"这个模型理论上能做什么"，但从不告诉你"在你这道具体题上，它每花一块钱能做成什么样"。后者才是 ROI 问题，而 ROI 只能在你自己的数据上测出来。
Token ROI 到底是什么
我给团队定义了一个朴素的指标：Token ROI = 单位成本买到的任务完成质量。它不关心绝对值多高，只关心"花同样的钱，谁把活干得更符合预期"。这个公式把"强"和"贵"两个维度绑成一个可以排序的数。
具体拆解，成本不只有输出 token。一次调用真实账单通常包含：输入 token（你的 prompt 和上下文）、输出 token（模型回复）、以及可能的缓存命中折扣、批量折扣。质量则要用"这件事做对了吗"来衡量，而不是"模型答得流畅吗"。流畅且错误，ROI 是负的，不仅白花钱，还可能在下游制造需要人工返工的脏数据。
一个常见误区是只比单价。某模型每百万输出 token 便宜一半，但它需要三倍轮次才能把格式对齐，还要你额外加校验重试。算上失败重试和错误处理的人力，便宜模型反而更贵。ROI 视角逼你把"隐性成本"也纳入账本。我见过团队因为贪便宜切到小模型，结果质检人力翻倍，总账反而亏了。
另一个误区是只看"一次成功率"却忽略"一次成功的成本结构"。有些模型一次成功率高，但因为它输出又长又啰嗦，token 消耗大，单位成功成本未必低。所以我算 ROI 时，分母是"一次成功对应的全部 token 成本"，分子是"成功质量分"，两者相除才有可比性。
我给自己定的口诀：比价格之前，先比"一次成功率"。一次成功比三次勉强成功便宜得多，哪怕单次单价高。这听起来反直觉，但落到账单上几乎总是成立。
按任务分层选模型
最有效的省钱手段，是别用同一把刀切所有菜。我把流水线拆成三档，分别匹配不同价位模型。这套思路我称之为"分层路由"，也是目前最主流的降本架构。
- 草稿档：做最机械的活，比如初步分类、抽取、改写、生成草拟代码。这一档对精度容忍度高，用便宜的小模型或廉价 API 即可，错了后面还有人审。它的特点是量大、单价敏感，哪怕单条质量一般，摊薄下来也极划算。
- 主体档：承担真正影响产出的核心生成，比如写最终回复、复杂代码、长文摘要。这一档要质量，用主力中大模型，但仍在性价比区间内挑，不盲目上最贵旗舰。它占总调用量的主体，是成本和质量的平衡点。
- 评审档：对主体档的输出做校验、挑错、打分。这一档特别适合用能力强但调用量小的旗舰模型，因为它只在关键节点出手，频次低、单价高也烧不了多少。它像一道质检闸，把主体档的失误拦在出厂前。
这套分层最妙的地方在于，贵模型的总开销被压得很低，因为它只用在"少而关键"的地方。我一个文档处理管线，草稿用 8B 本地模型，主体用中等云模型，评审用旗舰，三者组合的成本，比全程旗舰低了约六成，而最终质量由评审档兜底，反而更稳。这就是分层路由的经济学本质：让贵的模型做它最值钱的少量工作。
# 分层路由的极简骨架
def route(task):
if task.kind in ("classify", "extract", "draft_rewrite"):
return "draft_model" # 草稿档：便宜、量大
if task.kind in ("final_reply", "codegen", "summary"):
return "main_model" # 主体档：主力、平衡
if task.kind in ("review", "score", "verify"):
return "judge_model" # 评审档：强但少用
return "main_model"落地时有个细节：草稿档的输出最好带一个"置信度"或"不确定"标签，低置信时直接转主体档，别让草稿的错误流向下游。这样分层不是硬切，而是带兜底软切换，体验更平滑。
缓存与批量请求的经济学
两笔常被忽略的省钱账，是缓存和批量。它们不挑模型，只要你的流量有结构，就能直接见效，是性价比最高的优化。
缓存（prompt caching）的意思是：如果你的系统 prompt 或长上下文在多次请求间不变，把它标记为可缓存，模型方只对首次计费，后续命中只收极低费用。对固定系统提示、固定知识库前缀的场景，缓存能砍掉一大截输入成本。我有个客服机器人，系统提示占了输入的七成，开启缓存后输入账单直接腰斩。注意缓存有最小长度门槛和 TTL，太长太短都浪费，需要按你的提示结构调。
批量请求（batch API）则是把请求攒成批，用异步、非实时（如 24 小时返回）的低价通道处理。单价常常打到五到六折。适合那些"不要求秒回"的任务：日志分析、离线摘要、批量标注、夜间数据清洗。把这些从实时通道挪到批通道，是纯利润。我一个数据团队把每日十万条离线摘要全迁到批通道，月度账单降了四成，而业务方本来就不关心这几小时延迟。
一个判断标准：用户愿不愿意等？愿意等且量大的，全丢批处理；不愿等的，才走实时。很多人把两者混在一起，白白多付了钱。缓存和批量是"架构层省钱"，不需要换模型、不损失质量，应该作为上线必做项，而不是可选项。
自建小型选型实验
不想被榜单牵着走，就自己搭一个迷你选型实验。成本不高，但结论只对你的场景有效，比公开跑分有用得多。我每个新模型上线前都过这道关。
第一步，建固定题集。从你真实流量里抽样（注意脱敏）五十到两百道代表性任务，覆盖你的高频类型和难点类型。题集一旦定下就冻结，后续所有模型都用它比，才有可比性。题集质量决定实验质量：如果题集里全是简单题，实验结果会高估小模型；如果全是难题，又会低估。我会特意混入约两成"边缘难例"，模拟真实长尾。
第二步，盲评打分。把不同模型的输出打乱、隐去来源，让评审人（人或强模型）按同一 rubric 打分，比如"格式正确、内容准确、无需返工"三档。盲评是为了避免"听说这是旗舰就给高分"的偏见。我常用 1 到 5 分制，并要求评审人写一句理由，防止随手打分。
第三步，算账。把平均分除以单位成本，得到你的 ROI 排序。你会发现它和公开榜经常不一致，而这不一致，正是你该赚钱的地方。下面是成本估算示例，注意数字都是示意，不是实测跑分，重点是方法。
# 成本与 ROI 估算示例（数字为示意，非实测跑分）
models = [
# 名称, 每百万输出token单价(元), 平均一次成功率, 平均输出token
("小模型-本地", 0.0, 0.72, 800),
("中模型-API", 4.0, 0.91, 1100),
("旗舰-API", 18.0, 0.97, 1300),
]
def cost_per_success(name, price, success, tokens_out):
# 单次成本 = 单价 * 输出token / 1e6
# 折算到"一次成功"的成本 = 单次成本 / 成功率
single = price * tokens_out / 1_000_000
return name, round(single / success, 4)
for m in models:
name, c = cost_per_success(*m)
print(f"{name:12s} 每次成功成本 ≈ {c} 元")跑出来往往是大模型单次便宜但单价高、小模型单价低但失败重试拉高隐性成本。真正该选谁，要看你更在意"单次账单"还是"端到端把事做成"。我的经验是，对可重试的机械任务用小模型摊薄，对不可重试的关键任务用高成功率模型，别被表面单价骗了。ROI 实验的价值，就是把这个直觉变成你自己的数字，而不是别人的榜单。
隐性成本：重试、校验与人工兜底
前面提过"隐性成本"，这里单独展开，因为它是最容易被账单掩盖的坑。很多人算 ROI 只算了 API 单价，没算三笔隐性账。
第一笔是重试账。一个一次成功率 80% 的模型，平均要调 1.25 次才成功；成功率 60% 的，平均要 1.67 次。如果失败还要走更复杂的兜底逻辑，成本再加。我有个抽取任务，小模型成功率 65%，每次失败还要调大模型兜底，算总账比直接用中模型还贵 12%。所以"便宜模型"的便宜，要在"含兜底的总调用"口径下才算数。
第二笔是校验账。输出格式不规整，你就得加解析、加校验、加清洗。这些代码和算力都是成本，而且会随模型换版反复修。我见过团队为了用便宜模型，写了一套三百行的容错解析，维护它的工程师工时远超省下的 API 费。格式越自由的任务，校验账越重；用强约束输出（比如强制 JSON schema）能压这笔账。
第三笔是人工兜底账。最贵的是人。当模型输出流到人工复核环节，每条人工处理都要算钱。一个看似省了 API 费却把 20% 流量推给人工复核的方案，往往比"稍贵但一次成功"的方案总成本高得多。我把人工复核费率也写进 ROI 公式，凡是会显著推高人工量的模型，一律降级。
# 把隐性成本纳入 ROI 的更完整估算
def true_cost(price, success, tokens, retry_overhead=1.0,
human_review_rate=0.0, human_review_ratio=0.0):
# 含重试的单次成本
per_call = price * tokens / 1_000_000 * retry_overhead / success
# 叠加人工复核成本（按触发比例计费）
per_call += human_review_rate * human_review_ratio
return per_call
# 示例：小模型看似单价 0，但 35% 需人工复核，反而可能比中模型贵
print(true_cost(0.0, 0.65, 800, human_review_rate=0.5, human_review_ratio=0.35))算清这三笔账，你会发现很多"便宜选型"的幻觉破了。ROI 必须是"端到端把事做成的总成本"，而不是"单次调用单价"。这是我从多次翻车里学到的最贵的一课。
模型换代的 ROI 复盘节奏
模型市场迭代极快，今年香的模型明年可能就被超越。所以选型不是一次决策，而是周期复盘。我定了一个季度复盘节奏，成本很低但能防止"用旧账本做新决定"。
每季度初，我重跑一遍固定题集盲评，把当前在用的几个模型和新冒出来的候选都测一遍，更新 ROI 排序。如果某个候选在"关键任务"上 ROI 超过现役模型 15% 以上，就启动小规模灰度。灰度期间新旧模型并行跑，用真实流量对比最终质量与成本，确认无回归再全量切换。这样既不漏掉更好的模型，也不会因为冲动切换翻车。
复盘时我特别警惕"锚定效应"：别因为已经在一个模型上攒了很多 prompt 工程和缓存，就拒绝换更优的。prompt 是可迁移的资产，缓存前缀也可以重写。切换成本通常是一次性的，而长期 ROI 差是持续的，账要算长线。我去年从模型 A 切到模型 B，重写了两天缓存前缀和少量提示，之后每季度省下的钱远超这两天投入。
选模型像管投资组合，不是买定离手。定期再平衡，才能让你的 Token 预算始终停在效率前沿。懒得复盘的人，最终都在替模型的旧定价买单。
一个真实迁移的叙述
讲个具体例子，让上面的方法落地。我们有一个"用户消息意图识别"服务，原来全程用旗舰 API，每月模型费约一万二。我按 ROI 思路重做：先抽样两百条真实消息建题集，盲评发现这类任务其实是浅层分类，旗舰和中模型准确率只差 1.3 个百分点，但单价差四倍。
于是我把草稿和分类档切到本地 14B，只保留评审档用旗舰做抽检（每天几百条）。上线后监控"每次成功成本"，从原来的约 0.012 元降到约 0.004 元，月度费用降到四千出头，而意图识别准确率在线上 A/B 里无显著差异。省下的八千块，我投到了更难摘要任务的旗舰调用上，整体体验反而更好。
这个案例的关键不是"换小模型"，而是"先测量、再分层、最后用数据确认无回归"。同理，我也试过把一个"复杂合规摘要"任务从小模型切回旗舰，因为题集盲评显示小模型在此任务退化 18%，省的钱不够返工填坑。ROI 方法既告诉我该换小的地方，也告诉我不该省的地方，这比盲信"越小越省"或"越大越好"都靠谱。
本地模型与云模型的 ROI 分水岭
分层路由里，草稿档常常落到本地模型，但这里有个容易被算漏的变量：本地模型并不是"免费"的，它的真实成本藏在显卡折旧、电力和运维工时里。我见过团队为了省 API 费，把全部草稿档搬回本地 14B，结果单机显存打满，并发一高就排队，最终用户体感延迟暴涨，反而推高了对实时性敏感的流失率。
我的判断很朴素：本地模型划算的前提，是你有稳定且足够的推理算力，且任务对延迟不敏感。如果你的流量是脉冲式的，白天高峰、夜间空闲，本地算力在非高峰时段就是纯浪费；而云 API 的弹性扩缩，反而更贴合"用多少付多少"的账本逻辑。所以本地还是云，从来不是信仰问题，而是把"隐性算力成本"也写进 ROI 公式之后的一道算术题。
我现在的做法是对草稿档做双轨：默认走云上廉价模型，本地算力作为高峰兜底，两者 ROI 定期比一比，谁合算谁上。这样既吃到云弹性的便宜，又不在高峰期被云账单反噬。
把本地显卡当成一笔"已经付过的沉没成本"而不计入账本，是 ROI 计算里最常见的自欺。算全，才叫算账。
供应商锁定与多模型抽象
ROI 选型还有一个容易被忽略的维度：别把架构绑死在单个模型上。模型市场变太快，今天最划算的，明年可能涨价或被超越。如果我的代码里到处硬编码某个模型的调用细节，切换成本会高到舍不得动，ROI 优化也就僵住了。
我的做法是做一层模型抽象：定义统一的"补全/对话"接口，把路由、缓存、批处理、重试都收在这层后面，业务代码只调接口、不感知具体模型。这样换模型只是改配置，不动业务。抽象层还顺手统一了错误处理和计费埋点，让 ROI 数据自动归集。代价是初期多写几百行胶水代码，但换来的是"随时再平衡"的自由，长期极划算。
# 统一的模型抽象骨架（伪代码）
class ModelGateway:
def __init__(self, routes):
self.routes = routes # 任务类型 -> 模型名
def complete(self, task, **kw):
model = self.routes[task.kind]
# 统一走缓存/批处理/重试/计费埋点
return self._call(model, task, **kw)
# 业务侧只关心"这类任务该找谁"，不关心是谁在跑
gw = ModelGateway(route_table)
gw.complete(task) # 切换模型只改 route_table此外，我会刻意保留一个"备选供应商"。主力用 A，备选接好 B 的适配，平时不流量但定期冒烟。这样 A 涨价或故障时，我能当天切过去，不至于被单一供应商卡脖子。多模型抽象 + 备选供应商，是我对"ROI 可持续性"的保险。
用 ROI 说服团队与老板
选型往往是团队决策，光自己算清账不够，还得把这账讲给别人听。我摸索出一套汇报方式，命中率很高。
第一，永远用"端到端成本"而不是"单价"说话。老板问"为什么不用更便宜的小模型"，我回答"含重试和人工兜底，它端到端反而贵 12%"，比说"它不准"有说服力得多。钱的语言最通用。
第二，用 A/B 数据替代主观判断。我上线任何模型变更都做灰度对照，拿"成本降 X%、质量无显著回归"的结论去汇报，而不是"我觉得旗舰更好"。数据让争论结束。
第三，把风险量化进账本。我会附一句"若选错模型，最坏情况是人工复核量翻倍，月增人力约 Y 元"，让决策者看到下界。老板要的不是你永远对，而是你知道错了会花多少、能不能兜住。
选型能力的一半是算账，另一半是把账讲成别人愿意签字的样子。ROI 思维最妙的地方在于，它把"技术偏好"翻译成了"商业语言"，让模型选择从玄学变成可辩论、可追责的工程决策。
常见的 ROI 误区清单
把几年里我见过的、也亲自犯过的 ROI 误区列成一张清单，方便你自查。每一条都对应一笔悄悄漏掉的钱。
- 误区一：只比单价。前面讲了，含重试和人工兜底的端到端成本才是真账。单价低不等于总账低。
- 误区二：用综合榜选垂直任务。你只用到代码能力，却按综合分选，往往花冤枉钱。看分项、看同构任务。
- 误区三：忽视数据污染。榜上异常高的分，可能是原题见过了。用你自己的题集盲测来破幻象。
- 误区四：把缓存和批处理当可选项。这两笔常比换模型更省，且零质量损失，是稳赚优化，别漏。
- 误区五：一次选型定终身。模型迭代快，不季度复盘就会一直替旧定价买单。定期再平衡。
- 误区六：用成功率掩盖格式成本。一次成功但输出乱，你要加解析校验，隐性账很重。强约束输出能压。
- 误区七：人工兜底不算钱。把流量推给人工复核最贵。任何会推高人工量的模型都要降级。
- 误区八：锚定迁移成本不敢换。prompt 和缓存可迁移，切换是一次性的，长期 ROI 差是持续的。
这张清单我贴在选型文档首页。每次有人提议换模型，先逐条过一遍，八条里踩中三条以上的，基本就是伪省钱。ROI 思维难在"算全"，清单的价值就是逼你把隐性项一个个摆上桌。
把 ROI 做成可观测的指标
选型不是一次性拍板，而是持续运营，那就得有可观测性。我给每个模型调用埋了三类数据：成本（token 折算费用）、质量（最终人工或评审打分）、成功率（一次成功比例）。每天聚合出"每模型每任务的每次成功成本"，画成趋势线。这条线比月度总额诚实得多。
为什么要可观测？因为模型方会调价、会换版、会悄悄改行为。我遇到过某模型一次无通知升级后，在我们任务上成功率从 91% 掉到 84%，ROI 曲线当场下拐，监控立刻报警，我当周就切了备选。如果没有这条线，这个劣化要等月底账单+客诉才暴露，损失已经造成。可观测的 ROI 监控，是选型纪律的"仪表盘"。
# ROI 监控聚合的极简示意
def daily_roi_report(records):
by_model = {}
for r in records: # r: {model, task, cost, success, quality}
key = (r["model"], r["task"])
by_model.setdefault(key, []).append(r)
for k, rs in by_model.items():
cost = sum(r["cost"] for r in rs)
ok = sum(1 for r in rs if r["success"])
quality = sum(r["quality"] for r in rs) / len(rs)
roi = quality / (cost / max(ok, 1)) # 质量 / 每次成功成本
print(k, "ROI=", round(roi, 3))我还会给 ROI 线下设阈值告警：某模型某任务 ROI 连续三天低于基线 10%，自动通知我复核。这套机制不复杂，却让"选型"从一年几次的大决策，变成了每天都在发生的微调优。省下的钱是持续的，而不是一次性的。
我的选型纪律
把上面的想法收敛成几条我自己的纪律，供你参考或反驳。这些不是银弹，是我踩坑后的经验结绳。
第一，榜单只用于"初筛候选池"，不用于"终选决策"。进池看分数，出池看自测 ROI。任何模型要进生产，必须先过我的固定题集盲评，没有这步，再好听的宣传都不进。
第二，分层路由是默认架构，不允许"全场用一个模型"的偷懒。贵模型天生就该被用在刀刃上、且用量受控。我会在代码里写死路由规则，并监控各档调用占比，防止某天有人图省事把全部流量打到旗舰上。
第三，缓存和批处理是上线 checklist 的必选项。两者叠加常常比换模型更省钱，且不损质量，是稳赚不赔的优化。
第四，建立成本看板，按"每次成功成本"而非"月度总额"监控。总额会被流量波动掩盖问题，而单位成本能暴露"某模型悄悄变贵或变菜"。我每周扫一眼各模型的 ROI 曲线，哪条掉下去就重新评估。
Token ROI 不是为了让你抠门到牺牲质量，是让你知道每一分钱花在了哪里。当你开始用 ROI 而不是跑分做决策，你会发现，最好的模型不一定是分数最高的那个，而是那个在你的账本上，把活干漂亮又最不烧钱的组合。账算清楚了，选型就不再是一场信仰，而是一门生意。2026 年做 AI 应用，能不能活得好，往往就藏在这笔账里。
这套方法我用了一年多，最大的收获是不再被榜单牵着走。每次有新模型发布，我不再焦虑"是不是又落后了"，而是淡定地丢进题集测一遍 ROI，数据说话。这种踏实感，比省下的预算还珍贵。如果你现在还在追着跑分换模型，不妨明天就抽两小时，建一份属于你自己的固定题集，那一小步，会让你从此看模型的眼光完全不同。选型这件事，终究要从"别人说它强"变成"我的账本说它值"。