カスタムllama.cppバックエンド、Ryzen AI MAX 385のAMD XDNA2 NPUにLLM行列乗算をオフロード

AMD XDNA2 NPU オフロードのためのカスタムバックエンド

開発者が、Ryzen AI MAX 385 (Strix Halo) の AMD XDNA2 NPU に GEMM 演算を直接ディスパッチするカスタム llama.cpp バックエンドを作成しました。このアプローチにより、iGPU の使用や共有メモリの競合を回避しています。

ハードウェアとソフトウェア構成

モデル: Meta-Llama-3.1-8B-Instruct Q4_K_M

ハードウェア: Ryzen AI MAX 385, CachyOS 6.19, amdxdna ドライバ, XRT 2.21.75

パフォーマンス結果

• Vulkan プリフィル + NPU デコード: 930 t/s プリフィル (pp512), 43.7 t/s デコード (tg64), 41.5W 平均電力, 0.947 J/tok
• Vulkan のみ: 833 t/s プリフィル, 41.6 t/s デコード, 52.2W 平均電力, 1.3 J/tok
• CPU のみ: 4.6 t/s プリフィル, 3.76 t/s デコード

NPU デコードパスは、Vulkan のみの場合と比較して約 10W を節約しながら、デコードスループットを同等（わずかに上回る）に維持しています。これにより、iGPU は他の作業のために空いたままになります。

技術スタック

• カーネル: mlir-aie xclbins (Xilinx/mlir-aie, Apache 2.0)
• ランタイムディスパッチ: XRT 2.21.75
• ベース: ggml-org/llama.cpp のフォーク (MIT)
• カーネルルーティング: 異なる K 次元タイルをカバーする 4 つの xclbin スロットで、MIN_N/MAX_N ルーティングにより実行時に適切なカーネルを選択

パフォーマンス上限の調査

開発者は、43.7 t/s を超えるデコード速度を目指して以下のアプローチを試みました：

• バッチスイープ N=1..64: 改善なし（性能は平坦）
• Int4 ダブル量子化: SNR が低下 (44.8 → 19.7 dB) - 行き止まり
• カスケードオフロード: AMD のドキュメントにより除外
• Llama-3.2-1B ドラフトによる推測的デコード: 44% の受容率、212 t/s のドラフト速度だが、実質的な向上はゼロ

推測的デコードからの改善がないこと（通常は 44% の受容率で向上が見られる）は、ボトルネックが計算ではなく LPDDR5 帯域幅にあることを示しています。NPU はすでにメモリの壁に達しており、43.7 t/s がこのハードウェア上でのこのモデルの上限となっています。

プロジェクトリンク

• GitHub: https://github.com/BrandedTamarasu-glitch/OllamaAMDNPU
• 変更履歴: https://brandedtamarasu-glitch.github.io/OllamaAMDNPU/xdna-npu/

このプロジェクトは Claude Sonnet 4.6 / Claude Code で構築され、再現性のために公開されています。開発者は、Strix Halo または Phoenix で amdxdna ドライバを実行している他のユーザーからのフィードバックを求め、同等の量子化モデルでのデコードスループットを比較し、他の XDNA2 構成でも同じパフォーマンス上限に直面するかどうかを確認したいと考えています。