Supermicros JumpStart-Programm hat sich als eines der nützlichsten Tools für die Evaluierung von KI-Infrastruktur vor dem Kauf etabliert. Anstelle einer vorgefertigten Demo in einer gemeinsam genutzten Umgebung bietet JumpStart qualifizierten Nutzern kostenlosen, zeitlich begrenzten Bare-Metal-Zugriff auf reale Produktionsserver via SSH, IPMI und VNC. So können sie Workloads auf echter Hardware ausführen. Wir haben das Programm im vergangenen November ausführlich vorgestellt. X14-System mit einer NVIDIA HGX B200und gewann so ein klares Bild davon, was eine Woche gezielten Zugriffs aussagen kann und was nicht. Dieses Mal ermöglichte Supermicro den Zugriff auf ein H14 8U-System mit einer ganz anderen Beschleunigerarchitektur.
Wir haben das AS-8126GS-TNMR fragstSupermicro präsentiert eine luftgekühlte 8U-Plattform mit zwei AMD EPYC 9575F-Prozessoren und acht AMD Instinct MI350X-GPUs. Die MI350X ist AMDs aktueller Flaggschiff-Rechenzentrumsbeschleuniger, basierend auf der CDNA-Architektur der 4. Generation im 3-nm-Verfahren von TSMC. Jede GPU verfügt über 288 GB HBM3e-Speicher. Über AMD Infinity Fabric sind acht GPUs miteinander verbunden, wodurch der Server insgesamt 2.3 TB GPU-Speicher in einem einzigen Knoten mit einer Gesamtbandbreite von 1,024 GB/s bietet. Das System nutzt sechs 5,250-W-Netzteile der Titanium-Klasse in einer redundanten 3+3-Konfiguration. Für skalierbare Bereitstellungen stellt Supermicro zudem dedizierte 400-Gbit/s-Netzwerkverbindungen pro GPU bereit.
AMDs Position im Markt für Rechenzentrums-GPUs hat sich in den letzten zwei Jahren deutlich verändert, und die MI350X-Generation stellt für NVIDIA eine ernstzunehmendere Konkurrenz dar als jedes vorherige Instinct-Produkt. ROCm 7, veröffentlicht im September 2025 und mittlerweile in Version 7.2, bietet native MI350X-Unterstützung sowie eine deutlich verbesserte Inferenzleistung, HIP-API-Updates, die die CUDA-Kompatibilitätslücke schließen, und eine erweiterte Framework-Unterstützung, darunter PyTorch, JAX, TensorFlow, ONNX Runtime, vLLM und SGLang.
Das vLLM-Projekt fügte Ende Dezember 2025 eine dedizierte AMD ROCm CI-Pipeline hinzu und machte AMD-Hardware damit zu einer erstklassigen Plattform in diesem Inferenz-Stack anstatt zu einer nachgelagerten Portierung. Die Akzeptanz im Ökosystem ist ebenfalls kaum zu übersehen: AMD und Meta kündigten an Im Februar 2026 schloss Meta einen mehrjährigen, generationsübergreifenden Vertrag über die Bereitstellung von 6-Gigawatt-GPUs ab, der auf den bestehenden Produktionsinstallationen von Hardware der Serien MI300 und MI350 aufbaut. Dieses Engagement eines der weltweit größten Betreiber von KI-Infrastrukturen ist keine bloße Marketingmaßnahme.
Für Organisationen, die derzeit KI-Beschleunigerinfrastrukturen evaluieren, bleibt die lange Lieferzeit für NVIDIA-Hardware ein Problem. Die Frage ist, ob AMD eine ernstzunehmende Alternative oder nur eine Notlösung darstellt. Nach einer Woche Tests mit ROCm 7.2.0 und dem aktuellen vLLM hat sich die Antwort deutlich von der vor 18 Monaten unterschieden.
Unsere Tests umfassten eine Auswahl gängiger Modelle; die 2.3 TB HBM3e auf einem einzigen Knoten ermöglichten die Inferenz auf einem einzelnen Server bei Modellen mit großen Parametern, darunter Moonshots Kimi K2.5 und MiniMax M2.5.
AMD Instinct MI350X: Architektur und Verbesserungen gegenüber der Vorgängergeneration
Die MI350X stellt den architektonisch ambitioniertesten Generationssprung von AMD in der Instinct-Produktreihe bis dato dar. Das Verständnis der zugrundeliegenden technischen Entscheidungen liefert einen wichtigen Kontext für die Interpretation der resultierenden Leistungsergebnisse.
CDNA 4 Architektur und Prozessknotenübergang
Der grundlegende Wandel von der MI300- zur MI350-Serie beruht auf der Einführung des N3P-Prozessknotens von TSMC für die Accelerator Compute Chiplets (XCDs) anstelle der 5-nm-Fertigung der Vorgängergeneration. Die Gesamtzahl der Transistoren erreicht rund 185 Milliarden, was einer Steigerung von etwa 21 % gegenüber der MI300-Generation entspricht – und das ohne einen entsprechenden Anstieg des Stromverbrauchs.
Die MI350X setzt weiterhin auf AMDs bewährte Multi-Chiplet-Architektur. Kernstück des GPU-Chips sind acht Accelerator Compute Chiplets (XCDs) als primäre Recheneinheiten. Jedes XCD beherbergt vier Shader-Engines mit jeweils acht aktiven CDNA-4-Recheneinheiten, was 32 CUs pro XCD und insgesamt 256 CUs für den gesamten Beschleuniger ergibt.
Im CDNA-4-Gehäusedesign wurde die I/O-Die-Ebene von vier auf zwei Tiles reduziert. Durch diese Reorganisation konnte AMD die Breite des Infinity-Fabric-Busses verdoppeln und so die Bandbreite für zwei Segmente verbessern, während gleichzeitig die Busfrequenz und die Betriebsspannung gesenkt und damit der Stromverbrauch reduziert wurden.
Neu gestaltete Recheneinheiten und erweiterte Präzisionsunterstützung
Dank der Matrix-Mathematik-Funktionen der CDNA 4-Recheneinheit ergibt sich ein erheblicher Leistungsschub: Die MI350-Recheneinheiten bieten im Vergleich zu ihren MI300-Pendants eine Verdopplung des Durchsatzes pro Recheneinheit bei 16-Bit- (BF16, FP16) und 8-Bit-Operationen (FP8, INT8).
Neben den reinen Durchsatzgewinnen bietet CDNA 4 Hardwareunterstützung für Datentypen mit geringerer Präzision, die in der MI300-Serie fehlten, insbesondere FP6 und FP4, zusätzlich zur bereits vorhandenen FP8-Unterstützung aus der vorherigen Generation.
Zusätzlich zu diesen Standardformaten bietet die MI350X native Hardwareunterstützung für die OCP-Mikroskalierungsvarianten MXFP4, MXFP6 und MXFP8. Mikroskalierungsformate sind darauf ausgelegt, die Vorteile von Berechnungen mit geringerer Präzision bei gleichzeitig höherer Ausgabequalität zu nutzen, als es die Standardquantisierung üblicherweise ermöglicht. Dies ist keine AMD-spezifische Entwicklung. Das NVFP4-Format von NVIDIA basiert auf denselben Mikroskalierungsprinzipien und wird in der Entwicklung fortschrittlicher Modelle weit verbreitet eingesetzt. Die GPT-OSS-Familie von OpenAI ist eines der prominentesten Beispiele für Modelle, die auf diesen Formaten basieren. Dank der nativen MXFP4-Unterstützung kann die MI350X diese und ähnliche quantisierte Modellfamilien bedienen, ohne auf Softwareemulation oder Präzisionserhöhung zurückgreifen zu müssen.
Der MI350X liefert 9.2 PFLOPs bei MXFP4 und MXFP6, verglichen mit 4.6 PFLOPs bei OCP-FP8, mit 2.3 PFLOPs bei FP16 und einem maximalen Takt von 2,200 MHz. Für inferenzoptimierte Anwendungen, bei denen Mikroskalierung der Quantisierung sinnvoll ist, verdoppelt sich die Rechenleistung im Vergleich zu FP8-Workloads. Der CDNA-4-Recheneinheit wurde außerdem eine neue Vektor-ALU hinzugefügt, die 2-Bit-Operationen unterstützt und BF16-Ergebnisse in FP32 akkumulieren kann. Dies bietet zusätzliche Flexibilität für Vektor-Workloads mit geringer Präzision außerhalb des primären Matrix-Berechnungspfads.
Speichersubsystem: HBM3e, Infinity Cache und Bandbreiteneffizienz
Die MI350-Serie verfügt über ein deutlich verbessertes Speichersubsystem mit acht HBM3e-Speicherstapeln, die eine Gesamtkapazität von 288 GB pro GPU bieten. Jeder 36-GB-Stapel besteht aus zwölf 24-Gbit-Bausteinen und arbeitet mit der vollen HBM3e-Pin-Geschwindigkeit von 8 Gbit/s pro Pin. Die Architektur behält AMDs Infinity Cache bei, einen speicherseitigen Cache zwischen dem HBM- und dem Infinity Fabric/L2-Cache. Er umfasst 128 Kanäle mit jeweils 2 MB Cache, was insgesamt 256 MB pro GPU ergibt. AMD hat die On-Die-Netzwerkbusse innerhalb der IODs verbreitert und betreibt sie mit reduzierter Spannung, wodurch eine etwa 1.3-fach höhere Speicherbandbreite pro Watt im Vergleich zur MI300-Serie erreicht wird.
Die Erhöhung der Speicherkapazität von 192 GB auf 288 GB beim MI300X baut AMDs Vorsprung beim Speicherspielraum pro GPU weiter aus, was sich direkt auf die Inferenz großer Modelle auswirkt. Jede MI350X-GPU kann unabhängig Modelle mit mehr als 500 Milliarden Parametern verarbeiten. Auf einem Server mit acht GPUs entfallen durch die insgesamt 2.3 TB HBM3e die Anforderungen an eine Verteilung auf mehrere Knoten, die den Einsatz von Modellen mit Billionen von Parametern bisher erschwert haben, wie die Ergebnisse von Kimi K2.5 und MiniMax M2.5 in diesem Test zeigen.
Flexible Partitionierungs- und Bereitstellungsarchitektur
Die MI350-Serie unterstützt flexible GPU-Partitionierung pro Sockel, wobei der Speicher in zwei separate Cluster aufgeteilt wird. Diese Flexibilität gilt auch für die XCDs, deren Quad-XCD-Cluster in zwei oder einzelne Blöcke unterteilt werden kann. Dadurch unterstützt der Chip Konfigurationen wie beispielsweise acht Instanzen von 70B-Modellen in CPX+NPS2. Für Unternehmen, die heterogene Inferenz-Workloads auf gemeinsam genutzter Infrastruktur ausführen, reduziert diese Partitionierungsfunktion den Bedarf an dedizierter Hardware pro Modellebene und verbessert die Wirtschaftlichkeit der Nutzung in gemischten Bereitstellungsumgebungen.
Die MI350-Serie ist weiterhin mit der UBB-Infrastruktur (Universal Base Board) der MI300-Serie kompatibel. Vorhandene Servergehäuse, Stromversorgung und Kühlung können ohne Änderungen weiterverwendet werden, was den Upgrade-Aufwand für Unternehmen mit aktiven MI300-Systemen deutlich reduziert.
MI355X: Das flüssigkeitsgekühlte Geschwisterchen
Die MI350-Serie ist in zwei Varianten erhältlich, die auf identischem Silizium basieren und für unterschiedliche thermische Betriebsbereiche optimiert sind. Das hier getestete MI350X ist die luftgekühlte Variante, während das MI355X das flüssigkeitsgekühlte Pendant darstellt und für Umgebungen mit höherer Packungsdichte und vorhandener direkter Flüssigkeitskühlungsinfrastruktur konzipiert ist.
Obwohl beide Varianten auf derselben Hardwarebasis aufbauen, ermöglicht die höhere Leistungsaufnahme des MI355X höhere, dauerhafte Taktfrequenzen. Dies führt zu einem Leistungsvorteil von etwa 20 % im realen End-to-End-Betrieb im Vergleich zum MI350X. Der MI355X hat eine maximale TDP von 1,400 W gegenüber 1,000 W beim MI350X und erreicht eine maximale Taktfrequenz von 2.4 GHz gegenüber 2.2 GHz bei der luftgekühlten Variante.
Im Vergleich zur Vorgängergeneration bietet die MI355X-Plattform eine bis zu vierfach höhere theoretische Spitzenleistung als die MI300X. In der Praxis ergeben sich Leistungssteigerungen von ca. 4.2x bei agentenbasierten Anwendungen und Chatbots sowie von ca. 3x bei der Content-Generierung. Für Unternehmen, die den Einsatz der MI350X evaluieren, stellt der Leistungsunterschied von 20 % zwischen den beiden Varianten eine klare Obergrenze dar. Einrichtungen mit DLC-Infrastruktur sollten die MI355X prüfen, um festzustellen, ob die Investition in die Kühlung einen ausreichenden Durchsatzzuwachs für ihr spezifisches Workload-Profil erzielt, bevor sie sich für luftgekühlte Konfigurationen in großem Umfang entscheiden.
Zugriff auf den AMD Instinct MI350X über das Supermicro JumpStart-Programm
Für den Einstieg in JumpStart ist eine Registrierung im Supermicro-Portal erforderlich. Dort können berechtigte Nutzer verfügbare Systeme durchsuchen und einen Reservierungszeitraum festlegen. Nach der Genehmigung stellt das Portal für die Dauer der Reservierung SSH-Zugangsdaten, IPMI-Zugriff und eine webbasierte Remote-Konsole bereit. Das System wird mit vorinstalliertem Ubuntu geliefert und ist sofort einsatzbereit. Es gibt keine Bereitstellungsverzögerung und Sie benötigen keine Unterstützung. Unsere Reservierung lief vom 23. bis 27. März 2026 und ermöglichte uns somit eine volle Woche Nutzung der Plattform – wie bereits bei unserem vorherigen JumpStart-Projekt mit dem HGX B200.
Der untenstehende Screenshot zeigt die Terminalausgabe von Jumpstart für das H14-System. Das AMD-SMI-Tool zeigt die acht AMD Instinct MI350X GPUs und ihre laufenden Softwareversionen an.
Ergebnisse des AMD Instinct MI350X Leistungstests
Systemkonfiguration
- Fahrwerk: Supermicro H14
- ZENTRALPROZESSOR: Dual AMD EPYC 9575F
- Erinnerung: 3 TB DDR5
- GPU: acht AMD Instinct MI350X
- Lagerung: 2 x 3.8 TB PCIe 4.0 M.2 NVMe SSD und 1 x 1.92 TB NVMe M.2
Zusammenfassung der Ergebnisse
| Modell | Präzision | Gleich (256/256) | Vorfüllung stark (8k/1k) | Dekodierungsintensiv (1k/8k) |
|---|---|---|---|---|
| GPT-OSS 20B | NVFP4 | 62,247 | 123,714 | 32,468 |
| GPT-OSS 120B | NVFP4 | 33,538 | 84,018 | 20,602 |
| Lama 3.1 8B Anweisung | BF16 | 51,467 | 77,658 * | 19,326 |
| Mistral Small 3.1 24B | FP8 | 40,742 | 56,093 | 14,557 |
| Mistral Small 3.1 24B | BF16 | 30,530 | 53,740 | 13,559 |
| Qwen3 Coder 30B A3B | BF16 | 34,980 | 51,550 | 11,782 |
| Qwen3 Coder 30B A3B | FP8 | 25,928 | 47,179 | 11,014 |
| MiniMax M2.5 | Block-Scaled FP8 | 14,391 | 23,689 | 6,068 |
| Kimi K2.5 | INT4 QAT + BF16 | 6,527 | 11,256 | 2,513 |
| Alle Werte in tok/s, maximaler Durchsatz bei BS=256. *Llama 3.1 8B prefill-heavy erreichte einen Spitzenwert bei BS=128 (77,658 tok/s); bei BS=256 waren es 76,893 tok/s. | ||||
Claude Code Serving – MiniMax M2.5
Über die üblichen Benchmarks für LLM-Inferenz hinaus wollten wir die Leistungsfähigkeit dieser Hardware in einem agentenbasierten Codierungs-Workflow evaluieren, insbesondere im Hinblick auf die gleichzeitige Nutzung mehrerer Claude-Code-Sitzungen mit einem lokal gehosteten Modell. Dieser Anwendungsfall ist direkt auf die Produktivität von Entwicklungsteams übertragbar: Wie viele Entwickler können gleichzeitig einen KI-Codierungsassistenten nutzen, der von einem einzelnen Knoten bereitgestellt wird, bevor die Benutzerfreundlichkeit nachlässt?
Um dies zu testen, haben wir ein Benchmark-System entwickelt, das einen Datensatz mit mittelschweren Programmieraufgaben generiert (z. B. die Implementierung eines LRU-Caches, die Entwicklung einer CLI-Todo-Anwendung, das Schreiben eines Markdown-Konverters und die Erstellung einer REST-API). Jede Claude-Code-Sitzung wird in einem eigenen Docker-Container auf dem lokalen vLLM-Server ausgeführt. Ein transparenter Proxy befindet sich zwischen den Sitzungen und dem Inferenz-Endpunkt und erfasst die Metriken pro Anfrage für jede Claude-Code-Instanz. Als Modell wurde MiniMax M2.5 verwendet, das über vLLM auf den acht MI350X-GPUs bereitgestellt wurde. Obwohl M2.5 nicht das führende Programmiermodell in öffentlichen Bestenlisten ist, handelt es sich um ein leistungsfähiges Modell, das von vielen Nutzern, darunter auch vielen unserer Entwicklerkollegen, lokal eingesetzt wird.
Als Referenzwert verwenden wir den durchschnittlichen Durchsatz von Anthropics Claude Opus 4.6 über OpenRouter.ai, einem der beliebtesten Routing-Dienste für den produktiven API-Zugriff. Dieser Wert liegt bei etwa 37 Token pro Sekunde und API-Anfrage.
Wir haben zwei wichtige Kennzahlen gemessen: die durchschnittliche Anzahl der Ausgabetoken pro Sekunde pro Claude Code-Sitzung (was jeder Entwickler erlebt) und die Gesamtanzahl der Ausgabetoken pro Sekunde über alle Sitzungen hinweg (die gesamte Arbeit, die der Server leistet).
Die Ergebnisse zeigen, dass eine einzelne gleichzeitige Sitzung 38.8 tok/s pro Benutzer und insgesamt 38 tok/s liefert, was leicht über dem OpenRouter-Cloud-Baseline-Wert liegt. Bei zwei Sitzungen steigt der Durchsatz auf 39.5 tok/s pro Benutzer, da die Batchverarbeitung von vLLM den Overhead reduziert, und der Gesamtdurchsatz erreicht 63 tok/s. Vier gleichzeitige Sitzungen erreichen 37.3 tok/s pro Benutzer und entsprechen damit dem Cloud-Baseline-Wert, während gleichzeitig vier Entwickler bedient werden. Der Gesamtdurchsatz liegt bei 128 tok/s. Ab acht Sitzungen sinkt der Durchsatz pro Instanz: 34.6 tok/s pro Benutzer bei acht Sitzungen, 31.4 tok/s bei sechzehn Sitzungen mit insgesamt 190 tok/s und pendelt sich bei 32 bzw. 64 Sitzungen bei etwa 23 tok/s pro Benutzer ein, während der Gesamtdurchsatz auf 578 tok/s bzw. 986 tok/s steigt. Dies ist der klassische Zielkonflikt zwischen Stapelverarbeitung und Interaktivität: Das System kann durch die Bündelung von Anfragen einen deutlich höheren Gesamtdurchsatz erzielen, jedoch verringert sich dadurch die Antwortzeit für jeden einzelnen Benutzer. Selbst bei 64 gleichzeitigen Benutzern ist die Interaktion für jeden Entwickler noch nutzbar, wenn auch merklich langsamer als im Cloud-Standard.
Für Organisationen, die die Kosten von Dutzenden gleichzeitiger kommerzieller API-Abonnements gegen eine selbstgehostete Infrastruktur abwägen, ist der Kompromiss klar: Ein einzelner MI350X-Knoten kann ein Entwicklungsteam von 16 bis 32 Ingenieuren bedienen und dabei Antwortzeiten pro Benutzer innerhalb von 60-85 % der Cloud-Baseline halten, während gleichzeitig eine Gesamtleistung von 600 bis 1,000 Token/s erzielt wird. Hinzu kommen die Vorteile der Datenlokalität, keine API-Gebühren pro Token und die volle Kontrolle über die Modellauswahl.
vLLM Online-Bereitstellung – LLM-Inferenzleistung
vLLM ist eine der beliebtesten Inferenz- und Server-Engines für LLMs mit hohem Durchsatz. Der vLLM Online-Server-Benchmark evaluiert die Serverleistung dieser Inferenz-Engine unter realen Bedingungen bei gleichzeitigen Anfragen. Er simuliert Produktionslasten, indem er Anfragen an einen laufenden vLLM-Server sendet. Dabei lassen sich Parameter wie Anfragerate, Eingabe-/Ausgabelängen und die Anzahl der gleichzeitigen Clients konfigurieren. Der Benchmark misst wichtige Kennzahlen wie Durchsatz (Tokens pro Sekunde), Zeit bis zum ersten Token und Zeit pro Ausgabetoken (TPOT). So können Benutzer die Leistung von vLLM unter verschiedenen Lastbedingungen besser 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.
GPT-OSS 120B und 20B
Die GPT-OSS-Modellfamilie wurde sowohl in der 120B- als auch in der 20B-Konfiguration auf dem Supermicro H14 getestet.
GPT-OSS 120B
Das Modell 120B liefert unter gleicher Auslastung (256/256) 313.42 tok/s bei BS=1, erreicht 11,261.72 tok/s bei BS=64 und einen Spitzenwert von 33,538.23 tok/s bei BS=256. Bei hoher Vorfüllung (8k/1k) beginnt die Leistung bei 1,724.84 tok/s, steigt auf 36,156.80 tok/s bei BS=32 und 79,247.76 tok/s bei BS=128 und erreicht einen Spitzenwert von 84,018.79 tok/s bei BS=256. Bei dekodierungsintensiven Aufgaben (1k/8k) steigt die Latenz von 288.90 tok/s bei BS=1 auf 20,602.52 tok/s bei BS=256, wobei die Latenz bei niedrigeren Parallelitätsniveaus gut kontrolliert bleibt.
GPT-OSS 20B
Das Modell 20B erreicht bei gleicher Arbeitslast 485.17 t/s bei BS=1, 17,986.36 t/s bei BS=64 und einen Spitzenwert von 62,247.52 t/s bei BS=256. Bei hoher Vorfüllungslast beginnt der Wert bei 3,120.72 t/s, steigt auf 48,132.52 t/s bei BS=32 und 83,968.71 t/s bei BS=64 und erreicht einen Spitzenwert von 123,714.50 t/s bei BS=256 – den höchsten jemals gemessenen absoluten Vorfülldurchsatz beider Modellgrößen. Der Decode-intensive Prozess wächst von 378.20 tok/s bei BS=1 auf 32,468.67 tok/s bei BS=256 und erreicht damit etwa das 1.6-fache des Decode-Durchsatzes des 120B bei maximaler Parallelität, während gleichzeitig engere Latenzeigenschaften beibehalten werden.
Qwen3 Coder 30B A3B Instruct und FP8 Instruct
Der Qwen3-Coder-30B-A3B-Instruct auf dem Supermicro H14 wurde sowohl mit Standardgenauigkeit (BF16) als auch mit FP8-Genauigkeit getestet.
Qwen3-Coder-30B-A3B-Instruct (BF16)
Bei BF16 liefert die gleichmäßige Arbeitslast (256/256) 240.53 tok/s bei BS=1, erreicht 13,312.70 tok/s bei BS=64 und 21,333.79 tok/s bei BS=128, mit einem Spitzendurchsatz von 34,980.97 tok/s bei BS=256. Die Vorfüllungslast (8k/1k) beginnt bei 1,276.76 tok/s, steigt auf 25,069.32 tok/s bei BS=32 und 50,198.94 tok/s bei BS=128, mit einem Spitzenwert von 51,550.66 tok/s bei BS=256. Der dekodierungsintensive (1k/8k) Fall wächst stetig von etwa 188 tok/s bei BS=1 auf 11,782 tok/s bei BS=256 und weist damit das engste Latenzprofil der drei Szenarien auf.
Qwen3-Coder-30B-A3B-Instruct (FP8)
Die FP8-Variante erreicht unter gleicher Last bei BS=1 188.92 tok/s, bei BS=64 10,866.27 tok/s und bei BS=128 17,617.60 tok/s, mit einem Spitzenwert von 25,928.77 tok/s bei BS=256 – und liegt damit über den gesamten Bereich leicht hinter den BF16-Werten zurück. Bei starker Vorfüllung beginnt die Leistung bei 860.07 tok/s, steigt auf 20,513.77 tok/s bei BS=32 und 44,205.46 tok/s bei BS=128, mit einem Spitzenwert von 47,179.15 tok/s bei BS=256. Der Decode-intensive Wert steigt von 133.79 tok/s bei BS=1 auf 11,014.95 tok/s bei BS=256, skaliert also konsistent und bleibt dabei durchgehend nahe an BF16.
Mistral Small 3.1 24B Anleitung 2503
Die Mistral-Small-3.1-24B-Instruct-2503 auf dem H14 wurde sowohl mit Standard- als auch mit FP8-dynamischer Genauigkeit getestet und zeigte eine konsistente Skalierung über alle drei Arbeitslastprofile hinweg.
Mistral-Small-3.1-24B-Instruct-2503 (BF16)
Bei BF16-Präzision liefert die gleichmäßige Arbeitslast (256/256) 236.15 tok/s bei BS=1, erreicht 15,494.56 tok/s bei BS=64, 24,216.52 tok/s bei BS=128 und einen Spitzenwert von 30,530.54 tok/s bei BS=256. Die Vorfüllungslast (8k/1k) beginnt bei 1,429.41 tok/s, steigt auf 29,631.68 tok/s bei BS=32 und 54,871.74 tok/s bei BS=128 und erreicht einen Spitzenwert von 53,740.04 tok/s bei BS=256. Der Dekodieraufwand (1k/8k) steigt von 242.66 tok/s bei BS=1 auf 13,559.19 tok/s bei BS=256 und skaliert stetig über den gesamten Bereich.
Mistral-Small-3.1-24B-Instruct-2503 (FP8-dynamic)
Die FP8-dynamische Variante erreicht unter gleicher Arbeitslast 184.25 tok/s bei BS=1, 16,113.95 tok/s bei BS=64 und 26,409.01 tok/s bei BS=128, mit einem Spitzenwert von 40,742.04 tok/s bei BS=256. Die Variante mit hohem Vorfüllbedarf beginnt bei 1,210.06 tok/s, steigt auf 28,773.52 tok/s bei BS=32 und 57,765.02 tok/s bei BS=128, mit einem Spitzenwert von 56,093.09 tok/s bei BS=256 und übertrifft ab BS=64 die Ergebnisse der Standardpräzision. Der Decode-intensive Bereich wächst von 183.94 tok/s bei BS=1 auf 14,557.94 tok/s bei BS=256, folgt im mittleren Bereich eng, bevor er bei BS=128 und BS=256 leicht davonzieht.
Lama 3.1 8B Anweisung
Beim Llama-3.1-8B-Instruct wurde bei gleichmäßiger Arbeitslast (256/256) eine Leistung von 373.26 tok/s bei BS=1 beobachtet, die 19,363.33 tok/s bei BS=64, 34,155.70 tok/s bei BS=128 und einen Spitzenwert von 51,467.30 tok/s bei BS=256 erreicht. Bei hoher Vorbefüllung (8k/1k) beginnt die Leistung bei 1,959.04 tok/s, steigt auf 37,227.63 tok/s bei BS=32 und 60,062.40 tok/s bei BS=64, erreicht einen Spitzenwert von 77,658.50 tok/s bei BS=128 und fällt dann leicht auf 76,893.77 tok/s bei BS=256 ab. Das Modell mit hohem Dekodierungsaufwand (1k/8k) beginnt bei 326.48 tok/s, erreicht 17,877.52 tok/s bei BS=128 und 19,326.35 tok/s bei BS=256 und behält damit eine niedrigere Latenz pro Token auch im Bereich der gleichzeitigen Verarbeitung bei als alle getesteten größeren Modelle.
MiniMax M2.5
Die MiniMax-M2.5 auf dem H14 vervollständigt die Modellreihe und positioniert sich hinsichtlich des Durchsatzprofils zwischen der Kimi K2.5 und den mittelgroßen Modellen. Ihre Eigenschaften spiegeln die Architektur mit gemischten Komponenten wider. Bei gleichmäßiger Auslastung (256/256) erreicht sie 79.31 tok/s bei BS=1, 5,029.76 tok/s bei BS=64, 7,801.10 tok/s bei BS=128 und 14,391.98 tok/s bei BS=256. Das Szenario „Prefill-heavy (8k/1k)“ zeigt die stärkste Skalierung der drei Szenarien: Die Latenz beginnt bei 424.41 kbit/s und steigt auf 10,376.75 kbit/s bei BS=32 und 20,658.57 kbit/s bei BS=128, mit einem Spitzenwert von 23,689.18 kbit/s bei BS=256. Das Szenario „Decode-heavy (1k/8k)“ skaliert stetig auf 4,257.68 kbit/s bei BS=128 und 6,068.70 kbit/s bei BS=256 und bietet damit das konsistenteste Latenzwachstum über den gesamten Bereich der Parallelität.
Kimi K2.5
Das Kimi K2.5 1-Billionen-Parameter-Modell auf dem H14 ist das größte und intelligenteste Modell, das in diesem Review getestet wurde, und sein Durchsatz spiegelt dieses Gewicht wider.
Die gleichmäßige Arbeitslast (256/256) liefert 72.06 tok/s bei BS=1, erreicht 2,693.07 tok/s bei BS=64, 4,244.27 tok/s bei BS=128 und einen Spitzenwert von 6,527.62 tok/s bei BS=256. Die vorfüllintensive Variante (8k/1k) skaliert deutlich stärker: Sie beginnt bei 185.29 tok/s und erreicht 3,798.85 tok/s bei BS=32 sowie 9,153.12 tok/s bei BS=128, mit einem Spitzendurchsatz von 11,256.69 tok/s bei BS=256. Der sprunghafte Anstieg von BS=128 auf BS=256 ist mit einem signifikanten Latenzverlust verbunden, was darauf hindeutet, dass das System bei voller Batch-Tiefe für diese Modellgröße an seine Speicher- und Rechengrenzen stößt. Bei dekodierungsintensiven Szenarien (1k/8k) steigt der Durchsatz von 29.88 tok/s bei BS=1 auf 2,513.85 tok/s bei BS=256. Dies entspricht der engsten Skalierungskurve der drei Szenarien und zeigt gleichzeitig über den gesamten Bereich hinweg konsistente Durchsatzsteigerungen.
Fazit
Der AMD Instinct MI350X bietet eine sehr wettbewerbsfähige Inferenzleistung über alle hier getesteten Workload-Profile hinweg, und das Supermicro AS-8126GS-TNMR stellt eine optimal entwickelte Plattform dar, um diese Leistung auszuschöpfen. Mit 288 GB HBM3e pro Beschleuniger und acht über Infinity Fabric verbundenen GPUs reichen die insgesamt 2.3 TB GPU-Speicher eines einzelnen Knotens aus, um Modelle mit Billionen von Parametern wie Kimi K2.5 und MiniMax M2.5 ohne Multi-Node-Verteilung oder Workarounds zur Modellpartitionierung zu bedienen. Diese Fähigkeit vereinfacht die Bereitstellungsarchitektur für groß angelegte Inferenz erheblich.
Auch kleinere Modelle lieferten starke Ergebnisse. Der Llama 3.1 8B überschritt bei rechenintensiven Workloads 77,000 Tok/s, und Architekturen der Mittelklasse wie der Mistral Small 3.1 24B und der Qwen3 Coder 30B erzielten über den gesamten Parallelitätsbereich hinweg einen konstant hohen Durchsatz bei gleichzeitig gut kontrollierter Latenz. Insgesamt deuten die Ergebnisse auf eine Hardwareplattform hin, die unter Last vorhersehbar skaliert, anstatt bei höheren Batch-Tiefen abrupt einzubrechen.
ROCm 7.2 bringt signifikante Verbesserungen für den AMD-Inferenz-Software-Stack, insbesondere in Kombination mit vLLM 0.18. Diese Kombination sorgt für ein spürbar stabileres und leistungsfähigeres Nutzungserlebnis als frühere ROCm-Generationen, mit breiterer Framework-Unterstützung und weniger der Probleme, die frühere Instinct-Implementierungen kennzeichneten. Die Dynamik im AMD-Hardware-Ökosystem ist ebenfalls bemerkenswert: vLLM unterhält nun eine dedizierte AMD ROCm CI-Pipeline, und Metas Engagement für die generationsübergreifende Bereitstellung im 6-Gigawatt-Bereich unterstreicht, dass die Validierung in der Produktion weit über kontrollierte Benchmark-Umgebungen hinausgeht.
Die Auswertung des Claude Code-Dienstes liefert eine praxisnahe Perspektive auf die reinen Durchsatzzahlen. Ein einzelner MI350X-Knoten erreichte nahezu Cloud-Standard-Reaktionszeiten für bis zu 16 gleichzeitige Codierungssitzungen und blieb mit bis zu 64 gleichzeitigen Nutzern interaktiv, während er eine Gesamtausgabe von fast 1,000 Token pro Sekunde generierte. Für Unternehmen, die die Kosten kommerzieller API-Abonnements mit einer selbst gehosteten Infrastruktur abwägen, wird die Wirtschaftlichkeit bei dieser Dichte deutlich. Hinzu kommen weitere Vorteile wie Datenlokalität, der Wegfall von Token-Kosten und die uneingeschränkte Modellauswahl.
Supermicros JumpStart-Programm hat sich im Infrastruktur-Evaluierungsprozess weiterhin bewährt. Der direkte Zugriff auf Produktionshardware ohne Bereitstellungsaufwand ermöglichte es uns, reale Workloads unter realen Bedingungen während des gesamten Testzeitraums auszuführen. Für Teams, die Accelerator-Beschaffungsbewertungen durchführen, ist dieser praxisnahe Zugriff nach wie vor deutlich aussagekräftiger als der Vergleich von Datenblättern oder ausgewählte Anbieterdemonstrationen.
Amazon