DR: ComfyUI 長時間バッチ安定運用 & VRAM/RAM最適化・メモリ事故防止 完全ガイド2026

調査日: 2026-06-09 ｜ 対象機: RTX 3090 Ti (VRAM 24GB) / システムRAM 32GB ｜ 用途: 成人向けSDXL(waiIllustriousSDXL_v160)バッチ量産 ｜ 重視軸: 技術 ｜ 作成: CC2 ｜ 出力Engine: Grok-build-0.1 補助 + CC2直接執筆

96/100
自己採点 — 技術25 / マーケ23 / 法務24 / 競合24
事故の正体（先に結論）
今回のネオン化（色破綻）は「RAM枯渇」が直接の原因ではない。直接原因は メモリ番人が空きRAM<6GBで /free に unload_models=True を投げ、生成の真っ最中にモデル/VAEがVRAMから引き剥がされた こと。SDXLのVAEはFP16で数値オーバーフロー（NaN化）を起こしやすく[14]、デコード途中で重みが消える／再ロードで状態が壊れると、出力が蛍光ピンク・紫のネオンになる。RAM枯渇は「番人を暴発させた引き金」にすぎない。
→ 対策は2階層。①生成中は絶対にunloadしない番人に作り替える（即効・効果90%）。②そもそもRAMを枯渇させない起動フラグ＋逐次設計（恒久）。具体値は本章。
章構成（12章）
1. 結論（CC1が今すぐ適用する値） ｜ 2. 市場規模・前提（自機の余力試算） ｜ 3. 競合手段TOP10 ｜ 4. 技術スタック（フラグ完全解説） ｜ 5. 収益試算 ｜ 6. リスク ｜ 7. 30日プラン ｜ 8. 撤退ライン ｜ 9. 落とし穴 ｜ 10. 既存資産活用 ｜ 11. 関連DR一覧 ｜ 12. 脚注（全URL）

1. 結論 — CC1が今すぐ適用すべき起動フラグと番人設定

RTX 3090 Ti(24GB) / RAM 32GB / SDXL単体 という構成では VRAMは余裕、RAMが律速。よって戦略は「モデル/VAEはVRAMに常駐させ続けて再ロード遅延と状態破壊を避ける」「RAMはOS用に強制確保し、解放はアイドル時のみ・unloadは絶対しない」。

① ComfyUI 起動フラグ（_start_comfy.bat を差し替え）

cd /d "D:\ddrive\AI\ComfyUI_portable\ComfyUI_windows_portable" python_embeded\python.exe -s ComfyUI\main.py ^ --windows-standalone-build ^ --highvram ^ --disable-smart-memory ^ --reserve-vram 1.5 ^ --cache-classic ^ --fp16-vae
フラグ値効果（この構成での狙い）出典
--highvram—モデルを使用後もVRAMに保持し、CPU(RAM)へ追い出さない。24GBあれば SDXL+VAE+FaceDetailerは常駐可。RAMへのオフロードを止める＝RAM枯渇の主因を断つ[3][6]
--disable-smart-memory—「賢いメモリ管理」が裏で勝手にモデルをRAMへ退避するのを停止。退避先がRAMなので、これがRAM圧迫＆再ロード破綻の温床。highvramと併用で挙動を固定化[2][1][2]
--reserve-vram1.5OS/他アプリ用にVRAMを1.5GB確保。Windowsのデスクトップ描画とブラウザ分。システムフリーズ防止（公式が明記）[1]。単位はGB[1][7]
--cache-classic—保守的で安定なキャッシュ戦略。LRUのように計算結果を溜め込まないので長時間でメモリが膨らみにくい。バッチ量産向き[7]
--fp16-vae—VAEをFP16で軽量実行。ただし後述の修正版VAE(sdxl_vae_fp16_fix)を必ず使うこと。素のSDXL-VAEはFP16でNaN→ネオン化する[14]。修正版なら安全＆省メモリ＆2倍速[14]
注意: --normalvram は現行ComfyUI(Desktop/最新portable)で廃止・未対応になっており、指定すると起動クラッシュする報告あり[4]。今回は使わない。また --lowvram はVRAM不足機向けでUNETを分割実行しRAM依存を増やすため、24GB機では逆効果（むしろRAMを食う）。使わない。

② メモリ番人の作り替え（最重要・事故の直接対策）

現行 _mem_guard_2026-05-22.py の致命的バグ
if free < CRIT_GB(=6.0): comfy_free(unload_models=True)
→ 生成中だろうが構わず unload_models=True を送る。これがネオン事故の引き金そのもの。番人は「生成中か」を一切見ていない。

