CUDA, cuDNN a NVIDIA Container Toolkit: rozumný postup instalace AI serveru

Máte nově osazený server se čtyřmi nebo osmi GPU, Ubuntu 22.04 nebo 24.04, zafixovaný ovladač NVIDIA (viz L01), a nvidia-smi vrací rozumná čísla. To je základ. Nad ním leží nepříjemně složitá vrstva — CUDA, cuDNN, container toolkit, runtimy, NGC image — kterou většina návodů odbyde mávnutím ruky. Tento článek vás provede od ovladače až do bodu, kdy docker run --gpus all rozsvítí každou kartu a kontejner s vLLM začne servírovat tokeny.

Má jasný názor na to, kterou cestou jít, a upřímně říká, která z nich kouše.

Trojice ovladač / runtime / toolkit

Pod hlavičkou „CUDA“ se dodávají tři věci a lidé je neustále zaměňují:

Za běhu rozhoduje ovladač. Ovladač podporuje maximální verzi CUDA runtime; runtime musí být tato verze nebo starší. Toolkit potřebujete, jen pokud sami kompilujete CUDA kód — u 95% instalací nepotřebujete nvcc na hostiteli.

Právě proto kontejnery fungují: image s sebou nese vlastní CUDA runtime, hostitel potřebuje jen ovladač. Jediné, co musí na hostiteli sedět, je ovladač. Všechno ostatní je přenositelné.

┌─────────────────────────────────────────────────┐
│ 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ázek je rozdíl mezi odpolednem práce a třemi dny v pekle závislostí.

CUDA 12.x, nebo 13.x — kterou zvolit

V květnu 2026 se aktivně používají obě. Upřímná matice pro workloady, které servery Kentino provozují:

Výchozí volbou Kentino je u nových sestav CUDA 13.0. Podporována je každá GPU z nabídky (5090, 4090, RTX Pro 6000 Blackwell, L40, L4), vLLM nyní na PyPI dodává wheely pro 13.0 jako výchozí, image vllm/vllm-openai používá 13.0, PyTorch 2.11 (proti kterému se vLLM sestavuje) je postavený pro 13.0 a nové funkce (FlashAttention 3 na Blackwellu, trénovací kernely FP8) míří nejdřív na 13.x.

Zůstaňte na 12.8 jen tehdy, pokud: reprodukujete zafixovaný benchmark, SDK dodavatele se neposunulo, nebo máte výhradně karty před Blackwellem. U nových instalací nic staršího než 12.4 — jde o chyby opravené upstreamem před dvěma lety.

Čistá instalace ovladače a CUDA

Ubuntu 24.04 LTS (22.04 je totožné). Čistou cestou je apt repozitář CUDA od NVIDIE:

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 restartu by měl nvidia-smi hlásit ovladač 570.x a CUDA 13.0. Pasti, kterým se vyhnout:

• Neinstalujte cuda metabalíček, pokud nechcete úplně všechno. Stáhne toolkit, ukázky, GDS, Nsight a připne balíčky, které jste nechtěli. Zvolte raději přímo cuda-runtime-13-0 nebo cuda-toolkit-13-0.
• Zafixujte ovladač, aby unattended-upgrades nemohly přetočit jaderný modul: sudo apt-mark hold cuda-drivers cuda-drivers-570 nvidia-driver-570 nvidia-dkms-570 libnvidia-compute-570.
• Vždy jen jedna větev ovladače. Míchání balíčků 550 a 570 vytvoří systém, který nabootuje, ale kde nvidia-smi vrací nejasnou chybu o neshodě verzí. Nápravou je apt purge '*nvidia*' '*cuda*' a začít znovu — lepší je se tam vůbec nedostat.

cuDNN — apt, nebo tarball?

cuDNN je knihovna primitiv pro deep learning — konvoluce, attention, RNN. Závisí na ní PyTorch / TensorFlow / JAX. Od verze 9.x existují dvě cesty instalace.

apt (doporučeno):

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

