CHANGELOG.md

更新履歴

日本語 | English

日付は日本時間です。各版は Hugging Face の ryugyosoft/onw にタグ（v0.4.2 以降）付きで残っています。 onw ウィンドウは、新しい版があるとこのファイルから変更点を表示します（## v… の見出しで区切っています）。

v3.2.1 (2026-10-20)

• MoE（Qwen3.6-35B-A3B など）の生成を速く（モデルの更新は不要）：Panther Lake の Qwen3.6-35B-A3B で、生成 10.7 → 13.1 tok/s（短い文脈）、約 6,000 トークンの文脈で 7.0 → 約 10 tok/s。答えは同じで、メモリも増えていません。
  • 前のトークンと同じエキスパートは、結び付け直しません（新しく選ばれたものだけを、1 回の呼び出しで結び付ける。ホスト側 9.6 → 4.7 ms／トークン）。
  • アテンションの要求を、MoE でも最初に一度だけ結び付けます（最大 48 個。それを超えたブロックは従来どおり。アテンション 10.9 → 7.2 ms）。
  • 出力層のグラフだけを、プロファイリングをオンにしてコンパイルします。NPU コンパイラーは、そのときだけ語彙 × 隠れ次元の大きな行列積を速く組みます（出力層 17.6 → 5.6 ms。原因はコンパイラー側で調査中）。
• 新しいモデル Qwen3.6-35B-A3B（NF4）（Lunar Lake 以降専用）：エキスパート以外の重みを元の bf16 からチャネル単位の NF4（フル アテンションの q/k/v は INT8）に変換し直した版です。エキスパートは通常版と同じです。Panther Lake で生成 15.6 tok/s、プロンプト 161 tok/s、プロセスのメモリ 1.5 GB（通常版 4.0 GB）、NPU のメモリ 17.2 GB（同 19.5 GB）。Lunar Lake（16 GB、エキスパートは SSD から）では、通常版と同じ速さ（約 10 tok/s）でメモリが 0.9 GB 少なくなります。
• 古いダウンロードの Qwen3.6 系はモデルの更新を：2.0 で入れた「プロンプトをエキスパートごとにまとめる」グラフ（mixer）を含まない古いダウンロードでは、プロンプトが約 25 tok/s のままです（更新後は Panther Lake で約 140 tok/s）。モデルの一覧に「更新」が出ます。

v3.2.0 (2026-10-20)

• Ternary Bonsai 2 4B／9B のプロンプト処理を 10 倍以上に（64 トークン用グラフ、2 ビットの重みは 1 組のまま）：これまで 2 ビットの重みは 1 トークンずつしか正しく計算できず、プロンプトも 1 トークンずつでした。onw の NPU キットのコンパイラーで 64 トークンのブロックを正しく速く計算できるようにし、NPU 上の 2 ビットの重みを 1 トークン用と 64 トークン用のグラフで共有します（重みを 2 組持たない）。モデルの更新（64 トークン用のグラフ入り）が必要です（モデルの一覧に「更新」が出ます。新しいグラフは onw 3.2 以降だけが使い、3.1.0 以前はこれまでどおり 1 トークンずつ動きます）。Panther Lake（Core Ultra X7 358H）、3.1.0 との比較：
  • Bonsai 2 4B：約 1,200 トークンのプロンプト 25 → 約 300 tok/s、生成 20〜21.6 → 約 22 tok/s、専用メモリ 2.96 → 約 2.1 GB、初回のロード 約 3.6 → 約 6 分（2 回目以降 約 20 秒）。
  • Bonsai 2 9B：プロンプト 約 190 tok/s、生成 約 14.5 tok/s、専用メモリ 約 3.2 GB、初回のロード 約 12 分（2 回目以降 約 35 秒）。
  • 画像の質問も、64 トークンのブロックで読み込みます。
  • 正直に書くと、NPU のメモリは 2 ビットの重みよりずっと大きく、ここは失敗です：重みとスケール 約 0.9 / 2.1 GB に対してNPU 約 2.6 / 4.5 GB（4B / 9B）。グラフごとに要る重みテーブルが、1 トークン用と 64 トークン用の 2 組で重みと同じくらいあるためです。Intel に改善を要望しています。
• Ternary Bonsai 2 27B は 1 トークン用のグラフのままです（64 トークン用は試作したが失敗）：作って動かすことはできました（プロンプト 約 60 tok/s）が、NPU のメモリを 13.8 GB 使い、16 GB の PC に載りません。2 ビットの重みを NPU で計算するには、グループ（128 個の重み）ごとに 16 バイトの「重みテーブル」がグラフごとに必要で、27B ではグラフ 1 組あたり 3.4 GB になるためです。初回のコンパイルも Panther Lake で 36 分かかりました。Intel に改善を要望しています。
• 初回のロードを速く：コンパイルを複数のプロセスで同時に：NPU のコンパイラーはグラフ 1 つに CPU を約 1 コアしか使わないので、空きメモリとコア数に応じて最大 6 つの子プロセスで同時にコンパイルします（省メモリモードでは最大 2）。子プロセスはコンパイルして保存するだけで、NPU には読み込みません（重みが二重にならない）。Panther Lake で Bonsai 2 4B の 1 トークン用＋64 トークン用のグラフ：819 → 約 180 秒。融合グラフの裏でのコンパイルも、既定で同時に行います。
• NPU コンパイラーの高速化（キット）：戦略探索で同じ計算を繰り返していた所を直し、2 ビットのモデルの 64 トークン用グラフ 1 つのコンパイルが 335 → 約 20 秒になりました（結果のバイナリーは同じ）。
• 融合グラフを使う大きさでは、従来のグラフをメモリから外す：融合グラフが動く範囲では従来のグラフは使わないので、読み込んだあとで外します（重みテーブルの分だけ省メモリ。Bonsai 2 4B：NPU 3.9 → 2.6 GB）。画像の質問や、融合グラフより長い文脈のときだけ、その場で読み込み直します（数秒）。
• 画像エンコーダーを裏でコンパイル：画像の付いたモデルは、初回のロードのあと裏で画像エンコーダーをコンパイルしておき、最初の画像の質問で数分待たないようにしました。
• Linux 版のキットも更新しました（上の修正を含む。Bonsai 2 の 64 トークン用グラフも、Ubuntu の Lunar Lake で確かめました）。
• 2 ビットのモデルでは、融合グラフの長さ違いの種類を全部は常駐させず、1 つずつ入れ替えます（種類ごとに重みテーブルが要るため）。
• 融合グラフでも、最後の正規化の fp16 のあふれで 0 になった行を、縮めて計算し直します（従来のグラフと同じ処理。Bonsai 2 9B の 64 トークンのブロックで、Lunar Lake の 256 行中 20 行が一様分布になっていた）。
• 2 ビットのモデルでは、先読み検証（PLD）を使いません（下書きの確認に 64 トークン用のグラフを使うことになり、Lunar Lake で生成が 23 → 13〜17 tok/s に落ちていた）。

v3.1.0 (2026-10-19)

• Qwen 系を速く（設定「Qwen 系を高速化する」、既定オン）：Qwen3.5・Ornith など、これまで NPUW で動いていたモデルを、Lunar Lake 以降の PC（onw の NPU キット）では区間ごとの融合グラフと MTP 先読みで動かします。重みは 1 組のまま（キットの共有）で、同じ質問には 3.0.0 と同じ答えが返ります。
  • Panther Lake（Core Ultra X7 358H）の Qwen3.5-9B NF4、3.0.0 との比較：約 3.5K トークンのプロンプト 205 → 299 tok/s、約 900 トークン 242 → 280 tok/s、生成 17.9 → 19.3 tok/s。
  • Lunar Lake（Ubuntu）の Ornith-1.5-9B NF4：約 3.5K トークンのプロンプト 224 → 約 320 tok/s、生成 約 16 → 約 21 tok/s。
  • メモリは約 0.9 GB 多く使います（Panther Lake の Qwen3.5-9B NF4：ワーキングセット 5.8 → 6.7 GB）。NPUW は同じ形の層を 1 つにまとめてコンパイルしますが、融合グラフは区間の層をすべて持つためです。オフにすると 3.0.0 と同じです。メモリ節約モードでは、これまでどおり NPUW で動きます。
  • 融合グラフは 4K 位置の種類から使い、会話がそれより長くなると 8K・16K・32K の種類をその場で読み込みます（Qwen3.5 系はアテンション層が 4 層に 1 つなので、長めの種類でも遅くなりにくい）。
• 4K 位置近くまでのプロンプトが遅くなることがあったのを修正：融合グラフの長さ違いの種類を、初めて使うときに 1 つ約 10 秒かけて読み込んでいました。4K 位置までの種類を、起動後に回答していない間に裏で読み込むようにしました（Lunar Lake の Granite 4.2 8B NF4：約 3.7K トークンのプロンプト 84 → 326 tok/s。専用メモリ +0.1 GB）。
• モデル一覧に検索・並べ替え・絞り込み：名前・説明の検索、ダウンロードの大きさ・メモリ目安・名前での並べ替え、重みの形式（NF4・INT8・INT4・2 ビット）とダウンロード済みだけの絞り込み。選んだ条件は覚えておきます。
• NPUW を使わないモデルでも、キットで重みを共有できるときは MTP 先読み（4 トークンの検証用グラフ）を使うようにしました。

v3.0.0 (2026-10-19)

• onw 独自の NPU キット（Windows・Linux）を同梱：NPU のコンパイラーとプラグインを、Intel の公開ソースから onw 用に作り直したもの（onw/npukit、Apache 2.0、変更点は onw/npukit/patches）。onw が入れる OpenVINO 2026.5.0 のときだけ使い、インストール済みの OpenVINO には手を加えません（ONW_NPUKIT=0 で OpenVINO 自身のものに戻せます）。これにより次のことができるようになりました。
  • 重みを持たないコンパイル済みグラフ：キャッシュにはグラフだけを置き、重みはロードのたびにモデルのファイルから NPU 上で組み立てます。キャッシュがモデル本体の 1/10 以下になります（Granite 4.2 8B NF4：10.5 → 0.8 GB、llm-jp-4.1-8B NF4：9.2 → 0.65 GB、Granite 4.2 3B NF4：4.2 → 0.5 GB）。OpenVINO 2026.5 のコンパイラーでは NF4 の重みでこれができませんでした。
  • 同じ重みを NPU 上で 1 つだけ持つ：グラフの種類（ブロックサイズ、文脈の長さごとのグラフ）がいくつあっても、重みは 1 組です。
  • コンパイラーの修正：Qwen3.5 系 NF4 の 4 トークンの検証グラフ（MTP 先読み）、2 ビットの重み（Bonsai）を 2 行以上で計算すると 0 になる不具合、コンパイルの高速化（Panther Lake で Ternary Bonsai 2 9B の初回のロード約 7.5 分、生成約 17 tok/s など）。
