NVIDIA CDI для rootless GPU-контейнеров: безопасный запуск LLM inference

После обновления драйвера GPU хост отвечает на nvidia-smi, а rootless-контейнер внезапно перестаёт видеть ускоритель. В панике сервис запускают с --privileged и пробрасывают все device nodes, возвращая API в строй ценой потерянной изоляции. NVIDIA CDI позволяет описать доступ к конкретному GPU или MIG-instance как проверяемый контракт для OCI runtime. Разберём путь от host baseline до vLLM, hardening, обновления и rollback без магических флагов.

Почему CDI удобнее старой связки runtime hook и privileged

Симптом обычно выглядит не как «сломался контейнерный runtime», а как внезапное исчезновение GPU после обновления драйвера, перезапуска daemon или переноса сервиса на другой engine. На хосте nvidia-smi исправен, а внутри контейнера библиотека возвращает Failed to initialize NVML или CUDA не видит устройств. Попытка быстро починить ситуацию через --privileged, проброс всех /dev/nvidia* и bind-mount системных библиотек возвращает сервис в строй, но одновременно размывает границу между workload и хостом.

Container Device Interface решает другую задачу: описывает устройство как набор точных изменений OCI-конфигурации. В CDI-spec могут входить нужные device nodes, mounts, переменные окружения и hooks. Runtime получает квалифицированное имя вроде nvidia.com/gpu=0, находит спецификацию и применяет только связанные с этим устройством изменения. Сам CDI не распределяет ресурсы и не ограничивает VRAM; scheduling, квоты и конкуренция остаются задачей оркестратора или операционной политики.

Для self-hosted inference это полезно по двум причинам. Во-первых, один и тот же селектор понимают CDI-совместимые Podman и новые версии Docker, поэтому deployment меньше зависит от vendor-specific синтаксиса. Во-вторых, rootless-контейнеру не требуется владеть daemon с root-правами. Это не делает GPU безопасным автоматически, но убирает распространённый анти-паттерн: запуск API модели от root только ради доступа к ускорителю.

Важно отделить CDI от Kubernetes DRA и device plugin. CDI отвечает за инъекцию уже выбранного устройства в OCI-контейнер, а выделение GPU между несколькими workloads находится выше. Для кластерного сценария полезен отдельный материал про Kubernetes DRA для GPU; здесь разбирается один dedicated-сервер и управляемый rootless inference-сервис.

Сначала проверяем хост: драйвер, cgroup v2 и версии runtime

Начинать нужно с хоста, а не с контейнера. Если драйвер не загрузился, устройство отсутствует в PCIe или после обновления остались несовместимые модули ядра, CDI лишь аккуратно опишет нерабочее состояние. Зафиксируйте модель GPU, UUID, версию драйвера, наличие MIG и доступность device nodes. Эти данные станут baseline для rollback: после любого изменения вы сможете сравнить не впечатления, а конкретный инвентарь.

На дату подготовки материала актуальная bugfix-линия NVIDIA Container Toolkit — 1.18.2. Автоматическая генерация CDI-spec появилась в 1.18.0 через systemd-механизм nvidia-cdi-refresh. CDI поддерживается toolkit с 1.12.0, но на старых релизах спецификацию обычно приходилось обновлять вручную. Не копируйте номер версии из статьи в production-пин без проверки репозитория вашей ОС: сначала прочитайте release notes и проверьте совместимость с текущим драйвером.

Для rootless Podman проверьте user namespaces, диапазоны в /etc/subuid и /etc/subgid, а также cgroup v2. Отдельно посмотрите владельцев и группы device nodes: rootless-процесс может увидеть CDI-spec, но получить permission denied при открытии устройства. На системах с SELinux понадобится осознанное решение о labels; бездумное глобальное отключение SELinux ради одного контейнера слишком дорогая уступка.

