Power cap для GPU в LLM inference: production-runbook без гадания по ваттам

Стойка уже близка к пределу по питанию, GPU на пиках забирают весь доступный запас, а запрос «просто поставьте лимит на 50 ватт ниже» звучит подозрительно легко. Само значение power limit меняется одной командой, но эта команда ничего не доказывает о качестве LLM-сервиса. Нужны одинаковая нагрузка, стабильная identity устройства, три независимых gate и возврат к исходному состоянию. Ниже — production-runbook, который помогает проверить power cap без выдуманных процентов ускорения или экономии.

Что именно решает power cap — и когда он бесполезен

Power cap задаёт верхнюю границу потребления GPU. Когда карта достигает её, алгоритм управления питанием может снизить частоты. Это инструмент управления power envelope, а не кнопка «сделать inference эффективнее». В официальной документации nvidia-smi параметр --power-limit описан как максимальный лимит в ваттах в пределах min/max, причём изменение требует административных прав.

Хороший повод для эксперимента — физическое ограничение стойки, желание сгладить пики или проверить, можно ли улучшить energy-per-token при сохранении SLO. Плохой повод — низкая GPU utilization, длинная очередь из-за CPU tokenizer, медленная сеть или storage. В таких случаях GPU не упирается в собственную мощность, и новый cap лишь добавляет переменную.

Первый disqualifier прост: если одинаковый репрезентативный replay не выводит GPU к заметной загрузке и текущему power ceiling, power cap не является главным рычагом. Сначала ищите bottleneck. Для контекста полезно отделять управляемый cap от диагностики: материал про GPU throttling через DCGM и Prometheus объясняет причины снижения частот, а здесь мы намеренно создаём SW power cap и проверяем его влияние на приложение.

Есть и коммерческая граница. Если задача — разместить больше серверов в существующем power envelope, выделенная инфраструктура даёт прозрачное ownership над GPU, питанием и canary-узлами. Если задача — «сэкономить вообще», без счётчика токенов и SLO вывод будет слишком слабым для решения о конфигурации.

Baseline: что сохранить до первого изменения

Baseline должен позволять другому инженеру ответить на три вопроса: какое устройство меняли, какой лимит действовал и как в тот момент вёл себя LLM-сервис. Снимок одного nvidia-smi после инцидента для этого недостаточен. Запишите UUID, модель GPU, версию драйвера, power management mode, requested/default/min/max limit и фактически применяемый ceiling.

Затем зафиксируйте workload identity: версию модели и движка, параметры tensor parallelism, длины prompt/output, concurrency, режим batching, состояние prefix/KV cache и сам replay-набор. Знакомая ловушка: baseline прогоняют на холодном cache, а canary — уже на прогретом, после чего разницу приписывают ваттам.

Application evidence важнее красивой кривой мощности. Для vLLM сохраните TTFT, время на выходной токен, end-to-end latency, throughput, queue time, число running/waiting requests и ошибки. Актуальная документация vLLM Production Metrics перечисляет соответствующие Prometheus-метрики, но имена могут меняться между версиями, поэтому сверяйте endpoint именно вашего образа.

Соберите evidence bundle с timestamp и owner. Он пригодится не только для сравнения, но и для rollback: исходное значение нужно восстанавливать из сохранённого состояния конкретного UUID, а не копировать «обычный лимит» с соседней карты. Особенно если в сервере разные GPU или platform-level ограничения.

#!/usr/bin/env bash
set -euo pipefail
GPU_UUID="${1:?pass GPU UUID}"
STAMP="$(date -u +%Y%m%dT%H%M%SZ)"
OUT="power-baseline-${GPU_UUID}-${STAMP}.txt"

{
  nvidia-smi --query-gpu=uuid,name,driver_version,power.management,power.limit,power.default_limit,power.min_limit,power.max_limit --format=csv
  nvidia-smi -i "$GPU_UUID" -q -d POWER,CLOCK,TEMPERATURE
} | tee "$OUT"

