GPU-Server für eine Universität oder ein Forschungslabor: Slurm, MIG und faire Aufteilung der Karten

Was ein GPU-Server für eine Universität oder ein Forschungslabor braucht

Ein GPU-Server an der Universität, den sich ein Forschungslabor oder ein Kurs teilt, braucht neben den Karten einen Scheduler, der Jobs einreiht und GPUs zuteilt, eine Partitionierung, damit kleine Jobs ohne eine ganze Karte laufen, und Quoten mit Fair-Share, damit keine Arbeitsgruppe die Maschine wochenlang besetzt. Auf Bare Metal ist Slurm der übliche Scheduler; er behandelt GPUs als generische Ressourcen (GRES) und rechnet sie je Nutzer und Konto ab. Auf einem Kubernetes-Cluster ergänzt Kueue den normalen Scheduler um Quoten und Warteschlangen. NVIDIAs Multi-Instance GPU (MIG) teilt eine H200 NVL in bis zu sieben Instanzen und eine RTX PRO 6000 in bis zu vier, jede mit eigenem Speicher. Training und Simulation mit doppelter Genauigkeit führen zur H200 NVL, Inferenz und Lehre zur RTX PRO 6000 Server Edition.

Forschung erzeugt Last in Schüben. Ein Doktorand führt zwei Tage lang ein Fine-Tuning aus und pausiert dann eine Woche, und ein Kurs öffnet in derselben Stunde dreißig Notebooks. Ohne Scheduler nimmt sich die Karten, wer sich zuerst anmeldet, und ein ungenutztes Notebook hält eine Karte mit 96 GB für sich allein.

Slurm und GPUs: GRES-Konfiguration, Job-Anforderungen und Accounting

Slurms GRES-Dokumentation (Version 26.05, Stand Oktober 2026) schreibt zu slurm.conf: „Sie müssen ausdrücklich angeben, welche GRES verwaltet werden sollen“. GresTypes=gpu benennt den Ressourcentyp, und jede Node-Zeile deklariert ihre Karten, zum Beispiel Gres=gpu:4. Die Gerätedateien und die CPU-Kerne nahe jeder Karte kommen in gres.conf, von Hand eingetragen oder über AutoDetect=nvml ausgefüllt, das in Slurms Worten die Angaben „für jede vom System erkannte GPU“ liefert. Die Anzahl in slurm.conf bleibt Pflicht, damit der Controller weiß, wie viele Karten er erwarten soll.

Nutzer fordern Karten mit --gpus oder mit --gres an, dessen Form aus Name, optionalem Typ und Anzahl besteht, wie im Beispiel --gres=gpu:kepler:2 der Dokumentation. Die Typnamen legt der Administrator fest; so kann ein Labor Nodes mit H200 NVL und mit RTX PRO 6000 in einem Cluster betreiben und Jobs die eine oder die andere Karte anfordern lassen.

Ist AccountingStorageTRES=gres/gpu gesetzt, erfasst Slurm außerdem GPU-Speicher und Auslastung je Job, als gres/gpumem und gres/gpuutil, für NVIDIA-GPUs, die über AutoDetect=nvml gefunden wurden. Die Dokumentation ergänzt, dass NVML keine Auslastungsmetriken für MIG-Instanzen unterstützt, Slurm für sie also weder gpumem noch gpuutil aufzeichnet. Den Zustand der Karten, Speicherfehler und XID-Ereignisse liefert NVIDIAs DCGM, das unser Leitfaden zum Monitoring von GPU-Servern behandelt.

MIG in Slurm: eine H200 NVL oder eine RTX PRO 6000 aufteilen

Slurm unterstützt MIG-Geräte seit Version 21.08. Sie werden mit AutoDetect=nvml erkannt und in slurm.conf wie gewöhnliche GPUs aufgeführt, mit einem optionalen Typ, der „ein Teilstring der Zeichenkette ‚MIG Profile‘ sein muss“, die der Node meldet; das Beispiel der Dokumentation verwendet a100_3g.20gb. Dieselbe Seite stellt fest: „Slurm erwartet, dass MIG-Geräte bereits partitioniert sind, und unterstützt keine dynamische MIG-Partitionierung.“ Das MIG-Layout ist daher eine Eigenschaft des Nodes. Wer es ändert, muss den Node per Drain leeren, die Instanzen neu anlegen und die Konfiguration anpassen; planen Sie Layoutwechsel deshalb wie jede andere Wartung. NVIDIAs MIG-Leitfaden stellt außerdem fest, dass „NCCL mit MIG derzeit nicht unterstützt wird“; eine Instanz führt also Jobs mit einer GPU aus, und Training über mehrere Karten braucht ganze Karten.

