Ada- und Blackwell-GPUs mischen: ein Treiberzweig, verschiedene GPUs in einem Server und in einem Cluster

Ada- und Blackwell-GPUs auf Ebene von Host und Treiber mischen

Ada- und Blackwell-GPUs lassen sich auf Ebene des Hosts und des Treibers mischen. NVIDIAs Rechenzentrumstreiber 580.178.04 und 595.91.07, beide am 3. August 2026 erschienen, führen die Karten RTX 6000, 5880, 5000, 4500 und 4000 Ada Generation, die L40S und die L4 neben der RTX PRO 6000 Blackwell in allen drei Editionen und der RTX PRO 5000, 4500, 4000 und 2000. Ein installierter Treiber betreibt also beide Generationen, in einem Server oder über eine ganze Flotte.

Mehrere Funktionen reichen nicht über beide Generationen. FP4-Tensor-Kerne gibt es nur auf den Blackwell-Karten und MIG nur auf den größeren davon, und nach unserer Lesart läuft ein Modell, das auf beide Generationen verteilt ist, im Tempo der langsameren Karte. Eine virtuelle Maschine mit vGPU migriert nur auf einen Host mit demselben GPU-Typ, und Container-Images brauchen Code für beide Architekturen.

Dieser Leitfaden richtet sich an ein Unternehmen, das 4 bis 8 Ada-Karten betreibt, etwa zwei Server mit je vier L40S, und nun Karten der RTX PRO Blackwell hinzunimmt. Das Muster, das wir für eine solche Flotte empfehlen, ist ein GPU-Modell je Host, beide Generationen als getrennte Pools in einem Cluster und eine Liste, welche Workloads auf Ada bleiben. Das Mischen der H200 NVL mit der RTX PRO 6000 behandelt unser Artikel zum Betrieb von H200 NVL und RTX PRO 6000 in einer Plattform, die Karten selbst unser Vergleich von RTX Ada und RTX PRO Blackwell Klasse für Klasse.

Ein NVIDIA-Treiber für Ada und Blackwell

Die Produktlisten von R580 und R595 enthalten die oben genannten Karten, mit zwei Ausnahmen unter den Karten, die wir liefern: Die RTX PRO 4500 Blackwell Server Edition erscheint nur in der Liste von R595, und die RTX PRO 5500 steht noch in keiner der beiden. NVIDIAs Seite zur Plattformunterstützung des GPU Operator (23. September 2026) nennt 595.91.07 als empfohlenen und Standardtreiber des Release 26.7.1. Sie führt die L40S und die L4 unter Ada und die RTX PRO 6000 und RTX PRO 4500 Blackwell Server Edition unter Blackwell. Die RTX 6000 Ada fanden wir auf dieser Seite nur in ihrer Liste der GPUs für vGPU mit KubeVirt.

Ein Host mit einer Blackwell-Karte braucht die offenen Kernelmodule. NVIDIA schrieb am 17. Juli 2024 zu Blackwell: „Sie müssen die Open-Source-GPU-Kernelmodule verwenden“, und empfahl dieselben Module für GPUs der Generationen Turing, Ampere, Ada Lovelace und Hopper. Ein Host, der für seine Ada-Karten die proprietäre Variante nutzte, wechselt mit der ersten Blackwell-Karte auf die offenen Module, und die Ada-Karten laufen ebenfalls darauf.

Lebenszyklen der Zweige, CUDA-Kompatibilität und das Festschreiben des Zweigs behandelt unser Leitfaden zu NVIDIA-Treiberzweigen und CUDA-Versionen.

Funktionen, die nicht beide Generationen abdecken

NVIDIAs Seiten zur L40S und zur RTX PRO 6000 Server Edition, Liste der CUDA-GPUs, Release Notes zu CUDA 11.8 und 12.8, MIG-Leitfaden, vGPU-GPU-Liste und Blog vom 17. Juli 2024, gelesen am 10. Oktober 2026; die Folgen sind unsere Lesart. Die RTX 6000 Ada hat dieselben 48 GB, PCIe Gen 4 und dieselbe Compute Capability, bei 300 W.

