Neuen GPU-Server einrichten: vom BMC und BIOS bis zum ersten Modell in vLLM

GPU-Server einrichten: die Reihenfolge auf einen Blick

Ein neuer GPU-Server erreicht in zehn Schritten einen funktionierenden Modell-Endpunkt, und die Reihenfolge zählt mehr als jede einzelne Einstellung: der BMC vor dem BIOS, das BIOS vor dem Betriebssystem, der Treiber vor dem Container Toolkit und eine Gesundheits-Basislinie vor dem ersten Nutzer. Diese Anleitung begleitet einen Server mit vier NVIDIA RTX PRO 6000 Blackwell Server Edition, den Inferenzknoten unserer KI-Server-Seite, vom Rack bis zu einem vLLM-Endpunkt und verweist bei jedem Schritt auf den Leitfaden, der ihn ausführlich behandelt.

Unsere Anleitung; Werkzeuge und Prüfungen aus der in jedem Abschnitt genannten NVIDIA-Dokumentation, gelesen am 25. Oktober 2026.

Die Schritte 5 bis 9 sind auf jedem Server einer Flotte gleich, und unser Leitfaden GPU-Server mit Ansible automatisieren macht Rollen daraus. Die Prüfungen bei der Lieferung selbst, Seriennummern und ein langer Lastlauf, stehen in unserem Leitfaden zum Abnahmetest.

Vor dem Einschalten: Zuleitungen und GPU-Stromkabel

Vier RTX PRO 6000 Server Edition mit 600 W ziehen allein 2,4 kW, der ganze Server nach unserer Schätzung etwa 3,4 kW an der Steckdose (Karten, zwei Prozessoren EPYC 9355 und 15 Prozent für den Rest); bei einem Limit von 450 W je Karte sind es etwa 2,7 kW. Eine Zuleitung mit 230 V und 16 A, zu 80 Prozent belastet, trägt 2,94 kW, der Server braucht also einen einphasigen 32-A-Anschluss oder Drehstrom, je einen für jede Seite seiner redundanten Netzteile, ausgelegt nach der Angabe des Serverherstellers. Unser Leitfaden zu 16 A, 32 A und Drehstrom rechnet das für größere Server durch.

Prüfen Sie ein Detail im Gehäuse, bevor der Deckel wieder schließt. Die Server Edition liest die Sense-Pins ihres Stromkabels, und ein Kabel, das 450 W signalisiert, setzt Maximum und Standardlimit auf 450 W; nvidia-smi kann das Limit nicht über das hinaus anheben, was das Kabel meldet, wie unsere Seite zur Leistung der Server Edition bei 600, 450 und 300 W erklärt. Schritt 6 bestätigt das Ergebnis in der Software.

Zuerst der BMC: Netz, Konten, Firmware-Liste

Der BMC ist der eigene Verwaltungsrechner des Servers, erreichbar auch dann, wenn das Betriebssystem nicht läuft, und er wird als Erstes eingerichtet. Legen Sie seinen Port ins Management-Netz, ersetzen Sie die Werkszugangsdaten durch benannte Konten und prüfen Sie, ob Remote-Konsole und virtuelle Medien funktionieren, denn die Installation des Betriebssystems, das Einschreiben eines Secure-Boot-Schlüssels und jede spätere BIOS-Änderung laufen darüber.

Dann halten Sie die Firmware fest: BIOS, BMC und das vBIOS jeder Karte, wie der BMC sie meldet, mit Servername und Datum. Gleiche, gemeinsam gekaufte Karten sollten gleiche Versionen melden. Ob ein Update fällig ist und in welcher Reihenfolge, behandelt unser Leitfaden zu Firmware-Updates; die Redfish-Schnittstelle des BMC speist außerdem die Prüfungen außerhalb des Betriebssystems aus unserem Leitfaden zur Überwachung über BMC und Redfish.

BIOS-Einstellungen für einen Server mit mehreren GPUs

Vier Firmware-Einstellungen entscheiden, ob die Karten zusammenarbeiten, und ihre Namen unterscheiden sich je Boardhersteller; suchen Sie also nach der Funktion, nicht nach der Bezeichnung.

