ComfyUI用の画像モデルGGUFをggufyで自作する｜SDXL量子化のサイズ・VRAM・速度を実測

ComfyUIで画像生成モデルをローカルで動かしていると、容量とVRAMの壁にぶつかる。FLUXやSDXL級のモデルは配布元のsafetensorsが数GB〜十数GBあり、そのままでは手元のGPUに載らないことも多い。回避策のひとつがGGUF量子化だが、欲しいモデルの欲しい量子化レベルが、いつも誰かの手で用意されているとは限らない。配布されているのはQ8_0だけ、あるいはそもそもGGUF版が無い、という場面は珍しくない。

そこで「自分で量子化する」道具になるのがggufyだ。safetensorsから各種GGUF量子化へ変換する単一実行ファイルで、Pythonの仮想環境も巨大なライブラリ群も要らない。作者は配布のきっかけを「画像モデルの変換・量子化まわりの道具が乏しく、数少ない既存ツールはRAMの要求が極端で複雑だったから自作した」と述べている。名前が示すとおり、GPUにもメモリにも余裕がない環境を想定した造りになっている。

本記事では、このggufy（v0.6.4）でSDXL（Stable Diffusion XL 1.0 Base）を実際に各レベルへ量子化し、出力サイズ・所要時間・変換中のRAM消費を実測した。先に数字を挙げると、約4.8GBのモデルをピーク90MB前後のRAMで量子化でき、1本あたり5〜13秒で終わった。作ったGGUFは実際にComfyUI（RTX 5080）で画像生成でき、生成時のVRAMと速度も測った。量子化レベルごとにファイルがどこまで縮むか、生成時にどれだけVRAMを使うか、どれを選べば手元のVRAMに収まるかを、測った数字で示す。

ggufyとは — 画像モデルをGGUFに変換する単一実行ファイル

ggufyは、safetensors形式のモデルをGGUF形式の各種量子化へ変換するツールである。Zigで書かれた単一実行ファイルで、Windows・Linux・macOS（arm64／x86_64）向けにビルド済みのバイナリが配布されている。CLI版とGUI版があり、GUIはファイルをドラッグ&ドロップで変換できる。ライセンスはMIT。量子化の実処理にはggml（llama.cppなどが使うC/C++ライブラリ）を取り込んでいる。

対象は画像拡散モデルに絞られている。SD1.5・SDXL・Flux・SD3・Lumina2・Aura・HiDream・Cosmos・LTXV・Hyvid・WAN・Qwen・ERNIEといったアーキテクチャを認識して変換できる。テキスト生成のLLMは対象外で、LLMをGGUF化したいならllama.cpp系を使う。ローカルLLMの量子化でQ4_K_MやQ8_0をどう選ぶかはローカルLLMの量子化はどれを選ぶかで実測比較しているが、ggufyが扱うのはあくまで画像側である。

紛らわしい点として、ウェブ上には同名の別プロジェクト（GGUFモデルを検索・ダウンロードして管理するツール）も存在する。本記事が扱うのは変換ツールのほうで、配布元はGitHubのqskousen/ggufyになる。両者は機能がまったく違うので、入手時にリポジトリを取り違えないようにしたい。

立ち位置を整理しておく。ComfyUIでGGUFを読み込んで動かす側の定番がcity96のComfyUI-GGUFで、ggufyはその手前、ComfyUIで使うGGUFを作る側にあたる。既製のGGUFが見つからないモデルや、配布されていない量子化レベルが欲しいときに、自分の手元でファイルを起こせる。

