CUDA, cuDNN et NVIDIA Container Toolkit : une configuration raisonnable pour un serveur d’IA

Vous disposez d'un serveur fraîchement installé avec quatre ou huit GPU, Ubuntu 22.04 ou 24.04, et le pilote NVIDIA installé (conformément à la documentation). L01), Et nvidia-smi L'objectif est d'obtenir des résultats cohérents. Voilà pour le plancher. Au-dessus se trouve une pile complexe – CUDA, cuDNN, le kit d'outils de conteneurisation, les environnements d'exécution, les images NGC – que la plupart des guides survolent. Cet article vous guide du pilote jusqu'au point où… docker run --gpus all Chaque carte s'illumine et un conteneur vLLM sert de jetons.

Il a un avis tranché sur la voie à suivre et il est honnête quant à celle qui s'avère payante.

Le triptyque pilote / environnement d'exécution / boîte à outils

Trois éléments sont commercialisés sous l'appellation « CUDA » et sont constamment confondus :

C'est le pilote qui compte lors de l'exécution. Un pilote prend en charge un maximales Version du runtime CUDA : le runtime doit être cette version ou une version antérieure. Le toolkit n’est nécessaire que si vous compilez vous-même le code CUDA ; dans 95 % des cas, il n’est pas requis. nvcc sur l'hôte.

C’est pourquoi les conteneurs fonctionnent : l’image intègre son propre environnement d’exécution CUDA, l’hôte n’a besoin que du pilote. Le pilote hôte est le seul élément qui doit être correct. Tout le reste est portable.

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

Cette image illustre la différence entre un après-midi de travail et trois jours d'enfer de dépendance.

CUDA 12.x ou 13.x : lequel choisir ?

Les deux sont en service actif en mai 2026. Voici la matrice réelle des charges de travail exécutées par les serveurs Kentino :

La version par défaut de Kentino est CUDA 13.0 sur les nouvelles versions. Tous les GPU de la gamme (5090, 4090, RTX Pro 6000 Blackwell, L40, L4) sont pris en charge, vLLM distribue désormais par défaut les roues 13.0 sur PyPI et vllm/vllm-openai L'image utilise la version 13.0, PyTorch 2.11 (version avec laquelle vLLM est livré) est conçu pour la version 13.0, et les nouvelles fonctionnalités (FlashAttention 3 sur Blackwell, noyaux d'entraînement FP8) ciblent d'abord la version 13.x.

Restez sur la version 12.8 uniquement si : Pour reproduire un benchmark figé, un kit de développement logiciel (SDK) fournisseur inchangé ou exclusivement des cartes graphiques antérieures à Blackwell. Aucune version antérieure à 12.4 n'est requise pour les nouvelles installations ; les bugs ont été corrigés en amont il y a deux ans.

Installation propre du pilote et de CUDA

Ubuntu 24.04 LTS (la version 22.04 est identique). La solution la plus simple est d'utiliser CUDA de NVIDIA. apt dépôt :

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

Après le redémarrage, nvidia-smi Devrait signaler le pilote 570.x et CUDA 13.0. Pièges à éviter :

• N'installez pas le cuda méta-paquet Sauf si vous voulez tout installer. Cela inclut les outils, les exemples, GDS, Nsight et les paquets de broches que vous n'avez pas souhaités. Choisissez cuda-runtime-13-0 or cuda-toolkit-13-0 explicitement.
• Épingler le pilote Les mises à niveau automatiques ne peuvent donc pas déployer le module du noyau : sudo apt-mark hold cuda-drivers cuda-drivers-570 nvidia-driver-570 nvidia-dkms-570 libnvidia-compute-570.
• Une branche de conducteur à la fois. Mélanger les kits 550 et 570 produit un système qui démarre mais où nvidia-smi renvoie une erreur obscure de non-concordance de version. La solution est : apt purge '*nvidia*' '*cuda*' et recommencer à zéro — mieux vaut ne pas en arriver là.

cuDNN — apt ou tarball ?

cuDNN est la bibliothèque de primitives d'apprentissage profond (convolution, attention, RNN). PyTorch, TensorFlow et JAX en dépendent. Depuis la version 9.x, il existe deux méthodes d'installation.

apte (recommandé) :

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

Installe sur /usr/lib/x86_64-linux-gnu/, est prise en charge par l'éditeur de liens dynamique et s'intègre au gestionnaire de paquets afin que les mises à jour de sécurité soient diffusées. Une seule version CUDA de cuDNN 9 peut être installée à la fois. - non libcudnn9-cuda-12 et libcudnn9-cuda-13 côte à côte via appartement.

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/