• Lunar Lake 以降の PC（Windows・Ubuntu）で、融合グラフを既定で使うように（2.1.0 では試験的・既定オフ）。区間ごとに NPU を 1 回呼ぶだけにして、生成もプロンプトも速くなります。重みを共有するので、メモリは増えず、むしろ減ります。Panther Lake（Core Ultra X7 358H）、2.1.0 の既定との比較：
  • Granite 4.2 8B NF4：生成 約 9 → 約 13 tok/s、約 900 トークンのプロンプト 約 160 → 約 400 tok/s、専用メモリ 11.4 → 約 1.6 GB（ピーク 12.5 → 約 9.8 GB）、1 トークンあたりの電力量 約 1.3 → 約 0.9 J。
  • llm-jp-4.1-8B NF4：生成 約 9.9 → 約 14 tok/s、プロンプト 約 170 → 約 440 tok/s、専用メモリ 11.0 → 約 2.4 GB。
  • Lunar Lake（Ubuntu、16 GB）の Granite 4.2 8B NF4：生成 11〜13 tok/s、約 900 トークンのプロンプト約 385 tok/s、専用メモリ約 2 GB（ピーク 3.3 GB）、キャッシュ 1.8 GB、初回のロード 3.5 分（残りの融合グラフは裏で約 14 分）。
  • Granite 4.2 3B NF4：生成 約 14.3 → 約 23 tok/s、プロンプト 約 235 → 約 730 tok/s、専用メモリ 5.1 → 約 1.4 GB。
  • 長い会話も速く：融合グラフは文脈の長さまで 8K・16K・32K 位置の種類も作ります（2.1.0 は 4K 位置まで、その先は従来の経路）。Granite 4.2 3B NF4、約 7.3K／15K／22K トークンのプロンプト（従来の経路との比較）：生成 4.6 → 13.6／4.0 → 8.8／2.6 → 4.9 tok/s、プロンプト 94 → 170／62 → 146／43 → 74 tok/s。
  • 文脈の長さごとのグラフ（1K〜32K 位置）をすべて読み込んだままにするので、会話の途中で止まらず、同じ質問には同じ答えが返ります。初回のロードは 2.1.0 とほぼ同じで（8B で約 10〜12 分）、残りのグラフは回答しながら裏でコンパイルします。
  • 省メモリモードでは、今までどおり使う長さのグラフだけを読み込みます。
• Qwen3.5 系・Ornith・gemma-4（NPUW で動くモデル）もキャッシュが小さくなります（Qwen3.5-9B NF4：約 0.3 GB）。Qwen3.5-9B NF4 の生成は MTP 先読み付きで約 14〜19 tok/s。
• Ubuntu でもキットを使います（onw/npukit/linux、32 MB の圧縮ファイルを最初の起動で展開）。Lunar Lake（16 GB）の Qwen3.5-9B NF4：初回のロード約 2.2 分、生成 15.5〜20.6 tok/s、プロンプト約 240 tok/s、キャッシュ 0.26 GB、専用メモリ約 1.1 GB。Granite 4.2 3B INT4 は初回のロード 4.7 → 2.7 分（答え・速さは 2.1.0 と同じ）。
• INT4 版のモデル（Granite・llm-jp など区間に分けて動くもの）は、重みを持たないグラフにできない（重みが分離されない）ので、Lunar Lake 以降でも重みを持つグラフ・融合グラフなしの 2.1.0 と同じ動作です。Lunar Lake 以降では NF4 版を勧めます。
• Meteor Lake・Arrow Lake（NPU 3720）は、2.1.0 と同じ動作です（重みを持たないグラフに対応していないため）。
• OpenVINO は 2026.5.0b1 に固定しました（キットがこの版専用のため）。

v2.1.0 (2026-10-18)

• Lunar Lake 以降専用の NF4 版を 3 つ追加：Granite 4.2 3B／8B、llm-jp-4.1-8B-thinking（ryugyosoft/granite-4.2-3b-nf4-onw、granite-4.2-8b-nf4-onw、llm-jp-4.1-8b-thinking-nf4-onw）。重みはチャネル単位の NF4 を基本に、誤差の出やすいアテンションの入力（q/k/v_proj）と down_proj だけをチャネル単位の INT8 にしました。
  • Panther Lake（Core Ultra X7 358H）：Granite 4.2 8B は生成 5.4 → 約 9 tok/s（INT4 版・2.0.3 との比較）、約 900 トークンのプロンプト約 160 tok/s。llm-jp-4.1-8B は生成約 9.9 tok/s・プロンプト約 170 tok/s、Granite 4.2 3B は生成約 14.3 tok/s・プロンプト約 235 tok/s。1 トークンあたりの電力量（パッケージ全体）は 8B で約 1.3 J、3B で約 0.7 J。
  • 精度も INT4 版より元のモデル（bf16）に近くなります（512 トークンの教師強制で 1 位の一致率／KL）：Granite 4.2 3B 81.4% → 82.6%／0.139 → 0.091、Granite 4.2 8B 85.5% → 88.5%／0.132 → 0.097、llm-jp-4.1-8B 83.4% → 90.2%／0.132 → 0.053。
  • ダウンロードは 2.6／6.2／6.1 GB（INT4 版より 0.5〜1.5 GB 大きい）。使用メモリ（プロセスの専用メモリ）は 3B 約 5.1 GB、8B 約 11.4 GB、llm-jp 約 11.0 GB です（NPU 4000 以降では 2 トークン用と 64 トークン用のグラフがそれぞれ重みを持ちます）。初回のロードは 8B で約 11 分、3B で約 5 分です。
  • NF4 は NPU 4 以降でしか計算できないので、Lunar Lake 以降の PC でだけ一覧に出ます。Meteor Lake・Arrow Lake（NPU 3720）は今までどおり INT4 版を使います。
• dense モデルの生成で、区間どうしの入出力を最初に一度だけつないでおくように（2.0 の MoE と同じ「wired」）。毎トークンの受け渡しのコピーがなくなります（ONW_WIRED=0 で無効）。
• アテンションの NPU 呼び出しを層・ブロックごとに用意して入出力を固定：KV キャッシュのテンソルを毎回渡し直さずに済みます（ONW_KV_BOUND=0 で無効。MoE モデルは対象外）。
• Lunar Lake 以降で 2 トークン用のグラフで回答するモデル（Granite 4.2、llm-jp-4.1-8B）は、空いている 2 行目で先読み検証：会話の中から見つけた下書きを 1 トークンだけ一緒に確かめます（今までは 64 トークン用のグラフで 16 トークンを確かめていて、外れると数ステップ分の時間がかかっていました）。貪欲生成のときだけで、結果は同じです。
• 試験的：融合グラフ（既定オフ、ONW_FUSED=1 で有効）：dense モデルの区間のアテンションを INT8 の KV キャッシュの読み出しに置き換え、区間ごとに NPU を 1 回呼ぶだけにします（回答用、Lunar Lake 以降はプロンプト用も）。Panther Lake で生成が Granite 4.2 8B NF4 9 → 約 11 tok/s、Granite 4.2 3B NF4 14.3 → 約 22.5 tok/s、Granite 4.2 3B INT4 12.6 → 約 20 tok/s になります。
  • ただし、1K・2K・4K 位置用の 3 種類 × ブロックサイズごとのグラフがそれぞれ重みの写しを持つので、コンパイル済みのキャッシュがモデルの約 6〜7 倍になります（Granite 4.2 8B NF4 で約 42 GB。既定の経路では約 10.5 GB）。初回は裏でのコンパイルも長く（8B で約 22 分）、会話が 1K・2K・4K 位置を越えるたびに数秒止まります。重みを共有できるようになるまで既定ではオフです。

v2.0.3 (2026-10-18)

• Panther Lake・Lunar Lake で、Granite 4.2 と llm-jp-4.1-8B（INT4）の初回のロードがずっと短く：Panther Lake の Granite 4.2 8B で約 2 時間 45 分 → 約 23 分です。
  • 原因：NPU のコンパイラーは、グループ単位で量子化した INT4 の行列積が 1 行だけのとき（1 トークンずつの生成）、重みのグループごとの行列積に分解します。その結果の書き出しに、OpenVINO 2026.5 に同梱のコンパイラー（8.4）は NPU 4000 以降向けで部品 1 つに数分かかっていました（Panther Lake で約 4 分）。2 行以上なら分解しないので、数秒で済みます。
  • そこで、NPU 4000 以降では、1 トークン用のグラフの代わりに 2 トークン用のグラフで回答を生成します。生成速度は約 1 割遅くなります（Granite 4.2 8B：6.0 → 5.4 tok/s）。計算は同じで、生成される文章も同じか、計算の丸めの差で途中から少し変わる程度です（Granite 4.2 8B の試験では同じでした）。
  • モデルの更新が必要です（Granite 4.2 3B・8B、llm-jp-4.1-8B-thinking（INT4）のカードに「更新あり」と出ます。2 トークン用のグラフの追加だけで、重みのファイルは変わりません）。古い onw は追加分を読まず、今までどおり動きます。ONW_DECODE2=0 で 1 トークン用のグラフに戻せます。
  • Meteor Lake・Arrow Lake（NPU 3720）は、1 トークン用のグラフのコンパイルが速いので、今までどおりです。
• 試験的な設定 ONW_NPU_COMPILER=driver（Windows）：OpenVINO に同梱のコンパイラーの代わりに、NPU ドライバーに入っているコンパイラー（8.3）を使います。1 トークン用のグラフの書き出しは約半分の時間になりますが、NF4 版の 4 トークン用のグラフ（MTP 先読みの検証用）を作れないなど、まだすべてのモデルには使えないので、既定ではオフです。
• onw convert の後からブロックサイズを足す処理（compact.graft_sizes）が、以前に足したサイズの定数ファイル（seg*x.bin）を上書きしていたのを修正（2 回目に足したとき、1 回目のグラフが壊れていました）。

v2.0.2 (2026-10-17)

• Panther Lake・Lunar Lake でも、dense モデルのプロンプトをまた 64 トークンずつ処理するようにしました（2.0.1 で止めた原因を突き止めて直しました）。Panther Lake で計算がずれていたのは、重みを共有する仕組み（NPUW）の設定の一つ（NPUW_DQ_FULL）が原因でした。OpenVINO 自身や llama.cpp と同じ設定にしたところ、正しく計算できるうえに速くなりました。
  • Panther Lake（Qwen3.5-9B INT4、1024 トークン）：約 44 → 約 157 tok/s（2.0.0 の約 105 tok/s より速く、計算も正しい）。16 トークンずつの処理も約 44 → 約 51 tok/s。
  • 初回のコンパイルも短くなり（Qwen3.5-9B で約 23 → 約 14 分）、使用メモリも少し減ります。
  • Panther Lake では、更新後の最初のロードでコンパイルし直します。Lunar Lake と NPU 3720（Meteor Lake・Arrow Lake）は今のキャッシュのまま使えます（Lunar Lake の 64 トークンのグラフは、もともと正しく計算できていることを確かめました）。
  • Qwen3.6 系（2.0.0 の高速化）は、この設定を使わないので変わりません。

v2.0.1 (2026-10-17)

• Panther Lake・Lunar Lake で、dense モデルの 64 トークン処理（2.0.0 で追加）を使わないように戻しました：Panther Lake（NPU 5010）で、2.0.0 で加えた 64 トークンのグラフの計算結果が正しくなく、Qwen3.5-9B などで意味のない文字が出ることがありました（16 トークンでは正しく計算されます）。NPU 4000 以降では 1.4.13 と同じブロックの選び方に戻します。NPU 3720 では正しく計算できているので、2.0.0 のまま 64 トークンずつ処理します（約 2〜2.5 倍）。モデルの更新はそのままで構いません。
• Qwen3.6 系のプロンプト処理（2.0.0）は Panther Lake でも正しく動いているので、変わりません。

v2.0.0 (2026-10-17)

• Qwen3.6-35B-A3B と Qwen3.6-REAP-18B-A3B のプロンプト処理が約 4〜6 倍に（メモリ 24 GB 以上の PC）：AMD 版 onwx と同じ工夫を Intel NPU に移しました。プロンプト全体を層ごとに処理し、同じエキスパートを選んだトークンをまとめて 1 回で計算します（今までは 16 トークンのブロックごとに、選ばれたエキスパートの重みを毎回読んでいました）。
  • Panther Lake（Qwen3.6-35B-A3B、1024 トークン）：約 24 → 約 147 tok/s（42 秒 → 7 秒）。
  • Core Ultra 9 285HX（NPU 3720）：Qwen3.6-35B-A3B 約 22 → 約 100 tok/s、REAP-18B 約 24 → 約 106 tok/s。
  • 出力はほぼ同じです（16 トークンのブロックとの差は KL 0.0003〜0.0005、最初のトークンは一致）。
  • 使用メモリはほぼ変わりません（システム全体のピーク：Panther Lake で +0.1〜0.3 GB、NPU 3720 では 16 トークンのグラフを読み込まなくなるぶん同じか少なめ）。
  • モデルの更新が必要です（カードに「更新あり」と出ます。差し替えは区間ファイルの約 0.9 GB だけです）。更新すると初回のロードで新しいグラフをコンパイルし直します。古い onw でも更新後のモデルはそのまま動きます。
  • メモリ 24 GB 未満の PC（16 GB の Lunar Lake など）では、新しいグラフのコンパイル中にメモリが足りなくなるため、今までどおりの処理のままです（ONW_GROUPED=1 で強制、0 で無効）。