FP8 ist das Format, das beide Generationen teilen. NVIDIA nennt FP8-Tensor-Leistung für die L40S und die RTX PRO 6000 Server Edition sowie FP8-Tensor-Kerne für die RTX 6000 Ada. FP4-Tensor-Leistung erscheint nur auf der Blackwell-Seite; die Tabelle der L40S endet bei INT8 und INT4. NVFP4-Checkpoints gehören daher auf die Blackwell-Karten; FP8- und 16-Bit-Modelle laufen in beiden Pools, sofern sie hineinpassen.

NVIDIAs MIG-Leitfaden, aktualisiert am 11. September 2026, führt die RTX PRO 6000 mit bis zu vier Instanzen und die RTX PRO 5000 und 4500 mit zwei, aber keine GPU der Generation Ada Lovelace; die Seite der L40S gibt die MIG-Unterstützung mit „No“ an.

Container-Images brauchen die meiste Sorgfalt. Die Unterstützung für Ada kam mit CUDA 11.8, die Compiler-Unterstützung für SM_120, die Architektur der RTX PRO Blackwell, mit CUDA 12.8. NVIDIAs Kompatibilitätsleitfaden für Blackwell, aktualisiert am 13. September 2026, stellt fest, dass Binärdateien, die für ältere Architekturen „nur Cubins enthalten“, „neu gebaut werden müssen, um auf den Blackwell-GPUs zu laufen“, während Binärdateien mit PTX „unverändert funktionieren sollten“. Ein Image, das für den Ada-Pool nur mit Code für sm_89 gebaut wurde, scheitert auf den Blackwell-Karten. Images für beide Pools enthalten je Architektur einen Eintrag -gencode, zum Beispiel -gencode=arch=compute_120,code=sm_120 neben dem für sm_89.

Ein Modell über Ada- und Blackwell-Karten verteilen

Tensor-Parallelität teilt jede Schicht in gleiche Anteile, einen je Karte, und die Karten tauschen innerhalb jeder Schicht Teilergebnisse aus. Nach unserer Lesart wartet deshalb jeder Schritt auf die langsamste Karte, und jede Karte kann nur so viel Speicher nutzen, wie die kleinste hat. Zwei L40S und zwei RTX PRO 6000 Server Edition mit Tensor-Parallelität über vier Karten verhalten sich wie vier Karten mit 48 GB: 192 GB nutzbar von 288 GB installiert, bei der Speicherbandbreite der L40S und mit dem Verkehr zur L40S über PCIe Gen4.

In vLLMs Dokumentation zur Parallelität (6. Mai 2026) fanden wir keine Aussage zum Mischen von GPU-Modellen. Sie verlangt, dass „jeder Node eine identische Ausführungsumgebung bereitstellt, einschließlich Modellpfad und Python-Paketen“, und für GPUs, die „keine NVLINK-Verbindung haben (z. B. L40S)“, schlägt sie für den Durchsatz Pipeline-Parallelität statt Tensor-Parallelität vor. Das tragfähige Layout hält jedes Modell innerhalb eines Pools, skaliert durch weitere Kopien, und der Router vor den Inferenz-Engines wählt den Pool.

Verschiedene GPUs in einem Server

Der Treiber akzeptiert eine L40S und eine RTX PRO 6000 in einem Gehäuse, aber die Serverhersteller legen Stromkabel, Lüftersätze und Höchstzahlen je Kartenmodell fest. Unser Artikel zur Planung eines GPU-Servers für späteres Wachstum fand keine Regel von Dell oder Lenovo zum Mischen von Modellen und empfiehlt, mit dem Modell zu wachsen, mit dem ein Server gestartet ist.

