Kimi K3 auf AMD MI355X: Besser Performance-per-Dollar als B300

Die Ausgangslage

Kimi K3 ist mit 2.8 Billionen Parametern das größte Open-Source-Modell das aktuell existiert. Es braucht über 1.5 TB VRAM — bevor der KV-Cache für 1M Token Kontext überhaupt anfängt. Nicht einmal ein B200-Node (8 GPUs) kann K3 fassen. Bleiben zwei Optionen: B300-Node mit 288GB VRAM pro GPU, oder zwei B200-Nodes (TP16).

Oder — AMD’s MI355X, die ebenfalls 288GB HBM3 pro GPU hat und etwa 2.4× günstiger pro GPU ist als eine B300.

Die Zahlen

Wafer hat K3 auf einer 8× MI355X-Node (TP8) betrieben und mit B200 (2 Nodes, TP16) und B300 verglichen:

Bei ~$2.50/GPU-hr für MI355X vs $6.00 für B300 und $4.25 für B200 ist der Performance-per-Dollar-Vorteil dramatisch — 48 tok/s pro Dollar vs 33 bei B300 und nur 7 bei B200.

Die Engineering-Aufgabe

AMD lieferte Day-0-Support für K3, aber es gab dennoch Framework-Bugs. Der interessanteste: Speculative Decoding mit RadixArks DSpark-Draft-Modell schoss den Scheduler auf ROCm ab — eine NameError-Exception wegen einer fehlenden top_k_renorm_prob-Funktion die auf CUDA existiert, auf ROCm aber nur als Triton-Alias definiert war. Die Lösung war ein paar Zeilen PyTorch — kein Custom Kernel nötig.

Ein zweites Problem: Der schnelle AITER MLA-Prefill-Kernel lud nicht wegen einer Shape-Mismatch (12 Heads pro Rank, aber der Kernel erwartet 4/8/16). Die Lösung: Zero-Pad 12→16, Kernel ausführen, echte 12 Heads aus dem Output extrahieren. Prefill beschleunigte sich um 2-3×.

Fazit

Wafer’s Fazit ist knapp: “Is the CUDA moat dead?” Die MI355X brauchte weniger Custom-Engineering als GLM5.2 auf AMD, kein einziger Custom-Kernel war nötig, und AMD’s Fokus auf HBM-Capacity statt Compute zahlt sich bei Modellen dieser Größe konkret aus. B300 bleibt schneller im Aggregate-Throughput — aber bei 2.4× des Preises reicht das nicht.

Quelle: Wafer: Running Kimi K3 on MI355X