• Qwen3.6 系の生成が少し速く：1 トークンの処理で、区間どうしの入出力を最初に一度だけつないでおき、毎回の受け渡しをなくしました。Panther Lake で 8.9 → 10.3 tok/s、NPU 3720 で 6.0 → 6.5 tok/s（出力は同じ）。
• dense モデルのプロンプト処理が約 2〜2.5 倍に（2.0.1 では NPU 3720 のみ、2.0.2 で全機種に戻しました）：Qwen3.5-9B、Ornith-1.5-9B、NeoHorse-1-4B、Granite 4.2 3B / 8B、llm-jp-4.1-8B-thinking（INT4 / INT8）に 64 トークンのブロックを加え、プロンプトを 16 トークンずつではなく 64 トークンずつ処理します。Gemma 4 E4B と NF4 版は、今まで 64 トークンのブロックを使えなかった PC（NPU 3720 のメモリ 24 GB 未満、NPUW が使えない設定など）でも使うようになります。
  • Core Ultra 9 285HX（NPU 3720）：Qwen3.5-9B 約 31〜43 → 約 80〜87 tok/s、llm-jp-4.1-8B 約 46 → 約 111、NeoHorse-1-4B 約 67 → 約 132、Granite 4.2 3B 約 69 → 約 139 tok/s。
  • 出力はほぼ同じです（16 トークンのブロックとの差は KL 0.00005〜0.0015、最初のトークンは一致）。
  • 使用メモリはほぼ変わりません（+0.35〜0.5 GB）。16 トークン用のグラフの代わりに 64 トークン用を読み込むので、重みの写しは増えません。そのぶん、短い入力や先読み検証は少し割高になります（NPU 3720 では先読み検証が自動でオフになります）。設定の「64 トークン処理」を off にすると今までどおりです。
  • モデルの更新が必要です（カードに「更新あり」と出ます。追加のグラフファイル数 MB だけで、重みのファイルは変わりません）。更新後の初回のロードで新しいグラフをコンパイルします（Panther Lake の 9B で数十分かかります）。古い onw は追加分を読まず、更新後のモデルもそのまま動きます。

v1.4.13 (2026-10-16)

• Ternary Bonsai 2 9B / 4B（2 ビット、画像も読める、Lunar Lake 以降専用）をモデル一覧に追加：Prism ML が Qwen3.5-9B / 4B を三値（−1・0・+1）の重みで学習し直したモデルを、重みを 2 ビットのまま NPU で動かします。Lunar Lake で 9B は生成約 13 tok/s・メモリ約 3.5 GB、4B は約 21 tok/s・約 2 GB です。27B と同じく、NPU コンパイラーの制限でプロンプトは 1 トークンずつ処理します。
• onw convert が Bonsai 2 9B（回転ブロック 4096）・4B（回転ブロック 512、埋め込みと共有の LM ヘッド）と、その画像エンコーダーを読めるようになりました。Bonsai 2 27B の変換結果は変わりません（コンパイル済みのキャッシュもそのまま使えます）。

v1.4.12 (2026-10-15)

• エージェント（Hermes など）で、思考の中に書かれたツール呼び出しを認識するように：Qwen3.5 はツールの結果を受け取ったあと、思考を閉じないまま <tool_call> を書くことがあります。今までは思考の一部として扱っていたので、エージェントからは「何も出力していない」ように見えて止まっていました。思考は呼び出しの直前で終わったものとして扱います。
• 設定に「API の最大出力トークン」を追加（既定 8192）：アプリが max_tokens を送らないときの、1 回の回答の長さの上限です。今までは 512 で、エージェントが長いファイルを書くと途中で切れていました。「文脈の残りまで」も選べます。大きくしても使用メモリは増えません。
• サーバータブのボタンを整理：選んだモデルが読み込み済みなら「ロード」ボタンが「アンロード」になります（上のアンロードボタンはなくしました）。

v1.4.11 (2026-10-14)

• Ternary Bonsai 2 27B のカードが「更新あり」のままでロードできなかったのを修正（1.4.9 から）。MTP 付きで出し直した NF4 版の古いダウンロードを見分ける判定に Bonsai も入っていて、MTP を持たない Bonsai がいつも古い版とみなされていました。モデルはそのままで、onw を更新すればロードできます。

v1.4.10 (2026-10-13)

• NPU のターボモードを既定でオンに（速くなります）：NPU のクロックを上げて動かします。出力は変わりません。
  • Lunar Lake（Qwen3.5 9B、NF4＋MTP）：生成 13.8 → 19.1 tok/s（+38%）、プロンプトの読み込み +46%。
  • Panther Lake（Qwen3.5 9B、INT4）：生成 7.2 → 8.6 tok/s（+19%）、プロンプト +17%。
  • そのぶん消費電力が増えます（Lunar Lake で約 6 W、1 トークンあたりの電力量は Lunar Lake で約 13%、Panther Lake で約 2% 増）。電池で長く使いたいときは、設定の「NPU を性能優先で動かす（ターボ）」をオフにしてください。
  • コンパイル済みのキャッシュはそのまま使えます（コンパイルし直しはありません）。ただし、初めてコンパイルしたグラフは、次にロードしたときからターボになります。

v1.4.9 (2026-10-11)

• Ternary Bonsai 2 27B（2 ビット、Lunar Lake 以降専用）をモデル一覧に追加：三値で学習された 27B を、重みを 2 ビットのまま NPU に載せて動かします（メモリ約 10 GB、約 4 tok/s）。NPU コンパイラーの制限で、プロンプトは 1 トークンずつの処理です（Intel に報告済み）。onw convert は Prism ML の MLX 2 ビット版（prism_hadamard_qwen35）を読めます。
• チャット画面の最大トークンの既定値を、コンテキストが許す限りにしました（会話とプロンプトの残りの文脈いっぱいまで書けます。欄にはコンテキスト長が入ります）。今までは 512 で、長い回答が途中で切れていました。自分で変えた値はそのまま使います。API の既定（max_tokens を送らないときの 512）は変わりません。

v1.4.8 (2026-10-07)

全体を見直して、見つかった不具合をまとめて直しました。

• onw のウィンドウ
  • 終了・モデルの切り替え・アンロードのたびに、一瞬「ロードに失敗しました」と赤字で出ていたのを修正（止めている途中を失敗と見ていました）。
  • 止まった理由に、関係のない行（進捗の行など）が出ていたのを修正。エラーで止まったときはそのエラー、それ以外は「予期せず終了（メモリ不足の可能性）」を出します。
  • トレイから起動して失敗したときも理由を表示し、次に起動・停止したら消えるようにしました。
  • モデルの更新をキャンセルしたり失敗したりすると、使えていたモデルが「途中で止まったダウンロード」になり、削除ボタンだけが出ていたのを修正。更新の続きとして扱い、何も置き換わっていなければ元どおりに戻します。
  • ロード・切り替えボタンの二重押しを防止。更新に失敗したときの案内を閉じられないのを修正。モデルの既定値の「保存しました」がすぐ消えるのを修正。ダウンロード中に一覧のクリックが効かないことがあるのを修正。名前に「'」を含むモデルのボタンが動かないのを修正。
  • ポートの変更を保存してまだ再起動していないとき、チャット・検証ページ・API の URL を、動いているサーバーのポートで開くように。URL は 127.0.0.1 にしました（localhost を ::1 と解釈するクライアントでつながらないことがありました）。
  • ウィンドウの表示部品（WebView）が起動できない環境では、ブラウザで開くように（原因は設定フォルダーの window.log に残ります）。
  • 初回のコンパイルの最後に「初回だけ数分〜15 分」の表示に戻っていたのを「仕上げています…」に。
  • コンテキスト長：サーバーのタブに実際の文脈の長さを表示し、モデルの上限より長い値（Gemma 4 E4B に 262,144 など。エンジンは上限の 131,072 で動きます）を選ぶとその旨を添えるように。メモリの見積もりも上限で計算します。チャット画面の「文脈は約…トークン」が設定の変更後に古いままになることがあったのを修正。
  • Ubuntu：すでに開いている onw のウィンドウが、トレイの「onw を開く」で前に出なかった（通知だけが出ていた）のを修正。GNOME がメニューのクリックに付けて渡す「前に出してよい」という許可を受け取って、そのまま前に出します（受け取れない環境では開き直して前に出します。開いていたタブもそのままです）。
  • 設定で、変えるとモデルをコンパイルし直す項目（NPUW 重み共有、その実験的な 3 つ、64 トークン処理を on にするとき）に「※」を付け、変えたときは「未保存の設定があります」の通知に「コンパイルし直します」と出すように。
  • NPU ドライバーか OpenVINO の版が上がって全部コンパイルし直すときは、サーバーのタブにそう表示するように（例：driver 1004512 -> 1005540）。
  • サーバーのタブに、メモリの横棒グラフと NPU の使用率：onw（サーバーと、NPU が使うメモリ）・ほかのアプリ・空きを 1 本の棒で表示します。
  • Windows：タスクバーにピン留めすると、押しても何も起きない「Python」がピン留めされていたのを修正。スタートメニューの onw と開いているウィンドウを同じアプリとして扱い、ピン留めからトレイごと起動します。
• トレイ
  • 説明文が長いと Windows でトレイが固まることがあったのを修正。Ubuntu でメニューの状態表示が更新されないのを修正。
  • 終了するとき、進行中のダウンロードも止めるように（裏で続いて、次回は途中のダウンロードとして見えていました）。
  • 更新のあと、更新前にモデルを読み込んでいなかったのに自動でロードしていたのを修正。自分で更新できない入れ方（開発用の取得など）では更新の案内を出さないように。URL のコピーでコンソールが一瞬出るのを修正。
• チャット画面
  • 回答中に Enter を押すと二重に送られていたのを修正。サーバーの再起動などで接続が切れたとき、途中までの回答を残して理由を表示するように。モデルを切り替えたあとも画面の情報（画像対応・思考など）が古いままだったのを修正。
  • 思考ありのとき、最大トークンを思考の分だけ自動で増やすように。最大トークンで打ち切られたことを表示。画像に対応しないモデルでは画像を送らないように。回答中に会話を削除すると戻ってくるのを修正。長い回答で重くなるのを改善。
• 確認ページ：思考するモデルで空の回答を「OK」としていたのを修正。表示する文字のエスケープ漏れを修正。
• API
  • API キーを設定すると onw 自身のチャット画面・確認ページが使えなくなっていたのを修正（この PC からのアクセスにはキーを求めません。LAN からは今までどおり必要です）。
  • Anthropic 互換：キャッシュ済みのトークンを入力に二重に数えていたのを修正（Claude Code で文脈の使用量が実際の約 2 倍に見えていました）。長すぎるプロンプトを Anthropic 形式の 400（prompt is too long）で返すように（Claude Code の自動圧縮が働きます）。count_tokens が生成中の状態を乱すことがあったのを修正。
  • ストリームでない要求で、クライアントが切断しても生成を続けていたのを修正。ストリームの要求は、始まる前の検証で 400 を返すように。待っている要求が多いと応答が詰まることがあったのを修正。
