ComfyUIの起動オプション実測ガイド｜dynamic VRAM時代のVRAM設定

現行のComfyUI（NVIDIA環境）では、起動オプションは基本的に付けない

ComfyUI の起動オプションのうちVRAMの使い方に関わるものは、現行版のNVIDIA環境では指定しない状態が出発点になる。公式ドキュメント Startup Flags の一覧で dynamic VRAM の Default 列は「auto on Nvidia」と記載されており、NVIDIA環境では既定で有効になるためである。ページのその記載以上の条件、たとえば内部モジュールの初期化状況までは本記事では踏み込まない。

この既定の状態を変える側として使うのが --disable-dynamic-vram で、公式の定義は「dynamic VRAM を無効化し、推定ベースのモデルロードに戻す」。逆に、既定では有効にならない環境で有効にする側が --enable-dynamic-vram になる。本記事が扱うのはこの定義の範囲までで、dynamic VRAM が有効なときに内部でVRAMをどう配分しているかは扱わない。

本記事に載せた実測は、reserve の測定が2026年8月・精度フラグの比較が2026年8月24日に、いずれもRTX 5080(VRAM 16GB)で測ったものである。

すでにOOM（VRAM不足）が出ている状態で調べている場合は、OOMが出たときに試す順序から読むほうが早い。速度を上げる目的で探している場合は、速度を上げたいときに使えるオプションはあるかに該当する内容がある。

VRAM関連の起動オプション一覧

ここで扱うのは、モデルをどこに置くか（VRAM／RAM／ディスク）と、キャッシュをどう持つかに関わる指定に限る。公式 Startup Flags の VRAM & Memory 表には、モデルファイルの読み込み方式（mmap 系）やメモリのピン留めに関わるフラグ、演算そのものの非同期化に関わるフラグも並んでいるが、それらは本記事の範囲外になる。重みの保持形式を変える --fp8_e4m3fn-unet も別系統なので、この一覧ではなく後半の順序の中で扱う。

有効化と無効化が対になるフラグは原則として代表側だけを挙げているが、dynamic VRAM は環境によって既定が変わるため両方を載せた。「定義（出典）」欄は公式ドキュメントの記載を基本とし、ComfyUI本体のコードや起動時の警告文でしか確認できない部分、当サイトの判断にあたる部分には、それぞれ出典を添えている。

フラグ	定義（出典）	既定	排他グループ
--gpu-only	テキストエンコーダやCLIPを含むすべてをGPU上に置いて実行する（公式 Startup Flags）	指定なし	VRAMモード（5つで相互排他）
--highvram	使い終わったモデルをCPUへ退避せず、GPUメモリに保持し続ける（公式 Startup Flags）	指定なし	VRAMモード（5つで相互排他）
--lowvram	dynamic VRAM が有効な環境では効果がない。無効な環境ではテキストエンコーダをCPUで実行してVRAMを節約する（公式 Startup Flags）	指定なし	VRAMモード（5つで相互排他）
--novram	--lowvram で足りないときに使う、VRAM使用を最小限にするモード（公式 Startup Flags）。--enable-dynamic-vram を明示していない環境では、これを付けた時点で dynamic VRAM の自動有効化は行われない。--highvram / --gpu-only / --cpu / --disable-dynamic-vram も同じで、--lowvram だけは止めない（本体コード）	指定なし	VRAMモード（5つで相互排他）
--cpu	すべてをCPUで実行する。公式は括弧で slow と付記している（公式 Startup Flags）	指定なし	VRAMモード（5つで相互排他）
--reserve-vram	OSや他のソフト用に空けておくVRAM量をGB単位で指定する（公式 Startup Flags）	OSに応じた量が予約される（固定値ではない）	どちらの排他にも属さない
--vram-headroom	dynamic VRAM が既定の余白に上乗せして完全に空けておくVRAM量をGB単位で指定する。他のアプリが使っているVRAMも数に入れて空けようとする（本体コードの定義。2026年8月28日に確認した範囲では、公式 Startup Flags ページのVRAM表に同フラグの行を見つけられなかった＝コード側のほうが新しい）	0	どちらの排他にも属さない
--disable-smart-memory	モデルをVRAMに保持せず、積極的にRAMへオフロードする（公式 Startup Flags）	指定なし	どちらの排他にも属さない
--cache-none	ノードの実行結果をキャッシュせず毎回再実行することでRAM/VRAMの使用量を下げる（公式 Startup Flags）	指定なし	キャッシュ方式（5つで相互排他）
--async-offload	重みの非同期オフロードを行う。ストリーム数は任意で指定でき、既定は2。無効化する側のフラグは --disable-async-offload（公式 Startup Flags）	NVIDIA環境では有効	どちらの排他にも属さない
--fast-disk	ピン留めしていないRAMよりも、ディスクを使った動的な読み込み／退避を優先させる。公式は高速なNVMeで有用としている（公式 Startup Flags）	無効	どちらの排他にも属さない
--disable-dynamic-vram	dynamic VRAM を無効化し、推定ベースのモデルロードに戻す（公式 Startup Flags）。指定すると「この引数はまもなく削除される」という警告が出る（起動時の警告文）ため、恒久設定には向かない（当サイトの判断）	指定なし	どちらの排他にも属さない
--enable-dynamic-vram	既定では dynamic VRAM が有効にならない環境で、これを有効にする（公式 Startup Flags）	指定なし（NVIDIA環境では dynamic VRAM 自体が既定で有効）	どちらの排他にも属さない

