前回、同じモデルをMetal・MLX・CUDAで測り比べたとき、心に残った宿題がありました。「じゃあ、NPUはどうなの？」です。最近のPCには当たり前のようにNPUが載っていて、前回の半導体3社の回でも、Intelは「合計180 TOPS（うちNPU 50）」、AMDは「60 TOPSのNPU」と、しきりにNPUの数字を掲げていました。

これだけ推されているなら、ローカルLLMもNPUで動かせるのでは？ ——そう思って調べてみたら、なかなか意外な現実が見えてきました😳

※この記事は調査＋実測です。各社の対応状況は2026年7月時点のもので、この分野は動きが速く数か月で変わります。実測はMac（Apple M4）のNeural Engineで行いました。最新は必ず公式でご確認ください。

前回の宿題：「NPUはどうなの？」

p951では、同じ Qwen2.5-Coder-7B（Q4）を走らせて、Mac（Metal 20.6／MLX 21.1 tok/s）と Windows（CUDA 62.1 tok/s）を比べました。全部GPUの話です。一方、AI PCの宣伝で目立つのはNPUの数字。だったらNPUでもLLMが動いて、しかも省電力なのでは——と期待するのが自然な流れですよね。

まず結論：主流のツールはNPUを使っていない

先に、いちばん大事なことを書いてしまいます。

「TOPSが大きいNPUを載せたPCを買ったのに、ローカルLLMが速くならない」——この違和感の正体はここでした。前回で「TOPSが大きい＝体感が速いとは限らない」と書きましたが、そもそも使われていなかったわけです😅

もちろん「NPUでLLMがまったく動かない」という意味ではありません。各社が用意した専用の道具を使えば動きます。ただしそれは、いつものツールをそのまま使う話ではない——ここが今回のポイントです。

NPUとGPU、何が違うのか（図解）

そもそもNPUとは何者なのか。NPU（Neural Processing Unit）は、ニューラルネットワークの推論に特化した専用回路です。GPUがもともと映像処理のために作られた「なんでも並列に計算できる万能選手」なのに対し、NPUはAIの決まった計算だけを、とにかく省電力でこなす専門職。同じAI処理なら、CPUやGPUより電力効率が桁違いに良いのが持ち味です。

なぜNPUはLLMが苦手なのか

電力効率が良いなら、LLMもNPUで動かせばいいのでは？ そう思いますよね。ここには2つの壁があります。

壁①：想定しているモデルの大きさが違う。PC向けのNPUは、もともとスマホのAI処理の延長で設計されています。想定されているモデルは、せいぜい数百MB〜1GB程度。顔の検出、背景ぼかし、ノイズ除去——そういう軽い仕事のサイズ感です。ところがLLMは桁が違います。小さめの7Bでも数GB、大きなものは数十GB。最初から前提が合っていないのです。

壁②：ボトルネックが「計算」ではなく「メモリ」。これがより本質的です。LLMは文字を1つ生成するたびに、モデル全体のデータを読み出す必要があります。つまり速度を決めるのは計算力よりも「メモリからどれだけ速くデータを運べるか（メモリ帯域）」。

NPUの高いTOPSは「小さなモデルを省電力で大量に回す」ためのもので、「巨大なモデルを1文字ずつ吐き出す」用途には、そもそも向いていない——これが調べてみての理解でした。

各社のNPUとツールチェーンの現在地

とはいえ、各社とも手をこまねいてはいません。専用のツールチェーンを使えば、NPUでLLMを動かす道はあります。現在地を並べてみます。

共通して言えるのは、「モデルをそのNPU向けの形式に変換する」ひと手間が要ること。GGUFをそのまま渡せばいい llama.cpp のような手軽さは、まだありません。ONNX Runtime・OpenVINO・DirectML あたりが、その橋渡しをする標準的な道具として使われています。

面白いのはAppleの動きで、MLXが速かったように、AppleはGPU側を強化する方向に見えます。M5世代では各GPUコアにAI用の加速器を入れており、「NPUに全部任せる」のとは違う道を選んでいるようです。

実際に測ってみた：NPUを最大限に使うには

ここまでは調べた話。でも「じゃあNPUを本気で使ったら、どれくらい効くの？」が気になりますよね。というわけで、手元のMac（Apple M4）のNeural Engineで実際に測ってみました。