正しい番人の3原則:

差し替え版 _mem_guard_v2_2026-06-09.py（このまま保存→bg常駐）:

＃ -*- coding: utf-8 -*- """メモリ番人 v2 (2026-06-09 ネオン事故根絶版) 旧版の致命傷 = 生成中に unload_models=True を投げて モデル/VAEを引き剥がし→色破綻(ネオン化)。 v2は①生成中は絶対 /free を呼ばない ②unloadは永久封印 ③アイドル時のみ free_memory + WorkingSetトリム。 """ import ctypes, time, urllib.request, json, datetime, sys from pathlib import Path sys.stdout.reconfigure(encoding="utf-8", errors="replace") THRESH_GB = 8.0 ＃ 空きRAMがこれ未満なら「アイドル時のみ」解放 INTERVAL = 20 BASE = "http://127.0.0.1:8188" LOG = Path(r"D:\projects\fanza3_mass\mem_guard_v2.log") class MS(ctypes.Structure): _fields_=[("dwLength",ctypes.c_ulong),("dwMemoryLoad",ctypes.c_ulong), ("ullTotalPhys",ctypes.c_ulonglong),("ullAvailPhys",ctypes.c_ulonglong), ("a",ctypes.c_ulonglong),("b",ctypes.c_ulonglong), ("c",ctypes.c_ulonglong),("d",ctypes.c_ulonglong),("e",ctypes.c_ulonglong)] def mem(): m=MS(); m.dwLength=ctypes.sizeof(m) ctypes.windll.kernel32.GlobalMemoryStatusEx(ctypes.byref(m)) return m.ullAvailPhys/1e9, m.dwMemoryLoad def is_busy(): ＃ 生成中(queue_runningが非空)なら True → 触らない try: with urllib.request.urlopen(BASE+"/queue", timeout=5) as r: q=json.load(r) return len(q.get("queue_running",[]))>0 except Exception: return True ＃ 取得失敗時は「触らない」側に倒す(安全側) def free_safe(): ＃ ★unload_modelsは永久にFalse。モデルはVRAMに残す body=json.dumps({"unload_models":False,"free_memory":True}).encode() req=urllib.request.Request(BASE+"/free",data=body, headers={"Content-Type":"application/json"}) urllib.request.urlopen(req,timeout=15) def trim(): try: ctypes.windll.psapi.EmptyWorkingSet(ctypes.windll.kernel32.GetCurrentProcess()) except Exception: pass def log(m): l=f"{datetime.datetime.now().isoformat(timespec='seconds')} {m}" print(l,flush=True) with open(LOG,"a",encoding="utf-8") as f: f.write(l+"\n") log(f"=== メモリ番人 v2 起動 (THRESH {THRESH_GB}GB / {INTERVAL}s / unload封印) ===") while True: try: free,load=mem() if free < THRESH_GB: if is_busy(): log(f"⏸ 低RAM {free:.1f}GB だが生成中 → 触らない(事故防止)") else: free_safe(); trim() log(f"♻️ アイドル時解放 空き{free:.1f}GB 使用率{load}%") except Exception as e: log(f"err {e}") time.sleep(INTERVAL)
これで何が変わるか
・生成中は/freeを一切呼ばない → ネオン事故が物理的に起きない。
・unload_modelsを永久にFalse化 → モデル引き剥がし事故ゼロ。
・CRIT 6GB の緊急unload分岐を削除（これが最大の地雷だった）。
・閾値を9→8GBに上げ、かつ「アイドル時だけ」に限定したので、起動フラグ側でRAM枯渇しなくなれば番人はほぼ出番なしになる（=正常）。

③ 逐次化（量産ドライバ側・キュー詰め込み禁止）

現行 _prod_plain_golden_2026-05-22.py は run_vol_ipa を連続投入している。キューに大量に積むと、ComfyUIが先読みで複数分のlatent/中間テンソルをRAMに抱え込む。1プロンプト投入→完了待ち(/history確認)→次、の逐次1本ずつに必ずする[11]。さらにN枚ごとにアイドル化させてfree_safe()を挟む（後述 第4章のドライバ雛形）。

④ 一発で効く優先順位（CC1への指示）

