技术深度解析
从训练主导的算力消耗转向评估主导的算力消耗，其根源在于现代AI系统的架构复杂性。训练一个大型语言模型（如GPT-4或Claude 3.5）是一次性、高度优化的过程。但评估本质上是并行且组合式的。
评估算力分类学
现代评估流程由多个独立阶段组成，每个阶段都需要大量算力：
1. 安全与对齐测试：红队测试、对抗性提示生成和越狱检测需要数千到数百万个提示-响应对。每次测试可能涉及多次模型调用，通常使用温度采样来探索失败模式。对于一个前沿模型，全面的安全评估可能需要10^6到10^8次推理调用。
2. 多模态评估：像GPT-4V和Gemini Pro这样的模型处理文本、图像、音频和视频。每种模态都需要单独的基准测试。例如，在COCO数据集上评估视觉问答（VQA）涉及120,000多张图像，每张图像都要通过视觉编码器和语言解码器处理。对于视频理解，算力成本会随帧数倍增。
3. 智能体工作流评估：这是计算最密集的类别。智能体系统（如AutoGPT、BabyAGI或OpenAI的Code Interpreter）必须在多轮交互中进行测试，通常涉及工具使用。单次评估运行可能模拟50-100步，每一步都需要一次模型调用。为了达到统计显著性，研究人员每个任务运行100-1000条轨迹。对于像SWE-bench（软件工程任务）这样的基准测试，一次完整评估每个任务可能消耗10^4到10^5次模型调用。
4. 对抗鲁棒性测试：针对对抗性攻击（如基于梯度的攻击、提示注入）的测试需要生成对抗样本，每个样本需要多次前向和反向传播。对于视觉模型，这可能涉及每个样本超过100步的迭代优化。
量化算力差距
为了说明规模，考虑以下对一个假设的前沿模型（例如，一个200B参数的密集Transformer）的训练和评估算力比较：
| 阶段 | 算力（FLOPs） | 相对成本 |
|---|---|---|
| 预训练（1.4T tokens） | 1.4e25 | 1x（基准） |
| 完整评估套件（安全+多模态+智能体+鲁棒性） | 1.2e25 | 0.86x |
| 单一智能体基准测试（如SWE-bench，1000条轨迹） | 2.0e23 | 0.014x |
| 单一安全红队测试活动（10^6个提示） | 1.0e22 | 0.0007x |
数据要点：一个完整的评估套件现在消耗约86%的预训练算力。对于智能体模型，这一比例可能超过1:1，因为每条评估轨迹本质上都是一次微型训练运行。
GitHub仓库因素
开源项目既在推动这一趋势，也深受其影响。例如：
- lm-evaluation-harness（EleutherAI）：LLM评估的标准工具，目前在GitHub上拥有超过3000颗星。它支持200多个基准测试，但运行完整套件需要大量算力。最近的更新增加了对多轮智能体任务的支持，使算力需求增加了5-10倍。
- HELM（Stanford CRFM）：一个全面的评估框架，在42个场景中测试模型。在70B模型上运行完整的HELM评估可能需要500多个A100 GPU小时。
- AgentBench（清华大学）：一个针对智能体LLM的基准测试，模拟8个不同的环境。每个环境每个任务需要100多个交互步骤，完整基准测试包含100个任务——每次评估总计超过10,000次模型调用。
架构瓶颈
根本原因在于评估本质上是不可摊销的。训练受益于大规模并行和批处理。相比之下，评估是顺序且多样化的：每个测试需要不同的提示、上下文或环境状态。推测解码或KV缓存重用等技术可以提供帮助，但当评估需要多样化、未见过的输入时，它们的作用有限。
要点：行业正接近一个临界点，即评估新模型的边际成本超过了训练它的边际成本。这将迫使架构创新——例如评估专用硬件、高效采样方法或学习型评估代理——来打破这一瓶颈。
关键参与者与案例研究
主要实验室
| 组织 | 评估策略 | 预估算力分配 | 关键挑战 |
|---|---|---|---|
| OpenAI | 内部红队测试 + 自动化安全评估（如GPT-4安全系统卡） | 总算力的30-40% | 扩展到多模态+智能体模型 |
| Google DeepMind | 通过内部框架（如BIG-Bench、MMLU）+外部合作进行全面评估 | 总算力的25-35% | 在速度与全面性之间取得平衡（针对Gemini） |
| Anthropic | 宪法AI + 广泛的红队测试（如Claude 3安全评估） | 总算力的40-50% | 持续扩展评估维度 |