GPU уходила в троттлинг на 61 градусе: пыль в стойке и наши замеры

MAATRIX

Если в nvidia-smi вы видите 61 градус на GPU, а рядом график клоков ползёт вниз, первая реакция — искать причину где угодно, только не в температуре: «61°C — это же холодно». Мы тоже так рассуждали и потратили два дня, гоняясь за призраками — соседями по хосту, лимитами питания, версией драйвера. А виновата оказалась именно температура, просто не та, которую показывал основной датчик. Разбираем, как мы к этому пришли, какие гипотезы отбросили по пути и что теперь стоит в мониторинге, чтобы больше не наступать на эти грабли.

Что сломалось: инференс то работал ровно, то полз

Сервис — инференс LLM на выделенном сервере с одной GPU, стабильный поток запросов от одного клиента, без резких скачков нагрузки. По логике всё должно было работать предсказуемо: одна и та же модель, один и тот же батч-размер, ровный трафик.

Проблема проявлялась волнами: 10-20 минут всё летало на ожидаемой скорости, затем p95 по latency начинал расти, а throughput проседал — без видимой связи с количеством запросов. В Grafana это выглядело как рваная пила: провал, восстановление, снова провал. Причём провалы случались и ночью, при минимальной нагрузке, что сразу отметало версию «просто не хватает GPU под текущий трафик».

Первым делом сопоставили дашборд latency с метрикой clocks.sm из nvidia-smi. Совпадение было почти один в один: как только просаживался буст-клок GPU, тут же росла latency. Дальше вопрос стал техническим — почему проседает клок, если по нагрузке ничего не изменилось.

Первые гипотезы, которые не подтвердились

Прежде чем разбираться в температурах, прогнали стандартный чек-лист причин просадки клоков на GPU-сервере.

Шумный сосед. Сервер выделенный, не shared через MIG или vGPU, но на всякий случай проверили nvidia-smi по процессам — на карте висел только один процесс инференса, память и SM-utilization соответствовали ожиданиям. Версия отпала.

Лимит питания. Проверили nvidia-smi -q -d POWER — текущий power limit совпадал с заданным при настройке сервера, никто его не менял, троттлинга по превышению мощности (SW Power Cap) в флагах не было.

Драйвер и CUDA. Посмотрели dmesg и nvidia-bug-report.sh на предмет Xid-ошибок и признаков «GPU упала с шины» — ничего похожего. Версии драйвера и CUDA-тулкита на сервере не менялись со времени последнего планового обслуживания, так что списать на «что-то само обновилось» тоже не получилось.

Температура в серверной. Проверили показания датчиков воздуха на входе в стойку и сопоставили с соседними серверами в том же ряду — ничего похожего на аномалию, остальные машины работали ровно. Это временно сняло гипотезу «просто жарко во всей комнате», хотя, забегая вперёд, к теме воздуха мы ещё вернёмся — просто проблема оказалась куда более локальной.

После того как отвалились самые очевидные версии, стало ясно: раз клоки проседают волнами и синхронно с чем-то, чего мы пока не видим, надо смотреть не на агрегированные метрики, а на сырые данные с самой карты — подробно и с высокой частотой опроса.

Что показали логи и метрики: парадокс с 61 градусом

Включили частый polling через:

nvidia-smi --query-gpu=timestamp,temperature.gpu,clocks.sm,clocks_throttle_reasons.active \
  --format=csv -l 2 >> gpu_watch.csv

Через несколько минут поймали момент просадки. Клок падал заметно ниже буста, а clocks_throttle_reasons.active показывал битовую маску с активными флагами SW_THERMAL_SLOWDOWN и HW_THERMAL_SLOWDOWN. То есть карта действительно троттлила по теплу — сомнений в причине уже не было. Вопрос был в другом: temperature.gpu в тот же момент показывал 61°C.

Это и есть парадокс, который дал название разбору. Для большинства современных карт NVIDIA порог теплового троттлинга по основному датчику (edge/die-average) обычно находится в районе 83-84°C — точное значение отличается от модели к модели и указано в спецификации конкретной карты, но в любом случае это далеко не 61. Получалось одно из двух: либо порог на этой карте был выставлен аномально низко (что маловероятно и не подтвердилось при проверке заводских лимитов), либо мы смотрели не на тот датчик.

