Ternary Bonsai 2 4B for onw — 2 ビットの 4B を Intel NPU で（Lunar Lake 以降専用）
日本語 | English
Prism ML の Ternary-Bonsai-2-4B（Qwen3.5-4B を三値の重みで学習し直したモデル）を、onw（俺のNPUがこんなに動くわけない）用に変換したものです。重みは三値（−1・0・+1）を 2 ビットのまま NPU に載せます。メモリ約 2 GB で、Lunar Lake の NPU で約 21 tok/s で答えます。画像も読めます。
Lunar Lake（Core Ultra シリーズ 2、NPU 4000）以降の NPU 専用です。 2 ビットの重みは NPU 4 以降のハードウェアでしか計算できず、Meteor Lake・Arrow Lake（NPU 3720）ではコンパイルできません。onw ウィンドウは Lunar Lake 以降の PC でだけ一覧に出します。
測定（onw 3.2.0、64 トークン用のグラフ入り）
思考オフ、約 1,200 トークンのプロンプト。
| Lunar Lake（Core Ultra 5 226V、NPU 4000、メモリ 16 GB、Ubuntu 26.04） | Panther Lake（Core Ultra X7 358H、NPU 5010、メモリ 64 GB、Windows 11） | |
|---|---|---|
| プロンプト処理 | 約 190 tok/s（64 トークンずつ） | 約 300 tok/s（64 トークンずつ） |
| 生成速度 | 約 22 tok/s | 約 22 tok/s |
| 専用メモリ（プロセス） | 約 1.8 GB | 約 2.1 GB |
| NPU のメモリ | —（Linux では測れません） | 約 2.6 GB |
| 初回起動（NPU 向けコンパイル、複数のプロセスで同時） | 約 5 分（融合グラフは裏でさらに約 6 分） | 約 6 分 |
| 2 回目以降の起動 | 約 17 秒 | 約 20 秒 |
2 ビットの重みは、1 トークン用と 64 トークン用のグラフで NPU 上の 1 組を共有します（2 組持たない）。64 トークンずつ処理した結果は、1 トークンずつ処理したときとほぼ同じです（確率分布の差 KL 0.0005〜0.0006）。
参考：onw 1.4.13（1 トークン用のグラフだけ）
| Lunar Lake（NPU 4000、メモリ 16 GB） | Panther Lake（NPU 5010、メモリ 64 GB） | |
|---|---|---|
| 生成速度（思考オフ） | 約 21 tok/s | 約 16 tok/s |
| プロンプト処理 | 約 21 tok/s（1 トークンずつ） | 約 16 tok/s（1 トークンずつ） |
| 使用メモリ（プロセス、画像を 1 枚読んだあと） | 約 1.9 GB | 約 2.4 GB |
| 初回起動（NPU 向けコンパイル） | 約 2 分 | 約 20 分（画像エンコーダーはさらに約 3 分） |
| 2 回目以降の起動 | 約 2 秒 | 約 4 秒 |
| ダウンロード | 1.8 GB | 1.8 GB |
2 台で、同じ質問に一字一句同じ答えが返りました（日本語・英語・画像で確認）。
制限
- 正直に書くと、NPU のメモリは 2 ビットの重みよりずっと大きく、ここは失敗です。 2 ビットの重みとスケールは約 0.9 GB ですが、 NPU では約 2.6 GB（約 2.9 倍）使います。2 ビットの重みを NPU で計算するには、128 個の重みごとに 16 バイトの「重みテーブル」が グラフごとに要り、1 トークン用と 64 トークン用の 2 組で、テーブルだけで重みと同じくらいになるためです（重み自体は 1 組を 共有しています）。メモリ 16 GB の PC でも動きますが、「2 ビットだから軽い」とは言えません。テーブルを持たずに済む方法を Intel に要望しています（27B はこのせいで 64 トークン版を出せませんでした）。
- 64 トークン用のグラフには onw 3.2.0 以降と、onw の NPU キット（Lunar Lake 以降の Windows・Ubuntu で既定）が必要です。 キットのコンパイラーで、Intel の NPU コンパイラー（8.3・8.4）が 2 ビットの重みを複数トークンのブロックで間違える不具合（npu_compiler #355）を直しています。キットを使わないときは、これまでどおり 1 トークン用のグラフだけで動きます。onw 3.1.0 以前は 64 トークン用のグラフを使わず、これまでどおり 1 トークンずつ動きます。
- MTP 先読み・先読み検証（PLD）は使えません（どちらも複数トークンのブロックが要るため）。
- 精度は、三値で学習した 4B の精度です。温度 0（API の既定）では、日本語の長めの説明で同じ言い回しを繰り返すことがあります（元のモデルでも同じ答えになることを確かめています）。チャット画面の既定のサンプリングでは起きにくくなります。
仕組み
- 重み：Bonsai の MLX 版（2 ビット、グループ 128）の値をそのまま使い、OpenVINO の
u2型の定数として NPU に渡します。詰め直しや再量子化はしていません（損失なし）。LM ヘッドは埋め込みと共有で（元のモデルどおり）、同じ 2 ビットの値を順方向に回して NPU で計算します。NPU 上では 2.125 ビット／重み（三値 2 ビット＋グループごとの f16 の倍率）です。 - アダマール回転：Bonsai 2 は、重みを「ブロック 512 のウォルシュ・アダマール変換で回した基底」で学習しています。そのため、行列の掛け算の前に入力を同じように回す必要があり、onw はこれをグラフの中で計算します（16×32 の 2 段に分けた形）。
- 埋め込み：回した状態で保存されている行を、変換時に元の基底に戻して INT4（グループ 32）の表にしています（ホスト側で参照）。
- 画像：Qwen3.5 の ViT（Bonsai 2 でも元の重みのまま）を 512×512 ピクセル相当の固定サイズで NPU 上で動かします（重みは INT8）。
- そのほかは Qwen3.5 系の onw モデルと同じ作りです（Gated DeltaNet＋ゲート付きアテンション、ページ式の INT8 KV キャッシュ）。変換結果は、元の重みを CPU で計算したものと一致することを確かめています（行列ごとの誤差 1e-6 以下）。詳しくは onw の技術解説。
使い方
- onw 3.2.0 以降を入れます（onw の「インストール」）。
- onw ウィンドウの「モデル」タブで Ternary Bonsai 2 4B (2-bit) を選び、「ダウンロード」を押します（Lunar Lake 以降の PC でだけ表示されます）。
- 「サーバー」タブで「ロード」。初回は NPU 向けのコンパイルに時間がかかります（上の表）。
上級者向け：hf download ryugyosoft/Ternary-Bonsai-2-4B-onw で取得したフォルダを onw serve フォルダ で起動できます。
ライセンス
Apache-2.0（元モデルと同じ）。重みは Prism ML の Ternary-Bonsai-2-4B の 2 ビットの値をそのまま並べ直したもので、学習も再量子化もしていません。元のモデルは Qwen の Qwen3.5-4B（Apache-2.0）です。Created using Bonsai by Prism ML.