RTX PRO 4500 Blackwell: 3,4-facher LLM-Durchsatz durch Runtime-Optimierung

Die Wirtschaftlichkeit lokaler KI-Infrastruktur hängt nicht allein vom Anschaffungspreis einer GPU ab. Entscheidend ist, welcher produktive Durchsatz unter realer Last dauerhaft aus der vorhandenen Hardware erreicht werden kann. Gerade bei professionellen Blackwell-Karten gewinnt diese Kennzahl an Bedeutung: Steigen die Investitionskosten für die Hardware, steigt unmittelbar auch der Preis der verfügbaren Inferenzkapazität. OPAIRS hat deshalb nicht zuerst nach einer größeren GPU gesucht, sondern die bestehende Inferenzumgebung auf der RTX PRO 4500 Blackwell untersucht. Im Mittelpunkt standen die Scheduler-Konfiguration, die tatsächlich nutzbare Parallelität und die Frage, welches Modell auf dieser Hardware das beste Verhältnis aus Qualität, Performance und Verfügbarkeit erreicht.

Das Ergebnis der Tests: GPT-OSS-20B bleibt vorerst das Hauptmodell des OPAIRS-Stacks. Durch Änderungen an der Runtime- und Scheduler-Konfiguration konnte der gemessene Output-Durchsatz auf einer einzelnen RTX PRO 4500 Blackwell von rund 766 auf bis zu 2.637 Token/s erhöht werden. Das entspricht einer Steigerung um den Faktor 3,4, ohne die GPU oder das Produktionsmodell auszutauschen.

Qwen3.8-27B im Vergleich: höhere Modellgeneration, geringerer Durchsatz

Neuere Architektur bedeutet nicht automatisch höhere Produktionsleistung

Qwen3.8-27B-NVFP4 wurde als möglicher Nachfolger von GPT-OSS-20B auf derselben RTX PRO 4500 Blackwell evaluiert. Das Modell konnte stabil mit 32K Kontext betrieben werden. Unter paralleler Last zeigte sich jedoch ein deutlicher Unterschied: GPT-OSS-20B erreichte im Vergleich 766,47 Output-Token/s bei 6,97 Sekunden Mean TTFT und 12,78 ms Mean TPOT. Qwen3.8-27B erreichte 316,61 Output-Token/s bei 13,11 Sekunden Mean TTFT und 36,15 ms Mean TPOT. Qwen erreicht in diesem Testszenario damit rund 41 Prozent des Output-Durchsatzes von GPT-OSS-20B. Für die derzeitige Single-GPU-Konfiguration liefert GPT-OSS-20B deshalb weiterhin das bessere Verhältnis aus Performance und Verfügbarkeit.

Der erste Engpass lag nicht in der GPU, sondern im Scheduler

Die bisherige Produktionskonfiguration von GPT-OSS-20B verwendete --max-num-seqs 10. Diese Einstellung hatte einen stabilen Ausgangspunkt für den Betrieb geschaffen, begrenzte jedoch die mögliche Parallelisierung stärker als erforderlich. Bei steigender Request-Anzahl zeigte die Lastanalyse ein klares Muster: Die Time-to-First-Token nahm deutlich zu, während sich der Gesamtdurchsatz weiterhin im Bereich von etwa 760 bis 770 Token/s bewegte. Die vorhandene GPU-Kapazität wurde damit nicht durchgängig in zusätzlichen Output umgesetzt.

Von 10 auf 60 gleichzeitig verwaltete Sequenzen

OPAIRS hat max-num-seqs deshalb systematisch über unterschiedliche Request-, Prompt- und Outputprofile untersucht. Die neue Runtime-3-Konfiguration setzt --max-num-seqs 60. Der Parameter reserviert dabei nicht statisch Ressourcen für 60 Benutzer. Er definiert die maximale Anzahl gleichzeitig vom vLLM-Scheduler verwalteter Sequenzen. Die Änderung beseitigt den zuvor beobachteten Scheduler-Deckel und ermöglicht es, die vorhandene GPU unter paralleler Last wesentlich besser auszulasten.

Bis zu 60 parallele Sequenzen sind nicht gleichbedeutend mit 60 Benutzern

Clients, Tool Calls und Agenten teilen sich dieselbe Runtime

