AMD Ryzen AI 9 HX 370 で NPU と iGPU の LLM 推論を試す（CachyOS / Linux）

環境: MINISFORUM HX370（AMD Ryzen AI 9 HX 370, 64GB DDR5, CachyOS Linux, Kernel 6.19.7-cachyos）

はじめに

Reddit の r/MiniPCs に Minisforum AI X1 Pro 470 の詳細なレビューが投稿された。同じ AMD Strix Point アーキテクチャを搭載する HX 370 を使っている身としては見逃せない内容で、特に興味を引いたのが「Linux 上で iGPU と NPU の両方を使って LLM を動かす」という部分だった。

記事の著者は Windows 環境でのベンチマークを中心に紹介しているが、コメント欄でも指摘されている通り NPU のトークン生成速度（t/s）が載っていない。そこで同じ構成を CachyOS（Linux）上で再現し、NPU と iGPU の両方を実際に動かして比較してみた。

試したのは以下の 3 点だ。

iGPU（Radeon 890M）+ llama.cpp Vulkan バックエンドによる LLM 推論
NPU（XDNA2）+ FastFlowLM による LLM 推論（Linux サポートは 2026年3月に追加されたばかり）
同一モデル（GPT-OSS 20B）での NPU vs iGPU ベンチマーク比較

結論から言うと、速度は iGPU が圧倒的に優位だが、消費電力では NPU が約 10 倍以上効率的という興味深い結果になった。

アーキテクチャを理解する

セットアップに入る前に、このチップのメモリ構造を理解しておくと後のパラメータ調整の意味がわかりやすくなる。

UMA（Unified Memory Architecture）

HX 370 は物理的に独立した VRAM チップを持たず、CPU と GPU がシステム RAM を共有する UMA 構成だ。一般的なディスクリート GPU との最大の違いはここにある。

RAM 64GB
├── BIOS予約: 1GB（固定・常にGPU専用）
└── 残り63GB: CPU ＋ GTT で動的共有

GTT（Graphics Translation Table） というカーネルの仕組みを使うことで、GPU が必要なときだけシステム RAM を動的に VRAM として借りることができる。つまり BIOS での VRAM 予約を最小限（1GB）に抑えて GTT に任せるのが LLM 用途では最も合理的な設定だ。

実際にこの構成で動かすと、llama-bench --list-devices で 50GB 超の “VRAM” が見えるようになる。64GB の RAM を持つマシンで 30B 級のモデルをメモリに丸ごと乗せられるのは UMA ならではの強みだ。

NPU のメモリ構造

XDNA2 NPU はオンチップの SRAM（L2）を 4MB 持っているが、これはあくまで演算用のバッファであり、LLM のモデル重みはシステム RAM に置く。NPU はメモリをページアウトされないようにロック（memlock）する必要があるため、ulimit -l unlimited の設定が必須になる。ここを忘れると mmap failed: Resource temporarily unavailable というエラーで詰まる。

セットアップ手順

1. カーネルパラメータの設定

CachyOS は systemd-boot ではなく Limine を使っている

多くのガイドでは /boot/loader/entries/ を編集するように書かれているが、CachyOS の標準ブートローダーは Limine だ。bootctl status を実行しても systemd-boot not installed と表示される。

カーネルパラメータの永続設定は /etc/default/limine で行う。ここに書いた内容が次回のスナップショット生成時から自動的に limine.conf に反映される。

sudo nano /etc/default/limine

以下の行を追記する：

KERNEL_CMDLINE[default]+="amd_iommu=on iommu=pt"

反映：

sudo limine-update
sudo reboot

確認：

cat /proc/cmdline
# amd_iommu=on iommu=pt ... が含まれていれば OK

パラメータの選び方

パラメータ	目的
`amd_iommu=on`	IOMMU を有効化（NPU 検出に必要）
`iommu=pt`	パススルーモード（iGPU のオーバーヘッドを最小化）

ここで重要な注意点がある。元記事では amd_iommu=off が推奨されているが、Linux で NPU を使う場合はこの設定が致命的だ。amd_iommu=off にすると /dev/accel/accel0 が存在しなくなり、NPU が完全に使えなくなる。iommu=pt（パススルーモード）を使えば、NPU も正常に認識しつつ iGPU のオーバーヘッドも抑えられる。実際に計測した範囲では、iGPU の LLM 推論速度への影響は 5〜10% 程度にとどまる。

