動画で読む
結論: 4B の画像生成モデルが 1-bit 量子化で iPhone に載った
結論から書きます。PrismML が 2026 年 5 月 26 日に公開した Bonsai Image 4B は、40 億パラメータの画像生成モデルを 1-bit まで圧縮し、iPhone 17 Pro Max で 512×512 の画像を 9.4 秒で生成します。元の FLUX.2 Klein 4B が transformer だけで 7.75 GB だったものを、1-bit 版は 0.93 GB（8.3 分の 1）まで縮めました。手元のスマホで画像生成モデルが回る、という話が現実の数字として出てきたわけです。
きっかけは PrismML の Bonsai Image 4B の発表でした。重みを極端に削れば品質も削れる、という直感は正しいのですが、その「削れ方」が思ったより緩やかだったのです。私は普段 LLM の API を本番で回している側なので、これは抽象論ではなく推論コストの話として読みました。
Bonsai Image 4B とは — FLUX.2 Klein 4B を 1-bit / ternary 化したもの
Bonsai Image 4B は、画像生成モデル FLUX.2 Klein 4B をベースに、重みを 1-bit（{−1, +1} の 2 値）または ternary（三値、{−1, 0, +1}）へ量子化したモデルです。ライセンスは Apache 2.0 の open weights で、iPhone / iPad / Mac（Apple Silicon）と CUDA GPU で動きます。
量子化（quantization、重みをより低い精度の数値で表す圧縮手法）は LLM では BitNet などで先行していましたが、画像生成の拡散モデルに 1-bit を効かせた事例はまだ珍しい。スケーリング係数だけ FP16（16 bit 浮動小数点）でグループごとに持つので、実効ビット数は 1-bit 版で 1.125 bit、ternary 版で 1.71 bit になります。「1 bit」と言いつつ完全な 1 bit ではない。この 0.125 の上乗せが品質を支えている部分です。
数字を読む — メモリ・速度・品質のトレードオフ
トレードオフは「メモリと速度は劇的に得、品質は緩やかに損」とまとめられます。発表ページの数字を並べます。
| 指標 | 1-bit | ternary | 元 (FLUX.2 Klein 4B) |
|---|---|---|---|
| transformer サイズ | 0.93 GB | 1.21 GB | 7.75 GB |
| 配布パッケージ (Apple Silicon) | 3.42 GB | 3.88 GB | 15.97 GB |
| 512×512 の実効メモリ | 1.5 GB | 1.96 GB | — |
| 品質維持率 | 88% | 95% | 100% |
速度は Mac M4 Pro で約 6 秒、stock の FLUX より 5.6 倍速いとされています。品質は GenEval / HPSv3 / DPG-Bench で評価され、ternary が元の 95%、1-bit が 88% を維持。私の感覚では、5% 落ちで 6.4 分の 1 になる ternary が実務の落とし所で、最後の数 % をどうしても削れない用途だけ元モデルを GPU で回す、という二段構えになります。
なぜ品質が 88% も残るのか — group-wise scaling の効き方
重みを 2 値や 3 値まで潰しても品質が大きく崩れないのは、グループ単位の FP16 スケーリング係数が「振れ幅」を保存しているからです。重みの符号（±）だけを 1-bit で持ち、その大きさはグループ共通の係数で後から復元する仕組みです。
この発想は LLM 側の BitNet b1.58（重みを三値にする 1-bit LLM の研究）と同じ系譜にあります。面白いのは、ternary（1.58 bit 相当）が 1-bit より品質を保つ傾向が、画像生成でも再現した点です。0 を表現できる三値は「その重みを使わない」という選択肢を持てるので、疎な構造を素直に表せます。LLM で見た現象が拡散モデルでも出る、というのは量子化の一般性を示していて、地味に重要だと思いました。
運用者として何が変わるか — 推論コストの置き場所が動く
運用者目線での一番の変化は、推論コストの置き場所がサーバからデバイスへ動きうることです。これまで画像生成は GPU サーバの時間課金が前提でした。端末で 6〜9 秒で回るなら、その課金の一部は消えます。
私は LLM の推論を 標準 GPU で 3000 tokens/s/req という数字を運用者目線で読んだときにも同じことを考えました。総パラメータとアクティブパラメータを分けて読む話は Liquid の LFM2.5 8B-A1B の記事でも書きましたが、量子化はそれとは別の軸で「載る／載らない」を決めます。8.3 分の 1 になると、これまで「サーバ必須」だった機能が「端末で十分」に変わります。副次的な効果として、画像が端末から外に出ないのでプライバシー面の説明も楽になりますし、オフラインでも動く。サーバ課金とネットワーク前提が同時に外せるのは、運用の設計図をかなり身軽にします。
正直に書くと、私は最初この 9.4 秒という数字を疑いました。手元の MacBook Air M2 で stock の拡散モデルを回すと平気で 1 分はかかるからです。試しに小さい量子化モデルをいくつか触ってみて、メモリに載りさえすれば速い、という当たり前を体で理解しました。律速はだいたいメモリ帯域で、重みが軽いほど読み出しが速い。私のマシンはずっと「重いから遅い」のではなく「載らないから遅い」だったわけです。
なお、このサイトの記事は AI が下書きを書き、私が公開前に確認・編集して出しています。今回の数字も発表ページと照らし合わせながら直しました。
まとめ
1-bit / ternary 量子化は、画像生成モデルの「動く場所」を書き換えます。運用者として持ち帰る点を並べます。
- Bonsai Image 4B は FLUX.2 Klein 4B を 1-bit (1.125 bit) / ternary (1.71 bit) に量子化した Apache 2.0 の open weights
- メモリは 8.3 分の 1（1-bit, 0.93 GB）、品質は 88〜95% を維持。実務の落とし所は ternary
- iPhone 17 Pro Max で 512×512 を 9.4 秒、Mac M4 Pro で約 6 秒
- 律速はメモリ帯域。「重いから遅い」ではなく「載らないから遅い」を疑う
- 推論コストの一部がサーバから端末へ動きうる。サーバ前提の設計を見直す契機になる
重みを削るのではなく、符号だけ残して大きさは後から戻す。量子化が見せるのは、情報をどこまで捨ててよいかの線引きだ。
よくある質問
- Bonsai Image 4B はどのデバイスで動きますか？
- iPhone / iPad / Mac の Apple Silicon と CUDA GPU で動きます。iPhone 17 Pro Max で 512×512 を 9.4 秒、Mac M4 Pro で約 6 秒で生成でき、ライセンスは Apache 2.0 の open weights です。
- 1-bit と ternary はどちらを使えばよいですか？
- 品質を優先するなら ternary（三値）です。元モデルの 95% を維持しつつメモリは 6.4 分の 1 です。最小サイズ重視なら 1-bit で、88% 維持・8.3 分の 1 になります。実務では ternary が落とし所になりやすいです。
- なぜ 1-bit まで削っても品質が残るのですか？
- 重みの符号だけを 1-bit で持ち、大きさはグループ共通の FP16 スケーリング係数で後から復元するためです。実効ビット数は 1-bit 版でも 1.125 bit あり、この上乗せが品質を支えています。
- 量子化は推論コストにどう影響しますか？
- メモリ使用量が 8.3 分の 1 になると、これまで GPU サーバが必須だった処理が端末で完結しうるため、サーバの時間課金の一部が不要になります。律速はメモリ帯域なので、軽い重みほど速く動きます。