SDXL(Illustrious系) R18量産の生成高速化
— 6分/枚をどう削るか・品質を落とさない現実解（2026）

RTX 3090 Ti 24GB / ComfyUI portable / torch 2.6.0+cu124 / waiIllustriousSDXL_v160 / cfg6 dpmpp_2m karras 30steps 1024×1536｜現状 約6分/枚（安定上限）
過去ハング手法は採らない 壊さず安全な順序 即試せる本命=step削減 脚注15ソース・実在URL
作成 2026-06-15 ｜ 下書き Grok-4.3（grok_router: dr_world_top, $0.58）＋ WebSearch/WebFetch 一次情報15ソースを手検証で統合。速度数値は他GPU実測の参照値で、本環境では全て要実測。
最重要・先に結論。「dynamic-vram無効化／GPU-VAE化／smart-memory無効解除」はこの環境で既にハングし失敗済みです。よって本DRはそれらを提案しません。代わりに、現状の安定config（--disable-cuda-malloc --disable-all-custom-nodes --cpu-vae --disable-smart-memory）を一切壊さずに効く施策から積みます。最優先はサンプリングのstep削減（30→25）＋サンプラー据え置きとWFのモデル再ロード排除。この2つはフラグを触らず、ハングリスクがほぼゼロで、今日測れます[1][2]。

01結論｜今日やる順序（フラグを触らない手から）

鉄則は 1施策＝1計測＝1メモ。本環境はメモリ管理フラグをいじると過去にハングしているので、まずフラグを一切触らずに済む施策（WFとサンプリング設定だけ）から入ります。

  1. 30steps→25stepsへ短縮（サンプラーは据え置き）
    dpmpp_2m karrasは20〜25stepで品質プラトー。30→25は実質的な画質劣化が小さく、サンプリング時間を約17%削れます[1]。期待 約1.2x リスク最小 フラグ不要・WF1箇所
  2. WFのモデル再ロードを排除
    2枚目以降でログに model load が再走していないか確認し、ノード構成を整理して常駐させる。WF整理だけで15〜25%改善の報告[2]。期待 1.15〜1.25x リスク低
  3. batch_size=2 を実測
    24GBのVRAM余地で2を試す。1枚あたり時間が約32%短縮した実測例あり（11.5s→7.8s/枚, 別GPU）[3]。VRAMはほぼ線形増。期待 〜1.3x/枚 VRAM要監視
  4. （画質ゲート通過を条件に）DMD2 Speed LoRAで step削減
    Illustrious対応のDMD2を8steps/LoRA0.7/LCM/CFG1.4-1.8で。R18の手指がゲートを通った場合のみ本番投入[4][5]。大幅高速だが品質要審査
合算の見込み：施策1〜3だけで 6分 → 3分前後（要実測）。ここまではconfig無改変で到達しうる。さらにDMD2が品質ゲートを通れば2分台以下も射程。ただし倍率は全て参照値で、本環境の実測が絶対基準です。

02市場規模＝「6分/枚」の内訳をどう切り分けるか

速くする前に、6分のうちどこに何秒溶けているかを必ず実測します。これをやらずに高速化手法を足すと、効かない所を叩いて時間を溶かします。

①モデルロードチェックポイント＋VAE＋(LoRA)のVRAM転送。常駐できていれば2枚目以降は0に近いはず
②サンプリング1024×1536・30steps・cfg6の純UNet計算。ここが本来の主時間
③VAEデコード--cpu-vae のためCPUで実行。大判ほど重く、全体の2〜3割を占めうる[6]

切り分けの実務手順（ComfyUIログで測る）

  1. サーバ起動ログ（コンソール）を残す｜ComfyUIは各ステージのタイムスタンプを吐く。model loading／KSamplerの進捗バー（it/s）／vae decoding 前後の時刻を読む。
  2. 同一WFで「2枚連続」生成｜2枚目のログに 再び model load が出るかどうかが分岐点。出れば毎回リロード＝①が主犯。出なければ②③が主時間。
  3. VAEデコード単体を測る｜KSampler完了（progress 100%）から画像保存までの壁時計時間が概ね③。--cpu-vaeなのでここはCPU速度律速。1024×1536で数十秒なら「CPU-VAEのコスト」がここ。
  4. it/s から②を逆算｜KSamplerの it/s（例 1.5it/s なら 30step≒20秒）。本来この②が支配的のはず。②が小さいのに総時間6分なら、①か③で溶けている確定。
