GPU throttling в LLM inference: мониторинг через DCGM и Prometheus

LLM-сервис может внезапно отвечать медленнее, хотя очередь, VRAM и загрузка модели выглядят нормально. Причина нередко прячется ниже приложения: GPU упирается в лимит мощности или температуры, снижает частоту, а график utilization продолжает показывать почти идеальные 100%.

Такой инцидент легко принять за проблему batching, сети или планировщика и потратить часы на настройку не того слоя. Разберём рабочий контур DCGM Exporter, Prometheus и Alertmanager: какие метрики включить, как отличить power cap от thermal slowdown и что делать после алерта.

Почему GPU загружен на 100%, а токены идут медленнее

Высокая загрузка GPU отвечает только на вопрос, занят ли ускоритель. Она не показывает, с какой частотой выполняются ядра и почему эта частота ниже ожидаемой. В production картина знакомая: p95 time-to-first-token растёт, inter-token latency плывёт, а DCGM_FI_DEV_GPU_UTIL держится у потолка. Команда добавляет реплики, но новые узлы повторяют ту же деградацию.

Разделите три класса причин. Очередь перед inference-сервером увеличивает ожидание до начала обработки, но не обязана замедлять уже начатую генерацию. Давление на KV cache чаще проявляется вытеснением блоков, ошибками размещения или падением concurrency. Throttling меняет скорость вычисления: при сопоставимой модели, длине контекста и batch size падает SM clock, а рядом растёт время ограничения по мощности или температуре.

Не сравнивайте два произвольных окна. Возьмите одинаковый профиль нагрузки и сопоставьте четыре ряда: запросы и токены в секунду, utilization, SM clock и clock-event reasons. Один график вводит в заблуждение; четыре дают причинную картину. Если queue time стабилен, ITL ухудшается, частота падает, а violation растёт, гипотеза throttling становится проверяемой.

Рядом полезно держать разбор метрик AI Factory и руководство по GPU scheduling. Они закрывают goodput и планирование; здесь мы намеренно спускаемся к питанию, охлаждению и частотам конкретной карты.

Power cap, thermal slowdown и другие причины

Слово throttling часто используют как общий диагноз, хотя действие зависит от причины. Software power cap означает, что алгоритм управления питанием снижает частоты, удерживая GPU в заданном энергетическом конверте. Это не всегда неисправность. На плотном сервере лимит может быть осознанным компромиссом между скоростью одной карты и доступной мощностью стойки.

Thermal slowdown говорит о другой границе. Программное ограничение начинается возле максимальной рабочей температуры, аппаратное — у более жёсткого порога защиты. Повышение power limit здесь способно ухудшить ситуацию. Проверять нужно температуру входящего воздуха, обороты вентиляторов, загрязнение радиаторов, заглушки стойки, направление airflow и политику BMC.

Есть причины, которые нельзя автоматически назвать перегревом: sync boost ограничивает группу по самому медленному участнику, applications clocks фиксируют заданную частоту, а external power brake указывает на сигнал платформы или блока питания. В актуальной документации nvidia-smi события разделены, а часть старых названий помечена deprecated. Runbook должен опираться на конкретный event.

Представьте восемь GPU с одинаковой температурой, но аппаратный power brake только на одной. Это слабый аргумент в пользу общей проблемы охлаждения и сильный — в пользу проверки PSU, кабеля, riser или карты. Синхронный thermal violation на верхних серверах стойки, наоборот, часто указывает на рециркуляцию горячего воздуха.

Контур DCGM Exporter → Prometheus → Alertmanager

DCGM читает телеметрию NVIDIA GPU через драйвер и host engine. DCGM Exporter выбирает поля, добавляет метки устройства и, в Kubernetes-режиме, workload labels, затем отдаёт Prometheus-формат на /metrics. По официальному контракту dcgm-exporter стандартный listener — порт 9400, поддерживаемая платформа — Linux.

На bare metal разумно ставить один exporter на GPU-хост. В Kubernetes нормальная форма — DaemonSet или компонент NVIDIA GPU Operator. Один экземпляр на node видит локальные ускорители, а Prometheus связывает samples с node, pod и namespace. Запуск по exporter на каждый inference-pod размножает точки отказа и осложняет владение host engine.

У контура три независимых интервала: DCGM обновляет watched fields, exporter отдаёт значение, Prometheus делает scrape. Если температура собирается раз в 30 секунд, scrape каждые 5 секунд не создаёт новую физическую телеметрию. Быстрый collector при редком scrape тоже может скрыть короткое событие, если смотреть только gauges. NVIDIA рекомендует согласовать интервалы в руководстве по Prometheus.

