ComfyUIで使えるVRAMを絞ると画像・動画生成は遅くなるか｜ピークは測った全74組で下がるが、時間が増えたと言えたのは判定できた6構成のうち1つだけ

VRAMを絞ると待ち時間はどうなるか

このフラグは、ComfyUI がモデルに使ってよいVRAMを減らす向きに働く。載りきらない重みはGPUの外に置かれ、必要になった時点でPCIe経由でGPUへ転送される。空けたVRAMの代わりに何が起きるのかを、以下では所要時間・GPU全体のピーク・PCIe転送量の3つで見ていく。

ComfyUI に対して空けておくVRAM量の設定を 1.5GB から 12GB へ増やすと、GPU全体のサンプリングピークは測定した74組すべてで低下した。一方で、事前に決めた基準で生成時間の一貫した増加を検出できたのは、測った7構成のうち対応ブロックを6つそろえた6構成に限れば FLUX.2 Klein の1構成だけだった。残る Wan 2.2 は対応ブロックが1つしか取れず判定していないため、判定した構成は6つになる。残る5構成は「増加を検出できなかった」構成であって、差が無いことを確かめた構成ではない。

結果は非対称に読む。空けたい側 (ピークを下げたい) は74組すべてで効いており、目的が「OSや他のソフトにVRAMを残す」ことなら、下げる向きには例外なく働いた。ただし設定した量がそのまま空くわけではない。一方、待ち時間の代償が出るかどうかは判定できた6構成のうち1構成でしか検出できておらず、事前にどの構成で出るかをこのデータから読むことはできない。ただし出た構成では、この測定回の増減の中央値で +39.4% (起動後1本目)・+63.1% (続けて2本目) と、小さくない差だった。値そのものは測定回によって動く (後述)。判断に使えるのは「効果は測った範囲で例外なし、代償は検出できた構成と検出できなかった構成があり (どちらになるかが構成の性質だけで決まるとは言えない)、検出できたときは無視できない大きさ」までである。

何をどう測ったか

測定に使ったのは RTX 5080 16GB (16303 MiB) 1枚とシステムRAM 96GB の環境で、変えたのは ComfyUI の --reserve-vram の設定値だけである。設定値は 1.5GB と 12GB の2条件。ComfyUI は v0.31.1 (commit fe4195f7)、PyTorch は 2.9.1+cu128 で、起動ログに DynamicVRAM support detected and enabled と comfy-aimdo 0.4.13 の初期化が出ていることを確認している。--vram-headroom は既定の 0 のままである。起動フラグは全ブロック共通で --bf16-unet / --bf16-text-enc / --preview-method none を付けており、ブロック間で変えたのは設定値だけになる。使った重みのうち唯一の GGUF は flux-2-klein-9b-Q8_0.gguf (9,978,304,800 バイト) で、ファイル内に配布元の記録が無いため同定はファイル名とサイズによる。このフラグは公式の起動フラグ一覧で「OSや他のソフトが使うために確保しておくVRAM量をGB単位で指定する」ものと書かれており、使用量に上限を掛ける仕組みとしては記載されていない。フラグそのものの挙動はComfyUIの起動オプション実測ガイドに譲る。

この実験は、16GBのGPUに対して「これだけ空けておけ」と設定しただけで、物理的に容量の小さいGPUを挿したわけではない。この違いは実測に出ている。12GB設定のとき計算上の残りは 4,015MiB になるが、12GB設定側で実測したGPU全体のピークは 74組すべてでこれを超えており、値は個々の測定 (ブロック×相) で 5,510〜9,432MiB の範囲に散らばっていた (表のピーク列は構成と相ごとの中央値なので、この下限より高い)。ただしこのピークにはデスクトップなど他のプロセスの約2.8〜4.1GBが含まれるので、ComfyUI 側だけで計算上の残りを超えたと切り分けられているわけではない。それでも、他のプロセスの分を含むこの 5,510〜9,432MiB を4GBのカードにそのまま置くことはできない。より強い退避やホスト側メモリの利用が要ることになるので、16GBのカードを設定で絞った今回の結果を、そのまま4GBのカードへ当てはめることはできない。

