ComfyUIでGGUF版のHiDream-I1を試す(推奨VRAM 12GB)
Last update 7-10-2025
※ 最小サイズのGGUFモデルを使用して、VRAM 8GBで生成できる可能性があります(未検証)。ただし、品質が非常に劣ります(4-2.を参照)。
※ 記事中でも書いたとおり、プロンプトを変更した場合は生成開始前に「Unload Models」を実行する必要があります(3-1.を参照)。
■ 0. 概要
▼ 0-0. はじめに
前回の記事では、ComfyUIでFP8形式の「HiDream-I1」モデルを利用しました。本記事では、VRAM 12GBの動作も可能なGGUF形式のモデルを扱います。
▼ 0-1. 関連リンク1
公式のリポジトリとモデルです(前回の記事と同じ)。
HiDream-I1
https://github.com/HiDream-ai/HiDream-I1HiDream-I1 Full/Dev/Fast (Model)
https://huggingface.co/HiDream-ai/HiDream-I1-Full
https://huggingface.co/HiDream-ai/HiDream-I1-Dev
https://huggingface.co/HiDream-ai/HiDream-I1-FastHiDream-E1 Full (Model)
https://huggingface.co/HiDream-ai/HiDream-E1-Full
▼ 0-2. 関連リンク2
本項は、本記事で説明する内容に直接関係します。
gguf node for comfyui
https://github.com/calcuis/gguf
※ ComfyUIでGGUF形式を扱うための拡張機能calcuis/hidream-gguf
https://huggingface.co/calcuis/hidream-gguf
※ GGUF版のモデルMaziyarPanahi/Meta-Llama-3.1-8B-Instruct-GGUF
https://huggingface.co/MaziyarPanahi/Meta-Llama-3.1-8B-Instruct-GGUF
※ Text Encoderとして利用するLlama
▼ 0-3. 補足
モデルの設置場所が、過去の筆者の記事での説明と異なっているので、念のためお知らせします。どちらの場所に設置しても同様に認識します。
models\unet\ → models\diffusion_models\
models\clip\ → models\text_encoders\
なお、筆者は種類ごとにディレクトリを分けて設置する方針をとっています(models\diffusion_models\hidream-i1\ 等)。
■ 1. 使用リソース
▼ 1-1. VRAM使用量
Modelの量子化タイプは、VRAMが16GBの場合はQ8_0まで、12GBの場合はQ5_K_Mまで利用できるとみられます。ModelもText Encoderも、共有GPUメモリにはみ出すと処理時間がかなり増えます。タスクマネージャーで確認すると良いでしょう。
ComfyUIの仕組み上、VRAM使用量は必要最小限ではなく多めになります。下記は参考としてご覧ください。
筆者の環境(VRAM 16GB、アイドル時の使用量は1.4GB程度とする)では、Text Encoderのロード時に11.0GB程度、生成時はModelがQ4_K_Mの場合で14.0GB程度、Q2_K_Mでは9.7GB程度、Q5_K_M以上は15.3GB(ほぼ上限)となりました。