Instaluje se do /usr/lib/x86_64-linux-gnu/, dynamický linker si ji sám najde a integruje se se správcem balíčků, takže projdou i bezpečnostní aktualizace. Současně může být nainstalována jen jedna CUDA verze cuDNN 9 — žádné libcudnn9-cuda-12 a libcudnn9-cuda-13 vedle sebe přes apt.

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 dává smysl při více verzích cuDNN na jednom hostiteli, u balíčků pro air-gapped prostředí nebo při fixaci mikroverze. Ve všech ostatních případech apt. Dokumentace NVIDIE doporučuje tam, kde to jde, distribuční balíčky — tarball není instalátor, je to redistribuční archiv.

Upřímná odpověď: pokud používáte NGC kontejnery, neinstalujte cuDNN na hostitele vůbec. Je součástí image.

Kontejnery vs. bare-metal — kdy co

Největší rozhodnutí v celém stacku, na které neexistuje univerzální odpověď. Kompromis tak, jak vypadá na reálných sestavách Kentino:

Rozdíl ve výkonu CUDA mezi kontejnerem a bare-metalem je na moderních jádrech zanedbatelný — v nejhorším jednotky procent, obvykle šum. Kdo tvrdí opak, měří úložiště nebo síť, ne výpočet na GPU.

Bare-metal: honba za posledními 2–3% kvůli publikaci, ladění kernelů pomocí cuda-gdb / compute-sanitizer / Nsight tam, kde vrstva kontejneru překáží, nebo jeden proces, který stroj vlastní celé roky.

Kontejnery (výchozí volba Kentino): víceuživatelské stroje, PyTorch 2.5 a 2.11 vedle sebe, výměna inferenčních frameworků (vLLM, SGLang, TensorRT-LLM) bez přestavby hostitele nebo nasazení, které stačí docker pull na nový server a za pět minut běží.

Pro robotickou laboratoř nebo výzkumnou skupinu: kontejnery. Pro benchmarkový rig s jedním workloadem je bare-metal v pořádku.

nvidia-container-toolkit — co to je a jak jej nastavit

Toolkit je lepidlo, které dává kontejneru přístup ke GPU hostitele. Bez něj nvidia-smi uvnitř kontejneru selže. S ním kontejner vidí ovladač, zařízení i vložený runtime stub.

Instalace:

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í příkaz by měl uvnitř kontejneru zobrazit výstup nvidia-smi z hostitele. Pokud ano, stack je zapojený.

Podman

Podman používá 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 nejčistší nastavení pro víceuživatelské stroje, kde nechcete mít uživatele ve skupině docker (která je fakticky root).

CDI vs. starší runtime

Dva režimy, jak zpřístupnit GPU:

• Starší nvidia runtime hook — to, co --gpus all používá už roky. Docker vyvolá hook, který za běhu připojí knihovny ovladače a zařízení do kontejneru.
• CDI (Container Device Interface) — otevřená specifikace pro deklaraci přístupu k zařízením. nvidia-ctk cdi generate zapíše YAML soubor, který vyjmenuje GPU jako pojmenovaná zařízení (nvidia.com/gpu=0, nvidia.com/gpu=all); použije je libovolný runtime, který CDI rozumí.

Stav v polovině roku 2026:

U instalace Dockeru na jednom serveru starší režim pořád slouží dobře. Všude, kde jde o Kubernetes, rootless nebo více uživatelů, přejděte na CDI — tam směřují investice NVIDIE. Migrace je neinvazivní: nainstalujte toolkit, vygenerujte CDI specifikaci a vyměňte --gpus all za --device=nvidia.com/gpu=all. Oba režimy mohou existovat vedle sebe.

GPU passthrough — co --gpus all vlastně dělá

Když spustíte docker run --gpus all my-image, hook runtime přečte NVIDIA_VISIBLE_DEVICES / NVIDIA_DRIVER_CAPABILITIES, připojí /dev/nvidia* into the container with cgroup permissions, bind-mounts the host's driver .so soubory ovladače z hostitele a nastaví LD_LIBRARY_PATH, aby je linker našel.

Co 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

Pro server s 8 GPU, který běží tenzorově paralelní vLLM, použijte --gpus all. U stroje s více nájemci, kde uživatelé dostávají čtyřkartové výseky, fixujte podle UUID — fixace podle indexu se rozpadne při přepojení kabeláže.

NGC kontejnery — kdy je použít