やり方はシンプルで、PyTorchで作ったモデルをCore MLに変換し、実行先を切り替えて同じ推論を回すだけ。題材は2つ——CNN（画像系＝NPUが本来想定している仕事）とTransformer（LLMに近い形）です。

なぜ、このやり方で確かめられるのか

「実行先を切り替えるだけ」で本当に分かるの？と思われるかもしれません。ここが今回の肝なので、考え方を説明します。

ポイントは、これが対照実験になっていること。モデルも、重みも、入力データも、計測方法も、すべて同じまま固定して、変えるのは「どこで計算するか」だけにします。他の条件がすべて同じなら、出てきた時間差は「実行先の差」だと言い切れる——という理屈です。

それを可能にしてくれるのが、Core MLの compute_units という公式のスイッチ。「CPUだけ」「CPUとGPU」「CPUとANE（NPU）」「おまかせ」を、コード1行で指定できます。自作の計測ではなく、OSが用意した正規の切り替え口を使っているのが、この方法の信頼できるところです。

そしてもう一つ大事なのが、「ANEが使われなかったこと」も分かるという点です。CPU_AND_NE は「CPUとANEを使ってよい」という許可であって、実際にどちらで動かすかはOSが判断します。だから——

• ANEを許可した時間が、CPUだけの時間よりはっきり短い　→ ANEが働いた
• ANEを許可したのに、CPUだけとほぼ同じ時間　→ ANEに載らず、CPUに落ちた

この読み方があるおかげで、後述の「float32ではANEが使われていない」という判定ができました。速度を測っているようで、実は「どこで動いたか」を時間から逆算しているわけです😊

あわせて、計測のブレを抑えるためにウォームアップを5回してから30回測り、中央値を採用しています（初回はモデルのコンパイルが走るため極端に遅く、平均だと引きずられるので）。

import coremltools as ct

# ① モデルを Core ML に変換（★float16 がカギ）
mlmodel = ct.convert(
    traced_model,
    inputs=[ct.TensorType(name="x", shape=x.shape)],
    compute_precision=ct.precision.FLOAT16,   # ← ここが最重要
    convert_to="mlprogram",
)
mlmodel.save("model.mlpackage")

# ② 実行先を切り替えて計測する
for unit in [ct.ComputeUnit.CPU_ONLY,      # CPUのみ
             ct.ComputeUnit.CPU_AND_GPU,   # GPU
             ct.ComputeUnit.CPU_AND_NE,    # ★Neural Engine(NPU)
             ct.ComputeUnit.ALL]:          # おまかせ
    m = ct.models.MLModel("model.mlpackage", compute_units=unit)
    m.predict({"x": x})                     # 時間を測る

結果①：NPUはちゃんと速い（しかもGPUより速い）

まず float16 で、実行先だけを切り替えた結果です（中央値）。

NPUは、条件が合えばしっかり速いのが分かります。CPUの3〜3.8倍で、しかもGPUより速い。「おまかせ（ALL）」もきちんとANEを選んでくれました。ここまでは期待どおりです😊

結果②：float16でないと、NPUは動き出さない

次が、今回いちばんの発見でした。同じモデルをfloat32のまま変換すると、こうなります。

float32だと、ANEはまったく使われませんでした（CPUと同じ19.95ms）。おまかせにしても、Core MLはANEを諦めてGPUを選びます。つまり——

float16は、NPUの"どこ"に効いているのか

「精度を落とすと速くなる」と言われても、ピンと来ないですよね。実際には3か所に効いています。とくに1つ目が決定的です。

① 演算器そのものが「低精度専用」に作られている（＝これが決定的）
NPUの中身は、掛け算と足し算をひたすら並列にこなす小さな計算器を、大量に敷き詰めたものです。そしてその計算器は、float16やint8といった低い精度だけを扱えるように作られています。省電力・高密度を実現するために、あえてfloat32を扱う回路を持っていないのです。
だからfloat32のモデルを渡すと、速い遅い以前に「そもそも実行できない」。OSは仕方なくCPUかGPUへ回します。今回の「約10倍差」はNPUが10倍速くなったのではなく、float16にして初めてNPUが使われた——という話でした。