また、amdttm.pages_limit や amdttm.page_pool_size の大きな値を設定すると OS から見える RAM が激減するという罠にもハマった。たとえば amdttm.pages_limit=33554432（128GB 相当）を 64GB のマシンに設定すると、OS から見える RAM が 16GB 程度まで減ってしまう。GTT はカーネルが自動で管理してくれるため、こうしたパラメータは不要だ。

BIOS の VRAM 設定

BIOS（起動時に Del キー）で VRAM を 1GB に設定する。これにより残り 63GB を GTT として最大限活用できる。

$ sudo dmesg | grep -i vram
amdgpu: VRAM: 1024M（BIOS固定予約）

2. iGPU（llama.cpp Vulkan）のセットアップ

Vulkan ドライバーの確認

vulkaninfo --summary | grep -E "deviceName|driverName"
# deviceName = AMD Radeon 890M Graphics (RADV STRIX1)
# driverName = radv

Mesa RADV は CachyOS に標準搭載されており、追加インストールは不要だ。AMD 純正の AMDVLK より RADV の方がパフォーマンスが高いことが多く、llama.cpp の Vulkan バックエンドとの相性も良い。

llama.cpp のビルド（Vulkan バックエンド）

ROCm バックエンドでもビルドできるが、gfx1150（RDNA 3.5）は公式サポート外のため不安定だった。Vulkan バックエンドの方が確実に動く。

git clone https://github.com/ggerganov/llama.cpp ~/src/llama.cpp
cd ~/src/llama.cpp
cmake -B build-vulkan -DGGML_VULKAN=ON -DGGML_HIP=OFF
cmake --build build-vulkan --config Release -j$(nproc)

ビルド後のデバイス確認：

cd build-vulkan/bin
./llama-bench --list-devices
# ROCm0: AMD Radeon 890M Graphics (31447 MiB, 54122 MiB free)

GTT によって 50GB 超の VRAM が利用可能な状態になっている。

3. NPU（FastFlowLM）のセットアップ

FastFlowLM の Linux サポートは 2026年3月に追加されたばかりで、まだ手順が整備されていない部分も多い。実際にいくつかの壁にぶつかったので順番に記録しておく。

必要なパッケージのインストール

sudo pacman -S extra/xrt extra/xrt-plugin-amdxdna
sudo pacman -S extra/rust
sudo pacman -S cmake ninja

CachyOS の cachyos-extra-znver4 リポジトリの最適化版パッケージは 2026年3月時点で 404 エラーになるものがある。extra/ を明示的に指定するとインストールできる。

memlock の設定

NPU はメモリをロックする必要があるため、デフォルトの 8192KB では動かない。

sudo nano /etc/security/limits.conf

末尾に追記：

* - memlock unlimited

ログアウトだけでは反映されない。再起動が必要。

ulimit -l
# unlimited になっていることを確認

NPU ファームウェアの更新

ここが最大のハマりポイントだった。linux-firmware は最新版が入っているのに、FastFlowLM が「FW バージョンが古い」と言って動かない。原因はシンボリックリンクだ。

ls -la /usr/lib/firmware/amdnpu/17f0_10/
# npu.sbin.zst -> npu.sbin.1.0.0.63.zst  ← 古い方を指している
# npu.sbin.1.1.2.64.zst                  ← 新しい方も存在している

新しい方に向け直す：

sudo ln -sf npu.sbin.1.1.2.64.zst /usr/lib/firmware/amdnpu/17f0_10/npu.sbin.zst

ただしこれだけでは解決しない場合がある。古いカーネル内蔵の amdxdna ドライバーでは Incompatible firmware protocol major 7 エラーが出る。その場合は AUR の amdxdna-dkms をインストールして新しいドライバーに更新する必要がある。

yay -S amdxdna-dkms
sudo reboot

FastFlowLM のビルドとインストール

Linux 版はまだバイナリリリースがないため、ソースからビルドする。

git clone https://github.com/FastFlowLM/FastFlowLM.git ~/src/FastFlowLM
cd ~/src/FastFlowLM
git submodule update --init --recursive
cmake -S src --preset linux-default
ninja -C src/build -j$(nproc)
sudo cmake --install src/build

動作確認

flm validate
# [Linux]  Kernel: 6.19.7-1-cachyos
# [Linux]  NPU: /dev/accel/accel0 with 8 columns
# [Linux]  NPU FW Version: 1.1.2.64
# [Linux]  Memlock Limit: infinity

ERROR が出なければセットアップ完了だ。

ベンチマーク結果

NPU（FastFlowLM）

flm pull llama3.2:1b
flm run llama3.2:1b --verbose