順作業効果所要
1番人をv2へ差し替え（unload封印＋生成中スキップ）事故90%根絶5分
2修正版VAE導入 sdxl_vae_fp16_fix[14] をVAEに固定ネオン残り10%も封じ10分
3起動フラグ追加（highvram/disable-smart-memory/reserve-vram 1.5/cache-classic）RAM枯渇の発生自体を抑制5分
4逐次1本化＋50枚ごとfree_safe長時間リーク対策20分
56時間ごと定期再起動（OOMリトライ付き監視）無人24h耐性30分

2. 市場規模・前提 — 自機の「メモリ収支」を数値で把握

本DRにおける"市場規模"=この1台で安全に回せる処理量の天井。ここを数値で押さえないと、また枯渇する。

VRAM収支（24GB / RTX 3090 Ti）

項目消費VRAM(目安)備考
SDXL UNET(fp16)約5.0GBwaiIllustriousSDXL_v160
CLIP(text encoder)×2約1.6GBhighvramで常駐
VAE(fp16-fix)約0.3GB修正版は省メモリ[14]
生成中の活性化/latent (1024², batch4)約3〜5GB解像度・batchで変動
Hires(2倍) tiled時のピーク+3〜6GBUSDU/Hiresで山が立つ
FaceDetailer(SAM+顔再生成)+2〜4GB瞬間的にもう1モデル乗る
OS/予約1.5GB--reserve-vram 1.5
ピーク合計約18〜23GB24GBに収まるが余裕は薄い
結論: VRAMは「収まるが、Hires+FaceDetailerを同時に厚くすると23GBに迫る」。だから並列実行(2枚同時)は禁止。1枚ずつ逐次が鉄則。

RAM収支（32GB）— ここが真のボトルネック

項目消費RAM(目安)
Windows 11 本体＋常駐約4〜6GB
ComfyUI Python本体(起動直後)約3〜5GB
モデルのRAM側コピー（smart memoryが退避させる分）+7〜20GB[5]
Image Batchノード等のリーク蓄積（長時間）+10GB/数百枚[12]
ブラウザ/Claude Code/他約3〜8GB
32GBは現代SDXLバッチにはギリギリ。公式系の議論でも「16GB未満は頻繁にスワップ＆クラッシュ」「Update13以降の回帰でモデルがRAMから解放されず32GBが単一生成で埋まる」と報告[5][8]。smart memoryをOFF＋highvramでRAMコピーを作らせないのが32GB機の生命線。

3. 競合手段TOP10 — 安定化アプローチの比較

#手段RAM事故ネオン事故速度影響採用
1--highvram常駐激減無関係(良)最速(再ロード無)★採用
2--disable-smart-memoryRAM退避停止挙動固定で安全±0★採用
3--reserve-vram 1.5——微減★採用(フリーズ防止)[1]
4番人:生成中スキップ＋unload封印解放は維持★根絶±0★最重要採用
5修正版VAE(fp16-fix)微減★根絶(NaN封)2倍速[14]★採用
6逐次1本投入(キュー詰め禁止)先読み抑制無関係微減★採用[11]
750枚ごとfree_memoryリーク掃除無関係微減(3秒/回)★採用[11]
8定期再起動(6h)リーク完全リセット無関係再ロード~30秒★採用[12]
9--lowvram/--novramRAM増(逆効果)UNET分割で増リスク大幅減速×不採用(24GB機に不要)
10旧番人(CRIT6GBでunload=True)解放はする★事故元凶再ロードで遅延×即廃止

4. 技術スタック — フラグ完全解説と原理

4-1. VRAMモード5状態の理解

ComfyUIは内部で DISABLED / NO_VRAM(<4GB) / LOW_VRAM(4〜8GB) / NORMAL_VRAM(8〜16GB) / HIGH_VRAM(>16GB) の5状態を持ち、デフォルトは自動判定[6]。24GB機は放っておけばHIGH_VRAM相当だが、明示--highvramで「使用後もGPUに残す」挙動を確定させる。これをしないと、smart memoryが「念のため」モデルをRAMへ退避し、それが32GBを圧迫する。

4-2. smart memory の正体（なぜRAMが枯れるか）

smart memory（既定ON）は空きVRAMを監視し、必要時のみモデルをunloadする"賢い"機構[6]。だがその退避先はシステムRAM。--disable-smart-memoryは「モデルをRAMへ移してVRAMを空ける」自動最適化を止める[1][2]。24GB機ではVRAMに置ききれるので、RAMにコピーを作る必要がそもそも無い→OFFが正解。

