【ComfyUI 上級】 カスタムノードで高速化！　速度と画質のトレードオフ

はじめに

こんにちは、きまま / Easygoing です。

今回は ComfyUI 上級編で、カスタムノードを使った高速化について見ていきます。

高速化するカスタムノード

今回ご紹介するカスタムノードのは次の２つです

1. ComfyUI-MultiGPU（VRAM 管理を最適化）

2. ComfyUI-TeaCache（キャッシュを利用して高速化）

１．ComfyUI-MultiGPU

最初にご紹介するのは、ComfyUI-MultiGPU です。

ComfyUI-MultiGPU は、VRAM の管理を最適化 するカスタムノードです。

ComfyUI-MultiGPU を使うと複数の GPU の VRAM を利用できるので、メモリ利用の効率を上げることができます。

また、モデルのロード先を VRAM ではなく システムRAM に設定することもできるので、GPU が１つしかない場合でも必須 のノードになります。

ComfyUI-MultiGPU のインストール

それでは、ComfyUI-MultiGPU の使い方です。

まず、ComfyUI-Manager を使って ComfyUI-MultiGPU をインストールします。

GGUF 形式のファイルを使うときは ComfyUI-GGUF、Florence-2 モデル使うときは ComfyUI-Florence2 カスタムノードをあらかじめインストールする必要があります。

ComfyUI-MultiGPU の設定！

ComfyUI-MultiGPU は次のように設定します。

モデルのロード先

• cuda：VRAM

• cpu：システム RAM

モデルのコンポーネントのうち、テキストエンコーダーは処理が軽いので、システムRAM にロードしてもあまり所要時間は変わりません。

一方で、UNET / Transformer と VAE は重い処理が必要なため、モデルの入れ替えをしながらでも メイン の VRAM を利用した方が高速です。

複数のGPU を搭載しているとき

複数の GPU を搭載しているとき、演算はあくまでメインの GPU が行いますが、ComfyUI-MultiGPU を使うとモデルのロード先を任意に指定することができます。

サブの GPU の VRAM は、一般的に システムRAM より高速 に動作します。

使用例の紹介

それでは、私の環境での実際の使用例を紹介します。

構成

• Ryzen APU（cpu）

• RTX 4060 Ti  16GB（cuda:0）

• GTX 1070  8GB（cuda:1）

ワークフロー

ロード設定

• UNET / Transformer 、VAE → cuda:0

• Florence-2 、テキストエンコーダー（AuraFlow） → cuda:1

• テキストエンコーダー（Flux.1 / SDXL） → cpu

UNET / Transformer と VAE は、モデルの入れ替えをしながらでも メイン の VRAM を利用した方が高速です。

一方で、Florence-2 は サブ の GPU の VRAM にロードしても、それなりに高速に動作します。

サブ の GPU の VRAM は、Florence-2 をロードしてもまだ容量に余裕があるので、残りの VRAM 容量に収まる AuraFlow のテキストエンコーダーも割り当てています。

こうすることで モデルの移動が最低限 になり、処理にかかる時間を節約することができます。 

モデルのコンポーネントを分離する！

SDXL や Flux.1 の一部のモデルのコンポーネントは結合して配布されていますが、次の方法で簡単に分離できます。

コンポーネントを分離すると、ComfyUI-MultiGPU でロード先を個別に設定することができ、また共通のコンポーネントを使うときは一度だけ呼び出せばよいので、メモリやストレージの節約にもつながります。

２．ComfyUI-Teacache

後半は、ComfyUI-TeaCache をご紹介します。

ComfyUI-TeaCache は次の２つのアプローチで処理を高速します。

• キャッシュを利用して演算をスキップ（TeaCache）

• モデルを演算に最適な形に圧縮（torch.compile）

キャッシュを利用した高速化

まず、キャッシュを利用した高速化について見ていきます。

画像生成におけるキャッシュは、計算の際に前回と結果があまり変わらないと予想される場合に、前回の計算の結果をそのまま使って演算をスキップ する仕組みです。

TeaCache の使い方

TeaCache ノードは、Flux.1 と 動画生成AI に対応しています。

設定項目

• rel_l1_thresh（0～1）：どの程度までキャッシュを適応するか

• max_skip_steps（1～3）：キャッシュの連続適用上限

rel_l1_thresh と max_skip_steps は、いずれも数値が大きいほど高速化しますが、その分画質も低下します。

実際の測定！

それでは、Flux.1 で rel_l1_thresh と max_skip_steps を変化させたときの速度と画質のバランスを見てみます。

条件

• blue_pencil-flux1-v0.0.1-BF16

• 1440 x 1440

• eular

• normal  30steps

max_skip_step = 1

max_skip_step = 2

max_skip_step = 3

• 横軸：生成にかかった時間

• 縦軸：画質（元画像との類似度）

グラフは上にあるものほど画質が良く、左に行くほど高速に生成できることを示しています。

いずれのグラフを見ても、高速化に比例して画質が低下 しています。