ComfyUIで使うGGUFを作る道は、大きく3つある。(1) llama.cpp系のツール（リポジトリのクローンとPython環境の構築が要る）、(2) ComfyUI内で量子化するカスタムノード（ComfyUI-ModelQuantizerなど）、(3) ggufyのような単体ツール。このうち(2)はワークフロー内で完結できる手軽さがある反面、モデルをまるごとメモリに展開するため、配布元はGGUF量子化に96GB以上のRAMを目安として挙げている。対してggufyは、後述のとおり同じSDXLの量子化をRAM約90MB（実測）でこなす。ComfyUIを立ち上げず、Python環境も要らず、メモリも食わずに、ComfyUIに読み込むファイルだけを軽く作れる——ここがggufyの実利になる。

導入と基本の使い方

導入は、配布ページから自分のOS向けのzipを取得して展開するだけで済む。中身は実行ファイル本体で、インストーラもランタイムも要らない。パスの通った場所に置くか、展開した場所から直接呼び出せばよい。今回のWindows版はCLI（約1.4MB）とGUI（約6.6MB）の2つが入っていた。

変換はconvertコマンドで行う。必須の引数は入力ファイルだけで、量子化タイプを-d、出力ディレクトリを-o、出力名を-nで指定できる。

選べる出力タイプは、f32・bf16・f16のほか、q8_0・q6_k・q5_k・q5_1・q5_0・q4_k・q4_1・q4_0・q3_k・q2_kがある。末尾が_kの型は、一般には同じビット帯で品質とサイズのバランスを取りやすい量子化形式である。ただし、SDXLのように感度対応量子化が既定で効く場合は、敏感な層を高い精度で残すため、実測上は非k型より少し大きくなることもある。importance matrix量子化（iq系）は今のところ未対応である。header・tree・metadataといった、変換前にモデルの中身を確認するためのコマンドも備える。

実測 — SDXLをGGUFに量子化する

題材には、誰でも入手できて再現しやすいStable Diffusion XL 1.0 Base（sd_xl_base_1.0.safetensors）を使った。配布されているフルチェックポイントは約6.46GBで、中身は拡散本体（UNet）に2つのテキストエンコーダとVAEを束ねたものである。これをggufy v0.6.4で各レベルへ変換した。実行環境はCore i7-14700F（論理28スレッド）・メインメモリ96GBのデスクトップで、変換はGPUを使わずCPUで進む。

変換を始めると、ggufyはまずアーキテクチャをsdxlと判定し、テキストエンコーダの層を変換対象から外していく。つまり出力されるGGUFは拡散本体（UNet）だけで、テキストエンコーダとVAEは含まれない。これはComfyUIのGGUF読み込みノードがUNet単体のGGUFを前提にしているためで、出力ファイルにはComfyUI-GGUF向けのメタデータ（アーキテクチャ名や各テンソルの元の形状）が書き込まれていた。基準となるf16のUNetは約4.78GBで、ここから各量子化でどこまで縮むかを見ていく。

サイズは量子化を深くするほど素直に小さくなり、q4_kでf16の約3分の1、q2_kで約5分の1まで落ちた。変換時間はどのレベルでも5〜13秒に収まり、CPUだけで完結する。GPUの空きを待つ必要がないため、生成でGPUを使っている裏側でも量子化を回せる。

特筆すべきは変換中のRAM消費の少なさだ。量子化中のピークRAMを計測したところ、q8_0で92.6MB、q4_kで94.6MB、q2_kで91.2MBと、目標レベルによらず90〜95MB前後に収まった。4.78GBあるUNetを、その50分の1ほどのRAMで量子化している計算になる。ggufyがモデル全体を一度にメモリへ展開せず、テンソルを順に読みながら書き出す造りだからで、「既存ツールのRAM要求が極端だった」という作者の動機どおり、メモリの細い環境でも大きなモデルを処理できることを数字が裏づけている。VRAMだけでなくRAMも食いつぶさない点が、このツールの実利になる。ローカルでメモリが詰まる場面の一般的な対処はComfyUI外でツールを動かしRAMを節約する手法でも扱っている。

感度対応量子化 — SDXLは既定でオン

