CUDA, cuDNN a NVIDIA Container Toolkit: Rozumná cesta nastavenia pre server s umelou inteligenciou

Máte čerstvo nainštalovaný server so štyrmi alebo ôsmimi grafickými kartami, Ubuntu 22.04 alebo 24.04, nainštalovaný ovládač NVIDIA (za L01), A nvidia-smi vracanie rozumných čísel. To je základ. Nad ním sa nachádza nepraktický zásobník – CUDA, cuDNN, sada nástrojov pre kontajnery, runtime, obrázky NGC – ktorými väčšina ľudí prechádza ručne. Tento článok prechádza od ovládača až do bodu, kde docker run --gpus all rozsvieti každú kartu a kontajner vLLM slúži na vydávanie tokenov.

Mám názor na to, ktorou cestou sa vydať, a som úprimný o tom, ktorá z nich je pre mňa najlepšia.

Triáda ovládač / behové prostredie / sada nástrojov

Pod záštitou „CUDA“ sa spájajú tri veci a ľudia si ich neustále zamieňajú:

Ovládač je to, na čom záleží počas behu. Ovládač podporuje maximum Verzia runtime prostredia CUDA; runtime musí byť táto alebo staršia. Sada nástrojov je potrebná iba v prípade, že si kód CUDA kompilujete sami – pre 95 % inštalácií ju nepotrebujete. nvcc na hostiteľovi.

Preto kontajnery fungujú: obraz dodáva vlastný CUDA runtime, hostiteľ potrebuje iba ovládač. Jediné, čo musí byť správne, je hostiteľský ovládač. 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 ukazuje rozdiel medzi pracovným popoludní a tromi dňami závislého pekla.

CUDA 12.x alebo 13.x – ktorú si vybrať

Oba sú aktívne používané v máji 2026. Úprimná matica pre pracovné zaťaženia, ktoré servery Kentino spúšťajú:

Predvolená verzia Kentina je CUDA 13.0 v nových zostaveniach. Každá grafická karta v zostave (5090, 4090, RTX Pro 6000 Blackwell, L40, L4) je podporovaná, vLLM teraz štandardne dodáva 13.0 disky na PyPI a vllm/vllm-openai Obrázok používa verziu 13.0, PyTorch 2.11 (s ktorým je vLLM dodávaný) je zostavený pre verziu 13.0 a nové funkcie (FlashAttention 3 na Blackwell, tréningové jadrá FP8) sú najprv zamerané na verziu 13.x.

Zostaňte na 12.8 iba ak: reprodukuje sa pripnutý benchmark, SDK dodávateľa sa nepresunul alebo sú určené výhradne pre karty staršie ako Blackwell. Nič staršie ako 12.4 v nových inštaláciách – chyby opravené pred dvoma rokmi.

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

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

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, nvidia-smi mal by nahlásiť ovládač 570.x a CUDA 13.0. Pasce, ktorým sa treba vyhnúť:

• Neinštalujte cuda metabalík pokiaľ nechcete všetko. Stiahne balík nástrojov, vzoriek, GDS, Nsight a pinov, ktoré ste nechceli. Vyberte si cuda-runtime-13-0 or cuda-toolkit-13-0 explicitne.
• Pripnúť vodiča takže bezobslužné aktualizácie nemôžu aktualizovať modul jadra: sudo apt-mark hold cuda-drivers cuda-drivers-570 nvidia-driver-570 nvidia-dkms-570 libnvidia-compute-570.
• Jedna vetva ovládača naraz. Kombináciou balíkov 550 a 570 vznikne systém, ktorý sa síce bootuje, ale kde nvidia-smi vracia nejasnú chybu nezhody verzií. Oprava je apt purge '*nvidia*' '*cuda*' a začať odznova — lepšie sa tam nedostať.

cuDNN — apt alebo tarball?

cuDNN je knižnica primitív pre hlboké učenie – konvolúcia, pozornosť, RNN. PyTorch / TensorFlow / JAX sú na nej závislé. Od verzie 9.x existujú dve inštalačné cesty.

vhodné (odporúčané):

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

Inštaluje sa do /usr/lib/x86_64-linux-gnu/, je zachytený dynamickým linkerom a integrovaný so správcom balíkov, aby sa zabezpečili bezpečnostné aktualizácie. Naraz je možné nainštalovať iba jednu CUDA verziu cuDNN 9 - nie libcudnn9-cuda-12 a libcudnn9-cuda-13 vedľa seba cez apt.

Archívny súbor:

# 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 pre viacero verzií cuDNN na jednom hostiteľovi, oddelené balíčky alebo pinning mikroverzií. Všetko ostatné: apt. Dokumentácia NVIDIA odporúča distribučné balíčky, kde je to možné – tarball nie je inštalátor, je to redistribučný archív.

Úprimná odpoveď: Ak používate kontajnery NGC, cuDNN na hostiteľa vôbec neinštalujte. Dodáva sa v obraze.

Kontajnery verzus holé kovové riešenia – kedy čo robiť

Najväčšie rozhodnutie v tomto zozname, bez univerzálneho riešenia. Kompromis, ako ho vidno na skutočných zostavách Kentina:

Výkon CUDA v kontajnerovom verzu holém jadre je na moderných jadrách zanedbateľný – v najhoršom prípade ide o jednociferné percento, zvyčajne ide o šum. Každý, kto tvrdí opak, porovnáva úložisko alebo sieť, nie výpočty na GPU.

Holý kov: naháňanie posledných 2–3 % pre článok, ladenie jadra s cuda-gdb / compute-sanitizer / Zistite, kde prekáža vrstva kontajnera alebo kde jeden proces vlastní stroj už roky.

Kontajnery (predvolené pre Kentino): viacpoužívateľské boxy, PyTorch 2.5 a 2.11 paralelné, výmena inferenčných rámcov (vLLM, SGLang, TensorRT-LLM) bez nutnosti prestavby hostiteľa alebo nasadenia, ktoré môžete docker pull na nový server a spustenie do piatich minút.

Pre robotické laboratórium alebo výskumnú skupinu: kontajnery. Pre benchmarkové zariadenie s jednou pracovnou záťažou je holý kov v poriadku.

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

Sada nástrojov je spojivo, ktoré poskytuje kontajneru prístup k GPU hostiteľa. Bez nej... nvidia-smi vo vnútri kontajnera zlyhá. Kontajner pri tom vidí ovládač, zariadenia a 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

Tento posledný príkaz by mal zobraziť hostiteľa nvidia-smi výstup zvnútra kontajnera. Ak áno, zásobník je prepojený.

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 nastavenie pre viacpoužívateľské boxy, kde nechcete, aby boli používatelia v... docker skupina (ktorá je v podstate koreňom).

CDI verzus staršie behové prostredie

Dva režimy na odhalenie grafických kariet:

• Dedičstvo nvidia háčik za behu — čo --gpus all používa už roky. Docker za behu programu vyvolá hook, ktorý pripája knižnice ovládačov a zariadenia do kontajnera.
• CDI (rozhranie kontajnerového zariadenia) — otvorená špecifikácia na deklarovanie prístupu k zariadeniam. nvidia-ctk cdi generate zapíše YAML súbor, v ktorom vymenuje GPU ako pomenované zariadenia (nvidia.com/gpu=0, nvidia.com/gpu=all); spotrebuje ich akýkoľvek behový modul s podporou CDI.

Stav v polovici roka 2026:

Pre inštaláciu Dockeru na jednom serveri funguje staršia verzia stále dobre. Pre čokoľvek, čo sa týka Kubernetes, rootless alebo multiuser, prejdite na CDI – tam smerujú investície spoločnosti NVIDIA. Migrácia je neinvazívna: nainštalujte sadu nástrojov, vygenerujte špecifikáciu CDI, vymeňte --gpus all pre --device=nvidia.com/gpu=allTieto dva režimy môžu existovať súčasne.

Priepustnosť GPU – čo --gpus all skutočne robí

Keď spustíte docker run --gpus all my-image runtime hook číta NVIDIA_VISIBLE_DEVICES / NVIDIA_DRIVER_CAPABILITIES, držiaky /dev/nvidia* do kontajnera s oprávneniami cgroup, pripojí ovládač hostiteľa pomocou funkcie bind-mount .so súbory v a sady LD_LIBRARY_PATH takže ich linker nájde.

Čo ovládate:

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 vykonávajúci tenzorovo-paralelný vLLM použite --gpus allPre viacnájomnícke zariadenie, kde používatelia získajú segmenty so 4 GPU, pripnite ho pomocou UUID – pripínanie na základe indexu sa preruší, ak znova pripojíte kábel.

Kontajnery NGC – kedy ich použiť

Katalóg NGC od spoločnosti NVIDIA (nvcr.io) dodáva obrazy pre PyTorch, TensorRT, TensorRT-LLM, Triton a ďalšie. Sú veľké (5 – 15 GB), ale testované a dodávané s kombináciami runtime prostredia cuDNN / NCCL / CUDA, ktoré NVIDIA overila ako QA. Máj 2026:

Značky sú <year>.<month>-py3, mesačne rezané. Nie je to úplne proti prúdu – opravené a prestavané – ale sleduje to presne.

Čestné argumenty pre NGC: Ak používate TensorRT-LLM alebo Triton, použite obraz NGC. Práca s porovnávaním cuDNN, NCCL, TensorRT a CUDA je hotová. Pre upstream PyTorch alebo vLLM, verejné obrazy (pytorch/pytorch:..., vllm/vllm-openai:...) sú menšie a rýchlejšie sa aktualizujú – NGC je prehnané.

MIG – a prečo sa to nevzťahuje na zostavu Kentina

MIG rozdeľuje jednu grafickú kartu (GPU) až na sedem izolovaných segmentov, z ktorých každý má vlastnú pamäť, výpočtovú kapacitu a doménu chýb. Toto je užitočné pre inferenciu s viacerými nájomníkmi – päť používateľov získa 1/7 H100 s tvrdou izoláciou.

MIG nie je k dispozícii na spotrebiteľských grafických kartách (RTX 5090, 4090) ani na grafických kartách Blackwell pre pracovné stanice (RTX Pro 6000). Je obmedzený na SKU dátových centier – H100, H200, A100, B100, B200, GB200. Kentino nedodáva grafické karty SXM pre dátové centrá, takže MIG nie je súčasťou žiadnej zostavy Kentina.

Náhrada na spotrebiteľských/pracovných kartách je MPS (Multi-Process Service) — viacero procesov zdieľa plánovač výpočtov GPU. Nie je izolovaný ako MIG (jeden chybný proces môže zariadenie úplne zničiť), ale pre dôveryhodnú inferenciu pre viacerých nájomcov to funguje a nič to nestojí. Ak MIG skutočne potrebujete, potrebujete rad SKU dátového centra prostredníctvom iného integrátora.

Riešenie problémov – chyby, ktoré trápia každého

CUDA error: no kernel image is available for execution on the device (chyba 209). CUDA runtime v kontajneri nemá žiadne jadrá pre výpočtové schopnosti vášho GPU – zvyčajne ide o obraz CUDA 12.4 na karte Blackwell (sm_120), ktorá potrebuje verziu 12.8+. Oprava: novší obraz alebo zostavenie so správnym TORCH_CUDA_ARCH_LIST.

CUDA error: forward compatibility was attempted on non supported HW (chyba 100). Ovládač hostiteľa je starší, ako runtime v kontajneri požaduje. Oprava: aktualizujte ovládač hostiteľa – a nainštalujte ho z repozitára NVIDIA, nie zo zastaranej verzie Ubuntu.

Failed to initialize NVML: Driver/library version mismatch. Ovládač aktualizovaný cez apt bez reštartu; modul jadra je starý, používateľský priestor je nový. Oprava: reštart. (Ak nemôžete, rmmod moduly nvidia a modprobe ich späť – ale reštart je bezpečnejší.)

nvidia-container-cli: initialization error: nvml error: driver not loaded. Sada nástrojov je nainštalovaná, ale modul jadra ovládača nie je načítaný. Zvyčajne je potrebná nová inštalácia, kde nvidia-smi na hostiteľovi už zlyháva. Opravte hostiteľa a potom kontajner.

OCI runtime exec failed: ... no such file or directory on --gpus all. Runtime hook nie je zaregistrovaný v Dockeri. Spustite znova. sudo nvidia-ctk runtime configure --runtime=docker && sudo systemctl restart dockerAk nie je opravené, skontrolujte /etc/docker/daemon.json pre "runtimes" blok.

Tvorba zo zdroja verzus predpripravené

PyTorch, vLLM, llama.cpp, FlashAttention — všetky majú predpripravené kolesá a obrazy. Zo zdroja zostavujte iba vtedy, keď potrebujete nevydanú funkciu, ste na výpočtovej kapacite, na ktorú sa kolesá necielia z upstreamu, alebo kompilujte s vlastným CUDA / cuDNN. PyTorch zo zdroja vydrží na EPYC 30–90 minút s nulovým nárastom výkonu, pokiaľ neodošlete vlastné príznaky CMake. Zostavenia zo zdroja sú riešením konkrétneho problému, nie predvoleným nastavením.

---

Toto je súčasť Kentino Wiki, referenčnej série o umelej inteligencii, robotike a systémoch, ktoré ich spájajú. Komentáre a opravy sú vítané na info@kentino.com.