set -euo pipefail
nvidia-smi -L
nvidia-smi --query-gpu=index,uuid,name,driver_version --format=csv
ls -l /dev/nvidia* 2>/dev/null || true
stat -fc %T /sys/fs/cgroup
podman version
nvidia-ctk --version
systemctl status nvidia-cdi-refresh.path --no-pager || true
systemctl status nvidia-cdi-refresh.service --no-pager || true

Не включайте сервисы и не меняйте конфигурацию в первом проходе. Сначала сохраните вывод. Типичная ловушка — одновременно обновить драйвер, toolkit и Podman, а затем пытаться понять, какой слой изменил поведение. Для production лучше один change set, один canary-контейнер и заранее сформулированный критерий отката: устройство видно, CUDA context создаётся, health-check vLLM проходит, а соседний GPU остаётся недоступен.

Как создаётся CDI-spec и когда его нужно обновлять

CDI-spec — не список красивых имён, а машинное описание того, какие изменения runtime внесёт в OCI-spec контейнера. Стандартные каталоги поиска — /etc/cdi для статических файлов и /var/run/cdi для динамически создаваемых. NVIDIA в 1.18+ генерирует /var/run/cdi/nvidia.yaml сервисом nvidia-cdi-refresh при установке или обновлении toolkit, установке или обновлении драйвера и после перезагрузки.

Сначала используйте nvidia-ctk cdi list. Команда показывает квалифицированные имена полных GPU и, если включён MIG, отдельных экземпляров. Для диагностики полезен debug-режим: он сообщает ошибки чтения файлов из CDI-каталогов. Не редактируйте динамический YAML вручную: следующая регенерация перезапишет изменения, а ручная правка легко оставит ссылки на старые UUID или libraries.

У механизма refresh есть важные ограничения. Документация NVIDIA отдельно отмечает, что удаление драйвера и реконфигурация MIG не всегда автоматически инициируют корректное обновление. После изменения MIG layout перезапустите refresh, снова получите список устройств и лишь затем рестартуйте workload. Иначе контейнер может запросить CDI-имя, которого больше нет, либо получить другой экземпляр, чем ожидала конфигурация сервиса.

sudo systemctl restart nvidia-cdi-refresh.service
nvidia-ctk cdi list
nvidia-ctk --debug cdi list
sudo journalctl -u nvidia-cdi-refresh.service -n 100 --no-pager

# Ручной fallback, если сервис недоступен или нужен иной output:
sudo nvidia-ctk cdi generate --output=/var/run/cdi/nvidia.yaml
sudo test -s /var/run/cdi/nvidia.yaml

Считайте содержимое spec частью состояния узла. В CMDB или runbook достаточно хранить хеш файла, список CDI-имён, версию драйвера и toolkit; сам YAML с путями библиотек переносить между серверами не следует. Практический вопрос к команде: сможете ли вы после ночного обновления за минуту доказать, что имя nvidia.com/gpu=0 всё ещё указывает на тот же физический UUID? Если нет, baseline неполон.

Rootless Podman: выдаём GPU без root-демона

Podman особенно естественно сочетается с CDI: NVIDIA прямо рекомендует этот способ для Podman, а поддержка передачи CDI-имени через --device есть в современных версиях runtime. Rootless здесь означает, что контейнер создаёт пользовательский процесс, а не привилегированный daemon. Это уменьшает последствия компрометации control plane, но не отменяет доступ к самому GPU и host-библиотекам, которые нужны CUDA.

Запускайте первый smoke test не с vLLM, а с маленького CUDA-образа и nvidia-smi -L. Запросите один GPU по CDI-имени, затем проверьте отрицательное условие: остальные устройства не должны быть видны. Именно отрицательный тест ловит конфигурации, где старый OCI hook или переменная NVIDIA_VISIBLE_DEVICES параллельно раскрывают все ускорители.

В документации NVIDIA есть предупреждение о конфликте native CDI с legacy hook. Если на хосте остаётся /usr/share/containers/oci/hooks.d/oci-nvidia-hook.json, не смешивайте его с CDI и не задавайте одновременно NVIDIA_VISIBLE_DEVICES. Миграция должна иметь один источник инъекции устройства. Два независимых механизма дают труднообъяснимые mounts, двойные hooks и расхождение между staging и production.