CUDA zählt die Geräte standardmäßig „mit einer einfachen Heuristik von der schnellsten zur langsamsten“ auf, in einem gemischten Server kann Gerät 0 also die Blackwell-Karte sein, gleich in welchem Steckplatz sie sitzt. Mit CUDA_DEVICE_ORDER=PCI_BUS_ID nummeriert CUDA die Karten „aufsteigend nach PCI-Bus-ID“, und CUDA_VISIBLE_DEVICES bindet dann jeden Job an die Karte, die für ihn vorgesehen ist.

In Kubernetes meldet das Device-Plugin jede Karte als nvidia.com/gpu, und GPU Feature Discovery versieht den Node mit Labels, nicht jede einzelne Karte; seine Dokumentation beschreibt keinen Node mit zwei Modellen. Ein Pod, der auf einem gemischten Node eine GPU anfordert, kann jede der beiden Karten erhalten. NVIDIAs DRA-Treiber, der jedes Gerät für sich zuteilt, gibt an, dass seine Funktionen zur GPU-Zuteilung „noch nicht offiziell unterstützt werden“. Gemischte Karten passen zu einer Entwicklungs-Workstation, auf der jede Karte ihren eigenen Job ausführt; gemeinsam genutzte Produktionsserver behalten ein GPU-Modell je Host.

Ada- und Blackwell-Node-Pools in Kubernetes

1. Halten Sie ein GPU-Modell je Node, mit den Ada- und den Blackwell-Nodes als zwei Pools auf einer Treiberversion.
2. Lassen Sie GPU Feature Discovery jeden Node mit Labels versehen: nvidia.com/gpu.product mit dem Kartenmodell und nvidia.com/gpu.compute.major mit 8 auf Ada und 12 auf RTX PRO Blackwell; nvidia.com/gpu.compute.minor 9 trennt Ada von Ampere-Nodes, die noch im Cluster sind.
3. Geben Sie NVFP4-Modellen und Images, die nur für sm_120 gebaut sind, eine verpflichtende Node-Affinität auf Compute Major 12 und Images, die nur für sm_89 gebaut sind, eine Affinität auf die Ada-Labels.
4. Konfigurieren Sie MIG nur auf den Blackwell-Nodes; die Ada-Nodes behalten ganze Karten oder Time-Slicing.
5. Testen Sie jedes Image auf einem Node jedes Pools, bevor es in beiden laufen darf.

Ein Taint auf den Blackwell-Nodes hält allgemeine GPU-Arbeit von ihnen fern. Die eigenen Pods des GPU Operator brauchen dann die passende Toleration, sonst werden Treiber und Device-Plugin dort nicht eingeplant, wie unser Artikel zu H200 NVL und RTX PRO 6000 beschreibt. Die Sharing-Methoden behandelt unser Leitfaden zum GPU-Sharing in Kubernetes mit MIG, Time-Slicing und MPS.

vGPU-Hosts mit gemischten GPU-Typen

Ein vGPU-Release deckt beide Generationen ab. NVIDIAs Liste der unterstützten GPUs, aktualisiert am 2. Oktober 2026, nennt für jede Karte das erste Release, zum Beispiel 15.2 für die RTX 6000 Ada, 16.1 für die L40S und 19.0 für die RTX PRO 6000 Blackwell Server Edition. Hosts beider Art können denselben vGPU Manager des Release 19 oder 20 betreiben; die RTX PRO 4500 Blackwell Server Edition braucht Release 20.0 oder neuer, und die RTX PRO 6000 Workstation und Max-Q Edition stehen nicht auf der Liste.

Für jede physische GPU stellt das vGPU-Benutzerhandbuch (29. September 2026) fest: „Standardmäßig unterstützt eine GPU oder GPU-Instanz nur vGPUs mit derselben Framebuffer-Größe“, und Profile unterschiedlicher Größe setzen voraus, dass die GPU „in den Mixed-Size-Modus versetzt“ wird.