NVIDIAs MIG-Leitfaden beschreibt Instanzen mit „getrennten und isolierten Pfaden durch das gesamte Speichersystem“ und stellt fest, dass „MIG sicherstellt, dass ein Client die Arbeit oder das Scheduling anderer Clients nicht beeinträchtigen kann“. Stürzt das Notebook eines Studierenden ab, endet es für sich allein, und der Job eines Kollegen läuft weiter.

MIG-Benutzerhandbuch von NVIDIA (aktualisiert am 11. September 2026), das die H200 NVL mit 7 Instanzen führt und die Profile in einer Tabelle für die H200 141GB angibt; NVIDIAs H200-Seite nennt für die H200 NVL „bis zu 7 MIGs mit je 16,5 GB“. Produktseiten der H200 und der RTX PRO 6000 Server Edition, Workstation Edition und Max-Q, gelesen am 10. Oktober 2026; die FP64-Rate von 1/64 aus NVIDIAs Whitepaper zu RTX Blackwell PRO v1.1; die FP64-Werte der RTX PRO 6000 sind unsere Rechnung.

Auf der Workstation Edition und der Max-Q braucht MIG zuerst eine Umschaltung des Anzeigemodus, die unser MIG-Runbook für RTX PRO Blackwell beschreibt, zusammen mit einem zweiten Punkt, der für Slurm zählt. Auf Hopper und neueren GPUs sind der MIG-Modus und die Instanzen nach einem Neustart verschwunden. NVIDIA schlägt einen systemd-Dienst mit seinem MIG Partition Editor (nvidia-mig-parted) vor, der sie beim Start neu anlegt; auf einem Slurm-Node muss er vor slurmd laufen, da AutoDetect die Geräte ausliest, die der Node hat. Die L40S, L4, RTX PRO 4000 und RTX PRO 2000 stehen nicht in NVIDIAs MIG-Leitfaden; sie bedienen also ganze Jobs oder werden ohne Isolierung in Hardware geteilt.

Wir bauen GPU-Server auf Bestellung mit Karten H200 NVL oder RTX PRO 6000 Server Edition, auf Wunsch mit installierten Treibern und CUDA. Nennen Sie uns, wie viele Personen sich den Server teilen, und was darauf läuft.

Teilen ohne MIG: Shards in Slurm und MPS

Slurm bietet außerdem Shards, einen „generischen Mechanismus, mit dem GPUs von mehreren Jobs geteilt werden können“, konfiguriert als Anzahl je Node wie shard:64 neben den GPUs. Die Dokumentation stellt fest, dass Sharding „die auf der GPU laufenden Prozesse nicht abschottet“ und „am besten mit homogenen Workflows funktioniert“. Eine GPU wird entweder als gpu oder als Shards zugewiesen, nicht beides. Shards passen zu einem Kurs, in dem alle Studierenden dieselbe kleine Übung ausführen, sofern das Labor in Kauf nimmt, dass ein Job, der mehr als seinen Anteil an Speicher oder Rechenleistung nutzt, die anderen verlangsamen oder blockieren kann.

CUDA MPS ist die andere Option, und Slurms Dokumentation warnt, dass „NVIDIA MPS eine eingebaute Einschränkung beim Teilen von GPUs zwischen verschiedenen Nutzern hat“. Auf einem Server, auf dem alle Forschenden ein eigenes Konto haben, ist MIG die Methode, die Nutzer in Hardware voneinander trennt.

Fair-Share und GPU-Quoten in Slurm

