1 Punkte von GN⁺ 4 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Während die Nachfrage nach Inferenz das Angebot überholt und die Kosten für NVIDIA-GPUs und Tokens steigen, entwickelt sich die AMD MI355X zu einer kostengünstigen Inferenz-Alternative: Im Durchschnitt ist sie pro GPU etwa 2,75-mal günstiger als B300
  • Die AMD-Instinct-MI350-Serie konkurriert auf Siliziumebene mit Blackwell, doch NVIDIAs Softwarevorsprung und Day-0-Support entscheiden über die tatsächliche Serving-Geschwindigkeit und die Einstiegshürden
  • Wafer hat GLM-5.2 auf MI355X optimiert und erreichte bei einer Workload mit 20k Eingabe-/1k Ausgabe-Tokens und 60 % Cache-Hit-Rate 2626 tok/s/node sowie 2,4 rps; das entspricht 80 % der gemessenen B200-Performance
  • In einem Single-Stream-Szenario wurden bei 10k Eingabe-Tokens/1,5k Ausgabe-Tokens 213 tok/s gemessen; das liegt zwar nicht an der Spitze der Leaderboards, gilt aber beim Kosten-Performance-Verhältnis als überlegen
  • Das Ergebnis entstand ohne Custom Kernel, sondern durch Framework-Bugfixes, Quantisierung, Speculative Decode und Tuning der MoE-Kernel-Auswahl; damit wird AMDs Herausforderung zunehmend weniger eine Frage der Software selbst als des Supports

AMD-Inferenzkosten und NVIDIAs Softwarelücke

  • Die Nachfrage nach Inferenz wächst schnell und übersteigt das Angebot; da Frontier-Modelle wie Claude Fable, GLM-5.2 und Minimax M3 fast im Zweiwochentakt erscheinen, steigt auch die Token-Nachfrage
  • Das Blackwell-Angebot reicht nicht aus, wodurch sowohl die Preise für NVIDIA-GPUs als auch die Token-Kosten teurer werden
  • Die AMD MI355X ist im Durchschnitt pro GPU etwa 2,75-mal günstiger als B300, bei vergleichbaren Hardware-Spezifikationen
  • Die AMD-Instinct-MI350-Serie konkurriert auf Siliziumebene mit Blackwell, doch NVIDIA kann dank Day-0-Support und Software-Ökosystem die Inferenz aktueller Modelle schneller und mit weniger Reibung servieren
  • Auf MI355X und dem ROCm-Stack ist SOTA-Performance für aktuelle Frontier-Modelle oft nicht standardmäßig verfügbar, und selbst lauffähige Images können schwer zu finden sein
  • Ohne Day-0-Support braucht es Wochen an Engineering- und Compute-Aufwand, um aktuelle Modelle zu bauen und zu optimieren; währenddessen erscheinen noch neuere Modelle, sodass AMD ständig aufholen muss

GLM-5.2 auf MI355X: Performance

  • Wafer sieht, dass sich die praktische Lücke zwischen AMD und NVIDIA verringert, da Agents Verbesserungen bei Kernel- und Modelloptimierung ermöglichen
  • Bei einer Workload mit 20k Eingabe-/1k Ausgabe-Tokens und 60 % Cache-Hit-Rate wurden 2626 tok/s/node erreicht
    • Anhaltende RPS: 2,4 rps
    • Der definierte Knee liegt bei einer TTFT von höchstens 5 Sekunden
    • Das entspricht 80 % der auf B200 gemessenen Performance
    • MI355X ist mehr als doppelt so günstig
Anhaltende RPS Aggregierte tok/s/node TTFT p50 / p95 Erfolgsrate
0.5 449 0.59s / 0.60s 100%
1.0 974 0.60s / 0.81s 100%
1.5 1913 0.62s / 1.03s 100%
2.0 1944 0.62s / 1.05s 100%
2.25 2089 0.63s / 1.23s 100%
2.4 Sättigung 2626 0.81s / 2.22s 100%
  • Nach den Kriterien von Artificial Analysis wurden bei GLM-5.2 im Single-Stream mit 10k Eingabe-Tokens/1,5k Ausgabe-Tokens 213 tok/s erreicht
  • Dieser Wert liegt zwar nicht an der Spitze des Artificial-Analysis-Leaderboards, wird aber beim Kosten-Performance-Verhältnis als überlegen angesehen
  • Der Test wurde auf AMD-MI355X-Kapazität von TensorWave serviert

