--- license: apache-2.0 library_name: openvino language: - ja - en tags: - openvino - npu - intel - intel-npu - moe - inference-engine --- onw # onw — 俺のNPUがこんなに動くわけない **日本語** | [English](README_en.md) ・ [使い方マニュアル](MANUAL.md) ・ [更新履歴](CHANGELOG.md) ・ [技術解説](TECHNICAL.md)（onw 3.0 の NPU キット、NPU で初めて動かした 4 つ、MoE・SSD・画像エンコーダーの仕組み） ・ [LFM を自分で変換](CONVERT_LFM.md) LLM を **Intel NPU だけで** 動かす小さなエンジンです。MoE（専門家混合）モデルや Gated DeltaNet 系のハイブリッドモデル、 画像入力にも対応し、**OpenAI 互換 API サーバー**とブラウザのチャット画面を備えています。 llama.cpp と GGUF の関係と同じく、エンジンとモデルは別々にダウンロードします。エンジンは一つ、コマンドも一つで、 変換済みのモデルならどれでも動きます。 低電力の NPU で動かすので、ファンが低回転のままでも静かに LLM を使えます。Lunar Lake で計測したところ、1 トークンあたりの電力は iGPU（llama.cpp）より 3〜4 割少なく、CPU の 3〜4 割でした（先読みなし同士・先読みあり同士の比較）。詳しい数字と測り方は [電力効率と温度](#電力効率と温度) にあります。 NPU・iGPU・CPU の 1 トークンあたりの電力、生成速度、生成中の平均温度（先読みなし／MTP 先読みあり） **onw 3.0 では、OpenVINO の NPU プラグインとコンパイラーを onw 用に作り直して同梱しました**（onw の NPU キット）。Lunar Lake 以降の PC（Windows・Ubuntu）では、コンパイル済みのグラフが重みを持たなくなり（キャッシュはモデルの 1/10 以下）、区間を NPU の 1 回の 呼び出しで計算する融合グラフを既定で使います。Panther Lake の NF4 版（Granite・llm-jp）で、2.1.0 と比べて生成 1.4〜1.6 倍、 プロンプト 2.5〜3.1 倍、長い会話の生成 2〜3 倍、キャッシュ 1/6、ピークのメモリ約 2 割減です。Qwen3.5 系は速さ・メモリとも 2.1.0 と同じで、キャッシュと初回のロードが小さく・短くなります。仕組みと直した点は [技術解説](TECHNICAL.md)（最初の章）にあります。 onw 3.0 と 2.1.0 の生成速度・プロンプト・専用メモリ・長い会話の比較（Panther Lake） ## インストール（コマンドを 1 行貼るだけ） Intel Core Ultra（NPU 付き）の PC なら、次の 1 行で入ります（詳しい条件は下の「必要なもの」）。 **Windows** 1. スタートメニューで「**PowerShell**」と入力し、「Windows PowerShell」を開きます（管理者として開く必要はありません）。 2. 次の 1 行をコピーして貼り付け、Enter を押します。 ```powershell 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 回聞かれます。 ```bash curl -fsSL https://huggingface.co/ryugyosoft/onw/resolve/main/install.sh | bash ``` onw は `~/onw` に入り、画面右上に onw のアイコンが出ます。 > 貼り付ける前に中身を確認したい場合は、[install.ps1](install.ps1)／[install.sh](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](https://github.com/intel/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 ウィンドウの「サーバー」タブ（Gemma 4 E4B が動作中） 画面ごとの詳しい使い方（モデルの管理、チャット画面と会話の履歴、検証ページ、設定の各項目、困ったとき）は **[使い方マニュアル](MANUAL.md)** にあります。 ### モデル一覧 | onw モデル | アーキテクチャ | 入力 | 思考 | NPU 3720 生成速度 | ダウンロード | 使用メモリ | |---|---|---|---|---|---|---| | [ryugyosoft/gemma-4-E4B-it-onw](https://huggingface.co/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](https://huggingface.co/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](https://huggingface.co/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](https://huggingface.co/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](https://huggingface.co/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/Qwen3.6-35B-A3B-nf4-onw](https://huggingface.co/ryugyosoft/Qwen3.6-35B-A3B-nf4-onw) | `qwen3_5_moe`（上の NF4 版：エキスパート以外の重みをチャネル単位 NF4 に。**Lunar Lake 以降専用**） | テキスト＋画像 | 切替 | —（Panther Lake で約 15.6 tok/s） | 17 GB | 約 18 GB（SSD から読めば 8〜13 GB） | | [ryugyosoft/Ornith-1.5-9B-onw](https://huggingface.co/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](https://huggingface.co/ryugyosoft/Ornith-1.5-9B-nf4-onw) | 同上、重みはチャネル単位 NF4、MTP 先読み付き（**Lunar Lake 以降専用**） | テキスト＋画像 | 切替 | —（Lunar Lake で約 15 tok/s、通常版の約 2 倍） | 5.6 GB | 通常版の約 85% | | [ryugyosoft/Ternary-Bonsai-2-27B-onw](https://huggingface.co/ryugyosoft/Ternary-Bonsai-2-27B-onw) | `qwen3_5`（Qwen3.8-27B を三値の重みで学習し直した Ternary Bonsai 2。重みは 2 ビットのまま。**Lunar Lake 以降専用**） | テキスト | 切替（既定オフ） | —（Lunar Lake で約 4 tok/s。プロンプトは 1 トークンずつ） | 7.6 GB | 約 10 GB | | [ryugyosoft/Ternary-Bonsai-2-9B-onw](https://huggingface.co/ryugyosoft/Ternary-Bonsai-2-9B-onw) | `qwen3_5`（Qwen3.5-9B を三値の重みで学習し直した Ternary Bonsai 2。重みは 2 ビットのまま。**Lunar Lake 以降専用**） | テキスト＋画像 | 切替 | —（Lunar Lake で約 13 tok/s。3.2.0 からプロンプトは 64 トークンずつ） | 3.0 GB | 約 3.5 GB | | [ryugyosoft/Ternary-Bonsai-2-4B-onw](https://huggingface.co/ryugyosoft/Ternary-Bonsai-2-4B-onw) | `qwen3_5`（同じく Qwen3.5-4B の三値版。**Lunar Lake 以降専用**） | テキスト＋画像 | 切替 | —（Lunar Lake で約 21 tok/s。3.2.0 からプロンプトは 64 トークンずつ） | 1.8 GB | 約 2 GB | | [ryugyosoft/NeoHorse-1-4B-onw](https://huggingface.co/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](https://huggingface.co/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](https://huggingface.co/ryugyosoft/granite-4.2-8b-onw) | `granite`（同上の 8B） | テキスト | 切替 | 3.6 tok/s（チャット約 3.9） | 5.0 GB | 約 13 GB | | [ryugyosoft/granite-4.2-3b-nf4-onw](https://huggingface.co/ryugyosoft/granite-4.2-3b-nf4-onw) | 3B の NF4 版（重みはチャネル単位 NF4、q/k/v・down_proj は INT8。**Lunar Lake 以降専用**） | テキスト | 切替 | —（Panther Lake で約 23 tok/s） | 2.6 GB | 約 4.8 GB | | [ryugyosoft/granite-4.2-8b-nf4-onw](https://huggingface.co/ryugyosoft/granite-4.2-8b-nf4-onw) | 8B の NF4 版（同上。**Lunar Lake 以降専用**） | テキスト | 切替 | —（Panther Lake で約 13 tok/s） | 6.2 GB | 約 9.8 GB | | [ryugyosoft/llm-jp-4.1-8b-thinking-onw](https://huggingface.co/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-nf4-onw](https://huggingface.co/ryugyosoft/llm-jp-4.1-8b-thinking-nf4-onw) | 同上、NF4 版（q/k/v・down_proj は INT8。**Lunar Lake 以降専用**） | テキスト | **常に** | —（Panther Lake で約 14 tok/s） | 6.1 GB | 約 9.7 GB | | [ryugyosoft/llm-jp-4.1-8b-thinking-int8-onw](https://huggingface.co/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](https://huggingface.co/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](https://huggingface.co/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](https://huggingface.co/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](https://huggingface.co/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 でだけ一覧に出します。onw 2.1.0 では Granite 4.2 3B／8B と llm-jp-4.1-8B にも NF4 版を加えました（q/k/v_proj と down_proj だけチャネル単位 INT8。INT4 版より元のモデルに近く、Panther Lake の Granite 4.2 8B で、onw 2.0.3 の INT4 版より生成が約 1.7 倍）。 **2 ビット版（onw 1.4.9、Lunar Lake 以降専用）**：Lunar Lake 以降の NPU は 2 ビットの重みも計算できます。Ternary Bonsai 2 27B は三値（−1・0・+1）で 学習されたモデルで、重みを 2 ビットのまま NPU に載せると 27B がメモリ約 10 GB で動きます。ただし今の NPU コンパイラーは 2 ビットの重みを複数トークンの ブロックで計算すると間違えるため、プロンプトは 1 トークンずつ（約 4 tok/s）処理します。実用というより「NPU で 27B が動く」ロマン向けです（Intel に報告済み）。onw 1.4.13 では同じ三値の Ternary Bonsai 2 9B / 4B も加えました。こちらは画像も読め、メモリ約 3.5 GB / 約 2 GB と軽く、Lunar Lake で生成約 13 / 21 tok/s です。onw 3.2.0 では、NPU キットのコンパイラーでこの不具合を直し、9B / 4B に 64 トークン用のグラフを加えました（2 ビットの重みは 1 組のまま共有。Panther Lake でプロンプト約 190 / 300 tok/s）。27B も試作しましたが、NPU のメモリを 13.8 GB 使うため出していません（1 トークンずつのまま）。 **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 に置いたまま動かせます（設定の「エキスパートのメモリ」。仕組みは[技術解説](TECHNICAL.md)）。 プロンプト（入力した文章）の読み込みは、dense モデルは 64 トークンずつ、Qwen3.6 系はプロンプト全体を層ごとにまとめて 処理します（onw 2.0）。NPU 3720 で Qwen3.5-9B 約 80〜87 tok/s、llm-jp-4.1-8B 約 110、Granite 4.2 3B 約 140、Qwen3.6-35B-A3B 約 100 tok/s（メモリ 24 GB 以上）、Panther Lake で Qwen3.5-9B 約 157、Qwen3.6-35B-A3B 約 147 tok/s です。 先読み検証は、検証ブロックが十分安く済むモデル（LFM 系、Lunar Lake 以降の Qwen3.5-9B・Gemma など）で自動的に使われます。 「思考」の列の「切替」のモデル（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 系は自分の PC で変換して使う LiquidAI の LFM2.5-24B-A2B・LFM2.5-2.6B・LFM2-8B-A1B も onw で動きますが、変換済みのモデルは配布していません。LFM のライセンス （LFM Open License v1.0）は、年間売上 1000 万ドル以上の法人による商用利用を対象外にしているためです。元のモデルを Hugging Face から取得して、手元で変換します（onw だけで変換できます）。 - **LFM2.5-24B-A2B（onw 3.3.0、Lunar Lake 以降専用）**：onw ウィンドウの「モデル」タブに出ます。「ダウンロードして変換」を押すと、 元のモデル（約 48 GB）を Liquid AI のリポジトリから取得してこの PC で NF4 に変換し、元のファイルを消します（約 12 GB が残ります。 変換中は約 60 GB の空きが必要です）。onw が配布するのは変換の設定（[ryugyosoft/LFM2.5-24B-A2B-onw-kit](https://huggingface.co/ryugyosoft/LFM2.5-24B-A2B-onw-kit)）だけです。 - **LFM2.5-2.6B・LFM2-8B-A1B**：手順は **[LFM を自分で変換](CONVERT_LFM.md)** にあります（1〜数分）。AI アシスタントにそのページを 読ませれば、そのまま実行できる形で書いてあります。24B もこの手順で変換できます。 | モデル（自分で変換） | アーキテクチャ | 入力 | 生成速度 | 変換後の大きさ | 使用メモリ | |---|---|---|---|---|---| | [LiquidAI/LFM2.5-24B-A2B](https://huggingface.co/LiquidAI/LFM2.5-24B-A2B) | `lfm2_moe`（MoE 64 個から 4 個、24B のうち 1 トークン約 2B。NF4） | テキスト | Panther Lake で約 20 tok/s（プロンプト約 400 tok/s） | 12 GB | 約 12.6 GB | | [LiquidAI/LFM2.5-2.6B](https://huggingface.co/LiquidAI/LFM2.5-2.6B) | `lfm2`（短い畳み込み＋GQA、dense） | テキスト | NPU 3720 で 12〜13 tok/s（コード修正・要約では先読み検証で 29〜34） | 1.5 GB | 約 4.3 GB | | [LiquidAI/LFM2-8B-A1B](https://huggingface.co/LiquidAI/LFM2-8B-A1B) | `lfm2_moe`（短い畳み込み＋GQA＋MoE 32 個から 4 個） | テキスト | NPU 3720 で 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 などから使えます）にも 答えます。つなぎ方は[使い方マニュアル](MANUAL.md#他のアプリから使う（openai-互換-api-ほか）)にあります。 他のアプリからは 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` コマンドと設定 ```bash 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 トークン処理（dense モデルのプロンプトを 64 トークンずつ。auto はオンで、16 トークン用のグラフの代わりに読み込む。off で 16 トークンずつ、`ONW_S64=1` で両方） | `ONW_S64=1/0`／設定画面 | 初回のみ | | MTP 先読み（Qwen3.5 系 NF4 版。auto は Lunar Lake 以降でオン） | `ONW_MTP=1/0` | 初回のみ | | 融合グラフ（dense モデルの区間を 1 回の呼び出しで。回答用と、Lunar Lake 以降はプロンプト用も。onw の NPU キットが使える Lunar Lake 以降の PC では既定でオン） | `ONW_FUSED=0`（無効）／`1`（キットなしでも有効。キャッシュがモデルの約 6〜7 倍になる）、`ONW_FUSED_PROMPT=0`（回答だけ） | 初回のみ | | onw の NPU キット（Windows・Linux。重みを持たないグラフと重みの共有、コンパイラーの修正） | `ONW_NPUKIT=0`（OpenVINO 自身の NPU プラグインを使う） | 起動時 | | Qwen 系の高速化（Qwen3.5・Ornith などを NPUW の代わりに融合グラフと MTP 先読みで。Lunar Lake 以降・キットあり。メモリ約 +0.9 GB。メモリ節約モードでは使わない） | 設定画面「速度」タブ、`ONW_FAST_DENSE=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`（[技術解説](TECHNICAL.md)の「モデルを小さくする」） | 必要（変換し直し） | KV キャッシュは INT8 で、会話が実際に使った長さの分だけメモリ（1K トークンあたり 8〜16 MB）と計算がかかります。 コンテキスト長は「そこまで伸ばしてよい上限」なので、大きくしても短い会話は遅くなりません（仕組みは[技術解説](TECHNICAL.md)）。 `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）の有無で速さが 大きく変わるので、使わない同士・使う同士で並べています。 NPU・iGPU・CPU の 1 トークンあたりの電力、生成速度、生成中の平均温度（先読みなし／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 セクションの大きさで、命令の数そのものではありません。） ### 既知の問題（onw 3.3.0、2026 年 10 月 24 日） - **LFM2.5-24B-A2B（3.3.0）はメモリ 16 GB の PC では未確認です**：使用メモリは約 12.6 GB（うちエキスパート 11.5 GB）で、24 GB 未満の PC ではエキスパートを SSD から読み、プロンプトのまとめ計算も使いません（Panther Lake 64 GB で確認）。また、初回のロード（約 2 分）の直後だけ、最初の質問の読み込みに約 3 秒かかります（2 回目以降のロードでは約 0.8 秒）。 - **Ternary Bonsai 2 27B の 64 トークン用グラフは試作したが失敗**：NPU のメモリを 13.8 GB 使い（グラフごとに要る 2 ビットの重みテーブルが 1 組 3.4 GB）、16 GB の PC に載らないため出していません。27B のプロンプトは 1 トークンずつのままです。Intel に要望しています。 - **Ternary Bonsai 2 の 64 トークン版の初回のロードは長め**：Panther Lake で 4B 約 6 分、9B 約 12 分（2 回目以降は 20〜35 秒）。 - **Qwen 系の高速化をオンにした最初のロードは長め**：融合グラフのコンパイルが加わります（Panther Lake の小型機の Qwen3.5-9B NF4：使い始めるまで約 13 分、残りの種類は回答しながら裏で約 25 分）。2 回目以降はキャッシュから数十秒です。 - **INT4 版のモデルと Meteor Lake・Arrow Lake（NPU 3720）は 2.1.0 と同じです**：INT4 の重みは重みを持たないグラフにできず、NPU 3720 は それに対応していないので、キャッシュとメモリは 2.1.0 と同じで、融合グラフも使いません。Lunar Lake 以降では NF4 版を勧めます。 - **長い会話では生成が遅くなります**：文脈が長いほど毎回読む KV キャッシュが増えるためです（Panther Lake の Granite 4.2 3B NF4： 約 7.3K トークンで 13.6 tok/s、約 15K で 8.8 tok/s、約 22K で 4.9 tok/s。従来の経路の約 2〜3 倍です）。 - **初回のロード（Panther Lake の小型機 Core Ultra X7 358H、3.0）**：Granite 4.2 8B NF4 約 12 分、llm-jp-4.1-8B NF4 約 10 分、 Granite 4.2 3B NF4 約 6.5 分、Qwen3.5-9B NF4 約 7.5 分。残りの融合グラフは、回答しながら裏でコンパイルします（4K 位置までで 7〜10 分、32K 位置まで全部で Granite 4.2 3B NF4 は約 28 分）。 2 回目以降はキャッシュから数十秒です。ロードを途中で止めたり PC が再起動したりしても、コンパイルの済んだ部分は残ります。 - **Panther Lake の小型機では、MTP 先読みの生成が Lunar Lake より遅い**：Qwen3.5-9B（NF4）＋ MTP の生成は、Panther Lake の 小型機で 13.6〜14.3 tok/s（Lunar Lake は約 19 tok/s）でした。MTP は CPU 側の処理が多く、電力の制限で定格まで落ちる小型機の CPU が効いていると見て調査中です。 - **Panther Lake では、Qwen3.5 系は NF4 版のほうが速い**：1024 トークンのプロンプトが NF4 版で約 280 tok/s、INT4 版で約 160 tok/s、 初回のロードも NF4 版が約半分です。 - **メモリ 24 GB 未満の PC では、Qwen3.6 系のプロンプトの高速化（2.0）は使われません**：16 GB の Lunar Lake では、そのための グラフのコンパイル中にメモリが足りなくなるためです。 ## ライセンス コードは Apache 2.0。変換済みモデルは元のモデルのライセンスに従います（各モデルのリポジトリを参照）。