▼ 1-2. 生成時間
下記は筆者の環境(RTX 5060 Ti)にて、Q4_K_Mを利用した場合の1枚あたりの生成時間です。モデルの読み込み時間、プロンプトの処理時間は含まれていません(筆者の環境では両方合わせて20秒程度)。
Fast … 63秒(16 Steps)
Dev … 108秒(28 Steps)
Full … 377秒(50 Steps)
生成時間は量子化タイプによっても多少異なり、FastのQ2_Kでは58秒、Q8_0では69秒となりました。
参考まで、FP8版では55秒、95秒、320秒となっていたので、生成速度はGGUF版の方が少し遅いようです。
■ 2. 準備
▼ 2-1. はじめに
Model、Text Encoder、VAEのいずれもGGUF形式を用います。Modelの量子化タイプによっては、ComfyUI標準の方法(FP8)よりもVRAM使用量が減らせるメリットがあります。
▼ 2-2. 拡張機能のインストール
通常版(ComfyUIのインストール先にvenvディレクトリがある)の場合は、下記の手順でインストールできます。1行目は適宜読み替えてください。
cd \aiwork\ComfyUI\custom_nodes
..\venv\Scripts\activate
git clone https://github.com/calcuis/gguf
pip install ggufポータブル版の場合は、インストール先のルートディレクトリ(起動用のバッチファイルがある)に移動の上、gitコマンド(要Git)と内蔵のpython_embededを使用します。1行目は適宜読み替えてください。こちらの手順は未確認ですのでご了承ください。
cd \aiwork\ComfyUI_windows_portable\ComfyUI\custom_nodes
git clone https://github.com/calcuis/gguf
..\..\python_embeded\python .\python_embeded\Scripts\pip install gguf▼ 2-3. モデルの設置(Model)
ModelはFullとDevとFastがあります。下記のURLにModel、Text Encoder、VAEのいずれも掲載されていますが、一部は別のものを使用します。
calcuis/hidream-gguf
https://huggingface.co/calcuis/hidream-gguf
Modelの量子化タイプは、品質的にQ4_K_M以上を推奨します。VRAMが16GBの場合はQ8_0まで、12GBの場合はQ5_K_Mまで利用できるとみられます。後者はおそらくギリギリなので、Q5_K_S以下の選択肢も検討してください。
hidream-i1-fast-q4_k_m.gguf (11.7 GB)
ファイルは「models\diffusion_models\hidream-i1\」へ移動します。
▼ 2-4. モデルの設置(Text Encoder1)
※ Llama 3.1 8B Instructは別のものを利用します(2-5.に記載)
次はText Encoderです。通常は4種類すべてを使用します。個人的には非推奨ですが、「CLIP_GとLlama 3.1 8B Instructのみ」や、「Llama 3.1 8B Instructのみ」でも生成できます(生成結果は4-3.を参照)。
ファイルは「models\text_encoders\hidream-i1\」へ移動します。
clip_g_hidream_fp32-f16.gguf (1.29GB)
clip_l_hidream_fp32-f16.gguf (236MB)
t5xxl_fp32-q4_1.gguf (2.84GB)
llama-q2_k.gguf (2.96GB) ※本記事では利用しない
▼ 2-5. モデルの設置(Text Encoder2)
Text Encoderの「Llama 3.1 8B Instruct」は、別のものを利用した方が出力が良くなることが確認できました。本記事では下記を利用します。2-7.にて、別のURLも案内しています。
MaziyarPanahi/Meta-Llama-3.1-8B-Instruct-GGUF
https://huggingface.co/MaziyarPanahi/Meta-Llama-3.1-8B-Instruct-GGUF
Meta-Llama-3.1-8B-Instruct.Q2_K.gguf (2.95GB)
ファイルは「models\text_encoders\hidream-i1\」へ移動します。
Q2_Kよりもサイズの大きな量子化タイプを選んだ場合、共有GPUメモリにはみ出さないように気をつけてください。プロンプトの処理時間がかなり長くなります。
▼ 2-6. モデルの設置(VAE)
URLは2-3.と同じです。ファイルは「models\vae\」へ移動します。
pig_flux_schnell_vae_fp32-f16.gguf (160MB)
▼ 2-7. 補足
2-3.に記載したModelについて、量子化タイプ別のファイルサイズを一部記載します(k-quantとQ8_0のみ)。
7.13 GB … Q2_K
8.66 GB … Q3_K_S
9.18 GB … Q3_K_M
9.66 GB … Q3_K_L
11.1 GB … Q4_K_S
11.7 GB … Q4_K_M
12.6 GB … Q5_K_S
13.1 GB … Q5_K_M
14.6 GB … Q6_K
18.4GB … Q8_0
15.9 GB … FP8(※ Comfy Org版)
2-4.に記載した「t5xxl_fp32-q4_1.gguf」と「llama-q2_k.gguf」については、下記のURLに他の量子化タイプが掲載されています。
t5-v1_1-xxl-encoder-fp32-gguf
https://huggingface.co/chatpig/t5-v1_1-xxl-encoder-fp32-gguf
llama-3.1-8b-encoder-gguf
https://huggingface.co/chatpig/llama-3.1-8b-encoder-gguf
2-5.に記載したGGUF版の「Llama 3.1 8B Instruct」よりも下記の方が、より多くの量子化タイプが掲載されています。
bartowski/Meta-Llama-3.1-8B-Instruct-GGUF
https://huggingface.co/bartowski/Meta-Llama-3.1-8B-Instruct-GGUF
■ 3. 生成
▼ 3-1. 概要
2.の続きです。3種類(Fast、Dev、Full)のワークフローと生成画像を掲載します。参考まで、2-4.で触れた「2種類または1種類のみのText Encoder」も試せるようにノードを用意しました。
利用にあたり注意点があります。2回目以降でプロンプトを変更した場合は生成開始前に「Unload Models」を実行してください。専用GPUメモリ(VRAM)にデータが残った状態のままText Encoderのロードが行われて共有GPUメモリにはみ出し、プロンプトの処理時間がかなり長くなる場合があります。これは拡張機能の問題(現状の仕様)とみられるので、後に改善される可能性があります。

ワークフローでは下記のモデルが設定されていますので、適宜変更してから使用してください。
hidream-i1-****-q4_k_m.gguf
clip_g_hidream_fp32-f16.gguf
clip_l_hidream_fp32-f16.gguf
t5xxl_fp32-q4_1.gguf
Meta-Llama-3.1-8B-Instruct.Q2_K.gguf
pig_flux_schnell_vae_fp32-f16.gguf
ワークフローは下記の画像のようになっています。

