NVIDIA¶

Siehe auch

Verwandte Artikel

Offizielle Dokumentation

CUDA (ursprünglich Compute Unified Device Architecture, ein Akronym, das NVIDIA heute nicht mehr ausschreibt) ist NVIDIAs Programmiermodell für allgemeine Berechnungen auf der GPU. Damit laufen rechenintensive, parallelisierbare Workloads wie KI-Modelle auf der Grafikkarte statt auf der CPU. Dieser Artikel beschreibt Installation und Betrieb auf RHEL 9, RHEL 10 und Fedora.

GPU-Architekturen und Treiber-Varianten¶

Welcher Treiber benötigt wird, hängt von der GPU-Architektur ab. Entscheidend ist der GPU System Processor (GSP), den NVIDIA mit der Turing-Architektur eingeführt hat: Nur Karten ab Turing unterstützen die offenen Kernel-Module (nvidia-open), die NVIDIA als Standard empfiehlt. Ältere Karten (Maxwell, Pascal, Volta) brauchen den proprietären Treiber, werden aber schrittweise abgelöst: CUDA Toolkit 13.0 (2025) hat die Unterstützung für Maxwell, Pascal und Volta entfernt.

Architektur	Release	Treiber-/CUDA-Status
Kepler	2012	End-of-Life, Treiber-Support endete 2024 (R470-Legacy-Branch)
Maxwell	2014	vor Turing, kein GSP; nur proprietärer Treiber; von CUDA 13.0 (2025) entfernt
Pascal	2016	vor Turing, kein GSP; nur proprietärer Treiber; von CUDA 13.0 (2025) entfernt
Volta	2017	vor Turing, kein GSP; nur proprietärer Treiber; von CUDA 13.0 (2025) entfernt
Turing	2018	GSP vorhanden; offene Kernel-Module (Standard), von CUDA 13 unterstützt
Ampere	2020	offene Kernel-Module (Standard), von CUDA 13 unterstützt
Ada Lovelace	2022	offene Kernel-Module (Standard), von CUDA 13 unterstützt
Hopper	2022	offene Kernel-Module (Standard), von CUDA 13 unterstützt
Blackwell	2024	offene Kernel-Module (Standard), von CUDA 13 unterstützt

Nach Blackwell stehen die Architekturen Rubin (für 2026 angekündigt), Rubin Ultra (2027) und Feynman (2028) auf NVIDIAs Roadmap; sie sind Stand 2026-05 noch nicht verfügbar.

Die Architektur der verbauten Karte lässt sich aus dem Modell ableiten:

lspci | grep --ignore-case vga

CUDA installieren¶

NVIDIA stellt CUDA über sein eigenes Repository bereit. Auf RHEL und kompatiblen Distributionen werden zusätzlich EPEL und CRB vorausgesetzt; sie liefern DKMS und Build-Abhängigkeiten für die Treiber-Module (Details siehe EPEL und CRB). dnf config-manager stammt aus dnf-plugins-core.

RHEL 9 (Rocky Linux, AlmaLinux, CentOS Stream):

dnf --assumeyes install dnf-plugins-core
dnf config-manager --set-enabled crb
dnf --assumeyes install https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm
dnf config-manager --add-repo https://developer.download.nvidia.com/compute/cuda/repos/rhel9/x86_64/cuda-rhel9.repo

RHEL 10 (Rocky Linux, AlmaLinux, CentOS Stream):

dnf --assumeyes install dnf-plugins-core
dnf config-manager --set-enabled crb
dnf --assumeyes install https://dl.fedoraproject.org/pub/epel/epel-release-latest-10.noarch.rpm
dnf config-manager --add-repo https://developer.download.nvidia.com/compute/cuda/repos/rhel10/x86_64/cuda-rhel10.repo

Auf registriertem RHEL wird CRB nicht über config-manager, sondern über subscription-manager repos --enable codeready-builder-for-rhel-$(rpm -E %rhel)-$(arch)-rpms aktiviert.

Fedora nutzt dnf 5 mit anderer Syntax und braucht weder EPEL noch CRB. Neuestes verfügbares Repo ist (Stand 2026-05) fedora43:

dnf --assumeyes install dnf-plugins-core
dnf config-manager addrepo --from-repofile=https://developer.download.nvidia.com/compute/cuda/repos/fedora43/x86_64/cuda-fedora43.repo

NVIDIA bietet zwei Meta-Pakete:

cuda installiert alles: Toolkit plus vollständigen Treiber inklusive Desktop-Komponenten, und folgt der jeweils neuesten CUDA-Version. Der einfachste Weg auf einer Workstation mit Display.
cuda-toolkit installiert nur das Toolkit, ohne Treiber. Den Treiber wählt und installiert man danach selbst. Das ist vor allem auf headless Servern sinnvoll, wo nur der compute-only-Treiber ohne Desktop-Komponenten gewünscht ist.

