Когда самый мощный GPU виснет в виртуалке
Представьте: вы вложили $30,000 в сервер с двумя RTX 5000 Blackwell, настроили VFIO passthrough для ML-задач, запустили обучение — и через час VM падает с ошибкой GSP heartbeat timeout. Хост жив, но GPU заблокирован. Ребут? Не торопитесь. Есть способы оживить карту без полного выключения сервера.
Сердце Blackwell, которое остановилось
GSP (GPU System Processor) — это встроенный микроконтроллер на всех картах Blackwell, отвечающий за управление питанием, температурами и общение с драйвером. При VFIO passthrough хост-система теряет прямой контроль над GPU, но GSP продолжает работать внутри виртуальной машины. Если VM зависает или драйвер внутри неё не успевает отвечать на heartbeat-пакеты, GSP уходит в таймаут и блокирует доступ к карте. В теории это должно защищать оборудование, но на практике — просто выкидывает вас из работы.
Особенно остро проблема стоит на картах с пассивным охлаждением и без сброса по I2C — GSP timeout не лечится простым отсоединением GPU от виртуалки. Хост видит карту, но nvidia-smi показывает ошибку GPU is lost.
Почему GSP падает в обморок (и виноват ли драйвер 580.105.08)
Nvidia много раз пыталась исправить эту историю. В драйвере 580.105.08 (май 2026) компания добавила новые механизмы восстановления heartbeat и увеличила таймаут по умолчанию, но для VFIO-сценариев этого часто недостаточно. Как мы уже писали в статье про passthrough RTX Pro в Proxmox, корень проблемы — в том, что GSP firmware не знает о виртуализации. Он думает, что карта работает в физической системе, и ждёт отклика от драйвера с той же частотой. Когда VM временно замирает (например, из-за дискового I/O или миграции), heartbeat рвётся.
А если вы используете карты с NVLink (как в мульти-GPU сборках для LLM), сбой на одном GPU может заблокировать весь линк. Помните историю с vLLM на двух RTX 6000? Там были похожие грабли с GSP, но на Ада-поколении проблема лечилась ребутом VM. На Blackwell — нет.
Реанимация без дефибриллятора
Полностью убрать GSP нельзя — это часть архитектуры Blackwell. Но есть методы, которые снижают риск или позволяют вернуть карту к жизни без перезагрузки хоста. Вот рабочие варианты, проверенные на практике:
- Отключение GSP firmware полностью — параметр модуля
NVreg_EnableGSP_Firmware=0в/etc/modprobe.d/nvidia.conf. В этом случае GSP не участвует в управлении, но вы теряете некоторые функции энергосбережения и мониторинга. Для серверов с постоянной нагрузкой — оправдано. - Увеличение таймаута heartbeat — через переменную окружения
NVreg_RegistryDwordsможно задать значениеRMGfxHeartbeatTimeout=120(секунды). Драйвер 580.105.08 поддерживает этот ключ для Blackwell. - Принудительный сброс GPU через sysfs — после падения VM вы можете выполнить
echo 1 > /sys/bus/pci/devices/0000:xx:00.0/sriov/.../reset(если поддерживается) или использоватьnvidia-smi -rдля перезапуска GSP. На некоторых UEFI-системах это работает даже без отключения питания. - Использование open-драйвера nvidia-open — в версии 580.105.08
nvidia-openполучил патчи, которые позволяют сбросить GSP черезnvidia-smi -rбез выгрузки модуля.
Важный нюанс: если ваша VM использует PCIe passthrough с vfio-pci, не забудьте после сброса GPU перезапустить VM — карта может не появиться в гостевой системе без нового Rescan bus.
Что нового в драйвере 580.105.08 (и почему это не панацея)
Nvidia наконец-то признала, что GSP timeout — одна из главных головных болей для дата-центров Blackwell. В релизе от 15 мая 2026 года компания добавила:
- Логику автоматического восстановления heartbeat для VFIO-гостевых драйверов (только для R535+).
- Параметр
NVreg_GPUFaultRecovery=1, который при включении перезагружает GSP без участия хостового драйвера. - Поддержку
sriov_resetдля Blackwell — теперь можно делать мягкий сброс без полного выключения.
Но, как показывает опыт с RTX 6000, которая не POSTилась, даже новейшие драйверы не гарантируют стабильность. В некоторых системах (особенно с материнскими платами H13SSL от Supermicro) GSP упорно вылетает при высоких нагрузках. Иногда помогает отключение ASPM в BIOS или увеличение задержки после сброса на уровне PCIe.
Кстати, если вы столкнулись с тем, что после GSP timeout карта начинает шуметь (вентиляторы на 100%), не спешите паниковать — это штатная реакция на потерю управления. У нас есть проверенный способ успокоить вентиляторы, даже если GPU числится как lost.
Так ребута всё-таки не будет?
Будет — если ничего не предпринять. Но с правильными настройками (отключение GSP, увеличение таймаутов, использование nvidia-open и сброса через sysfs) вы сможете пережить GSP timeout без перезагрузки хоста. Потеряете только одну VM, а не весь сервер. Для дата-центров с ценой за аптайм — это золото.
А если карта всё-таки окончательно зависла и не отвечает даже на nvidia-smi, последнее средство — физическое выключение блока питания на несколько секунд. Но это, увы, уже почти ребут. Надеемся, в следующем драйвере Nvidia наконец-то запилит полноценный remote reset для GSP. А пока — сохраняйте себе этот текст.