L'utilisation d'une archive tar est judicieuse pour installer plusieurs versions de cuDNN sur un même hôte, pour des bundles isolés du réseau ou pour le verrouillage de versions spécifiques. Pour tout le reste : utilisez apt. La documentation NVIDIA recommande l'utilisation de paquets de distribution lorsque c'est possible ; l'archive tar n'est pas un programme d'installation, mais une archive de redistribution.

Réponse honnête : Si vous utilisez des conteneurs NGC, n'installez surtout pas cuDNN sur l'hôte. Il est inclus dans l'image.

Conteneurs ou métal nu : quand choisir ?

La décision la plus importante de toute la pile, sans réponse universelle. Le compromis observé sur des montages Kentino réels :

Les performances CUDA conteneurisées par rapport aux performances CUDA physiques sont négligeables sur les noyaux modernes — un pour cent au pire, généralement du bruit. Quiconque prétend le contraire teste le stockage ou le réseau, et non la puissance de calcul du GPU.

Métal nu : à la recherche des derniers 2 à 3 % pour un article, débogage du noyau avec cuda-gdb / compute-sanitizer / Nsight où la couche conteneur fait obstacle, ou un processus monopolise la machine pendant des années.

Conteneurs (par défaut chez Kentino) : boîtes multi-utilisateurs, PyTorch 2.5 et 2.11 côte à côte, en changeant de framework d'inférence (vLLM, SGLang, TensorRT-LLM) sans reconstruire l'hôte, ou un déploiement que vous pouvez docker pull Installés sur un nouveau serveur et opérationnels en cinq minutes.

Pour un laboratoire de robotique ou un groupe de recherche : conteneurs. Pour un banc d’essai avec une seule charge de travail, un serveur physique suffit.

nvidia-container-toolkit — qu'est-ce que c'est et comment le configurer

Le kit d'outils est le lien qui permet à un conteneur d'accéder au GPU de l'hôte. Sans lui, nvidia-smi L'opération échoue à l'intérieur d'un conteneur. Dans ce cas, le conteneur détecte le pilote, les périphériques et un stub d'exécution injecté.

Installez:

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

Cette dernière commande devrait afficher l'hôte. nvidia-smi Sortie depuis l'intérieur du conteneur. Si c'est le cas, la pile est câblée.

Podman

Podman utilise 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

Podman sans root + CDI est la configuration la plus propre pour les serveurs multi-utilisateurs où vous ne souhaitez pas que les utilisateurs soient dans le système. docker groupe (qui est effectivement la racine).

CDI vs exécution héritée

Deux modes d'exposition des GPU :

• Legacy nvidia hook d'exécution - quoi --gpus all Utilisé depuis des années, Docker invoque un hook qui monte les bibliothèques de pilotes et les périphériques dans le conteneur lors de l'exécution.
• CDI (Interface de périphérique conteneur) — une spécification ouverte pour déclarer l'accès aux périphériques. nvidia-ctk cdi generate écrit un fichier YAML énumérant les GPU sous forme de périphériques nommés (nvidia.com/gpu=0, nvidia.com/gpu=all); tout environnement d'exécution compatible CDI les consomme.

Situation à mi-2026 :

Pour une installation Docker sur un seul serveur, l'ancienne méthode fonctionne encore parfaitement. Pour toute application utilisant Kubernetes, sans privilèges root ou multi-utilisateurs, passez à CDI : c'est là que NVIDIA investit. La migration est non invasive : installez le kit d'outils, générez la spécification CDI, puis effectuez le remplacement. --gpus all pour --device=nvidia.com/gpu=allLes deux modes peuvent coexister.

Transfert direct du GPU — qu'est-ce que --gpus all fait réellement

Lorsque vous courez docker run --gpus all my-image le hook d'exécution lit NVIDIA_VISIBLE_DEVICES / NVIDIA_DRIVER_CAPABILITIES, supports /dev/nvidia* dans le conteneur avec les permissions cgroup, monte le pilote hôte. .so fichiers dans, et ensembles LD_LIBRARY_PATH Le lien les trouve donc.

Ce que vous contrôlez :

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

Pour un serveur à 8 GPU effectuant du vLLM parallèle tensoriel, utilisez --gpus allPour un serveur multi-locataires où les utilisateurs bénéficient de tranches de 4 GPU, épinglez par UUID — l'épinglage basé sur l'index ne fonctionne plus si vous rebranchez les câbles.

Conteneurs NGC — quand les utiliser

Le catalogue NGC de NVIDIA (nvcr.io) propose des images pour PyTorch, TensorRT, TensorRT-LLM, Triton et d'autres technologies. Ces images sont volumineuses (5 à 15 Go), mais testées et livrées avec des combinaisons de runtime cuDNN/NCCL/CUDA validées par NVIDIA. Disponible en mai 2026.