GPU_DEVICE='nvidia.com/gpu=0'

podman run --rm   --device "$GPU_DEVICE"   --security-opt=label=disable   docker.io/nvidia/cuda:12.8.1-base-ubuntu24.04   nvidia-smi -L

podman run --rm   --device "$GPU_DEVICE"   --security-opt=label=disable   docker.io/nvidia/cuda:12.8.1-base-ubuntu24.04   nvidia-smi --query-gpu=index,uuid,name --format=csv

label=disable уместен как точечный параметр тестового контейнера в системах с SELinux, но это не универсальная рекомендация отключить маркировку. После smoke test разберите audit log и сузьте policy. Если device nodes принадлежат дополнительной группе, rootless-процессу может потребоваться корректно сохранённое group membership. Не лечите это правами 0666 на все /dev/nvidia*: после перезагрузки правило исчезнет, а до перезагрузки расширит доступ всем пользователям.

Выбираем конкретный GPU или MIG, а не выдаём all

Селектор nvidia.com/gpu=all удобен для проверки лабораторного стенда, но в production почти всегда слишком широк. Даже если inference использует один ускоритель, контейнер увидит остальные и сможет создать на них CUDA contexts. Это мешает изоляции, усложняет capacity planning и превращает ошибку в конфиге tensor parallel в инцидент на всём узле.

Выбирайте устройство по стабильному признаку и документируйте связь с физическим UUID. Индекс GPU может поменяться после изменения PCIe topology, BIOS или драйвера; UUID устойчивее, но конкретный синтаксис доступных CDI-имён нужно брать из nvidia-ctk cdi list, а не угадывать. Для MIG принцип тот же: сервис получает один нужный instance, а после реконфигурации layout список и spec должны быть обновлены до запуска workload.

CDI не резервирует устройство. Два rootless-контейнера могут запросить одно CDI-имя, если внешняя политика им это позволяет. На одиночном сервере заведите простой source of truth: systemd unit names, Quadlet-файлы или inventory, где каждому inference-сервису сопоставлен GPU UUID. В более крупной среде используйте scheduler. Статья про GPU scheduling между inference, training и batch подробно разбирает этот верхний слой.

Проверяли ли вы конфликт до ввода в эксплуатацию? Запустите два canary-контейнера с одним селектором и убедитесь, что ваша операционная политика обнаруживает коллизию. Без такого теста CDI честно выполнит оба запроса: стандарт описывает доступ к устройству, а не бизнес-правило эксклюзивности.

Запускаем vLLM в rootless-контейнере и не прячем секреты в командной строке

Официальная документация vLLM показывает запуск образа через Podman с CDI-селектором. Для production добавьте три вещи: read-only root filesystem там, где это совместимо с образом; отдельные writable mounts для model cache и compile cache; секрет Hugging Face через защищённый environment file или secret mechanism, а не буквальное значение в shell history. Также не публикуйте порт API на весь интернет до появления reverse proxy, аутентификации и rate limiting.

Параметр --ipc=host часто встречается в примерах из-за shared memory для multiprocessing. Это осознанное расширение границы, а не обязательный талисман производительности. Если модель и режим работы позволяют, сначала протестируйте ограниченный --shm-size. Для multi-GPU tensor parallel потребуется проверить выбранный набор устройств, NCCL и topology; не начинайте с all, чтобы скрыть неправильную раскладку.

GPU_DEVICE='nvidia.com/gpu=0'
MODEL='Qwen/Qwen3-0.6B'

podman run --rm --name vllm-canary   --device "$GPU_DEVICE"   --security-opt=label=disable   --read-only   --tmpfs /tmp:rw,noexec,nosuid,size=2g   --mount type=bind,src="$HOME/.cache/huggingface",dst=/root/.cache/huggingface,rw   --env-file "$HOME/.config/vllm/secrets.env"   --shm-size=4g   -p 127.0.0.1:8000:8000   docker.io/vllm/vllm-openai:latest   --model "$MODEL"