UUID, допустимый диапазон и effective state

Не используйте индекс 0 как долговечную identity. После reboot, driver reload или изменения topology индекс может указывать на другое устройство. Для команды и автоматизации закрепляйте GPU UUID из inventory. Owner шага — инфраструктурная команда, которая контролирует host; приложение не должно само менять board power limit.

Перед write прочитайте ограничения именно целевого GPU. NVML предоставляет default limit и min/max constraints, а nvmlDeviceSetPowerManagementLimit требует root/admin, поддерживаемое устройство и значение в разрешённом диапазоне. Лимит применяется немедленно, но классический NVML-вызов не сохраняет его через reboot или driver unload. Это значит, что «команда вернула exit code 0» — только начало проверки.

После изменения снова прочитайте requested и enforced limit. На новых платформах различаются GPU ceiling, module power и GPU base power scopes; актуальная документация nvidia-smi отдельно описывает --scope. Не переносите команду с Hopper/Grace-конфигурации на другую архитектуру без проверки. Для обычного GPU ceiling не указывайте новый scope только потому, что он есть в свежей версии CLI.

Negative control нужен рядом: запрос к соседнему UUID должен показать, что его effective state не изменился. Если automation прошлась по группе целиком, canary потерян. В multi-GPU inference это особенно важно: один ограниченный rank способен изменить поведение всей tensor-parallel группы, поэтому либо тестируйте всю изолированную группу как единицу, либо не делайте вывод по одной карте внутри production replica.

Canary: меняем один управляемый контур

Выберите canary так, чтобы его можно было снять с трафика без нарушения доступности. Это может быть отдельная vLLM replica на одном GPU или целая tensor-parallel replica, если модель требует несколько карт. Baseline и canary должны получать один и тот же replay с одинаковой concurrency и распределением длин. Не смешивайте изменение cap с обновлением драйвера, модели, quantization или scheduler.

Шаг изменения намеренно скучный: подставьте UUID и предварительно согласованное значение в пределах min/max. Здесь нет универсального числа. Допустимый cap зависит от модели GPU, охлаждения, workload shape и SLO. Начинайте с малой, обратимой ступени, а не с минимально разрешённого значения.

Сразу после write подтвердите effective state чтением. Затем запустите прогрев, отбросьте прогревочное окно и только после этого соберите измеряемое окно. Проверяли ли вы, что токены и запросы на baseline и canary действительно совпали? Без этого power draw сравнивается с разной полезной работой.

Во время canary не отключайте защитные механизмы и не фиксируйте clocks «для чистоты эксперимента», если это не отдельный заранее спланированный тест. Power cap в реальной эксплуатации взаимодействует с boost, temperature и workload. Задача — увидеть поведение production-контура, а не лабораторную картинку без обычных ограничителей.

#!/usr/bin/env bash
set -euo pipefail
GPU_UUID="${1:?pass GPU UUID}"
CAP_WATTS="${2:?pass approved watts}"

nvidia-smi -i "$GPU_UUID" --power-limit="$CAP_WATTS"
nvidia-smi -i "$GPU_UUID" -q -d POWER
nvidia-smi --query-gpu=uuid,power.limit,power.default_limit --format=csv,noheader

Три gate вместо одной зелёной метрики

Gate 1 — configuration state. Целевой UUID сохранился, requested limit равен согласованному значению, enforced limit подтверждён, соседние GPU не изменились. Если этот gate не пройден, результаты нагрузки бессмысленны: вы тестируете неизвестное состояние.

Gate 2 — GPU data path. Смотрите power, total energy counter, SM/memory clocks, utilization, temperature и причины clock events. В актуальном DCGM поле DCGM_FI_DEV_CLOCKS_EVENT_REASONS заменяет deprecated throttle-reasons alias; отдельно доступны board power, total energy и время SW power cap. Справочник DCGM field IDs остаётся источником истины для единиц и поддержки.