ggufyの特徴が、層ごとに量子化の強さを変える「感度対応量子化（sensitivity-aware quantization）」である。モデルの中でも品質への影響が大きい層は高い精度で残し、影響の小さい層を目標レベルまで落とす。感度データが内蔵されているSD1.5とSDXLでは既定で有効になり、ほかのアーキテクチャでは無効から始まる。-xで全層一律の量子化に切り替えられ、-a（0〜100、既定50）で強さを調整できる。

効果を測るため、SDXLをq4_kで「感度対応あり（既定）」と「なし（-x）」の両方に変換した。感度対応ありは1.46GB、なしは1.35GBで、感度対応を効かせるとファイルが約8%大きくなった。敏感な層を高い精度で残す分だけ容量が増えるという、ツールの説明どおりの結果である。なお、この差はサイズについて実測したもので、生成画像の品質差そのものは本記事では計測していない。容量を少し足して品質を守る仕組み、という位置づけで捉えるのが正確だろう。精度設定がVRAMと品質にどう効くかはComfyUIの精度設定（FP16・BF16・FP8）の実測も参考になる。

この層ごとの振り分けは、できたファイルの中身にそのまま表れる。q4_kに変換したGGUFをComfyUIが読み込む際のログでは、テンソルの内訳がQ4_K（1288個）・Q5_K（182個）・Q6_K（12個）・F16（198個）と出た。本体の多くをQ4_Kに落としつつ、敏感な層はQ5_K・Q6_K・F16で高めに残している——一律ではなく層ごとに精度を変える動作が、実物のファイルで確認できる。

どの量子化を選ぶか — サイズとVRAMの目安

量子化レベルの選択は、手元のVRAMと品質の折り合いで決まる。GGUFの拡散モデルは、ComfyUI-GGUFが量子化したままの重みをVRAMに載せ、計算のたびに展開する。そのためUNetがVRAMで占める重みの量は、おおむねこのファイルサイズに対応する。実際の生成では、これに加えてテキストエンコーダ・VAE・中間バッファの分が乗るため、総VRAMはファイルサイズより大きくなる。その生成時の総VRAMも、後の節でComfyUI上で実測している。

VRAMに余裕があるならq8_0から始め、足りなければq6_k・q5_k・q4_kと落としていくのが扱いやすい（ただし容量を削ると生成速度の面で別の綾が出る。これも後の節で実測した）。q2_kは画質の劣化が見えやすいため、どうしても載らないときの逃げ道と考えるとよい。ComfyUIで用途別にVRAMをどう見積もるかはComfyUI推奨スペック（VRAM 8GB・12GB・16GB）に、VRAMが足りないときに何が起きるかはVRAM不足エラーの原因と解決法に整理がある。VRAMという指標そのものの意味はVRAMとは（AI用途で必要な容量の目安）を参照してほしい。

作ったGGUFをComfyUIで動かす — 生成とVRAM・速度の実測

ggufyが出力したGGUFのメタデータを確認すると、アーキテクチャ名はsdxl、各テンソルの元形状がComfyUI-GGUFの規約（comfy.gguf.orig_shape.*）で記録されており、ComfyUIのUnet Loader（GGUF）が期待する形式になっていた。読み込み自体は、このGGUFをmodels/unet/に置いてUnet Loader（GGUF）で指すだけでよい。実際に、できたq4_kとq8_0のGGUFをComfyUIで読み込み、SDXLの画像生成を回してVRAMと速度を測った（RTX 5080・16GB、1024×1024・20ステップ・euler）。

SDXLの場合、GGUFはUNet単体なので、テキストエンコーダ（clip_l・clip_g）とVAEを別に用意して読み込む。今回は元のチェックポイントからこの2つを供給した（GGUFのUNetだけを差し替える形）。生成は問題なく通り、プロンプトどおりの画像が出た。自分で量子化したモデルでも破綻なく描けている。

VRAMと速度の実測は次のとおり。VRAM増分は、デスクトップ描画が常時使う分（基準で約6.5GB）を差し引いた、純粋な上積みである。

