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.
📖 Read the full source: r/LocalLLaMA
👀 Siehe auch
CogniLayer: Ein MCP-Server für persistenten Speicher in Claude Code
CogniLayer ist ein Open-Source-MCP-Server, der Claude Code mit persistenter Speicherung über Sitzungen hinweg versorgt, indem er eine SQLite-Datenbank mit FTS5-Volltextsuche und Vektoreinbettungen nutzt. Er löst das Problem, dass Claude den Projektkontext zwischen Sitzungen vergisst.
Claudebin: Exportieren und Teilen Ihrer Claude-Code-Sitzungen
Claudebin ermöglicht es Ihnen, gesamte Claude-Code-Sitzungen zu exportieren, wodurch sie über eine einzige URL teilbar und fortsetzbar werden.
JetBrains stellt Plugin für modernen Go-Code mit den KI-Agenten Junie und Claude Code vor.
JetBrains hat ein Plugin für die KI-Agenten Junie und Claude Code veröffentlicht, das ihre Fähigkeit verbessert, modernen Go-Code zu erzeugen, indem es die neuesten Go-Funktionen und Best Practices berücksichtigt.
Queuelo: Eine schlanke Genehmigungs-API für LLM-Agenten
Queuelo ist eine einfache API-Schicht, die es LLM-Agenten ermöglicht, vor irreversiblen Aktionen zu pausieren. Agenten senden POST-Anfragen für Aktionen, Sie werden benachrichtigt, um diese zu genehmigen oder abzulehnen, und der Agent erhält die Antwort per Webhook.