onw — 俺のNPUがこんなに動くわけない

日本語 | English ・ 使い方マニュアル ・ 更新履歴 ・ 技術解説（NPU で初めて動かした 4 つ、MoE・SSD・画像エンコーダーの仕組み） ・ LFM を自分で変換

LLM を Intel NPU だけで 動かす小さなエンジンです。MoE（専門家混合）モデルや Gated DeltaNet 系のハイブリッドモデル、 画像入力にも対応し、OpenAI 互換 API サーバーとブラウザのチャット画面を備えています。 llama.cpp と GGUF の関係と同じく、エンジンとモデルは別々にダウンロードします。エンジンは一つ、コマンドも一つで、 変換済みのモデルならどれでも動きます。

低電力の NPU で動かすので、ファンが低回転のままでも静かに LLM を使えます。Lunar Lake で計測したところ、1 トークンあたりの電力は iGPU（llama.cpp）より 3〜4 割少なく、CPU の 3〜4 割でした（先読みなし同士・先読みあり同士の比較）。詳しい数字と測り方は 電力効率と温度 にあります。

インストール（コマンドを 1 行貼るだけ）

Intel Core Ultra（NPU 付き）の PC なら、次の 1 行で入ります（詳しい条件は下の「必要なもの」）。

Windows

1. スタートメニューで「PowerShell」と入力し、「Windows PowerShell」を開きます（管理者として開く必要はありません）。
2. 次の 1 行をコピーして貼り付け、Enter を押します。

irm https://huggingface.co/ryugyosoft/onw/resolve/main/install.ps1 | iex

onw が %LOCALAPPDATA%\onw にダウンロードされ、セットアップの黒い画面が開きます。Python が見つからない場合は 「Install Python 3.12 ... [Y,N]?」と聞かれるので Y を押してください。数分で終わり、タスクトレイ（画面右下）に onw のアイコンが出て、モデルを選ぶウィンドウが開きます。

Ubuntu

端末（Ctrl+Alt+T）を開き、次の 1 行を貼り付けて Enter を押します。途中で必要な部品を入れるために、ログイン パスワードを 1 回聞かれます。

curl -fsSL https://huggingface.co/ryugyosoft/onw/resolve/main/install.sh | bash

onw は ~/onw に入り、画面右上に onw のアイコンが出ます。

貼り付ける前に中身を確認したい場合は、install.ps1／install.sh を開いて読めます。 新しい版が出るとトレイと onw ウィンドウに通知が出て、ボタン 1 つで更新できます（同じコマンドをもう一度実行しても更新できます）。

必要なもの

• Intel Core Ultra を搭載した PC（NPU 付き。Core Ultra シリーズ 1／2（Meteor Lake・Arrow Lake・Lunar Lake）、シリーズ 3（Panther Lake）など）
• Windows 11、または Ubuntu 22.04 以降
• Ubuntu では NPU ドライバー（linux-npu-driver）1.38 以降。それより古いドライバーでは LFM2 系（自分で変換して使う場合）の前半の層が NPU 上で正しく計算されず、回答が途中から空になります（特殊トークンを出し続ける。Lunar Lake で確認、1.38 で解消）。版は dpkg -l | grep -i npu で確認できます。
• 空き容量：エンジン約 1 GB ＋ モデル 2〜21 GB（どのモデルを使うかによります）
• インターネット接続（最初のダウンロードのとき）

Python や git の知識は要りません。Python が入っていなければ、途中で入れるか聞かれます（Windows）。

使い方

インストールが終わると開く onw ウィンドウで、3 ステップです。

1. 「モデル」タブでモデルを選んで「ダウンロード」。迷ったら Gemma 4 E4B（画像も読める・使用メモリ約 6 GB）。
2. 「サーバー」タブで「ロード」。初回だけ NPU 向けのコンパイルに 10〜30 分ほどかかります（2 回目以降は約 20 秒）。
3. 「動作中」になったら、「チャット」でブラウザのチャット画面が開きます。他のアプリからは、base URL http://localhost:8000/v1 の OpenAI 互換 API として使えます。

画面ごとの詳しい使い方（モデルの管理、チャット画面と会話の履歴、検証ページ、設定の各項目、困ったとき）は 使い方マニュアル にあります。

モデル一覧

