Bonsai Image 4B - ローカルデバイス向け1ビット/3値画像生成モデル
(prismml.com)- ノートPCやスマートフォンのようなローカルハードウェアで高品質な拡散推論を実行するよう設計された小型画像生成モデル群
- FLUX.2 Klein 4Bのアーキテクチャを維持しつつ、拡散トランスフォーマーの重みを 1-bit または ternary 表現に変更
- 拡散トランスフォーマーのサイズは元の7.75GBから、1-bitでは0.93GB、ternaryでは1.21GBに縮小され、メモリ予算の負担を軽減
- iPhone 17 Pro Maxで512×512画像を 9.4秒 で生成し、Mac M4 Proでは約6秒、MFLUX比で最大5.6倍の速度を示す
- ternaryはFLUX.2 Klein 4B比で 95%の性能 を維持し、2つのバリアントはApache 2.0のオープンウェイトとコードとして公開予定
ローカル画像生成のための Bonsai Image 4B
- Bonsai Image 4B は、ノートPCからスマートフォンまでのローカルハードウェアで高品質な拡散推論を実行するよう設計された小型画像生成モデル群
- FLUX.2 Klein 4Bをベースとしており、アーキテクチャは維持したまま 拡散トランスフォーマー重み を1-bitまたはternary形式に変更
- 1-bit Bonsai Image 4B は、二値
{−1, +1}のトランスフォーマー重みとFP16のグループ単位スケーリング係数を使用し、重みあたり1.125有効ビットを提供 - Ternary Bonsai Image 4B は、
{−1, 0, +1}のトランスフォーマー重みとFP16のグループ単位スケーリング係数を使用し、重みあたり1.71有効ビットを提供
- 1-bit Bonsai Image 4B は、二値
- ternaryバリアントは1-bitより大きいが、追加された 0の状態 によって視覚品質とプロンプト忠実度を向上
- Bonsai Image 4Bは、オープンウェイトとローカル推論を通じて、これまでこのクラスのモデルを動かしにくかったデバイスでも画像生成を可能にする配布形態を目指す
- PrismMLによれば、Bonsai Image 4Bはこのパラメータ級の画像モデルとして iPhone上で直接動作する最初のモデル
ローカル実行のためのメモリ削減
- ローカル画像生成の中核的な制約は、モデルが デバイスのメモリ予算 内に収まらなければならない点
- 4B級の画像モデルでは、拡散トランスフォーマーがモデル中で最も大きな部分であり、生成中は各デノイジング段階ごとに繰り返し実行される
- トランスフォーマーのサイズは、メモリ圧迫、帯域幅要件、ローカル推論速度に直接影響する
- FLUX.2 Klein 4Bの拡散トランスフォーマーは7.75GBで、1-bit Bonsai Image 4Bは0.93GB、Ternary Bonsai Image 4Bは1.21GB
- 1-bitバリアントはフル精度のFLUX.2 Klein 4B比で 8.3倍、ternaryバリアントは 6.4倍 小さい
- 二値レイヤー自体はフル精度トランスフォーマー重みと比べて約14倍縮小されるが、精度に敏感な約5%の projection layer はFP16のまま維持される
- ternaryレイヤーは約10倍の削減を実現し、最終的なトランスフォーマーサイズは1.21GBとなる
配布ペイロードとランタイムメモリ
- 圧縮済みテキストエンコーダーとFP16 VAEを含むApple Silicon向け配布ペイロードは、1-bitが3.42GB、ternaryが3.88GB
- フル精度のFLUX.2 Klein 4Bの配布ペイロードは 15.97GB
- ランタイムでは、プロンプトエンコード後にテキストエンコーダーがオフロードされるため、平均メモリ使用量はペイロード全体より小さくなる
- 512×512画像生成時の平均アクティブメモリは、1-bitが 1.5GB、ternaryが 1.96GB、元のFLUX.2 Klein 4Bが 11.74GB
- 512×512基準でのメモリ削減率は、1-bitが7.8倍、ternaryが6.0倍
- 1024×1024画像生成時の平均アクティブメモリは、1-bitが 1.95GB、ternaryが 2.38GB、元のFLUX.2 Klein 4Bが 14.39GB
- 1024×1024基準でのメモリ削減率は、1-bitが7.4倍、ternaryが6.0倍
対応ハードウェアと実行性能
- 配布スタックは Apple Silicon iPhone、iPad、Mac とCUDA GPUをサポート
- Appleハードウェアでは MLX low-bit経路 を使用し、CUDAでは Gemlite low-bit GEMMカーネル を使用
- iPhone 17 Pro Maxではフル精度のFLUX.2 Klein 4Bパイプラインはデバイスのメモリ予算内に収まらないが、Bonsai Imageの2つのバリアントはオンデバイスで実行される
- Bonsai Image 4BはiPhone 17 Pro Maxで512×512画像を 9.4秒 で生成
- Mac M4 Proでは512×512画像を約 6秒 で生成
- Mac M4 ProでBonsai Image 4Bは標準のフル精度 MFLUXパイプライン より最大5.6倍高速
ベンチマーク性能
- Bonsai Image 4Bは GenEval、HPSv3、DPG-Bench の3つのベンチマークで評価
- GenEvalはオブジェクト構成と属性バインディングを評価し、HPSv3は人間の嗜好と美的品質を評価し、DPG-Benchは高密度なプロンプト追従と意味忠実度を評価する
- Ternary Bonsai Image 4Bは1.21GBの拡散トランスフォーマーでGenEval 0.723、HPSv3 12.22、DPG-Bench 0.851を記録
- Ternary Bonsai Image 4BはFLUX.2 Klein 4B比で 95%の性能 を維持しつつ、拡散トランスフォーマーサイズを6.4倍削減
- 1-bit Bonsai Image 4Bは0.93GBの拡散トランスフォーマーでGenEval 0.671、HPSv3 11.15、DPG-Bench 0.822を記録
- 1-bit Bonsai Image 4BはFLUX.2 Klein 4B比で 88%の性能 を維持しつつ、拡散トランスフォーマーを1GB未満に削減
- FLUX.2 Klein 4Bは7.75GBの拡散トランスフォーマーでGenEval 0.819、HPSv3 12.84、DPG-Bench 0.853を記録
- SDXLは5.14GBの拡散トランスフォーマーでGenEval 0.3、HPSv3 10.05、DPG-Bench 0.74を記録し、FLUX.2 Klein 4B比で67%の性能を示す
- BK-SDM-Smallは0.98GBの拡散トランスフォーマーでGenEval 0.297、HPSv3 3.05、DPG-Bench 0.559を記録し、FLUX.2 Klein 4B比で42%の性能を示す
- Stable Diffusion 1.5は1.72GBの拡散トランスフォーマーでGenEval 0.396、HPSv3 4.2、DPG-Bench 0.601を記録し、FLUX.2 Klein 4B比で51%の性能を示す
- PixArt-Σ XL 2は1.2GBの拡散トランスフォーマーでGenEval 0.541、HPSv3 11.93、DPG-Bench 0.769を記録し、FLUX.2 Klein 4B比で83%の性能を示す
- 2つのBonsaiバリアントは、現代的な4B級画像モデルと競争しつつ、拡散トランスフォーマーのフットプリントをはるかに小さく維持している
- 近いメモリフットプリントを持つより小さなモデルより高い性能を示し、従来はより小型で低性能なモデルが占めていたメモリ帯域に、現代的な 拡散トランスフォーマー動作 を持ち込む
ローカル推論のプロダクト上の意味
- 画像生成はモデル品質だけでなく、配布方式 にも左右される
- クラウドAPIは多くの製品で引き続き適しているが、クラウド専用生成ではすべてのプロンプトがリモートリクエストとなり、あらゆる反復に配信コストと往復遅延が加わる
- 画像生成は本質的に反復的であり、ユーザーはプロンプトを修正し、結果を比較し、バリエーションを作り、失敗した結果を捨てて再試行する
- 各試行がサーバー側処理になると、創作ループのたびにユーザーはコストを意識し、待たなければならない
- ローカル推論により、モデルがデバイスに入った後、生成機能を製品体験の中に直接組み込めるようになる
- ローカル実行は実行コストを下げ、反復速度を高め、プロンプトや生成アセットを非公開に保つ必要がある環境で使いやすい
- Bonsai Image 4Bは、ユーザーがすでに持っているハードウェア上で、ユーザーにより近い場所へ移っていく 画像生成の配布方式 に向けた一歩
公開形態とリソース
- 1-bit Bonsai Image 4BとTernary Bonsai Image 4Bは オープンウェイト とコードとして公開予定
- ライセンスは Apache 2.0
- PrismMLは、iPhone上でBonsai Image 4Bを直接試せるiOSアプリ Bonsai Studio もあわせて公開
- Whitepaper
- Hugging Face
- WebGPU demo
- Bonsai Studio for iPhone
- GitHub
1件のコメント
Hacker Newsのコメント
20年前には、私たちが見たり読んだりするものが本物かどうかを信頼できない未来のインターネットを予想した人は、あまりいなかったと思う。
いつかこの時代を、Mad Menでドレイパー一家がピクニックのゴミを芝生に投げ捨てて立ち去る場面のような、逸脱した時代として振り返れるといいと思う
時間がたつにつれて良くなることも多いし、人は新しい技術が最初に出てきたとき、その社会的リスクをいつも過大評価しがちだ
この会社は大学発のスピンアウトで、統計データだけからもっともらしい野球記事、その後は金融記事まで書けていた。地域ニュースサイトがあらゆる試合の記事を掲載できるようになり、スポーツファンにとって有益で、Webトラフィックを増やす主要な原動力と見なされていたが、「本物」ではないという批判も多かった。
Slateが2012年にこれについて書いた記事: https://slate.com/technology/2012/03/narrative-science-robot...
コンピューターが登場して以来、人々はコンピューターを人間のように聞こえさせようとしてきたし、私が会話したり読んだりしている相手が人間をまねたロボットではないかと心配するのも新しい話ではない
確かにより簡単にはなっているが、質的にまったく別物というほどの変化ではない。20年前のインターネットで見たものをそのまま信じるのも、今と同じくらい滑稽だったはずだ
高価なサブスクの代わりにハードウェアをアップグレードして、自分のAIをアップグレードする未来が本当に楽しみだ。
やりたい課題の中には数十億トークンが必要なものが多いが、今は企業プロジェクトの支援がなければ事実上手が届かない。Opus 4.6級の品質で毎秒数万トークンを出せるASIC生成マシンがあれば十分だ
現時点ではLLama 8Bモデルを使っていて、毎秒およそ17kトークンで動作し、https://chatjimmy.ai/で試せる
時間あたりの稼働率が高いからだ。私もいつも同じ想像をするが、論理的には幻想だと思う。平均してハードウェアをより有効活用する集団全体より多く使えるわけがない。
個人向けハードウェアも良くはなるだろうが、最先端は常にクラウドにあるはずだ
「1-bit」を見て最初に思い浮かべたのは、1ビットのモデル重みではなく、1ビットディザの白黒画像生成だった。
だから、学習画像と作業空間をFloyd-SteinbergやAtkinson、あるいは好みのアルゴリズムでディザ処理した1ビット画像に限定したら、拡散画像生成器がどれほど面白く、高速で、圧縮しやすくなるのか気になった。
学習はかなり速いだろうし、たぶん最新GPU1枚にも収まるはずだ
純粋に気になるのだが、これは実際の問題を解決しているのか？
拡散モデルを使うときのボトルネックはストレージやメモリではなく生成時間だと思う。多くのモデルは1080世代以降の8〜12GB GPUや、同程度のメモリを持つMacで動くし、いずれにせよGPU性能の観点ではそのあたりが下限に近い。しかも、このモデル群はベースになった小型のFLUX.2モデルより少し遅いように見える。
もちろん、iPhoneのように比較的強いGPUはあるがメモリが限られたデバイスでローカルモデルを動かせるようにはなるだろうが、それは本当に一般的な要件なのだろうか？
これまで見た画像生成製品はどれも従量課金なので、価値がかなり制限されている。ただ、これが本当に「そこそこ良い品質」の域に達しているのかは分からない
効率が良くなるたびに、既存の資源でできることが増える。画像を半分の計算量でレンダリングできるなら、必要なGPUも半分で済む
最前線のモデルですら、まだ辛うじて使える程度で、画像生成では最高のモデルでさえ大半はひどい結果が多い。だから、能力面で最前線よりはるかに劣るしかない小型の1ビットモデルは、今すぐ使えるものではないと思う。
ただし、演算単位あたりの能力密度を大きく高めることには大きな意味がある。最前線モデルをより良く、より安く運用でき、資源消費も減らせるし、個人のノートPCやスマートフォンのようなエッジで実行可能な作業の幅も広がる。
プライバシーの観点でも、デバイス内で動かすべき仕事は多いし、誰もが大きな専用GPUを持っているわけではない
Anthropicのような企業は今でも推論で巨額の損失を出しており、効率が良くて性能の高いモデルの進歩は収益性の改善に役立つ
「我々の知る限り、Bonsai Image 4Bは、そのパラメータ規模でiPhone上で直接動作する初の画像モデルだ」という文は誤っている。ただ、完全に間違いにならないよう慎重に表現している。
FLUX.2 [klein] 4B、つまり同じパラメータ規模で実質的に同じモデルが、Draw Thingsアプリ経由でiPhone上で動く。8ビットまたは6ビット量子化を使っているので「直接」ではないと言えなくもないが、その技術的なただし書きはかなり怪しく聞こえる
拡散モデルと呼んでいるが、ベースのFlux.2はフローマッチングモデルだ
変だな。イギリスからアクセスしているのに、こう表示される:
Website Not Allowed
“prismml.com” is a restricted website.
24時間以内に誰かがこの1ビットモデル向けのLoRAを学習させて、Apple Watchでヘンタイコンテンツを生成できるようにするだろう
ローカルファイルシステムをいじらずに動かしたいなら、https://github.com/kordless/bonsai-dockerを使えばいい
Webデモからコードを取り出して、ブラウザ内AIワークフローツールのWeb画像生成ノードとしてつなげてみたが、かなり良い感じだ。
xenovaがtransformersjs 4.3に追加してくれるのを待っていて、そうなったら私も公開するつもりだ。テストが待ちきれなくて先に試してみた