写给非硬件背景开发者的 GPU 功耗测量入门：从“看不懂瓦特”到第一张功耗曲线

为什么要写这篇过去半年我一直在做 LLM 推理能耗的实测工作，写了一系列关于量化省不省电的文章。但每次和朋友聊起这个话题，我发现大家卡住的地方往往不是“量化到底怎么样”，而是更前面的问题：

功耗这个数字到底怎么来的？

我手上有一张消费级 GPU，能不能自己测？

测出来的数据怎么用才不算自欺欺人？

本文试图回答这三个问题。它不涉及任何量化策略的对比，也不讨论具体模型的推理性能——那些是后续文章的事。这里只聊一件事：作为一个写代码的人，怎么开始理解并测量 GPU 的功耗。

第一个概念：GPU 功耗不是一个数，是一条曲线

很多开发者第一次接触“功耗”这个概念时，会下意识把它当成一个固定值——就像灯泡上标的 60W 一样。但 GPU 的功耗是动态变化的：它在空闲时可能只有 10W，满载时可能飙到 350W，而在推理的一个 batch 内部，它可能每毫秒都在波动。

所以当我们说“测量功耗”时，实际上是在对一个连续变化的信号做时间序列采样。你拿到的不是一个数字，而是一串 (时间戳, 功率值) 的数据对，最终画出来的是一条曲线。

这个认知转换很重要，因为它直接决定了你的实验设计：

如果你只采了一个点，你测的是“那一瞬间”，不是“这一次推理”。

如果你采样频率太低，你会丢失瞬态峰值。

如果你没有对齐时间轴，你无法把功耗和具体的计算阶段对应起来。

怎么读功耗：NVML 和它的能力边界

NVIDIA 提供了一个叫 NVML（NVIDIA Management Library）的 C 库，它可以通过驱动层读取 GPU 的实时状态，包括核心温度、显存占用、利用率，以及我们最关心的——瞬时功耗。Python 里最常用的封装是 pynvml。一段最基本的功耗读取代码长这样：

import pynvml

import time

pynvml.nvmlInit()

handle = pynvml.nvmlDeviceGetHandleByIndex(0)

for _ in range(100):

power_mw = pynvml.nvmlDeviceGetPowerUsage(handle) # 单位：毫瓦

print(f"{time.time():.3f}, {power_mw / 1000:.1f} W")

time.sleep(0.01) # 10ms 间隔

pynvml.nvmlShutdown()

这段代码做的事情很简单：每 10ms 读一次当前功耗，打印出来。但它暴露了几个你需要理解的概念：

采样频率。 NVML 的 nvmlDeviceGetPowerUsage 读取的是驱动内部功率传感器的当前值。不同 GPU 的传感器更新频率不同，常见在每秒 5 次到 100 次之间。你以 10ms 间隔去读，并不意味着你能拿到 100Hz 的真实数据——如果传感器本身每 50ms 才更新一次，你读到的是重复值。一个实用的自检方法：观察读数里连续重复值的长度，就能推断出你的卡实际更新多快。了解你的硬件的实际采样能力，是实验设计的第一步。

时间分辨率 vs. 能量积分。 如果你想知道“这次推理花了多少焦耳”，你需要对功率曲线做时间积分（近似为求和：E ≈ Σ Pᵢ × Δt）。采样间隔越密、负载时越长，积分越可信。注意这里有个容易想当然的坑：对于持续数十秒的批量推理，粗采样问题不大；但如果你测的是单流 decode 这种几秒级甚至亚秒级的窗口，低频采样会明显失真——我自己在 RTX 4090 上做过交叉验证：较新的卡还提供 nvmlDeviceGetTotalEnergyConsumption（硬件能量计数器），把它和你自己的积分对比，我实测发现计数器读数比 10Hz 采样积分平均高约 14.9%。这就是采样分辨率带来的真实差异量级，引用具体数字前值得心里有数。

NVML 读不到什么。 NVML 给出的是 GPU 板卡级别的功耗（包括 GPU 核心、显存、板载电路），但不包括 CPU、内存、主板、电源损耗、散热系统。如果你要算“整个系统的能耗”，NVML 只回答了其中一部分。对于数据中心场景，通常还需要 UPS 级别或 PDU 级别的功率计来补全。

实验设计的四个常见陷阱

当你能够稳定读取功耗数据之后，下一步是设计一个有意义的实验。这里有四点经验，每一条都是踩坑之后才写进流程的。

1. 空闲功耗不是常数GPU

在“什么都没做”的时候也在耗电，而且这个值不是恒定的。它会受到驱动版本、电源管理策略（nvidia-smi -pm）、甚至环境温度的影响。正确的做法是：每次实验前后各记录一段空闲功耗（建议 10–30 秒），取中位数作为该次实验的空闲基线。如果前后基线差异超过 5%，这次实验的数据值得打个问号。

2. 稳态和瞬态是两回事