VRAMは狙いどおり、深い量子化ほど下がった。増分はq4_kで約5.9GB、q8_0で約7.1GB。差の約1.2GBはUNetのファイルサイズ差にほぼ対応し（読み込みログでもq4_kのUNetは約1.5GBだった）、残りはテキストエンコードとVAEデコード、潜在空間のバッファ分にあたる。元チェックポイントのfp16のUNetはGPUには載らず、GGUFのUNetだけが載っていた。

意外なのは速度だ。小さいはずのq4_kが、q8_0より大幅に遅い。定常でq8_0が1枚あたり約6.6秒だったのに対し、q4_kは約24〜36秒と、4倍前後かかった（モデルの実行順を入れ替えても傾向は同じだった）。ComfyUIは重みを量子化したままVRAMに置き、計算のたびに展開するため、K系量子化（Q4_K）の展開がQ8_0の単純な展開より計算コストが高く、その分が1ステップごとに積み上がる。数値はRTX 5080・現行のComfyUI-GGUFでの計測で、GPUや実装の版によって幅は変わりうるが、「ファイルが小さい＝速い」とは限らないことははっきり出た。

つまりSDXLでは、q8_0が載るなら、品質でも速度でもq8_0が有利になる。q4_kの容量削減が効いてくるのは、q8_0では載りきらない大きめの拡散モデル——FluxやLTXのような重いモデル——で、まずVRAMに収めること自体を優先する場面である。容量と速度はトレードオフで、手元のVRAMで何が載るかが先に決まり、その範囲で速度と品質を取りにいく順序になる。ComfyUIの始め方はComfyUIとは（始め方）に、GGUF量子化モデルを16GBで動かした別の生成例はLTXを16GB VRAMで動かす実測にある。

注意点とライセンス

使ううえでの前提もいくつかある。感度対応の内蔵データはSD1.5とSDXLのみで、他アーキテクチャでは一律量子化から始まる。importance matrix量子化（iq系）は未対応。低い精度（量子化済み・FP8）から高い精度へ「戻す」変換は、-Uで許可はできるものの、欠けたビットを埋めるだけで品質は回復しない。対象は画像拡散モデルで、テキスト生成のLLMはllama.cpp系の領分になる。手元のVRAMでどのモデルが動くかの全体像はVRAM 16GBで動かすローカルLLM完全ガイドにまとめている。

ライセンスは2層で考える必要がある。ggufy自体はMITで配布されるが、量子化してもモデル本体のライセンスは変わらない。今回のSDXL 1.0 BaseはCreativeML Open RAIL++-Mで、これは出力GGUFのメタデータにもそのまま引き継がれていた。作った量子化版を再配布したり業務で使ったりする場合は、ツールではなく元モデルの条文に従うことになる。モデルごとに条件は異なるため、配布元の最新のライセンスを確認するのが前提になる。

まとめ

ggufyは、画像生成モデルのGGUF量子化を、軽い実行ファイル1つで手元に手繰り寄せる道具である。SDXL 1.0 Baseで実測したところ、UNetはf16の4.78GBからq8_0で2.54GB、q4_kで1.46GB、q2_kで0.93GBまで縮み、変換は1本5〜13秒、ピークRAMは90〜95MBに収まった。4.8GBのモデルを90MBほどのRAMで量子化できる軽さは、「GPUにもメモリにも余裕がない環境のための道具」という看板に見合う。出力はComfyUI-GGUF向けの形式で、実際に読み込んでSDXLの生成も確認できた。感度対応量子化を既定で効かせて品質を守る配慮もある。生成時のVRAM増分はq4_kで約5.9GB・q8_0で約7.1GBと深い量子化ほど下がる一方、生成速度はq8_0の約6.6秒に対しq4_kが約24〜36秒と逆転した（K系量子化の展開負荷）。容量と速度のどちらを取るかは、手元のVRAMで何が載るかが先に決め、その範囲で選ぶことになる。既製のGGUFが見つからないモデルや、欲しい量子化レベルが配布されていないとき、自分でファイルを起こせる選択肢として手元に置いておく価値がある。量子化レベルとファイルサイズの対応は本記事の実測値が出発点になる。