onw モデル	アーキテクチャ	入力	思考	NPU 3720 生成速度	ダウンロード	使用メモリ
ryugyosoft/gemma-4-E4B-it-onw	gemma4（検証済みの Gemma NPU グラフを取り込み）	テキスト＋画像	切替	7.2 tok/s	4.3 GB	約 6 GB（画像処理中 8.5 GB）
ryugyosoft/Qwen3.5-9B-onw	qwen3_5（Gated DeltaNet＋ゲート付きアテンション、dense）	テキスト＋画像	切替	4.1 tok/s	5.3 GB	約 11 GB
ryugyosoft/Qwen3.5-9B-nf4-onw	同上、重みはチャネル単位 NF4、MTP 先読み付き（Lunar Lake 以降専用）	テキスト＋画像	切替	—（Lunar Lake で約 15 tok/s、通常版の約 2 倍）	5.6 GB	通常版の約 85%
ryugyosoft/Qwen3.6-REAP-18B-A3B-onw	qwen3_5_moe、256 個中 128 個のエキスパートを残す（REAP）	テキスト＋画像	切替	6.8 tok/s	9.6 GB	約 12 GB
ryugyosoft/Qwen3.6-35B-A3B-onw	qwen3_5_moe（Gated DeltaNet＋ゲート付きアテンション＋MoE 256 個から 8 個＋共有エキスパート）	テキスト＋画像	切替	6.8 tok/s	17 GB	約 20 GB（SSD から読めば 8〜13 GB）
ryugyosoft/Ornith-1.5-9B-onw	qwen3_5（Qwen3.5-9B をエージェント・ツール呼び出し向けに鍛えた Ornith-1.5）	テキスト＋画像	切替	4.9 tok/s	5.3 GB	約 11 GB
ryugyosoft/Ornith-1.5-9B-nf4-onw	同上、重みはチャネル単位 NF4、MTP 先読み付き（Lunar Lake 以降専用）	テキスト＋画像	切替	—（Lunar Lake で約 15 tok/s、通常版の約 2 倍）	5.6 GB	通常版の約 85%
ryugyosoft/NeoHorse-1-4B-onw	qwen3_5（Qwen3.5-4B をエージェント・ツール呼び出し向けに追加学習した NeoHorse-1）	テキスト	切替	6.4 tok/s	2.4 GB	約 6 GB
ryugyosoft/granite-4.2-3b-onw	granite（IBM Granite 4.2：思考とツール呼び出しを強化した 3B。Llama 型）	テキスト	切替	6.7 tok/s（チャット約 7.7）	2.1 GB	約 6 GB
ryugyosoft/granite-4.2-8b-onw	granite（同上の 8B）	テキスト	切替	3.6 tok/s（チャット約 3.9）	5.0 GB	約 13 GB
ryugyosoft/llm-jp-4.1-8b-thinking-onw	llama（NII LLM-jp の日本語中心の思考型 8B、harmony 形式）	テキスト	常に	4.2〜4.7 tok/s	4.6 GB	約 10 GB
ryugyosoft/llm-jp-4.1-8b-thinking-int8-onw	同上、重みはチャネル単位 INT8（bf16 に近い精度）	テキスト	常に	4.1 tok/s	7.7 GB	約 15 GB（節約モードで待機中 約 8 GB）
ryugyosoft/llm-jp-4.1-32b-a3b-thinking-onw	qwen3_moe（llm-jp の MoE：128 個から 8 個、32B のうち 1 トークン約 3B、harmony 形式）	テキスト	常に	5.8 tok/s	16 GB	約 17 GB（SSD から読めば 16 GB の PC でも。Lunar Lake 16 GB で 3.4 tok/s）
ryugyosoft/llm-jp-4.1-32b-a3b-thinking-int8-onw	同上、エキスパート・アテンション INT8（bf16 に近い精度）	テキスト	常に	4.6 tok/s	30 GB	約 32 GB
ryugyosoft/gpt-oss-20b-onw	gpt_oss（OpenAI gpt-oss-20b：MoE 32 個から 4 個、attention sink、YaRN、harmony 形式。エキスパートはチャネル単位 INT4）	テキスト	常に	8.5 tok/s	11.4 GB	約 12 GB
ryugyosoft/gpt-oss-20b-int8-onw	同上、エキスパート INT8（bf16 に近い精度）	テキスト	常に	6 tok/s	21 GB	約 21 GB（SSD から読めば 8〜13 GB）