Ожидаемо увидеть SW power cap при насыщенной нагрузке. Неожиданно — thermal slowdown или HW power brake. Они указывают на охлаждение, PSU/platform control или другой инцидент. Не записывайте hardware slowdown в «успешно достигли лимита».

Gate 3 — application readiness. TTFT, TPOT, throughput, queue time и error rate остаются внутри заранее определённого SLO. GPU может быть холоднее и потреблять меньше, но пользователю станет хуже из-за роста очереди. Именно application gate решает, можно ли продолжать rollout.

В каждом gate заранее задайте stop condition и owner. Infra owner откатывает limit и проверяет effective state; service owner останавливает подачу нагрузки и подтверждает возврат SLO. Такая граница ролей быстрее любого общего чата во время инцидента.

Как считать энергию на токен, а не радоваться низким ваттам

Средняя мощность сама по себе обманчива. GPU на 40 ватт ниже, но генерирующий на треть меньше токенов, может оказаться хуже по энергии на полезную работу. Нужны два монотонных счётчика на одном окне: delta total energy и delta generated tokens. DCGM публикует total energy consumption в миллиджоулях, а vLLM — counter с количеством generation tokens.

Формула проста: joules_per_token = delta_energy_mJ / 1000 / delta_tokens. Сравнивайте её только при одинаковом workload identity и достаточном числе завершённых запросов. Рядом храните TTFT, TPOT и throughput: хорошая энергоэффективность не даёт права нарушать latency SLO.

Для prefill-heavy и decode-heavy профилей результат может различаться. Prefill лучше насыщает матричные блоки, decode чаще ограничен памятью и batching. Поэтому один смешанный replay способен скрыть, какой класс запросов пострадал. Разделите отчёт хотя бы на два профиля и не усредняйте их в единственную «экономию».

Считать деньги лучше после технического gate. В статье о стоимости одного LLM-запроса на своём сервере показано, почему utilisation и простои влияют на экономику не меньше железа. Power cap добавляет ещё одну ось, но не заменяет расчёт полной стоимости и capacity.

#!/usr/bin/env bash
set -euo pipefail
VLLM_METRICS="${VLLM_METRICS:-http://127.0.0.1:8000/metrics}"
GPU_UUID="${1:?pass GPU UUID}"

date -u +%FT%TZ
nvidia-smi -i "$GPU_UUID" --query-gpu=uuid,power.draw,power.limit,clocks.current.sm,temperature.gpu --format=csv
curl --fail --silent --show-error "$VLLM_METRICS" |
  grep -E 'vllm:(generation_tokens|time_to_first_token_seconds|request_queue_time_seconds|request_time_per_output_token_seconds)'

Как читать результаты без самообмана

SLO сохранён, joules/token снизились. Это кандидат на следующую малую волну, но ещё не fleet policy. Выполните контрфакт: верните исходный cap на том же canary и повторите replay. Если метрики возвращаются к baseline, причинная связь стала сильнее.

Мощность снизилась, latency выросла. Инструмент работает, решение — нет. Возможно, cap пересёк точку, где частота падает быстрее, чем экономится энергия, или очередь усилила tail latency. Верните baseline и, если цель всё ещё актуальна, тестируйте менее строгую ступень отдельным запуском.

Ничего почти не изменилось. Это не бесплатная победа. GPU мог не достигать cap, окно оказалось коротким, workload был CPU-bound или счётчик токенов не совпал. Ищите отсутствие механизма прежде, чем расширять rollout.

Появились thermal/HW события. Остановитесь. Power cap не должен маскировать проблему питания или охлаждения. Сопоставьте результат с материалом о power density AI-серверов и стоек: board-level настройка не отменяет ограничений стойки, PSU, airflow и facility capacity.

