NPUとは？CPU・GPUとの役割分担とTOPSの実効性能・採用判断【2026年版】

NPUは、ニューラルネットワークの推論に絞って設計された演算ユニットです。MicrosoftがCopilot+ PCの要件を40 TOPS以上と示したことで、搭載機は一気に広がりました。ただしカタログのTOPS値をそのまま速度差として読むと、実装の段階で見込みが外れます。この記事では、NPUの演算特性とCPU・GPUとの役割分担、TOPSが理論ピーク値である前提と実効性能が落ちる要因、Intel・AMD・Qualcomm・Appleと組込み向けSoCの系統、ONNX Runtimeの実行プロバイダを軸にした実行スタック、そして受託開発でオンデバイス推論を引き受けるときの採用条件と見送り基準までを実装の順序で並べます。数値は2026年8月時点で公開されている資料に基づく公称値です。

まとめ：NPUの採用可否はTOPSでなく演算子適合と量子化耐性で決まる

NPUを使うかどうかの判断は、性能値の比較から始めると必ず遠回りになります。先に見るのは2点だけです。動かしたいモデルの演算子がベンダーの対応表に収まるか、そしてINT8へ量子化しても精度が許容範囲に収まるか。この2つが通らなければ、公称80 TOPSの回路を積んでいても処理はCPUへ落ちます。

役割分担も整理しておきます。CPUは制御と前後処理、GPUは大きなバッチと学習、NPUは常時走り続ける軽い推論を低電力で引き受ける枠です。NPUはGPUの下位互換ではありません。単発の速度ではGPUに負けたまま、電力あたりの推論性能と常時稼働の持続性で取り返す設計になっています。

採用の線引きは条件で言い切れます。端末のSoCを固定でき、推論が高頻度で走り、データを外へ出せない案件なら採用の価値があります。逆に数Bパラメータ級のLLMを常用したい要件では採用しません。共有メモリの帯域が上限を作るため、TOPSをいくら積んでも体感速度に届かないからです。

実装の入口はONNX Runtimeと実行プロバイダの組み合わせに集約されます。端末側とクラウド側のどちらへ推論を置くかという上位の判断はエッジAIとは？クラウドAIとの違い・仕組み・実装の判断基準で扱っているため、本記事は端末に載る演算ユニットそのものの話に絞ります。

NPUの定義と演算特性｜行列積に振り切った推論専用ユニットの構造

NPUはNeural Processing Unitの略で、ニューラルネットワークの計算だけを高い密度で流すために設計された回路を指します。まず何を捨てて何を取ったのかから見ていきます。

NPUが速い理由｜積和演算器の並列配置と低精度整数演算への割り切り

NPUの中身は、積和演算器を格子状に並べた回路と、その周囲に置かれた小容量のオンチップメモリです。畳み込みも全結合も、計算式へ落とせば行列積の繰り返しに還元されます。この一種類の計算へ資源を集中させるため、汎用プロセッサが持つ分岐予測や深いキャッシュ階層を削り、その面積を演算器へ振り替えた構造がNPUにあたります。

もうひとつの割り切りが数値精度です。CPUがFP32、GPUがFP16やBF16を前提に組まれるのに対し、NPUはINT8を基準に設計され、世代によってはINT4も扱います。1回の演算に必要なビット数が減れば、同じ面積へより多くの演算器を置けますし、メモリから運ぶデータ量も減ります。8ビット整数への丸めで生じる誤差を、推論なら許容できるという前提の上に成り立っている回路です。

代償は汎用性の低さでした。学習で必要になる勾配計算や、入力のたびに形が変わる動的な処理は苦手です。実行できる演算子はベンダーが公開する対応表の範囲に限られ、そこから外れた層は別のプロセッサへ回されます。

CPU・GPU・NPUの役割分担｜電力あたり性能で分ける3者の守備範囲

3者の違いは処理の重さではなく、電力あたりで何を取りに行くかで分かれます。

