В этом материале
Failed to initialize NVML: Unknown Error после systemctl daemon-reload может соответствовать документированной проблеме legacy NVIDIA runtime hook и обновления cgroup. Проверяйте режим и версии: тот же текст ошибки имеет и другие причины, поэтому совпадение сообщения недостаточно для диагноза.
Failed to initialize NVML: Unknown Error после systemctl daemon-reload может соответствовать документированной проблеме legacy NVIDIA runtime hook и обновления cgroup. Проверяйте режим и версии: тот же текст ошибки имеет и другие причины, поэтому совпадение сообщения недостаточно для диагноза.
Зафиксируйте порядок событий
Сохраните время последнего успешного доступа, daemon-reload или изменения ресурсов контейнера и первого отказа. Проверьте host nvidia-smi и сравните с доступом внутри того же контейнера. Если устройство недоступно и на хосте, область расследования шире runtime injection. Не вызывайте daemon-reload в рабочей среде только для подтверждения догадки. Сначала соберите уже существующие события обслуживания и запланируйте отдельное воспроизведение с допустимым влиянием на тестовый узел.
Определите механизм инъекции
NVIDIA описывает ситуацию, когда legacy hook меняет device/cgroup access вне полного знания low-level runtime. Последующее обновление контейнера может лишить его доступа к GPU. На некоторых systemd cgroup configurations daemon-reload достаточно для такого обновления. Версии runc и драйвера также влияют на отдельные варианты проблемы. Сохраните runtime mode, cgroup driver, versions и способ передачи устройства. CDI имеет другую модель инъекции, поэтому выводы о legacy режиме нельзя автоматически переносить на него.
Разделите два уровня доступности
В учебном случае host enumeration остаётся нормальной, а давно запущенный контейнер после события обслуживания теряет NVML access. Новый тестовый контейнер с тем же назначением снова видит GPU. Это поддерживает гипотезу нарушенного контейнерного доступа, но требует сопоставления режима и событий. Перезапуск приложения внутри того же повреждённого контейнера может не восстановить runtime configuration. Документация описывает пересоздание контейнера как восстановительное действие для рассматриваемого случая.
| Наблюдение | Значение для гипотезы |
|---|---|
| Хост видит устройство | Отказ локализуется дальше хоста |
| Старый контейнер не видит | Проверять runtime access |
| Новый видит | Сравнить созданную конфигурацию |
| Есть cgroup update | Проверить описанный механизм |
Подберите совместимое исправление
Документация перечисляет варианты mitigations, включая CDI и особенности запроса device nodes. Не меняйте cgroup driver всего кластера по одной статье: настройка связана с kubelet, runtime и политикой управления узлом. Выберите поддерживаемый способ для конкретной среды, сохраните конфигурацию и оцените соседние workload. Переход на CDI требует проверки discovery и device definitions, а не только замены одного флага в команде запуска.
Проверьте обслуживание повторно
На тестовом узле повторите предусмотренное изменение и подтвердите доступ до и после него. Сохраните версии, режим инъекции, UUID и результат небольшой вычислительной проверки отдельно от nvidia-smi. Артефакт должен явно указывать, какой сценарий воспроизведён и какой mitigation применён. Если ошибка появляется без cgroup update или только у одного приложения, продолжайте расследование библиотек, прав и других причин. Узкий документированный случай не следует превращать в универсальное объяснение любого сообщения NVML.
Связанные разборы: gpu maintenance change register; vllm install compatibility.