Решение должно быть многомерным: application SLO, energy-per-token, стабильность, температура и capacity. Один график «ватты вниз» недостаточен для production change request.

Типичные ошибки эксперимента: где теряется причинность

Менять несколько параметров одновременно. Если вместе с power cap обновились драйвер, vLLM, quantization или batch scheduler, вывод не принадлежит ни одной переменной. Даже если сервис ускорился, нельзя утверждать, что причина в новом лимите. Разведите изменения по отдельным canary и оставьте одинаковый evidence bundle.

Сравнивать разные формы нагрузки. Средняя concurrency не описывает распределение prompt и output lengths. Один прогон может быть prefill-heavy, другой — decode-heavy; одинаковое число запросов при этом создаёт разную работу для GPU. Храните replay manifest, счётчики prompt/generation tokens и долю каждого профиля. Если production traffic нельзя повторить, хотя бы закрепите временные окна и объясните ограничение.

Игнорировать очередь. Throughput на завершённых запросах может выглядеть стабильным, пока waiting requests копятся. Через несколько минут tail latency внезапно выйдет за SLO. Поэтому queue time и waiting count проверяются на всём окне и после прекращения подачи: система должна успевать погасить хвост, а не только показывать хороший средний rate.

Принимать requested limit за enforced. Platform policy, module scope или out-of-band control способны сделать фактический ceiling ниже запрошенного. Читайте effective/enforced state и сохраняйте его рядом с desired value. Если они расходятся, owner сначала разбирается с control plane, а не подгоняет application benchmark под неизвестное состояние.

Считать idle-периоды экономией. Низкая средняя мощность во время пауз не показывает эффективность насыщенного inference. Отделяйте idle, warmup и измеряемое окно. Энергия на токен должна использовать delta counters только для окна, где запросы действительно обрабатывались; иначе паузы разных длительностей исказят результат.

Расширять cap на неоднородный fleet. Одинаковое число ватт не означает одинаковый operating point для разных GPU, BIOS, охлаждения и форм-факторов. Группируйте rollout по однородной hardware identity и проверяйте min/default/max на каждом устройстве. Policy должна выражать одобренное значение для конкретного класса, а не глобальную константу.

Забывать о multi-GPU синхронизации. В tensor parallel replica самый медленный rank способен удерживать остальные. Cap на одной карте может проявиться как рост collective wait и TPOT всей группы. Считайте такую replica неделимым canary-контуром, снимайте метрики по каждому UUID и откатывайте группу согласованно.

Объявлять успех без контрфакта. Температура в зале, соседняя нагрузка и cache state меняются со временем. Возврат к baseline на том же canary и повтор replay не делает эксперимент лабораторно идеальным, но хорошо отсеивает случайное совпадение. Если результат не воспроизводится в обратном направлении, зафиксируйте «эффект не доказан» вместо удобной истории.

Наконец, не превращайте runbook в гонку за минимальным cap. Цель задаётся ограничением стойки или экономической гипотезой, а guardrail — SLO. Как только следующий шаг не даёт полезного выигрыша или ухудшает application metric, эксперимент завершён. Production-инженерия выигрывает от ясной остановки, а не от самой низкой цифры в таблице.

Персистентность и автоматизация без скрытого drift

Классический NVML power limit не переживает reboot или driver unload. Persistence mode снижает вероятность unload между задачами, но не превращает произвольный write в вечную platform policy. Подробный runbook по жизненному циклу драйвера есть в статье про nvidia-persistenced для LLM.

Если cap нужен постоянно, автоматизация должна быть fail-closed. Перед write она сверяет ожидаемые UUID, модель GPU, допустимый диапазон и сохранённую policy. Если inventory изменился, новый GPU появился или UUID пропал, unit завершает работу ошибкой и не применяет лимит к «первой карте».

