AI 能耗主张需要更可靠的测量

一份实用指南,教你区分训练、推理和数据中心设施的能耗,并避免用误导性的单次查询数据描述 AI 效率。

Separate energy meters for training, inference and facility overhead

谈论 AI 能耗时,人们常把一个系统、一座数据中心乃至整个电网压缩成一个醒目的数字。要做出更好的决策,首先要明确测量边界、工作负载和时间范围。

区分训练与推理

训练是有起止范围的模型开发工作负载;推理则随每次生产请求反复发生。应分别报告两者;如果实验、失败的运行及支撑服务对决策有实质影响,也应纳入。大规模使用的模型在整个生命周期中的推理能耗可能超过一次训练的能耗,但具体比例取决于使用方式。

衡量推理时,要界定请求类型、输入与输出长度、批次大小、延迟目标和硬件。生成一张图片与分类一句话所需的工作量不同,因此“一次 AI 查询”不是稳定的计量单位。

测量 IT 能耗和设施额外开销

加速器并不等于整座数据中心。制冷、电力转换、网络和存储都会增加开销。电源使用效率(PUE)有助于描述设施额外开销,却无法揭示用电的碳强度或某项 AI 任务的效率。

尽可能报告实测能耗,并说明采样方法与不确定性。如果使用估算值,应写明利用率假设,不要把某个看似精确的数字说成普遍适用。

纳入时间和地点

相同的用电量,因电网能源结构和用电时段不同,可能对应不同的排放量。基于地点和基于市场的核算回答的是不同问题。应分别报告能耗和排放量,让读者能够检查换算过程。

美国能源部 2024 年的报告估计,数据中心在 2023 年约占美国全国用电量的 4.4%,并预测到 2028 年这一比例将达到 6.7% 至 12%。这是系统层面的情景预测,而非单个模型的测量结果,不能据此为某个应用分摊碳足迹。

按有效工作量归一化

追踪每项成功完成的任务所消耗的能源,而不只是每个 token 或每次请求的能耗。首次尝试看似便宜,但如果失败后还要重试三次,总体效率可能更低。还要设定质量门槛,避免以系统不可用为代价换取效率提升。

在同一评估集上比较不同架构。缓存、小模型、批处理、更短的输出和本地处理都可能有所帮助,但也可能改变质量、延迟或硬件利用率。

发布可审计的主张

可信的表述应明确工作负载、模型或系统版本、硬件、地区、测量时段、设施边界和质量水平,同时说明未纳入的项目。随着部署规模和电网条件变化,应更新这一表述。

这种严谨做法不会产出一个令人过目不忘的通用数字,而是提供采购方、工程师和政策制定者真正用得上的数据。

如何付诸实践

先选择一项与 AI 能耗主张及其测量相关、范围明确的工作流程。在改变系统之前,写下一页基线记录:目前的完成时间、质量检查、常见失败类别、升级处理路径,以及对结果负责的人。选择有代表性的样本,而不只挑最简单的例子。纳入普通案例、困难的边缘案例,以及至少一个正确做法是暂停或要求补充信息的案例。

先让候选方案与现有流程并行运行,再考虑替换现有流程。成功和失败的输出都要检查,因为整体错误率降低,仍可能掩盖新的高影响故障。记录每次测试所用的准确配置,并保留足以让其他审查者复现结果的材料。试点结束时,应依据事先商定的阈值决定扩大使用、调整还是停止,而不是凭事后对最佳演示的印象做决定。

向供应商或内部团队提出的问题

询问支撑核心主张的证据是什么、证据对应哪些系统和数据版本,以及排除了哪些条件。索取针对部署所涉语言、输入类型和风险类别的结果。了解变更如何通知、回归问题如何发现,以及客户如何导出事件复盘所需的日志。

还要询问置信度低、依赖项故障或请求超出支持范围时,系统会如何处理。可靠的产品应有明确的失败状态,而不只是给出措辞更漂亮的回答。责任归属也很重要:明确谁能暂停流程、谁批准例外,以及重大错误流入生产环境后由谁通知受影响用户。

实用检查清单

  • 在选择模型或工具之前,先定义用户任务以及真正重要的失败情况。
  • 保留一个从真实工作中抽取的小规模、带版本标识的测试集,包含棘手及对抗性案例。
  • 为每次运行记录模型、提示词、工具、检索设置、数据版本、延迟和成本。
  • 对不可逆、高影响或外部可见的操作,要求人工确认。
  • 按类别审查失败,而不只看平均分,并将回归案例纳入测试集。

Meydo Journal 延伸阅读

主要来源