RTX 3090（VRAM 24GB）環境におけるR18 99キャラ・数千枚規模の無人量産において、PCフリーズを引き起こす最大のボトルネックはVRAMではなく「システムRAM（メインメモリ）のリークと過剰コミット」である。この致命的課題を打破し、24/7無人運転を完遂するための最重要5原則を以下に定義する。
--cache-classic は、一度ロードしたモデルや中間テンソルを自動退避せず物理RAMに保持し続ける[14]。長時間運転ではRAMリークを加速させる主因となるため、--cache-lru 1 または --cache-none への移行が必須である[14]。POST /api/free を叩き、VRAMと実行キャッシュを強制解放させる[1][6]。model_management.py）は、安全マージンとして実使用量の最大67%過剰に仮想メモリをコミットする[5]。実RAMが空いていても、Pagefileが不足するとWindowsは即座にOOM（Out of Memory）クラッシュやPCフリーズを引き起こす[5]。_mem_guard_2026-05-22.py による EmptyWorkingSet（物理メモリの強制OS回収）と、_gpu_guard_2026-05-30.py による温度閾値監視、およびNSSM等を用いたプロセス自動再起動の3点セットが、無人運転の生命線となる[15]。python main.py --cache-lru 1 --reserve-vram 2.0 --disable-smart-memorynvidia-smi -pl 280 および nvidia-smi -pm 1 を実行[11]。MAX_Q=4（読者最適化済）を維持し、50枚ごとに POST /api/free を発行[1][6]。RTX 3090は24GBの大容量VRAMを搭載しているため、一見するとSDXLやFluxなどの巨大なモデルを用いた99キャラ量産でも余裕があるように見える。しかし、数千枚規模の無人運転において、システムはVRAMではなくシステムRAM（メインメモリ）の枯渇によって100%停止する。この崩壊メカニズムは、以下の4つの複合要因によって発生する。
【ComfyUI 長時間運転時のメモリ崩壊スパイラル】
[Image Batchの連続実行]
│
▼ (システムRAMリーク: 1回あたり約10GBのコミット増 [4])
[物理RAMの枯渇] ──(キャッシュがRAMに累積 [14])
│
▼ (model_management.py による67%過剰コミット [5])
[仮想メモリ(Pagefile)不足]
│
▼ (OSがメモリ要求を拒絶)
[PC全体のフリーズ / Pythonプロセスの強制終了 (OOM Kill)]ComfyUIでImage Batch（画像生成およびポスト処理）を繰り返すと、カスタムノードをすべて無効化したコア機能のみの環境であっても、1回（1バッチ）あたり約10GBのコミットRAM（仮想メモリ領域）が増加し、処理が終了してもOSに解放されない致命的な挙動が確認されている[4]。これはPyTorchのテンソルキャッシュや、ComfyUI内部の実行履歴（Execution Cache）がメモリ上に残留し続けることが原因である。対策を講じない場合、200〜300枚の生成で64GBの物理RAMすら完全に使い果たされる[6]。
ComfyUIのモデル管理機構（model_management.py）には、メモリ不足によるクラッシュを防ぐために「10%の安全マージン」がハードコードされている。しかし、大容量システムRAM（64GB以上）環境においてはこのマージン計算が異常にスケールし、実際の物理RAM使用量が45GB程度であるにもかかわらず、OSに対して75GB以上の仮想メモリ（Commit Charge）を要求する（約67%の過剰コミット）[5]。この時、Windowsのページファイル設定が「自動（デフォルト）」または「低すぎる値」に設定されていると、物理RAMに空きがある状態でもOSがメモリ確保要求を拒絶し、システム全体が沈黙（フリーズ）する[5]。
ComfyUIは、VRAM（24GB）に収まらないモデル（LoRAの複数同時適用、ControlNet、FaceDetailer用検出モデルなど）をシステムRAMに一時的に退避（オフロード）させる。この双方向転送が繰り返される過程で、Pythonのガベージコレクション（gc.collect()）が追いつかず、メモリの断片化（Fragmentation）が発生する。結果として、実質的な空き容量があるにもかかわらず、連続したメモリブロックが確保できなくなりOOMクラッシュを引き起こす。
RTX 3090のGPUダイは83℃に達するとサーマルスロットリング（強制クロック低下）が発生する[9]。さらに深刻なのは、基板裏面に配置されたGDDR6X VRAMチップの温度である。VRAMジャンクション温度が92℃を超えるとメモリコントローラの保護機能が働き、描画パフォーマンスが劇的に低下する[10]。100℃を超えた状態（Linux環境などではツールで可視化されにくく、数週間放置される事例が多発[10]）で動作を続けると、ドライバがクラッシュし、Windowsでは「ビデオドライバのリセット」に伴うComfyUIプロセスの切断、最悪の場合はブルースクリーン（BSoD）を誘発する。
無人量産においてシステムRAMの破綻を防ぐため、ComfyUIの起動フラグおよびOSの仮想メモリ設定を極限まで最適化する。
ComfyUIの挙動を制御する主要な起動フラグの特性を以下に整理する。
| 起動フラグ | VRAM消費 | システムRAM消費 | 生成速度（スループット） | 長時間運転時の安定性 | 概要・推奨ユースケース |
|---|---|---|---|---|---|
--cache-classic | 極大 | 極大 | 最高 (キャッシュ時) | 最低 (リーク直行) [14] | 旧デフォルト。キャッシュを無限に保持。24/7運用では絶対に使用禁止[14]。 |
--cache-lru N | 中 | 中 | 高 | 高 (推奨) [14] | 指定したN個のモデルのみRAMにキャッシュ。RTX 3090環境では N=1 が最適値[14]。 |
--cache-none | 最小 | 最小 | 低 (毎回ロード) | 最高 [14] | キャッシュを一切行わない。速度は低下するが、RAMリークを物理的に最小化する[14]。 |
--disable-smart-memory | 低 | 中 | 中 | 高 [13] | VRAM内にモデルを常駐させず、実行後に能動的にRAMへオフロードする[13]。 |
--reserve-vram N | 制限 | - | 影響極小 | 高 [13] | OSやブラウザ表示用にN GBのVRAMを強制的に除外。RTX 3090では 2.0（2GB）を推奨[13]。 |
--lowvram | 極小 | 高 | 最低 (分割実行) | 中 [13] | UNetを分割してロード。24GB VRAMを持つRTX 3090では速度低下が著しいため非推奨[13]。 |
読者の既存資産である「起動3点セット」のComfyUI起動部を、以下のパラメータに書き換える。
python main.py --cache-lru 1 --reserve-vram 2.0 --disable-smart-memory --cuda-malloc--cache-lru 1： キャッシュ対象を現在実行中の1スロットのみに制限し、過去のLoRAやCheckPointがRAMに死蔵されるのを防ぐ[14]。--reserve-vram 2.0： VRAMの最大使用可能枠を22GBに制限。WindowsのDWM（Desktop Window Manager）や監視スクリプト（_gpu_guard_2026-05-30.py）が使用するVRAM領域を確保し、OS巻き込み型のフリーズを防止する[13]。--disable-smart-memory： PyTorchの自動VRAM管理を無効化し、不要になったテンソルを即座にシステムRAMへ退避・解放させる[13]。--cuda-malloc： PyTorch標準のメモリ割り当て器の代わりにCUDA Caching Allocatorを最適化し、VRAMの断片化を抑制する[17]。Issue #8298（過剰コミット問題）に対処するため、Windowsの「システム管理のサイズ」を廃止し、手動で巨大なページファイルを固定確保する[5]。
sysdm.cpl（システムのプロパティ）を起動。...\<vol>_v160\）が配置されている高速SSD（NVMe推奨）を選択。65536 MB (64GB)131072 MB (128GB)どれだけ起動オプションを最適化しても、PythonおよびPyTorchの仕様上、数千枚の連続生成における微小なリークは避けられない。したがって、「定期的な能動的メモリ解放」と「プロセスの定時クリーン再起動」を組み合わせた運用設計が必須となる。
ComfyUIには、VRAM上のモデルデータをシステムRAMへ退避させ、実行キャッシュ（Execution Cache）を強制解放するAPIエンドポイント POST /api/free が標準実装されている[1]。
_prod_plain_golden_2026-05-22.py のループ処理内において、「50枚生成ごと」に以下のHTTPリクエストを非同期で発行する[6]。import requests
def force_unload_comfy():
try:
# unload_models=True: VRAMからRAMへ退避
# free_memory=True: PyTorchのキャッシュおよびExecution Cacheの解放
response = requests.post(
"http://127.0.0.1:8188/api/free",
json={"unload_models": True, "free_memory": True},
timeout=15
)
if response.status_code == 200:
print("[INFO] ComfyUI VRAM/RAM successfully flushed via API.")
else:
print(f"[WARN] /api/free failed with status: {response.status_code}")
except Exception as e:
print(f"[ERROR] Failed to connect to ComfyUI API: {e}")API経由の制御に加え、複雑なR18キャラ生成ワークフロー（FaceDetailerや複数LoRAを多重適用するタスク）の末尾に、以下のカスタムノードを挿入して自己完結型の解放を行う。
ワークフローの最終出力（Save Image等）の直前にこのノードを接続することで、1ジョブ終了ごとに自動でPyTorchのガベージコレクションを呼び出す。
このカスタムノードは、内部で以下のPythonコードを連続実行する[3]。
import gc
import torch
import comfy.model_management
comfy.model_management.unload_all_models() # 全モデルをVRAMからアンロード
comfy.model_management.soft_empty_cache() # ComfyUI管理下のキャッシュクリア
torch.cuda.empty_cache() # PyTorchのCUDAキャッシュ解放
gc.collect() # Pythonのガベージコレクション強制実行これをキャラ切り替え（99キャラの遷移時）のプロンプト送信直前に実行することで、前キャラのLoRAやControlNetがVRAM/RAMに残留するのを完全に防ぐ。
メモリリークを根治する唯一の方法は、「プロセスの再起動」である[4]。無人運転においては、以下のスケジュールでComfyUIプロセスを完全にKillし、再起動する設計を導入する。
_mem_guard_2026-05-22.py の緊急閾値である 6GB未満 に低下し、EmptyWorkingSet（メモリトリム）を実行しても10GB以上に回復しない場合。後述する「NSSM」または「ComfyUI-Watchdog」を介し、API経由でComfyUIを正常終了（またはタスクキル）させ、即座にクリーンな状態で再起動する[15]。
RTX 3090の24GB VRAMを最大限に活かしつつ、クラッシュ率を極小化するためのバッチサイズとジョブ分割の最適解を提示する。
batch_size = 4 〜 8 [6]batch_size = 1 を繰り返すよりも、PyTorchの並列演算効率が向上し、1枚あたりの生成時間は短縮される。しかし、SDXL環境において batch_size = 8 を超えると、FaceDetailer等のアップスケーラーが起動した瞬間にVRAMが瞬間的にスパイクし、OOM（Out of Memory）を誘発する[6]。| 物理バッチサイズ | 1枚あたり生成速度 | VRAM使用ピーク | 24/7無人運転における安定性 | 推奨度・用途 |
|---|---|---|---|---|
1 | 遅い (1.0x) | 最小 (~10GB) | 最高 (クラッシュ皆無) | △ (効率が悪く量産に不向き) |
4 | 速い (1.4x) | 中 (~16GB) | 極めて高い | ◎ (SDXL量産の黄金値) |
8 | 極めて速い (1.6x) | 高 (~21GB) | 高 (FaceDetailer併用時は注意) | ○ (シンプルなプロンプト用) |
16 | 最速 (1.7x) | 極大 (24GB超) | 極めて低い (即OOM) | × (無人運転では絶対禁止) |
99キャラ×100枚＝計9,900枚の量産タスクを実行する場合、単一の巨大なキューとしてComfyUIに投入してはならない。ネイティブのキュー管理システムは50〜100枚を超えるとメモリ消費が指数関数的に増加しクラッシュする[6]。
batch_size = 4 × 4回リピート ＝ 16枚 に制限する。_prod_plain_golden_2026-05-22.py 側でループ管理し、2,000〜3,000枚のまとまりで一度プロセス全体を再起動する[6]。RTX 3090 (24GB) における、解像度ごとの安全なバッチサイズ上限値：
batch_size = 8 まで安全。batch_size = 4 に制限。batch_size = 2 に制限。24時間365日フルロードでグラフィックボードを酷使するローカル量産環境において、ハードウェアの寿命保護とサーマルスロットリングによる速度低下防止は最優先課題である。
RTX 3090の定格消費電力は350W（モデルによっては370W以上）であり、これをそのまま無人運転に使用するのは極めて危険である。電力を 80%（280W） に制限することを強く推奨する[11]。
Windows環境において、ComfyUI起動前に必ず以下のコマンドを管理者権限のPowerShellで実行する。読者の「起動3点セット」のバッチファイル先頭に組み込むこと。
# 1. 永続化モード(Persistence Mode)を有効化 (GPUドライバを常時メモリにロードし、設定を安定化)
nvidia-smi -pm 1
# 2. 電力制限を 280W に設定 (RTX 3090の定格350Wに対する80%制限)
nvidia-smi -pl 280Windowsでは再起動ごとにPower Limitがデフォルト（350W）にリセットされる[12]。これを防ぐため、Windowsのタスクスケジューラに「システム起動時」トリガーで上記コマンドを実行するタスクを登録するか、読者の _gpu_guard_2026-05-30.py の初期化処理に以下のPythonコードを組み込み、起動時に自動適用させる[11][12]。
import subprocess
def apply_gpu_power_limit():
try:
# Persistence Mode ON
subprocess.run(["nvidia-smi", "-pm", "1"], check=True)
# Power Limit 280W
subprocess.run(["nvidia-smi", "-pl", "280"], check=True)
print("[INFO] GPU Power Limit set to 280W successfully.")
except Exception as e:
print(f"[ERROR] Failed to apply GPU limit: {e}")Linux環境とは異なり、Windows環境では HWiNFO64（Shared Memory有効化設定）を使用することで、PythonからVRAMジャンクション温度（GPU Memory Junction Temperature）を直接取得可能である[10]。読者の _gpu_guard_2026-05-30.py は、このVRAMジャンクション温度を監視対象に加え、「92℃」を警告ライン、「95℃」を緊急冷却（生成一時停止・ファン速度最大化）の閾値として再定義すべきである[10]。
ComfyUIのブラウザUI（WebUI）は、大量の画像を表示・保持するため、ブラウザ側のメモリリークを誘発しPCフリーズの原因となる。無人量産においては、WebUIを一切開かず、API経由でバックグラウンド制御するのが鉄則である。
外部の量産ドライバ（_prod_plain_golden_2026-05-22.py）からComfyUIを制御するために、以下のAPIを使用する[8]。
POST /prompt： ワークフローのJSONデータを送信し、生成キューにジョブを追加する[8]。成否判定として prompt_id が返却される[8]。WS /ws (WebSocket)： ComfyUIサーバーとの双方向通信を確立し、現在の実行ノード（executing）や、生成完了（executed）のイベントをリアルタイムで受信する[8]。GET /history/<prompt_id>： 生成完了後に呼び出し、出力された画像ファイル名やエラーログを取得する[8]。ComfyUIの内部キュー（Queue）に100枚以上のジョブを一度にスタックしてはならない[6]。キューが溜まるほど、ComfyUIはメモリ上にオブジェクトを保持し続け、リーク率が加速する[6]。
...\<vol>_v160\）を記述した CSVまたはJSONの構成リスト を外部に用意する。GET /queue で監視する。MAX_Q = 4（読者最適化済）を上限とし、キューの空きができた分だけ POST /prompt で新規ジョブを1件ずつ補充する[6]。これにより、ComfyUI内部のキューは常に最小限に保たれ、メモリ消費がフラットに維持される[6]。無人運転中にPCが強制終了した場合でも、生成済みのデータを無駄にせず即座に再開できる仕組みを量産ドライバに実装する[6]。
...\ComfyUI\output\...\<vol>_v160\）に保存されたファイル群を走査し、既に生成が完了している「キャラID + 連番」を特定する[6]。24/7の無人運転において、「絶対にクラッシュしないシステム」を作ることは不可能に近い。重要なのは、「クラッシュしたことを即座に検知し、120秒以内に自動でプロセスを再起動して量産を再開する自己修復システム」の構築である。
ComfyUIをバッチファイルから直接起動する方式は、エラー発生時にプロンプトウィンドウが閉じずにフリーズしたまま残るリスクがある。
ComfyUIをWindowsのバックグラウンドサービスとして登録する。NSSMはプロセスが異常終了（クラッシュ、OOM Kill、手動タスクキル）した際、ミリ秒単位で自動再起動をかける機能を備えている。
HTTPのヘルスチェック（http://127.0.0.1:8188/history への定期リクエスト）を行い、応答が120秒以上途絶えた場合、またはステータスコード500が返ってきた場合に、ComfyUIプロセスを強制終了させて再起動する[6][15]。
単純な即時再起動ループは、設定エラー（モデルファイルが見つからない、VRAM温度が下がらない等）が発生した際に、無限再起動スパイラルに陥りハードウェアに致命的な負荷をかける。これを防ぐため、以下の自律制御ロジックを監視スクリプトに組み込む。
クラッシュ後の再起動待機時間を、1回目：10秒、2回目：30秒、3回目：120秒と段階的に引き上げる[6]。
15分以内に 3回以上 のクラッシュ・再起動が発生した場合、システムに致命的な異常（物理RAM物理故障、SSD切断、ドライバ破損など）が発生したと判断し、量産ドライバのキュー処理を完全停止（回路遮断）し、管理者へDiscord Webhook等で緊急通知を送信してプロセスを安全に休止させる[6]。
# サーキットブレーカーの簡易ロジック例
import time
import sys
class CircuitBreaker:
def __init__(self, max_failures=3, reset_window=900):
self.max_failures = max_failures
self.reset_window = reset_window
self.failures = []
def record_failure(self):
now = time.time()
# 期限切れの古いエラー履歴を排除
self.failures = [f for f in self.failures if now - f < self.reset_window]
self.failures.append(now)
if len(self.failures) >= self.max_failures:
print("[CRITICAL] Circuit Breaker Triggered! Too many failures. Halting process.")
# 管理者通知APIの呼び出しなどをここに実装
sys.exit(1) # スクリプトを完全停止読者の既存資産である _mem_guard_2026-05-22.py と _gpu_guard_2026-05-30.py を統合・拡張し、無人運転を鉄壁にするための「監視マトリクス」を定義する。監視間隔は 30秒に1回 を維持する。
| 監視対象オブジェクト | 正常範囲 | 警告ライン (WARN) | 緊急アクションライン (CRITICAL) | 実行される自動処理 |
|---|---|---|---|---|
| システムRAM空き容量 | >12 GB | < 9 GB | < 6 GB | WARN: POST /api/free 発行[1]。CRITICAL: EmptyWorkingSet（メモリトリム）強制実行 ＋ 新規キュー投入の一時停止。 |
| VRAM使用率 | <85 % | > 90 % | > 95 % | CRITICAL: 現在のジョブ完了後に unload_all_models 実行[3]。 |
| GPUダイ温度 | <75 ℃ | > 83 ℃ [9] | > 85 ℃ | WARN: 警告ログ記録。 CRITICAL: 連続2回検出で生成を60秒間強制スリープ、ファン速度最大化[9]。 |
| VRAMジャンクション温度 | <88 ℃ | > 90 ℃ [10] | > 92 ℃ [10] | WARN: 警告ログ。 CRITICAL: nvidia-smi -pl 250 へ一時的に電力をさらに絞り、冷却を優先[11]。 |
| キュー滞留時間 (1枚あたり) | <40 秒 | > 120 秒 [6] | > 180 秒 | CRITICAL: フリーズと判定。ComfyUIプロセスをタスクキルし、自動再起動シーケンスへ移行[6]。 |
| 出力画像整合性 | 正常画像 | - | Black/White/ファイルサイズ異常 [6] | CRITICAL: 生成された画像が「真っ黒（NaN）」または「真っ白」、あるいはファイルサイズが1KB以下の場合、異常終了とみなして該当ジョブを再実行キューに戻す[6]。 |
読者の _mem_guard は、空きメモリが6GB未満になった際に EmptyWorkingSet を呼び出し、物理メモリを13.8GBまで回復させる極めて実用的なロジックを既に有している。これに以下の改良を加えることで、さらに堅牢性が向上する。
EmptyWorkingSet はWindowsのワーキングセットをページファイルに強制退避させるため、一時的に物理RAMの数値は回復するが、再度アクセスが発生するとディスクI/Oスパイクが発生する。したがって、この処理が「同一セッション内で3回」実行された場合は、メモリの断片化が限界に達しているとみなし、次のキャラ切り替えタイミングでComfyUIプロセスのクリーン再起動をスケジューリングする。
_gpu_guard が85℃を連続検出してモデル退避を行う際、_mem_guard に対しても「新規キュー送信のロック（一時停止）」を通知するプロセス間通信（IPC、または単純な共有フラグファイルの作成）を実装し、熱が下がるまでシステム全体を安全にアイドリングさせる。
量産運転中に発生する代表的なトラブル、その真因、および現場で即効性のある対処手順を以下にまとめる。
| 症状 | 推定される原因 | 即効対処手順・恒久対策 |
|---|---|---|
| 徐々にシステムRAMが増加し、最終的にOOMでプロセスが突然消滅する | ComfyUI内部のExecution CacheおよびPyTorchのテンソルキャッシュのリーク[4]。 | 1. 起動引数に --cache-lru 1 を追加[14]。2. 量産ドライバに50枚ごとの POST /api/free 送信を組み込む[1][6]。 |
| 200〜300枚生成した時点で、エラーも吐かずにComfyUIが完全停止する | ネイティブキューの過剰蓄積によるメモリ飽和、またはWebSocketの切断[6]。 | 1. ネイティブキューの使用を止め、外部ドライバから MAX_Q=4 で1件ずつ補充する方式へ移行[6]。2. 120秒タイムアウト監視を実装し、ハング時はプロセスを強制終了[6]。 |
| PC全体が激しくカクつく、または完全に画面がフリーズしてキー操作を受け付けない | 仮想メモリ（ページファイル）が不足し、OSのカーネル領域メモリが圧迫されている[5]。 | 1. Windowsのページファイルをカスタムサイズで「固定64GB〜128GB」に手動設定[5]。 2. --reserve-vram 2.0 を指定し、DWM（Windowsの描画エンジン）用のVRAMを死守する[13]。 |
| VRAM温度が100℃近くに達し、生成速度（It/s）が半分以下に低下する | RTX 3090の背面VRAMの過熱によるサーマルスロットリング[10]。 | 1. nvidia-smi -pl 280 を実行し、電力上限を280Wに制限する[11]。2. PCケースのサイドパネルを開放するか、バックプレートに120mmファンを直接配置して送風する。 |
| POST /api/free を実行しても、システムRAMが全く解放されない | --cache-classic フラグが有効なままであるか、カスタムノードがメモリを強固に参照保持している[14]。 | 1. 起動引数を --cache-none に変更し、キャッシュを物理的に禁止する[14]。2. ComfyUI-Unload-Model ノードをワークフロー末尾に挿入し、強制解放を試みる[3]。 |
| 再起動スクリプトが走るが、「Port 8188 is already in use」と出て再起動に失敗する | 前のComfyUI（Python）プロセスがゾンビ化し、ポートを掴んだまま生存している。 | 1. 再起動バッチの先頭に taskkill /f /im python.exe を挿入し、既存のPythonプロセスを完全に抹殺してから起動する。 |
無人量産システムを実戦投入し、30日間で「エラー率5%未満、24/7完全放置可能な黄金システム」へ昇華させるためのロードマップ、および撤退基準を策定する。
nvidia-smi -pl 280 -pm 1 をタスクスケジューラに登録し、電力制限を常時適用する[11][12]。--cache-lru 1 --reserve-vram 2.0 --disable-smart-memory に統一する[13][14]。_mem_guard_2026-05-22.py、_gpu_guard_2026-05-30.py、およびComfyUI本体を同時にバックグラウンド起動する「起動3点セット」を構築。_gpu_guard にVRAMジャンクション温度（92℃閾値）の監視ロジックを追加[10]。_prod_plain_golden_2026-05-22.py を改修。WebUIを使用せず、WebSocket経由の MAX_Q=4 制御へ移行。POST /api/free を自動発行するロジックを組み込む[1][6]。ComfyUI-Watchdog の導入[15]。以下の条件が2回以上発生した場合、ローカルRTX 3090での無人運転維持はコストパフォーマンス（時間的損失）の観点から破綻しているとみなし、RunPodやVast.aiなどのクラウドGPU環境（A100/H100/RTX 4090等）へ移行すべきである。
EmptyWorkingSet を適用しても、Windowsのシステム競合によりOS自体が1,000枚未満で確実にハングアップし、原因特定に3日以上を要する場合。--cache-classic のまま放置/free を叩いてもメモリは一切解放されず、200枚前後で確実にシステムRAMが破綻する[14]。無人運転を開始する前に、以下の15項目を上から順に確認し、すべてにチェックが入ることを確認せよ。
nvidia-smi -pl 280 が実行され、RTX 3090の電力が280W（または定格の80%）に制限されているか[11]。nvidia-smi -pm 1（Persistence Mode）が有効化されているか[11]。--cache-classic が含まれておらず、--cache-lru 1 または --cache-none が指定されているか[14]。--reserve-vram 2.0 が指定され、OS用のVRAMバッファが確保されているか[13]。_mem_guard_2026-05-22.py が起動しており、システムRAMが6GB未満になった際に EmptyWorkingSet を実行する準備ができているか。_gpu_guard_2026-05-30.py が起動しており、GPUダイ温度83℃以上で一時停止するロジックが機能しているか[9]。_gpu_guard の監視対象にVRAMジャンクション温度が追加され、92℃を警告上限として認識しているか[10]。_prod_plain_golden_2026-05-22.py の画像出力先（...\<vol>_v160\）のディスク空き容量が、数千枚の生成（1枚約2〜5MB）に対して十分（100GB以上）確保されているか。MAX_Q が 4 以下に制限されているか[6]。POST /api/free を発行するAPIコールが実装されているか[1][6]。