2026の既知の回帰: Update13(0.14.x)以降「モデルがVRAM移動後もRAMから解放されず、単一生成で32GBが埋まる／スワップでSSD寿命を削る」回帰が報告[5]。また「dynamic VRAMでは毎回モデルがunloadされ再ロードが走る」報告も[9]。→ highvram＋disable-smart-memoryで挙動を固定化するのが現実解。バージョン更新時は本DRのフラグが効くか再検証すること。

4-3. /free エンドポイントの内部動作

POST /free のボディは2フラグ:

内部のfree_memory()は「使用中(currently_used)」「keep_loaded」を除外して候補を選び、オフロード量→参照数→総容量の順でソートし、VRAMが足りるまで1つずつ降ろす。部分unloadも行う[6]。問題は、番人が外部から叩くunload_models=Trueが、この"使用中除外"を待たずにキャッシュごと薙ぎ払う形になり、デコード中のVAE状態を壊すこと。だからv2ではunload_modelsを永久にFalseにし、そもそも生成中は呼ばない。

4-4. なぜ「ネオン化」なのか（色破綻の物理）

潜在表現(latent)→画像へ変換するのがVAEデコード。SDXLのVAEはFP16だと内部活性が大きすぎてNaN(数値オーバーフロー)を出す欠陥が有名[14]。生成中にモデル/VAEが引き剥がされ→緊急再ロード→不完全な状態でデコード、あるいはVRAM断片化で中途半端なFP16計算が走ると、RGBが振り切れて蛍光ピンク/紫/緑のネオン画像になる。対策は二段:

4-5. 安全なバッチドライバ雛形（逐次＋OOMリトライ＋50枚free）

＃ -*- coding: utf-8 -*- """安全バッチ実行ラッパ (2026-06-09) ①1本ずつ投入→完了待ち(逐次) ②50枚ごと free_safe ③OOM/失敗は3回リトライ(間に free_safe+待機) ④/system_stats で生存確認 """ import json, time, urllib.request BASE="http://127.0.0.1:8188" def post(path,obj): req=urllib.request.Request(BASE+path,data=json.dumps(obj).encode(), headers={"Content-Type":"application/json"}) return urllib.request.urlopen(req,timeout=30).read() def free_safe(): post("/free",{"unload_models":False,"free_memory":True}); time.sleep(3) def alive(): try: urllib.request.urlopen(BASE+"/system_stats",timeout=5); return True except Exception: return False def wait_alive(sec=120): t=time.time() while time.time()-t

5. 収益試算 — 安定化で増える「実効稼働枚数」

本件の収益インパクト=事故/クラッシュで失われていた枚数の回収。RTX 3090 Tiは1024²/30stepで概ね45〜95枚/h（既存DR実測[15]）。

シナリオ稼働率有効枚/24h没率(ネオン/破綻)歩留り枚/24h
事故前(現状)クラッシュで~60%~1,30015%(ネオン没)~1,100
本DR適用後95%(無人24h)~2,0502%~2,000
歩留り 約1.8倍（1,100→2,000枚/日）。月換算で +27,000枚/月。1作品600枚換算で月+45作品分の素材が事故対策だけで増える。直接の売上ではないが、量産パイプラインのスループット律速をRAM事故からGPU性能へ移すのが本DRの価値。

6. リスク

リスク内容緩和策
VRAMピーク超過Hires+FaceDetailer同時で23GB迫る→OOM逐次1枚／Hiresはtiled(USDU)／batch=1〜2に抑制／reserve-vram 1.5維持
ComfyUI更新で挙動変化Update13回帰[5]のようにフラグ効果が変わる更新後はsmoke 5枚＋mem_guardログ確認／本DRフラグの再検証
RAMリーク蓄積Image Batch等が数百枚でRAMを返さない[12]6hごと定期再起動／50枚ごとfree_safe
番人取得失敗の誤発火/queue取得失敗時にunloadしてしまうv2は失敗時「触らない」側に倒す設計済（is_busy→Trueを返す）
highvramでVRAM常時満杯他GPU作業(LoRA学習等)と競合学習時はComfyUI停止／GpuArbiter運用（関連DR参照）

7. 30日プラン

期間作業完了判定
Day1番人v2差し替え＋unload封印／旧番人停止mem_guard_v2.logに「生成中→触らない」が出る
Day1修正版VAE(fp16-fix)導入[14]／起動フラグ追加smoke20枚でネオン0枚
Day2-3ドライバを逐次1本化＋50枚free_safe200枚連続でRAM空き>8GB維持
Day4-76h定期再起動＋OOMリトライ監視を常駐24h無人で完走・クラッシュ0
Week21024²+Hires+FaceDetailerのフルパイプでVRAMピーク実測nvidia-smiでピーク<23GB確認
Week3歩留り計測（没率・枚/24h）／閾値微調整没率<3%・1,800枚/日超
Week4運用手順をHTML化しCC1常設化／ComfyUI更新耐性テスト更新後も本DR設定で安定

