CUDA, cuDNN og NVIDIA Container Toolkit: En fornuftig opsætningssti til en AI-server

Du har en frisk racket server med fire eller otte GPU'er, Ubuntu 22.04 eller 24.04, NVIDIA-driveren fastlåst (pr. L01), Og nvidia-smi returnerer fornuftige tal. Det er gulvet. Ovenover ligger en akavet stak - CUDA, cuDNN, containerværktøjssættet, runtime-funktionerne, NGC-billederne - som de fleste guider håndbaseret igennem. Denne artikel går fra driveren op til det punkt, hvor docker run --gpus all lyser op på alle kort, og en vLLM-container serverer tokens.

Meningsfuld om hvilken vej man skal tage, og ærlig om hvilken man bider på.

Driver/runtime/toolkit-triaden

Tre ting sælges under "CUDA"-paraplyen, og folk blander dem konstant sammen:

Driveren er det, der betyder noget under kørsel. En driver understøtter en maksimal CUDA runtime-version; runtime-versionen skal være den eller ældre. Værktøjskassen er kun nødvendig, hvis du selv kompilerer CUDA-kode — i 95% af installationerne behøver du ikke den. nvcc på værten.

Det er derfor, containere fungerer: imaget sender sin egen CUDA-runtime, værten behøver kun driveren. Værtsdriveren er det eneste, der skal være korrekt. Alt andet er bærbart.

┌─────────────────────────────────────────────────┐
│ 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
└─────────────────────────────────────────────────┘

Dette billede er forskellen på en eftermiddag med arbejde og tre dages afhængighedshelvede.

CUDA 12.x eller 13.x — hvilken skal man vælge

Begge er i aktiv brug i maj 2026. Den ærlige matrix for de arbejdsbelastninger, som Kentino-servere kører:

Kentino-standarden er CUDA 13.0 på nye builds. Alle GPU'er i serien (5090, 4090, RTX Pro 6000 Blackwell, L40, L4) understøttes, vLLM leverer nu 13.0-hjul som standard på PyPI, og vllm/vllm-openai Billedet bruger 13.0, PyTorch 2.11 (som vLLM kører imod) er bygget til 13.0, og nye funktioner (FlashAttention 3 på Blackwell, FP8-træningskerner) er rettet mod 13.x først.

Bliv kun på 12.8, hvis: du reproducerer en fastgjort benchmark, et leverandør-SDK ikke er flyttet, eller udelukkende kort fra før Blackwell. Intet er ældre end 12.4 på nye installationer — fejl rettet upstream for to år siden.

Installation af driveren og CUDA korrekt

Ubuntu 24.04 LTS (22.04 er identisk). Den rene sti er NVIDIAs CUDA. 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

Efter genstart, nvidia-smi bør rapportere driver 570.x og CUDA 13.0. Fælder, der skal undgås:

• Installer ikke cuda metapakke medmindre du vil have alt. Den henter værktøjssæt, eksempler, GDS, Nsight og fastlåser pakker, du ikke ønsker. Vælg cuda-runtime-13-0 or cuda-toolkit-13-0 eksplicit.
• Fastgør føreren så unattended-upgrades kan ikke rulle kernemodulet: sudo apt-mark hold cuda-drivers cuda-drivers-570 nvidia-driver-570 nvidia-dkms-570 libnvidia-compute-570.
• Én chaufførgren ad gangen. At blande 550- og 570-pakker giver et system, der starter op, men hvor nvidia-smi returnerer en obskur versionsfejl. Løsningen er apt purge '*nvidia*' '*cuda*' og starte forfra – bedre ikke at komme dertil.

cuDNN — apt eller tarball?

cuDNN er biblioteket for deep-learning primitiver — convolution, attention, RNN. PyTorch/TensorFlow/JAX er afhængige af det. Fra og med 9.x er der to installationsstier.

apt (anbefales):

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

