英語版で読む
技術 約8分で読めます

Boogu-Image-0.1をM1 MaxのComfyUIで試す fp8はMPSで弾かれ、bf16なら回る

AI 画像生成 ComfyUI Apple Silicon MPS 実験
いけさん目次

Boogu-Image-0.1という画像生成・編集モデルが2026年6月16日に出た。10BパラメータでApache-2.0のフルオープンで、ComfyUIのコアも6月18日にはネイティブ対応している（コミットはSupport Boogu-Image (CORE-308)）。出たてをそのまま追える状態だった。

動かしてみたいが、ひとつ引っかかる点がある。Booguを読むにはComfyUIのコアを最新まで上げる必要があって、Macで単純にComfyUIを上げるのは過去に痛い目を見ている。

公式リポジトリはCUDA前提で、Macのことは何も書いていない。とはいえ手元で動かせるのがM1 Maxしかないので、それで試す。

冒頭の画像はそのBoogu Turbo bf16で出したカフェの内装で、4ステップでラテアートも観葉植物も暖炉も破綻なく入っている。

Boogu-Image-0.1とは

開発元は「Boogu / boogu-project」。親組織の素性は明示されておらず、技術レポートも「arXiv近日公開」でまだ無い。売り文句は「学習データ量が既存OSSの約1/10で、ほぼクローズドソース級」というもので、Qwen-Image-Benchで53.58、20BのQwen-Image-2512（52.06）を10Bで上回ると主張している。

構成はQwen-Imageによく似ている。ComfyUIの実装（comfy/ldm/boogu/model.py）を覗くとBooguDoubleStreamBlockとBooguJointAttentionが並んでいて、テキストと画像を同じブロックで捌くダブルストリームのMMDiT系だと分かる。テキストエンコーダにフルのQwen3-VL-8Bを使い、VAEはFLUX.1のものを流用している。supported_models.pyではOmnigen2を継承し、flow matchingのshift=3.16をモデル設定に内蔵している。

要素中身
本体10B のダブルストリームDiT（MMDiT系）
テキストエンコーダQwen3-VL-8B（last hidden state、no-thinkテンプレート）
VAEFLUX.1 VAE 流用
バリアントBase / Edit / Turbo（各 bf16・fp8・nvfp4）
ステップBase/Edit 25〜50、Turbo 3〜4（蒸留）

Comfy-Orgの配布では、拡散本体がbf16（20.59GB）・fp8 scaled（10.31GB）・nvfp4（5.83GB）の3形式、テキストエンコーダはqwen3vl_8b_fp8_scaled（10.59GB）、VAEはflux1_vae_bf16（0.17GB）。Baseに当てる蒸留Turbo LoRA（1.35GB）もある。nvfp4はNVIDIA Blackwell前提なのでMacでは触れない。

もうひとつの売りが中英バイリンガルの文字描画で、ポスターや看板を読める文字で出せると謳っている。ここは後で実際に試す。

検証環境

項目内容
マシンMac Studio M1 Max 64GB
OSmacOS 26.5
Python3.12.12
PyTorch2.10.0（MPS）
ComfyUImaster先端 f2270f07（6月18日時点）
本体Boogu-Image-0.1-Turbo bf16（19GB）
TE / VAEQwen3-VL-8B fp8（10GB）/ FLUX.1 VAE bf16
共通条件Turbo 4step / cfg1.0 / euler / simple / 1024px

ComfyUIを上げると遅くなることがある

Booguを読むにはComfyUIのコアを上げる必要があるが、Macではこの更新が地雷になりうる。以前アップデートしたらQwen Image Editの生成が80秒から10分近くに跳ねたことがあった（原因と対策はComfyUIアプデでQwen Image Editが10分かかるようになった件に書いた）。

MacのMPSはBF16演算がFP16より遅く、M1〜M3にはBF16のハードウェア対応がない。コア更新の拍子にモデルの推論dtypeがBF16になると、それだけで生成が何倍にも重くなる。なので使っている環境はそのままにして、別に立てたComfyUIで先に速度を確かめてからBooguを回した。今回のmaster更新ではQwen系が遅くならずに済んだ。

fp8はMPSで弾かれる

ネイティブ構成は単純で、UNETLoaderに拡散本体、CLIPLoaderをtype=booguにしてQwen3-VL-8B、VAELoaderにFLUX VAEを読ませる。t2iは標準のCLIPTextEncode、Editだけ専用のTextEncodeBooguEditを使う。

まずMacで一番軽いfp8 Turboで起動確認したら、サンプリングで落ちた。

TypeError: Trying to convert Float8_e4m3fn to the MPS backend
but it does not have support for that dtype.

MPSはfloat8型のテンソルをそもそも保持できない。fp8 scaledはCUDAのfp8演算を前提にした量子化で、Apple Siliconには載らない。これは3月のQwenの件と同じ根っこで、当時もFP8モデルはMPSで動かずBF16へ変換するパッチが要った。