モード指定の5つ（--gpu-only / --highvram / --lowvram / --novram / --cpu）は公式が相互排他と明記しており、いずれか1つだけを指定する。キャッシュ方式にも別の相互排他グループがあり、--cache-ram / --cache-classic / --cache-lru / --cache-none / --high-ram の5つから1つを選ぶ（本体コード）。

残りのフラグはこのどちらの排他にも属さないが、それは自由に組み合わせられるという意味ではない。--enable-dynamic-vram と --disable-dynamic-vram は同じ設定の裏表で同時には成り立たず、--async-offload と --disable-async-offload も同様。--disable-smart-memory（RAMへ退避）と --highvram / --gpu-only（GPUに保持）のように、排他の指定が無くても定義が打ち消し合う組み合わせもある。

--lowvram 単体が効かない条件

公式 Startup Flags における --lowvram の定義は「dynamic VRAM が有効な環境では効果がない。無効な環境ではテキストエンコーダをCPUで実行してVRAMを節約する」となっている。dynamic VRAM は NVIDIA環境では既定で有効なので、この定義に照らすと、NVIDIA環境で --lowvram だけを付けても定義の後半（テキストエンコーダをCPUへ）の前提が成り立たない。

VRAM不足の第一手として --lowvram を覚えている場合、現行のNVIDIA環境ではその前提が成り立たない点に注意が要る。効かせるには dynamic VRAM を無効化する --disable-dynamic-vram を併せることになるが、そのフラグには起動時に「まもなく削除される」という警告が付く。

裏を返せば、dynamic VRAM が有効でない環境では --lowvram は定義どおりに働く。効くかどうかはフラグ単体ではなく dynamic VRAM の状態で決まる、という条件付きの関係になる。

--reserve-vram で空きVRAMを削るとどうなるか

--reserve-vram は、OSや他のソフト用に空けておくVRAM量をGB単位で指定するフラグ（公式 Startup Flags）。既定でもOSに応じた量が予約される。ComfyUI から見れば使える量が減る指定なので、申告量を段階的に変えて何が動くのかを測った。

測定環境は RTX 5080 (VRAM 16GB) / ComfyUI / MiniMax Music 3 INT8拡散モデル・タイルdecodeあり・60秒指定。表の「共有メモリ」は、GPU向けに割り当てられたシステムRAM領域のピークであって、プロセスのRAM使用量そのものではない。

reserve指定	専用VRAMのピーク	共有メモリのピーク	エンジン時間	結果
なし	13,420 MiB	11,322 MiB	408.0秒	成功
4GB	13,413 MiB	11,298 MiB	376.2秒	成功
6GB	11,767 MiB	11,299 MiB	431.2秒	成功
8GB	9,702 MiB	11,309 MiB	460.5秒	成功
10GB	7,539 MiB	11,292 MiB	454.0秒	成功
12GB	6,335 MiB	11,276 MiB	477.7秒	成功
13GB	6,193 MiB	11,277 MiB	549.3秒	成功

この構成では、申告した量は使用量の上限としては働いていない。reserve を指定した6条件はいずれも専用VRAMのピークが「16GB − 申告量」を上回っており、13GB申告の回でも、この計算でいう上限3,072 MiB に対して実測は6,193 MiB だった（指定なしの回は申告量が無いので比較の対象にならない）。ここから導けるのは、専用VRAMのピーク値は必要量の下限ではない、というところまでになる。

4GBの申告では、指定なしの回との差が7 MiB で、専用VRAMのピークに実質的な差を観測できなかった。ただし各条件を1回ずつしか走らせていないため、内部の挙動や時間への影響まで否定はできない。この2回はエンジン時間が31.8秒（起点比7.8%）違うが、それが設定の効果か実行ごとの振れかも分離できない。申告量への追随が観測できるのは6GB以上からになる。