Стартуйте с 15–30 секунд для общего мониторинга и ускоряйте только thermals, power и clock events, если этого требует SLO. Одновременно алертите up: отсутствие samples не должно выглядеть как здоровый ускоритель.

Развёртывание и первая проверка

До установки сверяйте совместимость GPU, драйвера и DCGM по актуальной матрице. Контейнеру нужен NVIDIA Container Toolkit и доступ к устройствам. В Kubernetes используйте GPU Operator, если он уже владеет драйвером и device plugin; отдельный Helm release удобен при раздельных жизненных циклах.

На standalone-хосте после установки проверьте GPU, сервис и endpoint. Фиксируйте версию пакета или образа в инфраструктурном коде. Копирование случайного latest-тега усложнит расследование, когда формат метрики или поддержка поля изменится.

nvidia-smi
systemctl status nvidia-dcgm-exporter --no-pager
curl --fail --silent http://127.0.0.1:9400/metrics \
  | grep -m1 '^DCGM_FI_DEV_GPU_UTIL'

В Kubernetes проверяйте не только Ready у DaemonSet. Убедитесь, что pod есть на каждом GPU-node, endpoint достижим из сети Prometheus, а метрики получили workload labels. Target может быть UP, но нужное поле отсутствовать из-за collector configuration, доступа к устройству или несовместимой связки driver/DCGM.

Endpoint лучше оставить в закрытой monitoring-сети. Exporter поддерживает web-config Prometheus exporter-toolkit для TLS и basic auth. Если chart-managed ServiceMonitor предполагает HTTP, а вы включили TLS, создайте собственную scrape-конфигурацию с нужными credentials.

Для общей платформы сверяйтесь со статьёй про Kubernetes для AI inference. DCGM закрывает hardware telemetry, но не заменяет метрики vLLM, KServe или gateway: без них вы увидите торможение карты, но не влияние на запрос.

Какие поля включить в collector

Набор должен покрывать состояние, причину и эффект. Для состояния нужны температура, power usage, GPU utilization и SM clock. Для причины — power/thermal violation и clock event reasons. Эффект измеряют application-level tokens/s, TTFT и ITL, которые приходят не из DCGM.

DCGM_FI_DEV_POWER_VIOLATION и DCGM_FI_DEV_THERMAL_VIOLATION относятся к shipped optional metrics и могут быть закомментированы в default collector. Согласно справочнику DCGM Exporter, их включают через custom CSV, YAML fields или Helm custom metrics.

DCGM_FI_DEV_GPU_UTIL, gauge, GPU utilization in percent.
DCGM_FI_DEV_GPU_TEMP, gauge, GPU temperature in Celsius.
DCGM_FI_DEV_POWER_USAGE, gauge, GPU power usage in watts.
DCGM_FI_DEV_SM_CLOCK, gauge, SM clock frequency in MHz.
DCGM_FI_DEV_POWER_VIOLATION, counter, Power violation time in microseconds.
DCGM_FI_DEV_THERMAL_VIOLATION, counter, Thermal violation time in microseconds.
DCGM_FI_DEV_CLOCKS_EVENT_REASONS, gauge, Active clock event reason bitmask.

CSV содержит ровно три поля в строке. Для новых конфигураций доступен YAML schema version 1 и отдельные watch groups. Изменение YAML требует restart, тогда как file-based CSV может перезагружаться. Exporter-owned cumulative counters хранятся в памяти и сбрасываются при recreation collector или restart, значит запросы обязаны переживать reset.

Не включайте все profiling fields «на будущее». На некоторых поколениях они требуют proprietary package и дополнительных привилегий, а поддержка определяется возможностями GPU. Для throttling базовых device fields достаточно. Короткий collector проще сопровождать и он меньше рискует раздуть cardinality.

Семантика счётчиков и типичные ошибки

Power и thermal violation — накопительные значения времени ограничения в микросекундах. Абсолютное число после недели работы почти бесполезно. Нужен прирост за окно: он показывает, сколько времени GPU находился под ограничением. При рестарте counter может сброситься, поэтому PromQL должен корректно обработать reset.

Clock event reasons может приходить как bitmask. Gauge удобен для ручной проверки, но неудобен для алерта. В актуальном exporter есть opt-in DCGM_EXP_CLOCK_EVENTS_TOTAL: он создаёт серию с label причины и считает переходы inactive→active. Это облегчает запросы, но состояние хранится в процессе и сбрасывается при его пересоздании.

