AMD MI300X/MI350/MI400: Mehr Speicher, aber gewinnt die Mathematik? — Eine kritische Silizium-Analyse von AMD Instinct vs NVIDIA

AMDs Instinct-GPUs bieten viel HBM-Kapazität und Speicherbandbreite. Die Tabelle vergleicht ausgewählte AMD- und NVIDIA-Produkte anhand von Herstellerangaben. Kapazität, Bandbreite, Rechenleistung, Quantisierungskernel und Verbindungstopologie sind relevant; keiner dieser Werte allein bestimmt den gelieferten Durchsatz eines konkreten Workloads.

Veröffentlichte Herstellerangaben

Die MI355X-Angaben für FP16 und OCP-FP8 sind dichte Matrixwerte; mit strukturierter Sparsity verdoppeln sie sich³. Die B200-Einträge nutzen ebenfalls dichte Werte. AMDs neuere MI455X-Produktseite nennt 23,3 TB/s. Eine frühere Helios-Broschüre nennt 19,6 TB/s pro GPU und kennzeichnet ihre Spezifikationen als technische Prognosen, die sich ändern können. Die nachfolgenden Rechnungen nutzen diesen früheren Wert ausdrücklich als beispielhaftes Spezifikationsszenario⁴.

Die berechneten Verhältnisse

MI355X gegenüber H200: 2,04-mal so viel Speicher, 1,67-mal so viel Bandbreite und 2,54-mal so viel FP8-Spitzenleistung (beide dicht). Gegenüber dem HGX B200 bei dessen Angabe von bis zu 8 TB/s bietet MI355X 1,60-mal so viel Kapazität und ungefähr dieselbe Spitzenbandbreite. Das sind Spezifikationsverhältnisse, keine gemessenen Serving-Durchsätze.

Mit 19,6 TB/s aus der Broschüre hat MI455X 3,06-mal die H200-Kapazität und 4,08-mal dessen Bandbreite (2,45-mal den HGX-B200-Wert von bis zu 8 TB/s). Mit den 23,3 TB/s der Produktseite ergäben sich andere Verhältnisse.

Warum Speicherkapazität allein keine Inferenz entscheidet

Grund 1: Die Quantisierungs-Unterstützung ist nicht symmetrisch

Der verfügbare Quantisierungspfad hängt von Engine, Version, GPU-Generation und Checkpoint ab. vLLMs veröffentlichte Kompatibilitätstabelle listet seine AWQ-, GPTQ-, Marlin- und bitsandbytes-Implementierungen für AMD als nicht unterstützt, FP8 W8A8 und GGUF dagegen als unterstützt. Der aktuelle ROCm-Plattformcode von vLLM nennt zugleich awq, gptq, quark und mxfp4; awq_marlin wird dort auf gewöhnliches AWQ umgeleitet⁷. Ein Kreuz in der Tabelle beweist deshalb nicht, dass jedes 4-Bit-Modell unter ROCm unmöglich ist.

SGLangs Tabelle listet AWQ auf AMD per Triton-Dequantisierung, FP8 per Aiter oder Triton und MXFP4 auf CDNA3/CDNA4 per Aiter. Die Kernel gptq_marlin und awq_marlin sind CUDA-exklusiv; quark_int4fp8_moe ist ein AMD-spezifischer Pfad⁸. Die Tabelle quantifiziert nicht Geschwindigkeit oder Qualität dieser verschiedenen Pfade für ein bestimmtes Modell.

Für denselben 70B-Checkpoint sind rund 70 GB FP8-Gewichte oder etwa 40 GB 4-Bit-Gewichte nützliche Planungswerte vor Metadaten, Aktivierungen und KV-Cache. Ob die 4-Bit-Variante läuft, muss für Engine und GPU geprüft werden. Ein Vergleich mit FP8 auf einer Seite und 4 Bit auf der anderen ändert zudem die Modelldarstellung; ein Kapazitätsverhältnis allein ergibt daraus keinen Leistungssieger⁷⁸.

70B-Modell-Footprint, nur Gewichte:
FP8-Gewichte            ~70 GB   (plus Skalen und Laufzeitspeicher)
4-Bit-Gewichte          ~40 GB   (abhängig von Format und Backend)
 
Llama-70B-GQA-KV-Cache: ~0,33 MB/Token (BF16) -> ein einziger
128k-Token-Kontext addiert ~43 GB KV zusätzlich zu den Gewichten.