押し下げ幅は申告量に対して単調に縮むわけではない。申告1GBあたりの低下は 4→6GB で823 MiB、6→8GB で1,033 MiB、8→10GB で1,082 MiB、10→12GB で602 MiB、12→13GB で142 MiB。8→10GB までは増えており、縮小が始まるのは10GB以降で、12→13GB では142 MiB まで縮んだ。試した申告は13GBまでで、それより大きい申告は測っていない。

エンジン時間は条件ごとに動いているが、その順位は条件差に帰属できない。専用VRAMのピークがほぼ動かなかった4GBの回ですら起点と31.8秒（起点比7.8%）差があり、中間の4条件（6・8・10・12GB）の幅46.5秒はこれより大きいものの同じ桁にある。各条件1回ずつのため、条件差と実行ごとの振れを分けられない。13GBの549.3秒は起点比+34.6%で、比較用に置いた無指定―4GB間の31.8秒差より大きいが、同条件を繰り返していないので、条件によるものか単発の外れかは切り分けられない。

共有メモリのピークは7条件で11,276〜11,322 MiB（幅46 MiB）とほぼ動かなかった。この測定で申告量に追随して動いたのは専用VRAM列だけになる。エンジン時間も動いてはいるが、前述のとおり条件差と振れを分けられない。

なお、この測定の起点（reserveなし）13,420 MiB は、掲載元記事の別の実行（13,256 MiB）とは異なる回のもの。条件ごとのログや測り方は--reserve-vram を段階的に変えた実測記事にある。

少なくともこの1機種・1モデル・1ワークフローで、13GBまでの申告を試した範囲では、--reserve-vram は使用量に上限を掛けるフラグではなく、6GB以上の申告で専用VRAMのピークを下げる方向へ押すフラグとして振る舞った。押し下げ幅は12→13GBで142 MiB まで縮み、ピークは6GB台に留まった。共有メモリ側はこの測定では動かせなかった。

OOMが出たときに試す順序

VRAM不足でワークフローが落ちるとき、公式トラブルシューティングの Model Issues ページは --lowvram → --novram → --cpu（最後の手段）という3段の順序を示している。Troubleshooting Overview ページのほうで挙げられているのは --lowvram と --cpu の2つ。以下の手順は、この公式3段の手前に、当サイトの整理として --fp8_e4m3fn-unet と --disable-smart-memory の2段を足したものになる。そもそもエラーがVRAM由来かどうかの切り分けはVRAM不足エラーの原因と解決法にまとめている。

並び順は副作用の小さい順ではなく、VRAMの減らし方の系統順になっている。重みの数値形式そのものを変えるのはステップ1だけで、以降は形式を変えずに置き場所や実行先を変えていく。ただしステップ3だけは、置き場所ではなくメモリ管理の方式ごと推定ベースへ切り替わる段で、必ず使用量が減る側に働くとは限らない。出力への影響を避けたい場合はステップ1を飛ばし、ステップ2から入ることになる。

現行のNVIDIA環境で手を入れる必要があるのは、公式3段のうち先頭の --lowvram だけになる。dynamic VRAM が有効な環境では効果がないため、効かせるには --disable-dynamic-vram を併せる必要があるが、このフラグを指定すると ComfyUI は「この引数はまもなく削除される」という警告を出す（GGUF を使う場合は dynamic VRAM を有効なまま、ComfyUI ネイティブのモデル形式を使うことを勧める、とも書かれている）。恒久的な手順にはできない。一方 --novram は、--enable-dynamic-vram を明示していない環境なら、これを付けた時点で dynamic VRAM の自動有効化が行われないので、公式の順序のまま使える。

ステップ1｜--fp8_e4m3fn-unet を足す。公式定義は「拡散モデルの重みをFP8(e4m3fn)で保持する」で、重みの保持形式を変える指定であり、演算全体が速くなることを保証するものではない。2026年8月24日に --fp16-unet を基準として5モデルで切り替えた当サイトの比較では、VRAMピークが下がったのは5モデル中2つ(SDXL・SD 3.5 medium)、下がらなかったのは Flux 1 dev・FLUX.2 Klein 9B・MiniMax H3で、速度向上を確認できたモデルはなかった。基準が --fp16-unet であるため、何も指定しない起点からの下げ幅とは一致しない。モデルごとに解像度・ステップ数が異なり、Flux 1 dev と MiniMax H3 は条件間の差より測定ごとの振れが大きく、速さの順位は判定できていない。この比較の MiniMax H3 は、前節の測定に使った MiniMax Music 3 とは別のモデルである。条件の内訳は精度フラグを5モデルで比較した実測記事にある。重みの数値形式が変わる以上、出力も変わりうる段になる。