Verschiedene GPU-Typen in einem vGPU-Host sind für XenServer dokumentiert. NVIDIAs Benutzerhandbuch sagt, dass XenServer beim Start GPU-Gruppen anlegt, „um die verschiedenen Typen physischer GPUs auf der Plattform abzubilden“, jede davon „eine Sammlung physischer GPUs, alle vom selben Typ“, und sein Beispielhost trägt drei GPU-Modelle. Für die anderen Hypervisoren fanden wir keine solche Aussage.

Die VM-Migration bleibt innerhalb eines GPU-Typs. Für jeden Hypervisor führt das Handbuch die Bedingung „Die NVIDIA-GPUs auf beiden Hostmaschinen müssen vom selben Typ sein“, und seine allgemeinen Voraussetzungen ergänzen, dass die GPU-Topologien auf beiden Hosts identisch sein müssen. Ein virtueller Desktop auf einer L40S kann nur auf einen Host mit einer L40S wechseln, die Platz für sein Profil hat. Jeder GPU-Typ ist daher eine eigene Migrationsdomäne und braucht freie Kapazität für die VMs eines Hosts in Wartung. Zwei L40S-Hosts und zwei RTX-PRO-6000-Hosts bilden zwei Domänen mit je zwei Hosts, nicht eine mit vier.

Lizenzen für NVIDIA AI Enterprise und vGPU kommen auf dieselbe Rechnung wie die Hardware. Nennen Sie uns den Hypervisor und die vGPU-Profile, die heute auf Ihren Ada-Hosts laufen, und wir nehmen die Lizenzen, die die neuen Karten brauchen, in das Angebot auf.

Welche Workloads auf Ada bleiben, und Muster für den Mischbetrieb

Unsere Einschätzung, auf Grundlage von NVIDIAs vGPU-Benutzerhandbuch (29. September 2026), der Dokumentation zu GPU Feature Discovery und CUDA und der ersten Tabelle.

Die Ada-Karten behalten Arbeit, die je Kopie in 48 GB passt und weder FP4 noch MIG braucht: Embeddings und Reranker, Speech-to-Text, Chat-Modelle, deren FP8-Gewichte und Cache auf eine oder zwei Karten passen, Videoanalyse auf der L4 und virtuelle Desktops auf Hosts mit L40S oder RTX 6000 Ada. Die Blackwell-Karten übernehmen NVFP4-Checkpoints, Modelle, die 96 GB je Karte brauchen, und isolierte MIG-Instanzen.

Als Beispiel dienen zwei Server mit je vier L40S und ein neuer Server mit vier RTX PRO 6000 Server Edition. Die Ada-Server betreiben Embeddings, einen Reranker und Kopien eines FP8-Chat-Modells, sodass einer ausfallen kann, während der andere weiter bedient. Der Blackwell-Server betreibt ein größeres Modell über seine vier Karten, 384 GB insgesamt, das keinen zweiten Host hat, bis ein zweiter Blackwell-Server hinzukommt.

Wir liefern beide Generationen, als Karten für Server, die Sie bereits betreiben, oder in KI-Servern, die wir auf Bestellung bauen. Beschreiben Sie Ihre heutigen Ada-Server im Formular unten, mit den Workloads, die Sie verlagern wollen, und wir schicken Ihnen eine Konfiguration für die Blackwell-Seite.

Was wir liefern

Wir liefern die RTX 6000, 5880 und 5000 Ada, die L40S und die L4 sowie die RTX PRO 6000 in allen drei Editionen, die RTX PRO 5000 und die RTX PRO 4500 und 4500 Server Edition, als GPUs für die Server und Workstations, die Sie betreiben, oder in auf Bestellung gebauten KI-Servern. Alles kommt unter einem EU-Vertrag und auf einer Rechnung, mit Herstellergarantie. Bei Servern, die wir auf Bestellung bauen, installieren wir auf Wunsch Betriebssystem, Treiber, CUDA und eine Container-Runtime, in der Treiberversion, die Ihre Ada-Hosts nutzen. Rack, Strom und Luftstrom prüfen wir, bevor wir ein Angebot erstellen, und Konfiguration und Angebot schicken wir innerhalb eines Werktages.

FAQ