LLM 的 prefill 阶段和 decode 阶段的功耗特征完全不同——前者是计算密集型的大矩阵运算，功耗高且相对稳定；后者是自回归的逐 token 生成，功耗低且波动大。如果你把整个推理过程的功耗取平均，你会得到一个“看起来合理但实际上什么都没说”的数字。正确的做法是：用时间戳对齐推理日志和功耗日志，至少区分 prefill 和 decode 分别统计。至于更细的子阶段（attention、MLP），NVML 的时间分辨率通常对不齐——除非你有内核级的打点工具，否则不要在这个粒度上许愿。

3、温度会污染下一次测量

这一条是我自己项目第一次就栽过的坑。GPU 刚跑完一个高负载任务时是热的，热卡会降频、单位计算更费电——如果紧接着跑下一次测量，后者的读数会被前者余温系统性抬高。我们第一次出数据时就因为 arm 顺序固定 + 没有冷却，两个配置的差异里混进了温度效应，被迫全部重测。正确的做法是：两次测量之间等 GPU 回到空闲温度（看 nvmlDeviceGetTemperature 稳定即可），并且把 baseline 和实验组的执行顺序随机化。另外记住：冷态和稳态是两种不同的测量条件，注明你测的是哪种，两种模式内部的数字才可比。

4. 单次测量没有统计意义

GPU 的功耗会受到很多随机因素的影响：其他进程的干扰、驱动调度、甚至 PCIe 总线上的噪声。单次运行的功耗曲线可能恰好偏高或偏低。正确的做法是：同样的配置至少跑 5–10 次，报告均值和标准差（或者中位数和四分位距）。如果你看到两个配置的能耗差异小于它们各自的方差，那这个差异在统计上是不显著的——不管数字看起来多漂亮。

从零搭建你的第一个测量环境

如果你有一张 NVIDIA GPU（消费级即可，4090、3090 甚至更低的卡都行），以下是搭建测量环境的最小步骤：

第一步：确认驱动和工具链。

确保安装了兼容的 NVIDIA 驱动，nvidia-smi 能正常输出。安装 Python 环境和 pynvml（pip install nvidia-ml-py3 或 pip install pynvml，二者是同一个库的不同发行名）。

第二步：写一个最简单的功耗记录脚本。

不需要复杂框架，一个循环 + 时间戳 + 写 CSV 就够了。关键是确保时间戳的精度（用 time.time() 或 time.perf_counter()），以及输出格式方便后续处理。

第三步：跑一个你知道预期行为的负载。

比如一个简单的矩阵乘法，或者一个小型模型的固定长度生成。目的是验证你的测量链路是通的——功耗曲线应该呈现出你预期的模式（空闲 → 升高 → 回落 → 空闲）。如果曲线看起来不合理（比如全程一条直线），先排查测量脚本，不要急着分析“结果”。

第四步：开始做对比实验。

改变一个变量（比如 batch size，或者模型大小），保持其他条件不变，记录功耗曲线，计算总能耗，比较差异。这就是你所有后续分析的基础。

一些诚实的建议

最后说几点不太像“教程”的东西，但它们可能比代码更重要。

不要追求绝对精度，追求相对比较的可靠性。 消费级 GPU 的板载功率传感器精度有限（业界通常引用的容差在 ±5% 左右，具体因卡而异）。你很难用它测出“这次推理精确消耗了 3.142 焦耳”，但你完全可以可靠地比较“配置 A 比配置 B 多耗了约 30% 的能量”——前提是实验条件一致。

记录一切元数据。 GPU 型号、驱动版本、CUDA 版本、库版本、环境温度、其他运行中的进程……这些东西在你写实验报告的时候看起来是“显然的”，但三个月后你回来看自己的数据，你会发现没有这些元数据你根本不知道当时发生了什么。

先怀疑自己，再怀疑数据。

当你得到一个反直觉的结果时（比如“量化反而更费电”），第一反应不应该是“这一定是 bug”，也不应该是“我发现了一个新现象”。正确的反应是：检查实验条件，检查测量链路，重复实验，排除所有可能的混淆因素之后，再认真考虑这个结果可能是真的。这不是悲观主义，这是做实验的基本纪律。

系列预告与现成的路径

这是“GPU 能耗测量入门”系列的第一篇。后续会聊到：如何做跨 GPU 的对比实验、如何处理 Colab 等共享环境下的测量噪声、以及如何把功耗数据和推理质量指标（如困惑度）放在同一个实验框架里分析。如果你不想从零写采样脚本：我在维护一个开源测量容器 ecocompute-mlcube（NVML 10Hz 采样、schema 校验的报告输出、上述所有陷阱——冷却、随机化、分相统计——都已内置成协议），相关的公开数据集和交叉曲线在 quantenergy.tech。欢迎拿它当参考实现，或者直接跑一遍——你的卡可能正好补上数据集里的一个空格。