Grund 2: Compute-vs-Speicher-Balance (die Roofline)

Für idealisiertes Batch-1-Decoding, das durch die Bandbreite beim Lesen der Gewichte begrenzt ist, ergibt Bandbreite geteilt durch Gewichtsdatenmenge eine Obergrenze. Für ein 70B-BF16-Modell (140 GB) sind das etwa 24 Tokens/s auf einem H100 gegenüber 38 auf einem MI300X — ein Verhältnis von 1,58, genau wie bei der Bandbreite. KV-Lesezugriffe, Rechenarbeit, Kommunikation und tatsächlich erreichte Bandbreite können reales Decoding verlangsamen oder den Engpass verschieben.

Prefill und Decode mit großer Batch können rechengebunden sein. Die theoretischen FP8-Rechenleistung-zu-Bandbreite-Verhältnisse liegen bei rund 493 Operationen pro Byte für MI300X und 591 für H100 (629 für MI355X). MI300X hat den 1,32-fachen dichten FP16-Peak des H100, weniger als sein 1,58-faches Bandbreitenverhältnis. Das deutet auf einen kleineren relativen Vorteil in rechenintensiven Phasen hin, nicht zwingend auf geringere Geschwindigkeit. Die tatsächliche Time-to-First-Token hängt von Modellarchitektur, Kerneln, Promptlänge und Batch ab.

Auf Knotenebene bieten acht MI300X-GPUs zusammen 42,4 TB/s theoretische Spitzenbandbreite. Durch 671 GB FP8-Gewichte geteilt ergibt das eine idealisierte Grenze von rund 63 Tokens/s für ein verteiltes 671B-Parameter-Modell, vor Kommunikation, KV-Traffic und weiterem Overhead. Acht H100-GPUs besitzen zusammen nur 640 GB; die unkomprimierte 671-GB-Gewichtsdarstellung passt dort nicht. Eine bloße Division ihrer Bandbreite durch 671 GB beschreibt deshalb keine lauffähige Konfiguration.

Grund 3: Die Scale-up-Domäne hat 8 GPUs, nicht 72

MI300X/MI355X-Baseboards verbinden acht GPUs über Infinity Fabric (das MI300X-Plattformblatt beschreibt sieben Peer-Links pro GPU; für MI355X sind sieben Links mit je 153,6 GB/s spezifiziert)¹³. NVLink 4 bietet bis zu 900 GB/s aggregierte bidirektionale Bandbreite pro H100, NVLink 5 bis zu 1,8 TB/s pro GPU der B200/GB200-Klasse. NVL72 bildet eine NVLink-Domäne aus 72 GPUs; die Bandbreite pro GPU wird dabei auf Verbindungen aufgeteilt und steht nicht jedem GPU-Paar gleichzeitig exklusiv zur Verfügung⁹.

Die Domänengröße kann Tensor- und Expert-Parallelität begrenzen. TP8 passt in ein Acht-GPU-Baseboard; TP16 auf MI300X/MI355X überschreitet die Knotengrenze und nutzt das Scale-out-Netz. In einer NVL72-Installation können mehr GPUs innerhalb einer NVLink-Domäne bleiben⁹. Das ist für manche kommunikationsintensive Layouts ein Topologievorteil, aber kein gemessener Token-Durchsatzvergleich. Das Ergebnis hängt von Modell-Layout und Traffic-Muster ab.

Software-Stack-Realität vs Benchmark-Bilanz

AMD nennt Day-Zero-Support für optimierte Modelle als Ziel³. Die aktuelle vLLM- und SGLang-Dokumentation enthält sowohl CUDA-spezifische als auch ROCm-spezifische Quantisierungspfade⁷⁸. Welche Implementierung schneller ist, lässt sich nicht aus einer Support-Tabelle ableiten; dafür braucht es Benchmarks mit gleichem Modell, gleicher Präzision, gleichem Workload und gleichem Latenzziel.

AMD reichte in MLPerf Training v5.0 (Juni 2025) Ergebnisse ein; MI350-Ergebnisse folgten in v5.1 (November 2025)¹⁰. MLPerf Inference v5.1 (September 2025) enthält AMD-MI355X-Systeme¹¹. Diese Resultate belegen getestete Konfigurationen, keine allgemeine Reihenfolge zwischen AMD und NVIDIA für alle Workloads. Eine separate MI300X-Evaluierung beschreibt starke Leistung bei speichergebundenen Aufgaben und Grenzen des Software-Stacks in ihrem Testaufbau¹².