CPU-VAEが効いている分のコスト（考え方）：--cpu-vae はGPU-VAEのハング/NaNを避ける応急策ですが、デコードをCPUに移すぶん大判画像で遅くなります。一般にVAEデコードはパイプライン全体の2〜3割を占めうる工程で[6]、CPU実行ではさらに不利。ただし本環境はGPU-VAE化が過去にハングしているため、本DRでは「VAEはCPUのまま」を前提に、他工程で取り戻す方針です。③が実測で突出して重い場合のみ、別ブランチで VAE Decode (Tiled) 化（フラグ非依存・WF側のノード変更）を要検証として後述します。
結論の優先度：実測で①（毎回リロード）が見つかればそれを潰すのが桁違いに効く。①が無く②が支配的なら step削減・batch・蒸留LoRAが効く。③が突出ならTiled化を検討。まず測ってから手を選ぶ。

03競合TOP10｜高速化技術ランク（効果×リスク×品質）

「この環境で安全に・品質を落とさず効く順」に並べています。過去ハング手法（dynamic-vram無効/GPU-VAE/smart-memory解除）は意図的に除外。

順施策速度効果リスク品質影響一言
130→25steps（サンプラー据置）約1.2x最小ほぼ無プラトー内。今日やる[1]
2WFモデル再ロード排除1.15〜1.25x低無config無改変[2]
3batch_size=2〜1.3x/枚中(VRAM)無24GBで実測[3]
4DMD2 Speed LoRA 8step大幅(step1/3〜)中手指要審査ゲート通過が条件[4][5]
5Hyper-SDXL（8step LoRA）大幅中Turbo比は上CFG固定前提[7][8]
6SDXL-Lightning(4/8step)大幅中細部甘めnegative無効化前提[8][9]
7LCM-LoRA大幅中劣化やや大低CFG・コントラスト低下[8]
8SDXL Turbo最速級中R18細部弱い1024超で破綻しがち[8]
9クラウドGPUバースト台数で線形運用同一WFなら無ピーク時のみ[10][11][12][13]
10生成×後工程の並行パイプライン体感1.5〜2x低無待ち時間の消滅[14]
導入順の鉄則：1→2→3 は壊さず確実。4〜8（step蒸留系）はR18品質ゲートを必ず挟む。9・10は速度施策と独立に効く運用層。4以降は「速くなったが手指が崩れた」を必ず疑う。

04技術スタック｜この環境で安全に試せる順序

大前提：起動batの --disable-cuda-malloc --disable-all-custom-nodes --cpu-vae --disable-smart-memory は当面そのまま維持。過去に外してハングした実績があるため、本DRの施策1〜4はこのフラグ群を一切変更しません。触るのはWFとサンプリングパラメータだけ。

第1段：フラグ非改変で効く（即日・最低リスク）

:: 起動bat は現状維持（触らない）
.\python_embeded\python.exe -s ComfyUI\main.py --windows-standalone-build ^
  --disable-cuda-malloc --disable-all-custom-nodes --cpu-vae --disable-smart-memory
:: ↑ここは変えない。変えるのは WF 側だけ ↓
KSampler: steps 30 → 25   :: プラトー内。約17%削減[1]
同一モデルノードを使い回し、2枚目で再ロードが走らない構成に整理 :: 15-25%[2]

この2点だけで config無改変のまま 6分→4分台が見込めます（要実測）。サンプラーは dpmpp_2m karras 据え置き＝勝ちパターンを崩しません。

第2段：batch_size=2 を24GBで実測