手順は次のとおり。

• 1ブロック = 1プロセス。ComfyUI を起動し、初回実行を1本、続けて2本目を1本回して終了する。
• 「初回実行」は新規プロセスでの1本目という意味で、OSのファイルページキャッシュまで冷えた状態ではない。
• 設定 1.5GB と 12GB のブロックを対にして起動し、初回実行どうし・2本目どうしをそれぞれ1組として比べる (1つのブロック対から2組が取れる)。順序はブロックごとに入れ替える (ABBA)。条件間では同一seedを使う。本文の「74組」はこの数え方で、6構成×6対×2相 + Wan 2.2 の1対×2相 = 74 になる。
• 所要時間は ComfyUI の実行イベント (execution_start と execution_success) の時刻差。ワークフロー全体を挟む値なので、拡散のサンプリングだけでなくテキストのエンコードやVAEのデコード、ファイル保存も入っている。VRAM の設定だけで決まる値ではない。条件間でワークフロー自体は同じだが、これらの処理も所要時間に含まれる。VRAM の設定はエンコードやデコード側の扱いにも効きうるので、共通部分が差を取る側で必ず相殺されるとは限らない。観測された差を拡散のサンプリングだけに帰することはできない。
• GPU全体のピークは0.5秒間隔のサンプリング値で、ComfyUIプロセス単独の瞬間最大値ではない。同じGPU上でデスクトップなど他のプロセスが約2.8〜4.1GBを使っており、その量はブロックごとに変動する。

「遅くなった」と書いたのは、6組の対応ブロックが1つの例外もなく遅い側に振れ、かつどの組でも5%を超えて遅かったときだけである。この線は測る前に決めてある。判定は構成と相の組み合わせごとに付ける。遅い側に揃わなかったもの、揃っても5%に届かなかったものは「差を検出できず」とした。速くなる向きはこの基準では見ていない。本記事の実測値は2026年8月31日時点・当該構成での測定に基づく。

7構成でVRAMを絞ったときの所要時間

表の言葉を先に置き換えておく。「設定」は起動時に「これだけ空けておけ」と伝えた量。「相」の「初回実行」は ComfyUI を起動してからの1本目、「2本目」は同じプロセスで続けて回した1本で、何枚も続けて生成する使い方なら「2本目」のほうが近い。「対応ブロック」は同じ構成・同じ相で何組そろえて比べたかの数。

読むときは、モデルと量子化形式に加えてステップ数と解像度も近いものを探す。増加を検出できた FLUX.2 Klein では、同じモデル・同じワークフローのままステップ数だけを変えると上乗せがそれに沿って伸びたので (後述)、モデルと量子化形式が同じでもステップ数の違うものをそのまま当てはめることはできない。近いものが無ければ、その構成については今回のデータでは決まらない。

判定列は3種類ある。「遅くなった」は前の節で決めた基準を満たしたもの、「差を検出できず」は満たさなかったもの、「比較1組のみ・判定なし」は対応ブロックが1つしか取れず判定していないものである。