curl --fail --silent http://127.0.0.1:8000/health

Не используйте тег latest в постоянном unit: официальный пример удобен для знакомства, но production нужен digest или проверенный version tag. Сначала прогрейте canary, выполните health-check, короткий completion и запрос с максимальным допустимым контекстом. Наблюдайте VRAM, ошибки Xid и throttling. Для общей инфраструктурной картины полезен материал про NVIDIA NIM на выделенном GPU.

Успешный ответ /health ещё не доказывает изоляцию. Внутри контейнера повторно перечислите GPU, проверьте отсутствие лишних host mounts и убедитесь, что процесс работает не от root. Затем остановите контейнер и проверьте, что device access исчез вместе с ним. Такой negative path стоит дороже ещё одного скриншота, но именно он показывает, что граница действительно работает.

Docker и Compose: где CDI уже включён, а где нужен feature flag

Docker поддерживает CDI с версии 25.0.0, а начиная с 28.2.0 включает его по умолчанию. Для диапазона 25.0–28.1.1 поддержку нужно включить в daemon configuration и перезапустить daemon. Это чувствительная к версии деталь: не добавляйте feature flag вслепую на новый узел и не считайте старый Docker CDI-готовым только потому, что он принимает обычный --device /dev/....

Compose допускает CDI-синтаксис в services[].devices, например квалифицированное имя vendor device. Это отличается от GPU reservations через deploy.resources.reservations.devices, где используются driver, count, device_ids и обязательный capabilities. Оба пути могут работать, но для статьи про native CDI полезнее один явный селектор. Не смешивайте его с legacy runtime: nvidia и NVIDIA_VISIBLE_DEVICES в том же сервисе.

Rootless Docker имеет отдельную конфигурацию daemon в домашнем каталоге пользователя. NVIDIA описывает настройку через nvidia-ctk runtime configure --runtime=docker --config=$HOME/.config/docker/daemon.json и пользовательский restart daemon. При этом системный config.toml toolkit остаётся привилегированным объектом. Если цель — минимальная сложность на одном GPU-host, Podman с native CDI обычно даёт короче цепочку доверия.

services:
  inference:
    image: docker.io/vllm/vllm-openai:latest
    devices:
      - "nvidia.com/gpu=0"
    ports:
      - "127.0.0.1:8000:8000"
    volumes:
      - "${HOME}/.cache/huggingface:/root/.cache/huggingface"
    read_only: true
    tmpfs:
      - /tmp:size=2g,mode=1777
    command: ["--model", "Qwen/Qwen3-0.6B"]

Перед rollout зафиксируйте вывод docker info, версию Compose и фактический daemon config. Затем проведите тот же отрицательный тест видимости устройств, что и в Podman. Разница runtime не должна менять критерий успеха: один запрошенный GPU виден, другие не видны, workload работает без privileged и без ручного проброса набора host-библиотек.

Hardening: rootless полезен, но GPU остаётся частью доверенной базы

Rootless снижает привилегии container manager, однако процесс получает реальный доступ к GPU, драйверу ядра и части пользовательских библиотек. Уязвимость в model server, парсере модели или цепочке зависимостей всё ещё может стать точкой входа. Поэтому защищайте не только runtime: фиксируйте digest образа, проверяйте происхождение model weights, ограничивайте исходящую сеть после загрузки и не монтируйте домашний каталог целиком.

Секреты должны жить отдельно от образа и compose-файла. Hugging Face token часто нужен лишь при первой загрузке; после materialization модели его можно убрать из постоянного сервиса. Cache mount делайте отдельным каталогом с минимальными правами. Если несколько сервисов делят cache на запись, один скомпрометированный workload способен подменить файлы для другого. Для особо чувствительных моделей полезнее immutable artifact и read-only mount.

