Проброс GPU в Docker: NVIDIA Container Toolkit

Контейнер не видит видеокарту по умолчанию. Docker не пробрасывает внутрь ни устройства /dev/nvidia*, ни библиотеки драйвера, поэтому nvidia-smi в свежем контейнере не найдётся. Чтобы проброс заработал, нужны три вещи: драйвер NVIDIA на хосте, установленный NVIDIA Container Toolkit и явный запрос GPU при запуске контейнера.

Проверка того, что всё собрано правильно, укладывается в одну команду:

sudo docker run --rm --gpus all ubuntu nvidia-smi

Если она выводит ту же таблицу, что nvidia-smi на хосте, — проброс работает. Ниже разобран каждый шаг до этого вывода, синтаксис для Docker Compose и семь типичных отказов.

Команды в статье проверены на стенде: Ubuntu 24.04, драйвер 580.95.05, Docker Engine 28.x, NVIDIA Container Toolkit 1.20.0. Теги CUDA-образов подобраны под этот драйвер; как пересчитать их под свой — в шаге 4.

Данные на 6 сентября 2026 года. К этой дате привязаны все версии, пороги драйверов и теги образов в тексте — источник каждой цифры указан рядом. Это самая скоропортящаяся часть статьи: пороги двигаются с каждым апдейтом CUDA, теги образов пересобираются. Даты релизов пакетов приведены отдельно и остаются верными: у них есть постоянный якорь в репозитории. Цен аренды в тексте нет намеренно — они двигаются чаще всего остального и устарели бы к моменту чтения; актуальные ставки лежат на странице с ценами.

Что должно быть на хосте до начала

Проброс настраивается на Linux с уже работающим драйвером. Container Toolkit не устанавливает драйвер и не заменяет его — он только отдаёт контейнеру то, что уже загружено в ядро хоста.

Список проверок перед стартом:

nvidia-smi на хосте выводит таблицу с картой и версией драйвера. Если нет — задача не в Docker, а в драйвере;
дистрибутив из списка поддерживаемых. Документация NVIDIA перечисляет Ubuntu 22.04, 24.04 и 26.04, Debian 11, CentOS 8, RHEL 8.x, 9.x и 10.x, Rocky Linux 9.7, Amazon Linux 2 и 2023, openSUSE/SLES 15.x. Точечный релиз у Rocky Linux — не опечатка: в самой таблице он записан именно так, тогда как остальные дистрибутивы перечислены семействами. Debian 12 в таблице отсутствует, но там же оговорено, что релизы работают и на платформах вне списка, включая более новые версии дистрибутивов;
Docker Engine не ниже 26.1.0 — причина этого порога разобрана в разделе про режимы рантайма;
права sudo: настройка правит /etc/docker/daemon.json и перезапускает демон;
время: около 10 минут на чистой машине.

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

Почему Docker сам по себе не видит видеокарту

Контейнер делит ядро с хостом, и модуль nvidia.ko в этом ядре уже загружен. Проблема не в ядре, а в пространстве имён: внутри контейнера нет ни файлов устройств /dev/nvidia0 и /dev/nvidiactl, ни пользовательских библиотек драйвера вроде libcuda.so.

NVIDIA Container Toolkit закрывает именно этот разрыв. При старте контейнера он подкладывает внутрь device-ноды и библиотеки драйвера, взятые с хоста, — то есть монтирует хостовый драйвер в контейнер.

Отсюда следует правило, которое объясняет большую часть последующих отказов: версия драйвера всегда хостовая, версия CUDA — из образа. Обновить CUDA сменой образа можно, обновить драйвер сменой образа нельзя.

Практическое следствие для проверки: nvidia-smi внутри контейнера показывает данные хостового драйвера. Строка CUDA Version в его выводе — это максимальная версия CUDA, которую поддерживает установленный драйвер, а не то, что лежит в образе. NVIDIA описывает это в матрице совместимости драйверов и CUDA: драйвер сообщает максимальную поддерживаемую версию и способен запускать приложения, собранные вплоть до неё.

Шаг 1. Установить NVIDIA Container Toolkit

По итогу шага в системе появятся пакет nvidia-container-toolkit и утилита nvidia-ctk. Ставим из репозитория NVIDIA — в репозиториях дистрибутивов пакет либо отсутствует, либо отстаёт на несколько релизов.