VRAMの余地で batch_size 2（KSampler/EmptyLatentの batch）を試す。1枚あたり実効時間が短縮（別GPUで約32%/枚）[3]。23GB超に張り付くなら2で止め、3には上げない（本環境はメモリ逼迫でハング履歴があるため）。メモリ番人 _mem_guard 常駐下で監視しながら。

第3段：DMD2 Speed LoRA（品質ゲート通過を条件に）

[Load Checkpoint: waiIllustriousSDXL_v160]
  └ LoraLoader( dmd2_sdxl_4step_lora, strength 0.7 )
KSampler: steps 8 / sampler LCM / scheduler normal(or simple) / CFG 1.4-1.8
※低step(3-5)は手指が崩れる → 8step + 解剖キーワードで救済[4][5]
※fp32版とfp16版を各0.5で併用すると良好の報告あり[5]（要検証）

これは別WF（run_fast用）として持ち、GOLDEN（30step）WFは温存。DMD2の出力をR18品質ゲート（r18_quality_gate.html）と3AIで採点し、手指/体液/輪郭がGOLDEN比で落ちないことを確認できた場合のみ量産WFに昇格させます。

dynamic-vram無効は使わない（既に失敗済み）

同種の別DR[15]は --disable-dynamic-vram を本命提案していますが、本環境ではこの系統（メモリ管理フラグ改変）が既にハングしています。よって本DRはフラグ層に触れず、WF・サンプリング・LoRA・運用層で速度を取り戻す方針に切り替えています。フラグ層の再挑戦は、本DRの施策で安定運用が固まった後に、別環境/別ブランチでのみ。

（任意・後回し）CPU-VAEが実測で突出して重い場合だけ

02の切り分けで③VAEデコードが突出して重いと判明した時のみ、フラグは触らずWF側で VAE Decode (Tiled)（tile512/overlap64）に置換すると大判のデコードが安定・短縮しうる[6]。要検証。GPU-VAE化（--cpu-vae除去）は過去ハングのため避ける。

05収益試算｜6分→目標秒が在庫に効く経済

段階施策想定/枚（要実測）同8h稼働の枚数比
現状30step / cpu-vae / batch1約360秒×1.0（基準 約80枚）
S1+25step +再ロード排除240〜290秒×1.25〜1.5
S2+batch_size=2180〜230秒/枚相当×1.6〜2.0
S3+DMD2 8step（ゲートOK時）60〜120秒×3〜6
数値は全て参照値からの見込み・要実測。枚数は「1日8時間連続生成」の概算で、選抜歩留り（GOLDENで多seed→ベスト選抜）は別。実際の在庫増は歩留り×速度で決まるため、DMD2導入で速くても手指破綻率が上がれば選抜後の純増は目減りします。
経済の読み方：律速が「生成6分/枚」なら、S2（config無改変で約2倍/枚）だけで同じ電気代・同じ時間で在庫が約2倍。Vol量産の天井がそのまま動きます。DMD2のさらなる加速は「画質ゲート通過」という条件付き上振れ。まずconfig無改変のS1・S2で確実な2倍を取り、DMD2は上澄みと位置づけるのが安全です。

06リスク｜画質破綻・手指・NaN・再ハング

手指破綻（最警戒）：step蒸留系（DMD2/Lightning/Turbo/LCM）は低stepで手指・指の本数・体液の質感が甘くなる。DMD2はstep3-5で破綻報告→8step＋解剖キーワード必須[4][5]。R18の見せ場（結合部・指・トロ顔）はここで崩れやすく、量産前ゲート採点が絶対条件。
CFG/negative前提の取り違え：Lightning/Turbo/LCM/Hyperは訓練時にCFGを内包するため、CFGは1〜2に固定しnegativeを基本無効化する[8]。これを通常CFG6/negative山盛りのまま使うと画質が大幅劣化。GOLDEN（cfg6）の感覚で回さないこと。
再ハング：本環境はメモリ管理フラグ改変でハング履歴。施策1〜3はフラグ非改変なので低リスクだが、batch=3やVAE関連のフラグ追加は再発の芽。1施策ずつ・再発したら直前の1変更が犯人。
VRAM逼迫：batch_size増は latent/attention が並列化しVRAM線形増[3]。23GB超に張り付くと不安定。_mem_guard 併用で監視し、超えたら batch を下げる。
NaN/黒画像：本DRはGPU-VAE/fp16-vaeに触れないため発生源を最初から断つ。CPU-VAE維持＝この経路のNaNは回避。