ステップ2｜--disable-smart-memory を足す。公式定義は「モデルをVRAMに保持せず、積極的にRAMへオフロードする」。ステップ1のフラグは残したまま積み増す。VRAM側の圧力をRAM側へ移す指定なので、RAMが先に上限へ当たる構成では逆効果になる。

ステップ3｜--lowvram と --disable-dynamic-vram を足す。ステップ1と2で足したフラグはそのまま残す。この2つはVRAMモードの排他グループの外にあり、--lowvram と定義のうえで打ち消し合う関係でもないためである。--lowvram は dynamic VRAM が有効な環境では効果がないので、NVIDIA環境で効かせるには --disable-dynamic-vram を併せることになる。この段はモデルの置き場所を変えるだけでなく、メモリ管理を推定ベースへ戻す段でもあるため、使用量が必ず減るとは限らない。ここで通ったとしても、削除予告の付いたフラグを常用の設定にはできない。続けてステップ4でも通るかを確かめ、常用はそちらに置く。

ステップ4｜VRAMモードの指定を --novram だけにする。公式定義は「--lowvram で足りないときに使う、VRAM使用を最小限にするモード」。ステップ1と2で足したフラグはそのまま残し、--lowvram と --disable-dynamic-vram を外して --novram に置き換える。--enable-dynamic-vram を明示していない環境であれば、--novram を付けた時点で dynamic VRAM の自動有効化は行われないため、削除予告の付いたフラグを使わずに済む。逆に --enable-dynamic-vram を明示している環境では判定がそちらを優先するので、--novram を足しても dynamic VRAM は無効化されない。無効化したい場合は --enable-dynamic-vram 自体を外す。

ステップ5｜--cpu。公式定義は「すべてをCPUで実行する」で、公式は括弧で slow と付記している。公式が最後の手段として置いている段になる。

--reserve-vram をこの順序に入れていないのは、測定として、申告した量が上限として効かず、押し下げたピークも6GB台に留まったため、一手目として何GBと指定すればよいかを決められないからである。指定量を決めるには効き始めと、低下幅が大きく縮む位置が要るが、押さえているのは2GB刻みの粗い解像度（効き始めは4GBと6GBの間、低下幅が大きく縮んだのは12→13GB区間）でしかなく、1機種・1モデル・1ワークフローの結果で、しかもOOMが出ている状態での回避効果は検証していない。付けるか付けないかだけの段には、いくつを指定するかという問題自体が生じない。ComfyUIと同じGPUを他のソフトも使う構成で余白を残したいときに、上の順序と併用するフラグという位置付けになる。

--vram-headroom もこの順序には入れていない。定義上これは dynamic VRAM が空けておく量を上乗せする指定で、ComfyUI が使える量を減らす向きになるためである（OOMの回避に効くかどうかは測っていない）。

速度を上げたいときに使えるオプションはあるか

速度目的で候補に挙がりやすいのは --highvram と --gpu-only の2つになる。公式の定義は、--highvram が「使い終わったモデルをCPUへ退避せずGPUメモリに保持し続ける」、--gpu-only が「テキストエンコーダやCLIPを含むすべてをGPU上に置いて実行する」。どちらもモデルの置き場所についての記述で、2026年8月27日に確認した Startup Flags の定義文の範囲では、速くなるとは述べられていない。当サイトでもこの2つの速度は測っていない。

この2つはVRAMモードの指定なので、モード指定の5つから1つしか選べず、他のモードとは併用できない。加えて、--enable-dynamic-vram を明示していない環境では、--highvram や --gpu-only を付けた時点で dynamic VRAM の自動有効化は行われない。速度目的で試す場合も、既定のメモリ管理から外れた状態で走らせることになる。

速度方向を持つ他のフラグにも、新たに足す余地は大きくない。--async-offload は重みの非同期オフロードを行う指定だが、NVIDIA環境では既定で有効なので、改めて足して増える効果はない。--cache-none については、公式 Troubleshooting Overview が「RAM使用量は減るが遅くなる」と述べており、速度目的では逆方向になる。精度フラグの --fp8_e4m3fn-unet も、2026年8月24日の --fp16-unet 基準の比較ではVRAMピークが下がったのが5モデル中2つで、速度向上を確認できたモデルはなかった。

