🤖 machine learning

From Tokens to Watt-hours: Analytical Energy Estimation for LLM Inference on Modern GPUs

本文介绍了一种经过经验校准的分析方法，通过将工作负载分解为计算和内存流量组件，用于估算 NVIDIA H100 GPU 上大语言模型（LLM）推理的能耗，从而在无需直接进行硬件测量的情况下，实现透明且可复现的能量评估。

原作者： Tina Vartziotis, Rodopi Kosteli, Elli Vartziotis, George Dasoulas, Michael Keckeisen, Konstantinos Skianis, Sotirios Kotsopoulos, Francesca Dominici

发布于 2026-07-30

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Tina Vartziotis, Rodopi Kosteli, Elli Vartziotis, George Dasoulas, Michael Keckeisen, Konstantinos Skianis, Sotirios Kotsopoulos, Francesca Dominici

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，互联网就像一座巨大的、繁忙的图书馆，数以百万计的人不断向一位神奇的图书管理员（人工智能）提问，让它写故事、解数学题或总结新闻。长期以来，我们只担心这位图书管理员学习这些技巧需要多少“脑力”（训练）。但现在，这位图书管理员正在不间断地工作，每天回答数百万个问题。这种持续的工作消耗了大量的电力，这对地球并不利。科学家和工程师面临的一个大问题是：“回答一个问题究竟需要多少能量？”问题的难点在于，直接测量这种能量就像是在飓风中试图称量一粒沙子的重量；你需要特殊的、昂贵的传感器和完美的环境，而大多数人并不具备这些条件。如果没有一种方法来估算能量成本，我们就很难知道哪一个 AI 更“绿色”，或者某种特定的提问方式是否在浪费电力。

这篇题为《从 Token 到瓦时》（From Tokens to Watt-hours）的论文提供了一种巧妙的方法来解决这个难题，而无需插上功率计。作者们是一群来自大学和科技公司的研究人员，他们构建了一个数学“计算器”，通过观察 AI 的规模和对话的长度来估算它使用了多少能量。你可以把它想象成 AI 的“营养标签”：它不计算卡路里，而是计算“瓦时”（能量的单位）。他们在被称为 NVIDIA H100 的强大计算机芯片上测试了这个计算器，这些芯片是驱动当今许多最智能 AI 的引擎。

以下是他们的计算器是如何工作的，我们用一个简单的类比：想象 AI 是厨房里的一位厨师。为了烹饪一顿饭（生成答案），厨师要做两件事：他们阅读食谱并收集食材（这是“计算”部分），然后他们跑回储藏室去拿香料和工具（这是“内存”部分）。研究人员发现，对于短订单，厨师主要是在进行烹饪，所以能量成本主要在于烹饪。但对于长而复杂的订单，厨师必须频繁地跑向储藏室，这时跑来跑去的能量消耗就开始占据主导地位。

论文将能量成本分解为两个主要阶段：

“预填充”（Prefill）阶段： 这是厨师阅读客户订单（输入提示词）的时候。这里的能量成本取决于订单的长短。
“解码”（Decode）阶段： 这是厨师逐字逐句写出答案的时候。这里的能量成本取决于答案的长短。

研究人员发现，能量成本不仅仅取决于 AI 有多大（它有多少“食材”或参数），还很大程度上取决于对话变得多长。他们发现，随着答案变得越来越长，能量并不仅仅是呈直线增长；它会急剧向上弯曲。为什么呢？因为 AI 每写出一个新词，都需要回头看之前所有的词，才能理解故事的意思。这就像厨师每加一小撮盐，就得把整份食谱重新读一遍。食谱越长，跑来跑去的需求就越多，消耗的能量也就越多。

利用这个公式，团队计算出，一个小型 AI（约有 3 亿参数）在处理一次请求时消耗的能量非常少，大约为 0.001 瓦时。但一个巨大的 AI（拥有 1200 亿参数）在执行相同任务时则消耗更多——大约为 0.15 瓦时。他们还展示了，对于一个 700 亿参数的模型，他们的估算值与其它科学家进行的真实世界测量结果非常接近（误差在 5% 以内），这证明了在无法直接测量功率的情况下，他们的“计算器”足够可靠。