Подключение репозитория для Ubuntu и Debian по официальной инструкции:

sudo apt-get update && sudo apt-get install -y --no-install-recommends 
  ca-certificates curl gnupg2

curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg 
  --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg 
  && curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | 
    sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | 
    sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list

sudo apt-get update

Дальше установка с явным пином версии. Инструкция NVIDIA показывает 1.20.0-1; релиз v1.20.0 опубликован 13 августа 2026 года.

export NVIDIA_CONTAINER_TOOLKIT_VERSION=1.20.0-1
sudo apt-get install -y 
    nvidia-container-toolkit=${NVIDIA_CONTAINER_TOOLKIT_VERSION} 
    nvidia-container-toolkit-base=${NVIDIA_CONTAINER_TOOLKIT_VERSION} 
    libnvidia-container-tools=${NVIDIA_CONTAINER_TOOLKIT_VERSION} 
    libnvidia-container1=${NVIDIA_CONTAINER_TOOLKIT_VERSION}

Пин здесь не формальность. Смена минорной версии тулкита меняла режим работы по умолчанию — так было при переходе на 1.18.0. Зафиксированная версия делает пересборку ноды воспроизводимой.

Проверка шага: nvidia-ctk --version выводит номер версии.

Шаг 2. Прописать рантайм в Docker

По итогу шага Docker узнает про рантайм nvidia и сможет обрабатывать запросы GPU. Пакет сам по себе конфигурацию демона не правит — это отдельная команда.

sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

Первая команда добавляет в /etc/docker/daemon.json секцию runtimes с записью nvidia. Вторая применяет изменения: без перезапуска демона правка файла ни на что не влияет.

Полезно знать, как выглядит результат, — при разборе отказов этот файл смотрят первым:

{
	"runtimes": {
		"nvidia": {
			"args": [],
			"path": "nvidia-container-runtime"
		}
	}
}

Если секции runtimes в файле нет, шаг не выполнился. Если она есть, а контейнеры карту не видят, дело в перезапуске демона или в версии Docker.

Для rootless-режима Docker набор команд другой — конфиг лежит в домашнем каталоге, а управление cgroups нужно отключить:

nvidia-ctk runtime configure --runtime=docker --config=$HOME/.config/docker/daemon.json
sudo nvidia-ctk config --set nvidia-container-cli.no-cgroups --in-place
systemctl --user restart docker

Порядок здесь отличается от инструкции NVIDIA, где no-cgroups выставляется последней командой, уже после перезапуска демона. Правка /etc/nvidia-container-runtime/config.toml подхватывается при старте демона, поэтому либо она идёт до рестарта, как выше, либо после неё нужен второй systemctl --user restart docker.

Проверка шага: docker info | grep -i runtime показывает nvidia в списке доступных рантаймов.

Шаг 3. Проверить nvidia-smi в контейнере

По итогу шага у вас будет подтверждение, что контейнер видит карту.

sudo docker run --rm --gpus all ubuntu nvidia-smi

Обратите внимание на образ: это обычный ubuntu, без CUDA внутри. nvidia-smi и библиотеки драйвера приезжают с хоста, а не из образа, — именно поэтому проверка работает на пустом базовом образе.

Когда к `--gpus all` добавляют `--runtime=nvidia`

В разделе с примером нагрузки NVIDIA записывает ту же проверку как sudo docker run --rm --runtime=nvidia --gpus all ubuntu nvidia-smi. Флаги делают разное, и понимать разницу стоит до разбора отказов.

--gpus all идёт встроенным в Docker путём: демон сам подставляет в OCI-спецификацию контейнера hook nvidia-container-runtime-hook. Поэтому README рантайма и говорит, что напрямую с этим флагом совместим режим legacy — Docker подставляет ровно тот же hook. --runtime=nvidia вместо этого отдаёт контейнер рантайму NVIDIA, который с версии 1.18.0 по умолчанию работает в режиме JIT-CDI.

Дальше в статье используется короткая форма: для проверки проброса хватает --gpus all. Явный --runtime=nvidia добавляют, когда рантайм выбирается осознанно — при не-дефолтной конфигурации демона или при обходе отказа с NVML, где важен именно CDI-режим.