• エンジン
  • 初回のコンパイル中に止める（アンロード・切り替え・終了）と、その経路を「コンパイラーが落ちた」と記録して以後避けていたのを修正。
  • あるブロックサイズが使えない環境で、読み込むたびに全部コンパイルし直していたのを修正。メモリ不足などの一時的な失敗のあと、代わりの経路を固定してしまっていたのを修正（NPU のメモリ不足の表記や、メモリ不足で強制終了された子プロセスも一時的な失敗として扱い、正しいコンパイル結果を消さないように）。読み込みの最後のほうで失敗したとき、次回に全部コンパイルし直していたのを修正。
  • 64 トークン処理や MTP を切り替えただけで、全部コンパイルし直していたのを修正（同じ設定で、より多くのグラフを読み込めた記録があれば使います）。
  • モデルの重みファイルが更新されたのに（大きさが同じだと）古い重みのコンパイル結果を使い続けることがあったのを修正。重みのほうが新しければ作り直します。
  • 更新が途中で止まったモデルは読み込まず、「更新」を押すよう案内します（新旧のファイルが混ざっているため）。
  • 前の会話を続けるときの再利用で、直前の要求が途中でエラーになると、別の会話の内容を前提に答えることがあったのを修正。
  • 温度ありの生成で、トークンを選ぶ計算を約 3 倍速く（top_k があるとき、候補だけで計算します。選ばれ方は同じです）。
  • Gemma 4 の画像付きの会話で、毎回最初から処理し直していたのを修正。
  • Windows（Lunar Lake・Panther Lake）で、重みファイルの大きさの分だけ「コミット済み」のメモリを使っていたのを修正：実際のメモリは使っていませんでしたが、Windows はその分を確保済みとして数えるため、メモリの少ない PC ではほかのアプリがメモリを確保できなくなることがありました。重みファイルを読み取り専用で開くようにしました。
  • クライアントが切断したとき、長いプロンプトでも処理の途中で止めるように（最後まで処理して、その間ほかの要求を待たせていました）。
  • Qwen3.5 系の画像付きのプロンプトで、MTP の層に渡すプロンプトの位置が本体とずれていたのを修正（答えは変わりません。Panther Lake の確認では下書きの当たり方もほぼ同じでした）。
  • SSD から専門家を読む MoE で、長いプロンプトのマスクの作り直しに時間を取られていたのを改善（約 8 倍速く）。
  • 同じモデルを 2 つの onw が同時に使うと（サーバーとコマンドラインのチャットなど）、相手のコンパイル中の印を「コンパイラーが落ちた」と記録したり、相手が使っているコンパイル結果を整理で消したりしていたのを修正。
  • 変換：変換済みのフォルダーに変換し直す途中で止まると、新旧の混ざったモデルが読み込めてしまっていたのを修正（終わるまで読み込みません）。--compact は途中で止まってもやり直せるように。
  • メモリ節約モード（厳密）で、裏で読み込み中のブロックサイズへの切り替えが重なると、同じグラフを二重に読み込んでメモリを倍使うことがあったのを修正。切り替えに失敗したとき、ブロックサイズが一つもない状態にならないように元のサイズを戻します。
  • 変換：Qwen3 MoE の rope_theta（transformers 5 の形式）と norm_topk_prob、Granite の tie_word_embeddings の既定値を transformers に合わせました（これから変換するモデルのみ）。
• アンインストール：onw のフォルダーの uninstall.bat（Ubuntu は uninstall.sh）で、プログラム・設定・モデル・スタートメニューの項目・ログイン時の起動をまとめて削除できるように（--keep-models でモデルを残す）。手順は MANUAL の「アンインストール」に。
• Microsoft Store 版の Python は使わないように：Store 版は onw の設定とモデルを見えない専用フォルダーに書き、ログイン時の起動も効きませんでした。セットアップは Store 版を選ばず、python.org 版を入れるよう案内します。すでに Store 版で入れている場合は、onw のウィンドウに uninstall.bat で削除して入れ直すよう案内を出します。
• 更新：依存パッケージが変わる更新で、動いているトレイの中で pip を動かしていたのを修正（Windows では、使用中の OpenVINO のファイルを置き換えられずに失敗し、新しい onw が古いパッケージで動くことがありました）。トレイとサーバーが終わってから pip を動かします（Windows では進み具合をコンソールに表示）。失敗したときは onw のウィンドウに案内を出します。
• セットアップのやり直し：setup.bat（Ubuntu は setup.sh）をもう一度実行したとき、依存パッケージが変わっていても入れ直していなかったのを修正。動いている onw は止めてから入れ直し、最後に起動します。
• start.bat：スペースを含むフォルダーのモデルを指定できるように。

v1.4.7 (2026-10-06)

• onw のウィンドウのタスクバー（Ubuntu はドック）のアイコンが、Python のアイコンや歯車ではなく onw のアイコンになりました （スタートメニューのショートカットを通さずに開いたとき、Ubuntu の Wayland のとき）。

v1.4.6 (2026-10-06)

• Windows で回答が約 3 割速く（Lunar Lake の Qwen3.5-9B（NF4）で約 12 → 16 tok/s、Panther Lake の Ornith-1.5-9B（NF4）で 12.3〜15.4 → 16.1〜19.9 tok/s）：onw のウィンドウはサーバーを優先度「通常以下」で 起動しており、Windows は回答も省電力コア・低いクロックで動かしていました。サーバーは「通常」で起動し、回答を作っている間だけ 「通常以上」にします。回答中に使う CPU は 1〜2 コア分なので、ほかのアプリへの影響は小さいです（ONW_PRIORITY=normal で回答中も 「通常」、off で変えない）。

v1.4.5 (2026-10-06)

• 初回のコンパイルが約 3 分短く：Qwen3.5 系の NF4 版の 4・64 トークン用グラフは、NPUW の「繰り返しをまとめる」方式ではコンパイル できず、毎回失敗してから別の方式に切り替えていました。最初から別の方式でコンパイルします（Panther Lake の Ornith-1.5-9B（NF4）で 初回 約 710 → 533 秒）。生成速度とメモリは変わりません。
• 初回のコンパイル中、onw のウィンドウとトレイに残り時間の目安を出すようにしました（「NPU 向けの準備 3/10（あと約 6 分）」）。

v1.4.4 (2026-10-06)

• 修正：1.4.2 と 1.4.3 で NPU のメモリが約 3 GB 余計にかかることがあった：初回のコンパイルを複数のプロセスで同時に行うと （1.4.2 で追加。CPU コアと空きメモリに余裕のある PC で使われていました）、読み込んだグラフが重みをプロセスごとに別々に持って いました（Panther Lake の Ornith-1.5-9B（NF4）で NPU のメモリ 5.2 → 8.4 GB）。同時コンパイルは既定でやめました。グラフの中の 並列コンパイル（1.4.1、1 区間 146 → 43 秒）はそのままです。
• そのため、1.4.0〜1.4.3 でコンパイルしたキャッシュは、次の読み込みで一度だけまとめてコンパイルし直します（同時コンパイルで 作られたものと見分けられないため）。
• 初回のコンパイルを途中で止めると（コンパイル中に onw を閉じた、など）、次の起動で残りを別の回にコンパイルし、その起動の間は NPU のメモリが二重になっていたのを修正。最後まで読み込めた設定を記録しておき、記録のないコンパイル結果はまとめて作り直します。

v1.4.3 (2026-10-06)

• Windows でメモリが約 3 GB 減りました：コンパイルのときに読んだ重みファイルのページが、NPU が自分のコピーを持ったあとも メモリに残っていました。区間ごとに読み終わった時点で手放すようにしました。Lunar Lake（RAM 16 GB）の Qwen3.5-9B（NF4）で、 使用中のメモリ 8.8 → 5.6 GB、読み込み中のピーク 8.5 → 5.6 GB。生成速度は変わりません。Linux は元からこのページを OS の キャッシュとして扱うので、変わりません。

v1.4.2 (2026-10-06)

• 修正：Windows の Lunar Lake でも読み込みに失敗する：1.4.1 で Panther Lake に入れた修正（コンパイル済みのグラフをメモリマップの まま NPU に渡さず、通常の読み込みにする）を、Windows のすべての NPU に広げました。
• 初回のコンパイルの並列化（1.4.1 では Panther Lake のみ）を、すべての NPU で使うようにしました。メモリ節約モードがオンのときは、 コンパイル中のメモリを抑えるため、これまでどおり 1 つずつコンパイルします。
• 修正：Panther Lake で読み込むたびに全部コンパイルし直す：NPU のコンパイラーが受け付けない経路を試したときに空のフォルダーが 残り、次の読み込みがそれを「別の回のコンパイル結果」と判断していました（Panther Lake では 4・64 トークン用のグラフがそうなります）。 空のフォルダーは数えずに消すようにしました。Ornith-1.5-9B（NF4）の 2 回目以降の読み込みが約 3〜5 分 → 12 秒になります。
• 修正：同時に動くコンパイル用のプロセスが、どの経路でコンパイルできたかの記録（onw_compile.json）を互いに上書きし、失敗する 経路を本体がもう一度試していました。記録は書き込むたびに合わせるようにしました（Ornith-1.5-9B の初回の読み込み 298 → 221 秒）。

v1.4.1 (2026-10-06)

• 修正：Panther Lake（NPU 5）で最初の推論が止まる：Windows でコンパイル済みのグラフをファイルのメモリマップのまま NPU に渡すと、 NPU 5 のドライバーでは最初の推論で ZE_RESULT_ERROR_DEVICE_LOST になっていました（その前に「invalid value encountered in divide」の警告が出ることもありました）。NPU 5 以降は通常の読み込みにしました。Panther Lake で Qwen3.5-9B が動くことを確認しています。
• 修正：Windows でコンパイルのやり直しが毎回起きる：OpenVINO はコンパイル結果を読み取り専用で保存するため、onw が古いコンパイル 結果を消そうとしても Windows では消えずに残り、読み込むたびに「別々の回に作られたコンパイル結果」と判断して全部コンパイルし直して いました。読み取り専用のファイルも消すようにしました。モデル一覧の「削除」「キャッシュ削除」でもファイルが残っていたのを直しています。
• Panther Lake で初回のコンパイルが約 3 倍速く：NPU のコンパイラーは 1 つのグラフを 1 コアでしか処理しないため、NPU 5 以降では グラフ内の部分を並列にコンパイルし（1 区間 146 → 43 秒）、さらに区間を別のプロセスで最大 4 つ同時にコンパイルします（メモリと CPU コア数に応じて減らします）。Qwen3.5-9B で 10 区間 368 秒。重みは区間の間で共有されたままです。Lunar Lake 以前は今までどおりです。
• コンパイルの途中でプロセスを止めると、次の読み込みでその経路を「コンパイラーが落ちた」と記録して避けてしまうことがあったのを修正 （onw が止めた同時コンパイルのプロセスについて）。

v1.4.0 (2026-10-06)

