Один профиль питания не подходит двум фазам LLM-сервиса

Энергопотребление LLM-сервиса удалось снизить, не нарушив заданный предел задержки. На Qwen3-Coder-480B команда Xenoscube повысила энергетическую эффективность на 20,4% при росте средней сквозной задержки на 3,5%, хотя препринт не прошёл рецензирование и все числа в нём получили сами авторы. Для систем с раздельными пулами GPU это превращает настройку питания из общего профиля оборудования в часть конфигурации модели и программного стека.

Почему двум фазам нужны разные регуляторы

Обслуживание LLM-запроса делится на обработку входного текста и последовательную генерацию ответа. В первой фазе GPU выполняет много вычислений параллельно и приближается к своему пределу мощности. Во второй он в основном читает веса модели и кэш из памяти, поэтому потребление остаётся ровным и обычно не достигает предела устройства.

При раздельном обслуживании эти фазы работают на разных пулах GPU. Значит, контроллеру не нужно распознавать короткие переходы между режимами: роль каждого устройства известна заранее. NVIDIA Max-Q, напротив, применяет к обоим пулам один профиль с лимитом мощности, пределом частоты и другими настройками.

Для обработки входного текста Xenoscube ограничивает диапазон частот вычислительных блоков. Нижнюю границу выбирают так, чтобы запрос укладывался в допустимую задержку, а внутри диапазона контроллер меняет частоту вместе с нагрузкой. Здесь частота напрямую влияет и на скорость, и на энергопотребление, поэтому служит предсказуемым регулятором.

Для генерации действует лимит мощности. Калибровка постепенно снижает его и ищет обрыв, после которого пропускная способность падает, а задержка быстро растёт. Рабочую точку ставят немного выше: встроенный контроллер GPU сам распределяет доступную мощность между вычислительными блоками и памятью.

Статическая фиксация частоты в этой фазе сработала хуже. Высокая частота почти не экономила энергию, а низкая пересекала обрыв производительности. Ровное потребление раздельного пула также устраняет скачки, из-за которых прежние работы считали лимит мощности слишком медленным регулятором.

Профиль привязан не только к модели и GPU. В ключ калибровки входят формат чисел, версия движка, настройки CUDA Graph и способ передачи кэша между пулами. При изменении этого набора контроллер должен заново найти рабочие точки.

Калибровка нашла точку лучше Max-Q

Главная метрика работы — число сгенерированных токенов на джоуль: она показывает, сколько полезной работы система получает из единицы энергии. Её проверяли вместе со средней сквозной задержкой и ITL-p99 — задержкой между соседними токенами в хвосте распределения. Оценка одной пропускной способности скрыла бы ухудшение ответа для пользователя.

На нагрузке с LLM-агентами Max-Q дал прибавку 8,6% по токенам на джоуль, но увеличил среднюю задержку на 5,2%. Откалиброванный режим одновременно сэкономил больше энергии и меньше замедлил запросы. На другой модели все его режимы соблюдали предел ITL-p99 во всех повторах, тогда как оба профиля поставщика иногда выходили за него.

Отдельное сравнение регуляторов подтвердило выбор для генерации: откалиброванный лимит мощности обошёл статические ограничения частоты. В длительном прогоне пара пулов израсходовала на 32,3% меньше электроэнергии.

Контроллер предлагает ступени от режима, близкого к обычной производительности, до наиболее экономного набора допустимых настроек. Все ступени проходят одну проверку задержки. Во время работы защитный механизм должен ослабить ограничение, если хвостовая задержка выйдет за предел, но в записанных экспериментах он не включался: соблюдение требований обеспечила сама калибровка.

Когда работа меняет архитектурный план

Подход относится к раздельному обслуживанию моделей MoE, где для каждого токена работает только часть экспертов. Его проверяли на одном узле с восемью B200, моделях Qwen3-Coder-480B в формате FP8 и Qwen3-235B-A22B в формате NVFP4, на нагрузке с агентами и обычной смеси запросов. Для плотной модели сопоставимого масштаба выигрыш оказался примерно впятеро меньше, поэтому переносить результат на все LLM нельзя.

Если проект уже разделяет обработку входа и генерацию между пулами GPU, менять движок обслуживания не требуется: прототип работал поверх стандартной связки NVIDIA Dynamo и sglang-runtime. В план эксплуатации стоит добавить калибровку после смены модели, формата чисел или конфигурации движка, а также хранить настройки вместе с отпечатком программного стека.

Практическая схема внедрения следует прямо из эксперимента:

• измерять энергию вместе со сквозной и хвостовой задержкой, а не только с пропускной способностью;
• управлять частотой в пуле обработки входа и лимитом мощности в пуле генерации;
• принимать рабочую точку только после проверки на целевой нагрузке и пределе задержки;
• возвращать GPU к менее строгим настройкам при ухудшении хвостовой задержки.

Работа пока не обосновывает замену контроллеров, которые адаптивно меняют частоту на каждой итерации: эксперимент сравнивал лимит мощности только со статической фиксацией частоты. Область проверки также ограничена устойчивой нагрузкой на одном узле и не охватывает обучение моделей.

Метод поиска настроек и политика выбора частоты внутри окна описаны через ожидаемое поведение, но их реализация осталась частью производственной системы Xenoscube. Поэтому статья даёт архитектурный шаблон и критерии приёмки, а не готовый независимый контроллер.

Источники

• Phase-Decoupled, Model-Calibrated Power Control for Disaggregated LLM Serving