• Above 4G Decoding und Resizable BAR. Jede GPU braucht ein großes Adressfenster. NVIDIAs Product Brief der Server Edition gibt der Karte im Standardmodus ohne Displayausgabe ein BAR1 von 128 GiB, beide Einstellungen bleiben also an.
• IOMMU. NCCLs Leitfaden stellt fest, dass CUDA und der Treiber unter Linux auf Bare Metal keine Peer-to-Peer-Übertragungen mit der IOMMU im Translated-Modus unterstützen. Ein Host, der nur Container ausführt, kann den Passthrough-Modus nutzen oder die IOMMU abschalten; ein Host, der Karten an virtuelle Maschinen durchreicht, braucht sie eingeschaltet.
• ACS. Mit ACS läuft Peer-Verkehr über den Root Complex des Prozessors, was NCCLs Leitfaden mit langsamen Übertragungen oder Hängern in Verbindung bringt. Virtuelle Maschinen brauchen ACS, es gilt also dieselbe Trennung.
• Secure Boot. Jetzt entscheiden. Es kann mit signierten Modulen an bleiben, und die Wahl bestimmt den Treiberweg in Schritt 5.

Jede dieser Einstellungen tauscht Schutz gegen Geschwindigkeit; dokumentieren Sie sie deshalb in der Bauakte und stimmen Sie sie mit den Verantwortlichen für die Host-Sicherheit ab. Unser Leitfaden zu P2P, IOMMU und ACS auf RTX-PRO-6000-Servern nennt die Kernelparameter und die Tests.

Ubuntu oder RHEL installieren, dann den NVIDIA-Treiber

Für einen Server, der Ende 2026 installiert wird, stehen Ubuntu 24.04 LTS, RHEL 9 und RHEL 10 auf jeder Support-Liste von NVIDIA, einschließlich CUDA, GPU Operator und NVIDIA AI Enterprise, wie unser Vergleich Linux für GPU-Server zeigt. Installieren Sie es mit aktuellen Updates vor dem Treiber, denn die Kernelmodule werden für den laufenden Kernel gebaut oder ausgewählt.

Der Treiber muss die Open-Kernel-Module nutzen. Laut NVIDIAs Treiber-README werden Blackwell und neuere GPUs nur von den Open-Kernel-Modulen unterstützt („Blackwell and later are only supported by the open kernel modules“), und jede RTX-PRO-Blackwell-Karte ist eine Blackwell-GPU. Unter Ubuntu heißt das: Canonicals -server-open-Pakete, signiert für Secure Boot, oder NVIDIAs eigenes Repository mit nvidia-open und einem vorher installierten Pinning-Paket wie nvidia-driver-pinning-580. Unter RHEL 10 gibt es von Red Hat signierte kmod-nvidia-open-Pakete; RHEL 8 und 9 nutzen DKMS-Streams mit eigenem Schlüssel unter Secure Boot. Unser Leitfaden zum NVIDIA-Treiber unter Secure Boot beschreibt jeden Weg, und unser Leitfaden zu Treiber-Branches erklärt, warum ein Produktivserver R580 oder R595 nutzt.

Nach dem Neustart bestätigen drei Prüfungen das Ergebnis. nvidia-smi -L listet vier GPUs. /proc/driver/nvidia/version beginnt mit „NVRM version: NVIDIA UNIX Open Kernel Module“, der Zeile, die NVIDIAs README für die Open-Variante nennt. Und die CUDA-Version, die nvidia-smi ausgibt, ist die neueste CUDA-Version, die der Treiber unterstützt, mit der später die Container-Images verglichen werden.

Wir installieren Betriebssystem, Treiber-Branch, CUDA und eine Container-Laufzeit auf Wunsch vor der Lieferung. Teilen Sie uns die Distribution mit und ob Secure Boot an bleibt, dann kommt der Server bei Schritt 7 dieser Liste an.

Persistence und Leistungslimits