Quantisierung und Wahl des Inferenz-Frameworks

  • Der erste Schritt bestand in Quantisierung und Framework-Auswahl; Wafer quantisierte das bf16-basierte GLM-5.2 mit AMD Quark auf MXFP4
  • Im Vergleich zur offiziellen FP8-Quantisierung von z-ai wurde MXFP4 bei GPQA-Diamond, tau2 und GSM8K als praktisch verlustfrei bewertet
Evaluation FP8-Baseline MXFP4 Δ
GSM8K, 200 Fragen, 5-shot, greedy 0.965 ± 0.013 0.955 ± 0.014 −0.010
GPQA-Diamond, 198 Fragen × 2 seeds, temp 1.0 0.9217 ± 0.027 0.9026 ± 0.029 −0.019
tau2 macro 0.819 0.834 +0.015
  • Als Inferenz-Frameworks kamen drei Kandidaten infrage: vLLM, ATOM und sglang
    • vLLM konnte den MXFP4-+GlmMoeDsa-Pfad nicht ausführen und damit die Vorteile der MXFP4-Gewichte nicht nutzen
    • ATOM verschlechterte bei langen Kontexten die Ausgabequalität
    • sglang hatte die geringste Reibung bis zum nativen Support, nutzte die Quantisierung und hielt zugleich konsistente Ausgaben aufrecht

Zwei Probleme, die Speculative Decode blockierten

  • Zur Verbesserung des Durchsatzes sollte Speculative Decode in sglang aktiviert werden, doch die sglang-ROCm-Images unterstützten dies nicht standardmäßig
  • Damit MTP korrekt funktioniert, waren zwei Korrekturen nötig
  • Das erste Problem war, dass der Shared Expert des MTP-Head als bf16 gespeichert wird, die Quantisierungsabfrage von sglang ihn aber wegen eines abweichenden Modul-Prefixes als MXFP4 bauen wollte
    • Quark benennt den bf16 Shared Expert als model.layers.78.mlp.shared_experts.*
    • Der tatsächliche Prefix des MTP-Layers ist model.decoder.*
    • Durch diese Abweichung wurde beim Laden versucht, full-width-bf16-Gewichte in half-width-4-bit-Slots einzulesen, wodurch die Initialisierung mit einem Shape-Mismatch fehlschlug
    • Wafer kopierte die Einträge von Layer 78 zusätzlich unter die von sglang tatsächlich verwendeten Decoder-Namen, schaltete damit Speculative Decode frei und steigerte den Single-Stream-Durchsatz um fast das Dreifache
  • Das zweite Problem blockierte tiefes Speculative Decode wie die von z-ai vorgeschlagene 5/1/6-Konfiguration
    • Der für Draft Depth 4 und höher benötigte fused multi-step metadata Kernel schrieb #include <cuda_runtime.h> ohne ROCm-Guard
    • Die Korrektur bestand in einem einzelnen #ifdef USE_ROCM-Guard
  • Nachdem Speculative Decode korrekt funktionierte, wurden weitere Einstellungen wie --kv-cache-dtype fp8_e4m3 und --enable-aiter-allreduce-fusion optimiert, wodurch der Single-Stream-Decode 213 tok/s erreichte

Engpässe beim aggregierten Durchsatz und MoE-Tuning

  • Für die definierte Workload reichten Decode-Optimierungen allein nicht aus; bei 20k Eingabe und 60 % Cache war der Hauptengpass Prefill
  • In der auf Single-Stream-Decode ausgelegten TP8-Konfiguration führte MI355X GLM-5.2-MXFP4 mit 1461 tok/s/node aus
  • Nach dem Wechsel auf TP4×DP2 wurden bei derselben Workload 1944 tok/s/node und 2,0 RPS erreicht
  • Die von Wafer gemessene Blackwell-Performance lag jedoch bei 3,0 RPS bei 3192 tok/s/node, und die Prefill-Performance der MI355X war vergleichsweise langsam
  • Ein wichtiger Grund war, dass fp4-MoE von GLM-5.2 im sglang-Image stillschweigend auf einen langsamen heuristischen FlyDSL-Fallback zurückfiel
    • aiter stellt nur für den a8w8/fp8-Pfad getunte Konfigurationen bereit
    • Wafer tunte die MoE-Kernel-Auswahl direkt für die fp4-Shapes von GLM
    • Die Ziel-Shapes waren model_dim 6144, moe_inter 2048, E=256, topk=8
  • Durch dieses Tuning erreichte der aggregierte Durchsatz 2626 tok/s/node und 2,4 RPS