После write automation обязана прочитать effective state и экспортировать результат в наблюдаемость. Полезны отдельные алерты: desired != enforced, cap отсутствует после restart, power brake/thermal event активен, application SLO деградирует после смены policy. Последний алерт связывает инфраструктурную настройку с тем, за что отвечает сервис.

DCGM умеет поддерживать конфигурацию групп через lifecycle, но это отдельная policy surface. Не смешивайте DCGM enforcement и systemd-скрипт без единого owner: два контроллера могут спорить за значение. Выберите один источник desired state, документируйте его и оставьте audit trail.

#!/usr/bin/env bash
set -euo pipefail
EXPECTED_UUID="${EXPECTED_UUID:?}"
EXPECTED_NAME="${EXPECTED_NAME:?}"
DESIRED_WATTS="${DESIRED_WATTS:?}"

read -r UUID NAME MIN MAX < <( nvidia-smi -i "$expected_uuid" --query-gpu="uuid,name,power.min_limit,power.max_limit" --format="csv,noheader,nounits" | tr -d ',' awk '{$1="$1;print}'" ) [[ "$uuid"="=" ]] "$name"="=" "$expected_name" -v x="$DESIRED_WATTS" lo="$MIN" hi="$MAX" 'begin{exit !(x>=lo && x<=hi)}' nvidia-smi -i "$expected_uuid" --power-limit="$DESIRED_WATTS" -q -d power< code>

Rollout волнами и симметричный rollback

После успешного canary расширяйте изменение малыми волнами: одна replica, небольшая группа, затем согласованная доля fleet. Между волнами выдерживайте полное измеряемое окно для обоих workload profiles. Не переходите дальше, если canary попал в период низкой нагрузки или не набрал достаточного числа запросов для ваших SLO.

Для каждой волны фиксируйте список UUID, старое и новое значение, owner, start/end timestamp, application dashboard и stop conditions. На выделенных GPU-серверах такое ownership проще обеспечить: topology и power policy не делятся с неизвестным соседом. При выборе платформы сверяйте не только VRAM, но и power/cooling envelope; обзор конфигураций GPU-серверов для ML помогает поставить эту настройку в более широкий capacity plan.

Rollback симметричен rollout. Сначала остановите расширение и снимите/заморозьте новую нагрузку, затем восстановите сохранённый baseline limit по тем же UUID. Прочитайте enforced state, повторите GPU gate и тот же application replay. Возврат числа в nvidia-smi без возврата SLO — незавершённый rollback.

Проверьте automation: она не должна через минуту снова применить неудачный desired state. Если policy хранится в systemd, operator или CM-системе, сначала отмените источник desired state, затем меняйте устройство. Иначе получите «дребезг» конфигурации и спор двух владельцев.

Наконец, сохраните incident evidence. Даже отрицательный результат ценен: он показывает, для какого workload shape и SLO выбранный cap не подходит. Это лучше универсального числа, которое случайно пережило один спокойный вечер.

Итог: power cap — это проверяемая гипотеза, а не готовая оптимизация

Безопасный power cap начинается не с команды nvidia-smi -pl, а с evidence: стабильной GPU identity, диапазона ограничений, одинакового replay и application SLO. Затем идут один canary, три gate, расчёт энергии на полезный токен и контрфакт с возвратом baseline. Только после этого можно говорить о следующей волне.

Главная мысль практичная: меньше ватт не обязательно означает меньше затрат или лучший сервис. Решение считается удачным лишь тогда, когда power envelope стал управляемее, joules/token улучшились или остались приемлемыми, а TTFT, TPOT, очередь и error rate не вышли за границы. Если не совпало хотя бы одно из этих условий, честный rollback полезнее красивого графика.

Возьмите один изолированный GPU-контур, подготовьте evidence bundle и прогоните этот runbook на репрезентативной нагрузке. Для новой инфраструктуры заранее согласуйте power/cooling envelope и наблюдаемость с владельцем площадки: так настройка останется воспроизводимым инженерным решением, а не ручной магией после очередного пика.