dGPUを積んだノートPCで同じモデルを回せば、多くの場合はGPUのほうが早く終わります。それでもNPUへ寄せる理由は2つあります。バッテリー駆動のまま何時間も動かし続けられること、そしてGPUを画面描画やほかの処理へ空けておけることです。カメラ映像の常時解析やノイズ抑制のように、1回あたりの負荷が小さく、しかし止まらない処理ほどNPU側の取り分が大きくなります。

逆に、数分で終わるバッチ処理を1日1回走らせるだけなら、NPUへ載せ替える手間に見合いません。移植コストを回収する前に案件が終わります。

TOPSの読み方と実効性能の乖離｜理論ピーク値が現場で出ない3つの要因

カタログに並ぶTOPSは、回路が理論上出せる上限値です。実測のスループットとは別物として扱う前提で読み進めてください。

TOPSの定義と前提精度｜INT8基準の理論値がINT4やスパースで膨らむ仕組み

TOPSはTera Operations Per Secondの略で、1秒あたり何兆回の演算を実行できるかを表します。計算式そのものは単純で、演算器の数に動作周波数を掛け、積和を2演算として数えた値です。ここに実際のモデルは一切登場しません。

注意が要るのは前提精度のほうです。同じ回路でもINT8で数えるかINT4で数えるかによって公称値は倍近く変わりますし、構造的スパース性を前提にした値ならさらに上振れします。Copilot+ PCの要件として示された40 TOPS以上も、INT8基準の数字として読むのが前提です。測定条件が揃っていない値を横並びで比べると、序列を取り違えます。

確認は3つの順序で行います。公称値がどの精度で数えられているか、スパース前提が含まれていないか、そしてそのNPUが自社モデルで使う精度に対応しているか。この3点が揃って、はじめて数字が比較可能になります。

実効性能を決めるメモリ帯域｜演算強度が低い層でNPUが待たされる条件

理論値が出ない最大の原因は、演算器ではなくメモリ側です。推論の各層は、読み出すデータ量に対してどれだけ計算するかという比率（演算強度）が層ごとに違います。畳み込み層のように同じ重みを何度も使い回す層なら演算器は埋まりますが、全結合層や注意機構のように重みを1回読んで1回使うだけの層では、データが届くのを待つ時間が全体を支配します。

PC向けNPUは専用メモリを持たず、CPUと同じ主記憶を共有する構成が主流です。Ryzen AI 400シリーズが対応する毎秒8,533MT級のLPDDR5Xでも、帯域は専用メモリを積んだdGPUに遠く及びません。公称50 TOPSのNPUで数Bパラメータのモデルを回すと毎秒数トークンまで落ちるのは、この構造が理由です。

実装前に押さえる指標は、TOPSではなく「1トークンあたり何バイト読み出すか」に置き換わります。7Bパラメータのモデルを4ビット量子化しても、1トークン生成のたびにおよそ3.5GBの重みを読みます。共有メモリの実効帯域が毎秒100GB前後なら、演算器が何TOPSあろうと毎秒30トークン付近が天井です。

NPU搭載SoCの系統と公称TOPS｜PC向け4陣営と組込みSoCの位置づけ

NPUを積むSoCは、PC向けと組込み向けで桁が2つ違います。まず数字の並びを押さえ、次にその桁差が用途の差である理由を見ます。

PC向けNPUの公称値比較｜Copilot+ PC要件の40 TOPSを基準にした整理

2026年8月時点で出荷されているPC向けSoCの公称値を並べます。いずれもベンダー公表の理論ピーク値で、測定条件は各社で揃っていません。

並びだけを見ればQualcommが頭ひとつ抜けた形です。ただし製品選定の分岐点は、その端末で動かすランタイムがベンダーの実行プロバイダに対応しているかどうかへ移ります。Windows向けにx86前提のネイティブ依存を抱えたアプリを配るなら、Arm系SoCでは変換層を通したときの挙動確認が別途必要になります。

40 TOPSという線引きにも注意が要ります。これはCopilot+ PCの機能要件であって、自社モデルの要求性能とは無関係な数字です。40 TOPS未満のSoCでも、対象モデルが軽ければ用途は成立します。

組込み・産業機器向けSoC｜数TOPS級で成立する用途と選定時の確認項目

