画像生成AI の登場から３年！　最新のモデルを高速に実行する方法を徹底検証【HiDream, Flux.1 Krea】

2025.12.24 追記

ComfyUI のアップデートで、テキストエンコーダーがデフォルトで RAM にロードされて CPU で処理が行われるようになりました。

本記事の device 設定 をしなくても、最適な処理が行われるようになっています。

はじめに

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

今回は、最新の 画像生成 AI モデルを高速に実行する方法について考えます。

画像生成 AI モデル は巨大化している

ローカルの画像生成は、今日からちょうど３年前の 2022年8月22日 に公開された Stable Diffusion 1 から始まりました。

この３年の間に 画像生成 AI は大きく進化しましたが、それと同時に モデルの容量も巨大化 しています。

モデルが VRAM に収まらない！

現在、コンシューマー向け最高性能の NVIDIA RTX 5090 の VRAM容量は32GB ですが、Flux.1 以降のモデルは容量が 32GB を超えているため、RTX 5090 を使っても モデルの全てを VRAM にロードすることはできません。

主な NVIDIA GPU の VRAM 容量

AI タスクは、VRAM の運用方法で所要時間が大きく変わりますが、大容量の 画像生成 AI モデルは どのようにモデルを分割してメモリへのロードするか が、イラストの生成時間を決めるカギになってきます。

測定環境

今回は、次の環境で生成時間の検証を行います。

• windows 11

• RTX 4060 Ti 16 GB

• RAM 64GB

１回目と２回目の生成時間が同じ

まずは、ローカル画像生成 AI の最大のモデルの HiDream でイラストの生成時間を調べてみます。

最初に通常通り１回目の生成を行い、さらにプロンプトを変えて２回目の生成も行います。

HiDream-I1-Dev, 1024 x 1024,  8steps

ComfyUI のデフォルトのワークフローでは、テキストエンコーダーとトランスフォーマーはいずれも VRAM にロードされて、GPU で処理が行われています。

• テキストエンコーダー ➡ VRAM（競合）

• トランスフォーマー ➡ VRAM（競合）

HiDream のモデルの容量は VRAM よりも大きいため、テキストエンコーダーとトランスフォーマーの間で VRAM の競合 が発生します。

１度使ったモデルは RAM に保持されているので、2回目はストレージからのモデルの読み込みは発生しませんが、VRAM と RAM の間でテキストエンコーダーとトランスフォーマの入れ替えが起こり、２回目の生成も１回目と同じ所要時間 がかかります。

テキストエンコーダーを RAM にロードすると、速度が２倍になる！

今度は、VRAM の競合を防ぐために、テキストエンコーダーを明示的に RAM にロードして CPU で処理を行ってみます。

エンコード処理を GPU から CPU に切り替えるには、ComfyUI-MultiGPU カスタムノードパックの QuadrupleCLIPLoaderMultiGPU ノードを使い、device を CPU に設定します。

• テキストエンコーダー ➡ RAM

• トランスフォーマー ➡ VRAM

テキストエンコーダーを RAM にロードして CPU で処理すると、プロンプトのエンコード時間は２倍に伸びましたが、画像の生成は速くなり ２回目の生成時間が半分 になりました。

HiDream はモデルの容量が巨大なので、プロンプトのエンコードよりも モデルの移動 の方がずっと長い時間がかかります。

今回の設定だと、テキストエンコーダーは RAM に、トランスフォーマーは VRAM に保持されたまま モデルの移動が起こらない ので、結果的に画像の生成が速くなるのです。

CPU は FP32 形式で処理を行う

今度は、CPU の処理についてもう少し詳しく見ていきます。

コンピュータは、AI タスクを行うときの演算を 浮動小数点計算（FP：Floating Point）で行っています。

浮動小数点計算の種類と精度

• FP32：高精度・高負荷

• FP16：精度が低下するが、処理は速くなる

GPU と浮動小数点計算の対応

CPU と浮動小数点計算の対応

FP16 以下の形式は FP32 より高速に処理を行えますが、FP16 形式 が普及したのはここ数年のことで、NVIDIA の RTX シリーズ 以外の GPU・CPU ではあまり対応は進んでいません。

CPU は、最新のフラッグシップモデルを除いて、FP32 形式 で処理を行っています。

ComfyUI のデフォルトは FP16 形式

一方で、ComfyUI はデフォルトではテキストエンコーダーを FP16 形式 で処理します。

今回の CPU のように、デバイスが FP16 形式に対応していない場合は、FP32 の処理上で仮想的に FP16 を実行するので、結果的に FP32 と同じ所要時間 がかかります。

CPU でエンコード処理を行うとき、FP32 形式 のテキストエンコーダーが配布されている場合は、ComfyUI の起動時に --fp32-text-enc を指定して FP32 形式で処理を行うと、同じ所要時間で精度を上げる ことができます。

