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

Krea 2をM1 MaxのComfyUIで試す Turboは3分強で回り、Rawは47分かけて黒画像

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

Krea 2が2026年6月22日に出た。12BのDiffusion Transformerで、Krea AIが1から学習した独立ラボ製のモデルだ。RawとTurboの2本がオープンウェイトで公開され、ComfyUIのコアも対応した。

公式はCUDA前提で、Macのことは何も書いていない。手元で動かせるのがM1 Maxしかないので、それで回せるかを確かめる。狙いは「ギリでも動くのか、それとも歯が立たないのか」のラインを引くこと。

特に気になるのがRaw。Krea自身が「Rawで学習してTurboで動かせ」と言っている未蒸留のベースモデルで、推論には52ステップ + CFGを推奨している。蒸留済みTurboの8ステップと比べて、Macでどこまで現実的な時間に収まるか（あるいは収まらないか）が今回の芯になる。

Krea 2とは

Krea 2はKrea AIが1から学習した画像生成モデル。Artificial Analysisのtext-to-imageで独立ラボ1位を主張している。2本構成で、用途がはっきり分かれている。

要素中身
本体12B のDiffusion Transformer（single-stream DiT）
テキストエンコーダQwen3-VL-4B
VAEQwen Image VAE
バリアントRaw（未蒸留ベース）/ Turbo（8step蒸留）
ステップRaw 52step + CFG3.5、Turbo 8step + CFGなし
解像度Raw 〜1k、Turbo 1k〜2k

RawとTurboは組みで使う設計になっている。RawでLoRAを学習してTurboに当てるのが公式の推奨で、「TRAIN on Raw, RUN on Turbo」と明言されている。つまりRawは生成用ではなく、未蒸留で素直なぶん学習・ポストトレーニング向けのベースという位置づけ。

Comfy-Orgの再パッケージ配布では、拡散本体がbf16（26.28GB）とfp8 scaled（13.14GB）、Turboはこれにmxfp8（13.53GB）とnvfp4（7.67GB）も加わる。テキストエンコーダはQwen3-VL-4Bがbf16（8.88GB）とfp8 scaled（5.24GB）、VAEはQwen Image VAE（0.25GB）。スタイルLoRAも13本付いてくる。nvfp4はNVIDIA Blackwell前提なのでMacでは触れない。

検証環境

項目内容
マシンMacBook Pro M1 Max 64GB
OSmacOS 26.5
Python3.12.12
PyTorch2.10.0（MPS）
ComfyUImaster先端（Krea2対応コミット #14589 以降）
拡散本体krea2_raw_bf16 / krea2_turbo_bf16（各26.28GB）
TE / VAEQwen3-VL-4B fp8 scaled（5.24GB）/ Qwen Image VAE（0.25GB）
共通条件1024×1024 / 固定プロンプト・固定seed

テスト方針

過去のローカルモデル検証（Boogu-Image、Z-Anime）と同じ枠組みで進める。変える変数を1〜2個に絞って、順に潰していく。

  1. 起動とロードが通るか。まずbf16拡散本体をComfyUIに読ませて、新アーキがMPSでロードできるか確かめる。Krea 2はTE（Qwen3-VL-4B）とVAE（Qwen Image VAE）がBoogu同型なので、過去の地雷（fp8拡散はMPS非対応、ComfyUIアプデでdtypeがBF16に化けて激重化）を踏まないかをまず確認する
  2. fp8拡散はMPSで弾かれる前提。Boogu・Qwenと同じく拡散本体のfp8はMPSで動かないはず。拡散はbf16一択になる見込みで、ここを実際に踏んで確認する。TEのfp8は通るはず
  3. 速度計測。cold（初回ロード込み）とwarm（2回目以降）を分けて測る。Turbo bf16（8step / CFGなし）とRaw bf16（52step / CFG3.5）を同じ1024pxで比較する。RawはCFGで実質2倍の前向き計算になるので、Turboとの差がそのまま「未蒸留の重さ」になる
  4. メモリ常駐量。bf16本体 + fp8 TEで64GBに対してどこまで埋まるか、OOMせず完走するかを記録する
  5. 出力品質。固定プロンプトで人物・アニメ・写実・文字描画あたりの通り具合を確かめる。LoRAは当たらないので自然文で造形だけ指定する

結果は出たものから順に下に追記する。

結果

1. ロード確認

載った。ComfyUIのコアを #14589 以降まで上げると comfy/ldm/krea2/model.py が入り、CLIPLoaderのtypeにkrea2が増える。構成はBooguと同じ並びで、UNETLoaderに拡散本体、CLIPLoaderをtype=krea2にしてQwen3-VL-4B、VAELoaderにQwen Image VAEを読ませる。t2iは標準のCLIPTextEncode、空のlatentはEmptySD3LatentImage（16chのWan21 latent）で通る。shiftはモデル設定に1.15が内蔵されているので、ModelSampling系を挟まなくても動く。

