Экономия энергии в AI-фабрике зависит от того, чем управляет RL

Управлять энергией GPU с помощью reinforcement learning можно, но сам факт применения RL ничего не гарантирует. Главный результат этого исследования в другом: контроллер эффективен только тогда, когда у него есть реальный рычаг влияния на нагрузку, а не формальный параметр в настройках генерации.

На масштабе 7B авторы собрали более 380 000 измерений с шагом в полсекунды на конфигурациях от одной до четырёх A100. PPO-контроллер менял параметры генерации прямо во время GRPO-обучения и в сравнении с полной 500-шаговой трассой дал заметный компромисс: на 89,8% сократил превышения лимита мощности, на 18,1% увеличил выпуск токенов и на 26,2% поднял эффективность в токенах на MWh.

Но перенос этого же подхода на 72B сначала провалился. При шардировании модели параметр размера группы почти перестал управлять фактической загрузкой GPU — у контроллера формально был рычаг, но усилия не передавались на систему. Это полезное напоминание против маркетинговой идеи «добавим AI-контроллер»: сначала нужно проверить, может ли выбранный исполнительный параметр вообще менять нужную характеристику.

После проверки авторы заменили размер группы на параллелизм генерации — параметр, который сохранил 17–22% влияния на мощность. В трёх запусках для 72B такой контроллер дал на 35,7% больше вывода, чем безопасный статический режим, при превышении бюджета на 2,27 ± 1,08%. По сравнению с неконтролируемой работой число нарушений снизилось на 87,2%.

Ограничения здесь существенные. Результаты получены на конкретных сценариях GRPO, A100 и выбранных конфигурациях; сам подход пришлось перестраивать после неудачи на 72B. Кроме того, точность измерения сильно зависит от окна наблюдения: нарушения, заметные на интервале в полсекунды, сокращались с 23,6% до 1,6% при окне 30 секунд и исчезали на пяти минутах. Для смоделированного парка из 16 GPU авторы получили нулевые нарушения при окне от 30 секунд и пиковый спрос на уровне 50–56% от номинальной мощности, поэтому примерно двукратная oversubscription выглядит возможной — но только после проверки оператором.

Практический вывод для владельца GPU-кластера простой: не начинайте с выбора алгоритма RL. Сначала найдите параметр, который действительно меняет загрузку и мощность, затем измерьте систему на том же временном масштабе, на котором принимаются решения. Иначе можно получить красивый контроллер, который управляет настройкой, но не энергопотреблением.

В вашем кластере важнее точность контроля мощности на полсекунды или стабильная экономия, видимая на пятиминутном интервале? Источник: cs.AI updates on arXiv.org