max_skip_step を比べると、どの設定でも特にバランスは変わりなく、Teacache を使う場合は最大設定の max_skip_steps = 3 で良いと思います。

実際の画像の比較

TeaCache の最大設定では、所要時間がおよそ ３分の１ になっています。

それでは、画質について実際のイラストを比較してみます。

イラストを比較すると、キャッシュを利用した画像は 指や文字 が不正確になり、背景もぼやけて単純化 されているのが分かります。

TeaCache は高速化の効果は大きいですが、右のイラストが許容できるかはケースによって違ってくるでしょう。

個人的には、下描きの時は TeaCache を最大限に利用 して、本番ではキャッシュを利用しない使い方が良いのではないかと思います。

WaveSpeed の First Block Cache と比較

TeaCache に似た機能として、以前に WaveSpeed の First Block Cache をご紹介しました。

First Block Cache は TeaCache を拡張して開発された機能で、Flux.1 だけでなく SDXL と SD 3.5 でも利用することができます。

First Block Cache は TeaCache より条件を細かく設定でき、適切なセッティングを行うと TeaCache より画質の低下を抑える ことができます。

一方で、First Block Cache の最大設定では満足な画像は得られないので、調整に TeaCache より時間がかかります。

手軽に使うなら TeaCache、高速化しつつ画質も追求するなら First Block Cache という使い分けが良いでしょう。

torch.compile の導入

ComfyUI-TeaCache では、torch.compile という機能でさらに処理を高速化することができます。

torch.compile の導入はやや難しいので、実際の手順は あっきょす さんの記事を参考にして下さい。

torch.compile は、演算を行う前にモデルを最適な形に圧縮します。

torch.compile を使うと、初回の画像の生成は遅くなりますが、2回目以降は処理が高速化します。

torch.compile の設定

torch.compile を利用できるノードには、ComfyUI デフォルトの TorchCompileModel ノードと、ComfyUI-TeaCache の Compile Model ノードがあります。

私の環境では、デフォルトの TorchCompileModel ノード を使っても効果はなかったので、ここでは Compile Model ノード を紹介します。

設定値

• mode

  • default：デフォルトの最適化、バランス設定

  • max_autotune：最大のパフォーマンス

• backend

  • inductor：PyTorch 標準の高速化

  • cudagraph：NVIDIA CUDA 専用の高速化

• fullgraph：モデル全体をコンパイル、速度上昇、コンパイル時間増加

• dynamic：可変サイズ入力、inductor のみ対応

torch.compile の高速化

私の環境での、CompileModel ノード の２枚目以降の画像の生成時間は次の通りです。

CompileModel ノードは、mode が default のとき 約 14 % 高速化 しましたが、max_autotune では変わりませんでした。

backend は cudagraph に指定した場合、画質の劣化はありませんでした。 

Sage Attention と FP8 形式を使う

最後に、ComfyUI-TeaCache 以外の高速化を２つご紹介します。

① Sage Attention

参考：GJL さんの記事

Sage Attention は、新しい Python ライブラリーを利用した高速化技術です。

Sage Attention 導入は、先ほどの あっきょすさんの記事 を参考にしてください。

実行するときは、ComfyUI の起動時に --use-sage-attention を指定します。

Sage Attention は 16 % ほど高速化 して、画質は少し劣化 します。

② FP8 形式 の利用

Nvidia の RTX 4000 以降 の GPU を利用している場合、FP16・BF16 形式の代わりに FP8 形式を利用すると高速化します。

FP8 形式には、次の２種類があります。

• FP8e4m3 形式：現在の主流

• FP8e5m2 形式：精度が低く、今はあまり使われない

FP8e4m3 形式を使うときは、ComfyUI の起動時に --fp8_e4m3fn-unet を指定します。

FP8 形式を利用するとそれなりに高速化しますが、画質は相応に劣化 します。

参考：FP8 形式の画質の比較

なお、FP8 形式 は 非対応の GPU で指定すると逆に処理が遅く なる場合があるのでご注意ください。

まとめ：速度と画質のトレードオフ

• ComfyUI-MultiGPU は必須のノード

• TeaCache と Wavespeed は効果が大きいが、画質も低下

• torch.compile は、適切な設定で劣化しない

今回ご紹介したカスタムノードのうち、ComfyUI-MultiGPU はデメリットがないので必須のカスタムノードです。

キャッシュを利用する TeaCache と WaveSpeed は、効果が大きいものの画質の劣化もあるので、イラストの下描きなどで導入すると良いと思います。

torch.compile は、自分の環境で試して劣化が無いようであれば導入をお勧めします。

今回紹介した方法は、いずれも違ったメカニズムで機能するので、組み合わせると 相乗効果 があります。

高速化機能の多くは、「わずかな画質の劣化と引き換えに高速化する」と紹介されていますが、実際は環境によって変わってくるので、使う前に自分で確かめる必要があります。

今回の検証で利用した、画像の差を数値で比較できるページ も公開していますので、みなさんもぜひ試してみて下さい。

最後までお読みいただきありがとうございます！

参考：今回測定したデータ

English Article