News

Von Uwe David, Platform Architect, Cyberlink AG

Unter Last – Modelle, Engines und Multi-GPU-Inferenz auf RTX PRO 6000 Blackwell

Lokale KI klingt zunächst nach einer Hardwarefrage: genügend schnelle GPUs, ausreichend VRAM, ein grosses Sprachmodell installieren und loslegen. Auf dem Papier wirkt eine RTX PRO 6000 Blackwell Max-Q mit rund 96 GB VRAM dafür bereits ziemlich komfortabel. Mit mehreren dieser Karten scheint die Sache endgültig erledigt zu sein.

In der Praxis beginnt die interessante Arbeit genau dort.

Wir haben bei Cyberlink sieben aktuelle Sprachmodelle mit drei Inferenz-Engines auf NVIDIA RTX PRO 6000 Blackwell Max-Q getestet. Über unsere Partnerschaft mit cloudscale standen uns dafür zwei GPU-Flavors mit zwei beziehungsweise vier identischen GPUs zur Verfügung. Die Messreihen umfassen Single-GPU-Inferenz, Multi-GPU-Betrieb, lange Kontexte und Lasttests mit bis zu 256 parallelen Requests.

Uns interessierte dabei weniger ein weiterer synthetischer GPU-Benchmark als die Frage, was mit aktueller Hardware und aktuellen Modellen tatsächlich funktioniert und wo im praktischen Betrieb die Grenzen liegen.

Eine Erkenntnis zog sich durch fast alle Tests: Bei lokaler KI ist die GPU nur ein Teil des Systems. Modellarchitektur, Speicherbedarf und Inferenz-Software entscheiden mindestens genauso stark darüber, was am Ende tatsächlich funktioniert.

Auf einer einzelnen GPU erreichten drei Engines mit demselben Modell bei einem einzelnen Benutzer nahezu dieselbe Geschwindigkeit. Unter 32 parallelen Requests lag zwischen der schnellsten und langsamsten Konfiguration plötzlich fast Faktor sechs. Ein Modell mit 90.7 GiB Gewichten passte nominell in den Speicher einer Karte und konnte trotzdem nicht betrieben werden. Zwei GPUs liefen je nach Software entweder unter Volllast oder blieben unabhängig von der Zahl der Anfragen bei rund 45 Prozent Auslastung. Allein das Abschalten von Thinking erhöhte in einer Messreihe die Zahl vollständiger Antworten pro Sekunde um Faktor 3.5.

Die Hardware setzt den Rahmen. Wie viel davon nutzbar wird, entscheidet der Software-Stack.

Die Testumgebung

Getestet wurde auf zwei GPU-Flavors von cloudscale:

	GPU2-256-40-2-1600	GPU2-512-80-4-800
GPUs	2 × RTX PRO 6000 Blackwell Max-Q	4 × RTX PRO 6000 Blackwell Max-Q
VRAM je GPU	97'887 MiB	97'887 MiB
vCPU	40	80
System-RAM	251 GB	512 GB
GPU-Anbindung	PCIe Gen5 ×16	PCIe Gen5 ×16
Storage	1.6 TB Scratch + 193 GB System	800 GB Scratch + 200 GB System

Beide Flavors laufen virtualisiert, das heisst, die GPUs kommunizieren über PCIe. Auf dem Papier ist das eine komfortable Ausgangslage für lokale Inferenz: viel VRAM, aktuelle Blackwell-GPUs und ausreichend CPU- und Hauptspeicher für grosse Modelle. Die Tests zeigen allerdings schnell, warum sich die Leistungsfähigkeit eines solchen Systems nicht aus GPU-Anzahl und VRAM allein ableiten lässt.

Als Inferenz-Software kamen vLLM, SGLang und llama.cpp zum Einsatz. Treiberversionen, Builds, Quantisierungen, Startparameter und die vollständigen Messreihen sind im Repository dokumentiert. Für die Einordnung sind zunächst die Effekte interessanter als die einzelnen Kommandozeilenparameter.