NF4 版（Lunar Lake 以降専用）：Lunar Lake（NPU 4000）以降の NPU は、NF4（正規分布に合わせた 4 ビット）の重みを ハードウェアで計算できます。NF4 版はチャネル単位の NF4 にしたモデルで、Lunar Lake では通常版より生成が約 2 倍（MTP 先読み込み）・ プロンプト処理が約 3 倍速く、メモリは約 15% 少なくて済みます（精度はほぼ同等）。NPU 3720（Meteor Lake・Arrow Lake）では動かないため、 onw ウィンドウは Lunar Lake 以降の PC でだけ一覧に出します。

MTP 先読み（onw 1.4.0、Lunar Lake 以降）：Qwen3.5 系のモデルには、次の次のトークンを予想する小さな層（MTP）が付いています。 onw はこれで 2 トークン先まで下書きし、本体の 4 トークン用のグラフで一度に確かめます（外れた下書きの分だけ正確に巻き戻します）。 NPU は数トークンを 1 トークンとほぼ同じ時間で計算できるので、下書きが当たった分だけ速くなります（8 種類の質問の平均で約 1.5 倍）。 温度ありの生成でも、1 トークンずつ生成したときと同じ確率でトークンを選びます。NF4 版に入っています。NPU 3720 では確かめるブロックが 2 トークンでも 1 トークンの 1.7 倍かかり、かえって遅くなるため使いません。

使用メモリは、テスト機（Core Ultra 9 285HX、NPU 3720）で、64 トークン処理なし・画像エンコーダーは使ったら解放（メモリ 24 GB 未満の PC の既定）で測ったプロセスのピークです。onw ウィンドウの「メモリ目安」は、この値にその PC の設定 （コンテキスト長、64 トークン処理、エキスパートのメモリ）を反映した目安です。メモリが足りない PC では、Qwen3.6 系の エキスパートを SSD に置いたまま動かせます（設定の「エキスパートのメモリ」。仕組みは技術解説）。

先読み検証は、16 トークンの検証ブロックが十分安く済むモデル（Qwen3.5-9B、Gemma、LFM 系）で自動的に使われます。 「思考」の列の「切替」のモデル（Qwen、LFM2.5、Gemma 4、Granite 4.2 など）は、既定では考えずに答えます（チャット画面の「思考モード」、API の chat_template_kwargs: {"enable_thinking": true} または reasoning_effort で考えさせられます）。「常に」のモデル（gpt-oss、llm-jp）は思考モードがオフでも裏で考え、その分も最大トークンに数えます（max_tokens は大きめに）。 モデルが考えた思考は、回答とは別に、API では reasoning_content（トークン数は usage.completion_tokens_details.reasoning_tokens）、チャット画面では折りたためる 「思考」欄に出ます。 どのモデルも会話の状態をターン間で保持するので、画像付きの会話でも 2 ターン目は新しいメッセージだけを処理します（約 2 秒）。

LFM 系は自分で変換して使う

LiquidAI の LFM2.5-2.6B と LFM2-8B-A1B も onw で動きますが、変換済みのモデルは配布していません。LFM のライセンス （LFM Open License v1.0）は、年間売上 1000 万ドル以上の法人による商用利用を対象外にしているためです。元のモデルを Hugging Face から取得して、手元で変換してください（onw だけで変換でき、1〜数分です）。手順は LFM を自分で変換 にあります。AI アシスタントにそのページを読ませれば、そのまま実行できる形で 書いてあります。

モデル（自分で変換）	アーキテクチャ	入力	NPU 3720 生成速度	変換後の大きさ	使用メモリ
LiquidAI/LFM2.5-2.6B	lfm2（短い畳み込み＋GQA、dense）	テキスト	12〜13 tok/s（コード修正・要約では先読み検証で 29〜34）	1.5 GB	約 4.3 GB
LiquidAI/LFM2-8B-A1B	lfm2_moe（短い畳み込み＋GQA＋MoE 32 個から 4 個）	テキスト	16〜17 tok/s（コード修正・要約では先読み検証で 29〜43）	4.0 GB	約 5 GB

サーバー（OpenAI 互換 API）

