ComfyUI のコード解説と高速化省メモリ技術のまとめ

生成 AI 技術の発展に伴いモデルのサイズは非常に大きくなりました。市販の GPU では　VRAM サイズを大幅に超えていたり、処理能力が不足しているため、生成に非常に時間がかかるようになりつつあります。

画像生成や動画生成など生成AIで広く使われているComfyUI では様々な技術により、生成精度をなるべく落とさずメインメモリや VRAM の消費を抑えたり処理時間を高速化することが可能です。

2025/11/21 時点での CUDA 及びに ROCm 対応 GPU に対する ComfyUI の標準動作と、起動オプションやモデル変更で可能な高速化技術や省メモリ化技術について、ComfyUI や llama.cpp のソースコードを踏まえて Grok と対話してまとめました。

あくまでも自分が独自に調べた内容なので、間違いがあれば指摘お願いします。

ComfyUI での生成フロー

ComfyUI では、潜在拡散モデル(Latent Diffusion Model、LDM)の各処理をノードに対応づけています。ノードをまとめたワークフローをに基づき、ノードを適切な順番で実行することで、画像や動画を生成します。

文章から画像を生成する Text to Image (T2I) の基本的な生成フローは以下のとおりです。

順番	処理内容	処理に使うもの	処理結果	ComfyUIでのノード例
①	モデルの読み込み	拡散モデル、テキストエンコーダモデル、VAEモデル	VRAM 上のモデル	チェックポイントを読み込む、VAEを読み込む、Unet Loader(GGUF)、CLIP Loader(GGUF)
②	潜在画像生成	画像サイズ	空の潜在画像	空の潜在画像
③	生成文の処理	テキストエンコーダモデル、プロンプト	文書トークンベクトル	CLIPテキストエンコード
④	画像生成	拡散モデル、潜在画像、文書トークンベクトル	生成潜在画像	Kサンプラー
⑤	通常の画像を生成	VAEモデル、生成潜在画像	生成画像	VAEデコード
⑥	画像を保存	生成画像	ディスク上の生成画像	画像を保存

高速化省メモリ技術

上記の生成フロー番号で適用箇所を示しどのような高速化や省メモリ化技術が適用されているか解説します。

ノード間キャッシュ

起動オプション

起動オプションの処理はcomfy/cli_args.pyで実装されています。

例えば、--cache-classicオプションをつけた場合、args.cache_classic 変数に対応付けされ、オプションに基づく処理の分岐を行う際にこの変数が活用されます。

ノードの実装

ノードはnodes.pyとcomfy_extras以下で実装されています。

ノード間の処理

ワークフローの実行はexecution.py で実装されています。ノード単位で処理が行われ、ノードの実行結果をキャッシュするようになっています。

同じワークフローを 2 回目以降実行する際に、変更されていないノードの実行結果がキャッシュに存在するならそのノードを実行することを省けるので、無駄な処理を減らして高速化できます。キャッシュ機能はcomfy_execution/caching.pyで実装されています

設定可能オプション

--cache-classic
標準のキャッシュ機能です。オプション未指定の場合はこれになります。メインメモリがある限り積極的にキャッシュします。HierarchicalCache クラスとして実装されています。メインメモリが十分あるならこの機能で問題ありません。不足気味の場合は変更した方がよいと思います。
--cache-lru CACHE_LRU
指定した CACHE_LRU 個をより多くノードを実行した場合に、Least Recently Used(LRU)に基づき使われてから最も長い時間が経ったノードのキャッシュを削除します。LRUCache　クラスとして実装されています。この機能に意味があるかよくわかりません。例えば、画像サイズとプロンプトを変えずノイズを変えて画像を生成する場合、保持すべきキャッシュは②と③で、不要なのは④と⑤です。LRU では②③④⑤の順にキャッシュを削除してしまうはずです。
--cache-none
ノード間キャッシュを作成しません。NullCache クラスとして実装されています。メインメモリが不足気味の場合に向いています。
--cache-ram [CACHE_RAM]
メインメモリの残り×1.1が CACHE_RAM 未満になると、キャッシュの古さとキャッシュの大きさから削除すべきキャッシュを選ぶようです。RAMPressureCache クラスとして実装され、削除すべきキャッシュの選択と実際の削除は poll() で実装されています。