In einem industriellen KI-System ist die Zahl menschlicher Benutzer nur ein Teil der tatsächlichen Inferenzlast. Ein Benutzer kann über einen Agenten mehrere Tool Calls und weitere Modellaufrufe auslösen. Parallel dazu greifen APIs, Retrieval-Prozesse, Hintergrundjobs und automatisierte Workflows auf dieselbe Inferenzinstanz zu. Die relevante technische Kennzahl lautet deshalb nicht 60 User, sondern bis zu 60 gleichzeitig vom Scheduler verwaltete Inferenz-Sequenzen auf einer einzelnen GPU. Diese können aus Benutzerinteraktionen, API-Clients, Agenten, Tool Calls, RAG-Prozessen oder automatisierten Systemen entstehen.

Das Ergebnis: von 766 auf bis zu 2.637 Token/s

3,4-facher Output auf derselben RTX PRO 4500 Blackwell

Die Optimierung verändert weder die eingesetzte GPU noch das Hauptmodell. Sie verändert, wie die vorhandene Rechenkapazität unter paralleler Last genutzt wird. Mit GPT-OSS-20B auf der RTX PRO 4500 Blackwell steigt der gemessene Output von einer Baseline von rund 766 Token/s auf einen Peak von bis zu 2.637 Token/s. Entscheidend ist dabei nicht nur der Peak-Wert. Die Konfiguration wurde über kurze, mittlere, lange und sehr lange Lastprofile geprüft. In mehr als 15 Testreihen wurden keine fehlgeschlagenen Requests beobachtet. Erst nach diesen Lasttests wurde max-num-seqs 60 als neue Produktionskonfiguration übernommen.

Performance und Verfügbarkeit sind nur zwei Teile der Architektur

Für industrielle KI reicht hoher Durchsatz allein nicht aus. Neben Performance und Verfügbarkeit muss die fachliche Qualität stimmen. OPAIRS verfolgt dafür bewusst nicht den Ansatz, jede Aufgabe mit einem einzigen möglichst großen Modell zu lösen. GPT-OSS-20B bleibt das zentrale Hauptmodell für allgemeine Anfragen und übernimmt innerhalb der Plattform gleichzeitig die Orchestrierung. Erkennt die Plattform eine spezialisierte industrielle Aufgabenstellung, kann der entsprechende Workload gezielt an ein dafür feintrainiertes kleineres Modell auf einer anderen GPU übergeben werden.

GPT-OSS-20B als Hauptmodell, spezialisierte Modelle als Fachinstanzen

GPT-OSS-20B verarbeitet die zentrale Interaktion und entscheidet gemeinsam mit der OPAIRS-Plattform, wann zusätzliche Spezialisierung erforderlich ist. Für Aufgaben aus Bereichen wie Produktion, Maintenance oder SQL und ABAP stehen kleinere feintrainierte Modelle zur Verfügung. Diese laufen auf separaten GPUs. Dadurch wird nicht nur Fachwissen gezielt eingesetzt, sondern gleichzeitig die Last getrennt: Eine komplexe SQL-Abfrage oder eine industriespezifische Maintenance-Analyse muss nicht dauerhaft Rechenkapazität auf der GPU des Hauptmodells belegen. Nach der spezialisierten Verarbeitung fließt das Ergebnis wieder in den zentralen OPAIRS-Kontext zurück.

Training auf Leonardo, Inferenz auf der OPAIRS-Infrastruktur

Spezialisierung beginnt vor dem lokalen Deployment

Die spezialisierten Modelle entstehen im Rahmen des OPAIRS-Trainingsprogramms auf dem Leonardo BOOSTER in Bologna. Über EuroHPC stehen OPAIRS dafür 5.000 GPU-Stunden zur Verfügung. Die rechenintensive Trainings- und Evaluierungsphase wird damit von der späteren produktiven Inferenz getrennt. Nach dem Fine-Tuning werden die Modelle in die OPAIRS-Plattform integriert und lokal auf den jeweils vorgesehenen GPU-Ressourcen betrieben. Aktuelle interne Evaluierungen zeigen bereits messbare Qualitätsunterschiede zwischen spezialisierten Modellen und nicht auf die jeweilige Domäne trainierten Basismodellen. Die vollständigen Ergebnisse dieser Evaluierungen sowie die Multi-Model-Orchestrierung werden in einem eigenen Folgebeitrag vorgestellt.

Mehr zum Trainingsprogramm auf Leonardo: https://opairs-systems.com/insights/eurohpc-spezialisierte-ki-agenten-fertigung

Auch 2.637 Token/s sind möglicherweise noch nicht das Ende

Der nächste Optimierungsschritt: natives MXFP4 auf SM120