よくある質問

ggufyを使うのにGPUは要るか

量子化の処理自体はCPUで走るため、変換にGPUは要らない。今回もCPU（Core i7-14700F）だけで、1本あたり5〜13秒で完了した。作ったGGUFを生成に使う段階で、はじめてGPUとVRAMが効いてくる。

変換にどれくらいのメモリが必要か

実測では、4.78GBのUNetをq8_0・q4_k・q2_kいずれに量子化しても、ピークRAMは90〜95MB前後にとどまった。モデル全体をメモリに展開せず、テンソルを順に処理する造りのため、メインメモリの細い環境でも大きなモデルを扱える。

q4_kとq4_0はどう違うのか

末尾が_kの型（q4_k・q6_kなど）は、一般に同じビット帯で品質とサイズのバランスを取りやすい量子化形式である。ただしSDXLでは既定で感度対応量子化が効くため、敏感な層をQ5_K・Q6_K・F16などで高めに残す分、今回の実測ではq4_kの方がq4_0より少し大きくなった。迷ったらまずq4_kが扱いやすい。

感度対応量子化はオフにしたほうがよいか

基本はオンのままでよい。SDXLをq4_kで試したところ、感度対応ありで1.46GB、なし（-x）で1.35GBと、容量差は約8%だった。わずかな容量増と引き換えに、品質に効く層を高い精度で残す仕組みなので、容量を最優先する場面以外はオンを推奨する。

q4_kはq8_0より小さいのに、生成は速くないのか

今回のSDXL・RTX 5080での実測では、むしろq4_kのほうが遅かった。1枚あたりq8_0が約6.6秒、q4_kが約24〜36秒で、4倍前後の差が出た。ComfyUIは重みを量子化したままVRAMに置き、計算のたびに展開するため、K系量子化（Q4_K）の展開コストが生成時間に乗る。q4_kはVRAMを節約できる一方で速度を割く関係にあり、q8_0が載るならq8_0のほうが速く品質も高い。GPUや実装の版によって幅は変わりうる。

ComfyUI内のノードで量子化するのと何が違うのか

ComfyUI内で量子化するカスタムノード（ComfyUI-ModelQuantizerなど）もあり、ワークフロー内で完結できる手軽さがある。違いはメモリと前提環境で、ノード方式はモデルをまるごと展開するため、配布元はGGUF量子化に96GB以上のRAMを目安に挙げている。ggufyはComfyUIを立ち上げず、単体の実行ファイルでRAM約90MB（実測）で同じ変換ができる。手元のRAMが小さい、あるいはComfyUIを起動せずにまとめて量産したい場合はggufyが向く。できたファイルはどちらもComfyUIのUnet Loader（GGUF）で読み込める。

LLM（テキスト生成モデル）もggufyで量子化できるか

できない。ggufyが対象とするのはSDXLやFluxなどの画像拡散モデルで、テキスト生成のLLMは扱わない。LLMのGGUF量子化はllama.cpp系のツールが担当する。LLM側でどの量子化を選ぶかはローカルLLMの量子化はどれを選ぶかで実測比較している。

参考資料

• qskousen/ggufy — GitHub（本体・対応アーキテクチャ・使い方）
• ggufy Releases（v0.6.4・各OSのビルド済みバイナリ）
• Sensitivity file explanation — ggufy Wiki（感度対応量子化の仕組み）
• city96/ComfyUI-GGUF（GGUFをComfyUIで読み込む側のノード）
• stable-diffusion-xl-base-1.0 — Hugging Face（題材モデル・ライセンス）