AI评估消耗了多少Token？被忽视的算力成本黑洞

一个被忽视的问题

近日，一条来自Twitter的提问在AI从业者圈子里引发了讨论："你认为全球AI Token支出中，有多少比例是花在跑评估（evals）上的？"

这个看似简单的问题，实际上触及了当前大模型应用开发中一个鲜少被量化、却又无处不在的成本黑洞——模型评估（Evaluation，简称evals）。当所有人都在关注模型训练和推理的算力消耗时，很少有人认真核算过：为了验证一个模型或一个AI应用是否"够好"，我们究竟烧掉了多少Token？

什么是Evals：AI开发中的隐形基建

评估是大模型质量保障的核心环节

在传统软件开发中，我们有单元测试、集成测试来保证代码质量。而在大模型应用开发中，由于模型输出具有不确定性，"测试"这件事变得异常复杂。你无法用简单的assert断言来判断一段生成文本是否"正确"，于是评估（evals）应运而生。

评估的典型场景包括：

• 模型能力基准测试：在MMLU、GSM8K、HumanEval等数据集上跑分。MMLU（Massive Multitask Language Understanding）涵盖57个学科的选择题，从人文社科到STEM全面测试模型的知识广度与深度；GSM8K包含8500道小学数学应用题，主要衡量模型的逐步数学推理能力；HumanEval是OpenAI发布的代码生成评测集，包含164个Python编程问题，用于衡量模型的代码生成与逻辑能力。每一个基准测试都需要将题目和上下文作为输入Token发送给模型，再接收生成的输出Token，单次完整的MMLU评测就可能消耗数百万Token。
• Prompt迭代验证：每改一版提示词，就要在测试集上重新跑一遍
• 回归测试：模型或流程更新后，确保原有功能没有退化
• LLM-as-a-Judge：用一个大模型去评判另一个模型的输出质量。这是近两年迅速流行的自动评估范式，核心思想是利用能力更强的大模型（如GPT-4）来评判其他模型的输出。具体流程是将待评估模型的输出、原始问题、参考答案和评分标准打包成一个Prompt，发送给裁判模型，由其输出评分和理由。这种方法相比人工评估速度更快、可规模化，但Token消耗惊人——每次评判都需要将完整上下文重新输入裁判模型，而裁判模型通常是参数量最大、单价最高的模型。MT-Bench和Chatbot Arena等知名评测体系都采用了这一范式。

评估的Token消耗为何被严重低估

关键在于，很多评估流程本身就是Token的"吞金兽"。以"LLM作为裁判"这种越来越流行的做法为例——你不仅要消耗Token生成待评估的答案，还要额外消耗Token让另一个模型来打分。一次评估往往意味着双倍甚至多倍的Token开销。

更重要的是，评估不是一次性的。一个严肃的AI团队，可能每天要跑成百上千次评估。在现代AI开发实践中，CI/CD（持续集成/持续部署）流水线已经成为标配——这一概念从传统软件工程延伸而来，被称为"LLMOps"。每当Prompt模板被修改、检索增强生成（RAG）的配置被调整、或者底层模型版本被切换时，CI/CD流水线会自动触发一整套评估任务。这意味着一个活跃的AI开发团队，一天可能产生数十次代码提交，每次都会消耗一轮完整的评估Token。与传统单元测试几乎零边际成本不同，这里的每一次自动化测试都是真金白银的API调用。A/B测试要对比多个版本，Prompt工程师一天要迭代几十轮。这些消耗日积月累，规模惊人。

全球AI Token支出中评估占比可能高得惊人

开发阶段与生产阶段的Token分布差异

如果我们把AI应用的生命周期拆开看，会发现一个有趣的现象。在应用尚未大规模上线前，开发和调试阶段的Token消耗几乎全部来自评估和实验，而非真实用户请求。

