onw

<img src="images/onw-banner.jpg" alt="onw" width="100%">

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

日本語 | English

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

私たちの知る限り、次の 4 つを 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 は開発版で対応を進めていますが、一般に使える形では未公開）
• メモリに入りきらない MoE を、エキスパートを SSD から読みながら Intel NPU で動かすオープンソースの実装（プロンプト処理と生成の両方でエキスパートを NPU で計算。LRU キャッシュ＋OS のキャッシュを通さない直接読み込み）。似た試みには、Qualcomm の NPU 向けの論文（PowerInfer-2、EStream、BigMoMo。コードは非公開）と、Apple の Neural Engine でプロンプト処理だけを行う ds4-ssd があります（2026 年 9 月、Fable 5.1 調べ）。

はじめに

必要なもの

• 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 がおすすめです。 選んで「ダウンロード」を押すと、進み具合がバーで表示されます。

<img src="images/onw-models.png" width="640" alt="onw ウィンドウの「モデル」タブ">

• 保存先は「保存先」の「変更…」で好きなドライブにできます（C ドライブが狭いときなど）。
• すでにモデルを別の場所に持っている場合（hf download で入れた、自分で変換した など）は、「ほかの場所」の「追加…」で そのフォルダ（またはモデルのフォルダをまとめて入れた親フォルダ）を選べば一覧に出ます。コピーは不要です。
• 画面の言語は OS に合わせて日本語・英語・中国語（簡体字）から選ばれます。「設定」タブの「言語」で変えられます。

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 ごと終わるときは「終了」です。

<img src="images/onw-server.png" width="49%" alt="「サーバー」タブ"> <img src="images/onw-settings.png" width="49%" alt="「設定」タブ">

上級者向けの入手方法

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

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

コンテキスト長を長くすると、短い会話でも 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 をそのまま 渡してください。

モデル

使用メモリは、テスト機（Core Ultra 9 285HX、NPU 3720）で、64 トークン処理なし・画像エンコーダーは使ったら解放（メモリ 24 GB 未満の PC の既定）で測ったプロセスのピークです。先読み検証は、16 トークンの検証ブロックが十分安く済むモデル （LFM2、Qwen3.5-9B、Gemma）で自動的に使われます。どのモデルも会話の状態をターン間で保持するので、画像付きの会話でも 2 ターン目は新しいメッセージだけを処理します（約 2 秒）。

onw ウィンドウの「メモリ目安」は、この値にその PC の設定（コンテキスト長、64 トークン処理、エキスパートのメモリ）を 反映した目安です。

onw 0.7 でのメモリ削減

同じモデルのままエンジン側だけで、使用メモリを 2〜6 割減らしました（テスト機での実測、ピーク）。

• コンパイル結果の二重持ちをやめた：OpenVINO のキャッシュから読み込んだモデルは、あとで書き出せるように コンパイル結果（blob）を保持し続けます。NPU ドライバーは読み込み時に重みを自分のメモリへ写すので、同じものを 2 つ 持っていました。onw は blob を自分で保存・読み込み（npu_cache/onw_blobs）、ドライバーへ渡したら手放します （Qwen3.6-35B で 1 トークン版・16 トークン版それぞれ 1.1〜1.4 GB）。
• 画像エンコーダーは画像が来たときだけ読み込み、メモリ 24 GB 未満の PC では画像を処理したらすぐ解放します （読み込み直しは 1〜5 秒。ONW_KEEP_VISION=1 で残す）。
• CPU で引くだけの表は NPU 用メモリに写さない：埋め込み表と Gemma の層ごとの埋め込み表（1.4 GB）はファイルの メモリマップのまま使い、引いた行だけがメモリに載ります。
• エキスパートの読み込みは OS のキャッシュを通さない：起動時に一時的に同じデータが二重に載ることがなくなり、 起動も速くなりました（LFM2 で 30 秒 → 6 秒）。
• 調べた道具：mem_breakdown.py（段階ごとの内訳）、mem_stages.py（区間の読み込み段階ごと）、mem_import.py （blob の読み込み方の比較）、mem_vision.py、mem_all.py（全モデル）。

モデルを小さくする（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% と落ち方が大きいため、刈り込んでいません。

メモリが足りないとき：エキスパートを SSD から読む（Qwen3.6 系）

MoE は 1 トークンごとに一部のエキスパートしか使いません（Qwen3.6-35B-A3B なら 40 層 × 256 個のうち、各層 8 個）。 そこで、エキスパートは SSD に置いたままにして、ルーターが選んだものだけを読み込み、最近使ったものをメモリに残します （LRU キャッシュ）。読み込みは OS のファイルキャッシュを通さない直接読み込み（Windows は FILE_FLAG_NO_BUFFERING、 Linux は O_DIRECT）で、8 並列です。OS のキャッシュに同じデータがもう一度溜まってメモリを圧迫することはありません。

• 設定画面の「エキスパートのメモリ」：auto（既定）は、モデル全体がメモリの 85% に収まらないときだけ SSD から読みます。 メモリは「約 4.8 GB＋キャッシュ」になり、16 GB の PC では Qwen3.6-35B-A3B が約 8 GB のキャッシュ（当たり率 9 割強）に なります（Qwen3.6-REAP は SSD から読まずに収まります）。GB を指定することもできます。 コマンドでは ONW_EXPERT_GB=5 onw serve …。
• 実測（Qwen3.6-35B-A3B、NPU 3720、USB 接続の SSD、キャッシュ 5 GB＝全エキスパートの 33%）：

回答はすべてメモリの場合と同じです。速さのための工夫は次のとおりで、どれもメモリを増やしません。

1. プロンプトは層ごとに処理：全部の 16 トークンの塊を 1 層目に通し、次に 2 層目…の順です。各層の状態はその層の前の 塊にしか依存しないので結果は同じで、各層のエキスパートはプロンプト全体で 1 回ずつ読むだけになります（塊ごとに全層を 通す順では 44 秒・33 GB 読み込み）。
2. プロンプト処理の先読み：ある塊が次の層で使うエキスパートは、その塊がこの層を終えた時点で分かるので、NPU が次の 塊を計算している間に読み始めます（24 秒 → 15 秒。別のバッファは使わず、キャッシュの枠に直接読み込み）。
3. 生成時の予測先読み（既定はオフ）：区間を NPU に渡す前に、1 層前の状態にその層のルーターを当てて上位を予測し、 NPU の計算中に読み始めます。予測は本物の上位 8 個の 92% を当て（12 個予測時）、生成は 5.8 → 6.5 tok/s になりますが、 外れた予測の分まで読むので CPU 時間が 1 トークンあたり 51 → 78〜85 ms に増えます。8 コアの Lunar Lake では負担が 大きいため既定では使いません（ONW_PREFETCH_K=12 で有効。ルーターの重み 80 MB が増えます）。

• LFM2-8B-A1B は 16 トークン処理で 32 個のエキスパートを一度に使う作りのため、この方式の対象外です（もともと 6 GB で動きます）。
• 調べた道具：trace_experts.py（実際の会話で選ばれたエキスパートを記録）、sim_expert_cache.py（キャッシュの大きさごとの 当たり率を計算）、bench_ssd.py（SSD の読み込み速度）、test_stream.py（SSD 読み込みでの速度とメモリ）。

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 個を 結び付けます。

エンジンの構成

注意点と制限

• コンテキスト長の既定は 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。変換済みモデルは元のモデルのライセンスに従います（各モデルのリポジトリを参照）。