智算集群规模上去后，制约性能的往往不是算力本身，而是供电与散热给出的功率上限。机柜功率封顶一旦触发，硬件会自动降频，训练与推理性能随之波动，而且波动难以预测。把功率当作调度资源来管理，比事后排查降频更有效。

功率管理首先要区分两种封顶。一种是机柜级硬封顶，超过即触发保护，风险高；另一种是集群级软封顶，通过调度把总功率控制在安全线以下。工程上应当以软封顶为日常管理手段，让硬封顶只作为兜底保护，而不是常态运行状态。

调度策略可以从三个层面入手。任务层面，把高功耗任务与低功耗任务搭配排布，避免同一时段所有节点同时冲到功耗峰值。节点层面，对非关键任务设置功率上限，关键任务保留冲刺空间。时间层面，利用业务低谷安排高功耗训练任务，把峰值错开。

降频策略也需要显式设计。均匀降频看似公平，实际上会拖慢所有任务；更好的做法是按任务优先级分层降频，低优先级任务先降，关键任务后降。降频幅度和恢复条件要事先定好，避免功率一回落就立即满负荷反弹，造成反复震荡。

监控同样重要。需要同时看机柜功率、节点功耗、硬件降频事件与任务进度四类信号，只看其中一类很难定位问题。复盘时重点关注一个问题：降频发生时，调度系统是否提前感知并采取了动作。如果每次都是硬件先触发保护，说明功率管理还停留在被动响应阶段，需要把调度阈值再往前提一步。

功率管理还要与散热联动考虑。同一机柜内高温节点的降频阈值更低，单纯按任务优先级调度可能把高负载持续压在散热条件差的节点上。调度时应当结合温度信号，避开热点节点，或者把高功耗任务分散到不同机柜。功率与温度是同一枚硬币的两面，只管一面，另一面迟早会反噬。