産業機器や店舗端末に載るSoCは、数TOPSの水準で設計されています。RockchipのRK3588は公称6 TOPS（INT8）で、Orange Pi 5系のシングルボードコンピュータなどに搭載されました。桁は小さくても、640ピクセル四方の入力で物体検出を毎秒15〜30フレーム回す程度なら十分に成立します。

用途を固定できる機器ほど、この帯域が現実解になります。1台あたりの単価と消費電力が数Wに収まり、ファンレスの筐体設計に無理が出ません。サーバ側で大量のリクエストをさばく専用チップとは土俵が異なり、その系統はAWS Inferentiaとは｜Trainiumとの違い・使い分けを推論チップの視点で解説で整理しています。

選定時に確認する項目は3つです。ベンダーの変換ツールが対象モデルの演算子を通すか、Linuxカーネルとドライバの供給期間が製品寿命に足りるか、そして温度上限まで連続稼働させたときにクロックが落ちないか。3つ目は仕様書に書かれないため、評価ボードでの実測が要ります。

NPUで推論を走らせる実行スタック｜ONNX Runtimeの実行プロバイダとSDK

NPUはドライバを入れれば勝手に使われる装置ではありません。推論ランタイム側で明示的に割り当てて、はじめて処理が流れます。

Windows環境の構成手順｜実行プロバイダの切り替えとモデル変換の流れ

Windows環境での標準的な組み立ては、ONNX Runtimeを土台に据えてSoCごとの実行プロバイダを差し替える形になります。順序は次のとおりです。

1. 学習済みモデルをONNX形式へ書き出し、演算子セットの版を固定する
2. ベンダー提供の量子化ツールでINT8化し、キャリブレーション用データで誤差を測る
3. 対象SoCの実行プロバイダを指定してセッションを生成する（Intel系はOpenVINO、Qualcomm系はQNN）
4. プロファイラで層ごとの割り当て先を出力し、CPUへ落ちた層を洗い出す
5. 落ちた層を等価な演算子へ置き換えるか、その層だけCPU実行を許容するかを決める

1番目でつまずく案件が実際には多く、書き出しの基本はONNXとは？モデル変換・推論の仕組みと使い方に整理しました。Windows側にはランタイムと実行プロバイダの配布を吸収する仕組みも用意されており、アプリへプロバイダ一式を同梱せずに済む構成も選べます。

AppleとAndroid・組込みの構成｜Core MLとLiteRT・変換ツールの差

Appleの構成は独立しています。Core MLの形式へ変換し、どの計算ユニットで実行するかはランタイム側の判断に委ねる形が基本です。層が対応外ならGPUやCPUへ静かに回るため、Neural Engineへ載ったかどうかはプロファイル出力を見る以外に知る手段がありません。

Androidと組込みはさらに分かれました。共通APIとして使われてきたNNAPIはAndroid 15で非推奨となり、LiteRTのベンダー委譲やSoCベンダーのSDKを直接呼ぶ形へ移っています。RockchipならRKNN系、Qualcomm系ならQNN系と、変換ツールが端末ごとに変わる状態です。

ここが受託開発の見積もりへ直に効きます。対象端末が2系統に増えるだけで、変換・量子化・精度検証の一式が2本走ります。工数はSoCの数に比例すると考えて計画してください。

NPU実装でつまずく箇所｜未対応演算子のフォールバックと量子化の精度劣化

NPU実装の失敗は「動かない」形では現れません。動いたのに速くない、あるいは動いたのに精度が足りない、という形で出てきます。

対応演算子から外れた層の分断｜フォールバックで速度が逆転する条件

ONNX Runtimeは、実行プロバイダが対応できない演算子に当たると、その部分だけがCPUへ戻る仕組みです。分割が起きた時点で、NPUとCPUの間でテンソルを受け渡す転送が発生します。切り替わりが数回で済むなら誤差の範囲ですが、モデルの中盤で何十回も往復すると転送待ちだけで実行時間を押し上げ、CPUのみで走らせたほうが速いという逆転すら起こります。

