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

日本語 | English

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

私たちの知る限り、次の 3 つを NPU だけで動かして公開している実装は onw が初めてです（2026 年 9 月、Fable 5.1 調べ）。

• 画像エンコーダーまで含めた VLM 全体（Intel 公式の OpenVINO GenAI は画像エンコーダーを CPU で動かします）
• Gated DeltaNet 混在のハイブリッドモデル（Qwen3.5／Qwen3.6。OpenVINO 公式は CPU・GPU のみ対応）
• MoE のエキスパート計算（Qwen3.6-35B-A3B、LFM2-8B-A1B。Intel は開発版で対応を進めていますが、一般に使える形では未公開）

はじめに

必要なもの

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

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

1. インストール（コマンドを 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 を最新版に更新できます。

2. モデルを選んでダウンロード

開いた onw ウィンドウ の「モデル」タブに、使えるモデルの一覧（サイズ、必要なメモリ、この PC で足りるか）が 出ます。迷ったら、16 GB の PC なら LFM2-8B-A1B（最速・4 GB）、画像も使いたいなら Gemma 4 E4B がおすすめです。 選んで「ダウンロード」を押すと、進み具合がバーで表示されます。

• 保存先は「保存先を変更…」で好きなドライブにできます（C ドライブが狭いときなど）。
• すでにモデルを別の場所に持っている場合（hf download で入れた、自分で変換した など）は、「モデルのある場所を追加…」で そのフォルダ（またはモデルのフォルダをまとめて入れた親フォルダ）を選べば一覧に出ます。コピーは不要です。

3. 使う

「サーバー」タブでモデルを選んで「ロード」を押します。初回だけ NPU 向けの準備（コンパイル）に 10〜30 分ほど かかります（モデルと PC によります。テスト機では LFM2 が約 1.5 分、Gemma 4 E4B が約 11 分、Qwen3.5-9B が約 13 分）。 状態が「動作中」になるまで待ってください。その間も PC は普通に使えます。2 回目以降は結果が保存されているので 20 秒ほどで起動します（コンテキスト長を変えたときだけ、もう一度コンパイルします）。

• すぐ試す：「チャットを開く」でブラウザにチャット画面が出ます。「検証ページを開く」では、速度や画像の テストを一括で実行できます。
• 他のアプリから使う：onw は OpenAI 互換 API です。OpenAI の API に対応したアプリ（チャットアプリ、エディターの 拡張機能、自作のプログラムなど）で、base URL に http://localhost:8000/v1、モデル名にウィンドウに表示される 名前を入れれば使えます。API キーの欄は、設定していなければ何を入れても構いません。

あとは、タスクトレイ（Ubuntu は右上）の onw アイコンを右クリックすれば、いつでもウィンドウやチャットを開けます。 ウィンドウを閉じてもサーバーは動き続けます。止めるときはメニューの「サーバーを停止」、onw ごと終わるときは「終了」です。

上級者向けの入手方法

• 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 すると、重みの代わりに小さな「ポインタ」ファイルしか入りません （onw はこれを検出して止まります）。
• コンソールで一度だけ起動したいときは start.bat モデル名（Ubuntu は bash start.sh モデル名）。

サーバー（OpenAI 互換 API）

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

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）	サーバーのオプション／設定画面	長さごとに 1 回（入力の形が変わるだけで、モデルファイルはそのまま）
64 トークン処理（Gemma）	ONW_S64=1/0／設定画面	初回のみ
NPUW 重み共有（試験的。auto は Lunar Lake 以降でオン、MoE モデル（LFM2・Qwen3.6）は対象外：重みを 1 コピーにしてメモリとコンパイル時間を削減）	ONW_NPUW=1/0／設定画面	初回のみ
ブロックサイズ、画像サイズ、量子化	onw convert	必要（変換し直し）

コンテキスト長を長くすると、短い会話でも 1 トークンごとの計算とメモリが増えます（固定長の KV キャッシュ全体を 毎回参照するため）。モデルの最大値ではなく、必要な長さを選んでください。

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

Git LFS への対策：Git LFS なしで git clone したモデルには、重みの代わりに約 130 バイトの「ポインタ」ファイルしか 入っていません。onw はこれを検出し、直し方を表示して止まります。hf download を使うか、リポジトリ ID をそのまま 渡してください。

モデル

onw モデル	アーキテクチャ	入力	NPU 3720 生成速度	ダウンロード	使用メモリ
ryugyosoft/LFM2-8B-A1B-onw	lfm2_moe（短い畳み込み＋GQA＋MoE 32 個から 4 個）	テキスト	16〜17 tok/s（コード修正・要約では先読み検証で 29〜43）	4.0 GB	約 6 GB
ryugyosoft/gemma-4-E4B-it-onw	gemma4（検証済みの Gemma NPU グラフを取り込み）	テキスト＋画像	7.2 tok/s	4.3 GB	約 15 GB
ryugyosoft/Qwen3.5-9B-onw	qwen3_5（Gated DeltaNet＋ゲート付きアテンション、dense）	テキスト＋画像	4.1 tok/s	5.3 GB	約 20 GB
ryugyosoft/Qwen3.6-REAP-18B-A3B-onw	qwen3_5_moe、256 個中 128 個のエキスパートを残す（REAP）	テキスト＋画像	6.8 tok/s	9.6 GB	約 15 GB
ryugyosoft/Qwen3.6-35B-A3B-onw	qwen3_5_moe（Gated DeltaNet＋ゲート付きアテンション＋MoE 256 個から 8 個＋共有エキスパート）	テキスト＋画像	6.8 tok/s	17 GB	約 23 GB