Anthropic の Messages API（/v1/messages、ストリーミング・ツール・思考・count_tokens 対応。Claude Code などから使えます）と OpenAI の Responses API（/v1/responses、ストリーミング・ツール・previous_response_id 対応。Codex CLI などから使えます）にも 答えます。つなぎ方は使い方マニュアルにあります。

他のアプリからは base URL に http://localhost:8000/v1、モデル名にウィンドウに表示される名前を指定します。 GET / でサーバーの案内（JSON）、/health でモデルの読み込み完了を確認できます。CORS は開放済みで、LAN に公開する 場合は API キー（--api-key または設定画面）で /v1 を保護できます。動作確認用に、チャット画面（/chat）と、 テキスト・先読み検証・2 ターン会話・画像の検証を一括実行して速度を表にする検証ページ（/check）もあり、どちらも トレイのメニューとウィンドウから開けます。NPU ドライバーがない環境では CPU で動きます。

ツール呼び出し（function calling）にも対応しています。OpenAI と同じく tools を渡すと、モデルが呼び出しを決めたときは finish_reason: "tool_calls" と message.tool_calls が返り、ストリーミングでも同じ形で届きます。ツールの結果は role: "tool" のメッセージで返してください。tool_choice は "auto"（既定）、"none"、関数の指定（そのツールだけを 見せる）に対応します（"required" は強制できません）。Qwen3.5／Qwen3.6、Gemma 4、LFM2.5、gpt-oss で確認済みです（モデルごとの 書式の違いは onw が吸収します）。

response_format（json_object／json_schema）は指示を足すだけのベストエフォートで、出力の形は保証しません。n は 1 のみ （2 以上は 400）、logprobs は null です。エラーは OpenAI と同じ {"error": {"message", "type", ...}} の形で返します。 http(s) の画像 URL は公開アドレスのものだけ取りに行きます（ローカルネットワークの URL は data: URL で送ってください。 ONW_ALLOW_LOCAL_IMAGES=1 で許可）。

onw コマンドと設定

onw serve MODEL [--port 8000] [--host 0.0.0.0] [--api-key KEY] [--context 4096] [--device NPU|CPU] [--no-pld] [--open]
onw chat MODEL [--think] [--context 4096]                     # ターミナルでチャット
onw tray                                                      # 常駐アプリ（setup が起動するもの）
onw window [--tab models]                                     # モデル管理・サーバー操作・設定のウィンドウ
onw convert HF_DIR OUT_DIR [--compact] [--prune SAL.json --keep 0.5] [--graphs-only]
onw list                                                      # 対応アーキテクチャ

設定を変えたときに何が必要か：

設定	変え方	再コンパイル
temperature、top_p、top_k、繰り返し抑制（repetition / presence / frequency penalty）、max_tokens、stop、seed、思考モード	リクエストごと（API またはチャット画面）	不要
ポート、待ち受けアドレス、モデル、デバイス、先読み検証のオン／オフ	サーバーのオプション／設定画面、再起動（約 20 秒）	不要
コンテキスト長（--context、既定 32K、モデルの最大まで）	サーバーのオプション／設定画面	不要（KV キャッシュの上限が変わるだけ）
64 トークン処理（Gemma、Qwen3.5 系 NF4 版。auto は Lunar Lake 以降か RAM 24 GB 以上でオン）	ONW_S64=1/0／設定画面	初回のみ
MTP 先読み（Qwen3.5 系 NF4 版。auto は Lunar Lake 以降でオン）	ONW_MTP=1/0	初回のみ
エキスパートのメモリ（Qwen3.6 系。上限を超える分は SSD から読む）	ONW_EXPERT_GB=5／設定画面	不要
NPUW 重み共有（試験的。auto は Lunar Lake 以降でオン、MoE モデル（LFM2・Qwen3.6）と区間の多いモデル（Granite・llm-jp）は対象外：重みを 1 コピーにしてメモリとコンパイル時間を削減）	ONW_NPUW=1/0／設定画面	初回のみ
メモリ節約モード（1 トークン用と 16 トークン用で重みを共有できない dense モデル：NPU 3720 ではすべて、Lunar Lake 以降は Granite・llm-jp と NPUW オフのとき。普段は 16 トークン用のグラフだけを持ち、回答を書く間だけ 1 トークン用と入れ替える。待機中のメモリ約 4〜6 割減、回答の出だし数秒は遅め、先読み検証なし）	ONW_LAZY16=1／設定画面（効くモデルがあるときだけ表示）	初回のみ
厳格メモリ節約モード（メモリ節約モードの追加。2 種類のグラフを同時に持たず、メモリの最大を待機中と同じにする。回答のたびに書き始めるまで数秒待つ）	ONW_SWAP_STRICT=1／設定画面	なし
API で思考の指定がないリクエストも考えてから答える（既定はオフ。エージェントのアプリ向け）	設定画面	なし
MoE モデルでも NPUW 重み共有（実験的、既定オフ。1 トークン用と 16 トークン用で重みを共有）	ONW_NPUW_MOE=1／設定画面	初回のみ
NPUW の非同期実行 NPUW_FUNCALL_ASYNC（実験的、既定オフ）	ONW_NPUW_ASYNC=1／設定画面	初回のみ
コンパイルキャッシュを重みなしで保存 CACHE_MODE=OPTIMIZE_SIZE（実験的、既定オフ。NPUW 使用時のみ）	ONW_CACHE_SIZE=1／設定画面	初回のみ
ブロックサイズ、画像サイズ、量子化	onw convert（技術解説の「モデルを小さくする」）	必要（変換し直し）