Wenn ein 90-GB-Modell nicht auf eine 96-GB-GPU passt

VRAM ist bei lokaler Inferenz zunächst die offensichtlichste Grenze. Aber die Rechnung "Modell kleiner als VRAM = Modell läuft" funktioniert nicht.

GLM-5.3-Flash lieferte dafür ein gutes Beispiel: Eine von uns getestete NVFP4-Variante belegte rund 90.7 GiB pro Karte. Die RTX PRO 6000 stellt knapp 96 GiB bereit. Die Gewichte konnten geladen werden, für den Betrieb reichte der verbleibende Speicher trotzdem nicht. Neben den eigentlichen Modellgewichten benötigt die Inferenz-Engine weiteren Speicher. Ein wichtiger Bestandteil davon ist der KV-Cache, in dem Informationen aus dem bereits verarbeiteten Kontext gehalten werden. Eine andere Quantisierung desselben Modells belegte rund 73 GiB und lief.

Das gleiche Grundproblem zeigte sich bei langen Kontexten. Gemma-4-31B lief auf einer Karte mit 32'768 Token Kontext. Bei einer Verdopplung auf 65'536 Token wuchs allein der KV-Cache auf rund 38 GB und die Konfiguration passte nicht mehr.

Für die Kapazitätsplanung sind deshalb mindestens drei Grössen relevant: Modellgewichte, Runtime-Overhead und gewünschter Kontext.

Quantisierung ist mehr als Kompression

Modelle müssen nicht mit der ursprünglichen numerischen Genauigkeit ihrer Gewichte betrieben werden. FP8, NVFP4 oder verschiedene GGUF-Formate reduzieren den Speicherbedarf teilweise erheblich. Das klingt zunächst nach einer klassischen Abwägung zwischen Speicherbedarf und Qualität. Für lokale Inferenz hat Quantisierung aber noch eine zweite Bedeutung: Sie kann darüber entscheiden, ob eine bestimmte Hardwarekonfiguration überhaupt möglich ist.

In unseren Messungen reichte der Speicherbedarf der getesteten Modelle von unter 20 GiB bis deutlich über 100 GiB pro GPU. Qwen3.5-397B-A17B kam selbst als NVFP4 auf rund 117 GiB pro Karte. Damit war der Fall erledigt, bevor der erste Benchmark starten konnte. Andere Modelle mit mehr als 100 Milliarden Parametern liefen dagegen problemlos.

Die reine Parameterzahl eignet sich deshalb nur begrenzt zur Abschätzung der benötigten Hardware. Dafür gibt es noch einen zweiten Grund.

116 Milliarden Parameter müssen nicht 116 Milliarden Berechnungen bedeuten

Viele aktuelle grosse Modelle verwenden eine Mixture-of-Experts-Architektur, kurz MoE. Dabei existiert eine grosse Zahl spezialisierter Teilnetze, sogenannte Experten, von denen pro Token nur einige aktiviert werden. MiniMax-M2.5 besitzt beispielsweise 116 Milliarden Parameter und 256 Experten. Pro Token werden davon acht Experten verwendet. Die Gewichte des Modells müssen weiterhin irgendwo gespeichert werden, für die eigentliche Berechnung wird aber nur ein Teil des gesamten Modells aktiv.

Wie gross der Effekt sein kann, zeigte ein direkter Vergleich mit Gemma. Wir betrieben ein sparsames Gemma-Modell und eine dichte Variante ähnlicher Grössenordnung auf derselben GPU und mit derselben Engine. Das sparse Modell aktiviert rund 4 Milliarden Parameter pro Token, das dense Modell berechnet seinen vollständigen Parametersatz. Bei 32 parallelen Anfragen erreichte das sparse Modell 5.45 vollständige Antworten pro Sekunde, die dichte Variante 0.80 Antworten pro Sekunde. Das entspricht fast Faktor sieben auf derselben Hardware.

Die Modellgrösse allein sagt damit immer weniger über die tatsächlichen Rechenkosten aus.

Dieselbe GPU, dasselbe Modell, fast Faktor sechs Unterschied

