GPU-Server mit Ansible automatisieren: NVIDIAs Treiber-Rolle, Container Toolkit, DCGM, MIG

Was Ansible auf einem GPU-Server übernehmen sollte

Um einen GPU-Server mit Ansible zu automatisieren, nutzen Sie NVIDIAs Rolle nvidia.nvidia_driver für den Treiber (auf Blackwell-Karten mit eigener Paketliste für die Open-Module), wenige dokumentierte Tasks für Container Toolkit und DCGM, eine nvidia-mig-parted-Datei für MIG-Layouts, und Sie verteilen Treiber-Updates mit serial in Etappen. Das sind die fünf Schichten, die ein GPU-Server einem gewöhnlichen Linux-Host hinzufügt: der NVIDIA-Treiber, das Container Toolkit mit seiner CDI-Geräteliste, DCGM für Zustand und Diagnose, ein MIG-Layout auf Karten, die eines nutzen, und Einstellungen wie der Persistence Mode.

Jede Schicht hat eine Version und eine Reihenfolge, und jede scheitert unbemerkt, wenn ein Host von den anderen abweicht. Als Ansible-Rollen mit einem Inventar beschrieben, liefern sie einem Infrastrukturteam auf dem fünften Server dasselbe Ergebnis wie auf dem ersten, dazu eine Aufzeichnung, welcher Branch wo läuft.

Firmware und BIOS-Einstellungen sind eine andere Sache. Ansible kann die vBIOS-Version jeder Karte lesen und abbrechen, wenn eine abweicht, das Update selbst läuft aber über die Werkzeuge des Serverherstellers und den BMC, wie unser Leitfaden zu Firmware-Updates für vBIOS, BMC und BIOS beschreibt. Auf Kubernetes-Knoten installiert der GPU Operator Treiber und Toolkit selbst; Ansible bereitet dann das Betriebssystem vor und hört dort auf.

README und Vorgaben von NVIDIAs ansible-role-nvidia-driver, Installationsanleitung und CDI-Seite des Container Toolkit (18. September 2026), DCGM-4.6-Benutzerhandbuch (17. Juni 2026) und README von nvidia-mig-parted, gelesen am 25. Oktober 2026.

Die Ansible-Rolle für den NVIDIA-Treiber: was sie tut und wo sie läuft

NVIDIA veröffentlicht auf GitHub eine Ansible-Rolle für den Treiber unter der Lizenz BSD-3-Clause. Sie wird mit ansible-galaxy install nvidia.nvidia_driver installiert und braucht die Collection community.general, die separat zu installieren ist; ein Checkout aus dem Quellcode nennt seine Abhängigkeiten in requirements.yml. Das Beispiel-Playbook im README wendet die Rolle auf eine Hostgruppe namens gpu_nodes an.

Die Rolle startet Knoten während der Installation neu, und das README sagt klar, was daraus folgt: ansible-playbook läuft auf einer anderen Maschine als dem GPU-Knoten. Mit einer lokalen Verbindung verweigert die Rolle den Lauf, und per SSH auf localhost kann sie die Maschine neu starten, auf der das Playbook läuft. Die Variable nvidia_driver_skip_reboot schaltet den Neustart ab, was zu einem Wartungsprozess passt, der nach eigenem Plan neu startet.

README von NVIDIAs ansible-role-nvidia-driver auf GitHub, gelesen am 25. Oktober 2026.

Ubuntu 26.04, RHEL 10 und Rocky Linux 10 fehlen in dieser Liste, obwohl CUDA und der GPU Operator sie unterstützen, wie unser Vergleich Linux für GPU-Server zeigt. Eine Flotte auf diesen Releases testet die Rolle dort zuerst oder schreibt eigene Treiber-Tasks nach NVIDIAs Installationsanleitung.

Variablen je Inventargruppe

Die Datei mit den Vorgaben zeigt, wie die Rolle entscheidet, was sie installiert. nvidia_driver_branch steht auf „580“, dem Long-Term-Support-Branch, den NVIDIA bis Juni 2028 unterstützt, wie unser Leitfaden zu NVIDIA-Treiber-Branches und CUDA-Versionen erklärt. nvidia_driver_package_version ist leer, es wird also das neueste Paket des Branches installiert, und nvidia_driver_package_state steht auf present. Der Persistence Mode ist standardmäßig an (nvidia_driver_persistence_mode_on: yes), und Moduloptionen landen in /etc/modprobe.d/nvidia.conf.

