Ryzen AI の NPU を使わなかった理由 Ryzen AI の NPU を使わなかった理由

はじめに

この連載でローカルLLM環境を作り直してきましたが、 一度も触っていない部品があります。NPU です。

Ryzen AI 9 HX 370 には XDNA2 の NPU が載っていて、50 TOPS を謳っています。 第2回で Vulkan（iGPU）を選んだきり、 NPU は完全に空白のままでした。

せっかく積んでいるので、使えるのか調べました。 結論は使いませんでした。インストーラをダウンロードしたところで止めています。

ハードウェアは正常

まず確認しました。

NPU Compute Accelerator Device   Status: OK
ドライバ: AMD 32.0.20102.3930（2026年5月7日）

デバイスもドライバも問題ありません。使えない理由はハード側にはないわけです。

壁 1: llama.cpp に NPU バックエンドが無い

最初の壁がこれでした。

いま使っている llama.cpp には、NPU を叩く口がそもそもありません。 Vulkan、ROCm、CUDA、CPU はありますが、XDNA2 向けのバックエンドは存在しません。 （XDNA1 向けの有志フォークはあるようですが、うちは XDNA2 です。）

つまり NPU を使うなら、いまのスタックを丸ごと別のものに替える必要があります。

選択肢: FastFlowLM

NPU で LLM を動かす選択肢として出てきたのが FastFlowLM でした。 AMD の GitHub 組織（ROCm）から配布されている、Ryzen AI NPU 専用のランタイムです。

• XDNA2 全系統（Strix / Strix Halo / Kraken / Gorgon Point）対応
• OpenAI 互換 API あり
• 最大 256k コンテキスト
• Windows は MSI で 30 MB

OpenAI 互換 API があるのは重要でした。 第3回で作ったレビュアーの仕組みが、 ほぼそのまま流用できることになります。

そしてモデルカタログを見て、期待が上がりました。

Qwen3.6-35B-A3B が載っています。 いま主役として使っているモデルそのものです。

壁 2: うちのチップで動く保証がない

カタログにある、と、自分の石で動くは別の話でした。

公開されているベンチマークは Ryzen AI 7 350（Kraken Point） と Ryzen AI MAX+ 395（Strix Halo） のみ。 うちの HX 370（Strix Point）は入っていません。

そして探したら、こういう Issue が見つかりました。

Support Qwen3.6-35B-A3B on Ryzen AI HX 370 / XDNA2（#547） ラベル: model request 2026年5月13日に作成、メンテナからの返答なし

4 か月以上、動きがありません。

NPU 向けモデルはチップごとに xclbin（回路構成）が要ります。 同じ XDNA2 だから動くだろう、とは言えないのがこの世界です。

壁 3: 動いたとしても、iGPU より遅い

仮に動いたとして、速くなるのかを確かめました。

深度	iGPU（この機体で実測）	NPU（Ryzen AI 7 350 の公開値）
浅い（〜1k）	18.57	17.48
深い（32k）	15.65	11.19

iGPU のほうが速いです。しかも深いほど差が開きます。

さらに、Strix Halo での報告では リクエストごとに固定で約 2.7 秒の TTFT（最初の1トークンまでの時間）が乗るとありました。 対話では体感に直結します。

念のため書いておくと、NPU 側はうちのチップの実測ではありません。 ただ、期待できる方向の数字が出ていないのは確かです。

壁 4: 最大の利点が、うちでは効かない

ここが決定打でした。

FastFlowLM が前面に出しているのは速度ではなく電力効率です。

< 2 W（CPU + NPU 合計）、約 25 W の GPU に対して 10 倍以上の効率

これは本物の強みです。10 倍以上の差は誤差ではありません。 バッテリー駆動のノートで LLM を常駐させるなら、これ以外の選択肢は無いでしょう。

ただしうちはミニPC で常時給電です。 机の上で電源に繋がったまま動いている機体にとって、 2 W と 25 W の差から得られる価値はほぼゼロでした。

勝っている軸が、自分の使い方では効かない。 それだけの話です。

インストーラを落として、止めた

ここまで調べたうえで、「動かないと確定させる価値はある」と考えて インストーラをダウンロードしました。

項目	結果
入手元	GitHub ROCm/FastFlowLM 公式リリース（HTTPS）
サイズ	30,491,316 バイト — API の申告値と完全一致
Authenticode 署名	無し

署名がありませんでした。

出所は AMD の GitHub 組織で、サイズも一致していて、改ざんの形跡はありません。 OSS で署名なし配布は珍しくもありません。

それでも、ここで止めました。得られるものと釣り合わなかったからです。

仮に動いたとしても iGPU より遅く、電力の利点は効かない。 つまりこの検証で得られるのは「動かないことの確認」か 「動くが使わないことの確認」のどちらかです。 そのために、署名を検証できないバイナリを入れる理由がありませんでした。

ダウンロードしたファイルは削除し、環境は何も変えていません。

やるとしたらの条件

永久にない、とは思っていません。条件が変わればやります。

llama.cpp に XDNA2 バックエンドが入ったとき — スタックを替えずに済むなら、 試すコストが一気に下がります。

HX 370 が公式サポートに入ったとき — Issue #547 が解決すれば、 「動く保証がない」という最大の不確定要素が消えます。

バッテリー駆動の機体で使うようになったとき — 電力効率の 10 倍差が、 そのまま価値になります。

NPU と iGPU を併走させたくなったとき — iGPU で 35B を回しながら、 NPU で軽い分類や要約を同時に処理する。これは「今の困りごとの解決」ではなく 「新しい使い方を作る」話なので、必要になってからです。

まとめ

• NPU のハードとドライバは正常。使えない理由はハード側には無い
• llama.cpp に NPU バックエンドが無いので、今のスタックからは手が出ない
• FastFlowLM なら可能だが、HX 370 の対応要望は 4 か月未回答
• 動いたとしてもiGPU より遅い（32k 深度で 15.65 対 11.19）
• NPU の強みは電力効率（10 倍以上）。本物だが、据え置き機では効かない

「50 TOPS 積んでいるのに使わないのはもったいない」と思って調べ始めましたが、 もったいないのは、使わないことではなく、合わない道具に時間を使うことでした。

スペック表に載っている性能と、自分の使い方で効く性能は別物です。 この機体ではメモリ帯域がすべてを決めていて、 NPU はその軸では勝負していませんでした。