使用メモリは、テスト機（Core Ultra 9 285HX）で読み込んだあとのプロセスの作業セットです（OS が必要に応じて手放せる、 メモリマップされた重みファイル分を含みます）。先読み検証は、16 トークンの検証ブロックが十分安く済むモデル （LFM2、Qwen3.5-9B、Gemma）で自動的に使われます。どのモデルも会話の状態をターン間で保持するので、画像付きの会話でも 2 ターン目は新しいメッセージだけを処理します（約 2 秒）。

onw ウィンドウの「メモリ目安」は、その PC と設定（コンテキスト長、64 トークン処理）から計算した、実際に必要な量の目安です。OS が手放せるメモリマップ分を除くので、この表より小さくなります（例：16 GB の PC で Gemma 約 11 GB、Qwen3.5-9B 約 13 GB）。16 GB の PC での実測はまだです。

モデルを小さくする（onw convert --compact / --prune）

• --compact：1 トークン用と 16／64 トークン用のグラフが同じ重みファイルを共有します（ダウンロード量・ディスク）。 ホスト側で引くだけの表（出力層と共有していない埋め込み、Gemma の層ごとの埋め込み）は 32 要素ごとのスケール付き INT4 に、Qwen の画像エンコーダーは INT8 にします。これらは使用メモリも減らしますが、重みファイルの共有だけは ディスクにしか効きません（NPU はブロックサイズごとにコンパイル済みの重みを持つため）。
• --prune SAL.json --keep 0.5（MoE）：REAP によるエキスパートの刈り込み。python -m onw.prune calibrate HF_DIR SAL.json で各エキスパートの寄与度（日本語・英語・コードのチャットデータでの「ルーターの重み×出力の大きさ」の平均）を測り、 python -m onw.prune eval で残す割合ごとのパープレキシティを確認できます。Qwen3.6-35B-A3B は 256 個中 128 個を 残してパープレキシティ +8.9%（Qwen3.6-REAP-18B-A3B-onw として公開）。エキスパートが 32 個しかない LFM2 は 半分で +35% と落ち方が大きいため、刈り込んでいません。

MoE を NPU で動かす仕組み

NPU は形の決まったグラフしか扱えませんが、MoE はトークンごとに違うエキスパートを選びます。NPU 3720 で Qwen3.6 の 寸法の 1 層・1 トークンを測ると、全エキスパートを計算すると 45 ms、グラフ内の Gather で選ぶ方式は INT4 定数では コンパイルできず、INT8 や詰め込み形式でも 18〜135 ms（NPU が表全体を転送するため）でした。 選んだエキスパートを実行時の入力として渡す方式なら 1.7 ms で、NPU のメモリ帯域いっぱいに出ます。そこで：

• ネットワークを MoE のルーターの直後で区間に分け、ルーターの上位 k 個をホストが受け取って、次の区間に選ばれた エキスパートの重みバッファを結び付けます（set_tensor、コピーなし。全エキスパートは NPU から見えるホストメモリ上の experts.bin にあります）。
• エキスパートは チャネル単位 INT4 を 1 エキスパート 1 テンソルに詰めた形 にします。実行時に渡す重みを NPU が 全速で扱えるのはこの形だけです（グループ単位のスケールを付けると要素ごとの遅い処理になり、20 倍遅くなります）。
• それ以外は区間の中のグループ 128 の INT4 定数です。出力層は共有の INT8 入力として独立した区間に置き（ブロック サイズが違っても 1 つだけ、ロジットが不要なプロンプト処理では飛ばす）、埋め込みと Gemma の 2.7 GB の層ごとの 埋め込みはホストで引きます（実行時入力からの Gather は NPU が表全体を転送するため）。
• プロンプトのブロックではブロック内の全トークンが選んだエキスパートの和集合を、生成時はそのトークンの上位 k 個を 結び付けます。

エンジンの構成

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

注意点と制限

• コンテキスト長の既定は 1024 トークンです。--context／設定画面で読み込み時に変えられます（長さごとに NPU 向け コンパイルが 1 回走ります）。Qwen の画像は 512×512（256 トークン）に縮小し、Gemma の画像は縦横比を保ちます （最大 280 トークン）。
• エキスパートはチャネル単位 INT4（四捨五入量子化）です。確認した範囲では、最初のトークンのロジットは bf16 との差が 約 33% で、1 位の予測は一致しました。回答は自然ですが、数トークン先から言い回しが bf16 モデルと分かれます。
• 16 トークンより大きいプロンプトブロック（Gemma の 64 トークン版）は RAM 24 GB 以上のときだけ読み込みます （ONW_S64=1/0 で強制）。
• OpenVINO のプレリリース版（2026.5 nightly）が必要です。NPU 3720（Windows 11）で動作確認済み、CPU での動作は Ubuntu 22.04（WSL）で確認しています。NPU 4000（Lunar Lake）と Ubuntu の右上常駐は、このエンジンではまだ未確認です。

ライセンス

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