Что читать в выводе

Строка Driver Version — версия хостового драйвера, CUDA Version — потолок, который этот драйвер поддерживает. Обе цифры понадобятся в следующем шаге, поэтому выпишите их сразу.

Если вывода нет, посмотрите, что вообще попало внутрь контейнера:

docker run --rm --gpus all ubuntu 
  sh -c "ls /dev/nvidia* && ldconfig -p | grep libcuda"

Пустой вывод первой части означает, что device-ноды не смонтировались, — это шаг 2. Ноды на месте, а libcuda.so.1 не находится — набор возможностей урезан переменной окружения, разбор ниже.

Как отдать контейнеру не все карты

На ноде с несколькими картами отдавать контейнеру всё сразу обычно не нужно. Флаг --gpus принимает несколько форм; по справочнику Docker: --gpus all отдаёт все карты, --gpus '"device=0,2"' — конкретные по индексу, --gpus device=GPU-<uuid> — по UUID.

Сам UUID берётся с хоста, подставлять его наугад не из чего:

nvidia-smi --query-gpu=index,uuid,name --format=csv

Двойные кавычки внутри одинарных нужны в bash и zsh: без них шелл разберёт запятую по-своему. Все примеры в статье записаны для POSIX-шелла — в PowerShell и fish правила кавычек другие, и форму с индексами там нужно экранировать по правилам своего шелла.

Тот же выбор задаётся переменной NVIDIA_VISIBLE_DEVICES, которая принимает индексы, UUID, значение all или none. Она же управляет доступом изнутри Compose-файла и Dockerfile, где флага командной строки нет.

Шаг 4. Убедиться, что работает CUDA, а не только nvidia-smi

Прошедший nvidia-smi ещё не означает работающий инференс. Утилита обходится набором возможностей utility, тогда как CUDA-приложению нужен compute — это разные наборы библиотек драйвера.

Полноценная проверка запускает CUDA-образ, и тег этого образа выбирается по драйверу, а не наугад. Порядок действий такой: взять Driver Version из шага 3, найти в таблице самую нижнюю строку, порог которой ваш драйвер перекрывает, и только после этого подставить тег из той же строки в команду.

Версия CUDA в образе	Минимальный драйвер Linux	Тег базового образа
CUDA 12.4 Update 1	≥ 550.54.15	`12.4.1-base-ubuntu22.04`
CUDA 12.9 Update 1	≥ 575.57.08	`12.9.1-base-ubuntu24.04`
CUDA 13.0 GA	≥ 580.65.06	`13.0.0-base-ubuntu24.04`
CUDA 13.0 Update 1	≥ 580.82.07	`13.0.1-base-ubuntu24.04`
CUDA 13.0 Update 2	≥ 580.95.05	`13.0.2-base-ubuntu24.04`
CUDA 13.3 Update 1	≥ 610.43.02	`13.3.1-base-ubuntu24.04`

Источник порогов — release notes CUDA Toolkit, таблица «CUDA Toolkit and Corresponding Driver Versions». Теги образов сверены с репозиторием nvidia/cuda в Docker Hub.

Ключевое здесь — патч-версия тега соответствует апдейту CUDA, а не ветке целиком. Ветка 580 не даёт права взять любой тег 13.0.*: на драйвере 580.95.05 и новее подходит 13.0.2, на 580.82.07–580.95.04 — 13.0.1, на 580.65.06–580.82.06 — только 13.0.0. Если версия драйвера ниже указанного порога, образ либо не стартует, либо упадёт при первом вызове CUDA, и обновлять в этом случае нужно хост, а не образ.

На стенде из вступления драйвер 580.95.05, поэтому проверка идёт на 13.0.2:

docker run --rm --gpus all 
  nvidia/cuda:13.0.2-base-ubuntu24.04 nvidia-smi -L

Если на хосте драйвер 610.43.02 или новее, тот же вызов делается на свежей ветке — 13.3.1-base-ubuntu24.04. Плавающий latest не подходит ни в том, ни в другом случае: у него в любой момент может смениться мажорная версия CUDA, а вместе с ней и требование к драйверу.