• MTP 先読みで回答が約 1.5 倍に（Lunar Lake 以降、Qwen3.5 系の NF4 版）：Qwen3.5 系のモデルに付いている MTP 層 （次の次のトークンを予想する小さな層）で 2 トークン先まで下書きし、本体で一度に確かめます。NPU は数トークンを 1 トークンと ほぼ同じ時間で計算できるので、当たった分だけ速くなります。温度ありの生成でも、1 トークンずつ生成したときと同じ確率でトークンを 選びます。Lunar Lake（8 種類の質問の平均）で Qwen3.5-9B（NF4）9.7 → 15.1 tok/s（温度 0.6：8.6 → 13.8）、Ornith-1.5-9B（NF4） 10.2 → 15.1 tok/s（8.7 → 13.8）。確かめるのは 4 トークン用のグラフで、外れた下書きの分だけ正確に巻き戻します。 NPU 3720 では確かめるブロックが重く、かえって遅くなるため使いません。
• Lunar Lake 以降で長いプロンプトの処理が約 2 倍に：「64 トークン処理」の auto が、Lunar Lake 以降でもオンになりました （これまでは RAM 24 GB 以上）。重みを共有するのでメモリはほぼ増えません（+0.1〜0.3 GB）。Gemma 4 E4B 73 → 140 tok/s、 Qwen3.5-9B（NF4）119 → 220 tok/s、Ornith-1.5-9B（NF4）117 → 212 tok/s（約 2,000 トークン）。
• Qwen3.5-9B（NF4）と Ornith-1.5-9B（NF4）のモデルを、MTP 層・4 トークン版・64 トークン版の入りに更新しました。入れてあるモデルは モデル一覧に「更新あり」と出るので、「更新」で変わったファイルだけ取り直してください（約 3.9 GB）。
• 回答の 1 ステップごとのホスト側の処理を約 3 割削減（NPU への入力をコピーせずに渡す、DeltaNet の状態を 2 つのバッファで交互に 使う、アテンションの出力を次の区間の形へ直接書く、など）。生成結果は変わりません（全モデルで、変更前と同じトークン列を確認）。
• 修正：複数トークンのブロック（先読み検証、MTP、プロンプトの最後のブロック）で、活性の大きい行の最終正規化が fp16 で溢れて ロジットが行ごと 0 になり、意味のないトークン（他の言語の単語など）がまれに混ざっていました。その行だけ縮めて計算し直します。
• 修正：NPU 4000 以降で、ブロックサイズごとのコンパイル結果が別々の回に作られていると（64 トークン処理を後からオンにした、 onw の更新で一部だけコンパイルし直した、など）、重みの共有が外れてメモリを 2.5〜3.8 GB 余計に使っていました。混ざっていたら 一度だけまとめてコンパイルし直します（Lunar Lake で約 10 秒）。
• 検証画面のモデル情報に「MTP 先読み」を追加。
• python -m onw.server で直接起動したとき、Anthropic・Responses の API（/v1/messages、/v1/responses）が 404 になって いたのを修正（onw ウィンドウや onw serve から起動した場合は問題ありませんでした）。

v1.3.0 (2026-10-04)

• Anthropic の Messages API（/v1/messages）と OpenAI の Responses API（/v1/responses）に対応。Claude Code や Codex CLI など、 OpenAI のチャット API 以外の形式で話すアプリからも使えます（ストリーミング、ツール呼び出し、思考に対応。count_tokens、 previous_response_id も使えます）。API キーは Anthropic 式の x-api-key でも受け付けます。
• 思考を 4 段階に：考えない／少し／普通／じっくり。gpt-oss・llm-jp は考える量（low／medium／high）を、ほかのモデルは考える 長さの上限（約 512／2048 トークン、じっくりは上限なし）を変えます。API の reasoning_effort（low／medium／high）も同じ意味に なりました。チャット画面の「思考モード」はこのスライダーに置き換えました。
• 「サーバー」タブに「このモデルの既定」：今のモデルの思考の段階と生成設定（貪欲・モデルの推奨値・自分で指定）を、モデル ごとに保存できます。API で指定のないリクエストとチャット画面の初期値に使い、保存するとすぐ反映されます（再起動不要）。設定の 「サーバーと API」にあった「API で思考の指定がない…」「API の既定の生成設定」は、ここに移しました（これまでの値は、モデルごとの 設定がないあいだ引き続き使われます）。
• チャット画面：回答の下に「コピー」「原文」（Markdown のまま表示）「再生成」（最後の回答）、コードブロックに言語名と 「コピー」ボタンを追加。

v1.2.3 (2026-10-04)

• 使い方マニュアル（日本語）の目次で、一部の項目に飛べなかったのを修正（Hugging Face の見出しのリンク名は「」や（）を残すのに 合わせました）。「サーバーと API」の画面を「API の既定の生成設定」入りで撮り直し、OpenCode などで使うときの説明を足しました。
• 設定画面：「API の既定の生成設定」の選択肢が英語表示で切れていたのを修正。

v1.2.2 (2026-10-04)

• 設定の「サーバーと API」に「API の既定の生成設定」を追加。温度・Top P などを送らないアプリ（OpenCode など）のリクエストに、 「貪欲（温度 0。これまでどおり、既定）」「モデルの推奨値（チャット画面と同じ。Qwen 系は思考時に思考用の値）」「自分で指定」の どれを使うかを選べます。アプリが送った値はそのまま使います。「自分で指定」にすると、チャット画面の初期値もその値になります （「（設定の値）」と表示）。

v1.2.1 (2026-10-04)

• Gemma：設定の「64 トークン処理」を切り替えるたびに、NPU 向けのコンパイル（数分）をやり直していた問題を修正。スライディング ウィンドウ層のリングの長さが「読み込んだ中で最大のブロック」で決まっていたため、64 トークン処理のオン／オフで 1 トークン用・ 16 トークン用のグラフの形まで変わっていました。今はモデルが持つ最大のブロック（64）で決めるので、切り替えても再コンパイル しません。メモリ 24 GB 未満の PC（64 トークン処理が auto でオフ）では、この版に更新したあとの最初の 1 回だけコンパイルが入ります。
• Lunar Lake 以降（NPUW 重み共有）で、onw の更新のたびに古いコンパイル結果がたまっていたのを修正。NPUW のコンパイル結果は OpenVINO のキャッシュ（npu_cache 直下）に置かれ、古い版が消されずに残っていました。今はグラフごとのフォルダ （npu_cache/npuw/）に置き、使わなくなった版は読み込みのあとで消します。以前の版が残したファイルも、この版での最初の 読み込みのあとで消えます（そのため Lunar Lake 以降の PC では、最初の 1 回だけコンパイルが入ります）。
• モデル一覧：onw の更新でコンパイル結果が使えなくなる変更があったとき、そのモデルに「onw の更新で、次のロードでは NPU 向けの準備をやり直すことがあります（数分）」と出すようにしました（一度読み込むと消えます）。
• 自動更新のたびにパッケージの入れ直し（pip）が走っていたのを、依存パッケージが変わったときだけにしました（版番号の行の違いで 毎回入れ直していました）。更新がその分速く終わります。

v1.2.0 (2026-10-04)

• llm-jp-4.1-32B-A3B-thinking に対応（モデル一覧に追加）。国立情報学研究所 LLM-jp の日本語 MoE で、全体 32B のうち 1 トークンで 使うのは約 3B（128 個のエキスパートから 8 個）。NPU 3720 で生成 5.8 tok/s、16 GB の PC でもエキスパートを SSD から読んで 動きます（Lunar Lake 16 GB で 3.4 tok/s）。元のモデルにより近い INT8 版（30 GB、メモリ 32 GB 以上向け）もあります。
• onw convert が Qwen3-MoE 形式（qwen3_moe）のモデルを変換できるようになりました。

v1.1.3 (2026-10-04)

• チャット画面の推奨値を、モデルの generation_config.json から読むようにしました（Gemma 4、Granite 4.2、Qwen3.6-35B-A3B、 LFM など）。書いていないモデルの値は onw/sampling.json にまとめました（Qwen3.5 系、gpt-oss、llm-jp）。Granite 4.2 は 推奨値（温度 1.0・Top P 0.95）が入っていなかったのを修正。元のモデルに推奨がない llm-jp は、長い文章でループしにくい 温度 0.7・Top P 0.95 を「（onw の推奨値）」として入れます。

v1.1.2 (2026-10-04)

• チャット画面：回答の途中で上にスクロールすると、自動で一番下まで戻らないようにしました（これまでは回答が流れている間、 開いた「思考」欄を閉じたり、上の会話を読んだりできませんでした）。下にいないときは右下に「↓ 最新へ」ボタンが出て、 押すと最新の位置に戻り、また回答に追従します。新しいメッセージを送ったときも追従に戻ります。

v1.1.1 (2026-10-04)

• NF4 版に Qwen3.5-9B (NF4) を追加（Lunar Lake 以降専用）。Lunar Lake（16 GB）で通常版と比べて、生成 7.1 → 9.4 tok/s、 プロンプト処理 約 2.3 倍速、使用メモリ 6.6 → 5.1 GB（約 2.4 割減）。CPU で元のモデルと比べた精度はほぼ同等です。
• チャット画面：Gemma・Qwen 系（Ornith・NeoHorse を含む）・gpt-oss では、モデルの推奨値（温度・Top P・Top K・出現ペナルティ） を最初から入れるようにしました。温度 0 のままだと、長い文章で同じ言葉を繰り返し続けることがあったためです。Qwen 系は 思考モードをオンにすると思考用の推奨値に切り替わります（自分で変えた値はそのまま）。「出現ペナルティ」の欄を追加しました。 API の既定は変わりません。

v1.1.0 (2026-10-04)

• NF4 版のモデルに対応しました。Lunar Lake（NPU 4000）以降の NPU は NF4（正規分布に合わせた 4 ビット）の重みを ハードウェアで計算できるので、重みをチャネル単位の NF4 にした版を用意しました。onw ウィンドウは、Lunar Lake 以降の PC で だけ NF4 版を一覧に出します（NPU 3720 では動かないため、一覧に出ず、手で読み込もうとしても分かりやすいエラーで止まります）。
• 最初の NF4 版は **Ornith-1.5-9B (NF4)**。Lunar Lake（16 GB）で通常版と比べて、生成 7.2 → 9.3 tok/s、プロンプト処理 約 2.3 倍速、使用メモリ 6.5 → 5.1 GB（約 2 割減）。CPU で元のモデルと比べた精度はほぼ同等です。
• onw convert に --fmt nf4（チャネル単位 NF4）と、Qwen3.5／3.6 系のアテンション q/k/v だけ形式を変える --attn-fmt を追加。

v1.0.1 (2026-10-03)

• 使い方マニュアル（MANUAL.md）を追加し、README の使い方を短くしました。スクリーンショットはすべて今の版で撮り直しています。
• チャット画面：回答の見出し（###）・表・箇条書き・番号付きリスト・区切り線・引用・リンクを整えて表示するようにしました （これまでは記号のまま出ていました）。
• Gemma を読み込んだときは、チャット画面と検証ページの「繰り返し抑制」の横に「1.2 以上推奨」と赤字で出します。温度 0 の Gemma は、NPU の計算が CPU とわずかに違うため、質問によっては同じ言葉を繰り返し続けることがあります（以前の版からの 挙動です）。既定値は 1.0 のままで、API の既定も変わりません。検証ページにも「繰り返し抑制」の欄を足しました。
• 64 トークン処理がオフのとき、読み込みの進み具合が 100% を超えて数えられていたのを修正。

v1.0.0 (2026-10-03)

• 最初の正式版（パブリックリリース）です。0.15.3 からの変更は次のとおりです。
• onw ウィンドウの設定画面を整理しました。「一般」「サーバーと API」「速さとメモリ」「詳細」の 4 つのタブに分け、各項目の すぐ下に短い説明を付けています（長い説明の段落はなくしました）。最後に開いたタブを覚えています。
• 未保存の設定の「元に戻す」が、押した直後に別の項目を変えると戻りきらないことがあった問題を修正。
• チャット画面：回答の途中で「新しい会話」や別の会話を開くと、止めた回答の残りが新しい会話に混ざり、止めた会話は保存されて いなかった問題を修正（止めたところまでを元の会話に保存します）。
• チャット画面：幅の狭いウィンドウで会話履歴を開くと、選ぶまで閉じられなかった問題を修正（外側をタップで閉じます）。
• 英語・中国語の表示で、設定のタブが狭い画面ではみ出していたのと、効くモデルの一覧の区切りが「、」だったのを修正。

v0.15.3 (2026-10-03)

• onw ウィンドウの「モデル」タブで、ダウンロードが終わっても「100%」のまま「ロード」に切り替わらなかった問題を修正（完了した ダウンロードを、まだダウンロード中として扱っていました。「サーバー」タブからはロードできていました）。

v0.15.2 (2026-10-03)

• onw ウィンドウ：「モデル」タブでモデルをロードしても、「サーバー」タブの「使うモデル」の欄が前に選んでいたモデルのままだった 問題を修正。ロード中のモデルが変わったら、欄もそのモデルに合わせます（自分で選び直した分はそのまま残します）。
• onw ウィンドウ：設定を変えてまだ保存していないときは、画面の下に「未保存の設定があります」のバーを出すように（どのタブでも 表示）。バーから「保存」と「元に戻す」ができます。