GPT-OSS-20B verwendet auf der RTX PRO Blackwell Architektur derzeit noch einen Marlin-Pfad für MXFP4. Die native Unterstützung der SM120-Workstation-GPUs ist in den beteiligten Open-Source-Inferenz-Frameworks weiterhin Gegenstand aktiver Entwicklung. OPAIRS untersucht deshalb aktuell, ob sich der heutige Marlin-Fallback durch einen stabilen nativen SM120-MXFP4-Pfad auf Basis der verfügbaren CUTLASS- und FlashInfer-Arbeiten ersetzen lässt. Veröffentlichte Vergleichsmessungen auf anderer SM120-Hardware zeigen je nach Lastprofil Verbesserungen gegenüber Marlin im Bereich von etwa 13 bis 28 Prozent. Für OPAIRS ergibt sich daraus eine technische Zielgröße von rund 20 Prozent zusätzlichem Potenzial. Dieser Wert ist ausdrücklich noch kein gemessener Benchmark auf der RTX PRO 4500 und wird vor einer Übernahme in die Produktionsruntime separat validiert.

Technische Referenzen zur SM120- und MXFP4-Unterstützung

• vLLM #31085 – Native NVFP4/MXFP4-Unterstützung und Backend-Auswahl für SM120: https://github.com/vllm-project/vllm/issues/31085
• vLLM #30135 – Marlin-Fallback auf RTX PRO Blackwell / SM120: https://github.com/vllm-project/vllm/issues/30135
• vLLM #33416 – SM120 Capability Checks im Quantisierungs- und Kernelpfad: https://github.com/vllm-project/vllm/issues/33416
• FlashInfer #2847 – MXFP4 MoE auf SM120 und Vergleichsmessungen gegenüber Marlin: https://github.com/flashinfer-ai/flashinfer/issues/2847
• NVIDIA CUTLASS #3096 – SM120 FP4/MXFP4 Kernel- und Performance-Untersuchungen: https://github.com/NVIDIA/cutlass/issues/3096

Fazit: Optimierung vor Hardware-Skalierung

Die Tests zeigen, dass bei lokaler LLM-Inferenz erhebliche Leistungsreserven außerhalb des eigentlichen Modells liegen können. Auf einer einzelnen RTX PRO 4500 Blackwell konnte OPAIRS den Output-Durchsatz von GPT-OSS-20B durch Runtime- und Scheduler-Optimierung von rund 766 auf bis zu 2.637 Token/s erhöhen. GPT-OSS-20B bleibt damit das Hauptmodell des Systems. Qwen3.8-27B wird weiter evaluiert, erreicht auf der getesteten Single-GPU-Konfiguration derzeit jedoch nicht das erforderliche Verhältnis aus Durchsatz und Latenz.

Für industriespezifische Aufgaben setzt OPAIRS parallel auf kleinere, auf Leonardo trainierte und für definierte Fachgebiete feinabgestimmte Modelle. GPT-OSS-20B bleibt dabei die zentrale Instanz für allgemeine Verarbeitung und Orchestrierung, während spezialisierte Workloads gezielt auf andere Modelle und GPU-Ressourcen ausgelagert werden. Damit werden Performance, Verfügbarkeit und fachliche Qualität nicht als Eigenschaften eines einzelnen Modells betrachtet, sondern als Ergebnis der gesamten Systemarchitektur.

Die Runtime-Arbeit ist gleichzeitig noch nicht abgeschlossen. Derzeit untersucht OPAIRS, ob sich der bestehende Marlin-Fallback durch einen stabilen nativen SM120-MXFP4-Pfad ersetzen lässt. Veröffentlichte Ergebnisse auf vergleichbarer SM120-Hardware deuten auf weiteres Performance-Potenzial hin. Die nächste Optimierungsstufe besteht damit nicht zwangsläufig aus einer größeren GPU oder einem größeren Modell, sondern aus der Kombination von Runtime-Optimierung, Lasttrennung, Modell-Spezialisierung und einer möglichst vollständigen Nutzung der vorhandenen Blackwell-Hardware.

Die Ergebnisse unserer aktuellen Evaluierungen der spezialisierten SQL-, Produktions- und Maintenance-Modelle sowie deren Zusammenspiel mit GPT-OSS-20B werden in einem Folgebeitrag veröffentlicht.

Für technische Zusammenarbeit, Benchmark-Ergebnisse oder gemeinsame Industrieprojekte: office@opairs-systems.com