GPU 服务器供电与功耗治理：从电源冗余到 Power Capping
说明：本篇为综述/无第一手实验数据，采用公开硬件规格与运维实践路线。
实验目标
万卡集群的功耗是"机房设计的输入"（01 章液冷篇提过功率密度），但运行期的功耗治理是另一回事：为什么同一批机器功耗波动很大？整机柜 220V 限流时谁先掉电？训练任务如何不踩功耗墙又能跑满？ 本篇目标：拆解 GPU 服务器的供电与功耗治理——电源拓扑与冗余（N+1/2N）、整机功耗构成与实测方法、Power Capping（功耗上限）的设置与代价、以及"集群级功耗预算"如何与调度联动。读完能对"这台机器该设多高的功耗上限"给出量化答案。
代码逐段拆解
第一段：整机功耗观测
# 节点级：整机功耗（电源模块读数，Linux 下通过 ipmi/powermeter）
# 1) 通过 ipmitool 读电源模块（PSU）功率
ipmitool sdr type 'Power Supply' # 看电源健康与负载
# 2) 通过 powermeter（带外）读整机实时功耗（示例，型号相关）
ipmitool sensor list | grep -i power
# GPU 级：每张卡的实时功耗与功耗墙
nvidia-smi --query-gpu=index,power.draw,power.limit,power.max_limit \
--format=csv要点：
- 两级功耗读数：节点级（PSU/整机）用 IPMI 带外读，GPU 级用
nvidia-smi读——治理时要能区分"整机功耗"与"GPU 功耗"，因为 CPU/内存/风扇也占 15%-30%。 power.limit是当前功耗墙，power.max_limit是硬件允许上限：GPU 出厂功耗墙可以下调（Power Capping），但一般不能超过max_limit（除非刷自定义 vbios，有保修风险）。power.draw是动态值：训练负载下 GPU 功耗接近功耗墙，空闲时掉到 10%-20%——集群功耗波动大的根源是"负载节奏"而不是硬件故障。
第二段：Power Capping 设置（nvidia-smi）
# 把 GPU 功耗墙从默认 350W 压到 300W（示例：H100 类）
sudo nvidia-smi -pl 300 -i 0,1,2,3
# 持久化：写入 nvidia-persistenced 配置或 systemd 开机执行
# /etc/systemd/system/gpu-power-cap.service
# [Service] ExecStart=/usr/bin/nvidia-smi -pl 300 -i 0,1,2,3要点：
-pl是"软上限"：GPU 自行调度降频以满足功耗墙，训练吞吐通常只掉几个百分点（峰值功耗段被削平），但整机柜限流场景下收益巨大——把"随机超限掉电"变成"稳定在预算内"。- Power Capping 的代价是尾部性能：压功耗墙 = 压 boost 频率，短突发计算（如小 batch 推理峰值）受影响比长稳训练大；推理服务压功耗墙要实测 P99 延迟变化。
- 持久化是必须的：
-pl重启即失，需 systemd/持久化守护；且与驱动升级联动——升级驱动后功耗墙可能回到默认，验收清单里要有"功耗墙复核"。
原理讲解
供电拓扑与冗余
GPU 服务器通常 2-4 个电源模块（PSU），供电拓扑决定"掉一个电源会怎样"：
| 冗余级别 | 含义 | 场景 |
|---|---|---|
| N+1 | 在线 N 个 + 1 个备用容量 | 数据中心主流：掉一个 PSU 不影响运行 |
| 2N | 双路独立供电（A/B 路） | 关键业务：一路市电/一路 UPS |
| 无冗余 | 满载运行，掉一个就限功率 | 低成本/边缘 |
关键认知：冗余是"容量冗余"不是"永远在线"——N+1 时掉一个 PSU，机器靠降载（GPU 降频）继续跑而不关机；2N 时单路断电机器无感。机柜层面还有"总进线限流"：整柜 220V×63A ≈ 14kW，机柜内所有机器的功耗和不能超——这是 Power Capping 的真正驱动力。
整机功耗构成与治理空间
典型 8×GPU 服务器（估算口径）：
| 部件 | 功耗占比 | 治理手段 |
|---|---|---|
| GPU ×8 | 70%-80% | Power Capping、驱动节能 |
| CPU | 8%-12% | 频率/核心调度 |
| 内存/存储 | 3%-5% | 少 |
| 风扇/散热 | 5%-10% | 液冷替代风冷、风扇策略 |
治理优先级：GPU 功耗墙（最大头、可控）> 散热方式 > CPU 节能。GPU 功耗墙 300W vs 350W 每卡省 50W，8 卡机省 400W，一个 1000 卡的集群每机柜（约 16 台）就能空出近 1 个机柜的供电余量——前提是吞吐损失可接受。
集群级功耗预算与调度联动
机柜进线预算（如 14kW）
→ 每台机器功耗上限 = 预算 / 机柜台数 × 冗余系数
→ 映射到 GPU 功耗墙（nvidia-smi -pl）
→ 调度器感知：SLURM/K8s 按功耗墙登记节点功耗，防止"满载节点叠加导致机柜跳闸"理想闭环：功耗墙设好后，调度器把"节点当前功耗"作为资源维度——新任务调度到功耗余量足够的节点，而不是只看 GPU 数。这需要监控侧（02 章 DCGM 功耗指标）提供实时功耗，调度侧按功耗余量过滤候选节点。
实验结果
（估算口径，非实测；以 H100 类 8 卡机为例）
| 功耗墙设置 | 单卡峰值 | 训练吞吐影响 | 机柜余量（1000 卡集群） |
|---|---|---|---|
| 默认 350W | ~350W | 0% | 基准 |
| 320W | ~320W | ~1%-3% | 约省 1 个机柜 |
| 300W | ~300W | ~3%-8% | 约省 2 个机柜 |
工程启示
- 先量后治：整机功耗（IPMI）+ GPU 功耗（smi）两级测量先跑两周，摸清负载节奏再设墙——不要拍脑袋压功耗。
- 功耗墙是"机柜限流下的保险"而非"省电手段"：省电收益一般（GPU 空闲时本身会降功耗），真正价值是防止机柜跳闸与降低峰值电费。
- 推理压墙必测 P99：功耗墙削的是 boost 峰值，推理的尾部延迟最敏感；压墙前后对比 P99，掉超 10% 就不值得。
- 与监控/调度联动：功耗墙是"静态设置"，实时功耗是"动态资源"——调度器感知功耗余量才能把机柜预算用满而不跳闸（02 章 DCGM 篇的功耗指标在此衔接）。
下一篇预告：单机能耗治理讲完，回到集群整体效率——"GPU 集群利用率治理：碎片、排队与调度效率"。