ここでの指定内容はノード間キャッシュのみに適用され、モデルの読み込み機能には直接は影響しません。ただし、ノード間キャッシュが増えれば増えるほどメインメモリが圧迫されるので、OS が自動的に行うファイルキャッシュが少なくなり、結果としてモデルの読み込みが遅くなってしまう可能性があります。キャッシュしない--cache-noneの方が速くなることもありうるので、--cache-noneを試してみてください。

モデル

①のモデルの読み込みと解放はcomfy/model_management.py内のトップレベルで実装されています(正直なところ model_management.py は汚く読みにくいです)。

モデル全体の読み込みと解放

他に Apple Silicon Mac のようなメインメモリを VRAM としても使う UMA アーキテクチャでは全体的に異なる処理をしているようです。

モデル形式

生成 AI のモデルは通常浮動小数点数でデータを保持し演算に利用します。

IEEE 765 の浮動小数点数の場合、符号部と指数部と仮数部からなります。

符号部は 0 なら正、1 なら負を表します。

指数部は 2 の何乗であるかを表します。指数部は浮動小数点数形式ごとに決められたバイアスを引くことで負の数を扱えるようにしています。2の -1 乗は 1/2、2 の -2 乗は 1/4 を表します。

仮数部は 2 進小数で表される数値に対して、整数部分は 1 固定、残りの小数部分に対応する部分を仮数部で保持します。

例えば、指数部 5 bit バイアス 15(２進数 1111) で、仮数部 2 bit なら、指数の範囲は-15〜16で、仮数部が２進数 1.00,1.01,1.10,1.11なので、10進数 1.0、1.25,1.5, 1.75です。

指数部 10000、仮数部 00 なら、2進数 10000 - バイアス 1111 より指数は1、仮数が 1.0 なので、2^1 * 1.0 = 2、指数部 10001、仮数部 10なら、2進数 10000 - バイアス 1111 より指数は 2 進数 10 = 10進数 2、仮数が 10進数 1.5 なので、2^2*1.5 = 3.0になります。

基本的に、指数部が大きいほど扱える数値の絶対値の最大値が大きくなり、仮数部が大きいほど扱える数値の細かさが広がります。

生成 AI でよく使われる浮動小数点数の形式と一般向け GPU での対応状況は以下の通りです。E は指数部の bit 数、M は仮数部の bit 数を意味します。

	bit 数	範囲	GPU での対応状況
FP32 (E8M23)	32	おおよそ -34030000000000000000000000000000000000 〜 34030000000000000000000000000000000000-	一般的な GPU ならどれでも対応
BF16 (E8M7)	16	おおよそ -30000000000000000000000000000000000000 〜 30000000000000000000000000000000000000	Geforce 2000番代以前では使えない。RADEONでは RDNA3 以降のみ
FP16 (E5M10)	16	おおよそ -65504 〜 65504	よほど古い GPU でない限り対応
FP8 (FP8E5M2)	8	おおよそ -57344 〜 57344	Geforce 2000番代以前では使えない。Geforce 4000番代以降は FP16 より高速、Geforce 3000番代は FP16 と同じ速度。RADEON では RDNA3 は FP16 と同じ速度のはず。RDNA4 は高速(2025/11/28修正)
FP8 (FP8E4M3)	8	おおよそ -448 〜 448	Geforce 2000番代以前では使えない。Geforce 4000番代以降は FP16 より高速、Geforce 3000番代は FP16 と同じ速度。RADEON では RDNA3 は FP16 と同じ速度のはず。RDNA4 は高速(2025/11/28修正)
FP4 (FP4E2M1)	4	-6.0, -4.0, -3.0, -2.0, -1.5, -1.0, -0.5, -0, +0, +0.5, +1.0, +1.5, +2.0, +3.0, +4.0, +6.0	現時点では Geforce 5000番代のみ対応