Les balises sont <year>.<month>-py3, coupé mensuellement. Pas exactement en amont — réparé et reconstruit — mais suit de près.

Argumentaire honnête en faveur de NGC : Si vous utilisez TensorRT-LLM ou Triton, utilisez l'image NGC. Le travail d'adaptation de cuDNN, NCCL, TensorRT et CUDA est terminé. Pour PyTorch ou vLLM en amont, les images publiques (pytorch/pytorch:..., vllm/vllm-openai:...) sont plus petites et plus rapides à mettre à jour — NGC est surdimensionné.

MIG — et pourquoi cela ne s'applique pas à la gamme de Kentino

MIG partitionne un GPU unique en sept tranches isolées au maximum, chacune disposant de sa propre mémoire, de ses propres ressources de calcul et de son propre domaine de gestion des pannes. Utile pour l'inférence multi-utilisateurs : cinq utilisateurs bénéficient ainsi d'un septième de la capacité d'un H100 grâce à une isolation stricte.

MIG n'est pas disponible sur les cartes grand public (RTX 5090, 4090) ou les cartes de station de travail Blackwell (RTX Pro 6000). Elle est limitée aux références pour centres de données : H100, H200, A100, B100, B200 et GB200. Kentino ne fournit pas de GPU pour centres de données au format SXM ; par conséquent, MIG n’est inclus dans aucune configuration Kentino.

Le substitut sur les cartes grand public/postes de travail est MPS (Service multiprocessus) Plusieurs processus partagent le planificateur de calcul GPU. Contrairement à MIG, l'isolation n'est pas totale (un processus défaillant peut entraîner l'arrêt du périphérique par manque de mémoire), mais cette solution est efficace et gratuite pour l'inférence mutualisée de confiance. Si vous avez réellement besoin de MIG, vous devrez vous procurer la gamme de produits Datacenter auprès d'un autre intégrateur.

Dépannage — les erreurs qui pénalisent tout le monde

CUDA error: no kernel image is available for execution on the device (erreur 209). L'environnement d'exécution CUDA du conteneur ne dispose pas des noyaux nécessaires pour exploiter pleinement la capacité de calcul de votre GPU — généralement une image CUDA 12.4 sur une carte Blackwell (sm_120) qui requiert la version 12.8 ou supérieure. Solution : utiliser une image plus récente ou compiler avec les paramètres appropriés. TORCH_CUDA_ARCH_LIST.

CUDA error: forward compatibility was attempted on non supported HW (erreur 100). Le pilote hôte est plus ancien que la version requise par l'environnement d'exécution du conteneur. Solution : mettez à jour le pilote hôte et installez-le depuis le dépôt NVIDIA, et non depuis la version obsolète fournie par Ubuntu.

Failed to initialize NVML: Driver/library version mismatch. Pilote mis à jour via apt sans redémarrage ; le module noyau est ancien, l’espace utilisateur est récent. Solution : redémarrer. (Si vous ne pouvez pas, rmmod les modules nvidia et modprobe les récupérer — mais redémarrer est plus sûr.)

nvidia-container-cli: initialization error: nvml error: driver not loaded. L'outil est installé, mais le module noyau du pilote n'est pas chargé. Généralement, une installation neuve où nvidia-smi Le problème sur l'hôte est déjà résolu. Corrigez d'abord l'hôte, puis le conteneur.

OCI runtime exec failed: ... no such file or directory on --gpus all. Le hook d'exécution n'est pas enregistré auprès de Docker. Veuillez relancer l'opération. sudo nvidia-ctk runtime configure --runtime=docker && sudo systemctl restart dockerSi le problème persiste, vérifiez /etc/docker/daemon.json | "runtimes" bloque.

Compilation à partir du code source ou préconfigurée

PyTorch, vLLM, llama.cpp et FlashAttention disposent tous de roues et d'images précompilées. Ne compilez à partir des sources que si vous avez besoin d'une fonctionnalité non publiée, si votre machine offre une capacité de calcul non prise en charge par les roues d'origine, ou si vous compilez avec une version personnalisée de CUDA/cuDNN. La compilation de PyTorch à partir des sources prend entre 30 et 90 minutes sur EPYC, sans gain de performance, sauf si vous utilisez des options CMake personnalisées. La compilation à partir des sources est la solution à un problème spécifique, et non le comportement par défaut.

---

Ceci fait partie du Kentino Wiki, une série de référence sur l'intelligence artificielle, la robotique et les systèmes qui les connectent. Commentaires et corrections bienvenus. info@kentino.com.