Финальная проверка на уровне фреймворка — готовый образ PyTorch, у которого ветка CUDA подобрана по тому же правилу. Тег сверен со списком тегов pytorch/pytorch в Docker Hub; там же лежат сборки на других ветках CUDA, и выбирать между ними нужно по той же таблице порогов, что и теги nvidia/cuda:

docker run --rm --gpus all 
  pytorch/pytorch:2.14.0-cuda13.0-cudnn9-runtime 
  python -c "import torch; print(torch.cuda.is_available(), torch.cuda.get_device_name(0))"

Ответ True и название карты означают, что дальше можно ставить свои зависимости.

Шаг 5. Тот же проброс в Docker Compose

По итогу шага сервис в compose.yaml получает GPU без флагов в командной строке. Форм записи две, и выбирать между ними стоит осознанно.

Короткая появилась в Compose v2.30.0, выпущенном 29 октября 2024 года (release notes Docker Compose):

services:
  inference:
    image: nvidia/cuda:13.0.2-base-ubuntu24.04
    gpus: all
    command: nvidia-smi

Развёрнутая работает на всех версиях Compose V2 и позволяет задать количество карт или конкретные индексы. Её описывает справочник Docker по GPU в Compose:

services:
  inference:
    image: nvidia/cuda:13.0.2-base-ubuntu24.04
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              device_ids: ["0"]
              capabilities: [gpu]
    command: nvidia-smi

Ключ capabilities: [gpu] в развёрнутой форме обязателен — без него Compose откажется разворачивать сервис. В короткой форме эта возможность подразумевается по умолчанию.

Ключ version в файл не добавляется: Compose V2 его игнорирует и пишет предупреждение об устаревании. Готовые примеры стеков с этим синтаксисом разобраны в гайде по Ollama и Docker и в запуске ComfyUI на арендованной карте.

Три режима рантайма: legacy, JIT-CDI и явный CDI

Этот раздел важен при обновлении уже работающей ноды, а не при настройке с нуля. Версия 1.18.0, выпущенная 21 октября 2025 года, сменила режим работы рантайма по умолчанию: вместо legacy теперь используется CDI-спецификация, генерируемая на лету, — режим JIT-CDI. Одновременно появился systemd-юнит nvidia-cdi-refresh, который пересоздаёт спецификации после установки или обновления драйвера.

У смены режима есть цена. В release notes тулкита записано: сгенерированные CDI-спецификации не работают с рантаймами, которые не поддерживают схему CDI версии 0.7.0. Минимальные версии там же — Docker 26.1.0, containerd 1.7.16, Podman 5.1.0, CRI-O 1.30.0.

Практический вывод: на ноде с закреплённым старым Docker обновление тулкита пройдёт успешно, а запросы GPU после него отвалятся. Версию смотрят до обновления, а не после:

docker version --format '{{.Server.Version}}'

Сравнивать с порогом 26.1.0 нужно именно версию сервера. Клиент и демон обновляются независимо, и привычный docker --version показывает только клиент — на ноде с новым CLI и старым демоном он даст ложное успокоение.

Третий вариант — явный CDI, когда спецификация лежит файлом и её видно:

sudo nvidia-ctk cdi generate --output=/var/run/cdi/nvidia.yaml
nvidia-ctk cdi list

Docker Engine поддерживает CDI-устройства и включает их по умолчанию с версии 28.2.0. Пункт «CDI is now enabled by default» стоит в release notes Docker Engine 28 в разделе 28.2.0, а соответствующий PR moby/moby#49963 закрыт в milestone 28.2.0.

Единого ответа в документации при этом нет: справочник dockerd называет другую версию — «enabled by default since Docker Engine 28.3.0». Здесь взята цифра из release notes и PR, потому что оба привязаны к конкретному коммиту и milestone, тогда как справочник описывает поведение без ссылки на релиз.

На своей ноде расхождение проверяется без выбора между источниками: docker info показывает фактический статус CDI. Отключается настройка ключом features.cdi в daemon.json. Запрос устройства при явном CDI идёт через --device, а не через --gpus:

docker run --rm --device nvidia.com/gpu=all 
  nvidia/cuda:13.0.2-base-ubuntu24.04 nvidia-smi -L

Типичные отказы и что с ними делать

Семь разборов ниже — частые отказы проброса. Каждый начинается с точного текста ошибки, поэтому по нему удобно искать.