KV キャッシュは INT8 で、会話が実際に使った長さの分だけメモリ（1K トークンあたり 8〜16 MB）と計算がかかります。 コンテキスト長は「そこまで伸ばしてよい上限」なので、大きくしても短い会話は遅くなりません（仕組みは技術解説）。

MODEL には onw 形式のモデルフォルダか Hugging Face のリポジトリ ID を指定します（ID の場合は ./models に ダウンロードされ、途中から再開できます）。onw コマンドは初回の setup／start のあと .venv に入ります （Windows は .venv\Scripts\onw、Linux は source .venv/bin/activate）。任意の環境に入れる場合は pip install -e . --extra-index-url https://storage.openvinotoolkit.org/simple/wheels/pre-release です。

上級者向けの入手方法

• hf download ryugyosoft/onw --local-dir onw（Hugging Face CLI）や git clone https://huggingface.co/ryugyosoft/onw でも入手できます。その後、フォルダ内の setup.bat（Windows）／bash setup.sh（Ubuntu）を実行してください。
• モデルは onw ウィンドウからのダウンロードをおすすめします。自分で取得する場合は hf download ryugyosoft/モデル名 を使ってください。Git LFS なしで git clone すると、重みの代わりに約 130 バイトの「ポインタ」ファイルしか 入りません（onw はこれを検出し、直し方を表示して止まります）。
• コンソールで一度だけ起動したいときは start.bat モデル名（Ubuntu は bash start.sh モデル名）。

構成

ファイル	内容
onw/ir.py	グラフ部品：量子化線形層、RMSNorm（FP16 で溢れない前処理つき）、RoPE／部分 RoPE、ホスト管理の KV キャッシュ上のアテンション、エキスパート枠、Gated DeltaNet（1 トークン用の行列形式、ブロック倍々の厳密な逆行列によるチャンク並列形式）
onw/runtime.py	区間の実行、命名規則による状態管理（KV の行、畳み込み窓、再帰状態）、エキスパートの結び付け、MRoPE、スライディング窓マスク、ホスト側の表引き、先読み検証のための正確な巻き戻し、コンパイル経路の自動切り替え
onw/paged.py、onw/kvcache.py	読み込み時に区間をアテンションの位置で切り分け、ページ化した INT8 KV キャッシュと塊ごとのアテンション（オンライン softmax で合成）
onw/store.py、onw/xio.py	エキスパートの保管（全部メモリ／SSD から読む LRU キャッシュ）、OS のキャッシュを通さない直接読み込み
onw/chat.py	生成ループ：画像（Qwen／Gemma）、サンプリング、停止文字列、先読み検証（正確な巻き戻し、再帰状態を持つモデルでは遅延やり直し、効く場合だけ自動で有効）、ターン間の差分処理
onw/models/	アーキテクチャごとの組み立て定義：lfm2_moe（dense の lfm2 も）、qwen3_5_moe（dense と MoE）、qwen_vision、gemma4、gpt_oss
onw/hub.py、onw/server.py、onw/web/	モデルのダウンロードと LFS 対策、OpenAI 互換サーバー、チャット画面（/chat）、検証ページ（/check）
onw/app.py、onw/tray.py、onw/manager.py、onw/update.py、onw/i18n.py	onw ウィンドウ（モデル／サーバー／設定）、トレイアイコン、ウィンドウの裏側（ローカル API）、自動更新、表示言語
setup.*、install.*、find_python.bat	インストーラー（Python の検出と winget）
check_ref.py、check_vision.py、test_*.py、probe_segments.py、prof_*.py、mem_*.py、bench_*.py	元の HF モデルとの比較、生成・画像・複数ターンの検証、区間ごとの NPU と CPU の比較、速度・メモリ計測

