VRAMが足りないという話になると、必ずこう言われます。
量子化版を使えば動きます
そのとおりなのですが、GGUF・fp8・NF4 が何をしていて、どう違うのかを説明したものはあまり見かけません。結果として、記号の意味が分からないまま適当に選ぶことになりがちです。
この記事では、実際のファイルを確認しながら整理します。数値は執筆時点で確認したもので、配布物は更新されるため、使う時点で確認してください。
量子化とは何をしているのか
モデルの中身は膨大な数値の集まりです。この1つあたりの数値を、どれくらい細かく記録するかを粗くするのが量子化です。
写真のファイルサイズを落とすときに、色の段階数を減らすのに似ています。段階を減らせばファイルは小さくなり、減らしすぎれば見た目に響きます。
- 細かく記録する → 大きい、品質が高い
- 粗く記録する → 小さい、品質が落ちる
どこで折り合いをつけるかが、量子化の選択です。
何のためにやるのか
VRAMに載せるためです。載らなければ生成そのものが始まりません。
「載るけれど遅い」と「そもそも載らない」の間には、決定的な差があります。量子化は後者を前者に変える手段です。
設定側で削る方法（解像度・バッチ数・処理の分割）で足りるなら、そちらが先です。品質を落とさずに済むからです。詳細は VRAM最適化ガイド にまとめています。
3つの方式
| 方式 | 出自 | 特徴 |
|---|---|---|
| GGUF | 言語モデルを軽く動かす系譜 | 刻みが細かく選べる。専用の読み込みが要る |
| fp8 | 数値表現そのものの規格 | 8ビット固定。対応環境では素直 |
| NF4 | 大規模言語モデルの省メモリ研究 | 4ビット。厳しい環境向け |
いずれも目的は同じで、やり方が違うだけです。
GGUF
もともとは言語モデルを手元の機械で動かすための形式で、画像生成にも持ち込まれました。
最大の利点は段階の細かさです。後述するように多くの刻みが用意されており、自分のVRAMに合わせて寄せられます。
読み込みには対応した仕組みが必要で、標準機能だけでは扱えないことがあります。
fp8
こちらは形式というより、数値の記録の仕方そのものです。8ビットで浮動小数点を表します。
いくつか変種があり、配布物のファイル名に e4m3fn のような記号が付きます。これは8ビットをどう割り振るかの違いです。
注意すべきは、fp8で速く計算できるGPUは比較的新しい世代だという点です。それ以前の世代でも読み込めてメモリは節約できますが、演算が速くなるとは限りません。「軽くなる」と「速くなる」は別の話です。
NF4
4ビットまで削る方式です。値の分布に合わせた刻み方をするため、単純に4ビットへ丸めるより品質が保たれやすいとされます。
大規模言語モデルを少ないメモリで扱う研究から来たもので、画像生成では一部のUIが対応しています。VRAMが本当に厳しいときの選択肢です。
GGUFの記号の読み方
flux1-dev-Q4_K_S.gguf のような名前は、慣れないと暗号です。
分解するとこうなります。
- Q … 量子化されている
- 数字 … おおよそのビット数。小さいほど軽く、粗い
- _K … 重みの重要度に応じて配分を変える方式。同じビット数でも品質が保たれやすいとされる
- _S / _M … 同系統内での大きさの違い（S のほうが小さい）
- _0 / _1 … 素朴な方式の変種
つまりまず数字を見て、次に _K の有無を見るのが読み方です。
実際のサイズ
FLUX.1-dev 向けに配布されているGGUFのファイルサイズを確認しました。
| 量子化 | サイズ |
|---|---|
| F16（量子化なし） | 23.80 GB |
| Q8_0 | 12.71 GB |
| Q6_K | 9.86 GB |
| Q5_1 | 9.01 GB |
| Q5_K_S | 8.29 GB |
| Q5_0 | 8.27 GB |
| Q4_1 | 7.53 GB |
| Q4_K_S | 6.81 GB |
| Q4_0 | 6.79 GB |
| Q3_K_S | 5.23 GB |
| Q2_K | 4.03 GB |
量子化なしの23.80GBが、Q4系で約7GB、Q2_Kで約4GBまで落ちます。
刻みが細かいことが分かると思います。「8GBに収めたい」なら Q4_K_S か Q5_K_S あたり、という寄せ方ができます。
最大の落とし穴：サイズを横断比較しない
ここが一番間違えやすい点です。
同じFLUX.1-dev向けに、こういうファイルがあります。
| ファイル | サイズ |
|---|---|
| 本体（量子化なし） | 23.80 GB |
| fp8 版 | 17.25 GB |
| GGUF Q8_0 | 12.71 GB |
これを見ると「fp8（17.25GB）よりGGUFのQ8_0（12.71GB）のほうが軽い」と読みたくなります。
しかしこの比較は成立しません。中身が違うからです。
何が違うのか
画像生成には、本体のほかにテキストを解釈する部分と画像に戻す部分が必要です。これらのサイズを確認すると、こうなっています。
| 部品 | サイズ |
|---|---|
| テキストエンコーダー（16ビット） | 9.79 GB |
| テキストエンコーダー（fp8） | 4.89 GB |
| 補助のエンコーダー | 0.25 GB |
| 画像に戻す部分 | 0.34 GB |
本体を8ビット相当にすると約11.9GB。ここに fp8 のエンコーダー4.89GB、補助0.25GB、0.34GB を足すとおよそ17.4GBになります。
観測された17.25GBとほぼ一致します。 つまり fp8 版のファイルは、必要なものが全部入った1本です。
一方GGUFの12.71GBは本体だけで、エンコーダーは別に用意します。
だからどうなるか
- 全部入りのファイル：1つ落とせば動く。合計サイズが大きく見える
- 本体のみのファイル：軽く見えるが、別途エンコーダーが要る
必要なVRAMを見積もるときは、本体だけでなく一式で考えてください。 本体を軽くしてもエンコーダーが重ければ、そこで詰まります。
エンコーダー側も量子化されたものが配布されているので、厳しい環境では両方を軽くするのが正解です。
ファイルサイズ＝VRAM使用量ではない
もうひとつ、見積もりでずれる点です。
生成時には、重みに加えて次のものが乗ります。
- 計算途中のデータ（解像度とバッチ数で増える）
- 処理系そのものが使う領域
そのため、ファイルサイズより少し多めに見積もる必要があります。ぎりぎりのサイズを選ぶと、解像度を上げた瞬間に落ちます。
余裕がどれくらい要るかは環境で変わるので、まず動かして、実際の使用量を見るのが確実です。
VRAM別の選び方
厳密な正解はありませんが、出発点としての目安です。
24GB以上
量子化なしでも動きます。まず量子化なしを試して、速度や同時実行の都合で必要になったら8ビット相当に落とすのが順当です。
品質を最優先できる位置にいるので、無理に削る理由はありません。
12〜16GB
8ビット相当（Q8_0 や fp8）が扱いやすい帯です。 品質の劣化を気にせず使えて、サイズも収まります。
エンコーダーを量子化したものにすれば、さらに余裕が出ます。解像度を上げたいときはここで調整します。
8〜10GB
4〜5ビット相当（Q4_K_S / Q5_K_S）が現実的です。 本体で7〜8GB前後に収まります。
ただしエンコーダーの分を忘れないでください。本体だけ見て選ぶと足りません。エンコーダーも量子化したものを使ってください。
8GB未満
4ビット以下か、そもそも軽いモデルへの乗り換えを検討する帯です。
FLUX系にこだわらず、SDXL系のほうが快適に動きます。モデル選びからやり直したほうが早いことも多いです。系統の違いは SDXL vs FLUX.1 比較2026 を参照してください。
品質はどこから落ちるか
8ビット相当では、多くの用途で違いを見分けるのが難しいレベルです。ここを基準に考えてください。
4ビット相当まで落とすと、細部で差が出やすくなります。特に出やすいのは次のような場面です。
- 細かい模様や装飾
- 文字の描画
- 手指など、もともと崩れやすい部分
2〜3ビット相当は明確に粗くなります。動くことを優先する段階の選択です。
題材によって出方が違う
単純な構図では気づきにくく、細かいものほど目立ちます。
だから「Q4は使える／使えない」という一般論は成立しません。自分の題材で同じ設定・同じシードで比べるのが唯一確実な方法です。
比較するときは、量子化以外の条件を全部固定してください。1つだけ変える、が鉄則です。
よくある失敗
記号を読まずに一番小さいものを選ぶ
サイズだけ見て Q2_K を選び、「量子化すると使い物にならない」と結論づけるパターンです。落としすぎです。 まず8ビット相当から始めて、必要なら下げてください。
エンコーダーを量子化なしのままにする
本体だけ軽くして、エンコーダーが16ビットのまま残っている状態です。ここだけで10GB近く食います。 本体を削った意味がなくなります。
形式をまたいでサイズを比べる
前述のとおりです。全部入りか本体のみかを確認してから比べてください。
fp8にすれば速くなると思う
メモリは減りますが、速度は世代次第です。 古いGPUでfp8にして「速くならない」と困惑するのは、この誤解が原因です。
量子化を先に試す
設定側で削れるなら、そちらが先です。解像度とバッチ数を見直して足りるなら、品質を落とす必要はありません。手順は VRAM最適化ガイド と AI画像生成トラブル辞典2026 にあります。
関連記事
- VRAM最適化ガイド：8GB / 12GB / 24GB
- FLUX.1完全解説2026
- SDXL vs FLUX.1 比較2026
- ComfyUI完全導入ガイド2026
- AI画像生成トラブル辞典2026
- AI生成PC構成ガイド2026
- AI音楽生成でBGMを作る2026（音楽モデルも同じGGUF形式）
まとめ
要点は4つです。
1つ目、量子化は「載らない」を「載る」に変える手段。 設定側で足りるならそちらが先で、それでも足りないときに使います。
2つ目、GGUFの記号はまず数字、次に _K を見る。 数字が小さいほど軽く、粗くなります。FLUX.1-dev では23.80GBが、Q4系で約7GB、Q2_Kで約4GBまで落ちます。
3つ目、ファイルサイズを形式をまたいで比べない。 全部入りのものと本体のみのものが混在しています。必要なVRAMは一式で見積もってください。 本体を削ってもエンコーダーが重ければそこで詰まります。
4つ目、品質の判断は自分の題材で。 8ビット相当なら多くの場合で違いが分かりにくく、4ビット相当は細部で差が出ます。ただし出方は題材次第なので、条件を固定して比べるのが確実です。
迷ったら8ビット相当から始めて、必要なら下げる。この順番が一番失敗しません。