GGUF 量子化

量子化とは連続量に対して目盛りを定めてデータを区切って数値化することをいいます。

例えば、温度は熱かったり冷たかったりする分子運動に基づく物理的な連続量ですが、温度計により温度を電気信号の高さとして取り込み、水が凍る温度を 0、水が沸騰する温度を 100 と決め、均等に 100 段階で区切ると数値化できます(摂氏温度)。

0 度〜100 度まで 1 度単位で区切ると 101 個の目盛りがあります(0 度の目盛りもあるから 100 + 1 個)。でも体温計ならば 0 度や 100 度を測れる必要はないので 33 度〜 42 度までの目盛りがあれば十分です。この場合目盛りは 10 個ですみます。より正確に測れるよう 0.5 度単位の目盛りにしても 20 個ですみます。0.1 度単位の目盛りでも 100 個です。

目盛りの数が少ないほうが情報量は減ります。データに合わせた上手な区切り方を考えて目盛りの数を減らせばデータを小さくできます。

生成 AI でのモデルにおける量子化は、学習時に区切り方や数値表現方法を工夫することでなるべく精度を落とさず少ないデータ量で学習することや、すでに数値化されているデータに対して区切り方や数値表現方法を変えることで、なるべく精度を落とさないようにしつつ情報量を減らしたり高速処理ができるように変換することを指します。

ComfyUI でよく使われるのは GGUF 量子化です。GGUF は LLM で広く使われているllama.cpp のモデル形式です。LLM は以前からモデルサイズが大きいので、モデルを縮減するためにさまざまな技術が開発されており、モデルを上手に量子化することで演算速度をなるべく落とさずモデルサイズを大幅に減らすことが可能になっています。

GGUF 量子化モデルは FP16 のモデルのデータを一定サイズブロックごとに区切り、ブロック単位で区切り方を工夫して 8 bit や 6 bit や 4bit でデータを保持することで、精度をなるべく落とさずモデルサイズを 1/2 や 1/4 程度に縮減しています。演算時には GPU で高速に演算可能な積和演算によりその場で FP16 に戻すので、演算速度は FP16 とほぼ同じでわずかに遅くなります。

llama.cppのコードを参考にデータ構造を分析すると次のようになります。

Q8_0
- 1 ブロック 32 データ
- 1 データ 8bit
- スケール値 16bit

(8 bit × 32 データ + 16 bit) ÷ 32 データ = 8.5 bit

Q6_K
- 1 スーパブロック 16 ブロック
  - スケール値 16 bit
- 1 ブロック 16 データ
  - ブロックスケール値 8 bit
  - データ 6 bit

((6 bit × 16 データ + 8 bit) × 16 ブロック + 16 bit ) ÷ (16 データ × 16 ブロック) = 6.5625 bit

(正確には、1 スーパーブロックは、データの上位 4 bit を入れる領域 8 bit × 128、データの下位 2bit を入れる領域 8 bit × 64、ブロックスケール値 8 bit × 16、スケール値 16bit × 1　で構成)

Q4_K
- 1 スーパブロック 8 ブロック
  - スケール値 16 bit
  - データ最小値 16 bit
- 1 ブロック 16 データブロック
  - ブロックスケール値 6bit
  - ブロック最小値スケール値 6bit
- 1 データブロック
  - データ 4bit × 2個

(4 bit × 2 データ × 16 データブロック × 8 ブロック+ (6 bit + 6 bit) × 8 ブロック + 16 bit + 16 bit) ÷ (2データ × 16 データブロック × 8 ブロック) = 4.5 bit

(正確には、1 スーパーブロックは、スケール値 16 bit、データ最小値 16 bit、ブロックスケール値とブロック最小値スケール値を入れる領域 8 bit × 12、データ 2 個セットで入れる領域 8 bit × 128 で構成)