v0.15.1 (2026-10-03)

• メモリ節約モードで、起動時に 1 トークン用と 16 トークン用のグラフを一度両方読み込んでいたのをやめました。2 回目以降は 16 トークン用だけを読み込み、初回（コンパイル済みのものがないとき）は 1 トークン用を区間ごとに「コンパイルして保存し、すぐ 捨てる」だけにします。起動の瞬間に通常モード並みにメモリが膨らむことがなくなりました。
• 厳格メモリ節約モードを追加（設定の「メモリ節約モード」の下。節約モードがオンのときだけ選べます）。2 種類のグラフを同時に 持たず、回答の前に 16 トークン用を捨ててから 1 トークン用を読み込みます。メモリの最大は待機中と同じになる代わりに、回答の たびに書き始めるまで数秒待ちます。NPU 3720 の実測で、Granite 4.2 3B の起動から終了までの最大メモリは通常 5.6 GB、節約モード 5.6 GB（入れ替えの瞬間）、厳格 3.2 GB（初回のコンパイル中も 3.7 GB）、待ちは約 3.5 秒でした。

v0.15.0 (2026-10-03)

• llm-jp-4.1-8b-thinking の高精度版（INT8）を一覧に追加しました。重みをチャネル単位の INT8 にして、元のモデル（bf16）との差を ほぼなくした版です（日本語 20 問の書き出しは INT4 版の 34/40 に対して 40/40）。7.7 GB、約 4.1 tok/s、メモリ約 15 GB （NPU 3720。メモリ節約モードなら待機中 約 8 GB）で、24 GB 以上の PC 向けです。
• チャット画面に会話の履歴：会話は自動で保存され（この PC の onw の設定フォルダの chats）、左の一覧から開いて続きを話せます。 一覧は「日付順」（今日・昨日・過去 7 日間…）と「モデル別」（モデルごとにまとめる）を切り替えられ、名前の変更・削除、 「会話履歴をすべて削除」もできます。画像は縮小して一緒に保存します。履歴はその PC からの接続でしか読み書きできません（LAN に 公開していても、他の PC や他のサイトからは見えません）。
• API の思考の返し方を vLLM などと同じに：モデルが考えたら、思考モードかどうかにかかわらず思考を reasoning_content で返します （常に考えるモデル＝llm-jp・gpt-oss でも、思考が見えないまま最大トークンを食うことがなくなります）。思考に使ったトークン数も、 OpenAI と同じ usage.completion_tokens_details.reasoning_tokens で返します。
• チャット画面：常に考えるモデルでは、思考モードがオフでも思考を折りたたんだ「思考（考え中… N 文字）」として表示します。開けば 中身を読めます（思考モードをオンにすると、今までどおり開いた状態で表示します）。
• onw ウィンドウのモデル一覧に、思考の種類（「思考：切替」＝思考モードで考える、「思考：常に考える」＝オフでも裏で考える）を 表示するように。README の一覧表にも「思考」の列を足しました。
• 設定に「API で思考の指定がないリクエストも考えてから答える」を追加（既定はオフ）。enable_thinking を送らないエージェントの アプリなどでも、思考モードで答えさせられます（明示的に考えないと指定されたリクエストはそのとおりにします）。

v0.14.3 (2026-10-03)

• チャット画面：常に考えてから答えるモデル（llm-jp、gpt-oss）では、最大トークンの既定値を 512 から 2048 にしました。思考モードが オフでも裏で考えていて、その分も最大トークンに数えるため、512 では考えるだけで使い切り、回答が「…」のまま出ないことがありました。
• 考えるだけで最大トークンに達したときは、「回答の前に最大トークンに達しました」と表示するように。そのときの「応答開始 -14.6 秒」の ような、おかしな時間と速度の表示も直しました。

v0.14.2 (2026-10-03)

• メモリ節約モードを、重みを共有できないすべての dense モデルに広げました。 NPU 3720（Meteor Lake・Arrow Lake）は NPUW を 使わないので、どのモデルも 1 トークン用と 16 トークン用で重みを 2 つ持っています。この PC では節約モードが Qwen3.5 系・Gemma・ LFM2.5 などにも効き、NPU 3720 の実測で待機中のメモリは Qwen3.5-9B 10.0 → 5.7 GB、Gemma 4 E4B 10.2 → 3.8 GB、NeoHorse-1-4B 5.7 → 3.5 GB、LFM2.5-2.6B 4.6 → 2.6 GB です。Lunar Lake 以降は、NPUW で重みを共有できない Granite・llm-jp（と NPUW をオフに したとき）だけが対象です。設定画面には、その PC で効くモデルの名前を表示します（MoE は対象外）。節約モードでは 64 トークン 処理も使いません。
• Gemma 4 の思考モードで、思考が reasoning_content（チャット画面の「思考」欄）に分かれず、回答本文に混ざっていた問題を修正。 Gemma 4 は思考を <|channel>thought … <channel|> の形で書くので、それを読み分けるようにしました。
• NPUW を使う PC で、出力層の区間は最初から分割なしの方式（npuw-none）でコンパイルするように。標準の方式は出力層では必ず 失敗するので、初回のロードのログに failed が並ばなくなります（動作は同じです）。
• 回答が短くて 1 トークン用のグラフが届く前に終わったとき、遅れて届いたグラフが 16 トークン用を追い出し、次のプロンプトが遅く なることがあった問題を修正（届く前に不要になったものは捨てます）。
• タスクトレイの onw が更新前の古い版のまま動いているとき（インストーラーを再実行した場合など）、onw ウィンドウに「トレイを 再起動してください」と表示するように。古いトレイは新しい設定を知らないので、保存しても黙って捨てていました。
• メモリ節約モードの実測（Lunar Lake、16 GB）：Granite 4.2 3B は通常 6.4 GB → 待機中も回答中も約 2.8 GB（入れ替えの約 3 秒だけ 5.1 GB）、入れ替えは約 3 秒。llm-jp-4.1-8b は通常 9.9 GB → 待機中 約 5 GB（入れ替えの数秒だけ約 9 GB）、入れ替えは片道 4〜5 秒。 サーバーのログの先読み検証の表示も、このモードでは off と出すように。

v0.14.1 (2026-10-03)

• メモリ節約モードの仕組みを変更：生成まで 16 トークン用のグラフでこなす方式（生成が約 4 割遅い）から、グラフを 1 種類ずつ 入れ替える方式にしました。普段とプロンプト処理は 16 トークン用だけを持ち、回答を書き始めると裏で 1 トークン用を読み込んで （その間は 16 トークン用で書き進めます）入れ替え、回答が終わると 16 トークン用に戻します。両方を持つのは入れ替えの数秒だけです。 NPU 3720 の実測で、待機中のメモリは Granite 4.2 3B が 3.2 GB（通常 5.6 GB）、llm-jp-4.1-8b が 5.7 GB（通常 9.9 GB）、プロンプト 処理は通常と同じ速さ、回答は出だしの数秒（1 トークン用が届くまで）を除いて通常の速さです。先読み検証は使いません。

v0.14.0 (2026-10-03)

• メモリ節約モードを追加（設定画面。Granite・llm-jp など区間の多いモデルが入っているときだけ表示）。16 トークン用のグラフだけを 読み込み、生成もそれで行います。NPU 3720 の実測で、Granite 4.2 3B は 5.6 → 3.2 GB（7.0 → 4.2 tok/s）、llm-jp-4.1-8b は 9.9 → 5.7 GB（4.7 → 2.7 tok/s）。プロンプト処理の速さは変わりません。メモリ 16 GB の PC 向けです。
• 「起動時に前回ロードしたモデルを自動でロードする」をオフにしていても、onw の更新後の再起動では更新前に動いていたモデルを 読み込み直していた問題を修正。オフのときは、更新後もモデルを読み込みません。

v0.13.2 (2026-10-03)

• Lunar Lake で Granite 4.2 をロードすると、NPU ドライバーの資源が尽きて（zeCommandQueueCreate ... driver is not initialized） 落ちる問題を修正。全層がアテンションのモデル（Granite、llm-jp）は区間が約 90 個に分かれ、NPUW（重み共有）では 30 個ほどで ドライバーが持たないため、こうしたモデルでは NPUW を自動でオフにします（設定の「NPUW 重み共有」を「オン」にすれば強制できます）。
• このドライバーの資源切れを「その NPU では使えない経路」と記録して、16 トークン用のグラフを使わなくなっていた問題も修正。 記録済みのものは次のロードで捨てられ、もう一度試されます。

v0.13.1 (2026-10-03)

• Lunar Lake など NPUW（重み共有）を使う PC で、Qwen3.5 系（Qwen3.5-9B、Ornith-1.5-9B、NeoHorse-1-4B）の 16 トークン用のグラフが 重み共有に失敗し（Unknown unpack combination boolean -> u8）、重みを別に持つ通常のコンパイルに落ちて、メモリを余計に使っていた 問題を修正。DeltaNet の因果マスクを boolean を使わない形に置き換えてからコンパイルします。初回だけ、もう一度 NPU 向けの準備が 走ります（モデルの再ダウンロードは不要）。

v0.13.0 (2026-10-03)

• モデルを 4 つ追加（どれも Apache 2.0）。
  • NeoHorse-1-4B（TokenRhythm）：Qwen3.5-4B をエージェント・ツール呼び出し向けに追加学習した軽量モデル。2.4 GB、6.4 tok/s。
  • Granite 4.2 3B／8B（IBM）：思考とツール呼び出しを強化した世代。3B は 2.1 GB・約 7 tok/s で onw の最速クラス、8B は精度重視 （メモリ 32 GB 以上推奨）。日本語はやや弱めです。
  • llm-jp-4.1-8b-thinking（国立情報学研究所 LLM-jp）：日本語を中心に学習した思考型 8B。必ず考えてから答えます（思考は思考 モードのときだけ表示）。
• 新しいアーキテクチャ granite と llama に対応（onw convert で自分で変換することもできます）。Granite は INT4 で誤差が出やすいため、 符号を考慮した INT4（速度は同じ）とアテンションの一部 INT8 を既定にしています。
• テキスト専用の Qwen3.5 系（qwen3_5_text）と、埋め込みと出力層を共有するモデルの変換に対応。onw convert --norm-maxscale （NPU の FP16 で極小になる値の対策、既定はオフ）を追加。
• harmony 形式の変種（llm-jp）に対応：記号の後ろに空白が入るトークナイザーと、ツール呼び出しの宛先の位置の違いを読み替えます。
• README とモデルのカードの対応 PC に Panther Lake（Core Ultra シリーズ 3）を明記しました。

v0.12.1 (2026-10-02)

• モデルのロード中に進み具合を表示するように。onw ウィンドウに「ロード中 40%」「NPU 向けの準備 4/10」、タスクトレイの アイコンにも割合が出ます（初回の NPU 向けコンパイルは数分〜15 分かかり、これまでは止まっているように見えていました）。
• モデルの「更新」（変わったファイルだけ取り直す）で、ダウンロードの進み具合が最初から 99% と出ていた問題を修正。取り直す ファイルの合計で数えるようにしました（NPU 向けのキャッシュも数えません）。
• タスクトレイが正常に終了しなかったとき（シャットダウンやクラッシュ）に残る管理画面の接続情報を、再起動後に別のプロセスの ものと取り違えて、onw ウィンドウが開けないことがあった問題を修正。トレイなしで開いたウィンドウも、閉じるときに後始末します。

v0.12.0 (2026-10-01)

