ローカルデバイス向け1ビット Bonsai Image 4B 画像生成

 (prismml.com)
1 ポイント 投稿者 GN⁺ 3 시간 전 | 1件のコメント | WhatsAppで共有
  • Bonsai Image 4Bは、ノート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% の性能を維持し、両バリアントは 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 の実効ビット数を提供
  • 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件のコメント

 
GN⁺ 3 시간 전
Hacker Newsのコメント

  • 20年前には、私たちが見たり読んだりするものが本物かどうかを信頼できない未来のインターネットを予想した人は、あまりいなかったと思う。
    いつかこの時代を、Mad Menでドレイパー一家がピクニックのゴミを芝生に投げ捨てて立ち去る場面のような、逸脱した時代として振り返れるといいと思う

    • 20年前、先生たちはインターネットでは何も信じられないからWikipediaを使うなと言っていたし、アプリやWebサイトで会った相手とは絶対にデートするなとも言っていた。そういう相手は100%殺人犯だと言われていたし、「インターネットはポルノのためのもの」という言い方もあった。
      時間がたつにつれて良くなることも多いし、人は新しい技術が最初に出てきたとき、その社会的リスクをいつも過大評価しがちだ
    • そのピクニックの場面: https://www.youtube.com/watch?v=FDIvzDGBLWU
    • 当時のNarrative Science(https://en.wikipedia.org/wiki/Narrative_Science)をめぐる議論を覚えていないようだ。
      この会社は大学発のスピンアウトで、統計データだけからもっともらしい野球記事、その後は金融記事まで書けていた。地域ニュースサイトがあらゆる試合の記事を掲載できるようになり、スポーツファンにとって有益で、Webトラフィックを増やす主要な原動力と見なされていたが、「本物」ではないという批判も多かった。
      Slateが2012年にこれについて書いた記事: https://slate.com/technology/2012/03/narrative-science-robot...
      コンピューターが登場して以来、人々はコンピューターを人間のように聞こえさせようとしてきたし、私が会話したり読んだりしている相手が人間をまねたロボットではないかと心配するのも新しい話ではない
    • 「逸脱した時代」と呼ぶには大げさな反応に見える
    • テキストにも画像にも常に偽情報はあったし、写真は写真術が生まれたときから加工可能だった。
      確かにより簡単にはなっているが、質的にまったく別物というほどの変化ではない。20年前のインターネットで見たものをそのまま信じるのも、今と同じくらい滑稽だったはずだ

  • 高価なサブスクの代わりにハードウェアをアップグレードして、自分のAIをアップグレードする未来が本当に楽しみだ。
    やりたい課題の中には数十億トークンが必要なものが多いが、今は企業プロジェクトの支援がなければ事実上手が届かない。Opus 4.6級の品質で毎秒数万トークンを出せるASIC生成マシンがあれば十分だ

    • Taalasという会社が似たようなものを作っている。Opus 4.6品質ではないが、より大きなモデルを目指しているはずだ。
      現時点ではLLama 8Bモデルを使っていて、毎秒およそ17kトークンで動作し、https://chatjimmy.ai/で試せる
    • そういう課題の例を一つ挙げてもらえる？
    • ハードウェアと電力のコストがサブスク費用と比べてどの程度になるのか気になる
    • 論理的に見れば、5人が資源を持ち寄るほうが1人より強いので、データセンターが常に勝つ。
      時間あたりの稼働率が高いからだ。私もいつも同じ想像をするが、論理的には幻想だと思う。平均してハードウェアをより有効活用する集団全体より多く使えるわけがない。
      個人向けハードウェアも良くはなるだろうが、最先端は常にクラウドにあるはずだ

  • 「1-bit」を見て最初に思い浮かべたのは、1ビットのモデル重みではなく、1ビットディザの白黒画像生成だった。
    だから、学習画像と作業空間をFloyd-SteinbergやAtkinson、あるいは好みのアルゴリズムでディザ処理した1ビット画像に限定したら、拡散画像生成器がどれほど面白く、高速で、圧縮しやすくなるのか気になった。
    学習はかなり速いだろうし、たぶん最新GPU1枚にも収まるはずだ

    • それでも、グレースケールで学習して後でディザリングするほうが良さそうだ
    • 私もまったく同じことを考えたし、ここには掘り下げる価値のある面白いアイデアがかなりありそうだ

  • 純粋に気になるのだが、これは実際の問題を解決しているのか？
    拡散モデルを使うときのボトルネックはストレージやメモリではなく生成時間だと思う。多くのモデルは1080世代以降の8〜12GB GPUや、同程度のメモリを持つMacで動くし、いずれにせよGPU性能の観点ではそのあたりが下限に近い。しかも、このモデル群はベースになった小型のFLUX.2モデルより少し遅いように見える。
    もちろん、iPhoneのように比較的強いGPUはあるがメモリが限られたデバイスでローカルモデルを動かせるようにはなるだろうが、それは本当に一般的な要件なのだろうか？

    • 有用な前進ではある。ローカル規模の推論でそこそこ良い品質が出るなら、コストを気にせず気軽に捨てられる画像を生成する製品が作れる。
      これまで見た画像生成製品はどれも従量課金なので、価値がかなり制限されている。ただ、これが本当に「そこそこ良い品質」の域に達しているのかは分からない
    • 今はGPU需要が極端に高く、供給が限られている時代だ。推論をエッジに押し出すたび、クラウド資源は別の仕事に回せる。
      効率が良くなるたびに、既存の資源でできることが増える。画像を半分の計算量でレンダリングできるなら、必要なGPUも半分で済む
    • 8〜12GBの1080世代GPUや同程度のメモリを持つMacは下限ではない。大半の人はそれよりGPU性能がずっと低いノートPCやモバイル機器を使っている
    • 現時点での価値は実用性というより学術的価値に近いように見える。
      最前線のモデルですら、まだ辛うじて使える程度で、画像生成では最高のモデルでさえ大半はひどい結果が多い。だから、能力面で最前線よりはるかに劣るしかない小型の1ビットモデルは、今すぐ使えるものではないと思う。
      ただし、演算単位あたりの能力密度を大きく高めることには大きな意味がある。最前線モデルをより良く、より安く運用でき、資源消費も減らせるし、個人のノートPCやスマートフォンのようなエッジで実行可能な作業の幅も広がる。
      プライバシーの観点でも、デバイス内で動かすべき仕事は多いし、誰もが大きな専用GPUを持っているわけではない
    • その通り。サイズと性能はローカルLLMだけの問題ではなく、OpenAIやAnthropicのような最前線のLLM企業にとっても問題だ。
      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に追加してくれるのを待っていて、そうなったら私も公開するつもりだ。テストが待ちきれなくて先に試してみた

    • その「ブラウザ内AIワークフローツール」について説明してもらえる？ 似たものを作っているかもしれないので、この分野で他の人が何を作っているのかとても気になる