onw 2.0.2: dense 64-token prompt blocks on all NPUs again - NPUW_DQ_FULL=NO on NPU 5000+ (the cause of the Panther Lake errors); Panther Lake Qwen3.5-9B 44 -> ~157 tok/s

CHANGELOG.md

@@ -5,6 +5,13 @@
 日付は日本時間です。各版は Hugging Face の `ryugyosoft/onw` にタグ（`v0.4.2` 以降）付きで残っています。
 onw ウィンドウは、新しい版があるとこのファイルから変更点を表示します（`## v…` の見出しで区切っています）。
 
+## 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 でも正しく動いているので、変わりません。
@@ -18,7 +25,7 @@ onw ウィンドウは、新しい版があるとこのファイルから変更
   - **モデルの更新が必要です**（カードに「更新あり」と出ます。差し替えは区間ファイルの約 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 のみ）：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 が使えない設定など）でも使うようになります。
+- **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 にすると今までどおりです。

CHANGELOG_en.md

@@ -4,6 +4,13 @@
 
 Dates are JST. Every version is on Hugging Face `ryugyosoft/onw`, tagged from `v0.4.2` on.
 
+## v2.0.2 (2026-10-17)
+- **Dense models read prompts 64 tokens at a time on Panther Lake and Lunar Lake again** (the cause behind 2.0.1 is found and fixed). The wrong results on Panther Lake came from one setting of the weight-sharing layer (NPUW, `NPUW_DQ_FULL`). With the setting OpenVINO itself and llama.cpp use, the results are right and faster too.
+  - Panther Lake (Qwen3.5-9B INT4, 1,024 tokens): ~44 -> ~157 tok/s (faster than 2.0.0's ~105 tok/s, and right). 16 tokens at a time ~44 -> ~51 tok/s.
+  - The first compile is shorter as well (Qwen3.5-9B ~23 -> ~14 min), and memory use slightly lower.
+  - Panther Lake compiles again on the first load after the update. Lunar Lake and the NPU 3720 (Meteor Lake, Arrow Lake) keep their caches (Lunar Lake's 64-token graphs were checked to compute right all along).
+  - The Qwen3.6 models (sped up in 2.0.0) do not use this setting and are unchanged.
+
 ## v2.0.1 (2026-10-17)
 - **On Panther Lake and Lunar Lake the dense models' 64-token blocks (new in 2.0.0) are off again**: on Panther Lake (NPU 5010) the 64-token graphs added in 2.0.0 computed wrong, and Qwen3.5-9B and others could write gibberish (the 16-token blocks compute right). NPU 4000 and later pick their blocks as in 1.4.13 again. On the NPU 3720 they compute right, so it keeps reading prompts 64 tokens at a time (~2-2.5x). The updated models can stay as they are.
 - The Qwen3.6 prompt path (2.0.0) works right on Panther Lake too and is unchanged.
@@ -17,7 +24,7 @@ Dates are JST. Every version is on Hugging Face `ryugyosoft/onw`, tagged from `v
   - **The models need an update** (their card shows "update available"; only the segment files, ~0.9 GB, are replaced). The first load after it compiles the new graphs. Older onw versions keep working with the updated models.
   - On PCs below 24 GB (a 16 GB Lunar Lake, for example) compiling the new graphs runs out of memory, so they keep the old prompt path (`ONW_GROUPED=1` forces it, `0` turns it off).
 - **Qwen3.6 models generate a little faster**: for single tokens the segments' inputs and outputs are wired to each other once, with no hand-over at every token. Panther Lake 8.9 -> 10.3 tok/s, NPU 3720 6.0 -> 6.5 tok/s (same output).
-- **Prompts of the dense models about 2-2.5x faster** (from 2.0.1 on the NPU 3720 only): Qwen3.5-9B, Ornith-1.5-9B, NeoHorse-1-4B, Granite 4.2 3B / 8B and llm-jp-4.1-8B-thinking (INT4 / INT8) get 64-token blocks, so prompts run 64 tokens at a time instead of 16. Gemma 4 E4B and the NF4 models now use their 64-token blocks on PCs that could not before too (NPU 3720 with less than 24 GB, NPUW off, ...).
+- **Prompts of the dense models about 2-2.5x faster** (NPU 3720 only in 2.0.1, all machines again in 2.0.2): Qwen3.5-9B, Ornith-1.5-9B, NeoHorse-1-4B, Granite 4.2 3B / 8B and llm-jp-4.1-8B-thinking (INT4 / INT8) get 64-token blocks, so prompts run 64 tokens at a time instead of 16. Gemma 4 E4B and the NF4 models now use their 64-token blocks on PCs that could not before too (NPU 3720 with less than 24 GB, NPUW off, ...).
   - 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.
   - Practically the same output (KL 0.00005-0.0015 against the 16-token blocks, the first token equal).
   - Practically no extra memory (+0.35-0.5 GB): the 64-token graphs are loaded in place of the 16-token ones, so there is no extra copy of the weights. Short inputs and draft checks cost a little more on them (on the NPU 3720 prompt lookup decoding turns itself off). The setting "64-token blocks" = off keeps the old way.

MANUAL.md

@@ -167,7 +167,7 @@
 | メモリ節約モード | 1 トークン用と 16 トークン用のグラフを入れ替えて、片方だけを持ちます。待機中のメモリが約 4 割減る代わりに、回答の出だし数秒は遅めで、先読み検証は使いません。初回のコンパイルも並列にせず 1 つずつ行います（コンパイル中のメモリを抑えるため）。効くモデルがあるときだけ表示され、この PC で効くモデルの名前が出ます |
 | 厳格 | メモリ節約モードの追加。2 種類のグラフを同時に持たないので、メモリは最小になりますが、回答のたびに書き始めるまで数秒待ちます |
 | エキスパートのメモリ | Qwen3.6 系の MoE 用。上限を超えるエキスパートは SSD に置いたまま、必要なときだけ読みます（メモリが少なくても動きますが、遅くなります） |
-| 64 トークン処理 | 長いプロンプトの処理が約 2〜2.5 倍速くなります。NPU 3720 では dense モデルすべてで、16 トークン用のグラフの代わりに読み込むのでメモリはほぼ増えません（+0.3〜0.5 GB。auto はオン、off にすると今までどおり 16 トークンずつ）。Lunar Lake 以降は Gemma と NF4 版だけで、重みを共有するのでメモリはほぼ増えません（auto はメモリ 24 GB 以上か NPUW のときオン） |
+| 64 トークン処理 | 長いプロンプトの処理が約 2〜2.5 倍速くなります（dense モデル。Qwen3.6 系は別の方法で速くしています）。16 トークン用のグラフの代わりに読み込むので、メモリはほぼ増えません（+0.3〜0.5 GB）。auto はオン。off にすると今までどおり 16 トークンずつ（短い入力の多い使い方や、NPU 3720 で先読み検証を使いたいとき） |
 
 ### 詳細
 

MANUAL_en.md

@@ -178,7 +178,7 @@ applies them ("Discard" throws them away). For settings that need a server resta
 | Memory-saving mode | Swaps the 1-token and 16-token graphs so only one set is held: about 40% less memory when idle, but the first seconds of an answer are slower and prompt lookup is not used. The first compile also runs one graph at a time instead of in parallel (less memory while compiling). Shown only when it applies, with the models it works for on this PC |
 | Strict | An addition to the memory-saving mode: never holds both sets of graphs, for the least memory, but every answer waits a few seconds before it starts |
 | Expert memory | For the Qwen3.6 MoE models: experts beyond the limit stay on the SSD and are read when needed (works with less memory, but slower) |
-| 64-token blocks | Long prompts are processed ~2-2.5x faster. On the NPU 3720 for every dense model, loaded in place of the 16-token graphs, so memory hardly grows (+0.3-0.5 GB; auto = on, off = 16 tokens at a time as before). From Lunar Lake on for Gemma and the NF4 builds only, with the weights shared (auto = on with 24 GB+ RAM or NPUW) |
+| 64-token blocks | Long prompts are processed ~2-2.5x faster (dense models; the Qwen3.6 models are sped up another way). Loaded in place of the 16-token graphs, so memory hardly grows (+0.3-0.5 GB). auto = on. off = 16 tokens at a time as before (for mostly short inputs, or to keep prompt lookup decoding on the NPU 3720) |
 
 ### Advanced
 

README.md

@@ -129,9 +129,9 @@ NPU は数トークンを 1 トークンとほぼ同じ時間で計算できる
 （コンテキスト長、64 トークン処理、エキスパートのメモリ）を反映した目安です。メモリが足りない PC では、Qwen3.6 系の
 エキスパートを SSD に置いたまま動かせます（設定の「エキスパートのメモリ」。仕組みは[技術解説](TECHNICAL.md)）。
 
-プロンプト（入力した文章）の読み込みは、dense モデルは NPU 3720 で 64 トークンずつ、Qwen3.6 系はプロンプト全体を層ごとにまとめて
+プロンプト（入力した文章）の読み込みは、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.6-35B-A3B 約 147 tok/s です。
+約 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 の
@@ -194,7 +194,7 @@ onw list                                                      # 対応アーキ
 | temperature、top_p、top_k、繰り返し抑制（repetition / presence / frequency penalty）、max_tokens、stop、seed、思考モード | リクエストごと（API またはチャット画面） | 不要 |
 | ポート、待ち受けアドレス、モデル、デバイス、先読み検証のオン／オフ | サーバーのオプション／設定画面、再起動（約 20 秒） | 不要 |
 | **コンテキスト長**（`--context`、既定 32K、モデルの最大まで） | サーバーのオプション／設定画面 | 不要（KV キャッシュの上限が変わるだけ） |
-| 64 トークン処理（dense モデルのプロンプトを 64 トークンずつ。auto は NPU 3720 ではオンで 16 トークン用のグラフの代わりに読み込む、Lunar Lake 以降は Gemma・NF4 版だけで RAM 24 GB 以上か NPUW のときオン。off で 16 トークンずつ、`ONW_S64=1` で両方） | `ONW_S64=1/0`／設定画面 | 初回のみ |
+| 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` | 初回のみ |
 | エキスパートのメモリ（Qwen3.6 系。上限を超える分は SSD から読む） | `ONW_EXPERT_GB=5`／設定画面 | 不要 |
 | NPUW 重み共有（試験的。auto は Lunar Lake 以降でオン、MoE モデル（LFM2・Qwen3.6）と区間の多いモデル（Granite・llm-jp）は対象外：重みを 1 コピーにしてメモリとコンパイル時間を削減） | `ONW_NPUW=1/0`／設定画面 | 初回のみ |

README_en.md

@@ -118,9 +118,9 @@ vision encoder freed after each image (the default below 24 GB of RAM). The "Mem
 window applies that PC's settings (context length, 64-token blocks, expert memory). On a PC short of memory the
 Qwen3.6 models can keep their experts on the SSD (Settings → "Expert memory"; how it works: [Technical notes](TECHNICAL_en.md)).
 
-Prompts (the text you send) are read 64 tokens at a time on the dense models on the NPU 3720, and layer by layer over the whole prompt
+Prompts (the text you send) are read 64 tokens at a time on the dense models, and layer by layer over the whole prompt
 on the Qwen3.6 models (onw 2.0): on the 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 of RAM or more); on Panther Lake Qwen3.6-35B-A3B ~147 tok/s.
+Qwen3.6-35B-A3B ~100 tok/s (24 GB of RAM or more); on Panther Lake Qwen3.5-9B ~157, Qwen3.6-35B-A3B ~147 tok/s.
 
 Prompt lookup decoding is used automatically where a verification block is cheap enough (the LFM models, Qwen3.5-9B
 and Gemma from Lunar Lake on, ...), and every model keeps the conversation state between turns (a follow-up with an image
@@ -182,7 +182,7 @@ What needs what:
 | temperature, top_p, top_k, repetition / presence / frequency penalty, max_tokens, stop, seed, thinking | per request (API or chat UI) | no |
 | port, address, model, device, prompt lookup on/off | server option / settings, restart (~20 s) | no |
 | **context length** (`--context`, 32K by default, up to the model's maximum) | server option / settings | no (it only bounds the KV cache) |
-| 64-token prompt blocks (dense models read prompts 64 tokens at a time; auto = on for the NPU 3720, loaded in place of the 16-token graphs; from Lunar Lake on only Gemma and the NF4 builds, with 24 GB+ RAM or NPUW; off = 16 at a time, `ONW_S64=1` = both) | `ONW_S64=1/0` / settings | once, the first time |
+| 64-token prompt blocks (dense models read prompts 64 tokens at a time; auto = on, loaded in place of the 16-token graphs; off = 16 at a time, `ONW_S64=1` = both) | `ONW_S64=1/0` / settings | once, the first time |
 | MTP draft tokens (the NF4 Qwen3.5-family builds; auto = on from Lunar Lake) | `ONW_MTP=1/0` | once, the first time |
 | expert memory (Qwen3.6 models; the rest streams from the SSD) | `ONW_EXPERT_GB=5` / settings | no |
 | NPUW weight sharing (experimental; auto = on from Lunar Lake, not for the MoE models LFM2 / Qwen3.6 or models with many parts (Granite, llm-jp): one copy of the weights, less memory, much faster compile) | `ONW_NPUW=1/0` / settings | once, the first time |

TECHNICAL.md

@@ -377,9 +377,9 @@ dense モデルのプロンプトは 16 トークンのブロックで処理し
 - **やったこと**：64 トークンのグラフを加え、16 トークン用の代わりに読み込みます（1 トークン用＋プロンプト用の 2 種類のまま）。NPU 3720 は重みを共有できないので、サイズを足すと重みの写しが増えますが、入れ替えなら増えません。Lunar Lake 以降も、サイズごとに NPU の作業領域（約 0.6 GB）を取るので入れ替えにしました。
 - **DeltaNet の計算は 16 トークンのチャンクのまま**（`ir.deltanet_chunks`）。64 トークンを 1 チャンクにする式（減衰をチャンク内の累積とチャンクの合計の積で作り、fp16 の桁落ちを避ける）も試しました。NPU 3720 では状態の読み書きが減って DeltaNet が 1.5 倍速くなりましたが、Panther Lake のコンパイラーでは答えが大きくずれたので採用していません。
 - **配布**：公開済みのモデルの重みファイル（`seg*.bin`）は変えていません。同じ変換器で作り直した 64 トークンのグラフの定数は、ほとんどが既存の `seg*.bin` の中に同じものがあり、そこを指します。足りない分（大きなブロックの形を表す整数、区間あたり数百バイト）だけを `seg*x.bin` に置き、読み込み時に入力として読んでから定数に置き換えます（`compact.graft_sizes`、`runtime._xbin_model`）。`engine.json` の `prompt_sizes` に書くので、2.0 より前の onw はこれらを読まず、今までどおり動きます。更新のダウンロードは数 MB です。
-- **Panther Lake では使わない（2.0.1）**：Panther Lake（NPU 5010）では、このモデルの 64 トークンのグラフの計算結果が正しくありませんでした（Qwen3.5-9B INT4 のロジットの KL が 14、16 と 128 トークンは正しい）。2.0.0 では速度だけを測っていました。NPU 4000 以降は 1.4.13 のブロックの選び方に戻しています。
-- **128 トークンは見送り**：Panther Lake では 139 tok/s とさらに速くなりますが、使用メモリが 16 トークンより約 1.1 GB 増え、初回のコンパイルが 9B で約 1 時間 40 分かかります（64 トークンで約 50 分）。NPU 3720 では 64 より遅くなります。
-- **結果**（1024 トークン）：Panther Lake の Qwen3.5-9B INT4 44 → 105 tok/s、NPU 3720 の Qwen3.5-9B 31〜43 → 80〜87、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。
+- **Panther Lake で計算がずれた件（2.0.1 で止め、2.0.2 で直した）**：Panther Lake（NPU 5010）では、2.0.0 の 64 トークンのグラフの計算結果が正しくありませんでした（Qwen3.5-9B INT4 のロジットの KL が 14）。原因は NPUW の `NPUW_DQ_FULL`（既定 YES）です。グループ量子化された INT4 の行列積を、重みのグループごとの行列積と足し算の連鎖に書き換える処理で、この NPU のコンパイラーが、ちょうど 64 行のときに、出力 4096 の行列積の後に足し算が続く形（各層の出力の射影と残差）を誤ってコンパイルしていました（16・32・48・80・96・128 行は正しい）。OpenVINO 自身の NPUW の LLM モードと llama.cpp は `NPUW_DQ_FULL=NO`（重みを転置するだけ）を使っています。2.0.2 では NPU 5000 番台でこれに合わせました。計算が正しくなったうえに、Qwen3.5-9B の 64 トークンは初回コンパイル 50 → 14 分、1024 トークン 105（誤り）→ 157 tok/s、16 トークンも 44 → 51 tok/s になり、メモリも少し減りました。NPU 4000（Lunar Lake）は YES のまま正しく計算でき、NO では約 2 割遅かったので変えていません。NPU 3720 は NPUW を使いません（使うと INT4 の重みを f16 に展開して持つので、9B でメモリが 9.8 → 34.7 GB になり、生成も半分になります）。
+- **128 トークンは見送り**：Panther Lake では 139 tok/s とさらに速くなりますが、使用メモリが 16 トークンより約 1.1 GB 増え、初回のコンパイルが 9B で約 1 時間 40 分かかります（64 トークンで約 50 分。どちらも `NPUW_DQ_FULL` が YES のときの値）。NPU 3720 では 64 より遅くなります。
+- **結果**（1024 トークン）：Panther Lake の Qwen3.5-9B INT4 44 → 157 tok/s（2.0.2）、NPU 3720 の Qwen3.5-9B 31〜43 → 80〜87、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。
 
 ## 1 ステップのホスト側の処理（onw 1.4）
 

TECHNICAL_en.md

@@ -387,12 +387,20 @@ Dense models read prompts in 16-token blocks. Every NPU run has a fixed cost tha
   inputs and turned into constants at load (`compact.graft_sizes`, `runtime._xbin_model`). They are listed under
   `prompt_sizes` in `engine.json`, which onw before 2.0 does not read, so it keeps working as before. An update
   downloads a few MB.
-- **Not used on Panther Lake (2.0.1)**: on Panther Lake (NPU 5010) these 64-token graphs computed wrong (Qwen3.5-9B INT4
-  logits KL 14; 16 and 128 tokens right) - 2.0.0 had only measured their speed there. NPU 4000 and later pick their blocks
-  as in 1.4.13 again.
+- **Wrong on Panther Lake (off in 2.0.1, fixed in 2.0.2)**: on Panther Lake (NPU 5010) the 2.0.0 64-token graphs
+  computed wrong (Qwen3.5-9B INT4 logits KL 14). The cause is NPUW's `NPUW_DQ_FULL` (default YES): it rewrites every
+  group-quantized INT4 MatMul into a MatMul per weight group plus an Add chain, and this NPU's compiler gets one shape
+  wrong at exactly 64 rows - a MatMul with 4096 outputs followed by an Add (every layer's out_proj + residual; 16, 32,
+  48, 80, 96 and 128 rows are right). OpenVINO's own NPUW LLM mode and llama.cpp use `NPUW_DQ_FULL=NO` (the weights are
+  only transposed); 2.0.2 does the same on NPU 5000+. Besides right results, Qwen3.5-9B's 64-token blocks now compile in
+  14 instead of 50 min and read 1,024 tokens at 157 instead of 105 (wrong) tok/s; the 16-token blocks go 44 -> 51 tok/s,
+  and memory is slightly lower. NPU 4000 (Lunar Lake) computes right with YES and runs ~20% slower with NO, so it keeps
+  YES. The NPU 3720 does not use NPUW (it would hold the INT4 weights expanded to f16: 9.8 -> 34.7 GB for a 9B, decode
+  halved).
 - **No 128-token blocks**: on Panther Lake they reach 139 tok/s, but take ~1.1 GB more memory than the 16-token
-  blocks and ~1 h 40 min to compile for a 9B the first time (64 tokens: ~50 min); on the NPU 3720 they are slower than 64.
-- **Result** (1,024 tokens): Panther Lake Qwen3.5-9B INT4 44 -> 105 tok/s; NPU 3720 Qwen3.5-9B 31-43 -> 80-87,
+  blocks and ~1 h 40 min to compile for a 9B the first time (64 tokens: ~50 min; both with
+  `NPUW_DQ_FULL` YES); on the NPU 3720 they are slower than 64.
+- **Result** (1,024 tokens): Panther Lake Qwen3.5-9B INT4 44 -> 157 tok/s (2.0.2); NPU 3720 Qwen3.5-9B 31-43 -> 80-87,
   llm-jp-4.1-8B 46 -> 111, NeoHorse-1-4B 67 -> 132, Granite 4.2 3B 69 -> 139 tok/s. KL 0.00005-0.0015 against the
   16-token blocks.
 

onw/__init__.py

@@ -2,4 +2,4 @@
 
 A small engine that runs LLMs entirely on the Intel NPU: static segment graphs + host-managed state.
 """
-__version__ = "2.0.1"
+__version__ = "2.0.2"

onw/app.py

@@ -301,13 +301,9 @@ def raise_window():
 
 
 def big_blocks_on(cfg, ram):
-    """64-token blocks beside the 16-token ones (memory estimate), the rule of chat.block_sizes: NPU 4000+ with
-    >= 24 GB RAM unless set in the settings; NPU 3720 only when forced on (2.0: "auto" loads them in the 16-token
-    graphs' place there)."""
-    b = cfg.get("big_blocks", "auto")
-    if b in ("on", "off"):
-        return b == "on"
-    return npu_arch() >= 4000 and ram is not None and ram >= 24
+    """A second copy of the weights for the 64-token blocks (memory estimate): only when forced on in the settings -
+    since 2.0 "auto" (chat.block_sizes) loads them in the 16-token graphs' place where the sizes cannot share weights."""
+    return cfg.get("big_blocks", "auto") == "on"
 
 
 def usable_ram(ram):

onw/chat.py

@@ -65,10 +65,6 @@ def block_sizes(meta, shared=False, mtp=False, arch=None):
         return [1]
     if only:
         return [S for S in sizes if str(S) in only.split(",")] or sizes
-    if arch is None or arch >= 4000:
-        # [2.0.1] NPU 4000+: as in 1.4 - the 64-token graphs added in 2.0 ("prompt_sizes") compute wrong on Panther
-        # Lake (NPU 5010, Qwen3.5-9B INT4: logits KL 14 against the 16-token blocks; 16 and 128 tokens are right)
-        return _block_sizes_14(meta, shared, mtp)
     cap = int(os.environ.get("ONW_PROMPT_MAX", "0")) or (64 if arch is not None and arch < 4000 else 0)
     if cap:
         sizes = [S for S in sizes if S <= cap]
@@ -93,23 +89,6 @@ def block_sizes(meta, shared=False, mtp=False, arch=None):
     return [S for S in sizes if S in keep or (S > 16 and (env == "1" or S == max(big)))]
 
 
-def _block_sizes_14(meta, shared, mtp):
-    """onw 1.4's choice (NPU 4000+): the 1- and 16-token graphs, larger blocks of "sizes" with NPUW or >= 24 GB RAM
-    (ONW_S64=1 / 0 forces them on / off), the smallest checking size instead of the 1-token graphs with MTP drafts."""
-    sizes = meta["sizes"]
-    env = os.environ.get("ONW_S64")
-    ram = total_ram_gb()
-    big = env == "1" if env in ("0", "1") else (shared or (ram is not None and ram >= 24))
-    sizes = [S for S in sizes if S <= 16 or big]
-    small = [S for S in sizes if S <= 16]
-    verify = [S for S in small if S >= 4]
-    if shared and mtp and verify:
-        keep = {min(verify)}
-    else:
-        keep = {S for S in small if S in (1, 16)} or set(small)
-    return [S for S in sizes if S > 16 or S in keep]
-
-
 # Thinking levels ("low" / "medium" / "high", the API's reasoning_effort): harmony models (gpt-oss, llm-jp) were trained
 # for them; models that only switch thinking on or off (Qwen, Gemma, Granite) get a budget of thinking tokens, after
 # which onw closes the thought and the answer follows (None: no limit)
@@ -138,6 +117,15 @@ class ChatEngine:
         arch = npu_arch(core) if device == "NPU" else None
         sizes = block_sizes(meta, shared, mtp, arch)
         from . import parts
+        while shared and parts.estimate(meta, sizes) > parts.MANY and len([S for S in sizes if S > 1]) > 1:
+            # [2.0] rather fewer block sizes than no sharing (a second copy of the weights): the 16-token graphs go
+            # first when larger prompt blocks are there, then the smallest of those
+            big = [S for S in sizes if S > 16]
+            if 16 in sizes and big:
+                drop = 16
+            else:
+                drop = min(big or [S for S in sizes if S > 1])
+            sizes = [S for S in sizes if S != drop]
         if shared and parts.estimate(meta, sizes) > parts.MANY:   # (NPUW goes off for so many parts: no sharing)
             shared = False
             mtp = use_mtp(meta, shared)

onw/i18n.json

@@ -39,7 +39,7 @@
 "URL をコピーしました": "URL copied",
 "auto（Lunar Lake 以降でオン）": "auto (on for Lunar Lake+)",
 "auto（OS に合わせる）": "auto (follow the OS)",
-"auto（NPU 3720 はオンで 16 トークン処理と入れ替え。Lunar Lake 以降は RAM 24 GB 以上でオン）": "auto (NPU 3720: on, in place of the 16-token blocks; Lunar Lake and later: on with 24 GB+ RAM)",
+"auto（オン。NPU 3720 などでは 16 トークン処理と入れ替え）": "auto (on; on NPU 3720 and the like in place of the 16-token blocks)",
 "auto（足りないときだけ SSD から）": "auto (SSD when RAM is short)",
 "gpt-oss-20b の高精度版": "The higher-precision gpt-oss-20b",
 "gpt-oss-20b の高精度版（エキスパート INT8。メモリ 24 GB 以上向け）": "The higher-precision gpt-oss-20b (INT8 experts; for 24 GB+ of RAM)",
@@ -397,7 +397,7 @@
 "URL をコピーしました": "已复制 URL",
 "auto（Lunar Lake 以降でオン）": "auto（Lunar Lake 起开启）",
 "auto（OS に合わせる）": "auto（跟随系统）",
-"auto（NPU 3720 はオンで 16 トークン処理と入れ替え。Lunar Lake 以降は RAM 24 GB 以上でオン）": "auto（NPU 3720：开启并替换 16 token 分块；Lunar Lake 及更新机型：内存 24 GB 以上时开启）",
+"auto（オン。NPU 3720 などでは 16 トークン処理と入れ替え）": "auto（开启；在 NPU 3720 等机型上替换 16 token 分块）",
 "auto（足りないときだけ SSD から）": "auto（内存不足时用 SSD）",
 "gpt-oss-20b の高精度版": "gpt-oss-20b 的高精度版",
 "gpt-oss-20b の高精度版（エキスパート INT8。メモリ 24 GB 以上向け）": "gpt-oss-20b 的高精度版（INT8 专家；面向 24 GB 以上内存）",

onw/runtime.py

@@ -54,7 +54,9 @@ def npu_info(core):
 
 def use_npuw(core):
     """NPUW weight sharing (one copy of the weights for all block sizes, much faster compile): on by default from
-    NPU 4000 (Lunar Lake) on; ONW_NPUW=1 / 0 forces it. On NPU 3720 it gave wrong output in our test."""
+    NPU 4000 (Lunar Lake) on; ONW_NPUW=1 / 0 forces it. Not on the NPU 3720: its compiler has no dynamic quantization, so
+    NPUW keeps the INT4 weights expanded to f16 (DCOFF) - [2.0.2] Qwen3.5-9B [1, 64] on Arrow Lake: 9.8 -> 34.7 GB, decode
+    5.1 -> 2.3 tok/s (right results with OpenVINO 2026.5)."""
     env = os.environ.get("ONW_NPUW", "auto")
     return env == "1" if env in ("0", "1") else npu_arch(core) >= 4000
 
@@ -1022,8 +1024,15 @@ class SegmentedModel:
             # by data pointer, so every block size reads its IR against the same in-memory copy of the .bin
             # same baseline as OpenVINO's NPUW LLM mode: NPU 4000+ compilers dequantize themselves (compiler DQ),
             # older ones get the weights decompressed by NPUW (DCOFF)
-            dq = {"NPUW_DQ": "YES", "NPU_COMPILER_DYNAMIC_QUANTIZATION": "YES"} \
-                if npu_arch(core) >= 4000 else {"NPUW_DCOFF_TYPE": "f16", "NPUW_DCOFF_SCALE": "YES"}
+            dq = ({"NPUW_DQ": "YES", "NPU_COMPILER_DYNAMIC_QUANTIZATION": "YES"}
+                  if npu_arch(core) >= 4000 else {"NPUW_DCOFF_TYPE": "f16", "NPUW_DCOFF_SCALE": "YES"})
+            if npu_arch(core) >= 5000:
+                # [2.0.2] NPU 5010 (Panther Lake): NPUW_DQ_FULL=NO, as OpenVINO's own NPUW LLM mode (and llama.cpp) set
+                # it. The default (YES) rewrites every group-quantized multi-row MatMul into a MatMul per weight group +
+                # an Add chain, which this NPU's compiler gets wrong at 64 rows (Qwen3.5-9B INT4: logits KL 14) and
+                # compiles 3-4x slower; NO only transposes the weights (a 64-token part: 274 -> 74 s compile, 47.8 ->
+                # 29.5 ms, right results). NPU 4000 (Lunar Lake) keeps YES: right there, and NO runs ~20% slower
+                dq["NPUW_DQ_FULL"] = "NO"
             # The same set as the standalone Qwen3.5 / Gemma ports that run on Lunar Lake, plus the shared weights bank.
             # Not NPUW_SLICE_OUT (cuts outputs to the last token; breaks multi-token blocks) and not the LLM mode's
             # "compute-layers-with-higher-precision" (its f32 -> f16 converts fail to compile on NPU 4000; our graphs

onw/web/manage.html

@@ -256,7 +256,7 @@
       </div>
       <div class="opt"><span class="k">エキスパートのメモリ</span><select id="f-expert_gb" style="width:220px"><option value="auto">auto（足りないときだけ SSD から）</option><option value="off">すべてメモリに置く</option><option value="2">2 GB</option><option value="3">3 GB</option><option value="4">4 GB</option><option value="5">5 GB</option><option value="6">6 GB</option><option value="8">8 GB</option></select>
         <span class="desc">Qwen3.6 系の MoE 用。上限を超えるエキスパートは SSD に置いたまま必要なときだけ読みます（動きますが遅くなります）。</span></div>
-      <div class="opt"><span class="k">64 トークン処理<span class="rc" title="変えるとコンパイルし直します">※</span></span><select id="f-big_blocks" style="width:300px"><option value="auto">auto（NPU 3720 はオンで 16 トークン処理と入れ替え。Lunar Lake 以降は RAM 24 GB 以上でオン）</option><option value="on">on</option><option value="off">off</option></select>
+      <div class="opt"><span class="k">64 トークン処理<span class="rc" title="変えるとコンパイルし直します">※</span></span><select id="f-big_blocks" style="width:300px"><option value="auto">auto（オン。NPU 3720 などでは 16 トークン処理と入れ替え）</option><option value="on">on</option><option value="off">off</option></select>
         <span class="desc">長いプロンプトの処理が速くなる代わりに、そのぶんメモリを使います（Gemma）。</span>
         <span class="desc">※ 64 トークン処理は on にしたときだけ（off にするのはすぐです）。</span></div>
     </div>