onw-Image 0.3 — NPU だけで画像生成
日本語 | English
画像生成 AI Z-Image-Turbo（6B、Apache 2.0）を Intel NPU だけで 動かすデスクトップアプリです。 プロンプトの読み込み（テキストエンコーダー）、画像の生成（DiT）、画像への変換（VAE）まで、すべて NPU で計算します。 LLM を NPU で動かす onw の姉妹アプリです（上のバナーも onw-Image で生成）。
- Panther Lake（Windows）：1024×1024 の画像が 1 枚約 48 秒（FP8、9 ステップ。0.2 は約 77 秒）
- ディスクを食わない：NPU 向けにコンパイルした結果は合計わずか約 8〜25 MB（0.1 では約 13〜36 GB）。初回のコンパイルも Panther Lake で約 8 分です
- Lunar Lake（Ubuntu、メモリ 16 GB）：768×768 の画像が 1 枚約 80 秒（INT8、9 ステップ）
- 日本語のプロンプトにも対応
- 生成中もステップごとのプレビューを表示。画像はプロンプトとシード付きで PNG 保存
- 連続生成：同じプロンプトでシードを変えながら、指定した時間（最長 30 日）生成し続けます。 NPU で生成中のチップ全体の消費電力は 15 W 前後なので、つけっぱなしでも電球 1 個ぶん程度です
インストール（コマンドを 1 行貼るだけ）
Windows（Panther Lake）
PowerShell を開き、次の 1 行を貼り付けて Enter を押します。
irm https://huggingface.co/ryugyosoft/onw-image/resolve/main/install.ps1 | iex
アプリは %LOCALAPPDATA%\onw-Image に入ります。Python が無ければ winget で入れるか聞かれます。
続けてモデル（約 10 GB）がダウンロードされ、終わると onw-Image のウィンドウが開きます。
次回からはスタートメニューの「onw-Image」から起動できます。
Ubuntu（Lunar Lake）
端末（Ctrl+Alt+T）を開き、次の 1 行を貼り付けて Enter を押します。途中で必要な部品を入れるために、 ログインパスワードを 1 回聞かれます。
curl -fsSL https://huggingface.co/ryugyosoft/onw-image/resolve/main/install.sh | bash
アプリは ~/onw-image に入ります。続けてモデル（約 10 GB）がダウンロードされ、終わると onw-Image のウィンドウが開きます。
次回からはアプリ一覧の「onw-Image」から起動できます。
どちらも、同じ 1 行をもう一度実行すると最新版に更新されます。
初回だけ NPU 向けのコンパイルがあります
最初に生成ボタンを押すと、モデルをお使いの NPU 向けにコンパイルします（Panther Lake で約 8 分、Lunar Lake で約 20 分）。 進み具合はウィンドウに表示されます。結果は保存されるので、2 回目以降の起動は数秒で生成を始められます。 サイズを初めて変えたときや、長いプロンプト（64 トークン超）を初めて使ったときも、その分だけ同じコンパイルが走ります （Panther Lake で数分）。
0.1 から更新した場合、0.1 が残したコンパイル結果（Panther Lake で約 36 GB、Lunar Lake で約 13 GB）は更新の途中で自動的に消え、 新しい形式でもう一度コンパイルします。モデルも一部が新しくなるので、Panther Lake 版は約 10 GB、Lunar Lake 版は約 4 GB を 再ダウンロードします（不要になった古いファイルは自動で消します）。
必要なもの
| 項目 | Windows 版 | Ubuntu 版 |
|---|---|---|
| CPU | Core Ultra シリーズ 3（Panther Lake、NPU 5000 以降） | Core Ultra 200V シリーズ（Lunar Lake、NPU 4000） |
| モデル | FP8（DiT が FP8・全層共通の 1 グラフ。テキストエンコーダーは INT8） | INT8（DiT・テキストエンコーダーとも INT8。DiT は 6 層 1 グラフ） |
| メモリ | 32 GB 以上（64 GB で確認） | 16 GB 以上 |
| OS | Windows 11 | Ubuntu 24.04 以降（26.04 で確認）、linux-npu-driver 1.38 以降 |
| ディスク | 約 11 GB（モデル 10 GB、コンパイル結果 約 8 MB、Python 環境 0.4 GB） | 約 11 GB（モデル 10 GB、コンパイル結果 約 25 MB、Python 環境 0.4 GB） |
速さの目安（9 ステップ）
| 処理 | Panther Lake（1024×1024、FP8） | Lunar Lake（768×768、INT8） |
|---|---|---|
| 1 ステップ（DiT） | 約 5.0 秒（長いプロンプトでは約 5.7 秒） | 約 5.6 秒 |
| 1 枚（テキストエンコーダー・DiT・VAE の合計） | 約 48 秒（2 枚目以降） | 約 80 秒 |
| 平均消費電力（チップ全体） | 約 15 W | 約 14 W |
1024×1024 の PNG は 1 枚 1.2 MB 前後なので、連続生成で 1000 枚作っても 1.2 GB ほどです。 保存先の空きが 2 GB を切ると、連続生成は自動で止まります。
使い方
- 左側：プロンプト（Ctrl+Enter で生成）、サイズ、ステップ数（4〜12、既定 9）、枚数、シード（固定・ランダム）
- 枚数を 8 の次に進めると「連続」になり、続ける時間（1 時間〜30 日）を選べます
- 中央：生成中のプレビューと進み具合、完成した画像
- 右側：履歴（保存先フォルダの画像も表示）。ファイルの場所を開く、コピー、同じ設定で再生成、ごみ箱へ移動
- 保存先：ピクチャの
onw-Imageフォルダ（設定で変更可）。PNG にプロンプト・シード・サイズなどを書き込みます
仕組み（NPU で動かすための工夫）
- DiT は Panther Lake で FP8、Lunar Lake で INT8（テキストエンコーダーはどちらも同じ INT8 重み）：FP8 を NPU がそのまま計算できるのは NPU 5000 以降です。 FP8 は INT8 より精度が高く、元のモデルに近い画になります。INT8 版は外れ値の多い FFN の出力側を層ごとに調整しています
- 画像トークンとプロンプトのトークンを分けて量子化：プロンプト側の一部のトークンに巨大な値が出るため、 画像側は静的な尺度、プロンプト側はトークンごとの尺度にしています
- 1×1 畳み込みの形で計算：トークンを画像のマス目として並べると、NPU では行列積の形より約 2.5 倍速くなりました
- 全層で同じグラフにする（Panther Lake）：NPU 向けのコンパイル結果は、ループのない作業命令の羅列です （1024×1024 の 1 層で約 27 万件・約 80 MB）。0.1 は 30 層それぞれにこれを持っていましたが、0.2 では層ごとに違う値 （活性化と重みの FP8 の尺度、プロンプト側の補正）を重みと実行時の入力の側へ移して、30 層をまったく同じグラフにしました。 コンパイル結果は 1 つだけで、読み込むときに層ごとの重みを当てはめます
- 重みを持たないコンパイル結果：onw 3.x と同じ自前の NPU コンパイラー・プラグイン（Intel のオープンソースから構築）で、 コンパイル結果から重みを外し、モデルのファイルから読み込みます。作業命令は繰り返しが多いので、xz で圧縮して置きます （1 層ぶん 80 MB → 約 1 MB）
- VAE はタイルに分けて復号：512×512 ずつ重ねて復号し、つなぎ目をなめらかに混ぜます。画像サイズによらずグラフは 1 つで、 1024×1024 を丸ごとコンパイルするより大幅に軽くなります（コンパイル 14 分 → 1〜4 分、PSNR 41 dB で丸ごとと同等）
- アテンションのマスクを使わない：NPU ではマスク付きのアテンションが遅く不正確なため、詰め物のトークンは k・v を 0 にし、 v に「本物のトークン」を示す列を足して、その値で割ります（マスクと同じ結果）。0.3 の Panther Lake では FlashAttention-2 が ヘッド次元 128 でしか正しく動かないため、プロンプトの区切りの長さまでの詰め物は、モデル自身のパディング用トークンとして 注意に含めます（元のモデルも 32 の倍数まではそうしています。画の内容は変わらず、細部だけが変わります）
- 16 GB に収める（Lunar Lake）：6 層ずつを 1 つのグラフにまとめ、空きメモリに応じて常駐させる数を自動で決めます
- NPU の turbo：コンパイル済みのグラフを書き出し、NPU_TURBO 付きで読み込みます
- 層の中の「転送待ち」を削る（0.3、Panther Lake）：NPU のタスクを 1 つずつ記録して調べると、時間の大半は行列演算ではなく、 RMSNorm やアテンションのたびに大きなテンソルを NPU とメモリの間で何度も往復させる転送でした。RMSNorm を NPU の専用処理 （1 回の読み書き）に乗る形に書き換え、アテンションは NPU コンパイラーに眠っていた FlashAttention-2 を使うようにしました （1 層 205 → 150 ms 前後、精度はむしろ向上）。グラフは 0.2 のモデルファイルからアプリが起動時に組み直すので、 モデルの再ダウンロードは不要です
- 層と層の間でコピーしない（0.3）：層の出力をそのまま次の層の入力に渡し、次の層の準備は NPU の実行中に済ませます （1 ステップ約 1.4 秒短縮、結果はビット単位で同じ）
- NPU 特有の数値の落とし穴を回避：RoPE や RMSNorm の書き方によって NPU の計算結果が崩れる箇所を見つけ、 正しく計算できる形に置き換えています。0.2 ではテキストエンコーダーにも同じ問題が残っていたのを見つけました （RoPE の「半分を入れ替えて符号を反転」を NPU のコンパイラーが誤って計算し、1 層目で 59% ずれていた）。 ±1 の行列との積に置き換えて、fp32 の元モデルとの差は 8.2% → 1.3% になりました
- トークンの埋め込み表は INT8：15 万語 × 2560 次元の表を行ごとの尺度付き INT8 で持ち、778 MB → 389 MB（誤差 1.6%）
生成例（Lunar Lake、768×768）
右 2 枚のプロンプトは「アニメ調の夕暮れの港町、猫耳の少女、看板に『NPU』の文字」です。
ライセンス
- アプリ（このリポジトリ）：Apache License 2.0
- モデル：FP8 版・INT8 版。 元は Tongyi-MAI/Z-Image-Turbo（Apache License 2.0）を NPU 向けに変換したものです
更新履歴
0.3（2026-10-25）：Panther Lake で 1 枚約 77 秒 → 約 48 秒（1 ステップ 8.1 → 5.0 秒）。RMSNorm を NPU の専用処理に、 アテンションを FlashAttention-2 に、層の間のコピーをなくし次の層の準備を NPU の実行中に。モデルはそのまま （0.2 のコンパイル結果は自動で消え、初回だけ新しい形でコンパイルし直します）。Lunar Lake は 0.2 と同じです
0.2（2026-10-25）：お詫び：0.1 はコンパイル結果に重みを層ごと・畳み込みごと・プロンプトの長さごとに丸ごと抱え込み、 元のモデル（約 10 GB）より大きい約 36 GB をディスクに置いていました。申し訳ありません。0.2 で直しました。 ディスクの使用量を大幅に削減。Panther Lake のインストール全体で約 47 GB → 約 11 GB（コンパイル結果が約 36 GB → 約 10 MB）、 Lunar Lake は約 25 GB → 約 11 GB。初回のコンパイルは Panther Lake で約 40 分 → 約 8 分。全層共通のグラフ、重みを持たないコンパイル結果（自前の NPU キット）、 圧縮保存、VAE のタイル復号。テキストエンコーダーが NPU 上で 8% ずれていた不具合を修正（1.3〜1.5% に。プロンプトに忠実になり、 看板の文字なども崩れにくくなりました）。トークンの埋め込み表を INT8 に（778 → 389 MB）。 Lunar Lake の 1 枚は約 70 → 約 80 秒（重みを持たないコンパイル結果を読み込むたびに重みを当てはめるため）。右側の履歴が詰まって表示され スクロールできなかった不具合を修正
0.1（2026-10-09）：Windows・Panther Lake 版（FP8、1024×1024 が既定、1 枚約 76 秒）を追加。連続生成（最長 30 日）を追加。 NPU の turbo を使うように。Lunar Lake では空きメモリに応じて DiT のグラフを常駐させ、1 ステップ 6.5 秒 → 5.7 秒、 生成中の SSD 読み込みと CPU 使用がほぼなくなりました
0.1a（2026-10-08）：最初の公開版。Ubuntu の Lunar Lake 向け INT8 モデル、768×768 が既定