论文明确指出，这个工具并不能完美替代使用电表测量电力。它没有计算空调、互联网电缆或其他数据中心计算机所消耗的能量。它只计算正在进行思考的特定芯片所使用的能量。然而，作者认为，这部分芯片能量是工程师可以控制的最大开支。

那么，这对未来意味着什么？论文建议，如果我们想要节省能源，我们不应该仅仅尝试制造更大的 AI。相反，我们应该尝试缩短“食谱”（压缩输入）、要求更短的答案，或者为简单的任务使用更小、更专业的“厨师”。作者希望这个计算器能帮助开发者比较不同的 AI 模型并选择那些更具能效的模型，从而在不需要在每台计算机上都安装功率计的情况下，帮助建设一个更“绿色”的数字世界。

技术摘要：从 Token 到瓦时：现代 GPU 上 LLM 推理的分析性能量估算

1. 问题陈述

大语言模型（LLM）推理的运行能耗是部署 AI 系统环境足迹的关键组成部分。虽然“绿色 AI”研究已广泛涵盖了训练成本，但推理能耗——由持续的、随需求规模变化的自回归 Token 生成所驱动——仍然是一个重要的可持续性问题。

目前的 AI 能耗估算方法面临着一种二分法：

基于测量的方法依赖于硬件遥测、功率仪表或特定基础设施的监控。虽然这些结果很有价值，但它们与特定的硬件、服务系统和运行时配置绑定在一起，限制了其在对比研究、早期系统设计以及缺乏此类仪表设备的可持续性报告中的适用性。
基于 Transformer 缩放法则和微架构基准测试的分析模型提供了 FLOPs 计数，但往往无法提供考虑了内存流量和硬件特定系数的请求级或 Token 级能量估算。

这造成了一个缺口，即需要一种透明、可复现的估算器，能够结合 Transformer 计算模型、内存流量归因以及硬件特定的能量系数，从而在不需要运行时仪表的条件下估算 GPU 推理能量。

2. 方法论

作者提出了一种半分析、经验校准的方法，用于估算 NVIDIA H100 类加速器上 LLM 推理的加速器侧 GPU 能量消耗。该框架明确区分了**提示词预填充（Prompt Prefill）阶段和自回归解码（Autoregressive Decode）**阶段，因为这两个阶段表现出截然不同的计算和内存访问模式。

2.1. 能量分解

单个请求的总 GPU 能量 ( $E_{GPU}$ ) 被建模为张量核心计算能量 ( $E_{compute}$ ) 与高带宽内存（HBM）移动能量 ( $E_{memory}$ ) 之和：
$E_{GPU} = E_{compute} + E_{memory}$

计算项： 与张量核心浮点运算（FLOPs）的数量成正比。
$E_{compute} = \alpha_{TC} C_{TC}$
其中 $\alpha_{TC}$ 是硬件特定的单位 FLOP 能量， $C_{TC}$ 是总 FLOPs 计数。
内存项： 与通过 HBM 传输的比特数成正比。
$E_{memory} = e_{HBM} Q_{HBM} \eta(N)$
其中 $e_{HBM}$ 是单位比特能量， $Q_{HBM}$ 是总比特流量， $\eta(N)$ 是校准后的内存低效因子。

2.2. 流量建模

内存流量 ( $Q_{HBM}$ ) 被分解为三个主要部分：

参数访问： 加载模型权重所需的流量。
KV-Cache 写入： 在生成过程中存储新的键值对（Key-Value pairs）的流量。
注意力相关读取： 从 KV-cache 中读取累积上下文的流量。

该模型区分了稠密（Dense） Transformer 操作（随参数和 Token 线性缩放）与**注意力（Attention）**修正（由于二次方级别的 KV-cache 读取需求，随序列长度超线性缩放）。

2.3. 校准与系数