Вот тут стало понятно, почему первые полдня мы искали причину не там: nvidia-smi по умолчанию выводит один агрегированный показатель температуры, и глазами он выглядит как «вся правда о нагреве карты». На деле это не так.

Докопались до датчика hotspot и памяти

У современных GPU не один температурный датчик, а несколько, и они измеряют разные вещи:

Именно по hotspot и memory junction температуре чаще всего срабатывает аппаратный троттлинг, а не по усреднённому edge-показателю. И вот эти два датчика простой запрос --query-gpu=temperature.gpu не показывает вообще — нужен полный дамп:

nvidia-smi -q -d TEMPERATURE

или метрики через DCGM-экспортер, если он развёрнут (DCGM_FI_DEV_GPU_TEMP для edge и отдельные поля для hotspot/memory, в зависимости от версии DCGM и модели карты). У нас DCGM в тот момент не стоял — только базовый nvidia-smi, поэтому и не видели полной картины до тех пор, пока не запросили её явно.

Когда подняли полный дамп в момент просадки, разница между edge-показателем и hotspot оказалась очень большой — настолько, что hotspot уверенно пересекал порог теплового троттлинга, пока edge продолжал показывать спокойные 61°C. Большая дельта между edge и hotspot сама по себе диагностический признак: в норме она не должна быть большой, потому что тепло от горячей точки должно эффективно расходиться по всему радиатору. Если дельта аномально велика — где-то в тракте отвода тепла плохой контакт или заблокирован поток воздуха.

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

Физический осмотр: пыль в стойке

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

Картина была предсказуемой постфактум и совершенно неочевидной заранее: рёбра радиатора GPU и лопасти вентиляторов были плотно забиты пылью. Не критично на глаз — сервер не выглядел заброшенным, — но плотности пыли в межрёберных промежутках хватило, чтобы серьёзно ухудшить теплообмен именно в зоне над hotspot-областью кристалла, при этом на остальной площади радиатора отвод тепла всё ещё работал более-менее приемлемо. Отсюда и парадокс: усреднённый edge-датчик «видел» кристалл в целом и показывал терпимые значения, а локальная горячая точка под забитым участком радиатора грелась куда сильнее и упиралась в аппаратный порог.

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

Так же проверили соседние блоки в стойке на предмет заглушек в свободных юнитах и организацию холодного/горячего коридора — тут всё было в порядке, рециркуляции тёплого воздуха не нашли. То есть проблема оказалась локальной для конкретного сервера, а не следствием проблем вентиляции всей стойки — что, кстати, было ещё одним аргументом в пользу физической, а не «климатической» причины.

Что изменили после инцидента

Сразу — механическая часть: сервер вынесли, продули радиатор и вентиляторы сжатым воздухом с соблюдением ESD-мер (заземление, без контакта с платой руками без браслета), проверили, что лопасти вентиляторов вращаются свободно и без люфта. После чистки повторили тот же тест с логированием nvidia-smi -q -d TEMPERATURE, HW/SW thermal slowdown флаги в проблемные моменты больше не поднимались.

Дальше — то, что должно было стоять в мониторинге с самого начала:

• В систему мониторинга добавили опрос clocks_throttle_reasons.active как отдельную метрику с алертом на любой активный тепловой флаг, а не только на превышение порога по edge-температуре. Это ближе к тому, что описано в материале про мониторинг здоровья железа — важно ловить не «температура высокая», а «карта реально троттлит прямо сейчас».
• Там, где это поддерживается платформой, стали смотреть на hotspot и memory junction температуру отдельно от edge, а не полагаться на единственное агрегированное число.
• Завели регулярный физический осмотр серверов с GPU по графику, а не по факту жалоб — пыль накапливается медленно и незаметно, и ждать, пока она вызовет инцидент, дороже, чем плановая чистка.
• Для удалённой диагностики железных проблем без выезда стали активнее использовать IPMI-датчики — если интересно, как это настроить, у нас есть отдельный разбор про IPMI и удалённое управление железом.
• Заодно вспомнили, что аналогичная логика — «показатель в норме, а троттлинг есть» — встречается и на процессорах, не только на GPU; механику мы разбирали в статье про троттлинг процессора в стойке.

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

Частые вопросы