構成	相	対応ブロック	1.5GB設定時の所要秒	12GB設定時の所要秒	増減の中央値	増減の範囲	判定	GPU全体ピークMiB
FLUX.2 Klein 9B (Q8_0 GGUF・4ステップ・1024×1024)	初回実行	6	12.71-13.18	17.64-18.23	+39.4%	+35.9%〜+42.8%	遅くなった	14891→8289
FLUX.2 Klein 9B (Q8_0 GGUF・4ステップ・1024×1024)	2本目	6	4.75-4.95	7.68-8.05	+63.1%	+56.7%〜+67.9%	遅くなった	14757→5776
Krea 2 Turbo fp8 (8ステップ・1024×1024)	初回実行	6	13.87-18.66	13.46-14.20	-3.6%	-26.3%〜+0.9%	差を検出できず	15090→8626
Krea 2 Turbo fp8 (8ステップ・1024×1024)	2本目	6	9.34-10.79	9.21-9.96	-5.2%	-14.7%〜+2.4%	差を検出できず	15274→8339
Krea 2 Turbo NVFP4 (8ステップ・1024×1024)	初回実行	6	20.32-21.57	19.79-21.17	-1.4%	-5.0%〜+4.2%	差を検出できず	15077→8652
Krea 2 Turbo NVFP4 (8ステップ・1024×1024)	2本目	6	14.93-16.57	16.10-16.71	+2.0%	-2.8%〜+9.4%	差を検出できず	13120→8548
LTX 2.3 22B distilled fp8 (20ステップ・512x320x41フレーム)	初回実行	6	77.19-113.54	58.36-93.44	-18.9%	-46.2%〜+13.4%	差を検出できず	15360→7457
LTX 2.3 22B distilled fp8 (20ステップ・512x320x41フレーム)	2本目	6	12.90-18.92	12.83-18.06	+5.4%	-9.4%〜+36.0%	差を検出できず	15403→7392
FLUX.2 dev fp8mixed (20ステップ・1024×1024)	初回実行	6	63.89-69.19	62.36-66.55	-1.6%	-4.0%〜+0.4%	差を検出できず	15017→8172
FLUX.2 dev fp8mixed (20ステップ・1024×1024)	2本目	6	43.11-45.35	40.67-45.29	+0.1%	-7.0%〜+4.2%	差を検出できず	15200→8082
MiniMax H3 fp8_scaled (20ステップ・864x480x56フレーム)	初回実行	6	77.39-83.06	79.45-82.07	-0.4%	-3.9%〜+3.5%	差を検出できず	15137→7732
MiniMax H3 fp8_scaled (20ステップ・864x480x56フレーム)	2本目	6	64.07-68.66	63.66-68.14	-1.5%	-6.7%〜+6.0%	差を検出できず	15223→7670
Wan 2.2 T2V 14B fp8 x2 (20+20ステップ・640x640x81フレーム)	初回実行	1	612.41-612.41	596.63-596.63	-2.6%	-2.6%〜-2.6%	比較1組のみ・判定なし	15196→9432
Wan 2.2 T2V 14B fp8 x2 (20+20ステップ・640x640x81フレーム)	2本目	1	555.86-555.86	577.02-577.02	+3.8%	+3.8%〜+3.8%	比較1組のみ・判定なし	15237→9403

遅くなったと判定されたのは FLUX.2 Klein の2相だけで、この回の増減の中央値は初回実行で +39.4%、2本目で +63.1% だった。残る5構成の10通りはいずれも「差を検出できず」に落ちている。Wan 2.2 は実用外に遅く精密計測を打ち切ったため対応ブロックが1つしかなく、判定はせず記述に留める。

表の LTX 2.3 は、2026年8月11日に open weights で公開された LTX 2.5 より前のものである。2.5 は今回測っていない。

表を読むときの前提を並べておく。

• 初回実行は新規ComfyUIプロセスでの1本目であって、OSのファイルページキャッシュまでcoldではない。
• GPU全体ピークは0.5秒間隔のサンプリング値でComfyUIプロセス単独ではなく、同一GPUでデスクトップなど他のプロセスが約2.8〜4.1GBを使用している。所要秒の列は各設定のブロック (本数は対応ブロック列のとおり) の最小-最大、ピークの列は同じブロックの中央値を 1.5GB→12GB の2値で載せており、ブロック間の幅は表に出していない。
• 判定の「差を検出できず」は、遅くならないと確かめたという意味ではない。
• Wan 2.2 は実用外に遅く精密計測を打ち切ったため対応ブロックが1つしかなく、記述に留める。