• Ornith-1.5-9B に対応（ornith-ai、MIT）。Qwen3.5-9B をエージェント・ツール呼び出し向けに鍛えたモデルで、モデル一覧に追加しました。 構造は Qwen3.5 と同じで、テキストと画像に対応します。MoE の 35B-A3B は NPU での精度を調整中で、次の版で追加する予定です。
• onw convert --deltanet-fmt q8g128：Qwen3.5／3.6 系の DeltaNet の in_proj_qkv・out_proj を INT8 にする変換オプション （量子化に敏感なモデル向け。INT4 と同じグループ 128 の形にしたので、チャネル単位 INT8 よりずっと速い）。
• 履歴の reasoning_content（前のターンの思考）をテンプレートに渡すように。Ornith のテンプレートは過去のターンの思考も残す作りで、 エージェント用途ではこれが効きます（Qwen は最新のターンだけ、gpt-oss は thinking として渡ります）。

v0.11.3 (2026-09-30)

• Ubuntu：ランチャー（アプリ一覧の onw）から起動するとすぐ落ちる問題を修正。GNOME はランチャーの中身をログインし直すまで 使い回し、しかもホームフォルダで起動するため、python -m onw がインストール先の ~/onw を空の onw パッケージとして 読み込み、本物を隠していました（cannot import name '__version__'）。起動時にこれを検出して読み直すので、古いランチャー のままでも更新するだけで起動できます。新しく作るランチャーとログイン時の自動起動は onw コマンド（.venv/bin/onw tray） を使います。

v0.11.2 (2026-09-30)

• 0.11.1 で、メモリ 16 GB の PC だとモデル一覧の速度が「遅め（SSD）」になっていた問題を修正。「エキスパートのメモリ」を 数値にしているとエキスパートのないモデル（Gemma、Qwen3.5-9B）にまで付き、auto でもメモリの見積もりを厳しくしすぎて、 収まる Qwen3.6-REAP と gpt-oss-20b まで SSD 読み込みにしていました。0.11.0 の基準に戻し、エキスパートがほぼ全部 収まるときも SSD 読み込みにしません（16 GB で SSD から読むのは Qwen3.6-35B と gpt-oss-20b の INT8 版だけ）。

v0.11.1 (2026-09-30)

• gpt-oss-20b の 2 モデルの精度を元に戻しました。公開前に --compact で埋め込みを INT4 にしたため、元のモデル（bf16）との 一致が 17 トークン中 14（ロジット差 4.6）に落ちていました。埋め込みを INT8 に戻して 16/17（差 2.5）、INT8 版は 17/17（差 0.9）。 --compact は gpt-oss の埋め込みを INT4 にしないようにしました。すでにダウンロードした人は、モデル画面に出る「更新」を押すと 変わったファイル（約 1.2 GB）だけ取り直します（削除は不要。ロード中のモデルは先にアンロード）。
• 新しくインストールできなくなっていた問題を修正。OpenVINO 2026.5.0b1 が nightly の配布元から pre-release の配布元へ 移り、インストーラーが見つけられなくなっていました（「2026.5.0b1 がない」）。インストーラー・更新とも pre-release の 配布元を使います。依存パッケージに上限（transformers 6 未満、huggingface_hub 2 未満）を付け、--pre で他のパッケージの 試験版まで入らないようにしました（transformers 5.17 で動作確認済み）。
• 全体の見直し（コードレビュー）で見つかった問題の修正：
  • 長いプロンプトの読み込みで、層ごとの中間結果を最後まで抱えてメモリが増え続けていた（Qwen3.6-35B で 8K トークンに約 4 GB）。 以降の区間が使わない値はすぐ捨てます。
  • サーバーの起動と停止が重なると（アンロード直後のロードなど）、動いているサーバーを「停止中」と取り違えて二重に 起動することがあった。起動・停止を 1 つずつ行い、サーバーはプロセスの開始時刻でも確かめます（再起動後の PID の 使い回しで別のプロセスを止めない）。
  • ポートが使用中のときやメモリ不足で落ちたとき、「停止中」としか出なかった。ロード前にポートを確かめ、止まった理由を サーバー画面に出します。
  • Windows：ユーザー名に日本語などが入っていると「ログイン時にトレイを起動する」が動かなかった（レジストリの Run に登録）。
  • ストリーミングで、stop 文字列の手前まで送った文字が取り消せなかった／文字化けの直後から出力が止まることがあった／ コンテキスト上限の直前だと 0 トークンで終わった。
  • 思考を回答と分けて返すように（API の reasoning_content、チャット画面は折りたためる「思考」欄）。reasoning_effort にも対応。
  • API：エラーを OpenAI の形で返す、不正な JSON や画像で 500 にならない、切断済みのリクエストは処理しない、画像の取得で ほかの要求を止めない、ローカルネットワークの画像 URL は取りに行かない、n・logprobs・/v1/models/{id} など。
  • gpt-oss のツール呼び出しをストリーミングすると <|start|>assistant が本文に混ざった。
  • 設定ファイルを書き換え途中で壊さない（一時ファイルに書いてから置き換え、壊れていたら .bad に退避）。
  • 保存先フォルダが使えない（外したドライブなど）とウィンドウが開けなかった。途中で止まったダウンロードや、いまは 見えないフォルダも画面から消せるように。ダウンロード中は自動更新しない。
  • Ubuntu：ウィンドウの確認ダイアログを画面内のものに（WebKit で出ない場合があったため）、「API の URL をコピー」を Wayland でも（wl-clipboard）、ホームにスペースがあるとランチャーが動かなかった、インストーラーを端末なしでも実行可能に。
  • コンパイル：部品のコンパイルがコンパイラーごと落ちたとき次回その経路を飛ばすように。メモリ不足や中断で「使えない経路」 と永久に記録しないように。初回ロードもコンパイル結果を読み直して 2 回目以降と同じメモリで動くように。 キャッシュの掃除は、今回読み込んだグラフの古い版だけを消すように（64 トークン処理のオンオフで消えない）。
  • SSD からのエキスパート読み込み：読み込み失敗で壊れた枠が残らない、先読み中の枠を待ってから入れ替える。
  • 変換：--graphs-only が --compact／--prune の情報を消していた、--prune が gpt-oss／Gemma では黙って無視された、 --expert-bits と既存のエキスパートの不一致、transformers 5 形式の RoPE 設定（gpt-oss）、エキスパートの並びの検証、 engine.json は最後に書く（途中で止まった変換を完成品と見なさない）。変換結果（グラフと重み）は 0.11.0 とビット単位で同じです。
  • start.sh／start.bat の既定モデルが非公開の LFM2-8B-A1B だったのを Gemma 4 E4B に。
  • 重複コードの整理（コンパイル経路を 1 つに、変換器の共通部分、使われていない関数の削除）。

v0.11.0 (2026-09-29)

• OpenAI gpt-oss-20b に対応（gpt_oss）。MoE（32 個から 4 個）、attention sink、YaRN の RoPE、128 幅の sliding 層、clamp 付き SwiGLU、harmony 形式（analysis／commentary／final チャネル。思考モードで analysis を表示、 commentary のツール呼び出しは OpenAI 形式に変換）。エキスパートはチャネル単位 INT4（9.6 GB、16 GB 機に載る。 bf16 と比べて貪欲生成 17 トークン中 16 一致、ロジットは確信度の高いところで 5〜12 低め）で、 onw convert --expert-bits 8 の INT8 版（19 GB、ロジット差 0.9）も公開。NPU 3720 で 8.5 tok/s（INT8 は 6 tok/s）。
• gpt-oss を NPU の FP16 で動かすための修正：巨大活性（残差の絶対値が 42,000 に届く）で RMSNorm の二乗が溢れる／ 行の最大値で割ると小さい要素が非正規化数になって 0 に潰される → 行を最大 64 にスケールしてから計算。INT8 の コード（≦127）と活性の積和が fp16 で溢れる（エキスパートと LM ヘッド）→ トークンごとに活性を最大値で割ってから 積和し、後で戻す。パディング行が RMSNorm で inf を作る件も修正。
• 変換：--expert-bits 4|8、--fmt の既定はアーキテクチャごと（gpt-oss はアテンションを INT8）。行幅がグループで 割り切れない重み（gpt-oss の 2880）は小さいグループに落とす。エキスパートの書き出しを 16 スレッド並列に。
• sliding 層だけの区間（gpt-oss）を子プロセスでコンパイルするときリングの形が渡っていなかった問題を修正。

v0.10.5 (2026-09-29)

• コンパイルキャッシュの自動掃除。モデルを読み込んだあと、その読み込みで使わなかったコンパイル結果（別の経路・ 別のブロックサイズ・以前の版の切り分け方のもの）を npu_cache から消します。NPUW を使わない機種では OpenVINO 側の キャッシュ（コンパイル確認の子プロセスや旧版が残していた複製）も空にします。手元では Gemma 4 の 32.6 GB → 8.1 GB、 LFM2-8B の 2.0 GB → 0.9 GB。ONW_CACHE_PRUNE=0 で止められます。
• アテンションのグラフも onw 自身の blob 置き場（npu_cache/onw_blobs/attn_*）に保存するように（OpenVINO のキャッシュを onw のもので占めないため）。コンパイル確認の子プロセスも、onw の blob に書き出すときは OpenVINO のキャッシュに複製を 残しません。

v0.10.4 (2026-09-29)

• Lunar Lake：0.10.3 で NPUW のコンパイルは通るのに読み込みが終わらない（最初の推論でプロセスが落ちる）問題を修正。 NPUW の重みバンクはコンパイル後もモデルの .bin を参照し続けるのに、読み込み後に解放していました。.bin はメモリに 複製せず mmap（ファイル裏付け）で持ち、モデルと同じ寿命にします（余分なメモリは使いません）。
• 切り分けた部品の NPUW は分割なし（NONE）ではなく REP（繰り返しブロック）パイプライン で。部品の中の Sliding 層 （Gemma 4 は 1 部品に 5 層）が折り畳まれ、コンパイルが短くなります（3720 で 91 → 64 秒）。REP が通らない部品は NONE、 それもだめなら通常コンパイルに落ちます。LM ヘッドの区間は NONE のまま（折り畳むものがないので損はありません）。

v0.10.3 (2026-09-29)

• Lunar Lake：0.10 以降 NPUW 重み共有が効いていなかった問題を修正。0.10 でグラフをアテンションごとに切り分けるようになった 部品に対して NPUW の自動分割が「宣言されていない Parameter」で失敗し、全部が通常コンパイルに落ちていました（重みが 1 トークン用と 16 トークン用の 2 コピーになり、Gemma 4 のコンパイルが 243 秒）。部品はほぼ 1 層ぶんで折り畳むものが ないので NPUW の分割をせず 1 サブグラフとしてコンパイルし、重みは共有バンクで持ちます。LM ヘッドの区間も同じ方法で NPUW を通します。以前の「通常コンパイル」の記録は無効にするので、次の読み込みで一度コンパイルし直します（古い コンパイル結果はモデルの「コンパイルキャッシュを削除」で消せます）。
• 保存後の確認ダイアログを「設定は保存しました。今すぐ再起動しますか？」に。キャンセルは再起動をやめるだけで、 設定は保存されています（次にモデルを読み込むときから反映）。
• NPU 3720 で ONW_NPUW=1 を使ったとき、最初の推論で落ちる問題を修正（重みを展開する DCOFF がモデルの .bin を 参照し続けるのに、読み込み後に解放していました）。3720 では NPUW は重みを FP16 に展開するためメモリを大きく 使います（Gemma 4 で 8.9 → 31.6 GB）。既定どおりオフのままを推奨します。

v0.10.2 (2026-09-29)

• 「実験的な設定」のスイッチを入れてもすぐオフに戻る問題を修正（編集中と見なされず、数秒ごとの状態更新で 保存済みの値に上書きされていました）。

v0.10.1 (2026-09-29)