Ohne Client deinitialisiert der Treiber eine ruhende GPU, was laut NVIDIA zu CUDA-Ladezeiten im Sekundenbereich führt und Einstellungen wie ein Software-Leistungslimit löscht. nvidia-persistenced kommt mit dem Treiber, NVIDIA sagt aber nicht zu, dass er standardmäßig startet; aktivieren Sie ihn also und prüfen Sie nach einem Neustart, dass er läuft.

Dann lesen Sie die Leistungsdaten mit nvidia-smi -q -d POWER. Jede Server-Edition-Karte sollte das Maximallimit melden, das ihr Kabel erlaubt, in der Konfiguration oben 600 W. Wenn Sie die Karten begrenzt betreiben, etwa mit 450 W passend zu den Zuleitungen, setzen Sie das Limit, nachdem der Persistence-Dienst läuft, und erneut nach jedem Neuladen des Treibers, denn ein mit nvidia-smi gesetztes Limit übersteht das nicht.

Docker, Container Toolkit und CDI

Die Modelle laufen in Containern, die nächste Schicht ist also das NVIDIA Container Toolkit. NVIDIAs Installationsanleitung, aktualisiert am 18. September 2026, installiert Version 1.20.1 aus dem Repository auf nvidia.github.io und richtet Docker mit nvidia-ctk runtime configure mit --runtime=docker ein, gefolgt von einem Neustart von Docker; für containerd und CRI-O schreibt derselbe Befehl eine Drop-in-Datei.

Podman nutzt CDI, das Container Device Interface, laut NVIDIA der empfohlene Weg zu den GPUs. Seit Toolkit 1.18.0 erzeugt ein systemd-Dienst, nvidia-cdi-refresh, die CDI-Spezifikation und aktualisiert sie nach Treiber- oder Toolkit-Upgrades und beim Booten. nvidia-ctk cdi list zeigt die Gerätenamen, nvidia.com/gpu=0 bis nvidia.com/gpu=3 auf diesem Server und dazu nvidia.com/gpu=all. NVIDIAs eigener erster Test führt nvidia-smi -L in einem schlichten Ubuntu-Image aus, mit --device nvidia.com/gpu=all unter Podman oder der nvidia-Laufzeit unter Docker. Erscheinen dort alle vier Karten, ist die Laufzeit fertig. Wie jeder Container seine eigene Karte bekommt, per Index, UUID oder MIG-Gerät, zeigt unser Leitfaden zur GPU-Zuweisung an Docker ohne Kubernetes.

Basislinie mit DCGM

DCGM 4.6 wird je CUDA-Hauptversion paketiert, als datacenter-gpu-manager-4-cuda13 für die Treiber R580 und R595, und läuft als Dienst nvidia-dcgm, gestartet mit systemctl --now enable nvidia-dcgm. dcgmi discovery -l sollte alle vier Karten auflisten. Speichern Sie drei Ausgaben als Basislinie des Servers: nvidia-smi -q -x, die GPU-Anordnung aus nvidia-smi topo -m und das JSON von dcgmi diag -r 3 -j.

Die Diagnose auf Stufe 3 dauert in der Größenordnung von 15 bis 30 Minuten und sollte auf jeder Karte bestehen; unser Leitfaden zum Abnahmetest erklärt, was jeder Test auf RTX-PRO-Karten abdeckt und wie man den Lauf unter Dauerlast verlängert. Dieselben Zähler, ECC-Fehler und XID-Meldungen, beobachtet von nun an auch die Überwachung.

MIG oder ganze Karten

Legen Sie das Layout fest, bevor die ersten Nutzer kommen, denn eine spätere Änderung bedeutet, die Workloads auf dieser Karte anzuhalten. Ganze Karten passen zu Modellen, die per Tensor-Parallelität über mehrere GPUs verteilt werden, da NCCL mit MIG nicht unterstützt wird. MIG teilt eine RTX PRO 6000 Server Edition in bis zu vier Instanzen 1g.24gb, zwei 2g.48gb oder eine 4g.96gb, jede mit eigenem Speicher, was zu mehreren kleinen Modellen oder Teams auf einem Server passt. Unsere MIG-Anleitung für RTX PRO Blackwell enthält die Befehle und die Voraussetzungen, darunter einen Treiber ab 575.51.03.