Сетевой порт vLLM слушайте на loopback или приватном интерфейсе. Перед ним поставьте reverse proxy с TLS, auth, rate limits и ограничением размера запроса. LLM endpoint дорогой: даже легитимные, но неограниченные запросы могут занять KV cache и вытеснить рабочий трафик. Rootless ничего не знает о такой атаке на ресурсный бюджет.

CDI-spec тоже входит в доверенную базу. Право записи в /etc/cdi или возможность подменить динамический файл фактически позволяют изменить mounts, hooks и device nodes будущих контейнеров. Контролируйте владельца, режим файлов и целостность генератора. Общие приёмы ограничения Linux-сервиса дополняет руководство по systemd sandboxing, а угрозы хранилищу моделей и данным — статья про безопасность AI-моделей на GPU-серверах.

Обновления драйвера и MIG: безопасный порядок без магии

Самый рискованный момент — не первая установка, а плановое обновление. Подготовьте canary до maintenance window: сохраните GPU UUID, CDI list, хеш spec, digest контейнера, набор параметров модели и контрольный запрос. Остановите новый admission трафика, дождитесь завершения активных запросов и только затем меняйте драйвер или toolkit. Одновременная смена модели и runtime уничтожает диагностическую ценность canary.

После обновления хоста проверьте nvidia-smi, дождитесь выполнения nvidia-cdi-refresh, затем сравните CDI inventory. При изменении MIG layout перезапустите refresh вручную и не поднимайте workload, пока ожидаемые имена instances не появились. Первым стартует smoke test, вторым — один inference canary, и только после контрольных запросов возвращается основной трафик.

Rollback тоже должен быть конкретным. Если новый toolkit не резолвит CDI selector, верните проверенный пакет и восстановите прежний driver/toolkit set; не переходите в аварии на --privileged как на постоянную конфигурацию. Если изменился MIG layout, восстановите схему, обновите spec и подтвердите UUID. Если контейнер теряет GPU после systemctl daemon-reload, сверяйтесь с актуальным troubleshooting NVIDIA: проблема известна для некоторых cgroup/systemd сочетаний, а CDI является одним из рекомендуемых способов сохранить явные device nodes.

Заранее решите, что важнее: быстрый rollback или сохранение новой версии драйвера. Для сервиса с жёстким SLA обычно надёжнее откатить весь согласованный набор, чем собирать гибрид из нового драйвера, старого toolkit и случайных библиотек. Такая смесь может пройти nvidia-smi, но упасть при создании CUDA context под реальной моделью.

Диагностика по слоям: от PCIe до model server

При отказе двигайтесь снизу вверх. Сначала хост: PCIe-устройство, модуль драйвера, nvidia-smi, device nodes. Затем CDI: существует ли spec, читается ли он без ошибок, содержит ли ожидаемый selector. Потом runtime: способен ли минимальный CUDA-контейнер увидеть ровно одно устройство. И лишь после этого разбирайте vLLM, модель, shared memory и параметры сервера.

Ошибка unresolvable CDI device указывает на каталог spec, имя или устаревший inventory. permission denied при существующем device name чаще связан с user namespace, группами или SELinux. Failed to initialize NVML после успешного старта заставляет проверить конфликт legacy hook, изменение device nodes и известные cgroup-проблемы. OOM в vLLM не является ошибкой CDI: устройство уже доступно, а VRAM не хватает модели, KV cache или concurrency.

Не начинайте диагностику с полной переустановки. Она стирает состояние, которое могло доказать причину. Сохраните journal refresh-сервиса, runtime events, container inspect, CDI list и хеш spec. Если хост обслуживает несколько GPU-задач, проверьте соседние workloads: одиночный отказ указывает на selector или контейнер, массовый — на драйвер, runtime либо общий spec.

set -euo pipefail
nvidia-smi -L
nvidia-ctk --debug cdi list
sudo journalctl -u nvidia-cdi-refresh.service -n 100 --no-pager

