LLM 能效并不是模型固有且固定的属性。当你改变预填充长度、输出长度、批次形状、精度、请求时序、GPU 时钟或服务运行时时，同一个模型每个有效请求消耗的能量可能大不相同。在认定某种配置高效之前，应结合延迟和质量测量这些因素。
本指南面向负责运行或评估 LLM 推理的高级读者。其实践结论很简单：在设备或节点层面采集能量数据，用服务遥测解释这些数据，并在请求层面将其归一化为有效工作量。单一的功率读数无法同时完成这三项工作。
随着推理预算增加，这一区分变得更加重要。额外生成的 token 会增加计算量，但围绕这些 token 的系统决定了硬件完成这些工作的效率。我的早期分析推理 token 及其计算成本介绍了工作负载方面的内容。本文聚焦于能效审计和服务方面。
LLM 能效是服务栈共同作用的结果
能量是功率随时间的积分。如果一块 GPU 在十秒内平均消耗 400 瓦，那么它使用了 4,000 焦耳能量。这部分很简单。困难在于选择时间窗口、硬件边界和报告单位。
“每个 token 的能量”至少可以表示三种不同的含义：
| 指标 | 适用场景 | 可能隐藏的因素 |
|---|---|---|
| --- | --- | --- |
| 每个输出 token 的焦耳数 | 以 Decode 为主的聊天和生成 | Prompt 处理、失败请求、质量差异 |
| 每个有效输入 token 的焦耳数 | Prefill 和长上下文工作负载 | 输出工作量和端到端请求价值 |
| 每个成功请求的焦耳数 | 产品和工作负载比较 | Prompt 与响应长度的巨大差异 |
| 每千瓦时请求数 | 容量和运营规划 | 请求难度、质量和延迟 |
没有哪一种指标在所有场景下都正确。选择与服务契约匹配的单位，并报告足够的上下文，使其他团队能够复现实验。
硬件边界同样重要。NVIDIA 的管理 API 在受支持的硬件上提供设备能量计数器。这可以得到清晰的 GPU 能量差值，但默认不包括 CPU 工作、主机内存、存储、网络、冷却或电源转换损耗。CodeCarbon 可以通过测量和估算部分扩展边界，但其文档说明，对于无法读取的硬件会使用回退估算。“由工具测量”并不意味着每个部分都经过计量。
四项研究测量了服务栈的不同部分
近期研究让系统层面的影响变得清晰。下面的关键百分比不是排行榜。每项研究使用了不同的平台、工作负载、基线和能量边界。
| 研究 | 范围与方法 | 报告结果 | 需要注意的边界 |
|---|---|---|---|
| --- | --- | --- | --- |
| AFlex | 将 attention 和 feed-forward 工作解耦，然后在 A800 系统上控制资源配置、频率、批次大小和微批处理 | 在满足 TTFT 和 TPOT 目标的同时，相比测试中的解耦基线，每个 token 的能耗最高降低 49% | 两个模型系列、A800 硬件，以及经过评估的生产风格轨迹 |
| Festina | 针对共享 H100 推理，协调放置、GPU 分区、运行点、整合和迁移 | 在报告配置中，能耗最高降低 56%，同时 SLO 达成率保持在两个百分点以内 | 共享 GPU 的无服务器场景；当 Prefill 已经是计算密集型时，收益会缩小 |
| EnerInfer | 预测不同 NPU 和内存设置下的吞吐量与功率，然后在温度限制下管理控制设置 | 手机、笔记本电脑和边缘板卡上的能效分别提升 65%、12% 和 24% | 端到端设备节能幅度更小，为 4.2–11%，因为其他组件和阶段仍会消耗能量 |
| Understanding Efficiency | 在 H100 GPU 上测试量化、批处理、到达模式和服务选择 | 相比研究中的顺序基线，连续批处理将每个请求的能耗降低了 12.5 倍；在固定测试中，结构化到达模式取得了更大收益 | 短 Prompt、两个 Llama 模型规模、单一加速器系列，以及主要聚焦 GPU 的能耗数据 |
共同结论比任何单项百分比都更有意义：编排可以大幅改变能耗，以至于模型级估算失效。这些论文也说明了为什么“使用更低精度”是不完整的建议。H100 研究发现，较低精度有助于计算受限的 Prefill，但在受内存限制的 Decode 阶段，反量化和 kernel 开销可能抵消甚至逆转这一收益。
应将所有“最高可达”的数字视为作者实验的属性。AFlex 并不能证明你的 B200 集群可以节省 49%。EnerInfer 也不能证明每部手机都能实现 65% 的整机节能。这些结果指出了值得测试的控制项，而不是可以直接复制到预测中的节省比例。
在优化之前先区分 Prefill 和 Decode
一个 LLM 请求包含两个瓶颈不同的阶段。
Prefill 通常是计算密集型的
Prefill 处理 Prompt 并构建键值缓存。较长的 Prompt 会产生大量并行矩阵运算。当该阶段受计算能力限制时，改变精度和提高时钟频率可能有所帮助，但更低的首 token 时间也可能伴随更高的功率峰值。应测量能量，而不只是功率。
Decode 通常受内存限制
Decode 一次生成一个 token。它会反复读取模型权重和不断增长的 KV cache，因此内存流量和批次形成往往占主导地位。提高时钟频率可能增加功率，却无法带来成比例的吞吐量提升。当 kernel 或硬件路径匹配不佳时，量化也可能增加转换开销。
这一阶段划分说明，整个请求的平均值可能产生误导。一种配置可能改善长 Prompt 的 Prefill，却损害短 Prompt 的 Decode。每项能耗结果至少应同时报告 Prompt 长度、输出长度、批次或并发数、精度，以及各阶段的耗时。
KV cache 也应纳入同一条记录。我的 KV cache 驱逐失败指南介绍了可靠性方面的内容。在能耗分析中，缓存压力可能改变内存流量、重计算、放置方式和重试率。存在静默驱逐的运行，不能与不存在驱逐的运行进行比较。
在保护延迟 SLO 的前提下进行能耗审计
审计需要三个相互连接的层次：请求结果、服务上下文，以及设备或节点能耗。
*有用的能耗结果需要明确的单位、服务上下文和清晰的硬件边界。*
1. 固定具有代表性的工作负载
不要只构造一个合成平均值，而应建立工作负载切片。至少要区分短 Prompt 和长 Prompt、短输出和长输出、稳定到达和突发到达，以及应用使用的质量等级。在比较期间固定模型、tokenizer、采样策略和停止规则。
在隐私和同意允许的情况下，使用真实请求形状。如果使用合成 Prompt，应保留驱动系统行为的 token 长度分布和到达分布。最终报告应将合成需求明确标记为合成数据。
2. 记录请求级结果
对每个请求记录：
不要从能耗总量中删除失败请求。一个通过让困难请求超时而在已完成请求上消耗更少能量的配置，并不代表它更高效。
3. 记录服务上下文
记录能够解释变化的控制项：Prefill 和 Decode 时长、批次大小、活跃序列数、队列深度、精度、并行度、缓存占用、放置方式、GPU 时钟或功率上限，以及共租户负载。
这些遥测数据也能捕捉空闲和突发效应。如果 GPU 等待时运行时仍让 CPU 保持繁忙，那么在仅 GPU 读数中可能看起来正常，但在节点或集群边界上表现更差。开源 issue 讨论有助于发现这些故障模式，但在你自己的服务栈上复现之前，它们仍只是个案。
4. 测量明确的能量边界
在受支持的 NVIDIA GPU 上，NVML 提供以毫焦耳为单位的总能量计数器。下面的 Python 探针可以为固定工作负载划定起止范围：
python from pynvml import ( nvmlDeviceGetHandleByIndex, nvmlDeviceGetTotalEnergyConsumption, nvmlInit, nvmlShutdown, )
nvmlInit() gpu = nvmlDeviceGetHandleByIndex(0) start_mj = nvmlDeviceGetTotalEnergyConsumption(gpu)
run_fixed_workload() # same requests, model, and stopping rules
end_mj = nvmlDeviceGetTotalEnergyConsumption(gpu) nvmlShutdown()
gpu_joules = (end_mj - start_mj) / 1_000 joules_per_output_token = gpu_joules / completed_output_tokens
NVML 设备查询文档定义了该计数器及其单位。请在确切的 GPU 和驱动上检查是否支持。驱动重新加载时，累计值会重置，因此应拒绝负值或损坏的差值。对于没有能量计数器的设备，应以能够捕捉短请求的频率采样功率，并在相同时间窗口内对轨迹进行积分。
GPU 能耗是一个有效边界，前提是你明确说明这一点。对于容量、成本或碳核算，应根据决策需要加入主机和设施部分。CodeCarbon 文档可以扩展审计范围，但要阅读工具测量了哪些值、估算了哪些值。对于整节点比较，外部机架或墙端电表仍是更有力的校验方式。
5. 以多种方式归一化结果
不要只报告一个胜出的数字，而应报告一组小型指标：
一个指标有助于调优 Decode 路径。另一个指标则能将变化与产品价值联系起来。延迟和质量字段可以防止能效优化悄悄削弱服务。
6. 每次改变一个控制项，然后重放需求
从隔离实验开始：精度、批处理策略、请求分桶、缓存设置、GPU 功率或时钟上限，以及放置方式。预热后运行多次试验。当温度或时间可能造成偏差时，应在试验之间改变执行顺序。
然后在混合到达模式下重放最佳候选方案。Festina 和 AFlex 都协调多个控制项，因为局部最优会相互作用。第一轮应隔离原因；最终一轮则应在真实 SLO 下测试组合策略。
按证据支持的顺序进行优化
最稳妥的优化顺序是先消除浪费的工作，再转向更精细的硬件控制。
如果系统提供不同的质量等级，应将这一流程与真实工作基准结合起来。实用模型基准测试工作流可以在改变服务路径时，同时呈现质量、延迟和成本。
不要混淆能量、成本和碳排放
这些指标回答的是不同问题。
更低的云账单并不能证明更低的能耗。更低的 GPU 计数器读数并不能证明更低的设施能耗。更低能耗的运行如果发生在不同时间或地点，也不一定自动意味着更低排放。
报告问题的重要性已经足以进入标准制定工作。ITU-T 关于 AI 推理能效指标的工作项目的范围包括 token 边界、每 token 能耗指标、碳排放计算和报告规则。这项工作表明，token 单位和系统边界仍未完全确定。它还不是一项完成的基准测试。
生产环境决策规则
只有当某项 LLM 能效变化降低了目标有效工作单位的能耗，并且使请求契约保持在预算内时，才应接受这项变化。
在测试前写下该契约：
这一规则可以避免三种常见错误：优化功率而不是能量；优化已完成 token，同时隐藏失败请求；以及将论文中的“最高可达”结果迁移到不同硬件上。
研究指出的是实践方向，而不是通用配置。分别分析 Prefill 和 Decode。保持请求、运行时和硬件记录的关联。测量你计划管理的边界。这样，能耗数字才能转化为工程决策。