CUDA, cuDNN a NVIDIA Container Toolkit: rozumná cesta k nastaveniu AI servera

Máte čerstvo osadený server so štyrmi alebo ôsmimi GPU, Ubuntu 22.04 alebo 24.04, pripnutý ovládač NVIDIA (podľa L01), a nvidia-smi vracia rozumné čísla. To je úplný základ. Nad ním sedí nepríjemný stack — CUDA, cuDNN, container toolkit, runtimy, NGC image — ktorý väčšina návodov odbaví mávnutím ruky. Tento článok vedie od ovládača až po bod, kde docker run --gpus all rozsvieti každú kartu a kontajner s vLLM začne servírovať tokeny.

Má jasný názor na to, ktorou cestou ísť, a úprimne hovorí, ktorá z nich bolí.

Trojica ovládač / runtime / toolkit

Pod hlavičkou „CUDA“ sa dodávajú tri veci a ľudia si ich neustále zamieňajú:

Pri behu je rozhodujúci ovládač. Ovládač podporuje maximálnu verziu CUDA runtime; runtime musí byť presne tá alebo staršia. Toolkit potrebujete len vtedy, ak CUDA kód sami kompilujete — pri 95% inštalácií na hostiteľovi nepotrebujete nvcc vôbec.

Práve preto fungujú kontajnery: image si nesie vlastný CUDA runtime, hostiteľ potrebuje len ovládač. Jediné, čo musí sedieť, je ovládač na hostiteľovi. Všetko ostatné je prenosné.

┌─────────────────────────────────────────────────┐
│ Container: PyTorch 2.9 + CUDA 13.0 runtime      │  ← shipped in image
│ Container: vLLM + CUDA 13.0 runtime             │  ← shipped in image
├─────────────────────────────────────────────────┤
│ Host: NVIDIA driver 570.x                       │  ← only thing host needs
│ Host: nvidia-container-toolkit                  │  ← bridges driver → container
└─────────────────────────────────────────────────┘

Tento obrázok je rozdiel medzi jedným popoludním práce a tromi dňami pekla závislostí.

CUDA 12.x alebo 13.x — čo si vybrať

V máji 2026 sa aktívne používajú obe. Úprimná matica pre workloady, ktoré bežia na serveroch Kentino:

Predvoľbou Kentino pri nových zostavách je CUDA 13.0. Podporované je každé GPU z portfólia (5090, 4090, RTX Pro 6000 Blackwell, L40, L4), vLLM už na PyPI predvolene dodáva wheels pre 13.0 a image vllm/vllm-openai používa 13.0, PyTorch 2.11 (voči ktorému sa vLLM zostavuje) je postavený na 13.0 a nové funkcie (FlashAttention 3 na Blackwelli, FP8 tréningové kernely) mieria najskôr na 13.x.

Na 12.8 zostaňte len vtedy, ak: reprodukujete pripnutý benchmark, SDK dodávateľa sa ešte neposunulo, alebo máte výhradne karty spred Blackwellu. Pri nových inštaláciách nič staršie ako 12.4 — chyby boli upstream opravené pred dvoma rokmi.

Čistá inštalácia ovládača a CUDA

Ubuntu 24.04 LTS (22.04 je identické). Čistou cestou je CUDA apt repozitár od NVIDIA:

wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2404/x86_64/cuda-keyring_1.1-1_all.deb
sudo dpkg -i cuda-keyring_1.1-1_all.deb
sudo apt update

# Driver + CUDA runtime libs. No nvcc — only what apps need to run.
sudo apt install -y cuda-drivers-570 cuda-runtime-13-0

# Optional full toolkit (nvcc, headers). Only if you compile on the host.
# sudo apt install -y cuda-toolkit-13-0

sudo reboot

Po reštarte by nvidia-smi mal hlásiť ovládač 570.x a CUDA 13.0. Pasce, ktorým sa treba vyhnúť:

• Neinštalujte meta-balík cuda, pokiaľ nechcete naozaj všetko. Stiahne toolkit, ukážky, GDS, Nsight a pripne balíky, ktoré ste nechceli. Vyberte explicitne cuda-runtime-13-0 alebo cuda-toolkit-13-0.
• Pripnite ovládač tak, aby unattended-upgrades nemohlo prevaliť jadrový modul: sudo apt-mark hold cuda-drivers cuda-drivers-570 nvidia-driver-570 nvidia-dkms-570 libnvidia-compute-570.
• Vždy len jedna vetva ovládača. Miešanie balíkov 550 a 570 vytvorí systém, ktorý nabootuje, ale v ktorom nvidia-smi vráti nejasnú chybu o nezhode verzií. Opravou je apt purge '*nvidia*' '*cuda*' a začať odznova — lepšie je sa tam vôbec nedostať.

cuDNN — apt alebo tarball?

cuDNN je knižnica primitív pre deep learning — konvolúcia, attention, RNN. Závisia od nej PyTorch / TensorFlow / JAX. Od verzie 9.x existujú dve cesty inštalácie.

apt (odporúčané):

sudo apt install -y libcudnn9-cuda-13 libcudnn9-dev-cuda-13

Inštaluje sa do /usr/lib/x86_64-linux-gnu/, zachytí ju dynamický linker a integruje sa so správcom balíkov, takže bezpečnostné aktualizácie prichádzajú automaticky. Naraz môže byť nainštalovaná len jedna CUDA verzia cuDNN 9 — cez apt teda nemôžu byť libcudnn9-cuda-12 a libcudnn9-cuda-13 vedľa seba.

Tarball:

# Fetch from the redist manifest at developer.download.nvidia.com/compute/cudnn/redist/
tar -xf cudnn-linux-x86_64-9.5.0.x_cuda13-archive.tar.xz
sudo cp -r cudnn-linux-x86_64-*/include/* /usr/local/cuda/include/
sudo cp -r cudnn-linux-x86_64-*/lib/* /usr/local/cuda/lib64/

Tarball má zmysel pri viacerých verziách cuDNN na jednom hostiteľovi, pri balíkoch pre air-gapped prostredia alebo pri pripínaní mikroverzií. Vo všetkom ostatnom: apt. Dokumentácia NVIDIA odporúča všade, kde sa dá, distribučné balíky — tarball nie je inštalátor, ale redistribučný archív.

Úprimná odpoveď: ak používate NGC kontajnery, cuDNN na hostiteľa vôbec neinštalujte. Je súčasťou image.

Kontajnery vs. bare-metal — kedy čo

Najväčšie rozhodnutie v celom stacku, na ktoré neexistuje univerzálna odpoveď. Kompromisy tak, ako ich vidíme na reálnych zostavách Kentino:

Rozdiel vo výkone CUDA medzi kontajnerom a bare-metalom je na moderných jadrách zanedbateľný — v najhoršom jednotky percent, zvyčajne šum. Kto tvrdí opak, meria úložisko alebo sieť, nie výpočet na GPU.

Bare-metal: honba za poslednými 2–3% kvôli publikácii, ladenie kernelov pomocou cuda-gdb / compute-sanitizer / Nsight, kde kontajnerová vrstva prekáža, alebo jediný proces, ktorý vlastní stroj na roky.

Kontajnery (predvoľba Kentino): stroje s viacerými používateľmi, PyTorch 2.5 a 2.11 vedľa seba, výmena inferenčných frameworkov (vLLM, SGLang, TensorRT-LLM) bez prestavby hostiteľa, alebo nasadenie, ktoré stačí docker pull na nový server a za päť minút beží.

Pre robotické laboratórium alebo výskumnú skupinu: kontajnery. Pre benchmarkový rig s jedinou úlohou je bare-metal v poriadku.

nvidia-container-toolkit — čo to je a ako ho nastaviť

Toolkit je lepidlo, ktoré dáva kontajneru prístup ku GPU hostiteľa. Bez neho nvidia-smi vo vnútri kontajnera zlyhá. S ním kontajner vidí ovládač, zariadenia aj vložený runtime stub.

Inštalácia:

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 update && sudo apt install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

# Smoke test
docker run --rm --gpus all nvidia/cuda:13.0.0-base-ubuntu24.04 nvidia-smi

Posledný príkaz by mal zvnútra kontajnera ukázať výstup nvidia-smi hostiteľa. Ak áno, stack je zapojený.

Podman

Podman používa CDI:

sudo nvidia-ctk runtime configure --runtime=podman
sudo nvidia-ctk cdi generate --output=/etc/cdi/nvidia.yaml

podman run --rm --device=nvidia.com/gpu=all \
  nvcr.io/nvidia/pytorch:25.12-py3 nvidia-smi

Rootless Podman + CDI je najčistejšie riešenie pre stroje s viacerými používateľmi, ktorých nechcete pridávať do skupiny docker (čo je v praxi root).

CDI vs. starší runtime

Dva režimy sprístupnenia GPU:

• Starší runtime hook nvidia — to, čo --gpus all používa už roky. Docker vyvolá hook, ktorý do kontajnera za behu pripojí knižnice ovládača a zariadenia.
• CDI (Container Device Interface) — otvorená špecifikácia na deklarovanie prístupu k zariadeniam. nvidia-ctk cdi generate zapíše YAML súbor, ktorý vymenúva GPU ako pomenované zariadenia (nvidia.com/gpu=0, nvidia.com/gpu=all); konzumuje ich ktorýkoľvek runtime podporujúci CDI.

Stav v polovici roka 2026:

Pri inštalácii Dockera na jednom serveri legacy stále funguje bez problémov. Pri čomkoľvek, čo sa dotýka Kubernetes, rootless alebo viacerých používateľov, prejdite na CDI — tam smerujú investície NVIDIA. Migrácia nie je invazívna: nainštalujte toolkit, vygenerujte CDI špecifikáciu a vymeňte --gpus all za --device=nvidia.com/gpu=all. Oba režimy môžu existovať vedľa seba.

GPU passthrough — čo --gpus all v skutočnosti robí

Keď spustíte docker run --gpus all my-image, runtime hook prečíta NVIDIA_VISIBLE_DEVICES / NVIDIA_DRIVER_CAPABILITIES, pripojí /dev/nvidia* do kontajnera s oprávneniami cgroup, dovnútra bind-mountne súbory .so ovládača hostiteľa a nastaví LD_LIBRARY_PATH tak, aby ich linker našiel.

Čo máte pod kontrolou:

docker run --gpus all ...                                     # all GPUs
docker run --gpus '"device=0,1"' ...                          # by index
docker run --gpus '"device=GPU-abc123..."' ...                # by UUID
docker run --gpus all -e NVIDIA_DRIVER_CAPABILITIES=compute,utility ...
docker run --device=nvidia.com/gpu=0 --device=nvidia.com/gpu=1 ...  # CDI

Pre 8-GPU server s tenzorovo paralelným vLLM použite --gpus all. Pri stroji s viacerými nájomníkmi, kde používatelia dostávajú 4-GPU výseky, pripínajte podľa UUID — pripínanie podľa indexu sa rozbije, len čo prekáblujete.

NGC kontajnery — kedy ich použiť

Katalóg NGC od NVIDIA (nvcr.io) ponúka image pre PyTorch, TensorRT, TensorRT-LLM, Triton a ďalšie. Sú veľké (5–15 GB), ale otestované a dodávané s kombináciami cuDNN / NCCL / CUDA runtime, ktoré NVIDIA preverila. Máj 2026:

Tagy majú tvar <year>.<month>-py3, vydávajú sa mesačne. Nie sú presne upstream — sú patchované a prestavané — ale držia sa blízko.

Úprimný argument pre NGC: ak prevádzkujete TensorRT-LLM alebo Triton, siahnite po NGC image. Zladenie cuDNN, NCCL, TensorRT a CUDA je už spravené. Pre upstream PyTorch alebo vLLM sú verejné image (pytorch/pytorch:..., vllm/vllm-openai:...) menšie a rýchlejšie sa aktualizujú — NGC je zbytočný luxus.

MIG — a prečo sa portfólia Kentino netýka

MIG rozdeľuje jedno GPU až na sedem izolovaných výsekov, každý s vlastnou pamäťou, výpočtovým výkonom a doménou zlyhania. Hodí sa na multi-tenant inferenciu — piati používatelia dostanú 1/7 H100 s tvrdou izoláciou.

MIG nie je dostupný na spotrebiteľských kartách (RTX 5090, 4090) ani na workstation Blackwelli (RTX Pro 6000). Je vyhradený pre datacentrové SKU — H100, H200, A100, B100, B200, GB200. Kentino datacentrové GPU vo formáte SXM nedodáva, takže MIG nenájdete v žiadnej zostave Kentino.

Náhradou na spotrebiteľských a workstation kartách je MPS (Multi-Process Service) — viacero procesov zdieľa výpočtový plánovač GPU. Nie je izolované ako MIG (jeden zlý proces vie zariadenie zhodiť cez OOM), ale pri dôveryhodnej multi-tenant inferencii to funguje a nestojí nič. Ak naozaj potrebujete MIG, potrebujete datacentrový rad SKU cez iného integrátora.

Riešenie problémov — chyby, ktoré potrápia každého

CUDA error: no kernel image is available for execution on the device (chyba 209). CUDA runtime v kontajneri nemá kernely pre compute capability Vášho GPU — zvyčajne ide o image s CUDA 12.4 na karte Blackwell (sm_120), ktorá potrebuje 12.8+. Riešenie: novší image, alebo build so správnym TORCH_CUDA_ARCH_LIST.

CUDA error: forward compatibility was attempted on non supported HW (chyba 100). Ovládač na hostiteľovi je starší, než vyžaduje runtime v kontajneri. Riešenie: aktualizujte ovládač na hostiteľovi — a inštalujte z repozitára NVIDIA, nie zo zastaranej balíčkovanej verzie v Ubuntu.

Failed to initialize NVML: Driver/library version mismatch. Ovládač bol aktualizovaný cez apt bez reštartu; jadrový modul je starý, userspace nový. Riešenie: reštart. (Ak nemôžete, odoberte cez rmmod moduly nvidia a cez modprobe ich vráťte späť — reštart je však bezpečnejší.)

nvidia-container-cli: initialization error: nvml error: driver not loaded. Toolkit je nainštalovaný, ale jadrový modul ovládača nie je načítaný. Zvyčajne ide o čerstvú inštaláciu, kde už na hostiteľovi zlyháva nvidia-smi. Opravte najprv hostiteľa, až potom kontajner.

OCI runtime exec failed: ... no such file or directory pri --gpus all. Runtime hook nie je zaregistrovaný v Dockeri. Spustite znova sudo nvidia-ctk runtime configure --runtime=docker && sudo systemctl restart docker. Ak to nepomôže, skontrolujte v /etc/docker/daemon.json blok "runtimes".

Build zo zdrojov vs. predpripravené balíky

PyTorch, vLLM, llama.cpp, FlashAttention — všetko má predpripravené wheels a image. Zo zdrojov stavajte len vtedy, keď potrebujete ešte nevydanú funkciu, ste na compute capability, ktorú upstream wheels nepokrývajú, alebo kompilujete voči vlastnej CUDA / cuDNN. PyTorch zo zdrojov zaberie na EPYC 30–90 minút s nulovým ziskom na výkone, pokiaľ neodovzdáte vlastné CMake prepínače. Build zo zdrojov je odpoveďou na konkrétny problém, nie predvolenou voľbou.

---

Toto je súčasť Kentino Wiki, referenčnej série o AI výpočtoch, robotike a systémoch, ktoré ich spájajú. Komentáre a opravy uvítame na info@kentino.com.