Einer der aufschlussreichsten Tests benötigte überhaupt keinen Hardwarewechsel. Wir verwendeten dieselbe RTX PRO 6000, dasselbe Modell und dieselbe Last. Geändert wurde nur die Inferenz-Engine. Gemma-4-26B-A4B lief mit vLLM, SGLang und llama.cpp.

Bei einem einzelnen Request lagen die drei Engines noch relativ dicht zusammen:

Engine	Antworten/s	GPU-Auslastung
vLLM	3.08	98 %
llama.cpp	2.98	73 %
SGLang	2.67	93 %

Für einen einzelnen Benutzer wären alle drei Varianten schnell. Bei 32 parallelen Requests sieht das Bild deutlich anders aus:

Engine	Antworten/s	GPU-Auslastung
vLLM	31.88	100 %
SGLang	21.55	76 %
llama.cpp	5.45	38 %

Aus einem relativ kleinen Unterschied bei einem Benutzer wurde unter Last ein Unterschied von fast Faktor sechs. Auch bei der Latenz wird das sichtbar. Der Median für eine vollständige Antwort lag bei dieser Last bei 1.03 Sekunden mit vLLM, 1.56 Sekunden mit SGLang und 6.48 Sekunden mit llama.cpp.

Für den praktischen Betrieb ist genau dieses Verhalten entscheidend. Ein Entwickler, der das System alleine ausprobiert, könnte bei allen drei Engines zu dem Schluss kommen: schnell genug. Mit 30 oder 50 gleichzeitigen Benutzern sieht die Situation anders aus. Die Engine entscheidet nicht nur darüber, wie schnell ein einzelner Request verarbeitet wird, sondern auch darüber, wie gut viele Anfragen gebündelt und die vorhandene GPU beschäftigt werden.

Mehr GPUs bedeuten vor allem mehr Möglichkeiten und nicht automatisch mehr Leistung

Ein grosses Modell lässt sich über mehrere GPUs verteilen, aber zusätzliche Karten verdoppeln nicht automatisch den Durchsatz. Wie gut das funktioniert, hängt stark von Modellarchitektur und Inferenz-Engine ab.

Das zeigte sich besonders deutlich mit llama.cpp: Qwen3.8-Flash-Next verteilte sich zwar auf zwei RTX PRO 6000, beide GPUs blieben aber selbst bei steigender Last konstant bei rund 45 Prozent Auslastung. Mehr parallele Requests änderten daran praktisch nichts. MiniMax-M2.5 unter vLLM zeigte auf derselben Hardware das Gegenbeispiel und beschäftigte beide GPUs vollständig.

Zusätzliche GPUs bedeuten deshalb zunächst vor allem zusätzliche Kapazität. Modelle, die auf einer Karte nicht in den Speicher passen, können verteilt werden und deutlich grössere Kontextfenster werden möglich. Auf vier RTX PRO 6000 konnten wir beispielsweise ein grosses DeepSeek-Modell mit einem Kontext von 1'048'576 Token betreiben und in einem Needle-in-a-Haystack-Test Informationen bei 10, 50 und 90 Prozent des Kontextes erfolgreich wiederfinden. Der vollständige Million-Token-Prefill dauerte rund 471 Sekunden.

Genau darin liegt für uns die wichtigere Erkenntnis aus den Multi-GPU-Tests: Mehr GPUs erweitern zuerst den Lösungsraum. Ob daraus auch entsprechend mehr Geschwindigkeit entsteht, entscheidet der Software-Stack.

"Thinking" ist auch eine Kapazitätsfrage

Bei Reasoning-Modellen kommt ein weiterer Faktor hinzu. Ein Modell kann intern deutlich mehr Token erzeugen, als später als eigentliche Antwort sichtbar werden. Diese zusätzliche Arbeit kann bei komplexen Aufgaben sinnvoll sein, kostet aber Rechenzeit.