Unter Ubuntu installiert die Rolle aus den Repositorys von Canonical, solange nvidia_driver_ubuntu_install_from_cuda_repo nicht gesetzt ist. Ihre Paketliste verbindet den Branch mit dem Suffix „-server“: nvidia-headless, nvidia-utils, nvidia-headless-no-dkms und nvidia-kernel-source, jeweils gefolgt von Branch und Suffix. Aus dem CUDA-Repository installiert sie stattdessen cuda-drivers- mit dem Branch. Das README nennt eine Falle beim Festschreiben: Unter Ubuntu ist der Branch Teil des Paketnamens, eine fest gewählte Version aus einem älteren Branch braucht also auch die passende Branch-Variable, sonst kombiniert die Rolle den Standardnamen mit einer unpassenden Version.

Unter RHEL und Rocky ab Version 8 aktiviert die Installations-Task einen DNF-Modulstream des Moduls nvidia-driver, standardmäßig den Branch mit dem Zusatz „-dkms“. Sie installiert außerdem Kernel-Header und kernel-devel für den laufenden Kernel, DKMS aus EPEL, und setzt nouveau auf die Blacklist.

Open-Kernel-Module für RTX PRO Blackwell

Keine der Standard-Paketlisten nennt ein Paket mit Open-Kernel-Modulen. Für Blackwell ist das entscheidend: NVIDIA erklärt, dass die proprietären Treiber auf Blackwell nicht unterstützt werden und die Open-Module zu verwenden sind, und jede RTX-PRO-Blackwell-Karte, auch die RTX PRO 6000 Server Edition, ist eine Blackwell-GPU. Canonical veröffentlicht die Open-Variante mit dem Suffix „-server-open“, etwa nvidia-driver-580-server-open und die vorkompilierten Module linux-modules-nvidia-580-server-open-generic, die unser Leitfaden zum NVIDIA-Treiber unter Secure Boot aus Canonicals Archiv auflistet. Für RHEL 8 und 9 nennt NVIDIAs Anleitung die Open-DKMS-Streams open-dkms oder 580-open.

Für H200 NVL, L40S und L4 funktioniert die proprietäre Variante weiterhin, das README von NVIDIAs Treiber 595.84 empfiehlt die Open-Module aber für jede GPU, die sie unterstützt. Unser Beispiel überschreibt deshalb nvidia_driver_ubuntu_packages in den group_vars mit den Open-Paketen des Branches, vorher auf einem Host mit apt-cache policy geprüft. Nach dem ersten Lauf ist die Modulvariante auf dem Host sichtbar: Mit den Open-Modulen beginnt /proc/driver/nvidia/version mit „NVRM version: NVIDIA UNIX Open Kernel Module“, und modinfo nvidia meldet die Lizenz „Dual MIT/GPL“; die proprietäre Variante meldet „NVIDIA“. Halten Sie eine Inventargruppe je Kartentyp, damit ein MIG-Layout oder ein Branch-Test für einen Typ nicht versehentlich die anderen erreicht.

Unser Beispiel. Support-Daten der Branches aus NVIDIAs Lebenszyklustabelle (9. September 2026); Paketnamen aus Canonicals Archiv, wie in unserem Secure-Boot-Leitfaden aufgeführt (24. Oktober 2026); Modulvarianten aus dem README des NVIDIA-Treibers 595.84, gelesen am 25. Oktober 2026.

Server, die wir auf Bestellung bauen, kommen auf Wunsch mit Betriebssystem, Treiber-Branch und Container-Laufzeit, sodass der erste Ansible-Lauf einen bekannten Zustand vorfindet. Nennen Sie uns Ihre Distribution und den Branch, den Ihre Playbooks festschreiben, und wir installieren ihn vor der Lieferung.

Container Toolkit und CDI als Ansible-Tasks

NVIDIAs Installationsanleitung für das Container Toolkit, zuletzt aktualisiert am 18. September 2026, setzt NVIDIA_CONTAINER_TOOLKIT_VERSION auf 1.20.1-1 und installiert vier Pakete in genau dieser Version: nvidia-container-toolkit, nvidia-container-toolkit-base, libnvidia-container-tools und libnvidia-container1. Das Repository kommt von nvidia.github.io: ein GPG-Schlüssel, in einen Keyring umgewandelt, und eine Listendatei für apt, oder eine .repo-Datei für dnf. Jeder Schritt wird zu einer Ansible-Task, die Version zu einer Variablen in group_vars.