Q4_K_S
少量の Q6_K を Q4_K と組み合わせた形式
Q4_K_M
Q6_K を Q4_K_S より多く Q4_K と組み合わせた形式

ComfyUI は標準では GGUF に対応していませんが、ComfyUI-GGUFカスタムノードで GGUF モデルの読み込みが可能です。画像生成用モデルや動画生成用モデルに対応するための llama.cpp 用のパッチも含まれているので、ComfyUI で使うためにモデルを GGUF 形式へ変換と量子化にはこのカスタムノードが必要です。

nunchaku

nunchakuは特異値分解という数学的手法に基づいてデータの区切り方を決め、4bit 整数 INT4 や FP4 の 4bit で量子化する手法のようです。

Geforce 5000番代のように FP4 に対応している GPU では精度をあまり落とさずに非常に高速な生成が可能になります。

ComfyUI は標準では nunchaku に対応していませんが、ComfyUI-nunchakuカスタムノードで利用できます。

モデル形式の情報量と精度の目安

形式	1データあたりの情報量	精度の目安	演算速度	備考
FP32	32 bit	標準精度	遅い(低速)	標準形式
BF16	16 bit	FP32とほぼ同じ	FP32より速い(中速)	生成時は FP32 と同等精度でより高速、FP32 から変換しやすい
FP16	16 bit	FP32とほぼ同じ	FP32より速い(中速)	FP32 より数値範囲が狭いので、FP32 から変換すると問題が生じる場合あり
FP8E4M3	8　bit	FP16 より落ちる	対応 GPU なら FP16より速い(高速)	FP16 より数値範囲が狭いのでうまく扱えない場合あり
FP8E4M3 scaled	8　bit	FP16 より落ちる	対応 GPU なら FP16より速い(高速)	FP16 とほぼ同じ数値範囲を扱えるよう工夫して変換した FP8E4M3
FP8E5M2	8　bit	FP8E4M3よりわずかに劣る場合が多い	対応 GPU なら FP16より速い(高速)	FP16 から変換しやすい
Q8_0	8.5 bit	FP16 より少し劣るが一般的には FP8 より良い	FP16 よりわずかに遅い(中速)	データサイズは 8 bit ではない
Q6_K	6.5625 bit	一般的には FP8 とほぼ同等	FP16 よりわずかに遅い(中速)	データサイズは 6 bit ではない
Q4_K_M	約4.84 bit	Q6_K よりやや劣るが一般的に実用的な精度	FP16 よりわずかに遅い(中速)	データサイズは 4 bit ではない
Q4_K_S	約4.58 bit	Q4_K_M より劣る	FP16 よりわずかに遅い(中速)	データサイズは 4 bit ではない
nunchaku FP4	約 4 bit のはず	FP8 よりやや劣る	FP8 より遥かに高速(超高速)	nunchaku 対応モデルのみ

モデル精度

モデルは通常モデル自体の精度のままで読み込みそのままの精度で演算しますが、上記のように、FP32 を BF16 にしても生成精度にはほとんど影響なく、VRAM の消費が半分になり、処理速度が向上します。

ComfyUI では model_management.py内で torch.cuda.get_device_properties() 等を用いて使用している GPU を調べ、BF16 対応 GPU なら自動的に FP32 のモデルを BF16 に変換して読み込み演算する機能が実装されています。

通常は手動でのオプション指定を行わなくても問題ありません。

手動オプション