Auf der Vier-GPU-Konfiguration haben wir denselben Workload mit unterschiedlichen Thinking-Einstellungen gemessen. Mit deaktiviertem Thinking wurden 3.5-mal mehr vollständige Antworten pro Sekunde verarbeitet. Der wesentliche Grund dafür war, dass pro Antwort 8.75-mal weniger Token erzeugt wurden.

Für einen produktiven KI-Service ist das relevant. Nicht jede Aufgabe benötigt denselben Reasoning-Aufwand. Eine komplexe Analyse, Fehlersuche oder Planung kann davon profitieren, eine einfache Informationsabfrage möglicherweise nicht. Thinking ist deshalb nicht nur eine Modelleigenschaft, sondern auch eine Frage der verfügbaren Kapazität und der gewünschten Antwortzeit.

Die Software bewegt sich fast so schnell wie die Modelle

Ein weiterer Teil der Tests bestand aus Dingen, die gar nicht erst liefen. Das klingt wenig spektakulär, ist bei aktueller KI-Infrastruktur aber eine wichtige Erkenntnis.

Ein Modell passte in den Speicher, wurde von der Engine aber noch nicht unterstützt. Bei einem anderen war die Modellarchitektur grundsätzlich bekannt, ein benötigter GPU-Kernel für Blackwell fehlte jedoch. Eine weitere Konfiguration startete problemlos und scheiterte erst unter höherer Last.

Blackwell ist aktuelle Hardware. Gleichzeitig erscheinen neue Modellarchitekturen teilweise schneller, als die verschiedenen Inferenz-Engines sie vollständig unterstützen können. "Das Modell passt auf die GPU" bedeutet deshalb noch lange nicht "das Modell läuft mit dieser Engine auf dieser GPU".

Lokale Inferenz ist längst ein Multi-User-Thema

DeepSeek-V4-Flash-0731 erreichte auf zwei RTX PRO 6000 unter Last bis zu 32.58 vollständige Antworten pro Sekunde bei 256 parallelen Requests. Die Median-Latenz lag dabei bei knapp acht Sekunden. Hohe Parallelität erhöht also den Gesamtdurchsatz, nicht automatisch die Geschwindigkeit für den einzelnen Benutzer. Die Messung zeigt aber, dass lokale Inferenz längst über den einzelnen Entwickler mit einer GPU-Workstation hinausgeht und als echter Multi-User-Service betrieben werden kann.

Damit verschiebt sich auch die Planungsfrage. Statt nur zu fragen "Welche GPU brauchen wir?", geht es darum, welche Kombination aus Modell, Quantisierung, Kontext, Reasoning, Engine und Hardware zum tatsächlichen Workload passt.

Fazit

Die RTX PRO 6000 Blackwell Max-Q bietet auf dem Papier eine komfortable Basis für lokale KI. Unsere Tests bestätigen, dass damit auch sehr grosse Modelle, hohe Parallelität und Kontextfenster bis in den Bereich von einer Million Token technisch möglich sind.

Die spannendere Erkenntnis liegt aber eine Ebene darüber: Die GPU setzt die Obergrenze. Der Software-Stack entscheidet, wie nahe man ihr kommt. Modellarchitektur, Quantisierung, Kontext, Inferenz-Engine, Scheduler und Multi-GPU-Strategie können den praktischen Unterschied zwischen "passt nicht", "läuft" und "läuft wirklich gut" ausmachen.

Deshalb betrachten wir lokale KI inzwischen weniger als Beschaffungsthema und mehr als Plattformthema. Die Frage ist nicht nur, welche GPU ein Modell ausführen kann. Die interessantere Frage lautet: Welche Kombination aus Modell, Engine und Hardware liefert für den konkreten Anwendungsfall den sinnvollsten Service?

Genau dort beginnt für uns die eigentliche Arbeit.

Technische Details und Rohdaten

Wer tiefer einsteigen möchte, findet die vollständigen Konfigurationen, Engine-Versionen, Quantisierungen, Benchmark-Protokolle, Rohdaten, fehlgeschlagenen Versuche und untersuchten Hypothesen im Repository github.com/flash-ultra/ai-server-setup.