Die Konfiguration der Laufzeit ist ein Befehl, der eine Datei schreibt. nvidia-ctk runtime configure mit --runtime=docker ändert /etc/docker/daemon.json; für containerd und CRI-O legt er die Drop-in-Dateien 99-nvidia.toml unter /etc/containerd/conf.d und /etc/crio/conf.d an. Im Playbook braucht der Befehl ein creates-Argument oder eine Prüfung der Datei, und einen Handler, der die Engine nur neu startet, wenn sich die Datei geändert hat. Der Treiber muss vorher installiert sein; NVIDIAs Anleitung nennt ihn als Voraussetzung.

CDI, das Container Device Interface, beschreibt die GPUs als benannte Geräte für Podman und andere Engines. Seit Toolkit 1.18.0 wird die Spezifikation laut NVIDIA „automatically generated and updated by a systemd service called nvidia-cdi-refresh“: Eine Path-Unit löst ihn nach Installation oder Upgrade von Toolkit oder Treiber und beim Booten aus. Zwei Ereignisse deckt er nicht ab, das Entfernen des Treibers und eine MIG-Umkonfiguration. Ein Playbook, das ein MIG-Layout ändert, startet deshalb danach nvidia-cdi-refresh.service neu und prüft das Ergebnis mit nvidia-ctk cdi list, das Namen wie nvidia.com/gpu=0 zeigt oder nvidia.com/gpu=1:0 für das erste MIG-Gerät auf GPU 1. Unser Leitfaden zur GPU-Zuweisung an Docker ohne Kubernetes zeigt, wie Container diese Namen nutzen.

DCGM: installieren, starten, prüfen

DCGM 4.6, im Benutzerhandbuch von NVIDIA zuletzt aktualisiert am 17. Juni 2026, wird je CUDA-Hauptversion paketiert: datacenter-gpu-manager-4-cuda gefolgt von der CUDA-Hauptversion, die nvidia-smi für den Treiber meldet, 13 auf Hosts mit R580 und R595. Das Handbuch entfernt zuerst ältere datacenter-gpu-manager-Pakete, installiert mit empfohlenen Paketen (--install-recommends bei apt, schwache Abhängigkeiten bei dnf) und startet den Dienst mit systemctl --now enable nvidia-dcgm. Seine Prüfung ist dcgmi discovery -l, das die GPUs auflistet, die DCGM sieht.

In Ansible ist die CUDA-Hauptversion ein Wert, den Sie einmal per nvidia-smi auf dem Host auslesen, und dcgmi discovery -l wird zu einer Task, deren Ausgabe registriert und mit der für diesen Kartentyp erwarteten Kartenzahl verglichen wird. Ein Host, der nur drei von vier Karten sieht, bricht den Lauf dann ab, statt in Produktion zu gehen. DCGM führt auch die Diagnosen aus, die unser Leitfaden zum Abnahmetest von GPU-Servern nutzt, und liefert die Metriken, die unser Leitfaden zur Überwachung mit Zabbix und Checkmk sammelt.

MIG-Layouts als Code mit nvidia-mig-parted

NVIDIAs MIG Partition Editor, nvidia-mig-parted, steht unter Apache 2.0 und erscheint als deb- und rpm-Paket. Seine Konfigurationsdatei ist deklarativ: version: v1, dann ein Abschnitt mig-configs, dessen Einträge frei gewählte Namen tragen und jeweils die Zielgeräte nennen, ob MIG aktiv ist und welche MIG-Geräte als Profil und Anzahl entstehen. Für eine RTX PRO 6000 Server Edition teilt ein Eintrag mit vier Geräten 1g.24gb die Karte in Viertel, die Profile aus unserem Leitfaden zu MIG-Profilen der RTX PRO 6000.

