2026年10月18日
要点
- Bonsai Image 4B(FLUX.2 Klein 4Bを3値化した軽量モデル)は、本来画像生成と画像編集だけの機能です。画像を読む(VLM)機能は、ありません。
- 内蔵のテキストエンコーダが Qwen3-4B なので、Qwen3-VL-4B の視覚エンコーダを、そのまま取り付けると、追加の学習なしで画像の判定に使えました。
- 環境は、RTX 5060(VRAM 8GB)とWindowsです。モデルの入れ替えは、していません。
- 手元の判定用画像33枚(人が映っているか)で32/33(97%)、1回約0.3〜0.5秒でした。生成は512×512で約3〜7秒、編集は約5〜10秒です。
- 得意なのは Yes/No の判定です。自由な文章での説明は弱いです。
なぜ作ったか
画像の生成、編集、判定を、それぞれ別のモデルで動かすと、8GBのGPUでは、モデルの入れ替えに時間がかかり、VRAMも足りません。Bonsai Imageは、テキストエンコーダとして、Qwen3-4B(4bit)を内蔵しています。このモデルは、生成のためだけでなく、文章を読む言語モデルとしても使えるはずです。そこに、画像を読む入り口を足せば、画像を読むモデルとしても使える、と考えました。
構成
| 部品 | 中身 | 大きさ |
|---|---|---|
| 画像を作る本体(変換器) | FLUX.2 Klein 4Bの3値化版(gemlite) | 約1.5GB |
| テキストエンコーダ | Qwen3-4B(HQQ 4bit) | 約2.7GiB(埋め込み表0.72GiBを含む) |
| VAE | 画像と潜在表現の変換 | 約0.16GB |
| 画像を読む入り口(追加) | Qwen3-VL-4Bの視覚エンコーダ+merger | 0.77GiB(int8化で約0.42GiB) |
画像を読む入り口を、学習なしで付ける
Bonsai ImageのQwen3-4Bは、言語の部分(Qwen3-4B)です。画像を読む部分を持っていません。Qwen3-VL-4Bは、同じQwen3-4Bを土台にしているので、視覚エンコーダとmergerの出力を、そのまま、言語モデルの入力に差し込むと、画像が「読める」ことを期待しました。
- 視覚エンコーダが出す画像のトークンを、文章のトークンの間に差し込みます(
<|vision_start|>と<|vision_end|>で挟みます)。 - 追加の学習は、していません。DeepStack(途中の層への注入)は、使わない方が、精度が良かったです。
- 答えは、YesとNoの確率の差(ロジット)を比べる方法で、取り出します。
手元の判定用画像33枚(人が映っているか)で、32/33(97%)でした。1回あたり約0.3〜0.5秒です。
質問の言い方で、精度が大きく変わる
同じ48枚の人の画像に、質問の英語の言い方だけを変えたときの、正答です。
| 質問 | 「人がいる」と答えた数 |
|---|---|
| Is there a person in this image? | 28/48(58%) |
| Is a human visible in this photo? | 48/48(100%) |
人のいない画像13枚に対して、後者が「いる」と誤った数は1枚でした。質問文は、必ず、手元の正解つきの画像で測ってから、使うことをお勧めします。
さらに、Yes/Noの**確信の強さ(ロジットの差)**を使って、しきい値を決めると、2値の答えだけを使うより、誤りが大きく減りました。
画像編集
編集は、FLUX.2 Kleinの方式(参照画像を、生成する側のトークンの後ろに連結する)で作りました。公式のCUDA版は、編集の機能が外されているので、Apple版などを手本に、移植しました。
- 参照画像を、VAEで潜在表現にします。
- 4×4のパッチにして、BN(正規化)をかけます。
- 時間の座標を、10、20、…と、生成側(0)と区別して付けます。
- 生成側のトークンの後ろに連結して、変換器に通します。出力は、生成側の分だけ使います。
「赤いリンゴ」を、「緑のリンゴにして」と編集すると、構図、机、窓、背景を、そのまま残して、リンゴだけが変わりました(上の画像)。
日本語のプロンプト
このモデルは、日本語の理解が弱いので、日本語が入っているときだけ、別のLLMで英訳してから、生成する前処理を入れました。固有の物の誤訳(例: 「錨」が「propeller」になる)は、「各名詞を逐語訳せよ」という指示を足して、直りました。
つまずいたところ
1. RAMが尽きて、PCが落ちた
公式の読み込み方は、変換器全体を、まず、CPUのメモリ(RAM)に、bf16で、約7.75GB作ります。16GBのPCで、他の処理が動いている状態で、これを実行すると、RAMが尽きて、PC全体が停止しました。
→ 空の枠(meta)で組み立てて、重みを、1つずつ、直接GPUへ載せる方式に変えました。埋め込み表(0.72GiB)は、SSD上のメモリマップに置きました。
2. VRAMが、ほぼ満杯
3役を同時に載せると、VRAMの空きは、約0.2GBでした。視覚エンコーダを、int8化して、0.78GiBから0.42GiBに減らしました(出力の類似度は、平均0.998)。
→ それでも余裕は、ほとんどありません。常時、3役を同時に動かすなら、他の処理のVRAMを減らすか、より大きなGPUが要ります。
3. 自由な文章の説明は、弱い
Yes/Noの判定は、安定して動きますが、「この画像を説明して」のような自由な文章は、画像を、文字のように扱ってしまい、質が低いです。必要なら、入り口の部分(projector)の学習が要ります。
まとめ
- 画像生成・編集専用のモデルでも、視覚エンコーダを足すだけで、画像の判定(Yes/No)に使えました。8GBのGPU1枚で、生成・編集と同じモデルで動きます。
- 画像の判定は、質問の言い方と、**確信の強さ(ロジット)**を使うことが、精度のカギでした。
- 余裕がほとんどないので、RAMとVRAMの安全策(空きが足りないときは、重い部分を載せない)を、必ず入れてください。
補足
- 数字(33枚、48枚の評価)は、手元の小さな評価の結果で、一般的な性能ではありません。
- 画像の最大サイズは、VRAMの都合で、512×512に制限しています。
Created using Bonsai Image by Prism ML.