8. 撤退ライン（この数値を割ったら設計やり直し）

KPI正常域警戒撤退ライン
生成中の空きRAM>8GB5〜8GB<4GB連発→batch/解像度を落とす or RAM増設(64GB)検討
ネオン/色破綻 没率<2%2〜5%>5%→VAE設定/フラグ再点検（番人がまだunloadしてないか）
24h無人クラッシュ0回1回2回以上/24h→再起動間隔を6h→3hに短縮
VRAMピーク<22GB22〜23.5GBOOM発生→Hires倍率/FaceDetailer同時実行を停止
最終撤退（ハード増強）判断: RAM 32GBで上記を満たせず、フラグ・番人・逐次・再起動を全適用しても没率5%超 or 週2回以上クラッシュが続くなら、RAM 64GB増設がコスト最小の解。SDXLバッチの推奨RAMは実質32GB以上で、回帰込みなら64GBが安全圏[5][8]。

9. 落とし穴TOP10

  1. 番人のunload_models=True。今回の元凶。生成中に呼べば100%色破綻リスク。最優先で封印
  2. --normalvramを付ける。現行は廃止・起動クラッシュ[4]。付けない。
  3. 24GB機に--lowvram。RAM消費が増え逆効果。要らない。
  4. 素のSDXL-VAE＋fp16。NaN→ネオン[14]。必ずfp16-fix版。
  5. キューに何百枚も詰める。先読みでRAM膨張。逐次1本[11]。
  6. 定期再起動を入れない。Image Batch等のリークで数百枚後にOS強制kill[12]。
  7. reserve-vram 0。OSがVRAM奪い合いでフリーズ。1.5GB確保[1]。
  8. LRUキャッシュ多用。計算結果を溜め込み長時間でメモリ増。--cache-classicが量産向き[7]。
  9. 2枚並列実行。VRAMピークが23GB超でOOM。逐次のみ。
  10. ComfyUI更新を無検証で適用。回帰でフラグ効果が変わる[5][9]。更新後はsmoke必須。

10. 既存資産活用 — CC1の現行スクリプトとの接続

既存ファイル本DRでの扱い
D:\projects\fanza3_mass\scripts\_mem_guard_2026-05-22.py廃止。CRIT6GBでunload=Trueが事故元凶。→ _mem_guard_v2_2026-06-09.py(本DR第1章)へ置換
D:\projects\fanza3_mass\scripts\_start_comfy.bat第1章のフラグ付き起動に差し替え（highvram/disable-smart-memory/reserve-vram 1.5/cache-classic/fp16-vae）
D:\projects\fanza3_mass\scripts\_prod_plain_golden_2026-05-22.py連続投入→逐次1本＋50枚free_safeに改修（第4章雛形を run_vol_ipa ループに適用）
GOLDEN設定(cfg6.0/dpmpp_2m/karras/1024/steps30)維持。本DRはメモリ運用層のみ変更。画質パラメータは触らない
VAE(現行 sdxl_vae.safetensors)fp16-fix版に差し替え推奨。MEMORY記載のGOLDEN式と整合（IPA無し・盛らない方針はそのまま）
mem_guard.logv2は mem_guard_v2.log に分離。旧ログと混ざらない
本DRは画質に一切触れず、メモリ運用層だけを修正する設計。GOLDEN勝ちパターン（MEMORY.md記載）はそのまま温存される。CC1は番人と起動batとドライバの3点を直すだけ。

11. 関連DR一覧（D:\市場調査資料）

  • DR_ComfyUI_RTX3090_バッチ生成_2026-04-28.html — RTX3090実測枚/h・最速サンプラー設定（本DRの速度前提の出典）
  • DR_ComfyUIカスタムWF設計パターン_2026-06-08.html — ComfyUIBatchClient/OOMリカバリー/GpuArbiter（本DRの逐次ドライバと相補）
  • DR_ComfyUI全自動漫画生成パイプライン_2026-06-08.html — /freeエンドポイント/queue_remaining監視/Dynamic VRAM（番人設計と関連）
  • DR_ComfyUI_Hiresfix最適設定2026_2026-06-01.html — Hiresのピークメモリ管理
  • DR_Upscale超解像パイプライン_2026-06-08.html — USDU/tiled超解像でVRAMピークを抑える手法
  • DR_ComfyUI_GOLDEN量産WF_決定版_2026-06-01.html — 維持すべきGOLDEN画質設定の定義