「差を検出できず」は「遅くならない」ではない

この記事の判定は、遅くなる向きの差を探すやり方である。差が無いことを確かめるやり方ではない。だから「差を検出できず」となった構成と相について言えるのは、この測り方では差を見つけられなかった、というところまでになる。本当に差が無かったのか、差はあるが小さすぎて見えなかったのか、6組では足りずに見えなかったのか、その区別はついていない。

散らばりの大きさは構成と相によって違う。Krea 2 Turbo fp8 の初回実行は -26.3%〜+0.9%、LTX 2.3 の初回実行は -46.2%〜+13.4% と大きく振れている。一方で FLUX.2 dev の初回実行 (-4.0%〜+0.4%) や MiniMax H3 の初回実行 (-3.9%〜+3.5%) は、6組とも ±5% の内側だった。ただし後者も、測った6つがその幅に収まったというだけで、本当の差が小さいと確かめたわけではない。どちらも書けるのは「増加を検出できなかった」までである。

唯一増加を検出できた構成で、増え方を追う

増加を検出できた FLUX.2 Klein について、同一モデル・同一ワークフローのままステップ数だけを 4・8・12 に変えて追加測定した。以下はすべて2本目の相の値である。各6ブロック×2条件 (1.5GB / 12GB) で、4・8・12ステップの3水準は1つのスクリプトで連続実行しているため、回をまたぐ変動は内部比較には入らない。ただし連続実行の中でも熱やページキャッシュの状態は動くので、3水準がまったく同じ状態で測られたわけではない。なおこれは上の表とは別の測定回で、4ステップの測定は上の表の Klein 2本目と同じ構成にあたるが、上の表から読める差 (+63.1%、約3秒) とは一致しない。この食い違い自体は後の節で扱う。

ステップ数	対応ブロック	1.5GB設定時の所要秒	上乗せ秒の中央値	上乗せ秒の範囲	1ステップあたり
4	6	4.84-4.87	+5.810	+5.531〜+6.169	1.45秒
8	6	8.51-8.64	+12.127	+11.600〜+12.772	1.52秒
12	6	12.35-12.43	+18.053	+17.898〜+18.406	1.50秒

上乗せ秒の中央値は +5.810秒 / +12.127秒 / +18.053秒 と、ステップ数に沿って伸びた。1ステップあたりに直すと、この測定回の中では 1.45〜1.52秒 に揃っている。ただしこれは4・8・12ステップの3水準を1つのスクリプトで連続実行した回の内部での揃い方である。同じ4ステップを別の回で測ったときの上乗せは +3.084秒、1ステップあたりに直すと約0.77秒だった (後述)。回をまたぐと1ステップあたりの値は倍近く動く。この測定から読めるのは、上乗せが生成1本あたり一定の固定費ではなくステップ数に沿って伸びた形までで、1ステップあたりの秒数を持ち帰れるわけではない。

切り分けられた範囲は限られる。同じモデル・同じワークフローの中では、ステップ数を4・8・12と操作したときに上乗せがそれに沿って動くところまでは確かめた。切れていないのは別の2点である。1つは、1ステップあたり1.5秒前後の上乗せが何によって生じているのかを測っていないこと。もう1つは、判定した6構成のうちこの構成だけが遅くなったと判定された理由をステップ数に帰せないことで、この構成は今回唯一のGGUF量子化であると同時に、基準側の所要時間が表の中で最も短い構成でもある。判定は5%という相対基準なので、基準時間が短い構成ほど同じ上乗せ秒でも基準を超えやすい。判定が分かれた要因は、量子化形式とも、基準時間の短さとも、構成ごとに測定した時間帯が違うこと (回をまたぐと上乗せが動くのは後述) とも区別がついていない。上乗せ秒の値も、その測定回における値であって、別の回では同じ値にならない。