Das Multifactor-Priority-Plugin von Slurm gewichtet neun Faktoren, darunter Alter, Fair-Share, Partition und QOS. Es definiert Fair-Share als „die Differenz zwischen dem Anteil an der Rechenressource, der zugesagt wurde, und der Menge an Ressourcen, die verbraucht wurde“, und seit Release 19.05 ist der Algorithmus Fair Tree der Standard. PriorityDecayHalfLife, standardmäßig 7 Tage, legt fest, wie schnell vergangene Nutzung an Gewicht verliert.

Für einen GPU-Server muss ein Standardwert geändert werden. „Standardmäßig ist die Rechenressource die von einer Maschine gelieferten Rechenzyklen in der Einheit allocated_cpus*seconds.“ Ein Job mit zwei CPU-Kernen und vier GPUs würde dann als klein zählen. Dieselbe Seite fährt fort: „Andere Ressourcen lassen sich berücksichtigen, indem man die Option TRESBillingWeights einer Partition konfiguriert.“ Erhalten GPUs in dieser Option ein Gewicht, rechnet Fair-Share die Karten ab, und das Priority-Flag MAX_TRES_GRES rechnet den größten der CPU- und Speicheranteile eines Nodes plus die GPUs ab.

Neben Fair-Share stehen harte Limits. Mit AccountingStorageEnforce=limits setzt Slurm Limits durch, die auf Assoziationen gesetzt sind, also auf den Cluster, ein Konto oder einen Nutzer. GrpTRES begrenzt die TRES, die eine Assoziation und ihre untergeordneten Assoziationen gleichzeitig nutzen, und das Beispiel der Dokumentation setzt mit sacctmgr gres/gpu=50 für einen Nutzer. In einer QOS begrenzt MaxTRESPerUser, was ein Nutzer belegt, MaxJobsPerUser die Jobs, die ein Nutzer gleichzeitig ausführt, und MaxWallDurationPerJob die Laufzeit jedes Jobs. Die Dokumentation warnt, dass ein typisiertes Limit wie gres/gpu:tesla=1 nicht durchgesetzt wird, wenn ein Job GPUs ohne Typ anfordert, eine „Designeinschränkung“, und schlägt ein Job-Submit-Plugin vor, das Anforderungen ohne Typ ablehnt.

Eine typische Einrichtung für einen Labor-Cluster läuft in dieser Reihenfolge ab:

1. Die MIG-Karten partitionieren, dann GPUs und MIG-Instanzen in slurm.conf und gres.conf mit AutoDetect=nvml deklarieren.
2. gres/gpu zu AccountingStorageTRES hinzufügen, damit die Accounting-Datenbank die GPU-Nutzung je Job aufzeichnet.
3. Ein Konto je Forschungsgruppe anlegen und darunter die Nutzer, mit den Anteilen, die jeder Forschungsgruppe zugesagt sind.
4. TRESBillingWeights auf den GPU-Partitionen setzen, damit Fair-Share Karten zählt und nicht nur Kerne.
5. AccountingStorageEnforce=limits setzen, eine GPU-Obergrenze je Arbeitsgruppe mit GrpTRES, eine Obergrenze je Nutzer und eine maximale Laufzeit in einer QOS.

Kubernetes im Labor: Kueue-Quoten und MIG-Ressourcen

Der NVIDIA GPU Operator und das Device-Plugin stellen ganze Karten oder MIG-Instanzen als Ressourcen bereit, und mit der Strategie mixed bekommt jedes MIG-Profil einen eigenen Ressourcennamen; unser Leitfaden zum GPU-Sharing in Kubernetes erklärt die Strategien. Wie dort vermerkt, haben wir mit Stand Oktober 2026 auf der Supportliste des GPU Operators keinen Eintrag für die RTX PRO 6000 Workstation oder Max-Q gefunden; planen Sie einen Kubernetes-Cluster deshalb mit Karten von der Liste, etwa der RTX PRO 6000 Server Edition und der H200 NVL.

Kueue, nach eigener Beschreibung „ein Kubernetes-natives System, das Quoten verwaltet und wie Jobs sie verbrauchen“, entscheidet, wann ein Job wartet, startet oder verdrängt wird, und „ersetzt keine bestehenden Kubernetes-Komponenten“. Jede Forschungsgruppe erhält eine ClusterQueue mit einer nominalQuota an GPUs. Queues in derselben Cohort „können sich gegenseitig ungenutzte Quoten leihen“, bis zu einem borrowingLimit, und ein lendingLimit hält einen Teil der eigenen Quote einer Queue zurück. Mit reclaimWithinCohort auf LowerPriority oder Any (Standard ist Never) kann ein wartender Job geliehene Arbeit in anderen Queues der Cohort verdrängen, die ihre nominale Quote überschreiten.

