Ryzen AI MAX 385（Strix Halo）の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 2.21.75
結果
| バックエンド | プリフェル（t/s pp512） | デコード（t/s tg64） | 平均消費電力 | J/tok |
|---|---|---|---|---|
| Vulkanプリフェル + NPUデコード | 930 | 43.7 | 41.5 W | 0.947 |
| Vulkanのみ | 833 | 41.6 | 52.2 W | 1.3 |
| CPUのみ | 4.6 | 3.76 | — | — |
NPUデコード経路は、他の処理のためにiGPUを空けられるため、Vulkanのみと同等（わずかに上回る）デコードスループットを維持しつつ、約10W節電できます。
スタック
- カーネル：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で作成 — 再現性に関係するため開示しています。
amdxdnaドライバでStrix HaloまたはPhoenixを動かしている人はいますか？同等の量子化で、どれくらいのデコードスループットが出ていますか？他のXDNA2構成でも同じ壁に当たるのか、それとも私が見つけられていない余地（ヘッドルーム）があるのかが気になります。
[リンク] [コメント]