電力効率と温度

同じ PC（LattePanda Mu Ultra、Core Ultra 5 226V＝Lunar Lake）で、Qwen3.5-9B の生成中のパッケージ電力と温度を、NPU・iGPU・CPU で比べました。 日本語の長文生成（768 トークン、temperature 0）を各 3 回測った平均です（onw 1.4.0、2026 年 10 月 6 日）。先読み（MTP）の有無で速さが 大きく変わるので、使わない同士・使う同士で並べています。

先読みなし

デバイス	実行環境	生成速度	パッケージ電力	温度（平均 / 最大）	1 トークンあたり	同（アイドル分を引いた値）
NPU	onw（Qwen3.5-9B-nf4-onw、NF4、5.6 GB）	9.3 tok/s	10.9 W	49 / 59 ℃	1.18 J	1.04 J
iGPU（Arc）	llama.cpp SYCL（Q4_K_M、6.2 GB）	13.6 tok/s	22.9 W	65 / 84 ℃	1.74 J	1.64 J
CPU（8 スレッド）	llama.cpp（Q4_K_M、-t 8）	11.9 tok/s	32.3 W	88 / 95 ℃	2.73 J	2.61 J

MTP 先読みあり（onw は 4 トークンの確認グラフ、llama.cpp は --spec-type draft-mtp。どちらもモデルに付いている MTP 層を使います）

デバイス	実行環境	生成速度	パッケージ電力	温度（平均 / 最大）	1 トークンあたり	同（アイドル分を引いた値）
NPU	onw 1.4.0（同上）	15.1 tok/s	11.6 W	51 / 71 ℃	0.77 J	0.65 J
iGPU（Arc）	llama.cpp SYCL	18.7 tok/s	23.4 W	67 / 91 ℃	1.29 J	1.21 J
CPU（8 スレッド）	llama.cpp（-t 8）	12.8 tok/s	31.0 W	89 / 96 ℃	2.44 J	2.33 J

アイドル時のパッケージ電力は約 1.2〜1.7 W、温度は約 40 ℃ です。

1 万トークンを生成したとき（上の平均値からの計算。MTP 先読みあり）：

デバイス	かかる時間	消費エネルギー	同（アイドル分を引いた値）
NPU	約 11 分	2.1 Wh	1.8 Wh
iGPU	約 9 分	3.6 Wh	3.4 Wh
CPU（8 スレッド）	約 13 分	6.8 Wh	6.5 Wh

• 1 トークンあたりの電力は NPU が最も少なく、iGPU より 32%（先読みなし）〜40%（MTP あり）少なく、CPU の 3〜4 割です。
• 速さは iGPU が最も速く、NPU の 1.2〜1.5 倍です。ただし電力は約 2 倍かかります。
• 生成中の平均温度は NPU が 49〜51 ℃（MTP を使っても 2 ℃ しか上がらない）、iGPU は 65〜67 ℃、CPU は 88〜89 ℃ です。最大は NPU 59〜71 ℃、iGPU 84〜91 ℃、CPU 95〜96 ℃ でした。

測り方と注意：

