В этом материале
Работающий nvidia-smi подтверждает доступ к utility/NVML, но не полную готовность CUDA-приложения. В NVIDIA container stack compute и utility подключают разные компоненты драйвера. Проверьте NVIDIA_DRIVER_CAPABILITIES вместе с device visibility, прежде чем переустанавливать весь стек.
Работающий nvidia-smi подтверждает доступ к utility/NVML, но не полную готовность CUDA-приложения. В NVIDIA container stack compute и utility подключают разные компоненты драйвера. Проверьте NVIDIA_DRIVER_CAPABILITIES вместе с device visibility, прежде чем переустанавливать весь стек.
Сохраните два независимых результата
Запишите host nvidia-smi, container nvidia-smi и точную ошибку небольшой CUDA-задачи. Установите, где именно выполняется каждая команда и каким пользователем. Для сравнения используйте один и тот же контейнер, а не разные образы с разными библиотеками. Доступность управляющего инструмента и успешное создание CUDA context относятся к разным функциям. Ошибка модели после инициализации CUDA также является следующим этапом, который нельзя объяснить только наличием utility capability.
Проверьте переменную capabilities
NVIDIA_DRIVER_CAPABILITIES определяет, какие драйверные библиотеки и бинарные компоненты монтируются в контейнер. Utility требуется для nvidia-smi и NVML, compute — для CUDA и OpenCL. Указанное значение заменяет набор capabilities, а не добавляет одну возможность к любому прежнему набору. Сохраните env из фактического запуска и runtime configuration. Не смешивайте эту переменную с Linux capabilities или seccomp: одинаковое слово capability обозначает здесь другой механизм и другую область настроек.
Разберите ограниченный пример
В учебном контейнере задано NVIDIA_DRIVER_CAPABILITIES=utility. Nvidiа-smi работает, а вычислительное приложение не получает нужного compute окружения. После явного задания compute,utility в тестовом запуске снова проверяются оба результата. Это демонстрирует различие назначения, но не гарантирует исправление любой CUDA ошибки. Несовместимый драйвер, архитектура, права и библиотечные конфликты могут сохраняться даже при правильно объявленном наборе capabilities и доступном устройстве.
| Слой | Проверяемый факт |
|---|---|
| Device injection | Нужный GPU передан контейнеру |
| Utility | Доступны NVML и nvidia-smi |
| Compute | Подключены компоненты CUDA |
| Приложение | Минимальная задача реально выполняется |
Измените минимальную настройку
Добавьте только требуемые функции драйвера в декларативный запуск и создайте новый тестовый контейнер. All расширяет набор компонентов, но скрывает, что действительно необходимо. Для inference обычно нужно понимать compute и наблюдаемость utility; graphics или video требуют отдельного назначения. Проверьте, не переопределяет ли template environment переменную после её задания. Также сохраните способ выбора устройств: правильные библиотеки не дают доступ к GPU, который runtime не передал в контейнер.
Подтвердите реальный compute path
Выполните согласованную маленькую CUDA-задачу и проверьте её результат, затем отдельно запуск приложения. Сохраните image digest, driver version, visibility и capabilities. Если минимальная задача работает, а модель нет, расследование переходит к её зависимостям и параметрам. Артефакт должен содержать оба результата, а не единственную зелёную строку nvidia-smi. Так проверка после обновления не сведётся к управляющему инструменту, который может успешно работать при всё ещё непригодном вычислительном окружении.
При сравнении избегайте установки дополнительных библиотек вручную в один контейнер. Такое отличие изменяет предмет опыта и не позволяет объяснить результат только выбранным набором driver capabilities в исходном декларативном запуске.
Связанные разборы: vllm install compatibility; vllm docker first launch.