0730日プラン

  1. Day1-3：フラグ非改変の即効施策｜25step化＋WF再ロード排除。02の手順で①②③の内訳を実測し基準値を記録。ここで勝ち筋の6割が見える
  2. Day4-7：batch_size=2の実測｜2で1枚あたり時間とVRAMピークを30枚分ログ化。23GB超で不安定なら1へ戻し記録。
  3. Day8-15：DMD2の品質審査｜別WFで8step/LoRA0.7/LCM/CFG1.4-1.8。30枚生成→r18_quality_gate＋3AIで手指/体液/輪郭をGOLDEN比採点。合格時のみ量産WF昇格。
  4. Day16-22：Hyper-SDXL/Lightningの比較｜DMD2がNGなら8step LoRA系を同手順で比較。CFG固定/negative無効を厳守して採点。
  5. Day23-30：並行パイプライン＋クラウド検証｜生成と写植/選抜を別プロセスで並行（10）。ピーク時のみVast.ai/RunPodで同一WFをバーストし、実コストと枚数増を実測して費用対効果を確定。

08撤退ライン（ダメなら即GOLDENへ戻す）

事象撤退/対処
25stepで明確な画質低下（ゲート点が下がる）30stepへ即復帰（速度より品質）
batch=2でNaN/メモリ不足が2回連続batch=1へ戻す。3は試さない
DMD2 8stepで手指破綻が10枚中3枚以上DMD2撤去。30step GOLDEN維持
Lightning/Turboで結合部・指がゲート落ちstep蒸留系を全撤去（R18細部優先）
フラグを足して再ハング直前の1フラグを除去（犯人確定）。安定configへ即復帰
クラウド月額が想定を超過ローカル運用へ完全回帰（金額閾値は要設定）
原則：速度WFはいつでも1クリックでGOLDENに戻せる状態を保つ。bat/WFは run_golden_safe（30step・現config）と run_fast（25step/batch/DMD2）の2本持ち。

09落とし穴（やりがちな失敗）

10既存資産の活用

🤑 マネタイザー：config無改変のS1＋S2だけで在庫が約2倍。律速が生成ならVol売上の天井がそのまま2倍に動く。まずstep25とbatch2を今日測れ。DMD2は上澄み、無理に急がない。
💼 コーチ：過去ハングの正体は「フラグを攻めた」こと。今回はフラグを触らない手から積む設計だから安全。1施策＝1計測＝1メモ。02の切り分けを最初にやれば、どこを叩くか迷わない。
💕 メンター：「外すと固まる」で何度も時間を溶かしたのは判断ミスじゃない、この環境のフラグ層が繊細なだけ。だから今回は触らずに速くする。step25とWF整理は壊しようがない。そこから一歩ずつで大丈夫。

11関連DR一覧（棲み分け）

本DRは「過去にハングしたフラグ層を触らず、WF・サンプリング・蒸留LoRA・クラウド・並行運用で6分/枚を削る」点に特化。既存のハング根治DR（フラグ層）とは前提と打ち手が異なるため棲み分け済み。