判定は実測でしか出せません。ONNX Runtimeのセッションオプションでenable_profilingを有効にすると、層ごとの実行先と所要時間が出力されます。CPUへ割り当てられた層の合計時間が全体の3割を超えていたら、モデル側を書き換える段階に入ったと判断してください。

書き換えの定石は、独自の演算子と動的な形状を避けることに尽きます。入力サイズを固定し、条件分岐をモデルの外へ出し、対応表にある演算子だけで組み直す。学習側の都合で入れた便利な層が、そのまま端末で足を引っ張ります。

量子化で落ちる精度の見極め｜検証データで判断するINT8採用の可否

INT8化は速度を得る条件であると同時に、精度を削る操作でもあります。一般的な分類タスクなら学習後量子化で1ポイント前後の低下に収まる例が多い一方、細かい欠陥検知や小さな文字の読み取りでは、その1ポイントが検出漏れという形で表面化します。

判断は自社の検証データで行う以外にありません。量子化の前後で同じ評価セットを流し、全体の精度だけでなく誤検知と検出漏れの内訳まで見比べてください。総合スコアが保たれていても、特定クラスだけが崩れる形は珍しくないためです。落ち幅が許容を超えるなら、量子化を織り込んだ学習へ切り替える選択肢があり、手法ごとの違いは量子化（モデル量子化）とは？仕組み・PTQとQATの違いと実装判断で扱っています。

ここで妥協すると、現場で使われない製品が出来上がります。速度は要件を満たしたのに検出漏れが増えて運用が止まる、という結末です。

オンデバイス推論でNPUを採用する条件と見送りが妥当な場面の判断基準

ここからは判断の話です。条件を示したうえで、採用する場面と外す場面を分けます。

採用してよい4条件｜常時稼働の軽量推論と端末固定・演算子適合・非移動

NPU前提で設計してよいのは、次の4条件が揃う場合です。

• 推論が常時または高頻度で走り、消費電力と発熱が制約になっている
• 端末のSoCを自社で固定できる（法人一括調達のPC、自社製造の機器）
• モデルがINT8量子化に耐え、演算子がベンダーの対応表に収まる
• データを端末の外へ出せない事情がある（回線が細い、持ち出しが禁止）

4つ目だけが単独で成立する案件もあります。工場や店舗のように回線が細く、映像を送り続けられない現場では、電力に余裕があっても端末側で完結させる設計が現実的です。この構成をどこまで端末へ寄せるかという前提の考え方はエッジコンピューティングとは？仕組み・クラウドとの違いから導入判断までにまとめました。

見送りが妥当な場面｜数B級LLMの常用とBYOD配布・更新頻度が高い開発

逆に、次の場面ではNPUを外して設計します。

まず数Bパラメータ級のLLMを端末で常用したい要件では採用しません。共有メモリの帯域が上限を作るため、体感で使える速度に届かないからです。同じ予算をdGPU搭載機かサーバ側の推論基盤へ回したほうが要件を満たせます。サーバ側へ寄せる場合の構成はLLM推論とは？仕組みと高速化の手法・推論基盤の選び方で比較しています。

私物端末を含むBYOD配布も見送りが妥当です。SoCが混在すると実行プロバイダの分岐と検証端末の確保が保守コストへ直結し、NPUで得た電力の余裕を開発工数が食い潰します。

モデルを週次で差し替える開発初期も外してください。変換・量子化・精度検証の一巡が回りきらず、更新のたびに端末側の版が置いていかれます。まずクラウド側で回して要件を固め、更新頻度が月次以下へ落ち着いてから端末へ下ろす順序が安全です。

受託案件で先に測る3項目｜実効スループットと消費電力・フォールバック率

NPU前提の要件を受けたとき、見積もりを出す前に測る項目は3つあります。ひとつ目は実効スループット。カタログのTOPSではなく、対象モデルを対象端末で走らせたときの毎秒処理数を、本番に近い入力で測ります。

ふたつ目は消費電力と温度です。連続稼働30分で筐体温度がどこまで上がり、クロックが落ちて速度が何割下がるかを確認します。評価ボードの短時間計測だけで通すと、量産機で速度が出ないという事故になりがちです。