Für Beschaffung oder Deployment sollten Gesamtsysteme bei der benötigten Präzision und dem geforderten Serviceniveau verglichen werden. Spitzenwerte zeigen mögliche Konfigurationen, entscheiden diesen Vergleich aber nicht.

MI400/Helios: Überleben die Versprechen die Physik?

Stand September 2026 ist die MI400-Serie angekündigt, aber nicht allgemein verfügbar: MI455X und Helios gelauncht am 2026-07-23, OpenAI erwartet Racks online ab Q4 2026⁵. Alles Folgende ist Herstellerangabe.

Die angekündigten Spezifikationen umfassen 432 GB HBM4, 20,1 PFLOPS FP8 und ein Helios-Rack mit 72 GPUs, 31 TB HBM4 und angegebenen 3,6 TB/s UALoE pro GPU⁴⁵. Die 19,6 TB/s der früheren Broschüre sind das 4,08-Fache der veröffentlichten H200-Bandbreite und das 2,45-Fache des Bis-zu-Werts für HGX B200; der neuere Wert der Produktseite ist höher. Das sind Verhältnisse von Spitzenangaben. Weder daraus noch aus einem berechneten FP8-Roofline-Verhältnis folgt ein gemessener Decode- oder Prefill-Durchsatz.

Die angegebene 72-GPU-Helios-Fabric adressiert den Unterschied der Scale-up-Domänen; beide veröffentlichten AMD-Bandbreitenangaben liegen über dem veröffentlichten Spitzenwert des HGX B200 pro GPU⁴. Die frühere Zahl von 19,6 TB/s ist eine technische Prognose, die neuere Produktseite nennt 23,3 TB/s; keine der beiden Zahlen ist eine gemessene Nutzbandbreite. Auch AMDs Angabe „bis zu 30 % mehr Inferenz-Tokens pro Dollar“ hängt vom nicht offengelegten Vergleichsaufbau ab⁵. Für Aussagen zu realer Leistung und Kosten sind unabhängige, vergleichbare Workloads nötig.

Konfigurationstabelle: Was die Zahlen belegen

Die folgenden Fits verwenden dezimale GB, beispielhaft 15 % Laufzeitzuschlag auf Gewichte und einen ausdrücklichen KV-Puffer, wo angegeben. Sie belegen Kapazitätsgrenzen, keinen Durchsatzsieger:

Die „Mehr VRAM = besser"-Falle, als ein durchgerechnetes Beispiel

Betrachten wir ein 405B-Modell in FP8 mit ungefähr 405 GB Rohgewichten, vor Laufzeitzuschlägen und KV-Cache:

• Auf 8×H100: 640 GB minus 405 GB Rohgewichte lassen 235 GB über acht GPUs, rund 29 GB/GPU für alle weiteren Nutzungen, einschließlich KV-Cache.
• Auf 8×MI300X: 1.536 GB minus 405 GB lassen 1.131 GB, rund 141 GB/GPU für alle weiteren Nutzungen. Das ist in genau dieser Rechnung etwa 4,8-mal die Restkapazität.

Diese Rechnung belegt einen Kapazitätsunterschied, kein Durchsatzergebnis. Ein Vergleich mit H100 muss H100-Rechenleistung und -Bandbreite verwenden; B200- oder NVL72-Werte einzusetzen würde die verglichene Hardware ändern. Erst ein Benchmark beider tatsächlicher Systeme mit gleichem Anfragemix, Quantisierung und Serviceniveau erlaubt eine Aussage zum Durchsatz.

Die Zahlen helfen zuerst, Konfigurationen anhand des Speichers auszusortieren. Ein 671B-FP8-Modell benötigt mehrere MI300X-GPUs, etwa ein Acht-GPU-Baseboard; in den Speicher eines einzelnen MI300X passt es nicht. Die Helios-Werte beschreiben eine angekündigte Rack-Konfiguration, deren reale Leistung noch anhand von Workloads gemessen werden muss.

Artikel erstmals veröffentlicht: 24. September 2026 Autor: flozi00

Weiterlesen

• NVIDIA NVLink Deep Dive — das Fabric auf der anderen Seite
• Der KV-Cache: Bit-exakte Speicher-Mathematik — jede Kapazitätsangabe hier, abgeleitet