CUDA, cuDNN a sada nástrojů NVIDIA Container Toolkit: Rozumná cesta nastavení serveru s umělou inteligencí

Máte čerstvě instalovaný server se čtyřmi nebo osmi grafickými kartami, Ubuntu 22.04 nebo 24.04, nainstalovaný ovladač NVIDIA (za L01), A nvidia-smi vrací rozumná čísla. To je spodní část. Nad ní se nachází neforemná hromada – CUDA, cuDNN, sada nástrojů pro kontejnery, běhové prostředí, obrázky NGC – kterou většina lidí provede ručně. Tento článek projde od ovladače až do bodu, kdy docker run --gpus all rozsvítí každou kartu a kontejner vLLM obsluhuje tokeny.

Mám názor na to, kterou cestou se vydat, a jsem upřímný ohledně toho, která z nich je správná.

Triáda ovladač / běhové prostředí / sada nástrojů

Pod pojmem „CUDA“ se skrývají tři věci, které si lidé neustále pletou:

Ovladač je to, na čem záleží za běhu. Ovladač podporuje maximum Verze běhového prostředí CUDA; běhové prostředí musí být toto nebo starší. Sada nástrojů je potřeba pouze v případě, že si kód CUDA kompilujete sami – pro 95 % instalací ji nepotřebujete. nvcc na hostiteli.

Proto kontejnery fungují: obraz obsahuje vlastní běhové prostředí CUDA, hostitel potřebuje pouze ovladač. Jediné, co musí být v pořádku, je hostitelský ovladač. Všechno ostatní je přenosné.

┌─────────────────────────────────────────────────┐
│ 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 ukazuje rozdíl mezi pracovním odpolednem a třemi dny závislostního pekla.

CUDA 12.x nebo 13.x – kterou si vybrat

Oba jsou aktivně používány v květnu 2026. Správná matice pro úlohy, které servery Kentino provozují:

Výchozí nastavení Kentina je v nových sestaveních CUDA 13.0. Všechny grafické karty v řadě (5090, 4090, RTX Pro 6000 Blackwell, L40, L4) jsou podporovány, vLLM nyní standardně dodává 13.0 kola na PyPI a vllm/vllm-openai image používá verzi 13.0, PyTorch 2.11 (proti kterému je vLLM dodáván) je vytvořen pro verzi 13.0 a nové funkce (FlashAttention 3 na Blackwellu, trénovací jádra FP8) cílí nejprve na verzi 13.x.

Zůstaňte na 12.8 pouze pokud: Reprodukce připnutého benchmarku, SDK dodavatele se nepřesunula, nebo výhradně karty starší než Blackwell. Nic staršího než 12.4 v nových instalacích – chyby opravené před dvěma lety.

Čistá instalace ovladače a CUDA

Ubuntu 24.04 LTS (22.04 je identický). Čistá cesta je CUDA od NVIDIA. apt repozitáře:

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

• Neinstalujte cuda metabalíček pokud nechcete všechno. Stáhne balíčky nástrojů, vzorků, GDS, Nsight a pins, které jste nechtěli. Vyberte si cuda-runtime-13-0 or cuda-toolkit-13-0 výslovně.
• Připnout řidiče takže bezobslužné aktualizace nemohou aktualizovat modul jádra: sudo apt-mark hold cuda-drivers cuda-drivers-570 nvidia-driver-570 nvidia-dkms-570 libnvidia-compute-570.
• Jedna větev ovladače najednou. Kombinací balíčků 550 a 570 vznikne systém, který se sice bootuje, ale kde... nvidia-smi vrací nejasnou chybu neshody verzí. Oprava je apt purge '*nvidia*' '*cuda*' a začít znovu – lepší se tam nedostat.

cuDNN — apt nebo tarball?

cuDNN je knihovna primitiv pro hluboké učení – konvoluce, pozornost, RNN. PyTorch / TensorFlow / JAX jsou na ní závislé. Od verze 9.x existují dvě instalační cesty.

vhodné (doporučeno):

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

Instaluje se do /usr/lib/x86_64-linux-gnu/, je zachycen dynamickým linkerem a integrován se správcem balíčků, aby mohly probíhat aktualizace zabezpečení. V daném okamžiku lze nainstalovat pouze jednu CUDA verzi cuDNN 9. - Ne libcudnn9-cuda-12 a libcudnn9-cuda-13 vedle sebe přes apt.