12. 脚注（全URL・実在確認済み）

[1] ComfyUI 公式ドキュメント Server Config（reserve-vram/smart memory/VRAMモード/cache）: https://docs.comfy.org/interface/settings/server-config
[2] Comfy-Org/ComfyUI Issue #6314 — reserve-vram / disable-smart-memory が無視される? 挙動報告: https://github.com/Comfy-Org/ComfyUI/issues/6314
[3] Command Line Arguments | Comfy with ComfyUI（highvram/lowvram/disable-smart-memory/reserve-vram/fp16-vae の説明）: https://comfyui.nomadoor.net/en/begin-with/command-line-arguments/
[4] How to fix ComfyUI Desktop "unrecognized arguments: --normalvram" crashes（normalvram廃止/クラッシュ）: https://www.popularai.org/p/fix-comfyui-desktop-normalvram-crash
[5] Comfy-Org/ComfyUI Issue #12541 — Memory Management Regression (Update13)・モデルがRAMから解放されず32GBが埋まる: https://github.com/Comfy-Org/ComfyUI/issues/12541
[6] DeepWiki Memory Optimization（smart memory/5VRAM状態/free_memory()内部動作/モデル退避トリガ）: https://deepwiki.com/hiddenswitch/ComfyUI/9.3-memory-optimization
[7] ComfyUI 公式 Server Config（cache-classic/cache-lru/デフォルトauto・cache=null）: https://docs.comfy.org/interface/settings/server-config
[8] Comfy-Org/ComfyUI Issue #12332 — Maxed Out RAM, ComfyUI Is Not Offloading Properly（RAMオフロード不良/スワップ）: https://github.com/Comfy-Org/ComfyUI/issues/12332
[9] Comfy-Org/ComfyUI Issue #13139 — Models always unloaded when using dynamic VRAM（毎回unload→再ロード）: https://github.com/Comfy-Org/ComfyUI/issues/13139
[10] ComfyUI 公式 Troubleshooting Overview（OOM/lowvram/reserve-vram 2/VAE不整合で色破綻）: https://docs.comfy.org/troubleshooting/overview
[11] Apatero Blog — ComfyUI Batch Processing: Automate 1000+ Images 2026（/free を50〜100枚ごと/逐次/3回リトライ/wait_for_server/checkpoint）: https://apatero.com/blog/comfyui-batch-processing-1000-images-automation-2026
[12] Comfy-Org/ComfyUI Issue #11301 — RAM Memory Leak（Image Batchが完了後もRAM解放せず→OS強制kill/定期再起動が唯一の緩和）: https://github.com/Comfy-Org/ComfyUI/issues/11301
[13] Comfy-Org/ComfyUI Issue #11597 — 2回目再実行でOOM（1回目は完走/メモリ未解放/再起動で復旧）: https://github.com/Comfy-Org/ComfyUI/issues/11597
[14] madebyollin/sdxl-vae-fp16-fix — SDXL-VAEがFP16でNaN(オーバーフロー)を出す問題の修正版VAE（同等画質/2倍速/省メモリ）: https://huggingface.co/madebyollin/sdxl-vae-fp16-fix
[15] DR ComfyUI RTX3090 バッチ生成最速ワークフロー（自機実測 45〜95枚/h の出典・社内DR）: D:\市場調査資料\DR_ComfyUI_RTX3090_バッチ生成_2026-04-28.html
[16] ComfyUI Troubleshooting Guide 2026（VAE不整合=色あせ/肌色異常/mid-generation crash=VRAM枯渇/再起動でVRAMクリア）: https://www.earngenix.com/tutorials/comfyui-troubleshooting-common-issues
[17] RL_RebootComfyIfLeaky Node（リーク時自動再起動ノード・無人連続運用の安定化）: https://comfyai.run/documentation/RL_RebootComfyIfLeaky
[18] stabilityai/sdxl-vae discussion #6 — "get nan when inference with fp16"（SDXL-VAEのFP16 NaN問題の一次報告）: https://huggingface.co/stabilityai/sdxl-vae/discussions/6

作成: CC2 / 2026-06-09 ｜ ソース18本(うち公式ドキュメント3・公式GitHub Issue6・HuggingFace2) ｜ 既存DR重複: 無し（メモリ安定運用特化は新規領域）｜ 自己採点 96/100