`could not select device driver ""` — Docker не знает про рантайм nvidia

Полный текст: could not select device driver "" with capabilities: [[gpu]]. Означает ровно то, что написано: демон не нашёл рантайм nvidia. Причин три — либо тулкит не установлен, либо после установки не выполнена nvidia-ctk runtime configure --runtime=docker, либо демон не перезапущен. Вернитесь к шагу 2 и пройдите его целиком, включая systemctl restart docker.

`Failed to initialize NVML: Unknown Error` — контейнер потерял карту на ходу

Контейнер стартовал нормально, а через какое-то время перестал видеть карту. Триггер описан в уведомлении NVIDIA в репозитории тулкита: при управлении cgroups через systemd команда systemctl daemon-reload отбирает у запущенных контейнеров устройства NVIDIA.

Отказ привязан к hook-режиму — то есть к пути, где устройства подкладывает nvidia-container-runtime-hook; так его и описывает раздел troubleshooting документации NVIDIA. На тулките 1.18.0 и новее, если контейнер запускается через --runtime=nvidia, по умолчанию работает JIT-CDI, и отказ почти не воспроизводится: при инъекции через CDI нужные device-ноды сразу попадают в конфигурацию контейнера.

Тот же раздел документации перечисляет три штатных обхода, равноправных между собой:

перевести Docker на cgroupfs: добавить {"exec-opts": ["native.cgroupdriver=cgroupfs"]} в /etc/docker/daemon.json и перезапустить демон. Настройка затрагивает всю ноду, не только GPU-контейнеры;
запрашивать device-ноды явно, флагами --device: /dev/nvidiactl, /dev/nvidia0, /dev/nvidia-uvm, /dev/nvidia-uvm-tools, /dev/nvidia-modeset, /dev/nvidia-caps;
инжектировать устройства через CDI — тот самый режим, который стал умолчанием в 1.18.0.

Четвёртый вариант не требует менять способ запуска: создать недостающие символьные ссылки в /dev/char, которые нужны свежим версиям runc, а у устройств NVIDIA отсутствуют. Утилита для этого появилась в тулките 1.12.0 — это записано в том же уведомлении NVIDIA вместе с готовым udev-правилом. Разовое лечение:

sudo nvidia-ctk system create-dev-char-symlinks --create-all

Постоянное правило, чтобы ссылки пересоздавались после загрузки драйвера:

ACTION=="add", DEVPATH=="/bus/pci/drivers/nvidia", RUN+="/usr/bin/nvidia-ctk system create-dev-char-symlinks --create-all"

Кладите файл в /etc/udev/rules.d/71-nvidia-dev-char.rules. NVIDIA в issue #48 приводит путь /lib/udev/rules.d/, но это вендорный каталог: его содержимое перезаписывается при обновлении пакета, тогда как правило в /etc обновление переживает и имеет приоритет при совпадении имён.

`nvml error: driver not loaded` — тулкит на месте, драйвера нет

Полный текст: nvidia-container-cli: initialization error: nvml error: driver not loaded. Проверьте nvidia-smi на хосте и загрузку модуля через lsmod | grep nvidia. Частый случай после обновления ядра: модуль собран под предыдущее ядро и не загрузился.

`nvidia-smi` работает, а `torch.cuda.is_available()` возвращает False

Три причины, для каждой указана своя проверка:

Причина	Что смотреть	Команда
CPU-сборка PyTorch	в версии нет суффикса с CUDA	`python -c "import torch; print(torch.__version__)"`
CUDA в образе новее драйвера	версию драйвера против таблицы из шага 4	`nvidia-smi --query-gpu=driver_version --format=csv`
Набор возможностей задан вручную	значение переменной внутри контейнера	`printenv NVIDIA_DRIVER_CAPABILITIES`

Третий случай стоит пояснить. Если переменная NVIDIA_DRIVER_CAPABILITIES пуста или не задана, контейнер получает набор utility,compute — так это описано в документации NVIDIA. Заданное значение этот набор заменяет, а не дополняет.

Отсюда и отказ: NVIDIA_DRIVER_CAPABILITIES=utility оставит nvidia-smi рабочим и отберёт compute, поэтому утилита отвечает, а PyTorch карту не находит. Образы nvidia/cuda прописывают ту же пару явно, строкой ENV NVIDIA_DRIVER_CAPABILITIES compute,utility, — на них поведение по умолчанию не меняется.

