FLUX 級の 4B 画像モデルを 1.21 GB に圧縮 — しかもブラウザで動く

編集メモ. 以下の速度・サイズの数値はすべて PrismML の公式値（M4 Pro / 48 GB）で、Hugging Face のモデルカードと照合済みですが、私たち自身の Apple Silicon で再計測したものではありません。私たちのベンチマークではなく、検証済みのベンダー主張として読んでください。

1-bit テキスト→画像は、もう論文ではなくなった

ternary や 1-bit のニューラルネットは新しくない。BitNet b1.58（arXiv 2402.17764）が 2024 年初頭に {−1, 0, +1} の重みを本格的なアイデアに押し上げ、1-bit diffusion も同年に BinaryDM（2404.05662）として登場した。だから見出しは 「初の 1-bit diffusion モデル」ではない。それは違う。

本当に新しいのは製品化だ。現代的な FLUX 級 4B のテキスト→画像モデルを ternary/binary 重みで出荷し、MLX・CUDA（gemlite）・WebGPU、そして iPhone 向けのランタイムパックまで揃え、すべて Apache-2.0 にした。それが PrismML の Bonsai Image（Hugging Face の prism-ml）であり、今すぐ叩けるゼロインストールのブラウザデモまである。

実際のところ何なのか

Bonsai Image は FLUX.2 Klein 4B（MMDiT diffusion transformer）そのもので、アーキテクチャはそのまま、重みの表現だけを ternary {−1, 0, +1} または binary {−1, +1} に変えたものだ：

• ~4.0B の trunk、25 個の MMDiT ブロック、matmul の重い 100 個の linear 層をすべて量子化。
• テキストエンコーダ：Qwen3-4B を 4-bit に圧縮し、エンコード完了直後に offload。
• VAE：Flux2 の 32 チャネル latent、タイル分割デコード（128px タイル）。
• ネイティブ 1024×1024、加えて 512×512 と 32 の倍数に対応。
• ternary は FP16 の group-wise scaling（グループサイズ 128）を使い、実効で重みあたり ~1.71 bit ——きれいな 2-bit ではない。
• サンプラ：FlowMatchEuler-discrete、4 ステップ、guidance 1.0（CFG なし）、shift 3.0。

「4 ステップ・CFG なし」の部分は、ビット幅と同じくらい効いている。1 ステップあたり forward が 1 本、合計 4 ステップ —— これが下記の実時間値を成立させている大きな要因だ。

フットプリントと速度（PrismML の数値）

変種	transformer	総 payload	512²	1024²	vs FP16 MFLUX
Ternary MLX 2-bit	1.21 GB	3.88 GB	5.78s	24.26s	3.15× / 5.56×
Binary MLX 1-bit	0.93 GB	3.42 GB	6.01s	24.07s	—

1024² の ternary でのエンドツーエンドのアクティブメモリは 2.38 GB —— FP16 ベースラインのおよそ 6 分の 1 だ。binary 変種は面白い事例で、512² ではむしろわずかに遅く（6.01s vs 5.78s）、1024² ではほぼ同等（24.07s vs 24.26s）—— つまり 0.93 GB の小さい transformer が買うのはフットプリントであって速度ではない。

これはテキスト側で私たちが追ってきたサイズ↔速度のトレードオフと同じ構図だ —— MTP と llama.cpp を扱った issue 9 を参照。ここでのレバーは投機的デコードではなく量子化だが、問いは同一だ：品質が動き出す前に、どこまで縮められるか。

正直なところ：2 つの品質数値、2 通りの読み方

Bonsai Image は FP16 の親モデル（FLUX.2 Klein 4B）に対して 2 つのベンチマークを報告している。両者は別のことを語っており、ひとつの「X% 悪化」にまとめると誤解を招く：

