高速化と軽量化とは？
Stable Diffusion 1.5 は登場当初、推奨 VRAM が 10GB 程度とされ、RTX 3080 クラスで 1 枚生成するのに 5 秒前後かかる、というベンチマーク結果が多く報告されていました。
それも今や昔。技術の進歩により、現在では CPU のみで数秒〜十数秒程度で推論できたり、1 秒間に何十枚も画像を生成できるようになってきました。
拡散モデルの歴史は、ある意味では 「高速化と軽量化の歴史」 と言ってしまっても良いでしょう。
ここで注意したいのは、次の 2 つは似ているようで別物だということです。
- 高速化：同じハードウェアで、1 枚あたりの生成時間を短くする
- 軽量化：同じモデルを、より少ない VRAM・メモリで動かせるようにする
軽量化のための技術（量子化 / GGUF など）を使うと、VRAM は削減できても、場合によっては推論速度がむしろ低下することもあります。
このページでは「軽量化」を、主にモデルの VRAM 使用量削減のこととして扱います。
このページのざっくり地図
まず、よくある目的ごとに、どのあたりの技術が関係してくるかをざっくり整理しておきます。
-
とにかく速くしたい
- 蒸留（Lightning / schnell / 各種 one-step 系）
- 小型 VAE（TAE など）
- Attention 最適化（FlashAttention 系など）
- サンプリングキャッシュ（TeaCache 系など）
-
VRAM を削りたい / とにかく動かしたい
- 量子化（8bit / 4bit）
- GGUF
- CPUオフロード / Block Swap
- VAE タイル化（Tiled VAE / Temporal Tiling）
SageAttention や Nunchaku のようなものも有名ですが、導入難度が高いので、このサイトでは扱いません。苦労より安定を取りましょう。
主な高速化・軽量化手法の一覧
- 高速化 / 軽量化 は、おおまかな効き具合（◎ > ○ > △ > ―）
- 導入難度 は「易 / 普 / 難」で、セットアップの手間と既存 workflow への組み込みやすさの目安です。
| 手法名 | タイプ | 高速化 | 軽量化 | 導入難度 |
|---|---|---|---|---|
| 8bit 量子化 | モデルの量子化 | △〜○ | ○（VRAM をざっくり半分に削減） | 易 |
| 4bit 量子化 | モデルの量子化 | △ | ◎（VRAM を大きく削減） | 難 |
| GGUF | 専用フォーマット + 量子化 | △ | ◎（モデル容量・VRAM 削減） | 普 |
| 蒸留モデル | モデル蒸留（Lightning / schnell） | ◎ | ―（モデルサイズはほぼ同じ） | 普 |
| Attention 最適化 | Attention 実装の置き換え | ○ | ― | 普〜難 |
| サンプリングキャッシュ | サンプリングのキャッシュ | ○ | ― | 難 |
| 小型 VAE | 蒸留された VAE | ○〜◎ | △（VAE 部分だけ軽くなる） | 普 |
| CPUオフロード | モデルの一部を CPU/RAM に退避 | ✕ | ◎（VRAM を数 GB まで削減可能） | 易 |
| Block Swap | Transformer ブロック単位の退避 | ✕ | ◎ | 易 |
| VAE タイル化 | 画像・動画をタイル分割して処理 | ― | ○（大解像度時の VRAM 節約） | 普 |
量子化
8bit 量子化
8bit 量子化は、モデルの重みを 8bit（INT8 や FP8 系）に落とし込むことで、VRAM 使用量をざっくり半分程度に抑える手法です。 多くの環境では、画質の劣化はほとんど気にならず、速度もほぼ変わらないか、わずかに改善する程度に収まります。
モデル名に fp8 と付いているチェックポイントなども、この 8bit 系の軽量版だと考えてかまいません。
4bit 量子化
4bit 量子化は、さらにビット数を削って VRAM を大きく節約する手法です。 そのぶん重みの再構成や数値誤差の影響が大きくなり、色やディテールの破綻が目につきやすく、現時点では「実験的な領域」と見ておくのが無難です。
SVDQuant や、その 4bit モデルを高速に動かす Nunchaku のようなスタックもありますが、導入や設定の自由度が高く、ここでは詳しく扱いません。
GGUF
GGUFは、量子化済みの重みを格納するための専用フォーマットです。 （補足として） これは、CPUメモリ (RAM) からの推論を効率的に行うことを主眼として設計されており、VRAMが不足している環境でも動作させやすいことが大きな特徴です。
ComfyUI では city96/ComfyUI-GGUF を導入すれば、Load Diffusion Model ノードを GGUF 用ノードに置き換え、GGUF モデルを指定するだけで使えます。
蒸留
蒸留は、教師モデルのふるまいを別のモデル（あるいは LoRA）に教え込む手法で、拡散モデルでは主に「少ないステップで同等の画像を出せるようにする」目的で使われます。
代表例
- FLUX.1-schnell のような「高速版」チェックポイント
- Qwen-Image-Lightning のような、高速生成 LoRA
ステップ数を 1〜4 steps 程度まで削れることもあり、とにかく速くしたいときの第一候補になります。
Attention 最適化
拡散モデルでは Self-Attention が重い処理なので、ここを速くする実装がいくつか提案されています。
- PyTorch 2 系の
scaled_dot_product_attention（FlashAttention 系） - 各種ライブラリが提供する高速化された Attention カーネル
こうした実装を使うと、モデル自体を変えなくても数十％の速度向上が見込めることがあります。 一方で、SageAttention のようにビルドや専用ノードが必要な実装もあり、導入難度が高いため、このサイトでは扱いません。
サンプリングキャッシュ
サンプリングキャッシュは、「サンプリング途中の一部ステップの結果をキャッシュして再利用し、計算をサボる」系の高速化手法の総称です。 TeaCache や MagCache のようなものが ComfyUI には実装されています。
追加学習なしに高速化できる一方で、他手法に比べると明らかな劣化が現れやすいです。
小型 VAE
小型 VAE は、元の VAE を蒸留して小さくしたもので、decode を高速化します。
代表例としては TAE（Tiny AutoEncoder 系）があり、リアルタイムプレビューや中間確認に使われています。
CPUオフロードと Block Swap
CPUオフロードは、VRAM が足りないときにモデルや中間テンソルの一部を CPU 側（RAM）に退避させる仕組みです。 CUDA OOM を避けやすくなる代わりに、PCIe 経由の転送が多くなるため、生成時間は一気に伸びます。
ComfyUI では、設定やノードに応じて内部で自動的にオフロードを行うことがあり、ユーザーが意識しなくても勝手に動いていることがあります。 「やけに 1 枚あたりの時間が長い」と感じたら、裏側で CPUオフロードや Block Swap が働いている可能性を疑ってみてもよいかもしれません。
Block Swap は、Transformer をブロック単位に分割し、「今必要なブロックだけを GPU に載せる」ように出し入れを制御する仕組みです。 どちらも RAM に逃がす点は同じですが、Block Swap のほうがより細かく VRAM のピークを抑えることを狙った手法で、大型の動画モデルなどで使われています。
VAEタイル化
VAEタイル化は、画像や動画をタイル状に分割して encode / decode することで、1 回あたりに処理する領域を小さくする手法です。
例えば画像を 4 分割して処理すれば、各タイルで必要な VRAM と計算量はおおよそ 1/4 になります。
このおかげで、本来ならメモリ的に無理なサイズの画像や、超高解像度の decode でも、なんとか処理できるようになります。
VAE decode に異常に時間がかかる場合や、4K 以上の画像を扱いたい場合に、試してみてください。