おもしろいのは、詰まったのが拡散本体だけだった点。エラーはKSamplerで出ていて、その手前のCLIPTextEncodeは通過している。つまりQwen3-VL-8Bのテキストエンコーダはfp8のまま動いていて、止まるのは拡散モデルのfp8演算だけ。Macで取れる道はbf16の拡散本体に絞られる。

bf16なら動く

bf16版（実体19GB）を落としてUNETLoaderに読ませると、今度はmodel weight dtype torch.bfloat16でロードが通り、生成まで走った。fp8の壁を回避できた。

速度はこうだった。

条件時間
cold（初回、ロード約50秒込み）118.8秒
warm（4step / 1024px）約70秒（約17秒/step）

メモリは21GBのbf16本体に10GBのテキストエンコーダが乗って、64GBがほぼ埋まる。compressorがフル稼働して空きが数十MBまで落ちたが、OOMはせず完走した。

70秒/枚は10Bモデルとして重いが、この環境では妥当な部類に入る。Qwen Image Edit AIOは5〜6分かかるし、IL系やAnima系も解像度を上げれば1〜2分になる。ステップを落とせば1分を切る。Macで10Bがこの速度で回るのは、正直なところ予想より健闘している。

人物で出してみる

LoRAは当たらないので、自然文でうちのキャラ（サイドポニーに青いスクランチー、白シャツに赤ネクタイ）の造形だけ指定して、人物がどれくらい出るかを試した。顔や細部はモデルが違うので寄らなくていい。大枠が出るかと、画質がどうかを確かめる。

実写

Booguは実写が強い。ただしプロンプト勝負だった。

portrait photo of a person程度の手抜き指定だと、肌が荒く、人種を指定しないとリアルな西洋の中年女性が出てくる。この素っ気なさのせいで、他の画像モデルのように勝手に美形補正をかけない。理想化しない写実寄りがデフォルトの傾向になっている。

そこにprofessional portrait、smooth clear skin、85mm f1.4、soft window lightあたりの品質語を盛ると、一気にプロ撮影風の綺麗な肌に化ける。よそで見かけるBooguの綺麗な人物は、だいたいこっち側のプロンプトだと思っていい。

手抜きプロンプトの実写。肌が荒く、人種未指定で西洋寄りの顔が出る

品質語を盛った実写。同じBoogu Turbo bf16でもプロ撮影風の綺麗な肌になる

人種を指定しないと西洋人がデフォルトで、Japaneseと入れれば東アジア顔に寄る。ただし盛った美形東アジアはK-beauty寄りで、日本人というより韓国のアイドル風に見える。学習データにK-POP系の画像が多いのかもしれない。

アニメ

anime illustrationだけだと水彩っぽくなって、カチッとしたアニメ塗りにならない。

masterpiece、cel shading、vibrant flat colors、clean lineartを足すとパキッとしたアニメ調になる。専用のAnima系ほど振り切ってはいないが、これはこれで立派にアニメ絵だ。

品質語を足したアニメ。水彩っぽさが消えてセル塗り寄りになる

手抜きで荒く出て「使えない」と判断されがちだが、叩いたプロンプトなら人物もアニメも十分実用域に入る。

文字描画の通り具合

売りのバイリンガル文字を試した。結論は、信頼できるのは大きな見出し1語までだった。

英語のCOFFEEも日本語のおはようも、ポスターのタイトルとしては読める文字で出る。ところがメニューの品目のような小さい本文に落ちると、CPASCPAのような意味をなさない文字列に崩れる。値段の数字も怪しく、一番上の0が0かどうか判別できない。

英語ポスター。COFFEEの見出しは読めるが、本文の品目は偽文字に崩れる

日本語ポスター。おはようの大見出しは読める

公式も弱点に「密なタイポグラフィで文字が不安定」と書いていて、Macの4step Turbo bf16でもそのまま出た。ヒーローの1語を狙うなら成立するが、本文まで読ませる用途には届かない。

NSFWの通り具合

モデル名で検索して来る読者はここを確かめに来る層が一定数いるので、はっきり書く。Booguでまともなアダルト画像は出ない。

水着までは普通に通る。成人女性の水着をビーチで、くらいなら拒否もぼかしもなくSFWで出る。ただし理想化しないデフォルトのせいで、ここでもリアルな中年女性が出てくる。

nude系を指定すると上半身裸までは出るものの、解剖が崩壊して油絵が溶けたような描画になり、まともな画にならない。さらにexplicitやfully nakedと強く攻めると、逆にSFWの水着姿に無害化されて返ってくる。攻めるほど浄化される挙動だった。

explicit指定で返ってきた画像。露骨な指定ほど水着姿に無害化される

フィルタが強いというより、NSFWがそもそも学習データに含まれていなさそうな手応えで、その方向の用途には向かない。汎用の写実モデルらしい安全寄りのアライメントになっている。

参考リンク