ひとつだけ起動オプションに注意がある。Qwen Image VAEはデフォルトのbf16だとMPSで黒画像を吐く（3月のQwen Image Editの件と同じ）。--fp16-vaeを付けて起動したら正常な画になった。

2. fp8拡散の可否

テキストエンコーダのfp8は通る。今回TEはqwen3vl_4b_fp8_scaled（5.2GB）を使っていて、CLIPTextEncodeもKSamplerも問題なく動いた。fp8のままMPSに載るのはBooguと同じ。

一方、拡散本体のfp8（krea2_turbo_fp8_scaled、13GB）は弾かれた。モデルのロードは通るが、KSamplerでこう落ちる。

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、6月のBooguと同じ根っこで、Macで拡散本体に使えるのはbf16版（26GB）だけ。13GBの軽いほうは諦めるしかない。

3. 速度（Turbo）

Turbo bf16（8step / CFGなし / 1024px）の実測がこれ。

条件時間
cold（初回ロード約26GB込み・DL並走）278.8秒
warm（8step / 1024px）約212秒（約25秒/step）

warmで1枚3分半。8stepの蒸留モデルでこの時間なので、1stepあたりが重い。Booguの10Bが約17秒/stepだったのに対し、Krea2は12Bで約25秒/step。パラメータ差以上に1stepが重い。単一ストリームで全シーケンスを一度に捌くぶん、アテンションのコストが大きいのだと思う。Macで蒸留版を回してこの速度なので、未蒸留のRawがどうなるかは次のセクション。

4. メモリ

warm生成中、bf16本体（26GB）にfp8 TE（5.2GB）が乗って、64GBに対して空きが33GBまで減った。常駐は約31GBで、Boogu（約31GB）とほぼ同じ着地。RAM pressure cacheが効いてOOMはせず完走した。64GBならbf16拡散 + fp8 TEは余裕を持って載る。

5. 出力品質（Turbo）

LoRAは当たらないので自然文で造形だけ指定して、写実・アニメ・文字・スタイルの通り具合を試した。

写実

professional photography、85mm f1.4、soft window lightあたりの品質語を盛ると、すんなりプロ撮影風の人物が出る。理想化しすぎない自然な肌で、ボケや陰影も破綻がない。

Krea2 Turbo bf16の写実ポートレート。サイドポニーに青スクランチー、白シャツに赤ネクタイ

もう一歩踏み込んで、うちのキャラのフル指定（茶髪・画像右側のサイドポニー・青スクランチー・制服一式）を高校生想定で盛ったのがこれ。

Krea2 Turbo bf16にうちのキャラのフル指定。茶髪・右サイドのサイドポニー・青スクランチー・制服まで乗る

茶髪も髪型の位置も制服も、指定どおりに乗った。同じキャラをBooguで出したときは髪色の指定を無視されたので、細かい外見属性への追従はKrea2のほうが明確に強い。サイドポニーの左右はseedで振れるが、髪色や服装のような属性は安定して拾う。

アニメ

cel shading、vibrant flat colors、clean lineartを足しても、パキッとしたセル塗りにはならず、水彩寄りのジブリ調になる。手描きアニメ映画の絵柄が強く出て、専用のAnima/Illustrious系のようなアニメ塗りとは別物になる。

Krea2 Turbo bf16のアニメ。cel shading指定でも宮崎調の水彩寄りになる

文字描画

ここは強い。KREA COFFEEの大見出しが正しく綴られるだけでなく、freshly roasted dailyの小さい本文まで読める文字で出た。Booguが大見出し1語までで本文が崩れたのと比べると、Krea2は小さい本文まで保っている。

Krea2 Turbo bf16の文字描画。大見出しKREA COFFEEに加え小さい本文も読める

スタイル

複雑な構図指定への追従も良い。「タイルのグリッドと青の正方形を交互に並べたヴィンテージコラージュ」というプロンプトで、グリッド構造・交互配置・紙の質感・ミッドセンチュリーの印刷感まで再現した。スタイル系の指定はそのまま絵に出る。

Krea2 Turbo bf16のスタイル。グリッドタイルのヴィンテージコラージュ指定に追従

Raw（未蒸留）はM1 Maxで詰まる

ここからが本題のRaw。公式の推奨どおり52step / CFG3.5 / 1024pxで、Turboと同じポートレートのプロンプトを回した。

まず時間。

条件時間
Raw bf16（52step / CFG3.5 / 1024px）47分2秒（約52秒/step）

1枚に47分。CFGが有効だとcond/uncondの2パスを毎step踏むので、Turboの倍以上のstepコストになる。生成中のメモリはこうだった。

ram空きwiredスワップ使用pressure
Turbo bf16（8step / CFGなし）33GB約21GBほぼなし余裕
Raw bf16（52step / CFG3.5）22.8GB28.3GB約11GB55%