モデル	Prefill (t/s)	Decoding (t/s)
Llama3.2 1B	~80	60
Gemma3 4B	13	18
Qwen3.5 4B	14	12
GPT-OSS 20B (MoE)	19	19

興味深いのは GPT-OSS 20B の結果だ。20B のモデルなのに 4B モデルより速い。これは MoE（Mixture of Experts）アーキテクチャの効果で、実際に使われるパラメータ数は 3.6B 程度に抑えられている。FastFlowLM の公式ベンチマーク（Kraken Point で 19 tps）とほぼ一致しており、Strix Point（HX 370）は Kraken Point と同等以上の NPU 性能を持つことが確認できた。

また、Llama3.2 1B の 60 t/s はかなり快適な速度で、軽量なタスクに使うなら十分実用的だ。

iGPU（llama.cpp Vulkan）

cd ~/src/llama.cpp/build-vulkan/bin
./llama-bench -m ~/src/llama.cpp/models/gpt-oss-20b-Q4_K_M.gguf -p 512 -n 128 -ngl 99

モデル	pp512 (t/s)	tg128 (t/s)
Qwen3.5 35B A3B Q8_0	262	16
GPT-OSS 20B Q4_K_M	511	30

GPT-OSS 20B の pp512 が 511 t/s というのは驚異的な数字だ。MoE の特性上プロンプト処理が非常に速く、長い文章を入力するようなタスクでは体感的にも速さを感じられる。

NPU vs iGPU 比較（GPT-OSS 20B）

同一モデルで両バックエンドを比較した結果がこちらだ。

バックエンド	Prefill	Decoding	消費電力
NPU（FastFlowLM）	19 t/s	19 t/s	< 2W
iGPU（Vulkan）	511 t/s	30 t/s	~25W

速度だけ見ると iGPU の圧勝だ。Prefill は約 27 倍、Decoding は約 1.6 倍の差がある。しかし消費電力を加味すると話が変わってくる。NPU はトークン生成中に CPU + NPU 合計で 2W 以下で動作するのに対し、iGPU は 25W 前後を消費する。常時起動しておくバックグラウンドサービスや、ミニ PC を 24 時間稼働させるような用途では NPU の省エネ性能が大きなアドバンテージになる。

使い分けの指針

今回の結果を踏まえると、用途によって使い分けるのがベストだという結論になった。

用途	推奨
応答速度重視（コーディング支援、Claude Code など）	iGPU（Vulkan）
常時起動・バックグラウンド処理（エージェント常駐など）	NPU（FastFlowLM）
大規模モデル（20B〜30B）	iGPU（GTT で大量メモリ利用可）
省電力・24 時間稼働	NPU

個人的には OpenClaw（自宅の AI エージェント）のバックエンドとして NPU を常時起動しておき、Claude Code を使った本格的な作業では iGPU を使うという分担が現実的に思える。

トラブルシューティングまとめ

今回のセットアップで実際にハマったポイントをまとめておく。同じ環境で試す人の参考になれば幸いだ。

問題	原因	解決策
`/dev/accel/accel0` が見えない	`amd_iommu=off` が設定されている	`amd_iommu=on iommu=pt` に変更して再起動
`flm validate` で FW バージョンエラー	`npu.sbin.zst` が古いバージョンを指している	シンボリックリンクを `npu.sbin.1.1.2.64.zst` に変更して再起動
`Incompatible firmware protocol major 7`	カーネル内蔵 amdxdna ドライバーが古い	`yay -S amdxdna-dkms` でドライバーを更新
`mmap failed: Resource temporarily unavailable`	memlock のデフォルト値が低い（8192KB）	`/etc/security/limits.conf` に `* - memlock unlimited` を追加して再起動
OS から見える RAM が激減（64GB → 16GB）	`amdttm.pages_limit` の値が大きすぎる	パラメータを削除してカーネルに任せる
`limine.conf` に反映されない	`limine-install` は EFI バイナリのみ更新	`sudo limine-update` を実行
CachyOS で pacman が 404 エラー	`cachyos-extra-znver4` のパッケージがミラーにない	`extra/パッケージ名` と明示的にリポジトリを指定

おわりに

FastFlowLM の Linux 対応はまだ始まったばかりで、インストール手順の整備も途上だ。今回は複数のエラーにぶつかりながらも、最終的には NPU と iGPU の両方を同一マシン上で動かすことができた。

「NPU は Copilot 機能にしか使えない」という時代は終わりつつある。常時 2W 以下で 20B 級のモデルが動くという事実は、自宅 AI インフラの設計に新しい選択肢をもたらしてくれる。