Zwei Punkte wirken auf die benachbarten Schritte. MIG-Instanzen überstehen auf Hopper und neueren GPUs keinen Neustart, ein Startdienst legt sie also wieder an. Und die CDI-Aktualisierung deckt MIG-Änderungen nicht ab: Starten Sie nach jeder Änderung nvidia-cdi-refresh.service neu, damit Container die neuen Geräte sehen.

Das erste Modell in vLLM

vLLMs Dokumentation nennt einen Befehl für das offizielle Image: docker run mit --runtime nvidia --gpus all, dem vom Host eingebundenen Hugging-Face-Cache, veröffentlichtem Port 8000, --ipc=host für gemeinsamen Speicher, dem Image vllm/vllm-openai und dem Modell als --model. Auf einem Server legen Sie das Image auf ein Release fest, am 25. Oktober 2026 vllm/vllm-openai:v0.32.0, statt latest. Um das erste Modell auf einer Karte zu halten, ersetzen Sie --gpus all durch den CDI-Namen, NVIDIA_VISIBLE_DEVICES=nvidia.com/gpu=0 als Umgebungsvariable mit der nvidia-Laufzeit.

Ein gutes erstes Modell ist gpt-oss-120b. Seine Hugging-Face-Karte nennt 117 Milliarden Parameter, davon 5,1 Milliarden aktiv, und die Lizenz Apache 2.0, und die 15 safetensors-Dateien auf der Files-Seite ergeben zusammen rund 65 GB oder 60,8 GiB. Nach unserer Nutzer-pro-Karte-Regel (0,9 × 95,6 GiB treibersichtbarer Speicher − 3 GiB Overhead − 60,8 GiB Gewichte) behält eine Karte 22,2 GiB für den KV-Cache, etwa 19 Gespräche mit 32K Tokens bei 16-Bit-Cache (je 1,125 GiB), die Zahl aus unserem Leitfaden zum Server mit vier Karten. Die anderen drei Karten bleiben frei für eine zweite Kopie, ein Tensor-Parallel-Paar oder andere Dienste.

Wenn der Container meldet, dass der Server läuft, sollte curl localhost:8000/v1/models das Modell auflisten. Bevor jemand anderes den Endpunkt nutzt, zählen zwei Fakten aus vLLMs Sicherheitsdokumentation: Der Server lauscht auf allen Schnittstellen, und --api-key schützt nur die Pfade unter /v1, /v2, /inference und /cohere, /metrics, /health und andere Routen antworten also ohne Schlüssel. Stellen Sie den Endpunkt hinter ein Gateway oder eine Firewall-Regel. Unser Leitfaden zu KV-Cache-Größe und Parallelität in vLLM hilft bei den Einstellungen nach dem ersten Test.

Nach dem ersten Modell

Zwei Aufgaben machen aus einem funktionierenden Server einen Dienst. Zuerst die Überwachung: DCGM-Metriken, XID-Meldungen und die Sensoren des BMC gehen in das System, das Sie schon betreiben, wie unser Leitfaden zur GPU-Überwachung mit Zabbix und Checkmk zeigt. Dann schreiben Sie auf, was Sie getan haben, denn der zweite Server sollte nur einen Bruchteil der Zeit brauchen: BIOS-Einstellungen, Treiber-Branch, Toolkit-Version und MIG-Layout sind genau die Variablen, die ein Ansible-Inventar enthält.

Was wir liefern

Wir bauen KI-Server auf Bestellung: einen Einstiegsserver mit zwei RTX PRO 6000 Server Edition, den Inferenzknoten mit vier aus dieser Anleitung 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. Die Inbetriebnahme vor Ort ist auf Wunsch möglich. Beschreiben Sie die geplanten Modelle und Nutzer, und unser Team antwortet innerhalb eines Werktages mit einer Konfiguration.

FAQ