Installerer til /usr/lib/x86_64-linux-gnu/, bliver opfanget af den dynamiske linker og integrerer med pakkehåndteringen, så sikkerhedsopdateringer flyder igennem. Kun én CUDA-version af cuDNN 9 kan installeres ad gangen - nej libcudnn9-cuda-12 og libcudnn9-cuda-13 side om side via lejl.

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 giver mening for flere cuDNN-versioner på én vært, air-gapped-bundter eller micro-version-pinning. Alt andet: apt. NVIDIAs dokumentation anbefaler distributionspakker, hvor det er muligt — tarballen er ikke et installationsprogram, det er et omdistributionsarkiv.

Ærligt svar: Hvis du bruger NGC-containere, skal du slet ikke installere cuDNN på værten. Det leveres i imaget.

Containere vs. bare-metal — hvornår skal man gøre hvad

Den største enkeltstående beslutning i stakken, uden noget universelt svar. Afvejningen set på rigtige Kentino-byggerier:

Containerbaseret vs. bare-metal CUDA-ydeevne er ubetydelig på moderne kerner - i værste fald en encifret procentdel, normalt støj. Enhver, der påstår andet, benchmarker lager eller netværk, ikke GPU-beregning.

Barmetal: jagter de sidste 2-3% for en artikel, kernel debugging med cuda-gdb / compute-sanitizer / Se hvor containerlaget er i vejen, eller hvor én proces har ejet maskinen i årevis.

Containere (Kentino-standarden): flerbrugerbokse, PyTorch 2.5 og 2.11 side om side, udskiftning af inferensframeworks (vLLM, SGLang, TensorRT-LLM) uden at genopbygge værten, eller en implementering du kan docker pull til en ny server og have den kørende om fem minutter.

Til et robotlaboratorium eller en forskningsgruppe: containere. Til en benchmark-rig med én arbejdsbelastning er bare-metal fint.

nvidia-container-toolkit — hvad det er, og hvordan man konfigurerer det

Værktøjssættet er den lim, der giver en container adgang til værtens GPU. Uden det, nvidia-smi fejler inde i en container. Med den ser containeren driveren, enhederne og en indsprøjtet runtime-stub.

Installer:

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

Den sidste kommando burde vise værtens nvidia-smi output fra indersiden af ​​containeren. Hvis det sker, er stakken forbundet.

Podman

Podman bruger 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 er den reneste opsætning til flerbrugerbokse, hvor du ikke ønsker brugere i docker gruppe (som reelt er rod).

CDI vs. ældre runtime

To tilstande til eksponering af GPU'er:

• Legacy nvidia runtime-krog - hvad --gpus all har brugt i årevis. Docker kalder en hook, der monterer driverbiblioteker og enheder i containeren under kørsel.
• CDI (Container Device Interface) — en åben specifikation til deklarering af enhedsadgang. nvidia-ctk cdi generate skriver en YAML-fil, der opregner GPU'er som navngivne enheder (nvidia.com/gpu=0, nvidia.com/gpu=all); enhver CDI-bevidst runtime forbruger dem.

Status medio 2026:

For en Docker-installation på én server fungerer legacy stadig fint. For alt, der berører Kubernetes, rootless eller multi-user, skift til CDI – det er der, NVIDIAs investering går hen. Migrering er ikke-invasiv: installer værktøjssættet, generer CDI-specifikationen, swap --gpus all forum --device=nvidia.com/gpu=allDe to tilstande kan sameksistere.

GPU-gennemgang — hvad --gpus all rent faktisk gør

Når du kører docker run --gpus all my-image runtime-krogen læser NVIDIA_VISIBLE_DEVICES / NVIDIA_DRIVER_CAPABILITIES, monteringer /dev/nvidia* ind i containeren med cgroup-tilladelser, bind-monterer værtens driver .so filer i, og sæt LD_LIBRARY_PATH så linkeren finder dem.

Hvad du kontrollerer:

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

For en 8-GPU-server, der udfører tensor-parallel vLLM, brug --gpus allFor en boks med flere brugere, hvor brugerne får 4-GPU-slices, skal du fastgøre via UUID — indeksbaseret fastgørelse afbrydes, hvis du omkabler.

NGC-beholdere — hvornår skal de bruges

NVIDIAs NGC-katalog (nvcr.io) leverer billeder til PyTorch, TensorRT, TensorRT-LLM, Triton og andre. Stor (5-15 GB), men testet og leveret med cuDNN / NCCL / CUDA runtime-kombinationer. NVIDIA har kvalitetssikret konfigurationen. Maj 2026:

Tags er <year>.<month>-py3, skåret månedligt. Ikke præcis opstrøms — lappet og genopbygget — men følger tæt.

Ærlig argumentation for NGC: Hvis du kører TensorRT-LLM eller Triton, skal du bruge NGC-billedet. Arbejdet med at matche cuDNN, NCCL, TensorRT og CUDA er nu færdigt. For upstream PyTorch eller vLLM er de offentlige billeder (pytorch/pytorch:..., vllm/vllm-openai:...) er mindre og hurtigere at opdatere — NGC er overkill.

MIG — og hvorfor det ikke gælder for Kentinos sortiment

MIG opdeler en enkelt GPU i op til syv isolerede skiver, hver med sin egen hukommelse, beregnings- og fejldomæne. Nyttig til multi-tenant inferens — fem brugere får 1/7 af en H100 med hård isolation.

MIG er ikke tilgængelig på forbrugerkort (RTX 5090, 4090) eller Blackwell-arbejdsstationskort (RTX Pro 6000). Det er begrænset til datacenter-SKU'er — H100, H200, A100, B100, B200, GB200. Kentino leverer ikke SXM-formfaktor-datacenter-GPU'er, så MIG er ikke en del af nogen Kentino-builds.

Erstatningen på forbruger-/arbejdsstationskort er MPS (Multi-Process Service) – flere processer deler GPU-beregningsplanlæggeren. Ikke isoleret som MIG (én dårlig proces kan OOM-dræbe enheden), men for pålidelig multi-tenant-inferens fungerer det og koster ingenting. Hvis du virkelig har brug for MIG, skal du bruge datacenter-SKU-linjen gennem en anden integrator.

Fejlfinding — de fejl, der rammer alle

CUDA error: no kernel image is available for execution on the device (fejl 209). Containerens CUDA-runtime har ingen kerner til din GPU's beregningskapacitet — normalt et CUDA 12.4-billede på et Blackwell-kort (sm_120), der kræver 12.8+. Rettelse: nyere billede, eller byg med det rigtige. TORCH_CUDA_ARCH_LIST.

CUDA error: forward compatibility was attempted on non supported HW (fejl 100). Værtsdriveren er ældre end runtime-programmet i containeren kræver. Rettelse: Opgrader værtsdriveren — og installer fra NVIDIAs repo, ikke Ubuntus forældede pakkede version.

Failed to initialize NVML: Driver/library version mismatch. Driver opgraderet via apt uden genstart; kernelmodulet er gammelt, brugerområdet er nyt. Rettelse: genstart. (Hvis du ikke kan, rmmod nvidia-modulerne og modprobe dem tilbage — men genstart er sikrere.)

nvidia-container-cli: initialization error: nvml error: driver not loaded. Værktøjskassen er installeret, men driverkernemodulet er ikke indlæst. Normalt en ny installation, hvor nvidia-smi på værten fejler allerede. Ret værten, derefter containeren.

OCI runtime exec failed: ... no such file or directory on --gpus all. Runtime-hook'en er ikke registreret hos Docker. Kør igen sudo nvidia-ctk runtime configure --runtime=docker && sudo systemctl restart dockerHvis det ikke er løst, tjek /etc/docker/daemon.json en "runtimes" blok.

Bygge fra kilden vs. præbygget

PyTorch, vLLM, llama.cpp, FlashAttention — alle har præbyggede hjul og billeder. Byg kun fra kildekode, når du har brug for en uudgivet funktion, er på en beregningskapacitet, som upstream-hjul ikke er målrettet mod, eller kompilerer mod brugerdefineret CUDA/cuDNN. En PyTorch fra kildekode er 30-90 minutter på EPYC med nul perf gain, medmindre du sender brugerdefinerede CMake-flag. Kildekode-builds er svaret på et specifikt problem, ikke standarden.

---

Dette er en del af Kentino Wiki, en referenceserie om AI-beregning, robotteknologi og de systemer, der forbinder dem. Kommentarer og rettelser er velkomne på info@kentino.com.