Supermicros JumpStart-Programm JumpStart verfolgt einen völlig anderen Ansatz bei der Hardware-Evaluierung. Anstelle einer kurzen, vorgegebenen Demo in einer gemeinsam genutzten Laborumgebung bietet JumpStart qualifizierten Kunden kostenlosen, zeitlich begrenzten Bare-Metal-Zugriff auf einen Katalog realer Produktionsserver. Von neuen X14-Plattformen mit Intel Xeon 6 bis hin zu H14-Systemen mit AMD EPYC der 5. Generation und großen HGX-GPU-Konfigurationen können Kunden Systeme reservieren, sich remote einloggen und ihre eigenen Workloads ausführen, als stünde die Hardware in ihrem eigenen Rack.
Der geschäftliche Nutzen wird deutlich, wenn schnelle und fundierte Plattformentscheidungen getroffen werden können. Ein realistischer Proof of Concept für KI oder High-Performance-Computing bedeutet üblicherweise, auf Evaluierungshardware zu warten, sich mit mehreren Anbietern abzustimmen und darauf zu hoffen, dass die Testkonfiguration der geplanten Einsatzumgebung ausreichend nahekommt. JumpStart beseitigt diese Hürden. Teams können die Leistung validieren, die Softwarekompatibilität prüfen, das Strom- und Wärmeverhalten untersuchen und Architekturen vergleichen, ohne interne Laborkapazitäten zu beanspruchen oder eine Palette Server quer durchs Land zu transportieren. Für die meisten Unternehmen genügt eine Woche konzentrierter Arbeit an der richtigen Konfiguration, um zu bestätigen, dass eine Plattform ihren Anforderungen entspricht oder sie auszuschließen, bevor eine endgültige Entscheidung getroffen wird.
Supermicro JumpStart Startseite
Was JumpStart so besonders macht, ist nicht nur die Anzahl der verfügbaren Systeme, sondern auch die Tiefe der Technologie, die Supermicro hier präsentiert. Zu den beliebten Optionen gehören X14-GPU-Server mit Intel Xeon 6- und NVIDIA-Beschleunigern, H14-Plattformen, optimiert für hohe CPU-Leistung mit AMD EPYC der 5. Generation, und speicherorientierte Systeme, die moderne CPUs mit NVMe-Backends kombinieren. Im High-End-Bereich bietet Supermicro bereits Zugriff auf Systeme der HGX B200- und B300-Klasse für KI-Training und -Inferenz. Mit JumpStart ermöglicht das Unternehmen zudem einen frühen, auf Geheimhaltung basierenden Einblick in Plattformen der nächsten Generation, die noch nicht flächendeckend verfügbar sind. Wir haben noch keinen anderen OEM gesehen, der so engagiert Infrastruktur vor der allgemeinen Markteinführung in ein strukturiertes, reproduzierbares Remote-Laborerlebnis verwandelt.
Die meisten Demo-Umgebungen von Anbietern beschränken sich auf geführte Lösungslabore oder eingeschränkte Produkt-Sandboxes. Diese sind zwar nützlich, um Management-Tools und Orchestrierungs-Workflows kennenzulernen, bieten aber selten Root-Zugriff auf einen High-End-Server oder die Freiheit, eine eigene Technologie zu installieren und zu betreiben. JumpStart hingegen verhält sich eher wie ein Leih-Rack in einem Remote-Rechenzentrum. Wenn Sie ein bestimmtes System buchen, erhalten Sie für die Dauer der Reservierung die volle Kontrolle per SSH, VNC und IPMI. Supermicro löscht und erstellt die Umgebung neu, bevor der nächste Kunde sie nutzt. In der Praxis fühlt sich das weniger wie eine Marketing-Demo an, sondern eher wie ein kurzes, fokussiertes Training in einem professionell geführten Remote-Labor.
Supermicro JumpStart X14 B200 System
Für diese Analyse gewährte Supermicro StorageReview Zugriff auf JumpStart genau so, wie es ein Kunde nutzen würde. Wir haben dafür Zeit eingeplant. X14 10U GPU-System Ausgestattet mit einem NVIDIA HGX B200 8-GPU-Mainboard und zwei Intel Xeon Platinum 6960P Prozessoren der 6. Generation, verfügte der Server über 3 TB DDR5-6400 ECC-Speicher, eine Kombination aus M.2- und U.2-NVMe-SSDs für den lokalen Speicher sowie acht B200-GPUs mit jeweils 180 GB HBM3e-Speicher. Eine Woche lang nutzten wir diese Plattform, um KI-Workloads und das Systemverhalten stichprobenartig zu testen. Dabei konzentrierten wir uns auf die Fragen, die potenzielle Käufer vor der Anschaffung einer neuen Infrastrukturgeneration beantwortet haben möchten.
Unsere Woche im Supermicro JumpStart-Programm
Sobald unser Reservierungsfenster geöffnet war, diente das JumpStart-Portal als zentrale Anlaufstelle für unsere Tests. Das unten abgebildete Dashboard zeigte den Reservierungszeitplan und bot alle notwendigen Informationen für den Einstieg, darunter SSH-Zugangsdaten für die Remote-Ubuntu-Umgebung und vollen IPMI-Zugriff. Da beide Schnittstellen sofort verfügbar waren, konnten wir innerhalb weniger Minuten mit der Systemvalidierung beginnen, anstatt auf die Bereitstellung oder Unterstützung warten zu müssen.
Der erste Schritt in unserem Arbeitsablauf bestand darin, die Betriebsbereitschaft der Hardware zu überprüfen. Mithilfe der Systemübersichtsseite im Portal (siehe Screenshot unten) stellten wir sicher, dass das Gehäuse eingeschaltet war, beide CPUs erkannt wurden, der Arbeitsspeicher vollständig bestückt war und der BMC einen positiven Systemstatus meldete. Diese Schnellprüfung ist mittlerweile Standard bei unseren Labortests, und die Fernzugriffsmöglichkeit über das Portal hat diesen Prozess deutlich vereinfacht.
Nach der Systemvalidierung gingen wir zur praktischen Arbeit über. Datei-Uploads für Testdaten wurden direkt über die JumpStart-Oberfläche abgewickelt, wodurch die übliche Hürde beim Bereitstellen von Datensätzen auf einer Remote-Plattform entfiel. Anschließend stellten wir per SSH eine Verbindung für die Workload-Bereitstellung her und nutzten die Remote-Konsole via IPMI, wenn wir Low-Level-Zugriff benötigten oder das Bootverhalten beobachten wollten.
Der Arbeitsablauf während der gesamten Woche ähnelte stark dem Betrieb der Geräte in unserem eigenen Labor. Wir konnten Workloads schnell starten, stoppen und iterativ bearbeiten, die Plattform bei Bedarf neu starten und das Hardwareverhalten überwachen, ohne den Supermicro-Support in Anspruch nehmen zu müssen. Die Kombination aus Betriebssystemzugriff und vollständiger Out-of-Band-Steuerung machte die Umgebung für kurze Testzyklen vorhersehbar und effizient.
Nach Ende der Reservierung wurde das System automatisch zurückgesetzt und die Nutzung ordnungsgemäß abgeschlossen. Dank dieser vorhersehbaren Struktur konnten wir uns auf das Testen anstatt auf die Logistik konzentrieren und das begrenzte Zugriffsfenster optimal nutzen.
GPUDirect-Speicherleistung
Einer der Tests, die wir auf der Supermicro X14-Plattform durchgeführt haben, war der Magnum IO GPUDirect Storage (GDS)-Test. GDS ist eine von NVIDIA entwickelte Funktion, die es GPUs ermöglicht, die CPU beim Zugriff auf Daten auf NVMe-Laufwerken oder anderen Hochgeschwindigkeitsspeichern zu umgehen. Anstatt Daten über die CPU und den Arbeitsspeicher zu leiten, ermöglicht GDS die direkte Kommunikation zwischen GPU und Speichermedium, wodurch die Latenz deutlich reduziert und der Datendurchsatz verbessert wird.
So funktioniert GPUDirect-Speicher
Traditionell müssen Daten, die auf einem NVMe-Laufwerk gespeichert sind, zunächst die CPU und den Arbeitsspeicher durchlaufen, bevor sie die GPU erreichen. Dieser Prozess führt zu Engpässen, da die CPU als Vermittler fungiert, was Latenzzeiten verursacht und wertvolle Systemressourcen verbraucht. GPUDirect Storage beseitigt diese Ineffizienz, indem es der GPU ermöglicht, über den PCIe-Bus direkt auf die Daten des Speichermediums zuzugreifen. Dieser direkte Pfad reduziert den Aufwand für die Datenübertragung und ermöglicht so schnellere und effizientere Datentransfers.
KI-Workloads, insbesondere solche mit Deep Learning, sind äußerst datenintensiv. Das Training großer neuronaler Netzwerke erfordert die Verarbeitung von Terabytes an Daten, und jede Verzögerung bei der Datenübertragung kann zu einer Unterauslastung der GPUs und längeren Trainingszeiten führen. GPUDirect Storage bewältigt diese Herausforderung, indem es sicherstellt, dass die Daten so schnell wie möglich an die GPU übermittelt werden, wodurch Leerlaufzeiten minimiert und die Recheneffizienz maximiert werden.
Darüber hinaus ist GDS besonders vorteilhaft für Workloads, die das Streamen großer Datensätze beinhalten, wie etwa Videoverarbeitung, Verarbeitung natürlicher Sprache oder Echtzeit-Inferenz. Durch die Reduzierung der Abhängigkeit von der CPU beschleunigt GDS die Datenbewegung und gibt CPU-Ressourcen für andere Aufgaben frei, was die Gesamtsystemleistung weiter verbessert.
Neben der reinen Bandbreite bietet GPUDirect mit NVMe-oF (TCP/RDMA) auch I/O mit extrem niedriger Latenz. Dadurch wird sichergestellt, dass den GPUs nie die Daten ausgehen, was das System ideal für KI-Inferenzen in Echtzeit, Analyse-Pipelines und Videowiedergabe macht.
GDSIO-Lesesequenzdurchsatz
Bei unseren sequenziellen Lesetests mit GDSIO auf der B200-Plattform begann die Arbeitslast mit einem einzelnen Thread und erreichte je nach Blockgröße etwa 14 bis 15 GiB/s. Sobald wir sowohl die Thread-Anzahl als auch die Blockgröße erhöhten, verbesserte sich die Leistung rapide. Mit 2 bzw. 4 Threads stieg der Durchsatz auf 20 bis 36 GiB/s, was die gute Skalierbarkeit des Systems bei der Einführung von Parallelverarbeitung verdeutlicht.
Die eigentliche Beschleunigung erfolgte ab acht oder mehr Threads, ab diesem Zeitpunkt pendelte sich die Verarbeitungsrate bei den meisten Workloads im Bereich von knapp über 30 GiB/s ein. Größere Blöcke profitierten am meisten, wobei Blöcke mit 5 MB und 10 MB über alle Thread-Anzahlen hinweg konstant hohe Werte lieferten.
Der Durchsatz erreichte schließlich bei einer Blockgröße von 10M und 256 Threads ein Maximum von etwa 43 GiB/s. Dies stellt die höchste anhaltende sequentielle Lesegeschwindigkeit dar, die wir in diesem Test beobachtet haben.
GDSIO-Lesesequenzlatenz
Hinsichtlich der Latenz reagierte die Arbeitslast zunächst sehr schnell, wobei Lesezugriffe einzelner Threads bei kleineren Blöcken im Bereich von 0.06–0.1 ms lagen. Mit zunehmender Anzahl an Threads skalierte die Latenz allmählich und blieb bis zum 8-Thread-Wert für die meisten Arbeitslasten unter 1 ms.
Ab 16 Threads stiegen die Latenzzeiten bei größeren Blockgrößen in den Millisekundenbereich, da der Speicherpfad zunehmend ausgelastet war. Die höchste Latenz trat am Ende des Tests auf: Bei einer Blockgröße von 10 MB und 256 Threads erreichte die Latenzzeit knapp über 1.2 Sekunden (rund 1200 ms). Dies spiegelte eine maximale Systemlast wider.
GDSIO-Schreibsequenzdurchsatz
Bei sequenziellen Schreibvorgängen war die Leistung im Vergleich zu Lesevorgängen deutlich konstanter. Die Arbeitslast stabilisierte sich schnell, wobei die meisten Thread- und Blockgrößenkombinationen Werte um 6.3–6.5 GiB/s erreichten. Dies deutet darauf hin, dass der Schreibpfad frühzeitig an eine konstante Obergrenze stößt, die wahrscheinlich eher mit Speichermedien und Pufferung als mit GPU- oder PCIe-Beschränkungen zusammenhängt.
Die Erhöhung der Threadanzahl hatte keine signifikanten Auswirkungen, da der Durchsatz von 2 bis 128 Threads im Wesentlichen unverändert blieb. Das einzige herausragende Ergebnis zeigte sich am Ende: Bei einer Blockgröße von 10 MB und 256 Threads erreichte der Durchsatz kurzzeitig 18.2 GiB/s. Dies verdeutlicht einen kurzfristigen Vorteil, wenn das System tiefe Warteschlangen und Schreibaggregation voll ausnutzen kann.
GDSIO-Schreib-Sequenzlatenz
Die Schreiblatenz war anfangs relativ niedrig; bei Single-Thread-Workloads lag sie bei kleineren Blockgrößen bei etwa 0.15–0.5 ms. Mit zunehmender Thread-Anzahl stieg die Latenz jedoch deutlich stärker an als bei den Lesevorgängen und erreichte bei vier Threads den Bereich von 1–4 ms und bei acht Threads 4–9 ms.
Ab 32 Threads mit größeren Blockgrößen stieg die Latenz sprunghaft an, wobei 5-MB- und 10-MB-Blöcke Werte zwischen 170 und 350 ms erreichten. Der Extremfall war die 10-MB-Blockgröße bei 256 Threads, die einen Spitzenwert von knapp 3 Sekunden (ca. 2900 ms) erreichte. Dies verdeutlicht, wie schnell der Schreibpfad unter hoher paralleler Last an seine Grenzen stößt.
GDSIO-Zufallslesedurchsatz
Bei zufälligen Lesezugriffen stieg die Arbeitslast schnell an. Die Leistung eines einzelnen Threads lag je nach Blockgröße zwischen etwa 11 und 31 GiB/s, wobei größere Blöcke sofort von der höheren Bandbreite profitierten. Mit zwei bzw. vier Threads erreichte der Durchsatz 20–36 GiB/s und zeigte damit frühzeitig eine starke Skalierung.
Ab 8 Threads pendelte sich das System in einem stabilen Bereich von knapp über 30 GiB/s ein, ähnlich wie im sequenziellen Lesetest. Das beste Ergebnis wurde mit einer Blockgröße von 10 MB und 256 Threads erzielt und erreichte einen Spitzenwert von etwa 42.7 GiB/s.
GDSIO-Latenz beim zufälligen Lesen
Die Latenz beim zufälligen Lesen war anfangs sehr gering und lag bei kleineren Blockgrößen im Bereich von 0.15–0.4 ms für Single-Thread-Workloads. Mit zunehmender Anzahl an Threads stieg die Latenz allmählich an, blieb bis zum vierten Thread unter 1 ms und erreichte bei acht Threads etwa 1–3 ms.
Mit 32 Threads und größeren Blöcken stieg die Latenz deutlich an, wobei 5- und 10-Mbit/s-Transfers Latenzen im Bereich von 30–55 ms erreichten. Der Extremfall trat bei 256 Threads und einer Blockgröße von 10 MB auf, wo die Latenz einen Spitzenwert von etwas über 1.1 Sekunden (rund 1180 ms) erreichte.
GDSIO-Zufallsschreibdurchsatz
Die Leistung bei zufälligen Schreibvorgängen war durchweg sehr konstant, wobei die meisten Blockgrößen und Threadanzahlen bei etwa 5.8–6.1 GiB/s lagen. Die Arbeitslast erreichte dieses Niveau nahezu sofort und zeigte nur eine minimale Skalierung bei Hinzunahme weiterer Threads, was darauf hindeutet, dass der Schreibpfad frühzeitig an seine Grenzen stößt.
Der einzige nennenswerte Ausreißer trat am Ende des Tests auf, wo die Blockgröße von 10M bei 256 Threads kurzzeitig auf 12.5GiB/s anstieg, was wahrscheinlich auf eine tiefe Warteschlangenbildung und Schreibaggregation unter hoher paralleler Last zurückzuführen ist.
GDSIO-Latenz beim zufälligen Schreiben
Die Latenz beim zufälligen Schreiben war anfangs relativ gering und lag bei kleineren Blockgrößen zwischen 0.6 und 1.2 ms und bei den größten Übertragungen zwischen 5 und 12 ms. Mit zunehmender Anzahl paralleler Threads stieg die Latenz jedoch schnell an und erreichte bei acht Threads 4 bis 9 ms und bei 32 Threads 18 bis 38 ms.
Ab diesem Punkt war der Schreibpfad ausgelastet. Bei größeren Blockgrößen stiegen die Latenzzeiten bei 64 Threads auf 150–380 ms, und eine weitere Skalierung erhöhte sie rapide. Der ungünstigste Fall war eine Blockgröße von 10 MB bei 256 Threads mit einer Latenz von maximal etwa 4.4 Sekunden.
vLLM Online-Bereitstellung – LLM-Inferenzleistung
vLLM ist die beliebteste Engine für Inferenz und Serverbereitstellung mit hohem Durchsatz für LLMs. Der vLLM Online-Serving-Benchmark ist ein Tool zur Leistungsbewertung, das die realen Serverleistungsfähigkeiten dieser Inferenz-Engine unter gleichzeitigen Anfragen misst. Er simuliert Produktionslasten, indem er Anfragen mit konfigurierbaren Parametern wie Anfragerate, Eingabe-/Ausgabelängen und Anzahl gleichzeitiger Clients an einen laufenden vLLM-Server sendet. Der Benchmark misst wichtige Kennzahlen wie Durchsatz (Tokens pro Sekunde), Zeit bis zum ersten Token und Zeit pro Ausgabetoken (TPOT) und hilft Benutzern so, die Leistung von vLLM unter verschiedenen Lastbedingungen zu verstehen.
Wir haben die Inferenzleistung anhand einer umfassenden Reihe von Modellen getestet, die verschiedene Architekturen, Parameterskalen und Quantisierungsstrategien umfassen, um den Durchsatz unter verschiedenen Parallelitätsprofilen zu bewerten.
Leistung des dichten Modells
Dichte Modelle folgen der konventionellen LLM-Architektur, bei der alle Parameter und Aktivierungen während der Inferenz einbezogen werden, was zu einem höheren Rechenaufwand als bei ihren spärlichen Pendants führt. Um die Leistungsmerkmale über verschiedene Modellgrößen und Quantisierungsstrategien hinweg umfassend zu bewerten, haben wir mehrere Konfigurationen dichter Modelle aus der Llama 3.1 8B-Familie verglichen.
Unsere Testsuite umfasste Meta Llama 3.1 8B-Evaluierungen in drei Präzisionsformaten: der Standardkonfiguration sowie FP8- und FP4-quantisierten Versionen im NVFP4-Format von NVIDIA. Wichtig ist, dass vLLM aktuell den Marlin-Kernel für NVFP4-quantisierte Modelle verwendet und die vollen Leistungsvorteile dieses Quantisierungsformats in diesen Benchmarks noch nicht zum Tragen kommen. Zukünftige vLLM-Optimierungen, die auf native NVFP4-Tensor-Kernoperationen abzielen, könnten weitere Leistungsverbesserungen erzielen. Diese Modellauswahlstrategie ermöglicht einen direkten Leistungsvergleich und isoliert gleichzeitig den Einfluss der progressiven Quantisierung auf den Inferenzdurchsatz.
Llama 3.1 8B Leistung
Das Llama 3.1 8B-Modell mit Standardgenauigkeit zeigt bei verschiedenen Parallelitätsstufen folgende Skalierungseigenschaften: Bei Einzelbenutzer-Parallelität (BS=1) erreicht das Modell 279.27 tok/s pro Benutzer, einen Gesamtdurchsatz von 1,727.62 tok/s und eine TPOT von 3.37 ms. Mit zunehmender Batchgröße sinkt der Durchsatz pro Benutzer, während der Gesamtdurchsatz steigt. Bei BS=8 erzielt das Modell 82.85 tok/s pro Benutzer, einen Gesamtdurchsatz von 3,386.48 tok/s und eine TPOT von 3.28 ms. Die Leistung skaliert weiter bis BS=32 (56.46 tok/s pro Benutzer, 8,274.66 tok/s insgesamt) und BS=64 (52.70 tok/s pro Benutzer, 13,707.66 tok/s insgesamt).
Das Modell erreicht seinen maximalen Gesamtdurchsatz bei BS=256 mit 32,797.67 Tok/s, was 30.64 Tok/s pro Benutzer und einer TPOT von 16.13 ms entspricht. Dies bedeutet eine 19-fache Steigerung des Gesamtdurchsatzes im Vergleich zur Einzelbenutzerleistung. Die TPOT-Werte bleiben bis BS=64 im Bereich von 3–4 ms und steigen bei BS=256 auf 16.13 ms an.
Llama 3.1 8B FP8 Leistung
Die FP8-quantisierte Variante weist unterschiedliche Eigenschaften auf. Bei BS=1 erreicht sie 149.46 Tok/s pro Benutzer, mit einem Gesamtdurchsatz von 9,565.20 Tok/s und einer TPOT von 3.44 ms. Die Pareto-Front-Analyse zeigt drei optimale Punkte (BS=1, BS=128, BS=256).
Bei BS=128 liefert das Modell 44.12 tok/s pro Benutzer mit insgesamt 19,198.40 tok/s und 11.04 ms.
TPOT. Der maximale Gesamtdurchsatz wird bei BS=256 mit 29,219.67 tok/s insgesamt, 30.13 tok/s pro Benutzer und 13.26 ms TPOT erreicht. Die FP8-Variante erzielt einen geringeren maximalen Gesamtdurchsatz als die Standardpräzision (29.2K vs. 32.8K tok/s).
Llama 3.1 8B FP4 Leistung
Die quantisierte FP4-Konfiguration liefert folgende Ergebnisse: Bei Einzelbenutzer-Gleichzeitigkeit (BS=1) werden 279.73 tok/s pro Benutzer, ein Gesamtdurchsatz von 830.46 tok/s und eine TPOT von 3.43 ms erreicht.
Das FP4-Modell zeigt sieben Pareto-Frontpunkte. Bei BS=2 erreicht es 159.95 tok/s pro Benutzer, insgesamt 928.60 tok/s und eine TPOT von 3.43 ms. Die Leistung skaliert weiter bis BS=4 (76.36 tok/s pro Benutzer, insgesamt 1,631.69 tok/s) und BS=32 (76.09 tok/s pro Benutzer, insgesamt 9,014.29 tok/s). Das Modell erreicht seinen maximalen Gesamtdurchsatz bei BS=256 mit 29,340.89 tok/s, 30.13 tok/s pro Benutzer und einer TPOT von 16.18 ms.
Leistung des Sparse-Modells
Sparse Modelle, insbesondere Mixture-of-Experts-Architekturen (MoE), stellen einen vielversprechenden Ansatz zur effizienten Skalierung von Sprachmodellen dar. Diese Architekturen behalten eine hohe Gesamtparameteranzahl bei, indem sie pro Token nur eine Teilmenge der Parameter aktivieren, was potenziell eine verbesserte Leistung pro aktivem Parameter ermöglicht.
Wir evaluierten zwei MoE-Architekturen: DeepSeek-R1, ein auf logisches Denken fokussiertes Modell, und Qwen3 Coder 30B-A3B, eine auf Codegenerierung spezialisierte Sparse-Architektur. DeepSeek-R1 ist das populärste auf logisches Denken fokussierte Modell und weist im Vergleich zu traditionellen Sprachmodellen deutliche Leistungseigenschaften auf. Das Qwen3 Coder-Modell verwendet 30 Milliarden Parameter, aktiviert aber nur 3 Milliarden Parameter pro generiertem Token. Wir führten Benchmarks für Qwen3 Coder sowohl in der Standard- als auch in der FP8-quantisierten Variante durch, um die Leistungseigenschaften verschiedener Quantisierungsstrategien zu untersuchen.
DeepSeek-R1-Leistung
Das DeepSeek-R1-Modell zeigt ein interessantes Skalierungsverhalten bei unterschiedlichen Batchgrößen. Bei Einzelbenutzer-Konkurrenz (BS=1) erreicht das Modell 30.24 tok/s pro Benutzer, einen Gesamtdurchsatz von 88.13 tok/s und eine TPOT von 29.85 ms. Bei Skalierung auf BS=4 erreicht das Modell 29.77 tok/s pro Benutzer bei einem Gesamtdurchsatz von 266.40 tok/s und einer TPOT von 32.04 ms. Dies stellt den maximalen Gesamtdurchsatz aller Konfigurationen dar.
Die Leistung von DeepSeek-R1 stagniert ab einer Batchgröße von 4 (BS=4). Bei BS=8 fällt der Durchsatz pro Benutzer rapide auf 14.98 kT/s, und der Rückgang setzt sich bei höheren Batchgrößen fort, bis er bei BS=256 nur noch 0.46 kT/s pro Benutzer beträgt. Der Gesamtdurchsatz bleibt zwischen 200 und 260 kT/s im Bereich von BS=4 bis BS=256 relativ stabil, da das Modell auf einem einzelnen Knoten nicht mit zusätzlichen gleichzeitigen Anfragen skalieren kann, was zu erhöhter Latenz ohne nennenswerte Durchsatzsteigerungen führt. Wichtig ist hierbei anzumerken, dass der B200 DGX eine der wenigen Einzelserverlösungen ist, die dieses umfangreiche Modell ausführen kann.
Qwen3 Coder 30B-A3B Leistung
Der Qwen3-Coder mit Standardgenauigkeit zeigt folgendes Skalierungsverhalten in Abhängigkeit von der Parallelitätsstufe. Bei Einzelbenutzer-Parallelität (BS=1) erreicht das Modell 178.30 tok/s pro Benutzer, einen Gesamtdurchsatz von 527.25 tok/s und eine TPOT von 5.46 ms. Bei BS=2 liegt die Leistung bei 174.56 tok/s pro Benutzer mit einem Gesamtdurchsatz von 718.70 tok/s und einer TPOT von 5.60 ms. Mit zunehmender Batchgröße sinkt der Durchsatz pro Benutzer, während der Gesamtdurchsatz weiter steigt: Bei BS=16 werden 127.76 tok/s pro Benutzer, ein Gesamtdurchsatz von 4,204.40 tok/s und eine TPOT von 6.93 ms erreicht.
Das Modell erreicht seinen maximalen Gesamtdurchsatz bei BS=256 mit 22,305.88 tok/s, 46.16 tok/s pro Benutzer und einer TPOT von 17.64 ms. Die Pareto-Front umfasst acht verschiedene Punkte, darunter einen doppelten Eintrag bei BS=32 (72.97 tok/s und 93.50 tok/s pro Benutzer, der wahrscheinlich unterschiedliche Konfigurationen repräsentiert). Die TPOT-Werte bleiben bis BS=64 im Bereich von 5–9 ms.
Qwen3 Coder 30B-A3B FP8 Performance
Die quantisierte FP8-Variante weist folgende Leistungsmerkmale auf: Bei Einzelbenutzer-Konkurrenz (BS=1) erreicht sie 107.46 tok/s pro Benutzer, einen Gesamtdurchsatz von 317.75 tok/s und eine TPOT von 9.16 ms. Bei BS=2 erzielt das Modell 99.55 tok/s pro Benutzer, einen Gesamtdurchsatz von 409.87 tok/s und eine TPOT von 9.86 ms.
Skalierung auf höhere Batchgrößen: BS=8 liefert 54.60 tok/s pro Benutzer mit insgesamt 1,383.13 tok/s und einer TPOT von 10.24 ms, während BS=32 48.78 tok/s pro Benutzer mit insgesamt 3,874.21 tok/s und einer TPOT von 10.67 ms erreicht. Der maximale Gesamtdurchsatz wird bei BS=256 mit insgesamt 19,114.86 tok/s, 36.38 tok/s pro Benutzer und einer TPOT von 20.00 ms erzielt. Dies entspricht etwa 86 % des maximalen Durchsatzes bei Standardpräzision.
Mikroskalierung der Datentyp-Performance
Mikroskalierung ist ein fortschrittlicher Quantisierungsansatz, der feinkörnige Skalierungsfaktoren auf kleine Gewichtungsblöcke anwendet, anstatt große Parametergruppen gleichmäßig zu quantisieren. NVIDIAs NVFP4-Format implementiert diese Technik durch eine blockierte Gleitkommadarstellung, bei der jeder Mikroskalenblock mit 8–32 Werten einen gemeinsamen Exponenten als Skalierungsfaktor hat. Dieser granulare Ansatz bewahrt die numerische Präzision bei gleichzeitiger 4-Bit-Darstellung und erhält so den für Transformer-Architekturen wichtigen Dynamikbereich. Das Format ist in NVIDIAs Tensor Core-Architektur integriert und ermöglicht effiziente Berechnungen mit gemischter Genauigkeit und sofortiger Dekomprimierung bei Matrixoperationen.
Wir evaluierten die GPT-OSS-Modelle von OpenAI anhand zweier Parameterskalen unter Verwendung der NVFP4-Quantisierung: der 20-Byte-Variante und der größeren 120-Byte-Variante. Diese Benchmarks demonstrieren die Leistungsfähigkeit der Mikroskalierungsquantisierung bei unterschiedlichen Modellgrößen.
GPT-OSS-20B Leistung
Das 20B-Parametermodell erzielt über verschiedene Batchgrößen hinweg die folgende Leistung: Bei Einzelbenutzer-Parallelität (BS=1) erreicht es 299.28 tok/s pro Benutzer, einen Gesamtdurchsatz von 943.43 tok/s und eine TPOT von 3.23 ms. Bei BS=2 beträgt der Durchsatz weiterhin 299.19 tok/s pro Benutzer, der Gesamtdurchsatz 1,356.87 tok/s und die TPOT ebenfalls 3.19 ms.
Skalierung auf höhere Batchgrößen: BS=8 erreicht 259.02 tok/s pro Benutzer mit insgesamt 5,149.59 tok/s und einer TPOT von 3.42 ms, während BS=16 200.69 tok/s pro Benutzer mit insgesamt 7,765.73 tok/s und einer TPOT von 3.77 ms liefert. Das Modell skaliert weiter über BS=32 (168.34 tok/s pro Benutzer, insgesamt 12,411.72 tok/s) und BS=64 (123.96 tok/s pro Benutzer, insgesamt 16,931.47 tok/s).
Der Gesamtdurchsatz wird bei BS=256 erreicht und beträgt insgesamt 38,258.50 tok/s, was 65.08 tok/s pro Benutzer und einer TPOT von 9.39 ms entspricht. Dies bedeutet eine Steigerung des Gesamtdurchsatzes um das 40.5-Fache im Vergleich zur Einzelbenutzerleistung. Die TPOT-Werte bleiben bis BS=32 im Bereich von 3–5 ms. Die Pareto-Front umfasst acht verschiedene Punkte.
GPT-OSS-120B Leistung
Das größere 120B-Parametermodell erzielt trotz der höheren Parameteranzahl folgende Leistung: Bei Einzelbenutzer-Konkurrenz (BS=1) erreicht es 248.62 tok/s pro Benutzer, einen Gesamtdurchsatz von 783.73 tok/s und eine TPOT von 3.89 ms. Bei BS=2 liefert das Modell 240.99 tok/s pro Benutzer, einen Gesamtdurchsatz von 1,092.91 tok/s und ebenfalls eine TPOT von 3.99 ms.
Die Leistung skaliert weiterhin mit höheren Batchgrößen: BS=4 erreicht 190.63 tok/s pro Benutzer mit insgesamt 2,096.73 tok/s und einer TPOT von 4.22 ms, während BS=8 172.66 tok/s pro Benutzer mit insgesamt 3,692.10 tok/s und einer TPOT von 4.54 ms liefert. Die Skalierung über BS=16 (138.28 tok/s pro Benutzer, insgesamt 5,751.41 tok/s), BS=32 (111.63 tok/s pro Benutzer, insgesamt 8,646.05 tok/s) und BS=64 (88.64 tok/s pro Benutzer, insgesamt 13,027.97 tok/s) zeigt eine kontinuierliche Steigerung des Durchsatzes.
Das Modell erreicht seinen maximalen Gesamtdurchsatz bei BS=256 mit 29,976.99 Tok/s, was 48.64 Tok/s pro Benutzer und einer TPOT von 12.53 ms entspricht. Dies bedeutet eine 38.2-fache Steigerung des Gesamtdurchsatzes im Vergleich zur Leistung bei einem einzelnen Benutzer. Der maximale Gesamtdurchsatz beträgt etwa 78 % des Spitzenwerts des 20B-Modells. Die Pareto-Front umfasst neun verschiedene Punkte – so viele wie bei keinem anderen getesteten Modell.
Unerwartete Leistung des quantisierten Modells
Die Ergebnisse des quantisierten Modells waren unerwartet und erfordern weitere Untersuchungen. In mehreren Fällen erreichten die quantisierten NVFP4- und FP8-Versionen der Modelle nicht die erwarteten Leistungsverbesserungen gegenüber ihren Pendants in nativer Präzision. Beispielsweise erzielte das Llama 3.1 8B FP4-Modell bei BS=1 nur einen Gesamtdurchsatz von 830.46 tok/s, verglichen mit 1,727.62 tok/s bei der Standardpräzisionsvariante, trotz ähnlichem Durchsatz pro Benutzer. Bei höheren Batchgrößen näherten sich die quantisierten Modelle zwar dem Durchsatz der Standardpräzision an (29.2–29.3 Tsd. tok/s gegenüber 32.8 Tsd. tok/s bei BS=256), die Gesamtergebnisse deuten jedoch darauf hin, dass die aktuelle Implementierung von vLLM möglicherweise nicht vollständig für Blackwell optimiert ist.
Wir planen, weitere Tests mit vLLM durchzuführen und es auch mit TensorRT-LLM zu vergleichen, um zu sehen, welche Leistung Endbenutzer heute erwarten können.
Supermicro JumpStart verändert das KI-PoC-Spiel
Supermicros JumpStart-Programm hält, was es verspricht: uneingeschränkter Zugriff auf Hardware der Produktionsklasse ohne die Logistik, Lieferverzögerungen oder den Laboraufwand eines herkömmlichen Proof of Concept (PoC). Unsere JumpStart-Woche auf der X14 HGX B200-Plattform verlief reibungslos und ermöglichte uns, die Leistung genauso zu bewerten wie mit Geräten in unseren eigenen Racks.
Für Unternehmen, die schnell Entscheidungen zur KI-Infrastruktur treffen müssen, kann diese Art von Plattformzugriff die Planung von Wochen auf Tage verkürzen. Ob es darum geht, den GPU-Durchsatz, das Speicherverhalten oder die Modellleistung zu validieren oder einfach die Kompatibilität des Stacks zu bestätigen – JumpStart liefert Ihnen schnell und unkompliziert die gewünschten Ergebnisse. Es ist ein zukunftsorientierter Ansatz zur Hardwarebewertung, und wir würden uns freuen, wenn mehr Anbieter ihn übernehmen würden.
Amazon