ピークの低下は、待ち時間の変化と必ずしも揃わない

設定を 1.5GB から 12GB へ増やすと、測定した74組すべてでGPU全体のサンプリングピークが低下した。ここは例外が無い。ただしこれは0.5秒間隔でサンプリングしたGPU全体の使用量であり、ComfyUIプロセス単独の瞬間最大値ではない。デスクトップなど他のプロセスが約2.8〜4.1GBを使っている同一GPU上での値でもある。また公式ドキュメントで --reserve-vram は設定として書かれており、使用量に上限を掛ける仕組みとしては記載されていない。公式実装では、設定値はVRAMの予約量としてメモリ管理へ渡される。実測に使った版のソースを読むと、この値は2つの経路に入っている。今回のように dynamic VRAM が有効なときは動的アロケータへ余裕分として渡り、それとは別に、ComfyUI 本体のメモリ管理でも予約VRAMとして必要空きメモリの計算に使われる。後者は dynamic VRAM の有無で分岐していない。起動フラグの --vram-headroom はこれとはさらに別で、動的アロケータのデバイス初期化時に渡る。どの経路もモデル側で使えるVRAMを減らす方向に働くため、ピークが下がる向き自体は説明が付く。ただし設定した量のとおりに使用量が制限されると確かめられたわけではないので、ピークが下がったことを設定したとおりに使用量が抑えられた結果として読むことはできない。

host から GPU への PCIe 転送量の積算も見ている。設定を増やしたときに増加したのは74組のうち56で、74組すべてではない。LTX 2.3 の初回実行は6組とも減少している。積算は nvidia-smi dmon の rxpci 列 (host から GPU への転送レート、MB/s) を1秒間隔で取り、各サンプルが1秒間継続したと仮定して単純合計した概算値である。rxpci は短時間の転送レートをサンプリングした値であり、生成区間全体の実転送量を直接測ったものではない。また生成の開始・終了と厳密に区間を合わせていないため、参考値として扱う。

この並びから読めるのは、ピークの低下・転送量の増減・所要時間の変化が同じ向きに揃って動くわけではない、という点までである。ただし積算は組単位で生成区間に合わせた値ではないため、転送の増減と所要時間の変化を組ごとに対応させる検証はしていない。転送が増えた分だけ待ち時間が伸びるという説明を、このデータで確かめることも退けることもできていない。

同じ構成でも、測定回が変われば上乗せ秒は同じにならない

再現性の確認として、FLUX.2 Klein の4ステップという同じ構成の2本目の相を、別の回でも測っている。上乗せ秒の中央値は、ある回で +3.084秒、別の回で +5.810秒だった。1.5GB設定側の所要は 4.752-4.952秒 と 4.843-4.866秒 で一致しており、ずれているのは絞った側だけである。背景のGPU使用量は、上乗せが大きかったほうの回 (+5.810秒の回) で低く、モデル側に回る余裕はむしろ大きかった。少なくとも観測した背景のGPU使用量の増加では説明しにくい。

2回の測定は同日で約3時間56分あいており、その間に重み25〜50GiB級の別構成の測定を挟んでいる。OSのページキャッシュの状態か、連続稼働後の熱か、候補は挙がるがこのデータでは分離できていない。単純な熱変動だけなら 1.5GB 設定側にも影響が出そうだが、今回の観測では確認できない。

したがって、この記事から秒数を単一の代表値として持ち帰ることはできない。持ち帰れるのは、その構成で上乗せが出た向きと、上乗せが数%ではなく数十%以上の規模だったことまでである。上乗せ秒そのものは回をまたぐと倍近く動いた。

この記事が測っていないこと

転送量の増減と所要時間の変化の組単位の対応は測っていない。積算は生成区間に合わせていない参考値で、対応づけの設計になっていない。

今回扱ったのは、所要時間・GPU全体のサンプリングピーク・PCIe転送量の積算の3つだけである。次の軸は測っていない。