② 運ぶデータ量が半分になる
float32が1つの数値に4バイト使うのに対し、float16は2バイト。同じモデルでもやり取りするデータが半分になります。前半で書いたとおり、PC向けNPUは専用メモリを持たずシステムRAMを共有していて、メモリ帯域がボトルネックになりやすい。データが半分になれば、同じ帯域で2倍運べることになります。

③ モデルのサイズが半分になる
これは③の「サイズの崖」に直結します。float16ならモデルは半分のサイズで済むので、崖にぶつかりにくくなる。今回806MBでコンパイルが失敗しましたが、これがfloat32なら同じ構成で1.6GB相当——もっと手前で崖に落ちていた計算になります。

まとめると、float16は「NPUに入場するためのチケット」であり、同時に「荷物を半分にする工夫」でもある、ということですね😊

結果③：大きくしていくと、ある所で"崖"がある

では、モデルを大きくしていくとどうなるか。Transformerのサイズを段階的に上げて測りました（すべてfloat16）。

450MBくらいまでは、きれいに3倍前後で効き続けます。ところが806MBで、いきなり崖から落ちました。ログを見ると、理由はハッキリしていて——

MILCompilerForANE error: failed to compile ANE model using ANEF.
Error=_ANECompiler : ANECCompile() FAILED.

ANE用のコンパイル自体が失敗しているのです。その結果、ANEに載せられずフォールバックし、かえってCPUより4倍も遅くなりました。

つまずき：そのままでは変換できないことがある

もうひとつ実務的な発見。最初、TransformerをPyTorch標準の nn.MultiheadAttention で書いたら、Core MLへの変換自体が失敗しました。

ERROR - converting '_native_multi_head_attention' op

対処は、Attentionを行列積とsoftmaxで手書きに置き換えること。これで問題なく変換でき、上の結果が得られました。「NPU対応」とは、突き詰めると"使っている演算がすべて対応表に載っているか"ということ。1つでも未対応の演算が混じると、そこで変換が止まるか、その部分だけCPUに落ちて遅くなります。前半で「モデル変換のひと手間が要る」と書いたのは、まさにこういう作業でした。

まとめ：NPUを最大限に使う5か条

実測から見えた、効率よくNPUを使うためのコツです。

1. float16（以下）にする——最重要。float32では、そもそもNPUが使われない（約10倍の差）
2. モデルは数百MB級までに抑える——450MBまでは3倍速、800MB超でコンパイル失敗の崖
3. 対応している演算だけで書く——1つ未対応が混じると、変換失敗かCPU落ちで台無しになる
4. 実行先は「おまかせ（ALL）」で良い——float16にしてあれば、Core MLが自分でANEを選ぶ
5. 速さより「電力あたりの仕事量」で選ぶ——同じ処理をずっと動かすなら、NPUの省電力が効いてくる

つまりNPUは「使えない」のではなく、条件を揃えれば非常に強い。ただしその条件が、今のLLMとは噛み合っていない——というのが、測ってみての結論です。

今、NPUを存分に活かせる場面はあるのか

ここまで読むと、「NPUをフル活用する方法は、まだ世の中に出回っていないのでは？」と感じると思います。実は、その感覚は半分だけ正しい——というのが調べた結論でした。

① 音声認識：いちばん現実的で、効果もはっきりしている

今すぐ試せて、しかも効果がハッキリしている代表例が音声認識（Whisper）です。whisper.cpp は Core ML に対応していて、エンコーダ部分をANE（NPU）で実行できます。公式に「CPUのみと比べて3倍以上速くなる」と説明されていて、これは今回eightが実測した3〜3.8倍という数字とぴったり一致します。Intel環境向けにもOpenVINO経由でエンコーダを高速化する道が用意されています。

面白いのは、whisper.cppの説明に「初回の実行は遅い。ANEサービスがモデルを端末専用の形式にコンパイルするため」とある点。これは、今回eightが806MBのモデルで失敗した、まさにそのコンパイル工程のことです。小さいモデルなら通る、大きすぎると失敗する——実測とドキュメントがきれいに符合しました😊

② OS・アプリに組み込まれた機能（気づかず毎日使っている）

• ビデオ会議の背景ぼかし・自動フレーミング・ノイズ除去：ずっと動かし続ける処理。CPUでやると電池が減るが、NPUなら省電力。WindowsのAI機能ではNPUが必須とされるものもあります
• 字幕の自動生成・その場翻訳：小さめのモデルを常時動かす、まさにNPU向きの仕事
• 写真の被写体認識・文字の抜き出し・整理：スマホやMacのOSが裏で回している
• カメラの画質補正・顔の検出：もともとNPUはここが本職

