教程
每一块 GPU,每一秒,每一瓦
PowerX 公开实测 AI 推理背后的功耗。
更新于
正在加载实测数据点…
HGX 机箱上 exporter 上报的是 GPU 板卡功耗。周围的 2 颗 x86 CPU、32 条 DIMM、8 块 NIC、4 颗 PCIe 交换芯片、10 块 NVMe 盘、风扇和 PSU 损耗都由模型估算,风冷按 PUE 1.3 计。
- 实测
- 建模
- 标称或假设
PowerX 测量每颗加速器在运行基准测试时的功耗,并对它周围的系统其余部分建模。实心标记是实测遥测,空心标记是开源功耗模型的建模值,虚线标记是标称或假设值。这套视觉语法在每张图表上都成立。
从实测到建模功耗
实测 GPU 功耗. 每 GPU 的平均、P75 和 P90 瓦特数在窗口内按时间加权,覆盖部署中的全部 GPU;prefill 和 decode 角色在同一窗口内分别求平均。
- 实测
- 建模
- 标称或假设
- 采样。 NVIDIA 节点上的
dcgm-exporter和 AMD 节点上的device-metrics-exporter每秒上报一次每颗 GPU 的功耗,头节点按同一时钟抓取所有节点。 - 开窗。 每个并发点只有一个服务窗口,从 warmup 结束到最后一个请求完成。只有窗口内的样本才计入统计。
- 积分。 每颗 GPU 的能量是其样本在窗口内的梯形积分;每 token 能量 = 整个部署的 GPU 能量 ÷ 客户端统计的 token 数。
- 建模。
power_model包接收实测瓦特数和一个工作状态(固定序列、智能体、带 KV offload 的智能体),加上 CPU、内存、NIC、交换芯片、存储、风扇和 PSU 损耗得到 IT 功率,再乘以 PUE(风冷机箱 1.3,液冷 NVL72 机柜 1.1)得到数据中心功率。
动手探索 PowerX
建模曲线位于实测曲线之上且形状相同,因为模型补上的部件几乎不随负载变化。
- 实测
- 建模
正在加载通过校验的数据点…
越低越好,两条线都是对交互性的 Pareto 前沿,与仪表板其他图表一致。
把 GPU 从空闲拉到 TDP,看哪些建模部件会跟着变。
B200 · 每 GPU IT 881 W
GPU
600 W实测输入
风扇
29 W随 GPU 变化
网络分摊
51 W固定
NVSwitch
50 W固定
电源损耗
35 W随 GPU 变化
CPU
38 W固定
PCIe 及其他
35 W固定
网卡
23 W固定
内存
15 W固定
存储
6 W固定
风扇和 PSU 损耗跟随 GPU;CPU、内存、NIC 和交换芯片保持不变,所以 GPU 负载越轻,额外开销的相对占比越大。
测试方法
平均、P75 和 P90 功耗在窗口内按时间加权,覆盖部署中的全部 GPU;prefill 和 decode 角色在同一窗口内分别求平均。做规划看 P90,因为动态功率调度对峰值敏感;比较芯片看每 token 能量。
只有离线验证器从原始样本重新执行并通过全部五项检查,数据点才标记为 Validated。其余都是 Historical:吞吐量保留,能量和建模功耗去掉,审计记录会写明未通过的检查。
01所有预期 GPU 在整个窗口内都有上报
验证器比对拓扑预期的设备与 samples.csv 中出现的设备,缺少任意一颗 GPU,该点即失效。
记录为
expected_device_missing02样本间隔不超过 3 s
exporter 卡住会留下空洞,梯形积分会把它抹平,所以要用每颗 GPU 的最大间隔与上限比较。
记录为
sample_gap_exceeded03遥测窗口与客户端窗口相差不超过 0.5 s 或 1 %
头节点按自己的时钟写窗口,基准测试客户端上报自己的起止时间,两者必须在 max(0.5 s, 窗口的 1 %) 内一致。
记录为
measurement_window_clock_mismatch04采集端 commit 与固定版本一致,并记录 exporter 镜像
写入样本的代码由其 git commit 标识,必须等于验证器构建时固定的版本;exporter 镜像摘要一并记录。
记录为
producer_commit_mismatch05用作能量分母的 token 数为正
每 token 焦耳数需要分母。输出 token 为零的窗口保留瓦特数,但不能给出能量指标。
记录为
invalid_output_token_count
五项全部通过:Validated。任一失败:Historical,保留吞吐量,去掉能量和建模功耗。
功耗采集是每次官方 sweep 的一部分,提交的测试配置会自动被测量。要自行运行,在多节点 matrix 条目中加上 power: true;单节点和 AgentX 任务直接使用集群自带的 exporter。require-power(或 REQUIRE_POWER=1)会让窗口无效的任务直接失败,而不是记录 power_valid: 0。
更多选项
kimik3-fp4-h200-dynamo-sglang:
multinode: true
scenarios:
fixed-seq-len:
- isl: 8192
osl: 1024
search-space:
- num-nodes: 4
srt-recipe: agg-tp16dp2ep32-latency.yaml
power: true
conc-list: [1, 2, 4, 8]汇总 JSON 包含 power_valid、avg_power_w、p90_power_w 和各 joules_per_* 指标;power_audit_<result> 产物包含 samples.csv、窗口文件和 power_validation_<result>.json。
应用结果
按容量规划的读法读一个通过校验的数据点:实测瓦特数、模型补上的 IT 瓦特数、每兆瓦可部署的 GPU 数,以及它与标称值之间的差距。
正在加载实测数据点…
打开 PowerX,通过 API 获取同样的数字,或用 skills 包中的 inferencex powerx export 命令导出。
常见问题
为什么实测功耗远低于 TDP?
以 decode 为主的推理受限于内存和延迟目标,而不是计算,所以 GPU 很少触及功率上限。Prefill、视频生成和训练则接近 TDP。
DCGM 和 nvidia-smi 的读数有差异吗?
没有。两者读取的是同一个 NVML 传感器,固件本身已经按约 1 秒做了平均,因此采样快于 1 Hz 收益很小。DCGM 额外提供一个守护进程和一个能量计数器。
为什么用 P90 而不是平均值?
容量是按峰值配置的。P90 是窗口内 10 % 时间会超过的功率,安全余量应在它之上叠加。
为什么提供不含 PUE 的 IT 口径?
数据中心容量团队按每 GPU 的关键 IT kW 做规划。PUE 取决于站点,所以 Facility 口径单独应用它。
功耗模型变化时会发生什么?
不存储任何建模值。每个建模数字都由存储的 GPU 实测值按固定的模型版本重新计算,所以更新会同时改变所有数据点,模型版本会显示在提示框中。
为什么同一次运行中其他点都是 Validated,只有一个点是 Historical?
有效性按窗口判定。丢失一个样本或时钟不一致只会使该窗口失效;该点保留吞吐量,但失去能量指标。
Facility 数值更高是否意味着站点效率更低?
不是。PUE 是按散热类型固定的模型输入,不是对基准测试站点的测量。