12GB VRAMで動かすKrea 2 Identity Edit最適化とLoRAランク（フルランク・r128・r64）一貫性検証

はじめに：Krea 2の登場と「顔の完全固定（Identity Edit）」の課題

2026年6月22日、画像生成AI分野における重要なマイルストーンとして、12B級の最新text-to-image DiT（Diffusion Transformer）モデル「Krea 2」が公開されました。Krea 2は、公式や各種UIドキュメントで「TRAIN on Raw and RUN on Turbo」と明記されている通り、未蒸留の学習向け「Rawモデル（BF16/26GB）」と、8ステップの高速推論に特化した「Turboモデル（FP8/13GB）」がそれぞれ役割を分担しています。

Krea 2の注目すべき機能の一つが、特定の人物の顔立ちを崩さずに別の衣服や背景へと自然に置き換える「Identity Edit（顔の固定編集）」機能です。しかし、この機能も、ローカル環境で動かすには膨大なVRAM容量を要求され、特にミドルクラス（VRAM 12GB）の環境ではOOM（メモリ不足）の壁に直面しがちです。

本稿では、VRAM 12GB（RTX 3080 Ti）というメモリ制限の厳しいローカルGPU環境において、Krea 2 Turboを活用して「Identity Edit」を安定動作させる最適化アプローチを解説します。さらに、LoRAの構成バリエーション（フルランク/r128/r64）比較に加えて、顔の一部を隠す処理（サングラス・フード等）だけでなく、**「初期状態で隠れていた部分をプロンプト指示で除去し、素顔を露出（復元）させる隠れないケース」**を掛け合わせた多角的な一貫性ベンチマーク結果をお届けします。

1. VRAM 12GB環境における最適化の構築方針

VRAM 12GB環境でKrea 2の12BパラメータDiTモデルと、テキストエンコーダであるQwen3-VL 4Bを同時にロードしてサンプリングを回すには、厳密なメモリ管理が必要不可欠です。本検証では、以下の最適化方針を徹底しました。

• モデルの量子化（FP8版）の採用: Rawモデル（26GB）のロードは完全に避け、公式のFP8量子化チェックポイントである krea2_turbo_fp8_scaled.safetensors（約13GB）をサンプラーに割り当てます。
• LOW_VRAMによる動的ステージングの有効化: ComfyUIの起動オプションに --lowvram を指定。これにより、推論ステージに応じてUNET（DiTモデル）とCLIP（テキストエンコーダ）をホストRAMからVRAM（GPU）へ動的（Dynamic）にロード・オフロードする AIMDO（AI Model Demand Offloading） をフル活用します。
• テキストエンコーダのFP8化: Qwen3-VL 4B のCLIP重みとして、FP8量子化が施された qwen3vl_4b_fp8_scaled.safetensors を使用し、テキスト解析時のピークメモリ消費を抑えます。

2. 開発者必見：ComfyUI APIおよびカスタムノードの最新パラメータ解決策

Krea 2のワークフローをAPIを介して自動実行する際、ComfyUIの最新仕様や一部の不安定なカスタムノードの挙動により、多くのバリデーションエラーや例外が発生します。ここでは、今回直面したエラーと、それらをプログラム的に解決した「コードレベルの知見」を共有します。

① DynamicComboカスタムノード (ResizeImageMaskNode) のクラッシュバグと代替策

画像やマスクのサイズ変更に用いられるカスタムノード ResizeImageMaskNode は、内部で io.DynamicCombo スキーマを採用しています。このノードはAPI経由でパラメータ（resize_type.width のようなドット付きキー）を渡すと、実行時のバインド時に TypeError: unexpected keyword argument や missing required positional argument という致命的なバグを抱えています。 これを回避するため、API送信時にこの不安定なノードを、ComfyUI標準で100%安定して動作する ImageScale ノードへ動的に置換する以下のパッチ処理（Python）を適用しました。

# API用JSON変換スクリプトにおけるノード置換パッチ
if api_node["class_type"] == "ResizeImageMaskNode":
    # 不安定なカスタムノードを標準のImageScaleに置換
    api_node["class_type"] = "ImageScale"
    api_node["inputs"]["image"] = api_node["inputs"].pop("image")
    api_node["inputs"]["width"] = width_val
    api_node["inputs"]["height"] = height_val
    api_node["inputs"]["upscale_method"] = "nearest-exact"
    api_node["inputs"].pop("resize_type", None)

② 最新の ResolutionSelector ノードにおける `multiple` パラメータ要件

ComfyUI本体を最新（v0.28.0付近）にアップデートした結果、標準ノードの ResolutionSelector にアライメント用の必須パラメータ multiple が追加されました。古いワークフロー定義のままAPIリクエストを投げると Required input is missing: multiple という400エラーが返されます。 これに対応するため、API用JSONの ResolutionSelector（ID 83）に対して、DiTモデルのlatent空間の解像度制約に合致する multiple = 8 をプログラム的に強制注入しました。

elif node_id == "83": # ResolutionSelector
    api_node["inputs"]["megapixels"] = 1.0
    api_node["inputs"]["multiple"] = 8  # 最新ComfyUI必須パラメータの注入

③ Qwen3-VL 4B ロード時の CLIPLoader `type` パラメータ制約