みっつ目がフォールバック率。プロファイル出力からCPUへ落ちた層の割合を出し、モデル改修の要否を見積もりへ織り込みます。この3点を先に潰しておくことが、後工程での手戻りを減らす条件です。オンデバイス推論を含むAIシステムの設計から実装までは生成AI開発・AI受託開発で対応しており、端末側とサーバ側のどちらへ推論を置くかの切り分けから相談を受けています。

よくある質問

NPUの導入検討で実際に寄せられる質問を5つ取り上げます。

NPUとGPU、どちらが速いのですか？

単発の推論を最短で終わらせたいなら、多くの場合はGPUのほうが速く終わります。演算器の数もメモリ帯域もGPUのほうが大きいためです。NPUが勝つのは、消費電力あたりの処理量と持続時間になります。数Wで動き続けられるNPUに対し、dGPUは数十Wを消費するためバッテリー駆動では長く回せません。カメラ映像の常時解析のように止まらない処理はNPU、まとまった量を一度に処理するバッチはGPU、という分け方が実務の目安です。

TOPSの数値が高いほど推論は速くなりますか？

比例しません。TOPSは演算器数と動作周波数から算出した理論ピーク値で、実際のモデルの構造は計算に入っていないためです。実効性能は、モデルの各層がどれだけメモリを読むか（演算強度）と、共有メモリの帯域で決まります。加えて公称値の前提精度がINT8かINT4かで数字が倍近く変わるため、条件を揃えずに比べても序列は分かりません。判断材料にするなら、対象モデルを対象端末で走らせた実測値を取ってください。

NPUがあればローカルでLLMを快適に動かせますか？

数Bパラメータ級以上のモデルを常用する用途では、快適さに届かないと考えてください。トークンを1つ生成するたびにモデルの重み全体を読み出す必要があり、速度は演算能力ではなくメモリ帯域で頭打ちになります。7Bを4ビット量子化しても1トークンあたり約3.5GBの読み出しが発生し、共有メモリでは毎秒数十トークン程度が上限です。要約や分類のような短い出力なら実用域に入りますが、長文生成を業務で回すならサーバ側の推論基盤を選ぶほうが確実です。

NPU非搭載のPCでもオンデバイス推論はできますか？

できます。ONNX RuntimeはCPU向けの実行プロバイダを標準で備えており、INT8量子化したモデルであれば軽量な画像分類や音声処理は成立します。差が出るのは消費電力と、推論中にほかの処理を妨げないかという点です。NPUへ載せれば同じ処理をより少ない電力で回せ、CPUを業務アプリへ空けておけます。既存端末を使い切る前提なら、まずCPU実行で要件を満たせるか測り、電力や応答性が足りない場合にNPU搭載機への更新を検討する順序をおすすめします。

学習済みモデルをNPU向けに変換する期間はどれくらいかかりますか？

標準的な畳み込み系の画像モデルで対象SoCが1系統なら、変換と量子化、精度検証までを合わせて1〜2週間規模が目安です。伸びる要因は3つあり、独自演算子を含む場合の書き換え、量子化で精度が落ちたときの再学習、そして対象SoCが複数系統ある場合の並行検証です。特に3つ目は工数がほぼSoCの数に比例します。見積もり前にプロファイルを取り、CPUへ落ちる層の割合を把握しておくと、期間の見通しが立ちます。

関連記事

• エッジAIとは？クラウドAIとの違い・仕組み・実装の判断基準を解説：推論を端末とクラウドのどちらへ置くかという上位の判断を扱っています。
• エッジコンピューティングとは？仕組み・クラウドとの違いから導入判断までわかりやすく解説：端末側へ処理を寄せる構成の前提を整理しています。
• AWS Inferentiaとは｜Trainiumとの違い・使い分けを推論チップの視点で解説：サーバ側で使う推論専用チップの系統を比較しています。
• 量子化（モデル量子化）とは？仕組み・PTQとQATの違いと実装判断を解説【2026年版】：INT8化の手法と精度低下への対処をまとめています。
• ONNXとは？モデル変換・推論の仕組みと使い方を初心者向けに解説：NPU向け変換の入口となる形式を解説しています。