なお公式 Troubleshooting は「For better performance」として、プレビューの無効化（--preview-method none）や attention 方式の変更（--use-pytorch-cross-attention / --use-flash-attention）も挙げている。これらはモデルをどこに置くかではなく描画や演算の側に効く指定なので、本記事が扱う範囲の外になる。当サイトでもこれらは測っていない。

以上を踏まえると、速度目的で確実に効くと言える指定は本記事の範囲には無い。試すこと自体を否定する材料も無いので、--highvram か --gpu-only を入れて比べる場合は、効果が保証されない前提で判断することになる。前節の測定でも、専用VRAMのピークがほとんど動かなかった2つの回のあいだで実行時間が起点比7.8%違っている。振れの幅はワークフローの長さで変わるので、同じ設定を数回走らせて手元の環境の振れを把握し、それと比べて判断するのが妥当になる。

システムRAM側で詰まるとき

VRAMではなくシステムRAMが先に埋まる構成では、フラグの向きが変わる。--disable-smart-memory はモデルをVRAMに保持せず積極的にRAMへオフロードする指定なので、VRAM側の圧力をRAM側へ移すことになる。RAMが先に上限へ当たる構成では逆効果になる。

RAMとVRAMの両方を下げる方向で使えるのが --cache-none で、公式定義は「ノードの実行結果をキャッシュせず毎回再実行することでRAM/VRAMの使用量を下げる」。速度については、公式 Troubleshooting Overview が「RAM使用量は減るが遅くなる」と明記している。一方、2026年8月28日に確認した範囲では、Startup Flags ページの定義欄に速度の記述は見つけられなかった。キャッシュを捨てて毎回実行し直す以上そのぶん時間はかかるが、どれだけ遅くなるかは当サイトでも測っていない。

前節の測定で共有メモリのピークがほぼ動かなかった件は、RAM側の判断材料としては限定して扱う必要がある。共有メモリは前述のとおりGPU向けに割り当てられた分であって、プロセスのRAM使用量そのものではない。またあの測定で動かした設定は --reserve-vram の1つだけなので、VRAM側の設定一般についてRAM側が動かないという話には広げられない。

よくある質問

AMDのGPU（ROCm）でも dynamic VRAM は既定で有効か

公式 Startup Flags ページの Default 列は「auto on Nvidia」で、2026年8月27日に確認した範囲では、同ページに ROCm の既定値についての記述は見つけられなかった。一方、v0.34.0 のリリースノートには ROCm 7.14 以降で dynamic VRAM を既定で有効にする、という記載がある。ページの Default 列だけでは ROCm の現在の既定値は決められないので、使用中バージョンのリリースノートで確認することになる。既定で有効にならない環境でこれを有効にするフラグが --enable-dynamic-vram になる。

VRAMモードのフラグは組み合わせて使えるか

--gpu-only / --highvram / --lowvram / --novram / --cpu の5つは公式が相互排他と明記しており、いずれか1つだけを指定する。--reserve-vram や --disable-smart-memory のようにこの排他グループの外にあるフラグは、モード指定と同時に書くこと自体は妨げられない。ただし、外にあることは自由に組み合わせられるという意味ではない。--disable-smart-memory はRAMへ退避させる指定で、GPUに保持し続ける --highvram / --gpu-only とは定義のうえで打ち消し合う。--cache-none はさらに別の排他グループ（--cache-ram / --cache-classic / --cache-lru / --cache-none / --high-ram の5つ）に属するので、他のキャッシュ方式とは併記できない。

--reserve-vram で6GB台まで下がったなら、6GBのGPUでも同じワークフローは通るか

その結論にはつながらない。あの測定は16GBのGPUに空けておく量を申告して動かした結果で、物理的に小容量のGPUを挿した状態とは別物になる。専用VRAMのピークが6GB台まで下がったことは、6GBのGPUで同じワークフローが通ることを意味しない。下がったのは専用VRAM側だけで、共有メモリのピークはこの測定では動かせなかった。単一モデル・単一ワークフローでの測定でもある。容量ごとの目安はComfyUIの推奨スペック(VRAM容量別の目安)にまとめている。

--async-offload は足したほうがよいか

公式定義は「重みの非同期オフロード。ストリーム数は任意で指定でき、既定は2」で、NVIDIA環境では既定で有効になっている。すでに有効な環境で改めて足す指定ではない。無効化する側のフラグとして --disable-async-offload がある。

参考資料

• ComfyUI 公式ドキュメント: Startup Flags
• ComfyUI v0.34.0 リリースノート
• ComfyUI 公式ドキュメント: Troubleshooting Overview
• ComfyUI 公式ドキュメント: Model Issues

起動オプションのうち、どのGPUを使うかの指定はComfyUIで使うGPUを指定するで別に扱っている。