Библиотеки cuDNN и cuBLAS не находятся при загрузке модели

Отдельный от драйвера класс проблем: libcudnn и libcublas в образ приезжают не с хоста, а из базового образа. Сборка FROM python:3.12-slim соберётся и запустится, но упадёт при первом обращении к GPU. Берите теги вида 13.0.2-cudnn-runtime-ubuntu24.04. Разбор такой сборки на конкретном сервисе есть в гайде по Whisper на GPU.

`ffmpeg` не находит кодировщик `h264_nvenc` — не хватает возможности video

Аппаратные кодеки требуют возможности video, которой нет ни в наборе по умолчанию utility,compute, ни в ENV образов nvidia/cuda. Перечислите нужные возможности целиком, помня, что переменная заменяет набор:

docker run --rm --gpus all 
  -e NVIDIA_DRIVER_CAPABILITIES=compute,utility,video 
  my-ffmpeg-image

Контейнер видит карту, но падает по памяти

Проброс здесь ни при чём: карта отдана целиком, и --gpus all не ограничивает потребление. Причины и обходные пути разобраны в разборе CUDA out of memory.

Как выглядит успешный результат

Три команды подряд отрабатывают без ошибок: nvidia-smi на хосте, nvidia-smi в контейнере и torch.cuda.is_available() внутри рабочего образа. Сравнивать полные таблицы nvidia-smi неудобно — в них есть меняющиеся поля вроде загрузки и температуры. Поэтому берите машиночитаемую форму, где сравнение сводится к посимвольному совпадению двух строк:

nvidia-smi --query-gpu=driver_version,name,memory.total --format=csv

docker run --rm --gpus all ubuntu 
  nvidia-smi --query-gpu=driver_version,name,memory.total --format=csv

Обе команды должны дать один и тот же вывод: та же версия драйвера, тот же список карт в том же порядке, тот же объём памяти. Расхождение по версии драйвера означает, что в контейнер попали библиотеки не от того драйвера, что загружен в ядро, — так бывает после обновления пакетов драйвера без перезагрузки ноды. Разный список карт — не отказ проброса, а урезанная выборка: смотрите --gpus и NVIDIA_VISIBLE_DEVICES.

По GPU-времени отладка почти ничего не стоит. Три проверочные команды занимают около двух минут, то есть одну тридцатую часа. Пересчёт под свою карту — деление часовой ставки на 30: при 100 ₽/час прогон обойдётся примерно в 3,3 ₽, при 400 ₽/час — примерно в 13 ₽. Конкретные ставки по всем картам каталога смотрите на странице с ценами: нижняя граница обновляется в течение часа, поэтому в текст она не зашита.

Если карта у вас уже есть — своя или в корпоративном кластере — арендовать ничего не нужно: Container Toolkit ставится на неё бесплатно по инструкции выше. Аренда закрывает другую задачу: получить карту, которой нет, или проверить код на железе, которое вы ещё не купили. Выбор конкретной модели под задачу разобран в гайде по подбору GPU, а расчёт объёма памяти под инференс — в справочнике по VRAM для LLM.

Нужна карта, на которой это уже настроено?

Инстансы YouGPU идут с установленным драйвером, Docker и NVIDIA Container Toolkit — проброс работает из коробки.

Выбрать GPU-сервер

Что в итоге

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

nvidia-smi на хосте — таблица есть? Нет — задача в драйвере, Docker ни при чём.
docker version --format '{{.Server.Version}}' — версия сервера не ниже 26.1.0?
docker info | grep -i runtime — рантайм nvidia в списке?
docker run --rm --gpus all ubuntu nvidia-smi — вывод совпадает с хостовым?
nvidia-smi -L в CUDA-образе — тег подобран по таблице порогов из шага 4, а не по ветке драйвера?
printenv NVIDIA_DRIVER_CAPABILITIES в рабочем образе — набор не урезан до utility?

Пункты 2 и 5 дают самые неочевидные поломки. В первом обновление тулкита проходит успешно, а запуск контейнеров перестаёт работать; во втором образ с подходящей на вид веткой CUDA падает из-за патч-версии, требующей более свежего драйвера.