ComfyUIの生成速度を比べるときは、workflow・model・ComfyUIのcommit・Driver・解像度・seedを固定します。初回Load（Cold）と2回目以降（Warm）を分け、起動ログの「Prompt executed in」秒数とnvidia-smiのPeak VRAMを同じ方法で記録してください。数値そのものより「同じ条件で取った記録か」が比較の価値を決めます。
情報確認日：2026年8月22日（日本時間）
結論：固定・分離・同一手法の3つを守れば比較になる
責任範囲
- 比較前に固定する条件を一覧にし、1回の測定で変えるのは1つだけにする
- Cold（model読み込み込み）とWarm（読み込み済み）を別の行として記録する
- 生成時間はComfyUIのログ「Prompt executed in」を正とし、Queue待ちは別に扱う
- Peak VRAMは
nvidia-smiの定期取得など、全測定で同じ方法を使う - 速度と画像品質は別の列にし、「速い＝良い」としない
- stepsやsamplerの意味はKSamplerの理解、VRAMが足りないときの対処はVRAM不足の切り分けに任せる
固定する条件は何か
「同じworkflowを動かした」だけでは比較になりません。生成時間に効く変数は、workflowの外側にも多くあります。測定の前に次を書き留め、比較対象の間で1つだけを変えます。
| 固定する条件 | 確認方法 | 変わると何に効くか |
|---|---|---|
| workflow（API形式JSON） | ファイルのhashを記録 | node構成・steps・CFG・samplerすべて |
| model（checkpoint・VAE・LoRA） | ファイル名とhash | Load時間・VRAM・1step当たりの時間 |
| ComfyUIのcommit | git rev-parse HEAD |
実行エンジンの最適化・memory管理 |
| torch・CUDAのversion | python -c "import torch; print(torch.__version__)" |
カーネルの速度 |
| GPU Driver | nvidia-smiの表示 |
速度とVRAMの見え方 |
| 解像度・batch size | workflow内の値 | VRAMと時間に直接効く |
| seed | 固定値を記録 | 出力画像の一致確認に使う |
| 起動フラグ | --lowvram・--highvram・--reserve-vram等 |
model のoffload挙動 |
| 同時に動いているもの | ブラウザのタブ、他のGPUプロセス | VRAMの空きと速度 |
workflowのhashを取るのは、UI上で「同じに見える」workflowでも、widgetの値が1つ違えば別物だからです。API形式で書き出したJSONを測定ごとに保存しておけば、後から差分で確認できます。
ColdとWarmをなぜ分けるか
ComfyUIは、既定ではmodelを使い終えるとCPU memoryへ退避し、必要になったら再びGPUへ戻す動きをします（--highvramのhelp文に「既定ではmodelは使用後にCPU memoryへunloadされる」と書かれています）。さらに初回は、ディスクからmodelを読む時間も含まれます。つまり同じworkflowでも、1回目と2回目以降は測っているものが違います。
Cold（初回）
- ComfyUI起動直後、またはmodelを切り替えた直後
- ディスク読み込み＋GPUへの転送＋生成
- ストレージの速度とRAM容量が効く
- 1回だけ記録する
Warm（2回目以降）
- 同じmodelで続けて実行
- 生成そのものの時間に近い
- GPUの計算速度が効く
- 3回記録し、中央値を代表値にする
Warmを3回取って中央値を使うのは、1回だけだとOSや他プロセスの影響を拾うためです。平均ではなく中央値にするのは、1回だけ極端に遅い値が混ざっても代表値が引きずられにくいからです。Coldは条件が作りにくいので、1回として扱い、Warmと同じ行に並べません。
生成時間をどう測るか
もっとも信頼できる値は、ComfyUI自身が出すログです。prompt実行が終わると、コンソールにPrompt executed in X.XX secondsのような行が出ます。これはComfyUIがtime.perf_counter()で測った実行時間で、Queueで待っていた時間は含みません（600秒を超えると時:分:秒の表記になります）。
got prompt
...
Prompt executed in X.XX seconds ← この値を「生成時間」として記録するブラウザのストップウォッチや体感で測らない理由は、Queue待ち・UIの描画・画像のプレビュー転送が混ざるからです。「送信してから画像が出るまで」を測りたい場合は別の指標なので、分けて記録します。
| 指標 | 取り方 | 含まれるもの |
|---|---|---|
| 実行時間（正） | ログの「Prompt executed in」 | node実行のみ。Queue待ちを含まない |
| 往復時間 | POST /prompt送信からGET /history/{prompt_id}に結果が載るまでを自分のスクリプトで計測 |
Queue待ち＋実行＋保存 |
| Queue待ち | 往復時間 − 実行時間 | 前のjobの残り・サーバーの空き |
比較に使うのは「実行時間」です。往復時間は、Queueに他のjobが残っていないことを確認したうえで参考値として残します。Queueの状態はGET /queueで確認できます。
秒／枚に直すときは、実行時間をbatch sizeで割ります。batch 4で20秒なら5秒／枚ですが、batch 1で4回回した合計とは一致しません。batch sizeも固定条件に含めてください。
Peak VRAMをどう取るか
VRAMは「どの瞬間を見たか」で値が変わります。生成中のピークを取るには、実行中に一定間隔で使用量を記録し、その最大値をPeakとします。方法は何でも構いませんが、全測定で同じ方法・同じ間隔にすることが条件です。
# 別ターミナルで、生成の前に開始し、終わったら Ctrl+C
nvidia-smi --query-gpu=timestamp,memory.used,memory.total \
--format=csv -l 1 > vram_run01.csv# CSV から最大値を取る（ヘッダー行を除く）
tail -n +2 vram_run01.csv | awk -F', ' '{gsub(/ MiB/,"",$2); if($2>m)m=$2} END{print m" MiB"}'1秒間隔では、1秒未満の短いピークを取りこぼす可能性があります。間隔を縮めれば精度は上がりますが、その分CSVが増えます。大事なのは精度の絶対値ではなく、比較する測定の間で間隔を揃えることです。
またnvidia-smiのmemory.usedはGPU全体の使用量で、ブラウザやデスクトップの分も含みます。測定前に「ComfyUIを起動しただけ」の状態の値を記録し、ベースラインとして一緒に残してください。
品質と速度をなぜ分けるか
速度の測定で最も起きやすい誤りは、「速くなった設定」をそのまま「良い設定」と読むことです。stepsを減らせば速くなりますし、解像度を下げれば速くなります。それが目的の画像として許容できるかは、別の評価です。
対策は単純で、記録表に「品質」の列を速度とは別に持ち、人が見て判定した結果を書くことです。判定を数値化したい場合も、「同一seedで基準画像と比べて、破綻・ぼけ・指示との不一致があるか」のように、見る観点を先に決めてから記入します。
| 列 | 何を書くか | 書かないこと |
|---|---|---|
| 実行時間（秒） | ログの値 | 体感・概算 |
| Peak VRAM | 同一手法の最大値 | 別の方法で取った値の混在 |
| 品質判定 | 基準画像との比較結果（人の判断） | 速度からの推測 |
| 採用可否 | 速度と品質の両方を見た結論 | 片方だけの結論 |
同一seedで出力を並べると、設定変更で画像がどう変わったかを目で確認できます。seedを固定しても完全に同じ画像にならない条件は別記事で扱っていますが、比較の出発点としては十分です。
再利用できる記録はどう残すか
記録はCSVにします。表計算ソフトでも、後からスクリプトで集計するときでも扱えるからです。1行が1回の実行で、固定条件の列と測定値の列を分けます。
run_id,date,phase,workflow_hash,model,comfy_commit,torch,driver,gpu,width,height,batch,steps,seed,flags,exec_seconds,roundtrip_seconds,peak_vram_mib,baseline_vram_mib,quality,note
01,2026-09-19,cold,abc123,sdxl_base.safetensors,0123abc,X.Y.Z+cu130,580.xx,RTX XXXX,1024,1024,1,25,12345,"",,,,,,
02,2026-09-19,warm,abc123,sdxl_base.safetensors,0123abc,X.Y.Z+cu130,580.xx,RTX XXXX,1024,1024,1,25,12345,"",,,,,,
03,2026-09-19,warm,abc123,sdxl_base.safetensors,0123abc,X.Y.Z+cu130,580.xx,RTX XXXX,1024,1024,1,25,12345,"",,,,,,
04,2026-09-19,warm,abc123,sdxl_base.safetensors,0123abc,X.Y.Z+cu130,580.xx,RTX XXXX,1024,1024,1,25,12345,"",,,,,,値の列（exec_seconds以降）は空欄にしてあります。固定条件の列の値は例で、自分の環境の値に置き換えてください。
Cold 1回＋Warm 3回の記録表
最初の測定は次の4行で足ります。Warm 3回の中央値をexec_secondsの代表値、Peak VRAMの最大値を代表値として別欄に書きます。
| run | phase | 実行時間（秒） | 往復時間（秒） | Peak VRAM（MiB） | 品質判定 |
|---|---|---|---|---|---|
| 01 | cold | ||||
| 02 | warm | ||||
| 03 | warm | ||||
| 04 | warm | ||||
| 代表値 | warm中央値 / Peak最大 | — | — |
見るべきことは3つです。Coldが極端に長ければストレージかRAMの問題、Warm 3回のばらつきが大きければ他プロセスの干渉、Peak VRAMがmemory.totalに近ければ次の解像度で足りなくなる兆候です。条件を1つ変えて同じ4行を取り、CSVに追記していけば、そのまま比較表になります。
出力PNGにはworkflowとpromptが埋め込まれるので、run_idと画像ファイル名を対応させて保存しておくと、条件の証跡にもなります。
よくある質問
it/sの表示を記録すればよいのではありませんか？
sampler進行中の表示はsamplingの速度だけを示し、text encode・VAE decode・保存を含みません。workflow全体の比較には「Prompt executed in」を使い、it/sはsamplerだけを比較したいときの補助にしてください。
他の人の測定結果と比べてもよいですか？
固定条件の列がすべて一致しない限り、差の原因を特定できません。参考にはなりますが、自分の環境で同じworkflowを回した記録と置き換えることはできません。
Coldを何度も測るにはどうしますか？
ComfyUIを再起動するのが確実です。modelを切り替えてから戻す方法もありますが、OSのファイルキャッシュにmodelが残るため、完全なColdにはなりません。再起動でも同じ影響があるので、「どう作ったCold条件か」をnote列に書いておきます。
まとめ
ComfyUIの生成速度の比較は、固定条件の一覧、ColdとWarmの分離、同一手法での測定の3つで成り立ちます。生成時間はログの「Prompt executed in」、Peak VRAMはnvidia-smiの定期取得の最大値、品質は人の判定を別の列に書きます。
Cold 1回＋Warm 3回をCSVに残し、条件を1つ変えて同じ4行を追記します。この繰り返しが、自分の環境で信頼できる唯一の比較表になります。動画生成の測定も同じ型で扱えますが、frame数という軸が増えるため別記事で続けます。