--force-fp32
すべて FP32 (FP32 でないモデルでも FP32 に変換して)で演算します。通常は処理が遅くなりVRAM の消費が増えるだけで意味はほとんどありません。
--force-fp16
すべて FP16 (FP16 でないモデルでも FP16 に変換して)で演算します。
Qwen Image のように元のモデルが BF16 モデルでは無駄な変換ロスが発生しますし、VAE を FP16 にすると黒画面が生成される場合があるなど、FP32 や BF16 に比べて表現できる数値範囲が狭い FP16 では問題が起こりやすいので、注意してください。
--fp32-unet
--fp64-unet
--bf16-unet
--fp16-unet
--fp8_e4m3fn-unet
--fp8_e5m2-unet
--fp8_e8m0fnu-unet
④の Unet(もしくは DIT)を使った拡散処理のモデルの読み込み精度と演算精度の指定です。明示的に精度を指定したい場合に使えます。
--fp16-vae
--fp32-vae
--bf16-vae
⑤の VAE での処理のモデルの読み込み精度と演算精度です。明示的に精度を指定したい場合に使えます。ヘルプにあるように FP16 では扱える数値範囲の問題で黒画面が生成される場合があるので、有効にする場合は FP16 対応 VAE を使うなど気をつけてください。
--cpu-vae
⑤の VAE モデルをメインメモリに読み込み、CPU で演算するオプションです。一般的には非常に遅くなります。
--fp8_e4m3fn-text-enc
--fp8_e5m2-text-enc
--fp16-text-enc
--fp32-text-enc
--bf16-text-enc
③のテキストエンコーダを使ったプロンプトの処理モデルの読み込みや処理精度の指定です。明示的に精度を指定したい場合に使えます。

生成処理

サンプラーとスケジューラ

④では拡散モデルが文書トークンベクトルを使って潜在画像のノイズを除去することで画像を生成します。

潜在拡散モデルは小さなノイズを 1000 ステップ与えて学習していたので、除去には1000ステップ必要です。そのままの 1000 ステップが必要だと時間がかかりすぎるので、例えば、20 ステップをひとまとめにして、1 回分の変更量を 20 倍にして適用すれば、多少誤差がでますが、1000 ステップ ÷ 20 = 50 ステップですみます。

ComfyUI では、変更量の計算のアルゴリズムをサンプラーと呼び、ステップのまとめ方をスケジューラと呼んでいます。Kサンプラーノードでこれらを指定できます。

単純に 1 回の変更量×まとめたステップ数で処理するのが euler サンプラーで、単純に一定回数ごとに分割するのが normal や simple スケジューラだと思ってもらえばだいたい正解です。まとめて変更する際の変更量の計算の仕方やステップのまとめ方で補完精度が変わり、他のサンプラーやスケジューラーでは、単純な補完処理ではなく処理速度がかかるが誤差を減らせるような工夫を行っています。

通常は euler + normal で困らないと思いますが、別なサンプラーやスケジューラーに変更すると生成画像が変化するので試してみてください。

高速化 LoRA

あるモデルの動作を学習して別のモデルを作成することを蒸留といいます。

euler サンプラー＋ simple スケジューラーのようなアルゴリズムで複数ステップをまとめるのではなく、元のモデルの 250 ステップ後の変化を学習して、1 ステップで 250 ステップ後の変化を再現する新しいモデルを作れば、4 ステップで元のモデルの 1000 ステップ分を再現できます。

このような考え方に基づいて作成したモデルを潜在一貫性モデル(Latent Consistency Model、LCM)といいます。DMD2 や Lightning が具体的なモデル例です。LCM は高速化蒸留モデルを使う際に使用するサンプラーの名称にもなっています。

高速化蒸留モデルや高速化蒸留 LoRA を元のモデルに適用するワークフローを使えば、少ないステップ数で生成することが可能となり、生成を高速化できます。

注意機構

現在の生成 AI は注意機構(attention) を使って生成処理を行います。

ComfyUI でどの注意機構を使うかは、モデル管理と同様にcomfy/model_management.pyのENABLE_PYTORCH_ATTENTION = Falseあたりから実装されており、起動オプション指定内容とインストールされているモジュールと GPU に合わせて決定します。これに基づきcomfy/ldm/modules/attention.pyで実装されている注意機構が設定され、③のCLIPテキストエンコードや④のKサンプラーでの生成処理や⑤のVAEデコードノードなどが呼び出します。

