8.0
热点
AI SCORE
编程提效2026-08-13 01:00
推理模型性价比曲线：如何算清每分正确率成本
dev.to · AI#推理模型#成本优化#评测
Editor brief · 编辑速览
推理模型每正确回答的成本公式为 cost_per_correct = (in_tokens * rate + out_tokens * rate) / accuracy，关键在于用 eval 集实测 accuracy 而非对比列表价格。
成本曲线：算出每个Dollar的准确率
推理模型的单位准确率成本曲线并不存在通用解，任何给你画出一条曲线的人，都是在拿一个不属于你的任务举例。真正可以泛化的是生成这条曲线的模型。下面把它分享出来，每个输入都标了名字，但你填不进去的值一个也没填。
看每次调用成本，推理模型显得毫无道理——比快模型贵五到二十倍，答案看起来长度差不多。真正决定一切的指标是每次正确回答的成本，因为错误答案没有价值，而你依然为此付了钱：
cost_per_correct = (in_tokens * in_rate + out_tokens * out_rate) / accuracy
其中 out_tokens 包含隐藏的推理 token，accuracy 用你自己的
eval 集和你自己的 grader 来测量。
除以 accuracy 干完了所有工作。准确率 50% 时，每次有效回答的实际花费是双倍；到了 90%，是 1.11 倍。某个 tier 贵了三倍，但准确率从 0.45 提升到 0.88，每次正确回答的实际成本是 1.53 倍，不是三倍——这个数字才是应该拿去给管预算的人看的。
前四个数字来自 harness 调优推理力度时得到的数据。第五个来自你的业务，拒绝估算它不会让它消失——只会让它变成隐式的，而且通常是错的。
下面的数字是说明性的占位符，不是任何真实模型的测量值。它们的作用是展示算术的结构；得出结论之前把每一个都替换成你自己的。
仅作说明 — 请代入你自己的测量值。
假设：in_rate 0.50 / Mtok，out_rate 2.00 / Mtok，in_tokens 1,200。
tier out_tok cost/call accuracy cost per correct
----------------------------------------------------------------
fast 300 0.0012 0.52 0.00231
low 1,100 0.0028 0.71 0.00394
medium 3,400 0.0074 0.83 0.00892
high 9,800 0.0202 0.86 0.02349
在这里，每次正确回答的成本随准确率上升而单调上涨。
基于这些假设，快模型是获得正确回答最便宜的方式——
这通常也是 V 很小时的一般结果。
如果你的表格出来之后长这样，每次正确回答的成本只是告诉了你该怎么做的前提——假设正确回答是唯一重要的事、错误的回答是免费的。但它们很少是免费的，这就是下一节要讲的内容。
在信任这张表之前，表格里还有两个调整项。如果你用了 prompt 缓存，缓存部分的实际输入费率会更低，而由于各 tier 的输入 token 是固定的，这会把比较稍微向低价端倾斜——缓存折扣作用于不区分 tier 的那部分。而且如果你的工作负载有任何部分符合批量定价资格，那个折扣会作用于你本来因为成本而会拒绝的 tier，偶尔会直接颠覆排名。这两个都值得查一下，因为它们是结构性的而非促销性的：它们改变哪一行胜出，而不只是改变胜出的幅度。
引入 V，即正确回答相对于错误回答的净价值，对于任何有后果的事情，比较就反转了。每次调用的期望价值是 accuracy × V − cost_per_call。用上面的说明性表格，fast tier 准确率 0.52，high tier 准确率 0.86，差了 0.34 的准确率和 0.019 的成本。所以当以下条件成立时，high tier 胜出：
0.34 * V > 0.019 => V > 0.056
盈亏平衡点在每个正确回答约六美分的价值处。
一般形式： V_breakeven = (cost_hi - cost_lo) / (acc_hi - acc_lo)
六美分。几乎所有需要人来看输出物的任务，这个门槛都差了两到三个数量级——客服回答、代码审查、合同条款。这就是整个成本争议的诚实总结：推理按 token 计价很贵，但相对于决策的价值几乎总是便宜的；除了高volume低价值的场景，在那些场景里它根本就是错误的工具。
这也就是路由 arguments 的正式版本。如果 V 在你的流量中各不相同——确实如此——那么最优 tier 也随之不同，每个请求各跑各的，这正是 router 实现的事情。
有一个应该算进 V 但几乎总被漏掉的成本：人工审核时间。如果错误回答在造成损害之前被人发现，错误的代价不是损害，而是审核——而审核无论回答对错都会发生。将准确率提升到可以省掉审核的程度，其价值远大于准确率本身，盈亏平衡计算在阈值两侧看起来完全不同。在你优化到这个阈值之前先算出你的阈值在哪里，因为增量准确率要么买到了那个阈值，要么几乎什么都买不到。
忘了隐藏 token 也要计费。按可见答案估算 out_tokens，你的数字会因为推理占比而错，推理占比通常在 80% 以上。从 usage object 里读，不要用字符串长度。
用均值成本代替偏态分布。Trace 长度有很长的右尾。基于均值的预测会低估流量变难的某个月，而"流量变难了"并不是罕见事件。
把准确率当作固定属性。它是模型、prompt、grader 和日期的综合属性。其中任何一个变了就重新跑一遍表格，尤其是模型更新之后——方向是不能保证的，overthinking 结果已经说明了这一点。
最后一个实践建议：评估本身也要花钱，四个 tier × 两百个例子是实实在在的账单。把它作为显性预算，而不是作为异常项目出现，并且把它当作月度节省对应的固定成本来对待。对于任何大到值得优化的负载，花一个下午和几十块currency跑一次评估，几天就能回本——而这件事永远不会发生的版本，几乎总是因为没人被允许花任何钱。
上面的表格需要每个 tier 的 token 计数和每个模型的费率放在一处，这是手工组装表格最别扭的部分。Multigrid 把推理 token 作为独立行项目按公布的模型费率计费，所以 out_tokens 和两个 rate 都来自同一条记录，而不是来自用两个来源对账的电子表格。