对于大量仍处于探索期、尚未找到PMF（产品市场契合）的AI创业公司来说，它们的Token账单里，评估、测试、调优可能占据了相当大的比例。PMF是创业领域的核心概念，指产品真正满足了市场需求并获得用户认可的状态。对于AI创业公司而言，寻找PMF的过程格外消耗Token：团队需要反复实验不同的Prompt策略、模型选择、RAG架构和输出格式，每一次实验都需要在评估集上验证效果。据a16z在2024年的调研，许多AI初创公司将超过20%的云计算预算花费在模型API调用上，而其中大量调用并非服务真实用户，而是用于内部开发、测试和评估。在尚未实现规模化营收之前，这些评估开销构成了显著的现金流压力。这解释了为什么有从业者猜测，全球AI Token支出中，evals的占比可能远超直觉——有人估计在10%到30%之间，甚至更高。

合成数据生成进一步放大评估成本

你可能没注意到，评估与合成数据生成、模型蒸馏等场景高度重叠。合成数据生成是指使用大模型批量产出训练数据或测试数据的技术，而模型蒸馏（Knowledge Distillation）则是用大模型（教师模型）的输出来训练小模型（学生模型）的技术。这两个场景的Token消耗极为可观：例如，微软的Phi系列小模型就大量依赖GPT-4生成的合成数据进行训练；斯坦福的Alpaca项目用52000条由GPT-3.5生成的指令数据微调了LLaMA模型。这些过程中，每一条合成数据的生成都需要消耗输入和输出Token，且为了保证数据质量，往往还需要额外的筛选和评估步骤，形成"生成-评估-再生成"的循环消耗。

当团队用大模型批量生成测试用例、构造评估数据集时，这些消耗虽然名义上不叫"eval"，但本质上都属于"非终端用户"的Token开销。如果把这些广义的"内部消耗"都算进来，比例只会更高。

评估成本对AI行业的深远影响

评估效率正在成为新的竞争力

如果评估真的消耗了如此大比例的算力，那么降低评估成本本身就是一门生意。这也解释了为什么近两年涌现出大量评估工具和平台，如LangSmith、Braintrust、Promptfoo等——它们的核心价值之一，就是帮助团队更高效、更省钱地跑评估。LangSmith是LangChain推出的全生命周期AI开发平台，提供Trace追踪、评估管理和数据集管理功能；Braintrust专注于AI产品的评估和实验管理，支持自定义评分函数和版本对比；Promptfoo是一个开源的Prompt测试框架，支持在多个模型和多组Prompt之间进行系统化对比评测。这些工具通过智能缓存（避免对相同输入重复调用API）、评估集精简（用统计方法选取最有区分度的测试用例）等技术手段，帮助团队显著降低评估阶段的Token开销。

未来，聪明的团队会采用分层评估策略：用小模型或规则做初筛，只在关键环节动用昂贵的大模型裁判；用缓存避免重复评估；用更精炼的评估集减少冗余Token消耗。

对AI算力需求预测的启示

对于云厂商和芯片公司而言，这个问题也有现实意义。当前市场对AI算力的需求预测，大多基于"推理服务真实用户"的假设。但如果很大一部分Token消耗其实来自开发者的评估和实验，那么算力需求的结构就与人们想象的不同——它更依赖于开发者生态的活跃度，而非终端应用的用户规模。

这意味着，像OpenAI、Anthropic、Google等模型提供商的API收入增长，不能简单等同于"AI应用的用户增长"。收入中可能有相当一部分来自开发者在构建和评估阶段的消耗。一旦产品成熟、评估流程稳定下来，这部分消耗可能会显著下降，这对算力需求的长期预测模型带来了不确定性。

结语：把评估纳入成本核算的时代到了

这条Twitter提问的价值，不在于给出一个精确答案，而在于提醒整个行业：我们对AI成本的认知存在盲区。

评估是保证AI应用质量不可或缺的一环，但它的成本长期被隐藏在"研发费用"的笼统科目里，很少有人单独核算。随着AI应用走向成熟，那些能够精细化管理评估成本、在质量与开销之间找到最佳平衡点的团队，将获得实实在在的竞争优势。

下一次当你看到一份AI公司的算力账单时，不妨多问一句：这里面，有多少是花在了"检验"而非"服务"上？