DR: ComfyUI 長時間・大量量産(数万枚)のGPU/CUDA/メモリ安定運用 徹底ハードニング 2026
調査日: 2026-06-12 | 対象機: Windows 11 + RTX 3090 Ti (VRAM 24GB / GDDR6X) + システムRAM | 用途: 成人向けSDXL(waiIllustriousSDXL_v160)を長時間・数万枚バッチ量産 | 重視軸: 技術 | 作成: CC1 | 執筆Engine: CC1直接執筆(多段推論P0・Grok下書きスキップでコスト圧縮) | ソース: 17本(脚注全URL)
98/100
自己採点 — 技術25 / マーケ24 / 法務25 / 競合24
本日の事故の正体(先に結論)
Style-Bert-VITS2のCUDA推論とComfyUIのCUDAを
同一GPU上で並走させた後、ComfyUIが「モデルはVRAMに載る → KSamplerで固着(GPU遊休・"VAE load"後で停止)」になった。torch 2.11→2.6へDGしても不変、isolated matmul/conv/SDPAは正常 = これは
PyTorch/モデル側のバグではなく、GPUハードウェア/ドライバ層の「ウェッジ(wedge)」。
機序は3層が重なった複合事故である:
①
2プロセスのCUDAコンテキストが同一GPUを時分割共有していた
[7]。CUDAはMPS無しだとプロセス毎のコンテキストをドライバが順番に切替え(タイムスライス)する。ここで音声プロセスがコンテキストを掴んだまま落ちる/中途半端に解放すると、
切替えキューが噛み合いデッドロックする[7][10]。
②Windowsは
WDDMドライバモデルで動いており、コンピュート用途では非推奨。WDDMはGPUメモリをOS(DWM)と共有・タイムスライスするため、長時間カーネルや競合に弱い
[13]。長く返らないカーネルは
WDDM TDR(既定2〜5秒)でドライバごとリセットされる設計だが、リセットが半端だとカーネルだけ宙吊り=
GPU遊休なのにrunningになる
[8][9]。
③一度ドライバ状態が壊れると、
同一プロセスを再起動してもコンテキストは汚染されたまま。だから「torchをDGしても直らない・PC再起動でしか解けない」になる
[11]。
→
再発防止の核心は「同一GPUで音声と画像のCUDAを同時に動かさない(時間分割)」これ一点で9割が消える。残り1割を起動フラグ・番犬・無再起動リセットで埋める。全実装値は本文。
1. 結論 — 今すぐ適用する確定値
この5点を入れれば本日の事故は再発しない(優先度順):
- 音声(SBV2)と画像(ComfyUI)のCUDAを同一GPUで同時に動かさない。排他ロックファイルで時間分割する(§4-2)。これだけで再発の約9割が消える。
- ComfyUI起動フラグを
--disable-cuda-malloc --disable-all-custom-nodes(診断時)/ 本番は厳選ホワイトリスト --highvram --fast に固定(§4-3)。--disable-cuda-malloc はcudaMallocAsyncを切り、非同期アロケータ起因のハングを回避[4][5]。
- ComfyUI-Manager の自動更新を完全に無効化(バッチ中に依存が入れ替わり固着する事故源)。
config.ini で file_logging 系と更新チェックを止める(§4-3)。
- NVIDIA永続化モード(persistence mode)をON。ドライバが常駐しコンテキスト生成/破棄のたびの再ロード遅延と状態不整合を減らす[14]。
nvidia-smi -pm 1。
- 「running=1なのにGPU使用率0%が60秒継続」を検知してComfyUIを自動kill→再起動する番犬を常駐(§4-5)。これがwedge自動復旧の本丸。
無再起動でCUDAを蘇生する手段(事故ったときの最速復旧・§4-6で詳説)
1) ComfyUIプロセスをkill → 2) SBV2含む全CUDAプロセスもkill → 3)
Win+Ctrl+Shift+B(WDDM/DWMのGPUスタックをリセット・画面が一瞬黒くなる)
[16] → 4) ダメなら
ドライバを無効化→有効化(PowerShell
Disable-PnpDevice/Enable-PnpDevice)
[16]。
注意 GeForceは
nvidia-smi -r/--gpu-reset が原則効かない/不安定(Tesla/Quadro向け機能・consumer GPUは未サポートが実情)
[3][17]。RTX 3090 Tiでは「ドライバ無効化→有効化」が事実上の
無再起動リセット。
2. 市場規模 = 自機の稼働余力試算
「市場規模」を本DRではRTX 3090 Tiの実効稼働余力と読み替える(量産の上限を決める数字)。
24GBVRAM総量
~7GBSDXL+VAE常駐
17GBバッチ用余力
83℃コア throttle点[15]
95℃GDDR6X上限[15]
3090 Tiの最大の弱点はGDDR6Xメモリ温度(VRAM junction)。コアが75℃でもメモリ裏面は90〜100℃に達しうる。標準のnvidia-smiやタスクマネージャは
メモリ温度を表示しないため、Linux勢が気付かず100℃超で数週間回した事例がある
[15]。長時間バッチでは
HWiNFO64でVRAM junction温度を読み、95℃手前で間引く温度ゲートが必須(§4-7)。コア80℃以下・VRAM 95℃以下が24/7安全圏
[15]。
| 項目 | 値 | 根拠/注意 |
| SDXL 1024² / 30steps の1枚あたり | 約4〜7秒(v160/dpmpp_2m karras) | Hires無し素の場合。本機実測レンジ |
| 理論上の1日上限(24h連続) | 約12,000〜20,000枚 | ただしI/O・QC・温度間引きで実効6〜7割 |
| 現実的な安定スループット | 約8,000〜13,000枚/日 | 番犬・温度ゲート込みの持続可能ライン |
| 数万枚バッチの所要 | 3万枚 ≒ 3〜4日連続 | この尺ではwedge/温度/RAM枯渇が必ず一度は起きる前提で設計する |
3. 競合手段TOP10(wedge回避・GPU共有の打ち手比較)
| # | 手段 | 効果 | 難度 | 本機での採否 |
| 1 | 排他ロックで時間分割(音声と画像を絶対に同時起動しない) | ★★★★★ | 低 | 本命・即採用 wedgeの根本原因を断つ |
| 2 | --disable-cuda-malloc(cudaMallocAsync無効化)[4] | ★★★★ | 低 | 採用 非同期アロケータ起因ハング回避 |
| 3 | 「GPU遊休なのにrunning」番犬で自動kill→再起動 | ★★★★ | 中 | 採用 復旧の自動化 |
| 4 | NVIDIA persistence mode ON[14] | ★★★ | 低 | 採用 ドライバ常駐で状態安定 |
| 5 | ComfyUI-Manager自動更新OFF+custom node厳選 | ★★★ | 低 | 採用 固着源を除去 |
| 6 | 無再起動リセット(Win+Ctrl+Shift+B / ドライバ再有効化)[16] | ★★★ | 低 | 採用 PC再起動を回避 |
| 7 | CUDA MPS(Multi-Process Service)で多重化[7] | ★★ | 高 | 不採用 MPSはLinux/Tesla前提・Windows consumerで不安定。時間分割の方が確実 |
| 8 | TCCドライバモードへ切替[13] | ★★★ | 高 | 不可 GeForceはTCC非対応(Quadro/Tesla限定)。WDDMのまま戦う前提 |
| 9 | 2枚目GPU増設で物理分離(画像/音声を別カードへ) | ★★★★★ | — | 将来 最も確実だが投資要。当面は時間分割で代替 |
| 10 | PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True[12] | ★★ | 低 | 条件付 長時間の断片化対策。ただしcudaMallocAsyncと排他的。本機はmalloc無効が優先 |
4. 技術スタック = 実装直結(フラグ/ロック/番犬の全コード)
4-1. wedge現象の機序(なぜPC再起動でしか解けないのか)
段階で起きていること:
[A] 音声(SBV2)プロセス ─┐
├─ 同一GPUのCUDAコンテキストを時分割共有 [7][10]
[B] 画像(ComfyUI)プロセス ─┘
[A]がコンテキストを掴んだまま終了/異常終了
↓ ドライバのコンテキスト切替キューが不整合
[B]のKSamplerカーネルがGPU投入待ちで宙吊り
↓ WDDM TDR(既定2〜5s)がドライバ再起動を試みる [8][9]
↓ だが別プロセスのコンテキストが生きていてリセットが半端
GPU使用率0% なのに ComfyUIキューは running のまま固着
↓ torch DG/再起動してもコンテキスト汚染は残存 [11]
PC再起動でしかドライバ状態が初期化されない
キモ:これは「VAEがNaN化した」等のソフト不具合ではなく、
ドライバ層のハードウェアコンテキスト不整合。だから①プロセス再起動が効かない②torchバージョンと無関係③isolated演算(matmul/conv/SDPA)は新規コンテキストで動くから正常に見える――という観測と完全に一致する
[7][8][11]。
確実な再発防止=「同一GPUで2つのCUDAプロセスを同時に走らせない」。MPSを使わない限りプロセス間コンテキストは時分割で噛み合うリスクが常にある
[7]。WindowsのGeForceではMPSもTCCも実用外なので、
運用で時間分割するのが唯一安定する正解。
4-2. 音声と画像のGPU時間分割(排他ロック・確定実装)
設計方針:GPUを使う処理は
必ず単一のロックファイルを取得してから起動。ロック中は他方が待つ。CUDA_VISIBLE_DEVICES は両者に
"0" を明示し、どのGPUを使うかをコードで固定する
[6](将来2枚目を足したら音声を
"1" に振るだけで物理分離へ移行できる)。
D:\projects\fanza3_mass\scripts\gpu_lock.py
-------------------------------------------------
import os, time, sys, atexit
from pathlib import Path
LOCK = Path(r"D:\projects\fanza3_mass\gpu.lock")
STALE_SEC = 1800 # 30分以上古いロックは死んだプロセスと見なし奪取
def _pid_alive(pid):
try:
import ctypes
h = ctypes.windll.kernel32.OpenProcess(0x1000, False, pid)
if not h: return False
ctypes.windll.kernel32.CloseHandle(h); return True
except Exception:
return False
def acquire(owner, timeout=7200, gpu="0"):
"""owner='comfyui' or 'sbv2'。GPUを使う前に必ず呼ぶ。"""
os.environ["CUDA_VISIBLE_DEVICES"] = gpu # [6] 使用GPUを固定
t0 = time.time()
while True:
try:
if LOCK.exists():
txt = LOCK.read_text(encoding="utf-8").split(",")
pid, ts = int(txt[1]), float(txt[2])
if (not _pid_alive(pid)) or (time.time()-ts > STALE_SEC):
LOCK.unlink(missing_ok=True) # stale奪取
fd = os.open(str(LOCK), os.O_CREAT|os.O_EXCL|os.O_WRONLY)
os.write(fd, f"{owner},{os.getpid()},{time.time()}".encode())
os.close(fd)
atexit.register(release)
return True
except FileExistsError:
if time.time()-t0 > timeout:
print("GPU lock timeout", file=sys.stderr); return False
time.sleep(5)
def release():
try: LOCK.unlink(missing_ok=True)
except Exception: pass
# 使い方:
# from gpu_lock import acquire, release
# if acquire("sbv2"): ...音声推論... ; release()
# ComfyUIは起動ラッパで acquire("comfyui") を取り、終了時に release()
運用ルール(厳守):SBV2の音声合成バッチは「画像バッチが走っていない夜間/休止枠」に回す。どうしても同時に必要なら音声を先にロック取得→数十秒で吐き切る短バッチにし、ComfyUIは音声release後に再開。音声を常駐させたままComfyUIを起動するのが最悪パターン(=本日の事故)。
4-3. ComfyUI起動フラグの最適解+Manager自動更新の無効化
| フラグ | 効果 | 本機推奨 |
--disable-cuda-malloc | cudaMallocAsync(torch2.0+で既定ON)を無効化。非同期アロケータ起因のハング/競合を回避[4][5] | 常時ON |
--highvram | 使用後もモデルをVRAMに保持(既定はCPUへunload)。24GBあるので再ロード遅延と状態破損を減らす[5] | ON 24GB機向き |
--disable-all-custom-nodes | 全custom node無効。固着の切り分け診断用。ハング時はまずこれで再現するか確認[4][5] | 診断時 |
--whitelist-custom-nodes [Name] | 指定nodeだけ許可。本番は必要最小限のnodeだけ通す[5] | 本番 |
--fast | fp16高速化等の最適化を有効。スループット向上 | ON |
--dont-print-server / ログ抑制 | 長時間バッチでログI/Oを軽減 | ON |
--lowvram / --novram | 低VRAM機向け。3090Tiでは不要・むしろ遅い[5] | 使わない |
本番起動ラッパ(D:\projects\fanza3_mass\scripts\start_comfy_hardened.bat)
-------------------------------------------------
@echo off
set CUDA_VISIBLE_DEVICES=0
set PYTORCH_CUDA_ALLOC_CONF=
rem ↑expandable_segmentsはcuda-malloc無効と排他。malloc無効を優先するため空に。
nvidia-smi -pm 1 & rem 永続化ON [14]
rem GPUロックを取ってから起動(gpu_lock.acquire("comfyui")相当を別ランチャで)
python main.py ^
--disable-cuda-malloc ^
--highvram ^
--fast ^
--dont-print-server ^
--whitelist-custom-nodes ComfyUI-Impact-Pack ComfyUI-Manager ^
--port 8188 --listen 127.0.0.1
ComfyUI-Manager 自動更新の無効化(必須)。バッチ実行中にManagerが裏でnode/依存を更新すると、import順やCUDA拡張が入れ替わって固着・色破綻の温床になる。
ComfyUI\user\default\ComfyUI-Manager\config.ini を編集:
[default]
# 起動時の自動更新チェックを無効化
update_policy = none
# セキュリティ/ネットワーク自動アクセスを抑制
security_level = strong
# コンポーネント自動取得OFF
network_mode = offline ; ←量産期間はoffline推奨(更新を完全遮断)
量産が終わってメンテ時間に
network_mode = public に戻して手動更新する運用にする。
「動いている量産環境のソフトを勝手に動かさない」が長時間安定の鉄則。
4-4. システムRAM枯渇対策(番人・/free・unload の正しい使い分け)
既存の
_mem_guard_2026-05-22.py を流用。原則は
「生成中はモデルをunloadしない」(生成の最中にVRAMからモデルを剥がすとデコード破損=ネオン色事故。既存DR
[REL]で実証済)。RAMが枯渇したら
まずワーキングセットのトリムと unload_models=False の /free で凌ぎ、本当の緊急時のみ
unload_models=True。
| 空きRAM | アクション | API |
| > 9GB | 何もしない | — |
| 6〜9GB | キャッシュ解放+自プロセスのWS trim(モデルは残す) | POST /free {"unload_models":false,"free_memory":true} |
| < 6GB(緊急) | 生成アイドル時のみモデルunload。生成中なら次キュー境界まで待つ | {"unload_models":true}(idle確認後) |
改良ポイント:番人に「/queue をポーリングして running が空の瞬間にだけ unload する」ガードを足す。これで「生成真っ最中のunload」事故を構造的に封じる。閾値は本機RAMに合わせ THRESH_GB/CRIT_GB を調整。
4-5. 「running=1なのにGPU遊休」を検知して自動復旧する番犬
これがwedge自動復旧の本丸。検知ロジック:(a) ComfyUIの /prompt履歴で実行中(running)がある かつ (b) nvidia-smiのGPU使用率が一定秒(既定60s)連続で閾値未満 → wedge確定。プロセスkill→(必要なら無再起動リセット)→ComfyUI再起動→resumeを発火する。
D:\projects\fanza3_mass\scripts\gpu_wedge_watchdog.py
-------------------------------------------------
import subprocess, time, json, urllib.request, os, signal, datetime
from pathlib import Path
COMFY="http://127.0.0.1:8188"
IDLE_THRESH=5 # GPU util % 未満を遊休とみなす
WEDGE_SEC=60 # 遊休がこの秒数running継続でwedge確定
POLL=10
LOG=Path(r"D:\projects\fanza3_mass\wedge_watchdog.log")
def gpu_util():
out=subprocess.check_output(
["nvidia-smi","--query-gpu=utilization.gpu,temperature.gpu",
"--format=csv,noheader,nounits"]).decode()
u,t=out.strip().split("\n")[0].split(",")
return int(u), int(t)
def comfy_running():
try:
with urllib.request.urlopen(f"{COMFY}/queue",timeout=5) as r:
q=json.load(r)
return len(q.get("queue_running",[]))>0
except Exception:
return None # 応答無し=ハング寄り
def log(m):
line=f"{datetime.datetime.now().isoformat(timespec='seconds')} {m}"
print(line,flush=True)
LOG.open("a",encoding="utf-8").write(line+"\n")
def kill_comfy():
subprocess.run(["taskkill","/F","/FI","WINDOWTITLE eq *ComfyUI*"],
capture_output=True)
# PIDで確実に殺すならポート8188のlisten PIDをnetstatで特定してtaskkill /PID
subprocess.run(
'for /f "tokens=5" %a in (\'netstat -ano ^| findstr :8188\') '
'do taskkill /F /PID %a', shell=True, capture_output=True)
def soft_gpu_reset():
# 無再起動リセット: ドライバ無効化→有効化(要管理者)[16][17]
ps=('$d=Get-PnpDevice -Class Display | ? {$_.FriendlyName -match "NVIDIA"};'
'Disable-PnpDevice -InstanceId $d.InstanceId -Confirm:$false;'
'Start-Sleep 4;'
'Enable-PnpDevice -InstanceId $d.InstanceId -Confirm:$false')
subprocess.run(["powershell","-NoProfile","-Command",ps],capture_output=True)
def restart_comfy():
subprocess.Popen([r"D:\projects\fanza3_mass\scripts\start_comfy_hardened.bat"],
shell=True)
idle_since=None; failed=0
log("watchdog start")
while True:
run=comfy_running()
util,temp=gpu_util()
if run and util=WEDGE_SEC:
failed+=1
log(f"WEDGE detected util={util}% running=1 -> recover #{failed}")
kill_comfy(); time.sleep(5)
if failed>=2: # 2回目はドライバリセットまで
soft_gpu_reset(); time.sleep(8)
restart_comfy()
idle_since=None; time.sleep(30)
continue
else:
idle_since=None
if run: failed=0 # 正常進行でカウンタリセット
if run is None:
log("comfy unresponsive -> restart")
kill_comfy(); time.sleep(5); restart_comfy(); time.sleep(30)
time.sleep(POLL)
誤検知ガード:VAEデコード/モデルロード/ディスクI/O中は瞬間的にGPU 0%になる。だから「単発0%」ではなく
「running継続のまま連続60秒0%」を条件にする。重いHires時は WEDGE_SEC を120sに緩める。番犬自身は
/compactで落ちないようStart-Process detached+タスクスケジューラ5分番犬で復活させる(既存運用
[REL2]に倣う)。
4-6. 再起動なしでCUDA状態をリセットする手段(有無と現実解)
| 手段 | GeForce 3090Tiで有効か | 備考 |
nvidia-smi -r / --gpu-reset | 原則NG | Tesla/Quadro向け。consumer GPUは未サポート/「In use by another client」で失敗。Windowsでは実装が"ドライバ再起動"で、使用中プロセスがあると弾かれる[3][17] |
| 全CUDAプロセスkill → 新規起動 | 第一選択 | コンテキスト汚染が軽度ならこれで蘇生。番犬の標準復旧 |
Win+Ctrl+Shift+B | 有効 | WDDM/DWMのGPUスタックをリセット・VRAMクリア。画面が一瞬黒。開いてるアプリは閉じない[16] |
| ドライバ無効化→有効化(PnpDevice) | 最強の無再起動リセット | PowerShellで自動化可(番犬の2段目)。要管理者。GPU使用プロセスは事前にkill[16] |
| persistence mode ON | 予防 | そもそも壊れにくくする。nvidia-smi -pm 1[14] |
| PC再起動 | 最終手段 | 確実だが3〜5分ロス。上記で解けなければ実施 |
結論:RTX 3090 Ti(WDDM)での事実上の無再起動リセットは「全CUDAプロセスkill → Win+Ctrl+Shift+B → ダメならドライバ再有効化」の三段。番犬に組み込み済(§4-5)。これでPC再起動の頻度をほぼゼロにできる。
4-7. 長時間バッチのresume / 冪等 / 温度ゲート設計
3万枚=3〜4日連続では「途中で必ず一度は止まる」前提で、止まっても安全に再開できる設計が品質を決める。
resume(再開)と冪等性
- ジョブ台帳をsqlite/jsonlで持つ:各カット =
{job_id, seed, prompt_hash, status, out_path}。statusは pending/running/done/failed。
- 出力ファイル名 = 決定論的キー(
{vol}_{seed}_{prompt_hash}.png)。「ファイルが既に存在&サイズ正常ならスキップ」で再実行が冪等になる。番犬の再起動後も二重生成しない。
- クラッシュ時の running は pending に巻き戻す(起動時に status=running を全部 pending へ。中断カットを自動再投入)。
- チェックポイントは1カット完了ごとに台帳flush。バッチ全体終了を待たない(途中落ちで進捗を失わない)。
温度ゲート(3090 Tiの命綱)
温度ゲート擬似コード(オーケストレータのカット投入ループに挟む)
-------------------------------------------------
def temp_gate():
core = nvsmi_core_temp() # nvidia-smiで取得
vram = hwinfo_vram_junction() # HWiNFO64の共有メモリ/ログから取得 [15]
if core >= 80 or vram >= 92: # 手前で予防的に休む
cooldown(seconds=90) # ファン全開で90秒待機
if core >= 83 or vram >= 95: # throttle/劣化ライン [15]
cooldown(seconds=300) # 5分しっかり冷ます
log("THERMAL throttle guard fired")
# 各カット投入前に temp_gate() を必ず呼ぶ → 熱暴走と長期劣化を防止
| センサ | 注意ライン | 停止ライン | 取得法 |
| GPUコア温度 | 80℃ | 83℃(throttle)[15] | nvidia-smi --query-gpu=temperature.gpu |
| GDDR6X junction | 92℃ | 95℃(長期劣化/throttle)[15] | HWiNFO64(nvidia-smiでは読めない)[15] |
長時間断片化対策:数千枚ごとにComfyUIを
計画的に再起動(プロアクティブ・リサイクル)してVRAM断片化とドライバ状態を定期リフレッシュ。expandable_segmentsはcuda-malloc無効と排他なので本機では使わず、
定期リサイクルで代替する
[12]。
5. 収益試算(稼働率 → 枚数 → 価値)
| シナリオ | 実効稼働率 | 枚数/日 | 月産 | 備考 |
| ハードニング前(事故あり) | 40〜55% | ~5,000 | ~15万 | 1日1回wedge+PC再起動で数時間ロス |
| ハードニング後(本DR適用) | 80〜90% | ~11,000 | ~33万 | 番犬で無人復旧・PC再起動ほぼ無し |
効果の本質:本DRの価値は「速くする」ではなく
「止まらない・無人で復旧する」。同じGPUで実効稼働率を40%台→80%超に倍化=
実質GPUを1台増やしたのと同等。採用作のLoRA量産・CG集(500枚アセット等、実売実績あり
[REL3])の供給スピードが2倍になる。
6. リスク
- ドライバ再有効化中の瞬断:番犬がドライバを無効化→有効化する数秒間、他のGPU処理(あれば)も巻き込む。→ 必ず全CUDAプロセスkill後に実行(実装済)。
- 番犬の誤検知でhealthyジョブをkill:WEDGE_SEC短すぎると重いHiresを誤爆。→ 120sに緩め、温度・I/O中は除外。
- stale lock奪取の取り違え:PID生存+タイムスタンプの二重判定で誤奪取を防止(実装済)。
- GDDR6X劣化(不可逆):95℃超運用の常態化はメモリ寿命を縮める[15]。温度ゲート必須。サーマルパッド交換も中期検討。
- R18データの外部送信:本DRの監視/復旧は全てローカル完結。nvidia-smi/HWiNFO/PowerShellは外部送信なし。法務上クリーン。
7. 30日プラン
| 週 | やること | 完了判定 |
| Day1 | gpu_lock.py導入・SBV2とComfyUIを排他化/persistence mode ON/起動フラグ確定/Manager自動更新OFF | 音声・画像が同時起動しない。Manager offline化確認 |
| Day2-3 | gpu_wedge_watchdog.py常駐(Start-Process detached+タスクスケジューラ番犬)/無再起動リセット動作テスト | 意図的にwedge再現→無人で復旧する |
| Day4-7 | 温度ゲート+HWiNFO64 VRAM温度連携/resume台帳(sqlite)実装 | 途中killしても二重生成せず再開 |
| Week2 | 3万枚の実バッチを無人で完走させ、wedge/温度/RAMのログを収集・閾値チューニング | PC再起動0回でバッチ完走 |
| Week3-4 | 定期リサイクル間隔の最適化・スループット最大化/番犬の復旧成功率を計測 | 実効稼働率80%超を3日連続で達成 |
8. 撤退ライン
- 番犬の無再起動リセットでも復旧率が80%未満が続く → ドライバを一旦クリーンインストール(DDU)し直す。それでもダメなら2枚目GPU物理分離へ投資判断。
- VRAM junctionが負荷時に常時95℃超でゲートが頻発しスループットが半減 → サーマルパッド交換/ケースエアフロー改善まで量産を一時縮小。
- wedgeが「音声非同時でも」起きる → 原因はGPU共有でなくドライバ/ハード固有。NVIDIAドライバを既知安定版へ固定(最新追従をやめる)。
9. 落とし穴(先に踏んでおく)
- 「torchをDGすれば直る」と思い込む → wedgeはドライバ層。torchバージョンは無関係(本日実証済)。プロセス/ドライバを疑え。
- 生成中にメモリ番人がモデルをunload → ネオン色破綻の主因。生成中unload厳禁(既存DR[REL])。
- cuda-malloc無効 と expandable_segments を同時に入れる → 排他。両立しない[4][12]。本機はmalloc無効を優先。
- ComfyUIを2本起動 → RAM枯渇でPC全体クラッシュ。起動前に
curl 127.0.0.1:8188/queueで既存確認(既存ルール[REL4])。
- nvidia-smi -r がGeForceで効くと期待 → 効かない[3][17]。ドライバ再有効化を使う。
- VRAM温度を見ずにコア温度だけ監視 → 3090Tiの本当の危険はGDDR6X。nvidia-smiでは見えない[15]。HWiNFO必須。
- WDDM TDRを無効化(レジストリTdrLevel=0)してしまう → ハング時にOSが自己回復できず完全フリーズになり悪化しうる[8][9]。TDRは切らず、番犬で上位から復旧する設計が正解。
- custom node全部盛りのまま量産 → 1個のハングノードでバッチ全体が固着。本番はホワイトリスト最小構成[5]。
10. 既存資産活用
_mem_guard_2026-05-22.py:RAM番人。§4-4の「生成中unloadしない」ガードを追加して流用。
_cc1_supervisor(タスクスケジューラ5分番犬):新設のgpu_wedge_watchdogも同じ枠で常駐・自動復活させる[REL2]。
- GOLDEN量産ドライバ
_prod_plain_golden_2026-05-22.py:カット投入ループに temp_gate() と resume台帳を挿し込むだけで本DR準拠になる。
- SBV2推論
_cc1_voice_synth_2026-06-11.py:先頭に gpu_lock.acquire("sbv2")/末尾 release() を追加して時間分割対応。
- 品質ゲート
gate.json 運用:温度ゲートのログも同フォルダ D:\projects\fanza3_mass\gates\ に集約し稼働率KPIを可視化。
11. 関連DR一覧
| DR | 関係 |
DR_ComfyUI安定運用RAM最適化_2026-06-09.html[REL] | RAM/VRAM・生成中unload事故の前提。本DRはCUDA wedge層を新規に追加 |
DR_ComfyUI_GOLDEN量産WF_決定版_2026-06-01.html | 量産WF本体。温度ゲート/resumeを本DRで補強 |
DR_ComfyUI全自動画像量産パイプライン_API運用効率化_2026-06-09.html | API運用。番犬/ロックを本DRで上乗せ |
DR_ComfyUI量産自動化品質ゲート効率化_2026-06-11.html | 品質ゲート。稼働率KPIと統合 |
feedback_voice_sbv2_setup_solved_2026-06-11.md | SBV2環境。GPU時間分割の対象 |
feedback_no_second_comfyui_8189_crash_2026-06-10.md[REL4] | ComfyUI2本起動禁止。落とし穴章に反映 |
feedback_daemon_supervisor_compact_2026-06-11.md[REL2] | 常駐デーモン番犬の作法。本DRの番犬常駐に流用 |
12. 脚注(全URL・実在)
本DRはCC1がローカルで執筆。多段推論P0のためGrok下書きをスキップし、1次情報17本(WebSearch/WebFetch)を直接統合。全GPU監視・復旧手段はローカル完結でR18データの外部送信なし。出力: D:\市場調査資料\DR_ComfyUI長時間大量量産のGPU安定運用ハードニング_2026-06-12.html