podman run --rm   --device nvidia.com/gpu=0   --security-opt=label=disable   docker.io/nvidia/cuda:12.8.1-base-ubuntu24.04   nvidia-smi -L

podman inspect vllm-canary 2>/dev/null || true
curl --fail --silent http://127.0.0.1:8000/health || true

Типичный реальный случай: после изменения MIG сервис сообщает, что device не найден. Команда видит исправный физический GPU и начинает менять permissions. Но слой ниже в порядке; устарел именно CDI inventory. Правильная последовательность — refresh, проверка новых qualified names, обновление selector сервиса и canary. Права здесь не лечат причину.

Production rollout: короткий чек-лист перед переключением трафика

Соберите rollout в два независимых gate. Infrastructure gate подтверждает драйвер, CDI, runtime и изоляцию устройств. Application gate подтверждает загрузку модели, health, контрольный inference, latency в допустимом диапазоне и отсутствие Xid/OOM. Если первый gate не пройден, не тратьте время на параметры vLLM; если второй падает при зелёном первом, не перестраивайте CDI.

• Зафиксированы версии driver, toolkit, Podman или Docker и digest образа.
• nvidia-ctk cdi list показывает ожидаемый GPU или MIG UUID.
• Canary видит только запрошенное устройство и работает без --privileged.
• Legacy hook и NVIDIA_VISIBLE_DEVICES не смешиваются с native CDI.
• Model cache и secrets смонтированы минимально; API слушает приватный адрес.
• Есть метрики GPU, health-check, контрольный запрос и критерий отката.
• После driver/MIG change spec обновлён и сравнен с baseline.

Не превращайте чек-лист в ритуал. У каждого пункта должен быть наблюдаемый результат. «GPU доступен» означает конкретный UUID внутри контейнера; «изоляция работает» означает, что соседний UUID недоступен; «rollback готов» означает проверенную команду и сохранённый набор версий, а не обещание найти старый пакет во время аварии.

Для dedicated GPU-host такая схема хорошо масштабируется: новый inference-сервис получает отдельного Linux-пользователя, rootless unit, CDI selector и собственные каталоги cache. Когда задач становится много и ручной inventory начинает расходиться, это сигнал перейти к scheduler, а не писать ещё один shell-скрипт распределения GPU.

Отдельно запишите операционную ответственность. Платформенная команда владеет драйвером, toolkit, CDI-spec и runtime; команда модели — образом, весами, параметрами vLLM и прикладным health-check. При инциденте это разделение сокращает круг поиска: если минимальный CUDA-контейнер проходит smoke test, infrastructure gate зелёный и расследование переходит к model server. Если он не видит выбранный UUID, прикладные настройки не меняют. Добавьте эти границы в on-call runbook вместе с командами сбора evidence и контактами владельцев. Такой простой договор особенно ценен ночью, когда соблазн расширить права контейнера сильнее желания сохранить диагностируемость.

Итог: CDI делает доступ к GPU явным и проверяемым

CDI не ускоряет модель и не заменяет GPU scheduler. Его ценность прозаичнее и поэтому важнее: доступ к ускорителю становится явным контрактом между host inventory и OCI runtime. Rootless Podman или Docker получает конкретное имя устройства, применяет vendor-описание и запускает workload без постоянного privileged-режима и ручного набора mounts.

Начните с одного canary на выделенном сервере: снимите baseline, проверьте refresh, запросите один GPU, докажите невидимость остальных и только затем запустите vLLM. После этого отрепетируйте driver update и rollback. Если оба пути воспроизводимы, у команды появляется не просто рабочий контейнер, а понятный production runbook.

Следующий практический шаг — выбрать один не-критичный inference-сервис и пройти чек-лист в maintenance window. Для новой площадки заранее подберите конфигурацию GPU-сервера с достаточной VRAM, RAM, NVMe и сетью, а CDI используйте как контролируемую границу доступа. Если инфраструктура подбирается с нуля, инженеры KingServers помогут сверить dedicated-конфигурацию с моделью, concurrency и планом эксплуатации.