dnf --assumeyes install cuda

# a reboot is needed so the driver kernel modules load cleanly
reboot

# after the reboot, nvidia-smi should detect the installed GPU(s)
nvidia-smi --list-gpus

Treiber installieren¶

Ohne Treiber lässt sich die GPU nicht nutzen. Mit dem cuda-Paket ist er bereits installiert; nach cuda-toolkit (das keinen Treiber enthält) wird er hier nachgezogen. Welche Variante passt, richtet sich nach der Architektur (Tabelle oben). Die *-dkms-Pakete nutzen DKMS (Dynamic Kernel Module Support), ein Framework, das die out-of-tree Treiber-Module nach jedem Kernel-Update automatisch neu baut, sodass kein manuelles Nachkompilieren nötig ist.

Offener Treiber (Turing und neuer):

dnf --assumeyes install nvidia-open

Headless bzw. compute-only (ohne Desktop-Komponenten) stattdessen:

dnf --assumeyes install nvidia-driver-cuda kmod-nvidia-open-dkms

Proprietärer Treiber (Maxwell, Pascal, Volta):

dnf --assumeyes install cuda-drivers

Headless bzw. compute-only stattdessen:

dnf --assumeyes install nvidia-driver-cuda kmod-nvidia-latest-dkms

Nach der Installation ist ein Reboot nötig, damit die Kernel-Module sauber laden:

reboot
nvidia-smi --list-gpus

Bemerkung

Wegen des Phasing-out von Maxwell, Pascal und Volta liegen die proprietären Metapakete nicht auf allen Versionen im CUDA-Repo. Stand Treiber-Branch R595 (2026-05) fehlen cuda-drivers und kmod-nvidia-latest-dkms im CUDA-Repo für RHEL 9 (dort nur die offenen Module und nvidia-driver*), für RHEL 10 sind sie vorhanden. Für diese älteren Karten gegebenenfalls eine Legacy-Treiber-Branch verwenden.

Nouveau und Nova deaktivieren¶

Manche Distributionen laden für NVIDIA-Karten automatisch einen quelloffenen Treiber: das etablierte nouveau oder das neuere, in Rust geschriebene Nova (Kernel-Modul nova_core, seit Linux 6.15, für Turing und neuer). Beide müssen deaktiviert werden, damit der NVIDIA-Herstellertreiber die Karte übernehmen kann.

# blacklist the in-tree open drivers
echo 'blacklist nouveau' > /etc/modprobe.d/nouveau-blacklist.conf
echo 'blacklist nova_core' > /etc/modprobe.d/nova_core-blacklist.conf

# back up and rebuild the initramfs
cp /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r)-$(date --iso-8601=seconds).img
dracut --force --verbose /boot/initramfs-$(uname -r).img $(uname -r)

Container Toolkit¶

Sollen Container auf die GPU zugreifen (siehe Container), wird das nvidia-container-toolkit benötigt. Es liegt in einem eigenen Repository, nicht im CUDA-Repo.

# add the NVIDIA Container Toolkit repository
curl \
    --silent \
    --location \
    --output /etc/yum.repos.d/nvidia-container-toolkit.repo \
    https://nvidia.github.io/libnvidia-container/stable/rpm/nvidia-container-toolkit.repo
dnf --assumeyes install nvidia-container-toolkit

# generate the Container Device Interface (CDI) spec so containers can reach the GPU(s);
# regenerate it whenever the hardware or the CUDA configuration changes
nvidia-ctk cdi generate --output=/etc/cdi/nvidia.yaml

# list the GPUs nvidia-ctk detected
nvidia-ctk cdi list

# test: nvidia-smi inside a throwaway container must match the host output
podman run --rm --security-opt=label=disable --device=nvidia.com/gpu=all ubuntu nvidia-smi --list-gpus

Mehrere GPUs¶

Sind mehrere Grafikkarten verbaut, eignet sich nvtop zur Diagnose, etwa um die Last pro Karte oder die zugreifenden Prozesse zu sehen. Anders als nvidia-smi arbeitet nvtop herstellerübergreifend und zeigt so zum Beispiel die integrierte Intel-GPU und die dedizierte NVIDIA-Karte nebeneinander. Auf RHEL 9 und 10 ist nvtop über EPEL verfügbar (siehe EPEL), unter Fedora direkt aus den offiziellen Repositories.

Beim offenen Treiber lässt sich mit switcherooctl ein einzelnes Grafikprogramm gezielt auf einer bestimmten Karte starten. switcherooctl (Paket switcheroo-control) ist auf den meisten Desktop-Distributionen vorinstalliert.