Katalog NGC od NVIDIE (nvcr.io) dodává image pro PyTorch, TensorRT, TensorRT-LLM, Triton a další. Jsou velké (5–15 GB), ale otestované a dodávané s kombinacemi cuDNN / NCCL / CUDA runtime, které NVIDIA prošla QA. Květen 2026:

Tagy mají tvar <year>.<month>-py3 a vycházejí měsíčně. Nejde o přesný upstream — jsou patchované a přestavěné — ale drží se ho těsně.

Upřímný argument pro NGC: pokud provozujete TensorRT-LLM nebo Triton, použijte NGC image. Práce se sladěním cuDNN, NCCL, TensorRT a CUDA je hotová. Pro upstream PyTorch nebo vLLM jsou veřejné image (pytorch/pytorch:..., vllm/vllm-openai:...) menší a rychleji se aktualizují — NGC je zbytečný overkill.

MIG — a proč se nabídky Kentino netýká

MIG rozdělí jednu GPU až na sedm izolovaných výseků, každý s vlastní pamětí, výpočetním výkonem a doménou selhání. Hodí se pro inferenci s více nájemci — pět uživatelů dostane 1/7 H100 s tvrdou izolací.

MIG není dostupný na spotřebitelských kartách (RTX 5090, 4090) ani na workstation kartách Blackwell (RTX Pro 6000). Je vyhrazen pro datacentrové SKU — H100, H200, A100, B100, B200, GB200. Kentino datacentrové GPU ve formátu SXM neodebírá, takže MIG v žádné sestavě Kentino není.

Náhradou na spotřebitelských a workstation kartách je MPS (Multi-Process Service) — více procesů sdílí výpočetní plánovač GPU. Není izolovaný jako MIG (jeden špatný proces může zařízení shodit přes OOM), ale pro důvěryhodnou inferenci s více nájemci funguje a nic nestojí. Pokud skutečně potřebujete MIG, potřebujete datacentrovou řadu SKU přes jiného integrátora.

Řešení problémů — chyby, které koušou každého

CUDA error: no kernel image is available for execution on the device (chyba 209). CUDA runtime v kontejneru nemá kernely pro compute capability vaší GPU — obvykle image s CUDA 12.4 na kartě Blackwell (sm_120), která potřebuje 12.8+. Náprava: novější image, nebo sestavení se správným TORCH_CUDA_ARCH_LIST.

CUDA error: forward compatibility was attempted on non supported HW (chyba 100). Ovladač na hostiteli je starší, než runtime v kontejneru vyžaduje. Náprava: upgradujte ovladač na hostiteli — a instalujte z repozitáře NVIDIE, ne ze zastaralého balíčku Ubuntu.

Failed to initialize NVML: Driver/library version mismatch. Ovladač byl aktualizován přes apt bez restartu; jaderný modul je starý, userspace nový. Náprava: restart. (Pokud nemůžete, odeberte moduly nvidia příkazem rmmod a znovu je načtěte příkazem modprobe — ale restart je bezpečnější.)

nvidia-container-cli: initialization error: nvml error: driver not loaded. Toolkit je nainstalovaný, ale jaderný modul ovladače není načtený. Obvykle čerstvá instalace, kde nvidia-smi na hostiteli už selhává. Opravte hostitele, pak kontejner.

OCI runtime exec failed: ... no such file or directory u --gpus all. Hook runtime není u Dockeru zaregistrovaný. Spusťte znovu sudo nvidia-ctk runtime configure --runtime=docker && sudo systemctl restart docker. Pokud to nepomůže, zkontrolujte v /etc/docker/daemon.json blok "runtimes".

Sestavení ze zdrojů vs. předpřipravené balíčky

PyTorch, vLLM, llama.cpp, FlashAttention — všechny mají předpřipravené wheely a image. Ze zdrojů sestavujte jen tehdy, když potřebujete nevydanou funkci, jste na compute capability, na kterou upstream wheely necílí, nebo kompilujete proti vlastní CUDA / cuDNN. PyTorch ze zdrojů zabere na EPYC 30–90 minut a bez vlastních CMake přepínačů nepřinese žádný nárůst výkonu. Sestavení ze zdrojů je odpovědí na konkrétní problém, ne výchozí volbou.

---

Toto je součást Kentino Wiki, referenční série o AI výpočtech, robotice a systémech, které je spojují. Komentáře a opravy uvítáme na info@kentino.com.