Krea 2のテキスト条件付け（conditioning）は、Qwen3-VLの特定のレイヤー出力だけではなく、全12レイヤー分のスタック（12x2560 = 30720次元）を要求します。 そのため、CLIPLoader ノードの type パラメータに通常の "qwen_image" などを指定すると、ValueError: Krea2 expects conditioning with 12x2560=30720 features で実行が中断します。最新のComfyUI環境では、正しく全レイヤーをスタックして出力させるために、type = "krea2" を指定する必要があります。

3. LoRAランク比較検証（前段階）

最初の検証として、顔を固定する Identity Edit 用のLoRAについて、フルランク（r256）、r128、r64の3つのバリエーションを用いて画像生成比較を行いました。

実験の結果、低ランクの r64 LoRA (0.46GB) であっても、フルランク（0.91GB）と視覚的に遜色ないレベルで顔立ちを固定できることが確認されました。そこで、これ以降の検証では、この高効率な r64 LoRA を採用して実験を進めています。

4. 多角ケース・顔隠れ（サングラス・フード）一貫性ベンチマーク評価

Identity Editの真の実力と頑健性を評価するため、被写体A（元々バイザーを装着した女性）と被写体B（素顔の男性）の2名を用いて、顔を部分的に隠す（サングラス、フードの影）シチュエーションで生成テストを行いました。

検証被写体A：女性 (Cyberpunk Visor - 目元初期遮蔽)

検証被写体B：男性 (test_man - 初期素顔)

この結果から、サングラスで両目が隠れる場合や、フードを深く被せて顔の上半分を強い影に落とすライティング下であっても、輪郭・鼻筋・口元のみから被写体の同一性（Identity）を保てることが分かりました。さらに、元のサイバーパンクジャケットのロゴ（NIGHT_CORP）や要素を中世のプレートアーマーと自動的に重ね着融合（マージ・ブレンド）させる、Grounded Attentionの優れたマージ能力も確認されました。

5. 素顔への復元：「隠れないケース」の検証と限界事例（Limitation）

続いて、読者の皆様から寄せられた「バイザーを取り除き、一切の遮蔽物をなくした完全な素顔（裸眼露出）状態でも同一性が保てるか？」という、難易度の高い「隠れないケース」の検証を実施しました。

元画像 test_cyberpunk.png の女性は目元が完全にバイザーで隠れています。これをプロンプトで "removing the visor to show her beautiful bare face, clear face without visor, highly detailed eyes" と指示し、バイザーの下に隠れていた瞳を「予測復元」させました。その結果が以下です。

検証被写体A：女性 (素顔への復元テスト - バイザーの除去)

素顔復元（隠れないケース）の高度な技術的考察

• バイザーの下の瞳の「予測復元」力 (ケースD, ケースE): ケースD（ビジネス）およびケースE（カジュアル）において、元画像で完全に見えなかった「瞳（ブラウンカラー）」が極めてリアルかつ自然な形で復元されています。 しかも、肌のきめ細かなテクスチャや、元のキャラクターが持っていた鼻・口元の同一性、髪型（黒髪に青紫のインナーカラー）は完全に維持されています。
• 表情変化（笑顔）における瞳の追従 (ケースE): ケースEでは「笑顔（smiling）」を指示した結果、ただ目元を描画するだけでなく、微笑みに伴って少し目尻が下がり、細められた「笑い目」として瞳の形状が完璧に制御されており、感情の表現力が非常に高いことが確認できます。
• ファンタジー衣装における復元限界（眼帯・肌色パッチ現象 - ケースF）: しかしながら、最も複雑なコンフリクトが生じるケースF（鎧騎士＋素顔露出）においては、Identity Editの復元限界（Limitation）が露呈しました。 生成された画像を確認すると、右目は美しいブラウンの瞳が描かれている一方、左目の位置が「肌色で塗りつぶされた平面（眼帯風）」の不自然なグラフィックスになってしまっています。 これは、元画像のバイザーの四角い形状拘束（LoRAの影響）と、「中世の鎧プレートアーマー」という非常に重厚な非日常的要素とのマージがAttentionの計算競合を起こした結果、目元のディテール復元に必要なデコード処理が不完全になった（肌色でマスク処理されてしまった）ことが要因と考えられます。

まとめ：検証結果に基づくローカル動作・選択指針

Krea 2のIdentity Edit（r64 LoRA）は、通常の一貫性保持のみならず、元画像で隠れていた目元をプロンプト指示によって自然な裸眼へと「予測復元」する能力を備えています。 しかし、複雑なファンタジー鎧などの非日常的なアセットや背景をプロンプトで強要し、同時にバイザーの除去を求めると、形状の競合によって「目元の一部が不自然に塗りつぶされる限界（眼帯現象）」が生じることが明らかになりました。

この現象を回避するためには、衣服と顔のプロンプト強度（Attention weight）のバランス調整や、あまりに重厚なファンタジー鎧を一度にマージするのではなく、先にクリアな素顔ビジネスポートレートを生成した上で、その画像をソース（Ref Image）として段階的にファンタジー画像へ変換するなどの2ステージ生成アプローチ（マルチパス生成）が有効です。

VRAM 12GB環境においては、LOW_VRAMによる動的オフロードを併用し、これらの特性と限界を理解して生成アプローチを選択することで、OOMを起こさず安定して極めて高度なAIイラスト生成を楽しむことができます。