FP32 形式を使うと、step を少なくできる！

それでは、FP32 形式のテキストエンコーダーが利用できる Flux.1 Krea [dev] モデルで、FP16 形式と FP32 形式のテキストエンコーダーのイラストを比べてみます。

FP16 Text Encoder 18 steps

Flux.1 Krea [dev] モデルは、高解像度でイラストを生成するときはノイズを多く使うため、FP16 形式だと収束するまでに 18 step かかります。

FP16 Text Encoder 16 steps

FP16 形式の 16 steps では、モニター上のアイコンや背景が未完成になっています。

FP32 Text Encoder 16 steps

一方で、FP32 形式のテキストエンコーダーを使うと、イラストのクオリティが上がるだけではなく、画像の収束も速く なり 16 steps でイラストが完成 するようになりました。

キャッシュを使って高速化する！

同じプロンプト で複数枚の画像を生成する場合、プロンプトのエンコード結果（conditioning）は キャッシュに保存 されて、２回目以降はキャッシュを使ってエンコードの処理自体がスキップされます。

つまり、一度 FP32 形式のテキストエンコーダーで高精度のキャッシュ を生成すれば、その後もずっとキャッシュを使い続ける ことができます。

FP16 Text Encoder 18 steps

FP32 Text Encoder 16 steps

FP32 形式のテキストエンコーダーは画質が向上するだけでなく、step 数を少なくする ことができるので、結果として FP16 形式より 高速化 につながります。

精度の高いモデルは収束が速い！

今回は、テキストエンコーダーの精度と生成時間を検証しましたが、画像を生成するトランスフォーマーも、同じように 精度の高いモデル の方が 収束は速く なります。

新世代の 画像生成 AI を使うときは、 VRAM を全てトランスフォーマーに割り振って、なるべく精度の良いモデルを利用するのが良いと思います。

ComfyUI のモデル別のトランスフォーマーの最小分割容量

VRAM が不足する環境では、FP8 や GGUF 形式などのモデルの軽量化は確かに有効ですが、逆に VRAM が確保できる環境下では、軽量化はイラストの収束を遅らせる 場合があることを覚えておきましょう。

ワークフロー

今回の検証で利用したワークフローはこちらです。

HiDream-I1-Dev 8steps

使用モデル

• HiDream_I1_Dev_BF16.safetensors

• Llama-3.1-8b-instruct-BF16.safetensors

• flan-t5-xxl_TE-only_FP32.safetensors

• CLIP-ViT-bigG-14-laion2B-39B-b160k-FP32.safetensors

• CLIP-SAE-ViT-L-14-FP32.safetensors

• FLUX1-schnell-AE-FP32.safetensors

HiDream について

Flux.1 Krea [dev] 16steps

使用モデル

• flux1-krea-dev.safetensors

• flan_t5_xxl_TE-only_FP32.safetensors

• CLIP-SAE-ViT-L-14-FP32.safetensors

• ae.safetensors

カスタムノードの紹介

今回利用した、ComfyUI のカスタムノードをご紹介します。

ComfyUI-Dev-Utils

ComfyUI-Dev-Utils は、ComfyUI 実行中の各ノードの所要時間と VRAM の使用量を表示するカスタムノードです。

ComfyUI-Dev-Utils を使うとノードの左上に所要時間と使用した VRAM の容量が表示されるほか、全てをまとめた一覧表も出力することができます。

ComfyUI-MultiGPU

ComfyUI-MultiGPU は、ComfyUI 上で複数の GPU の VRAM を利用できて、処理を CPU にも切り替えができるカスタムノードです。

ComfyUI-MultiGPUについて

まとめ：テキストエンコーダーは RAM にロードする

• テキストエンコーダーは RAM にロードする

• 高精度のモデルを使い、キャッシュを利用する

• step を思い切って減らしてみる

新世代の画像生成 AI モデルは、容量が大きく画像の生成に時間がかかります。

一方で、画像生成 AI における 画質 と 生成速度 は決して二者択一ではなく、PC の性能とモデルの容量に合わせた最適なセッティングを行えば、その 両方がついてきます。

画像生成には、さまざまな高速化技術がありますが、高速化技術でも 精度の悪化 を伴うものは結果として生成時間が延びる可能性もあり、そのメリットとデメリットについて十分に理解することが必要です。

皆さんも、新世代モデルで美しいイラストを生成しながら、デメリットのない高速設定 を試してみてはいかがでしょうか？

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

関連記事

ComfyUI の VRAM 管理の最適化

ComfyUI で次世代モデルを使うときは、VRAM 管理の最適化をオススメします。

更新履歴

2026.5.25

GPU と浮動小数点計算の対応表を更新しました

2025.8.26

ワークフローの CLIP-SAE-ViT-L-14-FP32.safetensors のスペルミスを修正し再アップロードしました

English Article