• GenEval：0.723 vs 0.819。 これはプロンプト遵守——オブジェクト数、属性、空間関係——への実質的なダメージだ。プロンプトが構成的（「3 つの青い球の上に赤い立方体」）なら、フルモデルより取りこぼしが増えると見ておくべき。
• DPG-Bench：0.851 vs 0.853。 濃密な記述的プロンプトではほぼ同等。リッチなシーン記述では品質が保たれる。

合わせて読むと、圧縮の代償は記述の豊かさよりも、構造的・構成的プロンプトの精度に効く。1.21 GB 対 7.75 GB なら、アイデア出し・ラフ・オンデバイス生成では喜んで受け入れる人が多い取引だ —— そして最終的な構成精度がすべて、という場面では受け入れないだろう。

ゼロインストールで試す

一番速いのはブラウザだ。ライブの WebGPU デモがある：

huggingface.co/spaces/webml-community/bonsai-image-webgpu

（PrismML 自身ではなく webml-community ネームスペースでホストされている。WebGPU 対応ブラウザ——最新版の Chrome か Edge——が必要。）

自分の Mac で動かす

アクセス状態（2026-05-27 に確認済み）： 重みは公開されている —— Hugging Face API は gated: false を返す。ただし落とし穴がある：公式デモリポジトリ（PrismML-Eng/Bonsai-Image-Demo）の README は更新が遅れており、いまだに「public launch まで BONSAI_TOKEN を設定せよ」と書いてある。無視してよい。トークンなしで直接重みを取得できる：

pip install "huggingface_hub[hf_xet]"
huggingface-cli download \
  --local-dir bonsai-image-ternary-4B-mlx-2bit \
  prism-ml/bonsai-image-ternary-4B-mlx-2bit

ternary-4B-mlx-2bit リポジトリが Apple Silicon 向けの第一候補だ。フルの Bonsai Studio UI（FastAPI + Next.js）が欲しければデモリポジトリの serve.sh が公式の手順だが、README が今や不要な BONSAI_TOKEN の設定を相変わらず指示してくる点に注意。

メモリ： 16 GB 以上のユニファイドメモリが快適。8 GB の Mac でも 2.38 GB のアクティブフットプリントなら 512² はこなせるかもしれないが、これは未検証で公式の裏付けはない。（そもそも自分のマシンに余裕があるか手早く確認したい場合 —— runlocal.dev の計算機 は diffusion ではなく LLM の VRAM 計算用だが、ユニファイドメモリの上限は教えてくれる。）

iPhone でも動く

PrismML は ternary モデルを A19 Pro（iPhone 17 Pro Max）で 512² を 9.4 秒、1024² を 34.0 秒と報告している。同社のオンデバイス MLX Swift iOS ビルド経由だ。完全にオンデバイスで、クラウド往復はない。FLUX 派生のテキスト→画像スタック一式がスマホに収まって動く —— これは 1 年前なら SF として読めた部分だ。

注目ポイント

• sub-2-bit が小型 diffusion モデルの標準的なパッケージングになるのか、それとも単発で終わるのか。PrismML は 4 月にすでに ternary のテキストモデルファミリ（8B/4B/1.7B、BitNet 流の 1.58-bit）を出荷しており、今回はその系譜を diffusion に適用したもの —— つまりデモではなく意図的な戦略を示唆している。
• binary 1-bit 変種の品質。速度はすでに公開されている（しかも ternary に対して妙に横ばいだ —— 上の表を参照）が、PrismML は binary ビルドの GenEval/DPG-Bench スコアを出していない。ternary から binary への追加圧縮が画質にいくら払わせるのか、それが本当の未知数だ。
• 512² の 5.78 秒がコンシューマの Apple Silicon で成立するか、そして —— より重要なのは —— あの GenEval の差が実際のプロンプトでどう体感されるのか（ベンチマーク上だけでなく）。モデルが広まれば後の号で自前の M シリーズ計測を出すかもしれないが、今回は PrismML の検証済み数値で進める。

いちばん正直なテストは自分の目だ —— WebGPU デモを開き、自分の本物のプロンプトを 5 つ投げて、品質のトレードオフを自分で判断してほしい。