ワークフローで使用したプロンプトは、既存のものをClaude Sonnet 4とChatGPT o4-miniで作り替えました。記述方法だけを参考にさせて、完全に異なる内容に変更できるのでおすすめです。
▼ 3-2. HiDream-I1 Fast
ワークフローを掲載します。ComfyUIの画面上にファイルをドラッグ&ドロップすると読み込まれます。プロンプトを変更した場合は生成開始前に「Unload Models」を実行してください。
Fastの場合、ModelSamplingは「3.0」、Stepsは「16」、CFGは「1.0」、Sampler+Schedulerは「lcm+normal」となっています。Negative Promptは使用できません。

▼ 3-3. HiDream-I1 Dev
ワークフローを掲載します。プロンプトを変更した場合は生成開始前に「Unload Models」を実行してください。
Devの場合、ModelSamplingは「6.0」、Stepsは「28」、CFGは「1.0」、Sampler+Schedulerは「lcm+normal」となっています。Fast同様、Negative Promptは使用できません。

▼ 3-4. HiDream-I1 Full
ワークフローを掲載します。プロンプトを変更した場合は生成開始前に「Unload Models」を実行してください。
Fullの場合、ModelSamplingは「3.0」、Stepsは「50」、CFGは「5.0」、Sampler+Schedulerは「uni_pc+simple」となっています。Fullのみ、Negative Promptが使用可となっています(本例では使用していません)。

■ 4. おまけ
▼ 4-1. はじめに
i2iのワークフローは制作していませんので、必要な方はFP8版の記事の4-1.に掲載したものを変更してご利用ください。
ここでは、ModelやText Encoderの選択による出力の違いを紹介し、比較のためにFP8版の出力も掲載します。
▼ 4-2. Modelによる違い
3-3.の、HiDream-I1 Fastのワークフローを使用します。noteでは画像の再圧縮が行われるため、参考程度にしてください。
▽Q2_K:かなりの劣化、変質が見られます。そのため、VRAM 8GBで動作したとしても非推奨としています。

▽Q3_K_S:だいぶ改善しますが、まだ劣化が目立ちます。

▽Q3_K_M:さらにましになりますが、まだ劣化がわかります。

▽Q3_K_L:細かい部分がだいぶましになります。

▽Q4_K_S:劣化が目立たなくなってきました。

▽Q4_K_M:劣化がそれほど気にならないレベルです。本記事ではQ4_K_M以上を推奨としています。

▽Q5_K_S:品質は十分です。これ以降はコメントを行いません。

▽Q5_K_M:

▽Q6_K:

▽Q8_0:

▼ 4-3. Text Encoderによる違い
HiDream-I1 Fastのワークフローを使用し、ModelはQ4_K_Mを選択します。Noteでは画像の再圧縮が行われるため、参考程度にしてください。
まずは、ワークフローの初回の出力を比較元とします。4種類のText Encoderを使用します。4-5.にFP8版の出力もあるので比べてみてください。

CLIP-GとLlamaのみを残します。つまり、CLIP-LとT5xxlを除外します。類似はしていますが変化が見られます。

LLamaのみを残します。出力が大きく変化しています。これらは、ワークフローのノードをつなぎ替えるだけで簡単に試すことができます。

▼ 4-4. Text Encoderによる違い2
今度は、ワークフローで使用しなかった「llama-q2_k.gguf」(2-4.を参照)を利用した場合です。まずは4種類のText Encoderを使用します。背景が変化し、遊園地らしくなくなってしまいました。

次はCLIP-GとLlamaのみです。

次はLlamaのみです。こちらも出力が大きく変化しています。

4-3.の出力と4-5.の出力が類似しているのに対して、本項では大きく変化しています。そのため、この「llama-q2_k.gguf」は利用しない方が良いと判断しました。
▼ 4-5. FP8版の場合
最後に、Comfy Orgが提供するFP8版の出力(前回の記事を参照)を掲載します。GGUF版(4-3.を参照)と出力の傾向が似ていることから、GGUF版の有用性が確認できました。
まずは4種類のText Encoderを使用します。

次はText EncodeをCLIP-GとLlamaのみにします。

次はLlamaのみです。GGUF版と同じように変化します。

■ 5. おわりに
▼ 5-1. まとめ
本記事では、HiDream-I1のフルGGUF版を利用しました。量子化タイプによってはFP8版よりも使用リソースが少なくて済み、VRAM 12GBでも十分な出力が得られることは大きなメリットです。
ただし、プロンプトを変更した場合は生成開始前に「Unload Models」を実行する必要があるので、その点だけ十分に気をつけてください。共有GPUメモリにはみ出すと処理時間がかなり増えますが、それが常態化していると異状に気づかずに見過ごしてしまうかもしれません。
■ 6. その他
私が書いた他の記事は、メニューよりたどってください。
記事に関することで何かありましたら、Xの@riddi0908までお願いします。
