Лимит мощности GPU: эксперимент с энергией и задержкой

Лимит мощности GPU следует исследовать как эксперимент с энергией и задержкой на разрешенных поддерживаемых режимах. Меньшее значение power cap не гарантирует меньшую энергию на выполненную задачу: работа может длиться дольше. Зафиксируйте workload, границу измерения и текущую настройку, затем сравнивайте согласованные operating points. Не меняйте пределы вслепую на общем production узле и не выводите экономию из одного наблюдения мощности без учета завершенной полезной работы.

Проверьте поддерживаемую область

Руководство nvidia-smi описывает power limits, доступность и ограничения управления. Сначала сохраните исходный режим и разрешенный диапазон конкретного устройства. Поддержка чтения не означает право или возможность изменения в любом окружении. Для статьи достаточно плана контролируемого теста, без универсальной команды, применимой ко всем GPU. Если policy платформы не разрешает изменение, используйте доступные approved profiles или обозначьте невозможность эксперимента. Не подменяйте power cap механическим управлением частотами: это связанные, но разные настройки.

Зафиксируйте цель и объем работы

CUDA Best Practices Guide помогает организовать измерение исполнения и интерпретацию производительности. Сохраните prompts, model revision, output policy и concurrency. Сравнивайте одинаковую задачу и фактическое количество завершенной работы. Если один режим генерирует более короткие ответы, его меньшая энергия не доказывает повышение эффективности. Отдельно задайте допустимые TTFT и интервалы token delivery, чтобы выбор по энергии не нарушил требования приложения, ради которых сервер вообще запускается и обслуживает этот workload.

Пример таблицы operating points

Обозначьте варианты A, B и C, соответствующие проверенным допустимым настройкам. В таблице оставьте столбцы cap, elapsed time, completed work, energy и latency tails. Это структура будущего измерения, не готовые проценты экономии. Если B потребляет меньше мощности, но завершает работу позже, вычислите энергию на тот же принятый workload отдельно. Если C нарушает latency threshold, такой вариант может быть непригодным даже при меньшей энергии. Не скрывайте отклоненные точки: они объясняют реальный компромисс и границу выбора.

Учитывайте условия эксперимента

Стабилизируйте temperature conditions и сохраняйте фактические clocks, доступные наблюдению, без обещания фиксированного поведения любого boost режима. Разделите прогрев и steady-state, повторите исходный operating point после серии. Если среда изменилась, отмечайте неопределенность. Используйте один sensor boundary во всех вариантах: board energy и AC energy нельзя подставлять друг вместо друга. Не делайте вывод о снижении счета за электричество по локальному GPU датчику без учета прочих компонентов, продолжительности работы и выбранной границы всей системы.

Как принять рабочую точку

Сохраните policy разрешений, исходный limit, выбранные режимы, raw telemetry и функциональные fixtures. Укажите процедуру возвращения исходной конфигурации и подтверждение фактического восстановления. Результат должен описывать измеренную frontier энергии и задержки для конкретной модели и нагрузки, а не универсальную рекомендацию снизить power limit всем серверам. При изменении GPU, workload или cooling повторите проверку. Полезный вывод позволяет выбрать точку, удовлетворяющую требованиям, и ясно показывает цену компромисса. Он не обещает линейной экономии, сохранения throughput или одинакового эффекта на разных архитектурах и не считает одно более низкое мгновенное показание достаточным доказательством улучшения полной энергетической эффективности inference.

Связанные материалы

Энергия на запрос LLM: как измерять без ложной точности; Скорость потока и задержка: как выбрать рабочий режим GPU.