Batch-Jobs, MPI-Codes und Nutzer, die sbatch aus einem Rechenzentrum kennen, passen zu Slurm. Notebooks, Modelldienste und als Container gebaute Trainingspipelines passen zu Kubernetes mit Kueue.

Karten für Training, Inferenz, Lehre und FP64-Codes wählen

Die doppelte Genauigkeit trennt die beiden Hauptkarten. Die H200 NVL liefert 30 TFLOPS in FP64 und 60 auf ihren Tensor Cores. NVIDIAs Whitepaper zu RTX PRO Blackwell stellt fest, dass „die FP64-TFLOP-Rate 1/64 der TFLOP-Rate von FP32-Operationen beträgt“ und dass die FP64-Kerne vorhanden sind, „um sicherzustellen, dass alle Programme mit FP64-Code korrekt arbeiten“. Simulation, Quantenchemie und andere Codes, die in FP64 rechnen, gehören auf die H200 NVL; unser Vergleich von GPUs für CFD und Simulation behandelt Solver im Detail. Für maschinelles Lernen stellt unser Vergleich von H200 NVL und RTX PRO 6000 für das Fine-Tuning Speicher, Tensor-Raten und NVLink einander gegenüber.

Unsere Auswertung von NVIDIAs MIG-Leitfaden und der Produktseiten (Tabelle oben) sowie der Referenzkonfigurationen auf unserer Seite zu KI-Servern, gelesen am 10. Oktober 2026; die Kartenzahlen sind Beispiele, keine Auslegung.

Unsere Seite KI-Server nennt zwei Referenzkonfigurationen dieser Größenordnung: vier Karten RTX PRO 6000 Server Edition für Inferenz und acht Karten H200 NVL an NVLink-Bridges mit 400G-Netzwerk für Training. Ein institutsweiter Cluster kann beide unter einem Slurm-Controller betreiben, in getrennten Partitionen.

Beschreiben Sie Ihr Labor im Formular unten, mit seinen Teams, Workloads und den Jobs, die gleichzeitig laufen, und wir antworten innerhalb eines Werktages mit einer Konfiguration und einem Angebot.

Storage und Netzwerk für einen geteilten GPU-Server

Home-Verzeichnisse, Datensätze und Checkpoints sollten auf jedem Node dieselben Pfade haben, damit ein Job überall läuft, wo der Scheduler ihn platziert. Lokale NVMe-Laufwerke dienen während eines Laufs als Scratch-Speicher, dazu kommt ein getrennter Modellspeicher für das, was das Labor behält. Bei einem einzelnen Server tragen 25-GbE-Uplinks Anmeldungen und Datenkopien; mehrere Nodes, die gemeinsam ein Modell trainieren, brauchen ein Cluster-Fabric mit 200 oder 400G, das der Trainings-Node mit H200 NVL auf unserer Seite zu KI-Servern vorsieht.

Was wir liefern

Wir bauen KI-Server auf Bestellung für die gemeinsame Nutzung, mit der H200 NVL und NVLink-Bridges, der RTX PRO 6000 Server Edition, der L40S oder der L4, montiert und im Burn-in getestet, mit Herstellergarantie auf jede Komponente und mit einem EU-Vertrag und einer Rechnung. Einzelne Karten kommen aus unserem Sortiment an professionellen GPUs, darunter die RTX PRO 6000 als Workstation Edition und Max-Q für Rechner am Arbeitsplatz. Wir prüfen Rack, Strom und Luftstrom, bevor wir ein Angebot machen, und installieren auf Wunsch Betriebssystem, Treiber, CUDA und eine Container-Runtime. Wenn das Labor darauf eine Kubernetes-Plattform mit Kubeflow aufbauen und betreuen lassen will, ist das unser Service Private AI/ML, mit dem Engineering von unserem Engineering-Partner Vixen.UNO.

FAQ