ComfyUI 標準の動作はややこしいのですが、NVIDIA GPU の場合、xformers インストール時は xformers attention、xformers 未インストール時は PyTorch 2 以降では pytorch cross Attentionで、それ以前では split cross attention、AMD GPU の場合 xformers インストール時は xformers attention、xformers 未インストール時は K サンプラーやプロンプト処理は GPU や ROCmバージョンや PyTorchバージョンから pytorch cross Attention または　split cross attention　のどちらか、VAE はsplit cross attention になっています。

オプション未指定でも通常は問題ないですが、使いたい注意機構をオプションを明示的に指定することで高速化省メモリ化できる可能性があります。

注意機構のオプション

--use-pytorch-cross-attention
PyTorch 標準の注意機構を使用します。様々な改良が施されているので、新し目の PyTorch を使っているならこれで問題ないと思います。このオプションを指定しなくても自動的にこれになる場合が多いですが、AMD GPU では明示的にこのオプションを指定しないと split cross attention になってしまう場合があるので、明示的に指定したほうがいいかもしれません。
--use-split-cross-attention
モデルを分割して処理します。元々の ComfyUI 標準注意機構はこの split cross attention のようです(ldm/modules/diffusionmodules/model.pyの normal attention)。VRAM の消費が減る代わりに遅くなります。今はモデルの読み込み側での VRAM 消費の工夫があるので、積極的に使う必要はないと思います。なお、AMD GPU では VAE が強制的にこれになってしまいます。手元の Radeon 7800 XT では pytorch cross attention の方がうまく動くので、コメントアウトして pytorch cross attention で動くように修正しています。
--use-quad-cross-attention
モデルを split cross attention より細かく分割して処理します。VRAM の消費が減る代わりに遅くなります。VRAM が小さい場合を除いて使う必要はないと思います。
--disable-xformers
xformersはメモリ効率や処理効率を重視した注意機構です。すでに PyTorch 標準の注意機構で同等の機能が実装されているようなので、あえて使う必要はないと思います。なお、xformers がインストールされているときは常に xformers attention が使われます。xformers をインストールしているが xformers atteionを使いたくない場合にこのオプションを指定してください。カスタムノードによってはこのオプションを指定しても xformers attention を使う場合があるので(例:ComfyUI-DepthAnythingV2)、完全に使いたくない場合は xformers をアンインストールしてください。
--use-sage-attention
拡散モデルの処理やテキストエンコーダの処理にsage attentionを使うオプションです。SageAttention1は 8 bit 処理、SageAttention2 は INT4、SageAttention3 は FP4 を活用するようです。有効にすると高速化したり VRAM の消費が抑えられる場合があります。特にGeforce 5000番代では SageAttention3を使うと高速化できる可能性があります。GPU によって動作が異なるので、有効にした場合と無効にした場合で比較し結果がよければ有効にしてください。
--use-flash-attention
拡散モデルの処理やテキストエンコーダの処理にflash attentionを使うオプションです。FlashAttention2 でメモリ効率をメインに改善できるようですが、Pytorch 標準の注意機構に同じような機能が入っているような気がします。FlashAttention3 ではさらに FP8 を活用するようです。GPU によって動作が異なるので、有効にした場合と無効にした場合で比較し結果がよければ有効にしてください。
--fast
Fp16Accumulation Fp8MatrixMultiplication CublasOps AutoTuneのオプションをそれぞれ指定できます。単に--fastとした場合はすべて有効になります。GPU によって動作が異なるので、有効にした場合と無効にした場合で比較して有効にすべきか決めるべきだと思いますが、コードを眺めた限り、つけても害はないが良くもならない場合が多いと思います。

その他

以前より PyTorch は進化し、ComfyUI 本体の機能が充実しています。

PyTorch は古い NVIDIA GPUでない限り 2.8 以降に上げ、ComfyUI も最新版まで上げましょう。カスタムノードで block swap などを使って手動で設定するより、今は ComfyUI に任せたほうがよいと思います。

更新履歴

2025/11/28
AMD の RDNA 3 (Radeon 7800 XT)でも ComfyUI や musubi-tuner で FP8 が動くようなので修正
2025/11/2
公開