12脚注（実在URL）

  1. [1] DPM++ 2M Karras は20〜25stepで品質プラトー・25が速度品質比のスイート（SDXL）— https://apatero.com/blog/comfyui-sdxl-workflow-optimization-guide-2026 ／ https://stable-diffusion-art.com/samplers/
  2. [2] WF整理によるモデル再ロード排除で15〜25%改善・サンプラー別実測（DPM++2M22step=10.8s等）— https://apatero.com/blog/comfyui-performance-speed-up-generation-40-percent-2025
  3. [3] batch_size=2で1枚あたり約32%短縮（11.5s→7.8s/枚）・VRAMは線形増 — https://apatero.com/blog/comfyui-performance-speed-up-generation-40-percent-2025 ／ https://www.databasemart.com/blog/stable-diffusion-benchmark-in-comfyui-on-rtx5090
  4. [4] DMD2 Speed LoRA [SDXL/Pony/Illustrious]（推奨8steps/LoRA0.7/LCM/normal-simple/CFG1.4-1.8・低stepで手指崩れ→6-8step+解剖キーワード）— https://civitai.com/models/1850983
  5. [5] DMD2 fp32/fp16 併用0.5+0.5の報告・4step LoRA配布 — https://civitai.com/models/1608870 ／ https://www.diffus.me/models/dmd2-speed-lora-sdxl-pony-illustrious-dmd2-sdxl-4step-lora
  6. [6] VAEデコードはパイプラインの一定割合を占め大判で重い・VAE Decode (Tiled)で安定化 — https://www.apatero.com/blog/comfyui-nan-error-black-image-output-fix-2025 ／ https://www.synpixcloud.com/blog/comfyui-memory-optimization-guide
  7. [7] Hyper-SD/Hyper-SDXL は1〜8stepで高品質生成・TurboよりHyper-SDが精度高め — https://stable-diffusion-art.com/hyper-sdxl/
  8. [8] Turbo/Lightning/LCM/Hyper比較：CFGを訓練時内包→CFG1-2固定・negative無効が前提。劣化傾向の違い — https://www.yeschat.ai/blog-turbo-lightning-lcm-hyper-sd-an-introduction-to-speeding-up-your-stable-diffusion-comfyui-43367
  9. [9] SDXL-Lightning は1/2/4/8step別チェックポイント・reconstruction+adversarial loss — https://www.felixsanz.dev/articles/sdxl-lightning-quick-look-and-comparison
  10. [10] RunPod Community Cloud：RTX4090 $0.34/hr、A100 80GB $0.89/hr（2026・変動）— https://www.runpod.io/gpu-models/rtx-4090 ／ https://checkthat.ai/brands/runpod/pricing
  11. [11] RunPod Secure Cloud：RTX3090 $0.44/hr、A100 80GB $1.89/hr（安定/高信頼）— https://gpus.io/en/providers/runpod
  12. [12] Vast.ai RTX4090：on-demand 典型$0.39/hr（$0.35-0.50）、interruptible $0.29-0.31/hr（2026・要確認）— https://www.synpixcloud.com/blog/vast-ai-vs-runpod-rtx-4090-pricing ／ https://vast.ai/pricing/gpu/RTX-4090
  13. [13] クラウドGPU価格比較2026（A100 $1.99/hr〜・interruptibleは50-80%安だが中断リスク）— https://www.spheron.network/blog/gpu-cloud-pricing-comparison-2026/ ／ https://getdeploying.com/gpus/nvidia-rtx-4090
  14. [14] ComfyUIバッチ自動化・キュー運用（生成と後工程の並行・queueはVRAM節約but遅い／batchは速いがVRAM増のトレードオフ）— https://apatero.com/blog/comfyui-batch-processing-1000-images-automation-2026
  15. [15] （参照）同種別DR：--disable-dynamic-vram を本命提案＝本環境では失敗済みのため本DRは不採用 — D:\市場調査資料\DR_ComfyUIハング根治と生成高速化_2026-06-15.html ／ 原典 https://github.com/Comfy-Org/ComfyUI/issues/13139

作成: 2026-06-15 ／ 下書き grok-4.3（grok_router dr_world_top, $0.5803）＋ WebSearch/WebFetch 一次情報15ソースを手検証で統合。速度の具体秒は別GPU/別解像度の実測参照値であり、本環境（3090Ti/1024×1536）では全て要実測。過去にハングしたメモリ管理フラグ層は意図的に不採用とし、フラグ非改変で効く施策から安全な順序で配置。