Не путайте _COUNT и _TOTAL. Первый описывает события последнего collection window, второй предназначен для increase() и rate(). Частый scrape не гарантирует видимость микрособытия, если исходное поле собирается реже. Интервалы — часть дизайна, а не декоративный параметр.

Ещё одна ловушка — преждевременная агрегация. Средняя температура восьми карт может быть нормальной, когда одна уже замедляется. Для оперативного алерта сохраняйте UUID и node; для capacity review позже агрегируйте по модели, стойке или пулу. Проверяйте также unsupported или blank values: разные GPU поддерживают не одинаковый набор сенсоров.

PromQL для причинной диагностики

Смотрите запросы в одном диапазоне времени. Первые два показывают долю окна под power cap и thermal violation, третий — частоту, четвёртый — отсутствие exporter. Деление прироста микросекунд на длительность окна переводит delta в долю времени.

clamp_min(increase(DCGM_FI_DEV_POWER_VIOLATION[5m]), 0)
  / (300 * 1e6)

clamp_min(increase(DCGM_FI_DEV_THERMAL_VIOLATION[5m]), 0)
  / (300 * 1e6)

DCGM_FI_DEV_SM_CLOCK

up{job="dcgm-exporter"} == 0

Сравнивайте SM clock с baseline той же модели GPU и сопоставимого workload. Максимальная частота из случайного окна не годится как SLO: boost зависит от температуры, питания и типа kernel. Лучше создать recording rule baseline на здоровом прогоне и версионировать её вместе с профилем нагрузки.

Добавьте рядом rate(tokens_generated_total[5m]), p95 ITL, queue time и active sequences. Если violation растёт, clock падает и tokens/s деградирует при стабильном batch profile, связь сильнее. Если clock падает без violations, ищите applications clocks, sync group, idle transitions или ограничения самой workload.

Обязательно испытайте запросы на reset. Перезапустите exporter на canary-node и убедитесь, что increase() не создаёт гигантский spike. Затем устройте scrape gap и проверьте алерт missing target. Production PromQL должен переживать обслуживание наблюдаемости так же спокойно, как обычную смену нагрузки.

Как снять baseline и провести честный тест

Baseline строится не из «обычного рабочего дня», а из воспроизводимого сценария. Зафиксируйте модель и её ревизию, inference engine, квантизацию, длины prompt/output, concurrency, scheduler flags, batch policy и время прогрева. Запишите температуру помещения и размещение сервера. Иначе различие легко объяснить не power cap, а новым распределением запросов.

Прогоните несколько ступеней нагрузки: низкую, ожидаемую и близкую к пику. Для каждой сохраните TTFT, ITL, tokens/s, GPU utilization, SM clock, power usage, temperature и violation deltas. Не публикуйте универсальные числа: результат относится только к конкретной карте, шасси, охлаждению и версии ПО.

Полезен контролируемый power-cap experiment, но только в тестовом пуле и после сверки допустимых min/max устройства. Меняйте один параметр, возвращайте его к исходному значению и давайте системе стабилизироваться. Цель — найти форму зависимости latency, throughput и joules/token, а не «доказать», что максимальный лимит всегда быстрее.

Проверяли ли вы разницу между первым холодным прогоном и установившимся тепловым режимом? Десятиминутный тест может выглядеть здоровым, а через час карта выйдет на иной clock. Baseline должен длиться достаточно, чтобы температура шасси стабилизировалась, и включать повторяемость, а не единственную удачную выборку.

Алерты: отделяем симптом от причины

Не пейджите по одной высокой температуре. Порог зависит от модели и airflow, а близость к нему ещё не равна деградации. Причинный alert требует устойчивого прироста violation и, желательно, подтверждения влияния на clock или SLO. Warning может опираться на hardware-признак, critical — на hardware плюс пользовательский эффект.

groups:
  - name: gpu-throttling
    rules:
      - alert: GpuPowerCappingSustained
        expr: increase(DCGM_FI_DEV_POWER_VIOLATION[10m]) > 120e6
        for: 10m
        labels:
          severity: warning
      - alert: GpuThermalThrottling
        expr: increase(DCGM_FI_DEV_THERMAL_VIOLATION[5m]) > 30e6
        for: 5m
        labels:
          severity: critical
      - alert: DcgmExporterMissing
        expr: up{job="dcgm-exporter"} == 0
        for: 5m
        labels:
          severity: warning

Числа — стартовая гипотеза, не стандарт. На batch-пуле power capping может быть нормальной политикой эффективности; на latency-sensitive endpoint тот же режим нарушит SLO. Порог должен отражать риск для пользователя и подтверждаться baseline.