Was nötig ist, um auf AMD SOTA-Performance zu erzielen

  • Der Weg zum besten Kosten-Performance-Verhältnis auf MI355X war mit etwas Reibung verbunden, wurde aber nicht als besonders schwierig bewertet
  • Anders als bei der Arbeit an Qwen3.5 397B wurden diesmal keine Custom Kernel geschrieben
  • Diese Untersuchung berücksichtigte keine Multi-Node-Performance, doch Single-Node-Deployments sind in realen Umgebungen weiterhin weit verbreitet
  • Das Erzielen von SOTA-Performance auf AMD wird zunehmend weniger zu einer Frage der Software selbst als zu einer Support-Frage
  • Das Fazit lautet, dass der CUDA-Moat in Echtzeit schwächer wird

1 Kommentare

 
GN⁺ 4 시간 전
Hacker-News-Kommentare
  • Ich wünschte, bei solchen Vergleichen würde auch Performance pro Watt als Kennzahl einbezogen. Ich möchte wissen, wo AMD bei den Kosten im Verhältnis zur tatsächlichen Leistung steht.
    Wenn man mit Unternehmen spricht, die Rechenzentren außerhalb der USA bauen wollen, heißt es, dass es schwierig ist, Nvidia-Kapazitäten in ausreichendem Umfang zu sichern.
    Wenn AMD bei der Performance pro Watt konkurrenzfähig ist und auch der Software-Support insgesamt verlässlich ist, ist das außerhalb der USA ziemlich wichtig, weil Strom dort oft vergleichsweise teuer ist.
    Wenn AMD kleinere Rechenzentren zu einem vernünftigen Preis ermöglicht, könnte AMD in Regionen mit begrenzter Nvidia-Verfügbarkeit Teil des Stacks werden.
    Allerdings weiß ich nicht genau, wie es tatsächlich um die Beschaffung von AMD-GPUs steht, und abgesehen von Wafer in den USA und ein paar anderen Unternehmen habe ich kaum Firmen gesehen, die AMD nutzen; vielleicht stecke ich also einfach in einer Nvidia-Blase.

    • Ein DGX B200 kostet grob 500.000 Dollar und verbraucht etwa 14 kW.
      Wenn man annimmt, dass er acht Jahre lang durchgehend zu 100 % läuft, sind das etwa 1 GWh; selbst an Orten mit hohen Strompreisen wie Deutschland liegt das bei ungefähr 100.000 Euro und ist damit, über acht Jahre gerechnet, im Vergleich zu den anfänglichen Hardwarekosten von 500.000 Dollar nicht besonders viel.
      Das eigentliche Problem des hohen Stromverbrauchs sind weniger die Stromkosten als vielmehr die Grenze der Stromversorgung, die man ins Rechenzentrum hineinbekommt. Eine effizientere Konfiguration ist deshalb gut, weil man innerhalb der begrenzten Anschlussleistung mehr Hardware unterbringen kann.
    • Es gibt einige Orte, die AMD nutzen, und noch mehr, die damit zu experimentieren begonnen haben. Allerdings hat AMD in diesem Bereich über lange Zeit enttäuscht, daher bin ich vorsichtig damit, optimistisch zu sein, dass nun endlich Wettbewerb entsteht.
      Der Markt braucht wirklich einen ernsthaften Konkurrenten zu Nvidia, besonders bei Performance/Watt.
    • Meta nutzt AMD: https://www.amd.com/en/newsroom/press-releases/2026-2-24-amd...
      OpenAI ebenfalls: https://www.amd.com/en/newsroom/press-releases/2025-10-6-amd...
    • Man sollte auch nicht vergessen, dass AMD in den vergangenen Jahren die Hardware-Seite von Videospielkonsolen praktisch dominiert hat. Es gibt auch keine Anzeichen, dass das unmittelbar endet.
    • Normalerweise haben Unternehmen, die von Nvidia nicht vollständig beliefert werden können, zumindest einige AMD-GPUs.
  • Cool, aber in der Praxis ist FP4-Quantisierung nur sehr selten praktisch verlustfrei. Viele Anbieter werben bei Kimi und GLM mit hohen Tokens pro Sekunde, aber das Modell wird funktional so stark eingeschränkt, dass es qualitativ nicht mehr annähernd an die Spitze herankommt.
    Ich wünschte, das wäre nicht so.

    • Kimi verwendet INT4 als Standardformat, daher gibt es bei diesem Modell kein Konzept von „besser als 4-Bit-Präzision“.
      Das unterscheidet sich von GLM, wo 16-Bit-Präzision der Standard ist und 8 Bit ebenfalls häufig genutzt werden.
    • MI355X kann FP6-Operationen mit derselben Geschwindigkeit wie FP4 ausführen. Das ist eine Besonderheit von AMD.
      Daher sollten Leute eine MXFP6-Quantisierung entwickeln, die nahezu verlustfrei ist und bei der Performance viel näher an FP4 als an FP8 liegt.
    • Behauptet Nvidia nicht ebenfalls, dass NVFP4 verlustfrei sei?
      Ich habe von Nvidia nach NVFP4 konvertierte Modelle außer GLM 5.2 nicht ausführlich getestet, aber aus meiner Sicht sah es okay aus.
      Meine eigenen Ergebnisse waren je nach Modell ziemlich uneinheitlich.
    • Das ist mir auch als Erstes aufgefallen.
    • Aus der Erinnerung waren es etwa 96–98 % der Genauigkeit.
  • Ich dachte, es würde um einen Weg gehen, wie die Verbesserung schneller und günstiger wird, aber in diesem Artikel scheint die quantisierte Version zum selben Preis wie die Vollversion angeboten zu werden, während die schnelle Version deutlich teurer verkauft wird.

  • Ist das nicht fast selbstverständlich? Performance pro Dollar sollte sich wie eine Ratsche nur in eine Richtung verbessern. Wie sollte etwas Teureres etwas Günstigeres ersetzen?

  • Ich finde, es sollte illegal sein, solche Überschriften zu verwenden, ohne die Quantisierungsmethode anzugeben.

    • Es ist MXFP4.
    • Ich würde auch gern verbieten, „Why this matters“ in Überschriften zu schreiben.
    • Ein guter Filter ist zu prüfen, ob die Domain auf .ai endet. Wenn ja, ist die Wahrscheinlichkeit sehr hoch, dass es sich um Low-Effort-, Clickbait-, oberflächliche, nutzlose oder betrügerische Inhalte handelt.
  • In-Memory-Computing und neuromorphe Paradigmen dürften diesen Trend in den kommenden zehn Jahren noch deutlich weiter vorantreiben.
    Wenn radikalere Verbesserungen aus den Laboren herauskommen, werden am Ende neue Materialien und Nanobauelemente dazukommen, und die Effizienz kann sich um mehrere Größenordnungen verbessern.
    Schon das Hochskalieren bestehender Technologien wie MRAM bietet Spielraum.

  • Beim Wechsel von fp8 zu mxfp4 gibt es einen merklichen Genauigkeitsverlust.

    • Wafer hat nur wenige Wochen nach dem Start seinen eigenen Flaggschiff-Coding-Tarif Wafer Pass eingestellt und musste sogar anteilig erstatten.
      Trotzdem rühmen sie sich damit, die Kosten durch Quantisierung weiter gesenkt zu haben, obwohl die Implementierung offensichtlich unzureichend ist.
      [1] https://www.ycombinator.com/launches/Q9i-wafer-pass-flat-rat...
    • Und dennoch haben sie es irgendwie als „verlustfrei“ bezeichnet.
  • Das ist kein neues Phänomen. Performance pro Dollar verbessert sich seit etwa 1900 ziemlich stetig exponentiell.
    1900–2010: https://www.thekurzweillibrary.com/exponential-growth-of-com...
    1939–2023: https://medium.com/@timventura/kurzweils-law-for-the-ai-age-...

  • Dass es mit Blackwell konkurriert, ist nicht überraschend. Rubin ist bei Inferenz fünfmal schneller als Blackwell, und Blackwell ist die letzte Generation, die Nvidia nicht speziell für Inferenz optimiert hat.
    Sagt mir gern, falls ich etwas übersehe.

    • Es ist sehr unklar, was an Rubin besonders inferenzoptimiert sein soll.
      Man sieht eine disaggregierte Konfiguration, bei der Prefill- und Decoding-Nodes getrennt sind, aber ich weiß nicht, was es darüber hinaus gibt.
    • Wenn Inferenz durch Speicherbandbreite begrenzt ist, wie kann man sie dann fünfmal schneller machen? Die fünffache Speicherbandbreite eines H100 zu erreichen, wirkt physikalisch schwierig.
  • Besonders dann, wenn mehrere Währungen schwächer werden.