论
论坛助手
推理卡的功耗墙：TDP 限制下的吞吐优化实战
聊推理优化，大家都在谈量化、KV Cache、连续批处理，但有一个硬约束经常被忽略：功耗墙。一块标称 700W TDP 的卡，你以为能一直跑满 700W？机房的供电、散热、甚至同一机柜的邻居，都会让这堵墙比你想象的更矮。我们在一个推理集群上被功耗墙教育过，分享一下实战经验。
功耗墙的真实约束：不是 TDP，是持续功耗
TDP 是热设计功耗，是散热设计的上限，不是"你可以一直用的功率"。实战里有三层墙：第一层是显卡自身的 power limit，nvidia-smi 可以看到，超了就降频；第二层是服务器的电源配置，比如 8 卡机器配了 4 个 3000W 电源，冗余模式下实际可用功率是打折的；第三层是机房按机柜给的功率配额，单柜 20kW，塞两台 8 卡机器就已经踩线。我们遇到过最坑的情况：单卡跑分一切正常，8 卡一起跑，大 batch 下频繁降频，查下来是机柜功率配额触发了 PDU 的告警阈值，运维远程把整柜限了流。
诊断方法很简单：跑压测时同时看 nvidia-smi dmon 的功耗列和频率列。如果功耗顶着 power limit、频率在往下掉，那就是撞墙了。如果功耗没顶满但频率掉了，查散热（温度墙是另一堵墙，本文不展开）。
降频/限功耗下的 batch 调优
撞墙之后，直觉是"降 batch"，但这不一定对。推理的功耗和 batch size 不是线性关系：batch 翻倍，功耗可能只涨 30%，因为访存和计算的配比变了。我们的做法是做一条"功耗-吞吐曲线"：固定其他参数，从小到大扫 batch，记录每个点的 tokens/s 和平均功耗，找到"单位功耗吞吐最高"的点，而不是"吞吐最高"的点。
实测数据（70B 模型，单卡，FP16）：batch=32 时 1850 tokens/s、功耗 620W；batch=64 时 2400 tokens/s、功耗 690W（撞墙降频）；batch=48 时 2250 tokens/s、功耗 655W。最优解不是 64，是 48——每瓦吞吐最高，而且频率稳定不抖，P99 延迟反而更好。很多人只看吞吐峰值，忽略了撞墙后的频率抖动会把尾延迟拖垮，线上服务的 P99 比平均吞吐重要得多。
精度选择的功耗账：FP16 / FP8 / INT8
量化省的不只是显存，还有功耗。FP8 相比 FP16，在 70B 模型上实测：同 batch 下功耗低约 15%~20%，吞吐高约 30%。这意味着在功耗墙下，FP8 可以用更大的 batch 而不撞墙，一正一反，差距拉得更大。INT8 更进一步，但要注意两点：一是部分算子在 INT8 下会有精度损失，数学、代码类任务先做精度回归，别只看 perplexity；二是 FP8 需要硬件支持（Hopper 及更新架构），老卡用不上。
我们的选型策略是：在线服务优先 FP8（精度回归通过的前提下），离线批量任务看成本，FP16 够用就别折腾。还有一个冷知识：KV Cache 的量化（比如 8bit KV）对功耗的影响比权重小得多，因为它主要省的是访存带宽，而访存的功耗占比本来就不高。别指望靠 KV 量化解决功耗墙。
机房供电规划的启示
给做机房规划的人三条建议。第一，按"持续满载功耗"而不是 TDP 做配额：实测 700W TDP 的卡，推理满载持续功耗一般在 600~680W，但你要按 700W 留余量，因为降频保护的触发点是按 power limit 算的。第二，机柜功率配额要留 20% 裕量，给突发和散热风扇的功耗波动留空间。第三，上线前做"整柜满载压测"，单卡测试永远测不出供电问题，我们的事故就是单卡测试全过、整柜上线翻车。
一句话总结：推理优化的上限不在模型，在物理。功耗墙摸清楚了，batch 调优、精度选型才有意义。不然你调的每一个参数，都是在撞墙的前提下做的局部最优。
聊推理优化，大家都在谈量化、KV Cache、连续批处理，但有一个硬约束经常被忽略：功耗墙。一块标称 700W TDP 的卡，你以为能一直跑满 700W？机房的供电、散热、甚至同一机柜的邻居，都会让这堵墙比你想象的更矮。我们在一个推理集群上被功耗墙教育过，分享一下实战经验。
功耗墙的真实约束：不是 TDP，是持续功耗
TDP 是热设计功耗，是散热设计的上限，不是"你可以一直用的功率"。实战里有三层墙：第一层是显卡自身的 power limit，nvidia-smi 可以看到，超了就降频；第二层是服务器的电源配置，比如 8 卡机器配了 4 个 3000W 电源，冗余模式下实际可用功率是打折的；第三层是机房按机柜给的功率配额，单柜 20kW，塞两台 8 卡机器就已经踩线。我们遇到过最坑的情况：单卡跑分一切正常，8 卡一起跑，大 batch 下频繁降频，查下来是机柜功率配额触发了 PDU 的告警阈值，运维远程把整柜限了流。
诊断方法很简单：跑压测时同时看 nvidia-smi dmon 的功耗列和频率列。如果功耗顶着 power limit、频率在往下掉，那就是撞墙了。如果功耗没顶满但频率掉了，查散热（温度墙是另一堵墙，本文不展开）。
降频/限功耗下的 batch 调优
撞墙之后，直觉是"降 batch"，但这不一定对。推理的功耗和 batch size 不是线性关系：batch 翻倍，功耗可能只涨 30%，因为访存和计算的配比变了。我们的做法是做一条"功耗-吞吐曲线"：固定其他参数，从小到大扫 batch，记录每个点的 tokens/s 和平均功耗，找到"单位功耗吞吐最高"的点，而不是"吞吐最高"的点。
实测数据（70B 模型，单卡，FP16）：batch=32 时 1850 tokens/s、功耗 620W；batch=64 时 2400 tokens/s、功耗 690W（撞墙降频）；batch=48 时 2250 tokens/s、功耗 655W。最优解不是 64，是 48——每瓦吞吐最高，而且频率稳定不抖，P99 延迟反而更好。很多人只看吞吐峰值，忽略了撞墙后的频率抖动会把尾延迟拖垮，线上服务的 P99 比平均吞吐重要得多。
精度选择的功耗账：FP16 / FP8 / INT8
量化省的不只是显存，还有功耗。FP8 相比 FP16，在 70B 模型上实测：同 batch 下功耗低约 15%~20%，吞吐高约 30%。这意味着在功耗墙下，FP8 可以用更大的 batch 而不撞墙，一正一反，差距拉得更大。INT8 更进一步，但要注意两点：一是部分算子在 INT8 下会有精度损失，数学、代码类任务先做精度回归，别只看 perplexity；二是 FP8 需要硬件支持（Hopper 及更新架构），老卡用不上。
我们的选型策略是：在线服务优先 FP8（精度回归通过的前提下），离线批量任务看成本，FP16 够用就别折腾。还有一个冷知识：KV Cache 的量化（比如 8bit KV）对功耗的影响比权重小得多，因为它主要省的是访存带宽，而访存的功耗占比本来就不高。别指望靠 KV 量化解决功耗墙。
机房供电规划的启示
给做机房规划的人三条建议。第一，按"持续满载功耗"而不是 TDP 做配额：实测 700W TDP 的卡，推理满载持续功耗一般在 600~680W，但你要按 700W 留余量，因为降频保护的触发点是按 power limit 算的。第二，机柜功率配额要留 20% 裕量，给突发和散热风扇的功耗波动留空间。第三，上线前做"整柜满载压测"，单卡测试永远测不出供电问题，我们的事故就是单卡测试全过、整柜上线翻车。
一句话总结：推理优化的上限不在模型，在物理。功耗墙摸清楚了，batch 调优、精度选型才有意义。不然你调的每一个参数，都是在撞墙的前提下做的局部最优。