Benutzerdefinierte llama.cpp-Backend verlagert LLM-Matrixmultiplikation auf AMD XDNA2 NPU in Ryzen AI MAX 385

Benutzerdefiniertes Backend für AMD XDNA2 NPU-Auslagerung

Ein Entwickler hat ein benutzerdefiniertes llama.cpp-Backend erstellt, das GEMM-Operationen direkt an den AMD XDNA2 NPU auf Ryzen AI MAX 385 (Strix Halo) weiterleitet. Dieser Ansatz vermeidet die Nutzung der iGPU und Konflikte im gemeinsamen Speicher.

Hardware- und Softwarekonfiguration

Modell: Meta-Llama-3.1-8B-Instruct Q4_K_M

Hardware: Ryzen AI MAX 385, CachyOS 6.19, amdxdna-Treiber, XRT 2.21.75

Leistungsergebnisse

• Vulkan Prefill + NPU-Dekodierung: 930 t/s Prefill (pp512), 43,7 t/s Dekodierung (tg64), 41,5W durchschnittliche Leistung, 0,947 J/tok
• Nur Vulkan: 833 t/s Prefill, 41,6 t/s Dekodierung, 52,2W durchschnittliche Leistung, 1,3 J/tok
• Nur CPU: 4,6 t/s Prefill, 3,76 t/s Dekodierung

Der NPU-Dekodierungspfad spart im Vergleich zu reinem Vulkan etwa 10W, während der Dekodierungsdurchsatz gleich bleibt (und ihn sogar leicht übertrifft), da die iGPU für andere Aufgaben frei bleibt.

Technischer Stack

• Kernel: mlir-aie xclbins (Xilinx/mlir-aie, Apache 2.0)
• Laufzeitverteilung: XRT 2.21.75
• Basis: Fork von ggml-org/llama.cpp (MIT)
• Kernel-Routing: 4 xclbin-Slots, die verschiedene K-Dimension-Tiles abdecken, mit MIN_N/MAX_N-Routing zur Auswahl des passenden Kernels zur Laufzeit

Untersuchung der Leistungsgrenze

Der Entwickler versuchte, über 43,7 t/s Dekodierung hinauszugehen, mit mehreren Ansätzen:

• Batch-Sweep N=1..64: Keine Verbesserung (flache Leistung)
• Int4-Doppelquantisierung: Zerstörte SNR (44,8 → 19,7 dB) - Sackgasse
• Kaskadenauslagerung: Von AMD-Dokumentation ausgeschlossen
• Spekulative Dekodierung mit Llama-3.2-1B-Entwurf: 44% Akzeptanzrate, 212 t/s Entwurf, aber kein effektiver Gewinn

Das Fehlen einer Verbesserung durch spekulative Dekodierung (die normalerweise bei 44% Akzeptanzrate Gewinne bringt) deutet darauf hin, dass der Engpass die LPDDR5-Bandbreite ist, nicht die Rechenleistung. Der NPU stößt bereits an die Speichergrenze, was 43,7 t/s zur Obergrenze für dieses Modell auf dieser Hardware macht.

Projektlinks

• GitHub: https://github.com/BrandedTamarasu-glitch/OllamaAMDNPU
• Changelog: https://brandedtamarasu-glitch.github.io/OllamaAMDNPU/xdna-npu/

Das Projekt wurde mit Claude Sonnet 4.6 / Claude Code erstellt, offengelegt für Reproduzierbarkeit. Der Entwickler sucht Feedback von anderen, die Strix Halo oder Phoenix mit dem amdxdna-Treiber betreiben, um den Dekodierungsdurchsatz bei vergleichbaren Quantisierungen zu vergleichen und festzustellen, ob andere XDNA2-Konfigurationen auf dieselbe Leistungsgrenze stoßen.