Archivní balíček:

# 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á smysl pro více verzí cuDNN na jednom hostiteli, balíčky s oddělenou mezerou nebo pinning mikroverzí. Vše ostatní: apt. Dokumentace NVIDIA doporučuje distribuční balíčky, kde je to možné – tarball není instalační program, ale redistribuční archiv.

Upřímná odpověď: Pokud používáte kontejnery NGC, neinstalujte cuDNN na hostitele vůbec. Je dodáván v obraze.

Kontejnery vs. holé železo – kdy který postupovat

Největší rozhodnutí v celém stacku, bez univerzální odpovědi. Kompromis, jak je vidět na skutečných sestaveních Kentina:

Výkon CUDA v kontejnerizovaném vs. holém prostředí je na moderních jádrech zanedbatelný – v nejhorším případě se pohybuje v řádu jednotek procent, obvykle se jedná o šum. Každý, kdo tvrdí opak, benchmarkuje úložiště nebo síť, nikoli výpočetní výkon GPU.

Holý kov: honba za posledními 2–3 % pro článek, ladění jádra s cuda-gdb / compute-sanitizer / Zjistěte, kde překáží kontejnerová vrstva, nebo kde jeden proces vlastní stroj po celá léta.

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

Pro robotickou laboratoř nebo výzkumnou skupinu: kontejnery. Pro benchmarkové zařízení s jednou úlohou je bare-metal v pořádku.

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

Sada nástrojů je pojítkem, které kontejneru poskytuje přístup k GPU hostitele. Bez ní... nvidia-smi Uvnitř kontejneru selže. Kontejner pak vidí ovladač, zařízení a vložený běhový 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 zobrazit hostitele nvidia-smi výstup z kontejneru. Pokud ano, zásobník je propojen.

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é boxy, kde nechcete, aby se uživatelé nacházeli v... docker skupina (což je v podstatě kořen).

CDI vs. starší běhové prostředí

Dva režimy pro vystavení GPU:

• Dědictví nvidia běhový hook — co --gpus all používá se již léta. Docker za běhu volá hook, který připojuje knihovny ovladačů a zařízení do kontejneru.
• CDI (rozhraní kontejnerového zařízení) — otevřená specifikace pro deklaraci přístupu k zařízením. nvidia-ctk cdi generate zapíše YAML soubor, který vyjmenovává GPU jako pojmenovaná zařízení (nvidia.com/gpu=0, nvidia.com/gpu=all); spotřebovává je jakýkoli běhový modul s podporou CDI.

Stav v polovině roku 2026:

Pro instalaci Dockeru na jednom serveru funguje starší verze stále dobře. Pro cokoli, co se týká Kubernetes, rootless nebo multiuživatelského prostředí, přejděte na CDI – tam směřují investice NVIDIA. Migrace je neinvazivní: nainstalujte sadu nástrojů, vygenerujte specifikaci CDI, vyměňte --gpus all for --device=nvidia.com/gpu=allTyto dva režimy mohou existovat vedle sebe.

Průchod GPU – co --gpus all vlastně dělá

Když spustíte docker run --gpus all my-image běhový hook čte NVIDIA_VISIBLE_DEVICES / NVIDIA_DRIVER_CAPABILITIES, držáky /dev/nvidia* do kontejneru s oprávněními cgroup, připojí ovladač hostitele pomocí bind-mountu .so soubory v a sady LD_LIBRARY_PATH takže je linker najde.

Co ovládáte:

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ý provádí tenzorově paralelní vLLM, použijte --gpus allPro vícenájemní box, kde uživatelé získají 4GPU segmenty, použijte pin podle UUID – pinování na základě indexu se přeruší, pokud provedete opětovné propojení kabelů.

Kontejnery NGC – kdy je použít

Katalog NGC od NVIDIA (nvcr.io) nabízí obrazy pro PyTorch, TensorRT, TensorRT-LLM, Triton a další. Jsou velké (5–15 GB), ale testované a dodávané s kombinacemi běhového prostředí cuDNN / NCCL / CUDA, které NVIDIA ověřila jako QA. Květen 2026:

Štítky jsou <year>.<month>-py3, měsíčně se stříhá. Není to přesně proti proudu – opraveno a přestavěno – ale úzce kopíruje směr.

Čestné argumenty pro NGC: Pokud používáte TensorRT-LLM nebo Triton, použijte obraz NGC. Práce s párováním cuDNN, NCCL, TensorRT a CUDA je hotová. Pro upstream PyTorch nebo vLLM se používají veřejné obrazy (pytorch/pytorch:..., vllm/vllm-openai:...) jsou menší a rychlejší na aktualizaci – NGC je zbytečné.

MIG – a proč se to nevztahuje na sestavu Kentina

MIG rozděluje jednu GPU až na sedm izolovaných segmentů, z nichž každý má vlastní paměť, výpočetní kapacitu a doménu chyb. To je užitečné pro inferenci s více klienty – pět uživatelů získá 1/7 H100 s tvrdou izolací.

Technologie MIG není k dispozici na spotřebitelských grafických kartách Blackwell (RTX 5090, 4090) ani na grafických kartách Blackwell pro pracovní stanice (RTX Pro 6000). Je omezen na SKU pro datová centra – H100, H200, A100, B100, B200, GB200. Kentino nedodává grafické karty SXM pro datová centra, takže MIG není součástí žádné sestavy Kentina.

Náhrada na spotřebitelských / pracovních kartách je MPS (víceprocesní služba) — více procesů sdílí plánovač výpočtů GPU. Není izolovaný jako MIG (jeden špatný proces může zařízení OOM zcela zničit), ale pro důvěryhodné odvozování od více klientů funguje a nic nestojí. Pokud MIG skutečně potřebujete, potřebujete datové centrum SKU od jiného integrátora.

Řešení problémů – chyby, které štípou každého

CUDA error: no kernel image is available for execution on the device (chyba 209). CUDA runtime v kontejneru nemá žádná jádra pro výpočetní kapacitu vaší GPU – obvykle se jedná o obraz CUDA 12.4 na grafické kartě Blackwell (sm_120), která potřebuje verzi 12.8+. Oprava: novější obraz nebo sestavení se správným jádrem. TORCH_CUDA_ARCH_LIST.

CUDA error: forward compatibility was attempted on non supported HW (chyba 100). Ovladač hostitele je starší, než běhové prostředí v kontejneru požaduje. Oprava: aktualizujte ovladač hostitele – a nainstalujte jej z repozitáře NVIDIA, nikoli ze zastaralé verze v Ubuntu.

Failed to initialize NVML: Driver/library version mismatch. Ovladač aktualizován pomocí apt bez restartu; modul jádra je starý, uživatelský prostor je nový. Oprava: restart. (Pokud nemůžete, rmmod moduly nvidia a modprobe je zpět – ale restart je bezpečnější.)

nvidia-container-cli: initialization error: nvml error: driver not loaded. Sada nástrojů je nainstalována, ale modul jádra ovladače není načten. Obvykle je nutná nová instalace, kde nvidia-smi na hostiteli již selhává. Opravte hostitele a poté kontejner.

OCI runtime exec failed: ... no such file or directory on --gpus all. Runtime hook není v Dockeru registrován. Spusťte znovu. sudo nvidia-ctk runtime configure --runtime=docker && sudo systemctl restart dockerPokud není opraveno, zkontrolujte /etc/docker/daemon.json pro "runtimes" blok.

Sestavení ze zdroje vs. předpřipravené verze

PyTorch, vLLM, llama.cpp, FlashAttention – všechny mají předpřipravená kola a obrazy. Sestavujte ze zdrojového kódu pouze tehdy, když potřebujete nevydanou funkci, jste na výpočetní kapacitě, na kterou se kola z upstreamu necílí, nebo kompilujte s vlastním CUDA / cuDNN. PyTorch ze zdrojového kódu vydrží na EPYC 30–90 minut s nulovým ziskem výkonu, pokud neposkytnete vlastní příznaky CMake. Sestavení ze zdrojového kódu jsou odpovědí na konkrétní problém, nikoli výchozím nastavením.

---

Toto je součást Kentino Wiki, referenční série o výpočetní technologii s využitím umělé inteligence, robotice a systémech, které je propojují. Komentáře a opravy jsou vítány na adrese info@kentino.com.