共通点は「軽いモデルを、長時間、静かに動かす」こと。ノートPCの電池を守りながらAIを常駐させる——これがNPUの本領です。派手ではありませんが、確実に効いています。

③ 自分のアプリに組み込むなら、今が狙い目

そして開発者目線でいちばん現実的なのが、「自分の作るアプリに、小さめのAIを組み込む」使い方です。今回の実測どおり、float16・数百MB級・対応演算だけという条件を守れば、NPUはCPUの3倍以上で動き、GPUより速く、しかも省電力。

具体的には、こんな用途がハマります。

• 画像の分類・検出・セグメンテーション（今回のCNNがまさにこれ。1.92msで回る）
• 音声の文字起こし・話者判定・キーワード検出
• 小さめの言語モデル（分類・要約・タグ付けなど、生成が短い用途）
• 常時動かす監視・センサー処理（電力効率がそのまま価値になる）

逆に言えば、「巨大なLLMを丸ごと」だけが、たまたまNPUの守備範囲から外れているのです。世間のNPUの評価が微妙になりがちなのは、いちばん話題のLLMがいちばん苦手な仕事だから——という、少し皮肉な事情でした😅

GPUとNPU、どう使い分ける？

ここまでを、用途ごとの判断表にまとめます。

AI PCを買うときの見方

調べてみて、機材選びの見方も少し変わりました。

• ローカルLLMが目的なら、NPUのTOPSではなくGPUとVRAMを見る。ここは実測とも一致します
• NPUの価値は「電池持ち」で考える。速さの指標として見ると期待外れになりやすい
• TOPSの内訳を確認する。前回のPanther Lakeの例では、合計180 TOPSのうちNPUは50でした
• 状況は変わりつつある。AMDのNPU対応が進むなど、来年には話が変わっている可能性も十分にあります

まとめ

「AI PCのNPUでローカルLLMは動くのか」を調べてみました。

• 主流のツール（Ollama・llama.cpp・LM Studio）はNPUを使っていない。CPUかiGPUで動いている
• NPUがLLMに向かない理由は①想定モデルが数百MB〜1GB級 ②専用メモリを持たずメモリ帯域が足りない
• 各社の専用ツール（OpenVINO／Ryzen AI／QNN／Core ML）を使えば道はあるが、モデル変換のひと手間が要る
• NPUの本領は「軽いモデルを長時間、省電力で」。背景ぼかしや字幕など、日常でしっかり働いている
• ★実測：条件が合えばNPUはCPUの3〜3.8倍速（GPUより速い）。ただしfloat16でないと使われず（約10倍差）、800MB超でコンパイルが失敗して逆に4倍遅くなった
  ※この「800MB超で失敗」はのちの検証で誤りと判明しました。末尾の訂正をご覧ください
• ローカルLLM目的なら、いまはGPUとVRAMを見るのが正解

正直、調べる前は「NPUでLLMが省電力に動くのでは」と期待していたので、「そもそも使われていない」という結論は意外でした😅 でも理由まで辿ると、NPUが手を抜いているのではなく、そもそも別の仕事のために作られた道具だと分かって、妙に納得もしました。適材適所ですね。

とはいえ各社が本気で手を入れている領域でもあるので、この結論は数年で変わるかもしれません。そのときはまた、実際に測って確かめてみたいところです😊

それでは、今回はここまで。最後までありがとうございました😊

【主な参考】各社公式ドキュメント（Intel OpenVINO／AMD Ryzen AI・XDNA／Qualcomm AI Hub・QNN／Apple Core ML・Neural Engine）／NPU比較・AI PC関連の技術記事／ローカルLLMランタイム（Ollama・llama.cpp・LM Studio）のNPU対応状況に関する報告／whisper.cpp 公式README（Core MLによるEncoderのANE実行＝CPUのみ比で3倍以上、OpenVINO対応）。いずれも2026年7月時点で確認。この分野は動きが速く、対応状況は短期間で変わります。／実測環境＝Mac（Apple M4・32GB）／coremltools 9.0・PyTorch 2.12／自作の小規模CNN・Transformerを Core ML（mlprogram）に変換し、compute_units を切り替えて中央値を計測。