onw

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 として使えます。

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

モデル一覧

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 アシスタントにそのページを読ませれば、そのまま実行できる形で 書いてあります。

サーバー（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                                                      # 対応アーキテクチャ

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

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 モデル名）。

構成

電力効率と温度

同じ 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）の有無で速さが 大きく変わるので、使わない同士・使う同士で並べています。

先読みなし

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

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

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

• 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 で活性化関数まで処理できる機能に合わせた最適化と見られます）。

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

ライセンス

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