В annotations добавьте node, UUID, модель GPU и ссылку на runbook. Не помещайте в labels текущие temperature, power или clock: постоянно меняющиеся значения создадут новые alert instances. Thermal critical направляйте on-call инфраструктуры, sustained power cap без SLO impact — в очередь capacity/performance.

Связываем GPU с TTFT, ITL и стоимостью токена

DCGM сообщает, что карта ограничена, но не знает, заметил ли это клиент. Для LLM нужны TTFT, ITL, tokens/s, queue time, batch size и active sequences. Сопоставляйте по node и времени. Протаскивать request_id в GPU metrics нельзя: cardinality взорвётся, а честной связи при continuous batching всё равно не получится.

Диагностическая матрица проста. Queue time растёт, частота и violations стабильны — смотрите admission control и capacity. ITL ухудшается вместе с падением clock и ростом power violation — проверяйте power policy и профиль kernel. Thermal violation растёт на одной позиции стойки — подключайте datacenter operations и анализируйте airflow.

Экономика тоже меняется. Сервер может потреблять меньше ватт под cap, но выдавать непропорционально меньше токенов; тогда joules/token ухудшается. Может быть обратное: умеренный cap немного снижает throughput, зато повышает эффективность и позволяет разместить больше GPU в power budget. Считайте на workload, а не по паспортному TDP. Методика связана с разбором стоимости LLM-запроса.

Не сравнивайте разные модели или квантизации без фиксации условий. Batch size, контекст и speculative decoding способны изменить power draw сильнее, чем лимит. Для каждого эксперимента фиксируйте версии, dataset, concurrency, warm-up, окружающую температуру и длительность.

Runbook после срабатывания

Первое действие — не менять power limit, а подтвердить событие независимым источником. Снимите clocks, temperature, power draw, enforced limit и clock event reasons через nvidia-smi. Сохраните время, UUID и node, затем сравните с DCGM и application SLO.

nvidia-smi --query-gpu=timestamp,uuid,name,temperature.gpu,power.draw,power.limit,clocks.sm,utilization.gpu,pstate --format=csv
nvidia-smi -q -d PERFORMANCE,POWER,TEMPERATURE,CLOCK
curl --fail --silent http://127.0.0.1:9400/metrics \
  | grep -E 'DCGM_FI_DEV_(GPU_TEMP|POWER_USAGE|SM_CLOCK|POWER_VIOLATION|THERMAL_VIOLATION)'

При thermal slowdown идите от общего к частному: холодный коридор, давление и заглушки, обороты и ошибки вентиляторов, фильтры, радиаторы, соседние карты. Не открывайте крышку как «быстрый тест»: это меняет рассчитанный airflow и иногда ухудшает охлаждение пассивных GPU.

При power cap выясните, задан ли лимит политикой. Сопоставьте requested и enforced limit, проверьте питание шасси и события BMC. nvidia-smi -pl требует root и поддерживается не везде; значение должно лежать между min/max устройства. Меняйте его только через change process после проверки power budget сервера и стойки.

Если виден external power brake или XID, не маскируйте симптом повышением порога. Выведите node из latency-sensitive пула, сохраните diagnostics, проверьте PSU, кабели, riser и firmware. DCGM diagnostics запускайте в согласованное окно: нагрузочный тест способен повлиять на рабочий сервис.

Безопасный rollout и вывод

Разверните collector на canary-node. Проверьте поддержку полей, units, labels, reset behaviour и cardinality. Затем добавьте recording rules без alert routing и соберите baseline по разным часам, профилям batch и температуре помещения. Только после этого включайте warning и проверяйте доставку контролируемым событием.

Свяжите alert с владельцем и runbook. У каждого сигнала должны быть ответы: кто реагирует, что безопасно сделать сразу и когда вывести node из пула. В Kubernetes предусмотрите cordon/drain либо scheduling label, но учитывайте disruption budget и запас остальных GPU: аварийный drain не должен превратить локальную деградацию в общий overload.

Постоянный power cap в часы пик может быть не инцидентом, а неверным балансом power density, cooling и SLA. Здесь полезен материал про power density AI-серверов: решение часто лежит в размещении и инженерной инфраструктуре, а не во флаге inference engine.

Главный вывод: utilization без частоты и причин ограничения не показывает реальную производительность. DCGM Exporter даёт аппаратные факты, Prometheus — время и корреляцию, метрики inference — пользовательский контекст. Начните с canary, снимите baseline и прогоните контролируемый тест. Тогда мониторинг станет инструментом сохранения latency, throughput и предсказуемой стоимости LLM-сервиса.