• 設定画面に「実験的な設定（NPUW、Lunar Lake 向け）」を追加（どれも既定オフ、NPUW 重み共有がオンのときだけ効きます）。 llama.cpp の OpenVINO 版が NPU で使っている設定を参考にしたもので、Lunar Lake での検証用です。
  • MoE モデルでも NPUW 重み共有を使う（ONW_NPUW_MOE=1）：1 トークン用と 16 トークン用のグラフで重みを共有し、 メモリを減らす試み。以前 Lunar Lake の LFM2 で途中で止まったのは、古いドライバ（1.38 未満）のせいだった可能性があります。
  • NPUW の非同期実行（ONW_NPUW_ASYNC=1、NPUW_FUNCALL_ASYNC）。
  • コンパイル結果を重みなしで保存（ONW_CACHE_SIZE=1、CACHE_MODE=OPTIMIZE_SIZE）：コンパイルキャッシュを小さくし、 読み込み時はモデルの重みを使います。
• 長い会話の CPU 負荷を削減：全体が見えるブロックのマスクを作り直さず使い回すように（8K トークンで 1 トークンあたり 19.0 → 14.2 ms の CPU 時間）。

v0.10.0 (2026-09-29)

• 長い文脈に対応（ページ化した INT8 KV キャッシュ）。KV キャッシュを会話が伸びた分だけ確保し、アテンションは 使った長さの分だけ NPU で計算するように。コンテキスト長は既定 32K、モデルの最大（Qwen3.5／3.6 は 262K、Gemma 4 は 128K）まで設定でき、長さを変えても再コンパイルはありません。重みのある区間が文脈の長さに依存しなくなったので、 Lunar Lake（16 GB）で Gemma 4 の 32K がコンパイルできなかった問題も解消。変換済みのモデルはそのまま使えます （読み込み時にグラフを切り分けます。初回だけ区間のコンパイルがあります）。従来の方式は ONW_KV=legacy で使えます。
• 前の既定値（1024）のままの設定は 32K に引き上げます（自分で選んだ長さはそのまま）。
• Gemma 4：RoPE の角度をグラフ内の FP16 で計算していたため、2048 を超える位置で回答が崩れる問題を修正（角度は CPU の FP32 で計算して渡す）。
• Ubuntu：ランチャーから起動すると何も起きない問題を修正（作業フォルダがホームになり、~/onw が本物のパッケージを 隠していた）。ランチャーとログイン時の自動起動に作業フォルダを入れ、既存のランチャーも起動時に直します。

v0.9.2 (2026-09-29)

• ツール呼び出し（function calling）に対応。OpenAI 互換 API の tools を受け取り、モデルが呼び出しを決めると tool_calls として返します（ストリーミングも）。履歴の tool_calls と role: "tool" の結果もモデルに渡ります。 Qwen3.5／3.6、Gemma 4、LFM2.5 でそれぞれ違う呼び出しの書式を onw が読み取ります。

v0.9.1 (2026-09-28)

• トレイの「終了」で onw ウィンドウも閉じるように（これまでは「接続なし」のまま残っていました）。更新による再起動のときは 閉じずに待ちます。
• 「今すぐ確認」を押すとすぐ「確認中…」と出し、終わったら結果（最新版です／新しい版のカード／確認できなかった理由）を 必ず表示するように。通信が遅いと、確認が終わるまで何も起きないように見えていました。
• 更新のダウンロードを 8 並列に（テスト機で 86 ファイル 4 秒）。

v0.9.0 (2026-09-28)

• LFM2.5-2.6B（LiquidAI、2.6B の dense）に対応。NPU 3720 で 12〜13 tok/s（先読み検証で 29〜34 tok/s）、使用メモリ約 4.3 GB。 onw convert が dense の LFM2／LFM2.5（lfm2）を変換できるように。
• LFM 系の変換済みモデルの配布をやめ、一覧から外しました（LFM2-8B-A1B-onw は非公開に）。LFM Open License v1.0 は 年間売上 1000 万ドル以上の法人による商用利用を対象外にしているためです。変換と実行の機能はそのままで、元のモデルから 手元で変換できます（手順は LFM を自分で変換。自分で変換したフォルダは一覧に「ローカル」として出ます）。
• onw convert が torch なしで動くように（safetensors を自前で読み込み。Qwen の画像エンコーダーの変換だけは今も torch が必要）。
• 値の大きさが極端に違うトークンが並ぶモデルで、NPU の FP16 で RMSNorm が崩れる問題に対処（各行を最大値で割ってから計算）。
• 必ず考えてから答えるテンプレート（LFM2.5）でも、既定は考えずに答えるように（「思考モード」で考えさせられます）。

v0.8.5 (2026-09-27)

• 更新後、開いていた onw ウィンドウも新しい版で開き直すように（これまではページだけ読み直していたため、タイトルの版表示や アイコンが古いままでした）。開いていたタブはそのまま。更新で再起動したトレイも、新しい版のウィンドウを開きます。

v0.8.4 (2026-09-27)

• 画面を英語・中国語（簡体字）にも対応。OS の言語に合わせて自動で選び、「設定」の「言語」で切り替えられます （onw ウィンドウ、トレイのメニューと通知、チャット画面、検証ページ）。
• 新しいアイコン（走るチップ）。トレイは状態を右下の点で表示（緑＝動作中、黄＝ロード中、赤＝失敗、灰色＝停止中）。 ウィンドウ、スタートメニュー／アプリ一覧、ブラウザのタブにも。
• 設定の保存で、サーバーに関係する項目が変わったときだけ再起動を確認するように。

v0.8.3 (2026-09-27)

• 更新の通知を右下のカードに（「更新する」「あとで」「変更点」、更新中は進み具合を表示）。サーバータブ上部の帯はやめました。
• 更新後、開いていたウィンドウが再起動したトレイに自動でつなぎ直し、「v… に更新しました」と表示するように。

v0.8.2 (2026-09-27)

• 生成時の予測先読みを既定でオフに。外れた予測の分まで読むため CPU 時間が 1 トークンあたり 51 → 78〜85 ms に増え、 8 コアの Lunar Lake では負担が大きかったため（ONW_PREFETCH_K=12 で有効）。プロンプト処理の先読みはそのまま。

v0.8.1 (2026-09-27)

• 自動更新：起動時と 1 日ごとに新しい版を確認し、トレイの通知とウィンドウの帯で知らせます。「更新」ボタン 1 つで ダウンロード・入れ替え・再起動まで行い、動いていたモデルを読み込み直します（1 行インストーラーで入れた場合）。
• この更新履歴（CHANGELOG.md）を追加。

v0.8.0 (2026-09-27)

• SSD からエキスパートを読む MoE を、メモリを増やさずに高速化。
  • プロンプト処理の先読み：次の層で使うエキスパートを、NPU が次の塊を計算している間にキャッシュへ読み込み （画像付きの質問 24 秒 → 15 秒）。
  • 生成時の予測先読み：1 層前の状態にルーターを当てて上位 12 個を予測し、計算中に読み込み（本物の上位 8 個の 92% を的中。 SSD 待ち 31 → 13 ms／トークン、生成 5.8 → 6.5 tok/s）。予測は別スレッド、急ぎの読み込みは別の待ち行列。
  • 読み込み時のコピーを 1 回に。

v0.7.2 (2026-09-27)

• Linux で保存済みのコンパイル結果をストリームで読み込むように（メモリマップのままだと NPU 4000 のドライバーで最初の推論が失敗）。
• ONW_OWN_BLOBS=0／ONW_IMPORT=stream|mmap の切り替えを追加。

v0.7.1 (2026-09-27)

• モデル一覧の説明文と、候補一覧のメモリの値を v0.7 の実測に更新。

v0.7.0 (2026-09-27)

• 使用メモリを 2〜6 割削減（Gemma 15 → 6 GB、Qwen3.5-9B 20 → 11 GB、Qwen3.6-35B 23 → 20 GB など）。
  • コンパイル結果を onw が自分で保存・読み込みし、ドライバーへ渡したら手放す（OpenVINO のキャッシュ経由だと二重に保持）。
  • 画像エンコーダーは画像が来たときだけ読み込み、24 GB 未満の PC では使用後に解放。
  • CPU で引くだけの表（埋め込み、Gemma の層ごとの埋め込み）はファイルのメモリマップのまま。
  • エキスパートの読み込みを OS のキャッシュを通さない直接読み込みに（起動も高速化）。
• Qwen3.6-REAP でも SSD 読み込みが効くように。
• README に「私たちの知る限り初」の 4 項目め（Intel NPU での SSD 読み込み MoE）を追加。

v0.6.1 (2026-09-27)

• SSD 読み込み時、プロンプトを層ごとに処理（各層のエキスパートをプロンプト全体で 1 回だけ読む）。

v0.6.0 (2026-09-27)

• メモリに入りきらない MoE を、エキスパートを SSD から読みながら実行（LRU キャッシュ＋直接読み込み、 Windows は NO_BUFFERING、Linux は O_DIRECT）。設定画面に「エキスパートのメモリ」（auto は足りないときだけ）。

v0.5.0 (2026-09-25)

• 新しいウィンドウ：HTML の画面を小さなネイティブウィンドウで表示（pywebview）。行の背景色で状態、狭い幅では列を減らす。
• モデル管理（ダウンロード・ロード・設定）をトレイ側に移し、ウィンドウを閉じてもダウンロードが続くように。
• セットアップで pip を更新しない（新しい pip でインストールが失敗したため）、失敗時は環境を 1 回作り直す。
• インストーラーの改行コードと、空で上がっていた setup.sh／start.sh を修正。

v0.4.10 (2026-09-25)

• 初めて使うコンパイル方法は子プロセスで試す（NPU のコンパイラが落ちても本体は無事）。
• NPU 4000 向け NPUW の設定を単体版と同じに（Qwen3.5-9B が Lunar Lake で動くように）。
• ログにコンパイラの版を表示。

v0.4.9 (2026-09-25)

• タイトルとログにバージョンを表示。
• コンパイルの代替手段（NPUW → タイル 1 つ → 従来方式 → そのブロックサイズを使わない）と、その記録。

v0.4.8 (2026-09-25)

• NPUW の修正（SLICE_OUT を使わない、真偽値の定数を置き換え）、NaN の検知、ONW_SIZES、Linux ドライバー 1.38 の注意書き、調査用ツール。

v0.4.7 (2026-09-25)

• MoE モデルは NPUW の対象外、壊れた文字で表示が止まらないように、「キャッシュを削除」ボタン、保存ボタンを上に。

v0.4.6 (2026-09-25)

• NPU 4000 以上の NPUW はコンパイラ側で量子化を戻す設定に（OpenVINO 本家の LLM モードと同じ）。

v0.4.5 (2026-09-25)

• NPUW の重み共有（NPU 4000 以上で自動、試験的）。Ubuntu で一覧の行が潰れる問題を修正。

v0.4.4 (2026-09-25)

• ロード／アンロードの画面、モデルの場所の表示、二重起動防止、状態確認を裏で、PC ごとのメモリ目安。

v0.4.3 (2026-09-25)

• モデルの保存先を選べるように、すでにモデルがあるフォルダを追加できるように。

v0.4.2 (2026-09-25)

• 1 行インストーラー（install.ps1／install.sh）、初心者向けの「はじめに」。

v0.4.1 (2026-09-25)

• 日本語の README と英語の README_en.md。

v0.4 (2026-09-25)

• API 中心のサーバー（/ に情報、/health、CORS、--api-key、/chat、/check）、onw ウィンドウ（モデルのダウンロード・サーバー操作・設定）、 Python の検出と winget でのインストール。

v0.3 (2026-09-25)

• 読み込み時のコンテキスト長の変更、top_k と繰り返し抑制、トレイ常駐とセットアップスクリプト、--compact／--prune。

v0.2 (2026-09-25)

• 名前を npue から onw（俺のNPUがこんなに動くわけない）に。onw コマンド、Qwen3.5（dense）／Gemma 4／画像入力に対応、出力層を独立した区間に。

v0.1 (2026-09-24)

• 最初の公開（npue）：Intel NPU だけで LLM を動かすエンジン、LFM2-8B-A1B と Qwen3.6-35B-A3B（MoE）。