• 物理的に容量の小さいGPUでの挙動。これは16GBのGPUに設定で絞った実験であり、ピークが5GB台まで下がったことは、5GBのGPUで同じワークフローが通ることを意味しない。
• 設定 1.5GB と 12GB の間の値、およびこの2つより外側の設定値。
• 別のGPU、別のシステムRAM容量。測定機はシステムRAM 96GB の1台のみ。
• 表の構成列に無い組み合わせ (モデル・量子化形式・ステップ数・解像度・フレーム数)。Wan 2.2 は実用外に遅く精密計測を打ち切っており、対応ブロックが1つしかない。
• GPUの外に置かれた重みが、ホスト側でどれだけのメモリを使ったか。今回記録したのはGPUのVRAMとPCIe転送だけである。
• 出力の画質や生成結果の内容。今回は時間と使用量だけを見ている。
• 回ごとに上乗せ秒が変わった原因。ページキャッシュか熱かを分離する測定はしていない。

VRAM容量ごとに何ができるかという方向の情報はComfyUI推奨スペック実測ガイドで扱っている。

ここで測っていない「GPU の外に置かれた重みがホスト側でどれだけ使ったか」の方向は、LTX 2.5 を 16GB VRAM で回すで扱っている。モデル一式が収まらない状態を、所要時間とシステム RAM の両方で追った測定になる。

まとめ

この測定 (2026年8月31日時点) から言えるのは、設定を増やせばGPU全体のピークは74組すべてで下がる一方、生成時間の増加を事前基準で検出できたのは判定できた6構成のうち1構成だけ、という非対称である。いずれも16GBのGPU1枚に設定で絞った結果で、物理的に容量の小さいGPUを挿した状態とは別物になる。

手元のワークフローが表のどれかと一致する場合には、その判定 (遅くなったか、差を検出できずか) と、遅くなったと判定されたものについてはその回の増減が数%ではなく数十%以上の規模だったことまでは読み取れる。増減の値そのものは測定回ごとに動き、同じ構成を別の回で測ったときは上乗せが +3.084秒から +5.810秒へ動いた。基準側の所要はどちらの回も約4.85秒で、割合に直すと +5.810秒の回は約+120% と表の範囲 (+56.7%〜+67.9%) の外に出る (表に載せたのはもう一方の +3.084秒の回にあたる)。手元の秒数の見積もりには使えない。一致しない場合、今回のデータでは決まらない。検出できなかった10通りについても、差が無いことを示した結果ではないため、そのまま「影響なし」として運ぶことはできない。

よくある質問

設定値を増やすと、その分だけVRAM使用量に上限が掛かるのか

公式の起動フラグ一覧では、--reserve-vram はOSや他のソフト用に空けておくVRAM量をGB単位で設定するフラグとして記載されており、使用量に上限を掛ける仕組みとしては書かれていない。今回の測定でピークが下がったのは観測された事実だが、設定した量のとおりに使用量が制限されたことまでは確かめていない。

ピークの中央値が5GB台まで下がったなら、その容量のGPUでも同じワークフローが通るのか

今回の結果からは言えない。これは16GBのGPU1枚に対して設定で絞った実験であり、物理的に容量の小さいGPUを挿した状態とは別物になる。ピークが5GB台まで下がったことは、5GBのGPUで同じワークフローが通ることを意味しない。

PCIe転送が増えるなら遅くなると考えてよいか

今回のデータからは決められない。転送量の積算が増えた56組の側にも、所要時間の増加を検出できなかった構成が並んでいる。ただし積算は生成区間と厳密に合わせていない参考値で、組ごとに転送量の増減と所要時間の変化を対応させる設計にもなっていない。支持も否定もできない、が正確なところである。なお積算が増えたのは74組のうち56で、LTX 2.3 の初回実行のように減った組もある。

参考資料

• ComfyUI 起動フラグ一覧 (公式)