大模型测评一次多少钱

团队要跑一轮模型测评，老板问「一次多少钱」，你发现没人算得清：调用费只是其中一块，人工标注、脚本返工、重跑都吃钱。这篇把一次测评拆成几笔账，给一套自己就能填的估算框架，并告诉你什么情况下这套算法不适用。

老板问「跑一轮模型测评多少钱」，很多团队第一反应是「调用费嘛，几百块搞定」，结果真跑起来账单一拉，人工出题和评分的工时费比调用费高一大截。问题不在于贵，而在于没人提前把账拆开算。

这篇不讲玄学，给你一套能自己填的估算框架：钱花在哪几块、报价怎么给区间、哪些动作能压账，以及什么情况下这套算法直接不适用。所有单价类数字一律去站内页面看当时的，不要拍脑袋。

一次测评的钱由哪几块组成

先把一次测评拆成三笔账，任何一笔漏了，报价都会偏。第一笔是调用费，第二笔是人工，第三笔是固定开销。很多团队只算第一笔，报出去的数字自然只有实际的一半不到。

调用费

题目数 × 每题输入输出长度 × 重复采样次数，再乘模型单价；单价到 /official-api 和 /tools/model-cost-calculator 核对当期数字。

人工费

出题、写参考答案、人工打分或抽检的工时；人天单价通常比调用费高一个量级，最容易漏。

固定开销

测评框架搭建、脚本调试、失败重跑带来的额外调用；一般按调用费的一个固定比例预留，别按零算。

这里的关键判断是：如果题目是你自己原创、还要人工打分，那人工费一定是大头，调用费只是零头；如果题目来自公开集、评分纯脚本，那调用费才是主项。先判断自己属于哪种，再决定精力往哪放。

报价区间怎么估：三个变量定高低

报价不要给一个绝对数，要给「区间 + 前提条件」。因为下面三个变量任何一个动一下，总价就能差出好几倍。给老板的应该是一句「在某个口径下，大概是这个区间」。

• 变量一：题目规模和重跑次数。重跑一次就是一次完整调用成本，做三次就乘三，别只按首次算。
• 变量二：模型档位。同一批题换不同档的模型，总价差好几倍，去 /price-watch 看目标模型当期单价。
• 变量三：评分方式。纯脚本评分便宜，人工评分贵，模型互评介于中间，但要额外留复核成本。

把这张表填一遍，你就能给出一句像样的报价：「在自研题库、脚本评分、单次采样、目标档位全量跑的口径下，总成本大概是某个区间」。具体单价去站内页面核对当时的数字，别抄别人的旧数。

怎么把一次测评的账压下来

压成本不是砍质量，是把钱花在该花的地方。下面几个动作按顺序做，通常能省掉大部分重跑和人工返工的钱。

1. 先小样本试跑挑少量题目跑通题目和评分脚本，确认没问题再全量；验证标准是脚本能稳定复现同一批题的评分结果。
2. 脚本能评的不要人工过客观指标一律脚本评分，人工只花在分歧样本和抽检上，验证方式是抽检一致率达到你团队设定的门槛。
3. 弄懂计费口径再落流程批处理、缓存命中这些口径去 /ai-dict/category/basics 弄懂，再把省钱动作写进测评流程，而不是事后补救。
4. 记一张历史账把每轮的题目数、调用次数、实际花费记成一张表，下一轮报价直接拿历史数据推，比重新估快得多。

需要提醒的是，压成本的边界是「结论不能变」。如果为了省钱把评分方式从人工换成纯脚本，导致结论和人工评分方向不一致，那省下的钱最后都要用返工还回去。

什么情况下这套算法不适用

这套框架默认的是「一次性、有明确交付物」的测评。下面几种情况，按次算账会算错，得换口径。

• 做的是需要长期跑、持续更新的评测基准，成本应按月摊而不是按次算，否则每轮都会低估。
• 测评结果要对外发布或作为采购依据，人工复核和第三方交叉验证的预算不能省，省了结论就不可信。
• 题目涉及多轮对话、长文档或工具调用，token 消耗波动大，估算误差会比单轮问答大得多，区间要给宽。
• 如果是临时应急、只跑几道题看个感觉，那根本不需要走完整套成本框架，按调用费粗估即可。

判断标准很简单：如果这轮测评的结论会被拿去下决策，就别按最省的口径算；如果只是内部看一眼方向，那就别把人工和复核预算堆上去。