该方法使用从 GPU 张量核心计算和 HBM 访问（特别针对 H100 类 GPU 上的 FP16/BF16）的微架构测量中得出的固定硬件系数：

$\alpha_{TC} = 0.52$ pJ/FLOP
$e_{HBM} = 11.68$ pJ/bit

为了解释非理想的硬件行为（例如参数复用、缓存驻留和内存低效），作者采用了拟合自先前文献中报告的能量测量值的校准缩放因子 ( $\gamma(N)$ , $s_{attn}(N)$ , $\eta(N)$ )。

2.4. 简化估算器

对于缺乏详细架构元数据（如层数、隐藏层维度）的场景，定义了一个简化的仅参数估算器。它近似将输出 Token 的能量与参数量 ( $N$ ) 成线性比例，并使用一个依赖于提示词长度的乘数来处理输入 Token。

3. 核心贡献

分析框架： 一种无需直接运行时测量即可估算请求级和归一化 Token 级 GPU 推理能量的结构化方法。
阶段分离： 将能量明确分解为提示词预填充阶段和自回归解码阶段，实现了对输入 Token 与输出 Token 成本的粒度分析。
组件拆解： 将总能量分解为计算、参数访问、KV-cache 写入和注意力读取组件，揭示了各部分的缩放行为。
经验校准： 将硬件特定的能量系数与经验校准的内存流量因子相结合，弥合了理论 FLOPs 计数与实际能量消耗之间的鸿沟。
具启发性的见解： 识别了降低能量的具体机制，包括模型规模缩减、缩短生成长度、KV-cache 量化、提示词压缩以及改进的批处理（Batching）。

4. 结果与评估

该估算器针对一系列 Transformer 类 LLM（参数量从 <3B 到 >120B 不等）进行了评估，并与基于测量的研究进行了对比。

随序列长度缩放： 计算能量和 KV-cache 写入流量随生成的 Token 数量 ( $T_{out}$ ) 线性缩放。然而，注意力相关的内存流量表现出超线性（二次方）增长，随着序列长度增加，成为主要的能量贡献者。
随模型规模缩放： 在对数-对数坐标系下，总请求能量随模型规模 ( $N$ ) 近似线性缩放。然而，由于架构差异（如隐藏层维度和层数）并未随参数量均匀缩放，内存能量在不同模型间表现出非单调行为。
能量分解： 对于短到中等长度的序列，计算能量占主导地位。随着序列长度增加，注意力相关的内存组件迅速增长，导致总能量趋势出现向上弯曲。
准确性： 在与 500 个输入 Token / 500 个输出 Token 工作负载的测量结果对比时，分析估算值与测量值的误差在 4.73% 至 27.23% 之间。对于 70B 参数模型，观察到的最低误差为 4.73%。
Token 级估算： 研究提供了简化的 Token 级能量估算（例如，对于 70B 模型，约为 218 mJ/输出 Token），展示了能量对参数量的线性依赖关系。

5. 重要性与声明

本文将该方法定位为一种透明、可复现且具有明确假设的近似方法，而非物理功率测量的替代品。

范围： 估算严格限于加速器侧运行能耗（GPU 计算和 HBM 移动）。它们明确排除了系统级开销，如 CPU 执行、主机内存、网络、存储、冷却以及电源使用效率（PUs）。
用途： 该框架旨在用于：
- 模型比较： 在异构模型库之间比较能量效率。
- 绿色编程分析： 评估架构选择和干预措施的影响。
- 设计时评估： 在缺乏全数据中心级仪表设备的情况下做出部署决策。
局限性： 作者承认，该模型抽象掉了特定效应，如张量并行通信、算子融合（Kernel Fusion）、批处理策略以及特定的推理引擎实现。因此，这些因子需要针对不同的 GPU 代际或服务配置进行重新校准。

总之，本文提供了一个理解 LLM 推理能量缩放的基础工具，强调了虽然计算在短序列中占主导地位，但内存流量（特别是注意力读取）成为了长上下文生成的关键瓶颈。

技术摘要：从 Token 到 瓦时：现代 GPU 上 LLM 推理的分析性能量估算