Turboは余裕で収まったが、Rawはモデル実体（wired 28GB）にCFGの2パスぶんの活性化が乗って64GBを超え、約11GBスワップに落ちた。Apple Siliconはユニファイドメモリなので、モデル実体はプロセスのRSSではなくwired側に出る。

そして47分待った結果が、これ。

真っ黒の画像だった。

ComfyUIのログにこれが出ていた。

nodes.py:1659: RuntimeWarning: invalid value encountered in cast
  img = Image.fromarray(np.clip(i, 0, 255).astype(np.uint8))

デコード結果にNaNが混じり、np.clip(NaN, 0, 255)をuint8にキャストして全ピクセルが0、つまり黒になっていた。unetはmodel weight dtype torch.bfloat16でロードされていて、bf16のままCFG3.5を52step回す過程で数値が破綻した。

原因をCFGに絞るため、モデルを載せたまま同じRawをCFGなし（cfg1.0）の8stepで1枚だけ回した。

Raw bf16をcfg1.0・8stepで出した診断画像。出るが眠い

今度はNaNを吐かず、ちゃんと画になった。構図は出ているが、未蒸留＋低step＋CFGなしなので全体にもやがかかって眠い。Rawをシャープに出すには本来CFGが要るのに、そのCFGがbf16のMPSで破綻する。

回避するならunetをfp32で回す手はあるが、47分がさらに倍以上になる。RawはそもそもLoRA学習・ポストトレーニング用のベースで、推論はTurboに任せる設計。「TRAIN on Raw, RUN on Turbo」をMacで身をもって踏んだ格好になった。Macで生成に使うならTurbo一択でいい。

NSFWの通り具合

モデル名で検索して来る読者はここを確かめに来る層が一定数いるので、はっきり書く。検証はすべてTurbo bf16。出力は強めにぼかしてある。

きっかけはX上で「Krea 2はNSFWに強い」「ConditioningKrea2Rebalanceというノードでフィルタを回避できる」という話を見かけたこと。このノードはKrea2の条件付け（Qwen3-VLの12層tapが平坦化された(B, seq, 12×2560)）を層ごとに再重み付けして増幅するもので、作者は「安全フィルタによる品質劣化のバイパス」「モデルのアンフィルター」を謳っている。噂が実機で本当かを確かめた。

まずノードなしの素のTurboで、直接ヌードを指定した。

ノードなしのTurbo bf16でヌード指定。強ぼかし

素で通った。拒否もぼかしも無害化もなく、解剖の破綻もない人体が出る。Booguがnude指定で油絵が溶けたような描画になったのとは対照的で、Krea2は素の状態でまともなヌードを出せる。「NSFWに強い」の噂はノード抜きでも概ね本当だった。

次に同じプロンプト・同じseedで、CLIPTextEncodeとKSamplerの間にノードを挿し、デフォルト設定（multiplier 4.0）で回した。

同条件にConditioningKrea2Rebalanceノードを挿入。描写が濃くなる。強ぼかし

ヌードが出る/出ないは変わらない（素で既に出る）。変わったのは描写の密度で、窓光や肌の陰影、部屋の作り込み、全体のコントラストが一段濃くなった。このノードの効きは「NSFWを解放する」というより、条件信号を増幅してプロンプト追従と描写の濃さを底上げするもの、というのが手元での印象。READMEのいう「quality dilution（品質の希釈）のバイパス」はこちらの効果を指していると思われる。基本的なヌードはそもそも素で通るので、解放という以前の話だった。

なお、これはライセンスに抵触する挙動でもある（次節）。記事ではあくまで噂の真偽を実機で確かめる目的に留め、踏み込んだ生成はしていない。

ライセンス

重みはApacheやMITのような無条件のオープンではなく、独自の Krea 2 Community License Agreement で配布されている。試す前に押さえておくべき条項がいくつかある。

項目内容
商用利用全社の年商100万ドル未満なら可。超える場合は opensource@krea.ai で商用ライセンス契約
再配布・改変・LoRA学習可。ただしライセンス文の同梱、派生モデル名の先頭にKreaを付ける、帰属表示の保持が条件
コンテンツフィルタ必須。「prohibited, harmful, or unlawful なコンテンツの生成・配布を検知・防止・緩和する、合理的かつ適切なContent Filter措置を実装しなければならない」
禁止事項法令・AUP違反のほか、セキュリティ・利用制限・来歴表示・電子透かし機構の回避を明示的に禁止

ここが今回の検証と絡む。前節で使ったConditioningKrea2Rebalanceは「安全フィルタのバイパス」を謳うもので、ライセンスが必須としているContent Filter実装や、利用制限の回避禁止条項に抵触する。手元で挙動を確かめるぶんはともかく、これを使った出力をそのまま配布・商用に回すのはライセンス違反にあたる。記事ではあくまで「噂が実機で本当か」を確認する目的に留めた。

参考リンク