Drei Befehle machen das Werkzeug Ansible-tauglich. nvidia-mig-parted assert -f mit der Datei und -c mit dem Eintragsnamen endet mit 0, wenn das Layout angewendet ist, und mit 1, wenn nicht; apply mit denselben Argumenten legt es an; export gibt den aktuellen Zustand aus. Eine Task, die assert ausführt, den Rückgabewert registriert und apply nur bei einem Fehler startet, ist von Haus aus idempotent. Das README weist darauf hin, dass das Werkzeug nicht sicherstellt, dass sich der Knoten in einem Zustand befindet, in dem MIG-Änderungen sauber greifen, und nennt ein bekanntes Problem: Ein geladenes Modul nvidia_drm muss vor apply entladen und danach wieder geladen werden. Stoppen Sie die GPU-Workloads auf dem Host vor dem Lauf, und starten Sie danach nvidia-cdi-refresh.service neu.

MIG-Instanzen überstehen auf Hopper und neueren GPUs keinen Neustart. NVIDIA schlägt einen systemd-Dienst um nvidia-mig-parted für den Systemstart vor, auf den das README im Verzeichnis deployments/systemd verweist; unser MIG-Leitfaden für RTX PRO Blackwell beschreibt die Voraussetzungen bei Treiber und vBIOS.

Treiber-Updates in Wellen, ohne den Dienst zu verlieren

Ein Treiber-Update auf einer produktiven Flotte braucht Etappen. Das Ansible-Schlüsselwort serial nimmt eine Zahl, einen Prozentsatz oder eine Liste: serial: [1, 5, 10] aktualisiert zuerst einen Host, dann fünf, dann jeweils zehn. Mit serial zählen Fehler je Etappe, und max_fail_percentage gilt für jede Etappe; laut Ansible-Dokumentation muss der Wert überschritten werden, nicht nur erreicht. Tasks mit run_once laufen in jeder Etappe auf einem Host.

Ein Lauf für eine Etappe folgt dieser Reihenfolge:

1. Host leeren: Container verschieben oder den Knoten im Scheduler sperren.
2. Das vBIOS jeder Karte mit nvidia-smi --query-gpu=vbios_version mit --format=csv lesen und abbrechen, wenn gleiche Karten abweichen.
3. Die Treiber-Rolle mit der neuen Paketversion anwenden und neu starten lassen, oder in einer eigenen Task neu starten.
4. nvidia-smi -L gegen die erwartete Kartenzahl prüfen, dazu dcgmi discovery -l.
5. Das MIG-Layout mit assert prüfen, nvidia-cdi-refresh.service neu starten und nvidia-ctk cdi list prüfen.
6. Den Host wieder in Betrieb nehmen und die nächste Etappe starten lassen.

Vor Schritt 3 lesen Sie die Release Notes und NVIDIAs aktuelles Security Bulletin, wie die Checkliste in unserem Branch-Leitfaden beschreibt. Ein mit nvidia-smi gesetztes Software-Leistungslimit wird beim Neuladen des Treibers gelöscht; ein Lauf, der die RTX PRO 6000 Server Edition auf 450 W begrenzt, setzt das Limit nach dem Neustart also erneut.

Wann der GPU Operator das bessere Werkzeug ist

In einem Kubernetes-Cluster verwaltet der NVIDIA GPU Operator Treiber, Container Toolkit, DCGM und MIG über eigene Ressourcen; installiert Ansible dieselben Schichten auf dem Host, konkurrieren beide Werkzeuge. Dort bereitet Ansible Betriebssystem, Kernel und Container-Laufzeit vor, und der Operator übernimmt, wie unser Leitfaden zum GPU-Sharing in Kubernetes beschreibt. Für Server ohne Internetzugang zeigen die Repositorys in diesen Tasks auf einen lokalen Spiegel; unser Leitfaden zum LLM-Server ohne Internet zeigt die Bereitstellung.

Was wir liefern

Wir bauen KI-Server auf Bestellung für Flotten, die mit Ansible verwaltet werden: einen Einstiegsserver mit zwei RTX PRO 6000 Server Edition, einen Inferenzknoten mit vier und einen Trainingsknoten mit acht H200 NVL, jeweils mit zwei AMD-EPYC-Prozessoren, vor der Lieferung montiert und getestet und EU-weit auf einen Vertrag und eine Rechnung geliefert. Unser Leitfaden zum Einrichten eines neuen GPU-Servers zeigt dieselben Schritte in manueller Reihenfolge. Schicken Sie uns Ihr Inventar und Ihre Kartentypen, und unser Team antwortet mit einer passenden Konfiguration.

FAQ