• 電力は Linux の RAPL（intel-rapl:0、package-0）の電力量を 0.5 秒ごとに読んだものです。SoC（CPU・iGPU・NPU）だけの値で、DRAM（約 0.4〜0.8 W）や PC 全体は含みません。温度は x86_pkg_temp です。
• 測るのは生成の区間だけで、モデルの読み込みは除いています。毎回、温度が 50 ℃ を下回るのを待ってからアイドル電力を 30 秒測りました。デバイスの順番による偏りが出ないよう、全部の組み合わせを 3 周しています。
• onw と llama.cpp ではエンジンが違い、重みの量子化も同一ではありません（onw は NF4、llama.cpp は Q4_K_M）。モデルと実行環境をまとめた比較として読んでください。
• CPU は llama.cpp の既定のスレッド数では使用率が約 25% にとどまり、5.9 tok/s・1 トークンあたり 3.7 J でした（MTP ありでも 6.2 tok/s）。表は 8 スレッド（-t 8）の値です。
• ばらつき：NPU は 3 回でほぼ揃いました（MTP ありで 1 トークンあたり 0.76〜0.77 J）。iGPU は先読みなしで 12.3〜14.0 tok/s と回ごとに差がありました。
• 以前の測定（onw 1.3.0、INT4 の Qwen3.5-9B-onw、2026 年 10 月 5 日）では、NPU は 7.3 tok/s・12.0 W・1 トークンあたり 1.66 J でした。NF4 と MTP 先読みで、1 トークンあたりの電力は半分以下になりました。
• 別の PC、別のプロンプト、別の冷却では値が変わります。

注意点と制限

• コンテキスト長の既定は 32K トークンで、モデルの最大（Qwen3.5／3.6 は 262K、Gemma 4 E4B は 128K）まで設定できます。 長い会話では 1 トークンごとのアテンションの計算が長さに比例して増えます。Qwen の画像は 512×512（256 トークン）に縮小し、Gemma の画像は縦横比を保ちます （最大 280 トークン）。

• エキスパートはチャネル単位 INT4（四捨五入量子化）です。確認した範囲では、最初のトークンのロジットは bf16 との差が 約 33% で、1 位の予測は一致しました。回答は自然ですが、数トークン先から言い回しが bf16 モデルと分かれます。

• 16 トークンより大きいプロンプトブロック（Gemma と Qwen3.5 系 NF4 版の 64 トークン版）は、Lunar Lake 以降（重みを共有するので メモリはほぼ増えません）か RAM 24 GB 以上のときに読み込みます（ONW_S64=1/0 で強制）。

• OpenVINO のプレリリース版（2026.5.0b1。OpenVINO の pre-release 索引から入ります）が必要です。NPU 3720（Windows 11）と NPU 4000（Lunar Lake、Ubuntu、 メモリ 16 GB）で全モデルの動作を確認しています。Panther Lake（NPU 5、Windows 11）と Lunar Lake（Windows 11）では Qwen3.5 系を確認しています。 NPU ドライバーがない環境では CPU で動きます。

• Panther Lake（NPU 5）は、今のところ初回のコンパイルに Lunar Lake の 2 倍以上かかります（2 回目からはキャッシュから十数秒）。 どちらも NPU のコンパイラーは CPU をほぼ 1 コアしか使わないので、差はコンパイラーがグラフ 1 つにかける手間です。同じグラフの コンパイル結果を比べると、NPU 5 向けは行列演算をより細かく分け、SHAVE（小さな汎用プロセッサ）の処理を DPU（行列演算器）へ 寄せています（NPU 5 の大きな演算器と、DPU で活性化関数まで処理できる機能に合わせた最適化と見られます）。

  Qwen3.5-9B／Ornith-1.5-9B（NF4）、onw 1.4.5	Lunar Lake（Core Ultra 7 256V、NPU 4000）	Panther Lake（Core Ultra X7 358H、NPU 5010）
  初回のコンパイル（26 パーツ）	225 秒	521 秒
  コンパイル中の CPU	約 1.4 コア（8 コア中）	約 1.9 コア（16 コア中）
  1 パーツの DPU 命令（本体／分割片）	965 KB／932 KB（4 タイル）	1,116 KB／1,837 KB（3 タイル）
  1 パーツの SHAVE 命令	133 KB	52 KB

  （Windows 11、ドライバー 32.0.100.5540、2026 年 10 月 6 日。1 パーツは 4 トークン用グラフの最初のパーツ。命令の大きさは コンパイル結果の ELF セクションの大きさで、命令の数そのものではありません。）

ライセンス

コードは Apache 2.0。変換済みモデルは元のモデルのライセンスに従います（各モデルのリポジトリを参照）。