この記事の要点
量子化は、モデルの重みを少ないビット数で持ち直してファイルを小さくする処理で、VRAM の使用量も減ることが多い。出力は元のモデルから変わることがある。
LLM は、まず Q4_K_M という形式を試す。Llama-3.1-8B の測定では、Q5_K_M・Q6_K・Q8_0 へ上げるほど VRAM の報告値が増え、生成は遅くなった。GPU に載せる合計が VRAM の容量に近い形式は、ファイルが1つ小さい形式とも速さを比べる。
ComfyUI の画像生成は、測った2つのモデルでは、RTX 50 シリーズ・PyTorch cu130 の環境で int8 と nvfp4 が bf16 より短い時間だった。どちらが速いかは2つの測定で逆になったので、手元で比べて選ぶ。Z-Image-Turbo では、nvfp4 は量子化する前の画像と背景や小物の配置まで変わり、int8 は nvfp4 より近い画像だった。動画生成の MiniMax H3 では、PyTorch が cu128 のとき int8 が fp8 より遅くなったので、先に PyTorch を確かめる。
初めて選ぶ場合は「Q4_K_M・Q8_0・bf16・fp8・int8・nvfp4 の名前の読み方」まで読めば判断できる。使ったソフトのバージョン、測った日、GPU のつなぎ方、測っていないことは「測定の条件と注意点」にまとめた。
- 量子化とは何か、どの形式から選ぶか
- 量子化で変わるのはファイルの大きさ・VRAM・速さ・品質
- Q4_K_M・Q8_0・bf16・fp8・int8・nvfp4 の名前の読み方
- Llama-3.1-8B では、ビット数の多い形式ほど VRAM の報告値が増え、生成が遅くなった
- Qwen3.8-27B は、GPU 上の合計が容量に近い形式で RTX 5080 の生成が半分以下に落ちた
- 測った2つの画像生成モデルでは、int8 と nvfp4 が bf16 より短い時間で作れた
- MiniMax H3 では、PyTorch が cu128 のとき INT8 が FP8 より遅くなった
- 品質はどこまで変わるか
- よくある質問
- 測定の条件と注意点
- 参考資料
量子化とは何か、どの形式から選ぶか
量子化（モデルの重みを少ないビット数で表し、ファイルを小さくすること。読み込んだときの VRAM の使用量も減ることが多い）は、LLM でも、ComfyUI（画像や動画を生成するソフト）で使う画像・動画生成のモデルでも使われている。重みとは、AI のモデルが持つ大量の数値のことだ。ビットは 0 か 1 を表す最小の単位で、1つの数値に使うビットが少ないほどデータは小さくなる。量子化という言葉は、計算の途中の値を低い精度で持つ場合にも使われるが、この記事では重みの量子化を扱う。
ビット数を減らすと、重みのデータが小さくなり、ファイルが小さくなる。読み込んだときの VRAM（GPU に載っている専用のメモリ。モデルの重みや計算途中のデータを置く）の使用量も減ることが多い。ただし、VRAM には計算途中のデータなども置かれるので、ファイルと同じ割合で減るとは限らない。その代わり、出力が元のモデルから変わることがある。llama.cpp（パソコン上で LLM を動かすオープンソースのソフト）の説明でも、量子化は重みの精度を下げる処理で、モデルが小さくなり、推論が速くなることがあるとされている。同じ説明は、精度が下がることがあるとも書いている。
使い方ごとに最初に選ぶ形式を、「使い方ごとの最初の選び方」の表にまとめた。LLM の行にある Q4_K_M（LLM 用のファイルで使う量子化の種類の名前。Q の後の数字は1つの重みに使うおおよそのビット数で、小さいほどファイルが小さくなる）が出発点になる。
| 使い方 | 最初に選ぶ形式 | 理由 |
|---|---|---|
| LLM を Ollama や llama.cpp で動かす | まず Q4_K_M。VRAM に余裕があれば Q5_K_M・Q6_K・Q8_0 と、ビット数の多い形式に替える | 測った4つのうち最も小さく、最も速かった (これより小さい形式は、このモデルでは測っていない)。ビット数の多い形式ほど VRAM の報告値が増え、生成は遅くなった。ビット数が増えるぶん量子化の誤差は小さくなる傾向があるが、回答の質の差は測っていない |
| LLM を載せたときの GPU 上の合計 (llama.cpp などの報告値) が、GPU の容量に近い | ファイルが1つ小さい形式とも速さを比べる | Qwen3.8-27B を llama.cpp で、モニターもつないでいる RTX 5080 に載せた例では、GPU 上の合計が容量の約96%になる形式で、生成速度が、ファイルが1つ小さい形式の半分以下になった。この生成速度は測るたびに変わりやすく、原因は切り分けていない。モニターをつないでいない RTX 5060 Ti では、生成速度の落ち幅は約9%だった |
| ComfyUI で画像を作る (RTX 50 シリーズ・PyTorch が cu130 以上) | int8 と nvfp4 のファイルが配布されているモデルでは、この2つを候補にして、手元で速さを比べる | 画像生成のモデル2つで、int8 と nvfp4 は bf16 の約4割〜6割弱の時間だった。ただし FLUX 3 Image Klein の時間は、プロンプト拡張の時間を含まない。int8 と nvfp4 のどちらが速いかは、2つの測定で逆になった。2つの測定は、モデルのほかに設定も違う。bf16 の画像との近さを比べた Z-Image-Turbo では、int8_convrot のほうが nvfp4 より近かった。FLUX 3 Image Klein の画像は比べていない |
| RTX 50 シリーズで、PyTorch が cu128 (測ったのは 2.9.1+cu128) | 先に PyTorch を cu130 以上に上げる。上げられないなら fp8 も試す | 動画生成の MiniMax H3 では、cu128 のとき INT8 が FP8 より遅くなった。cu130 では INT8 のほうが速かった (本体を bf16 や nvfp4 にした条件は、このモデルでは測っていない) |
| RTX 40 シリーズ以前の GPU で ComfyUI を使う | この記事では測っていない。モデルの配布元が案内している形式から選ぶ | comfy-kitchen の説明では、nvfp4 の高速な計算は RTX 50 シリーズなどの Blackwell 世代、fp8 の高速な計算は RTX 40 シリーズ以降が対象。FLUX 3 Image Klein の配布元は、int8 のファイルを、fp8 の計算に対応しない RTX 30 シリーズ以前の GPU でも動く形式として案内している |
「理由」の列のうち、VRAM・速さ・時間と、Z-Image-Turbo の画像の近さは、後の節の実測の結果だ。GPU の世代ごとの対応は、comfy-kitchen の説明と、モデルの配布元の案内による。ビット数の多い形式ほど量子化の誤差が小さくなるというのは一般的な傾向で、形式ごとの回答の質は、この記事では測っていない。ビット数の多い形式とは、Q4_K_M → Q5_K_M → Q6_K → Q8_0 の並びで後ろにあるものを指す。後ろへ行くほど、1つの重みに使うビット数が多い。
表の cu128 の行に当たるのは、古い環境をそのまま使い続けている場合だ。ComfyUI の README は2026年11月時点で cu130 以上を必須としている。PyTorch は ComfyUI の中で AI の計算を受け持つライブラリ、CUDA は NVIDIA の GPU で計算させるための仕組みで、cu130 は PyTorch がどの CUDA 向けに作られたかを表す名前だ。ComfyUI を起動したときのログに PyTorch のバージョンが出るので、2.14.0+cu130 のような末尾の表記で分かる。
この記事では、配布の基準になっている16ビットの形式 (bf16 と F16) を「量子化する前」と呼ぶ。fp8・int8・nvfp4 と、Q4_K_M などの Q や IQ で始まる形式は、どれも量子化した形式だ。ファイル名では int8・nvfp4 のように小文字で、計算の名前や表の列では INT8・NVFP4 のように大文字で書かれるが、この記事では同じものとして扱う。ただし、ファイル名の形式は、モデルの中のすべての計算がその精度で行われるという意味ではない。
大きさの単位は、GiB と MiB で書く。1GiB は 1,024MiB で、この記事の VRAM の値はこの単位にそろえた。製品の VRAM の容量は、16GB のように GB のまま書く。この記事で測った VRAM 16GB の2枚は、nvidia-smi (NVIDIA の GPU の状態を表示するコマンド) で、どちらも容量が約16,300MiB (約15.9GiB) と表示される。VRAM が何GB 要るかから GPU を決めたい場合は、画像生成・動画生成・LLM の用途別に必要な VRAM をまとめた生成AI用グラボの選び方から読むと早い。
量子化で変わるのはファイルの大きさ・VRAM・速さ・品質
量子化で変わるものは、大きさ (ファイルと VRAM)・速さ・品質の3つに分けられる。
ファイルの大きさと VRAM。重み1つあたりのビット数が減るぶん、ファイルが小さくなる。読み込んだときの VRAM の使用量も減ることが多いが、ファイルと同じ割合で減るとは限らない。
速さ。小さくなったぶん、速くなることがある。画像・動画生成では、その形式の計算に GPU と PyTorch が対応しているかどうかも速さに関わる。量子化した形式どうしの速さの順番は、環境によって入れ替わることがあり、「MiniMax H3 では、PyTorch が cu128 のとき INT8 が FP8 より遅くなった」の節で扱う。
品質。元のモデルから出力が変わることがある。どこまで変わるかは、モデルと形式によって違う。
llama.cpp の説明には、Llama-3.1-8B を例にした形式ごとのビット数が載っている。その値を写したのが「Llama-3.1-8B での、形式ごとの1つの重みあたりのビット数」の表だ。モデルが変われば、値も少し変わる。
| 形式 | 1つの重みあたりのビット数 |
|---|---|
| Q4_K_M | 約4.89 |
| Q5_K_M | 約5.70 |
| Q6_K | 約6.56 |
| Q8_0 | 約8.50 |
| F16 (量子化していない) | 約16.00 |
Llama-3.1-8B の表の4つでは、名前の数字が大きいほどビット数が多い。ビット数が多いほど量子化の誤差は小さくなる傾向があるが、作り方の違う形式どうしでは、数字の大小だけで元のモデルへの近さは決まらない。名前の数字と実際のビット数も、ぴったり同じではない。
ファイルの大きさは、重みの数とビット数からおおよそ見積もれる。重みの数 × 1つあたりのビット数 ÷ 8 が、おおよそのバイト数になる。モデル名の 8B や 27B の B は10億 (billion) の意味で、重みの数を表す。Llama-3.1-8B は重みが約80億個なので、Q4_K_M なら 約80億 × 約4.89 ÷ 8 で約49億バイト、GiB に直すと約4.6GiB になる。モデルを読み込んだときの VRAM は、ファイルの大きさに、文脈を保存する領域などが加わる。後の節の測定では、4.58GiB の Q4_K_M について、Ollama が報告した VRAM 上の大きさは約5.53GiB だった。
Q4_K_M・Q8_0・bf16・fp8・int8・nvfp4 の名前の読み方
形式の名前は、LLM と画像・動画生成で付け方が違う。そこで表を2つに分けた。表に出てくる浮動小数点は、小数点の位置を動かして広い範囲の数を表す方式で、整数は小数点の無い数だ。
LLM (GGUF) の名前
GGUF（llama.cpp や Ollama で使われる、モデルの重みなどを保存するファイルの形式）は、Hugging Face の説明では、モデルを速く読み込み・保存できるように作られたバイナリ形式だ。llama.cpp や Ollama で LLM を動かすときに、広く使われている形式だ。ファイル名に付く量子化の名前の意味を、「GGUF の主な形式名」の表にまとめた。
| 名前 | 意味 |
|---|---|
| F16 | 量子化する前の16ビット。16ビットの半精度浮動小数点 |
| Q8_0 | 8ビットに丸める方式。Hugging Face の表では旧型 (Legacy) に分類されているが、llama.cpp の表にも載っていて、この記事でも測った |
| Q4_K_M など、Q と K が付く形式 | Q の後の数字が主なビット数の目安。末尾の S・M・L は、どの重みにより多いビット数を使うかの組み合わせの違い (llama.cpp がこの方式を導入したときの説明による)。Hugging Face の表では、Q4_K という方式が1つの重みあたり約4.5ビット。Q4_K_M のファイル全体では、llama.cpp の Llama-3.1-8B の表で約4.89ビットになる |
| IQ4_XS など、IQ で始まる形式 | Hugging Face の表では、重要度行列 (importance matrix) を使う方式と説明されている。llama.cpp では、重要度行列は Q と K が付く形式を作るときにも使える |
表のうち、F16・Q8_0・Q4_K・IQ4_XS の説明は Hugging Face の GGUF の説明、ビット数と重要度行列の扱いは llama.cpp の説明による。この記事で扱ったモデルの範囲では、F16 や BF16 は量子化する前の基準として配られることが多いようだ。
LLM の GGUF にも、NVFP4 の形式で配られたファイルがある。Qwen3.8-27B の NVFP4 GGUF を RTX 5080・5060 Ti で測った記事では、UD-IQ4_XS との速さを比べている。
画像・動画生成 (ComfyUI) の名前
画像・動画生成のモデルでは、本体のファイル名に bf16・fp8・int8・nvfp4 のような名前が付く。ComfyUI の開発元が公開している計算ライブラリ comfy-kitchen は、INT8・FP8・NVFP4 の量子化の計算を持っている。その説明の表では、NVFP4 の計算は Blackwell 世代 (RTX 50 シリーズなど)、FP8 の計算は Ada 世代 (RTX 40 シリーズ) 以降の GPU が要件になっている。名前ごとの意味と、高速な計算の主な要件は「画像・動画生成の主な形式名」の表のとおりだ。
| 名前 | 意味 | 高速な計算の主な要件 |
|---|---|---|
| bf16 | この記事で「量子化する前」と呼ぶ基準の16ビット。16ビットの浮動小数点の1つで、F16 とは数の表し方が別の形式 | 量子化の計算への対応は要らない |
| fp8 | 8ビットの浮動小数点。細かな種類が複数ある (MiniMax H3 の測定で使ったのは fp8_scaled という名前のファイル) | RTX 40 シリーズ以降 |
| int8 | 8ビットの整数。この記事で測った int8 は、すべて int8_convrot という名前のファイル | comfy-kitchen に計算がある。この記事で測ったのは RTX 50 シリーズ |
| nvfp4 | NVIDIA の4ビットの浮動小数点 | RTX 50 シリーズなどの Blackwell 世代 |
右端の列は、その形式の高速な計算が働くための条件で、ファイルを読み込めるかどうかとは別の話だ。
NVIDIA は2025年6月の開発者ブログで、NVFP4 を Blackwell 世代の GPU とともに導入した4ビットの浮動小数点形式として紹介している。NVIDIA は、NVFP4 を使うと、モデルが占めるメモリの量を FP16 の約3.5分の1、FP8 の約1.8分の1にできると説明している。これは NVIDIA の説明で、この記事で測った値ではない。生成中の GPU 全体の使用量が同じ割合で減るという意味でもない。
形式の違うファイルに替えるのとは別に、ComfyUI の起動時の設定で、計算に使う数の形式 (fp16・bf16) を変えたり、読み込んだ重みを fp8 で持たせたりする方法もある。前者は量子化ではないが、後者は重みを8ビットに落とすので量子化にあたり、出力が変わることがある。どちらもファイルを替えずに使える手段で、SDXL や Flux などを FP16・BF16・FP8 で比べた実測で扱っている。
Llama-3.1-8B では、ビット数の多い形式ほど VRAM の報告値が増え、生成が遅くなった
同じ Llama-3.1-8B を、量子化の形式だけ替えて RTX 5080 で動かし、Ollama（パソコン上で LLM を動かすソフト）が報告する VRAM 上のモデルの大きさと、生成速度を測った。生成速度は、1秒あたりに出力したトークン（モデルが文章を扱う単位。文字のかたまり）の数だ。結果は「Llama-3.1-8B の量子化の形式ごとの測定」の表のとおりだった。
| 量子化 | ファイルの大きさ | VRAM の報告値 (Ollama) | 生成速度 |
|---|---|---|---|
| Q4_K_M | 4.58GiB | 5,660MiB (約5.53GiB) | 毎秒141.7トークン |
| Q5_K_M | 5.34GiB | 6,372MiB (約6.22GiB) | 毎秒125.2トークン |
| Q6_K | 6.14GiB | 7,128MiB (約6.96GiB) | 毎秒110.9トークン |
| Q8_0 | 7.95GiB | 8,861MiB (約8.65GiB) | 毎秒91.0トークン |
Q4_K_M から Q8_0 に上げると、VRAM の報告値は 3,201MiB 増え、生成速度は約36%下がった。間の Q5_K_M と Q6_K も、ビット数が増えるごとに報告値が増え、速度が下がった。
この結果は、1つのモデル・1枚の GPU・1つのコンテキスト長（モデルが一度に扱える文脈の長さ。入力と出力を合わせたトークンで数える）で測ったものだ。コンテキスト長を変えると、VRAM の報告値も変わる。
VRAM 8GB の GPU に読み替えると。8GB を 8GiB として、8,192MiB で計算する。表の Q8_0 の 8,861MiB は、この数字の上では容量を超える。Q6_K の 7,128MiB は容量を下回るが、差の約1,060MiB がそのまま空きになるわけではない。表の値は Ollama の報告値で、画面の表示や他のソフトが使う VRAM は含まれていないためだ。nvidia-smi に出る実際の容量は、GPU によって 8,192MiB と少し違う。
VRAM 12GB の GPU に読み替えると。12GB も同じ計算で 12,288MiB になる。この 8B のモデルは、Q8_0 の報告値 8,861MiB も容量を下回る。差がそのまま空きになるわけではない点は、8GB の場合と同じだ。
どちらも表の数字の読み替えで、VRAM 8GB や 12GB の GPU で動くかどうかを確かめた結果ではない。
まず Q4_K_M を試し、VRAM に余裕があれば、ビット数の多い形式に替える。モデルが大きく、Q4_K_M でも GPU 上の合計が容量に近くなる場合は、Qwen3.8-27B で測った例のように、ファイルが1つ小さい形式とも速さを比べる。ただし、この測定では回答の質を測っていない。ビット数の多い形式に替えると答えがどう変わるかは、「Llama-3.1-8B の量子化の形式ごとの測定」の表からは言えない。
形式ごとの精度の考え方は、Q4_K_M から Q8 までの量子化フォーマットの選び方で整理している。Q4_K_M・Q8_0・FP16 の VRAM と速度を並べた別の実測は、ローカルLLMの量子化を実測で比べた記事にある。コンテキスト長を伸ばしたときの VRAM の増え方は、VRAM 16GB でコンテキスト長をどこまで伸ばせるかの実測で扱っている。
Qwen3.8-27B は、GPU 上の合計が容量に近い形式で RTX 5080 の生成が半分以下に落ちた
モデルが大きくなると、形式を1つ替えるだけで、VRAM 16GB に余裕があるかどうかが変わる。27B の LLM、Qwen3.8-27B で、ファイルの大きさと量子化の方式が違う3つの形式を比べたのが「Qwen3.8-27B の量子化3種の測定」の表だ。生成速度は、画面表示に使っていない RTX 5060 Ti と、画面表示にも使っている (モニターをつないでいる) RTX 5080 の両方で測った。この2枚は型番のほかに、画面表示に使っているかどうかと、パソコンへのつなぎ方も違う。
形式名の頭の UD- は、配布元の Unsloth が自社の作り方 (Unsloth Dynamic) で作った GGUF に付けている名前だ。同じ Q4_K_M という名前でも、UD- の付かないファイルとは別のファイルになる。
| 量子化 | ファイルの大きさ | GPU 上の合計 (llama.cpp の報告) | RTX 5060 Ti (画面表示なし) | RTX 5080 (画面表示あり) |
|---|---|---|---|---|
| UD-Q3_K_XL | 12.24GiB | 12,651MiB (約12.35GiB) | 毎秒29.0トークン | 毎秒53.5トークン |
| UD-IQ4_XS | 13.27GiB | 13,706MiB (約13.38GiB) | 毎秒26.8トークン | 毎秒51.8トークン |
| UD-Q4_K_M | 15.33GiB | 15,654MiB (約15.29GiB) | 毎秒24.5トークン | 毎秒21.4トークン |
UD-Q4_K_M は、GPU 上の合計が 15,654MiB (約15.29GiB) で、GPU の容量 (nvidia-smi の表示で約16,300MiB) の約96%にあたる。ファイルが1つ小さい UD-IQ4_XS は約84%だ。画面表示にも使っている RTX 5080 では、UD-Q4_K_M の生成速度が、UD-IQ4_XS の半分以下に落ちた。ただし、RTX 5080 の UD-Q4_K_M の値は、測るたびに変わりやすかった。
画面表示に使っていない RTX 5060 Ti では、UD-Q4_K_M でも毎秒24.5トークンで、UD-IQ4_XS の毎秒26.8トークンから大きくは落ちなかった。
RTX 5080 の VRAM は、llama.cpp のほかに、画面表示なども使っている。モデルを読み込んだあとの nvidia-smi の使用量は、UD-Q3_K_XL が 14,141MiB、UD-IQ4_XS が 15,206MiB で、どちらも GPU 上の合計より約1,500MiB 多かった (この差が何に使われているかの内訳は分けていない)。UD-Q4_K_M にも同じだけ加わるとすると、nvidia-smi の使用量は約17,150MiB になり、容量 (約16,300MiB) を超える。実際の表示は 15,708MiB で、GPU 上の合計より多かったのは約54MiB だけだった。
収まらなかった分がメインメモリに回って遅くなった可能性があるが、同じ GPU で画面表示を外した場合とは比べていない。RTX 5060 Ti とは型番・画面表示・つなぎ方が同時に違うので、遅くなった原因は切り分けていない。約96%という値も、どの環境でも遅くなる境目を示すものではない。
表の「GPU 上の合計」は、llama.cpp が報告した重み・文脈を保存する領域・計算用の領域などのうち、GPU に置かれた分を足したものだ。GPU 全体の使用量や、動かすのに最低限要る容量を表す値ではない。llama.cpp の報告では、重みの一部 (521〜682MiB) は GPU ではなくパソコンのメインメモリに置かれ、合計には含まれない。読み込みのログには、使われない重みも個別に出ていて、足すと約335MiB になる。これもファイルには入っている。GPU 上の合計は、ファイルの大きさからこの2つを引き、文脈を保存する領域や計算用の領域を足した値になる。UD-Q4_K_M は、引く分が足す分を上回り、合計がファイルの大きさより小さくなった。
GPU 上の合計が容量に近い形式を使うときは、ファイルが1つ小さい形式とも速さを比べる。Qwen3.8-27B という1つのモデル・1つの構成での観測なので、手元でも両方を試してほしい。VRAM が 12GB の GPU では、測った3つのうち最も小さい UD-Q3_K_XL の 12,651MiB でも、全層を GPU に載せる設定では容量を数字の上で超える (これより小さい形式は測っていない)。27B での測定の詳細は、Qwen3.8-27B を VRAM 16GB で動かした実測にまとめている。
測った2つの画像生成モデルでは、int8 と nvfp4 が bf16 より短い時間で作れた
画像生成では、2つのモデルで本体の形式を bf16・int8・nvfp4 と替え、1枚を作る時間を RTX 5080 と RTX 5060 Ti で測った。どちらのモデルも、PyTorch は cu130 だった。nvfp4 は、NVIDIA が Blackwell 世代の GPU とともに導入した4ビットの形式だ。
Z-Image-Turbo の場合
「Z-Image-Turbo の形式ごとの生成時間」の表は、1024×1024 の画像1枚にかかった時間と、bf16 の画像との近さを表す PSNR を並べたものだ。PSNR の読み方は「品質はどこまで変わるか」の節で説明する。ファイル名の int8_convrot は、int8 の形式の1つだ。「本体のファイル」の列は VRAM に置く量の目安になる。生成中の VRAM のピークも記録したが、GPU 全体の値で、動かすのに最低限要る量を表さないため、この記事には載せていない。bf16 の 11.46GiB は VRAM 8GB の GPU の容量を超え、int8_convrot の 5.78GiB と nvfp4 の 4.20GiB は下回る。これは本体のファイルの大きさと容量の数字の比較で、テキストエンコーダーや計算の途中のデータは含まない。VRAM 8GB の GPU で動くかどうかと、動いたときの速さは測っていない。
| 本体の形式 | 本体のファイル | RTX 5080 | RTX 5060 Ti | bf16 との PSNR |
|---|---|---|---|---|
| bf16 | 11.46GiB | 6.4秒 | 13.2秒 | (基準) |
| int8_convrot | 5.78GiB | 3.2秒 | 6.2秒 | 29.7〜35.1dB |
| nvfp4 | 4.20GiB | 2.5秒 | 5.1秒 | 15.4〜20.0dB |
量子化した int8_convrot と nvfp4 は、どちらの GPU でも bf16 の約半分かそれ以下の時間だった。このモデルでは、nvfp4 が int8_convrot より短かった。画像がどう違ったかの実例は、Z-Image-Turbo の nvfp4・int8・bf16 を生成時間と画像の違いで比べた記事で見られる。
FLUX 3 Image Klein の場合
FLUX 3 Image Klein でも、1024×1024 の画像1枚にかかった時間を形式ごとに測った。使ったのは、少ないステップ（画像を仕上げていく計算の繰り返し回数）で出すように作られた蒸留モデルだ。配布元は、プロンプト拡張 (短い指示を長い説明文に書き直す前処理) を常に使うよう案内していて、配布元のワークフローでは最初から有効になっている。切ってよいのは、プロンプトがすでに十分な説明文になっているときだ。この測定では、書き直した説明文を先に用意して入力し、拡張にかかる時間を表に含めていない。拡張も動かした測定では、1枚あたり RTX 5080 で約8秒、RTX 5060 Ti で約9秒長くなった。表の時間は ComfyUI に送ってから画像を保存するまでの秒数で、Z-Image-Turbo の表の ComfyUI の実行時間とは、測る範囲が違う。結果は「FLUX 3 Image Klein の形式ごとの生成時間」の表のとおりだ。
| 本体の形式 | RTX 5080 | RTX 5060 Ti |
|---|---|---|
| bf16 | 8.5秒 | 17.7秒 |
| int8_convrot | 4.0秒 | 7.2秒 |
| nvfp4 | 4.8秒 | 9.1秒 |
このモデルでは、nvfp4 は、どちらの GPU でも int8_convrot より遅かった。量子化した2つは、どちらの GPU でも bf16 より短い時間だった。表の値は、12回作って初回を除いた11回の中央値だ。Z-Image-Turbo とは nvfp4 と int8_convrot の順番が逆だった。2つの測定は、モデルのほかに、ComfyUI のバージョン、ステップの数、サンプラー、テキストエンコーダーの形式、時間を測る範囲も違う。そのため、順番が逆になった理由は切り分けていないし、秒数を2つの表どうしで比べることもできない。詳しい測定は、FLUX 3 Image Klein の int8・nvfp4・bf16 の速さを測った記事にある。
int8 と nvfp4 の選び方
int8 と nvfp4 の両方が配布されているモデルでは、どちらが速いかを手元の環境で比べて選ぶ。2つの測定で順番が逆になり、Z-Image-Turbo では nvfp4、FLUX 3 Image Klein では int8_convrot のほうが短い時間だった (RTX 50 シリーズ・PyTorch cu130 の環境で、どちらも bf16 よりは短い)。高速な計算が働く形式は、GPU の世代で変わる (comfy-kitchen の説明による)。MiniMax H3 の測定では、PyTorch のビルドでも FP8 と INT8 の速さの順番が変わった (MiniMax H3 では、本体を nvfp4 にした条件は測っていない)。ComfyUI のバージョンの影響は測っていない。VRAM の容量別の選び方も、この記事では測っていない。
手元で比べるときは、次のようにする。
- どの形式にも、同じプロンプトと seed の並びを使う。
- モデルを読み込んだ直後の1枚目を除き、数枚の時間の中央値を見る。
- seed は1枚ごとに変える。同じ設定のまま続けて流すと、ComfyUI は変化のない部分を計算し直さないことがある。
枚数の少ない比較は、目安にとどまる。
ComfyUI の公式ブログ (2026年1月) は、NVFP4 がうまく動いた場合、RTX 50 シリーズで FP8 や BF16/FP16 に比べて約2倍の速さになると説明している。ComfyUI の開発元による説明で、この記事の表と同じ測り方の数字とは限らない。
MiniMax H3 では、PyTorch が cu128 のとき INT8 が FP8 より遅くなった
量子化した形式どうしの速さの順番は、PyTorch のバージョンやビルドで入れ替わることがある。cu130 は CUDA 13.0 向け、cu128 は CUDA 12.8 向けのビルドという意味だ。動画生成の MiniMax H3 を RTX 5060 Ti で動かし、ComfyUI はそのままで PyTorch だけを入れ替えて、動画1本を作る時間を測った。結果は「MiniMax H3 の PyTorch 別の生成時間」の表にまとめた。
| PyTorch | FP8 | INT8 |
|---|---|---|
| cu130 (2.14.0+cu130) | 121.0秒 | 85.5秒 |
| cu128 (2.9.1+cu128) | 132.3秒 | 232.2秒 |
cu130 では、INT8 が FP8 より短い時間で動画を作れた。PyTorch だけを cu128 に戻すと、INT8 は FP8 より長くかかり、順番が入れ替わった。FP8 の時間は 121.0秒と 132.3秒で大きくは変わらず、大きく延びたのは INT8 だった。RTX 5080 でも、表と同じ2つの PyTorch で、順番は同じだった。
表の2つの PyTorch は、CUDA のビルドだけでなくバージョン (2.14.0 と 2.9.1) も違う。そのため、RTX 5060 Ti の表だけでは、差が CUDA のビルドで生じたとは言い切れない。RTX 5080 では、PyTorch を同じ 2.9.1 にそろえて CUDA のビルドだけを替えた比較も取っている。2.9.1+cu128 では FP8 が約65秒、INT8 が約117秒で、INT8 が FP8 の約1.8倍の時間かかった。2.9.1+cu130 では FP8 が約59秒、INT8 が約39秒で、INT8 のほうが短かった。FP8 も INT8 も量子化した形式で、量子化する前の bf16 との比較は、MiniMax H3 の測定では取っていない。形式ごとの映像と音の品質も比べていない。
ComfyUI の公式ブログは、NVFP4 の高速化には CUDA 13.0 向けにビルドされた PyTorch (cu130) が要ると説明している。そうでない環境ではモデルは動くものの、FP8 より最大で2倍遅くなることがあるという。この説明の対象は NVFP4 だが、この測定では INT8 でも cu128 で FP8 より遅くなった。
ComfyUI の README は2026年11月時点で、NVIDIA の RTX 20 シリーズ以降の GPU では cu130 以上の PyTorch が必須だとしている。cu128 での結果は、2026年9月25日時点の比較として読んでほしい。
int8 や nvfp4 を使う前に、PyTorch が cu130 以上かを確かめる。
- 確かめ方: ComfyUI を起動したときのログに出る PyTorch のバージョンが、2.14.0+cu130 のように末尾が cu130 以上になっているかを見る。
- 古いビルドだった場合: 先に PyTorch を cu130 以上に上げる。ComfyUI の入れ方 (ポータブル配布・デスクトップアプリ・手動での導入) によって更新の手順が違うので、いま使っている ComfyUI が読み込む Python の環境を更新する。
- 上げたあとに ComfyUI が起動しない場合: NVIDIA のドライバが古い可能性がある。cu130 を同梱した Windows 向けのポータブル配布について、ComfyUI の README は、起動しなければドライバを更新するよう案内している。
- 上げられない環境: fp8 も試す。fp8 と int8 のどちらにも同じプロンプトと seed の並びを使い (seed は1本ごとに変える)、1本目を除いた時間の中央値を比べる。
動画生成での測定の詳細は、MiniMax H3 を ComfyUI で動かした RTX 5080・5060 Ti の実測にある。
品質はどこまで変わるか
画像生成の場合
画像の品質は、Z-Image-Turbo で bf16 の画像との近さを測った。物差しにしたのは PSNR (2枚の画像の画素の近さを表す数値。大きいほど近い) だ。同じプロンプト・同じ seed（画像を作るもとになる乱数の値）で作った画像を、bf16 の画像と比べた。
int8_convrot は 29.7〜35.1dB、nvfp4 は 15.4〜20.0dB だった。nvfp4 は bf16 と同じ seed でも、背景や小物の配置まで違う画像になった。
PSNR は bf16 の画像との近さを表す数値で、画像の良し悪しを表す数値ではない。Z-Image-Turbo では、bf16 の画像に近かったのは int8_convrot、時間が短かったのは nvfp4 だった。FLUX 3 Image Klein では int8 のほうが速く、画像の違いは比べていない。速さで選ぶときは、手元で両方を比べる。
LLM の場合
llama.cpp の説明は、量子化で精度が下がることがあるとしている。どれだけ下がるかは、モデルと形式によって違う。この記事の測定では、LLM の回答の質を形式ごとに比べていない。そのため、どの形式から答えが変わるかは、ここからは言えない。
よくある質問
Q4_K_M と Q8_0 はどちらを選べばよいか
まず Q4_K_M を試し、VRAM に余裕があれば Q8_0 まで、ビット数の多い形式に替えていく。Q8_0 は8ビットに丸める方式で、Q4_K_M より重みのビット数が多く、量子化の誤差は小さくなる傾向がある。そのぶん VRAM を多く使う。Llama-3.1-8B を RTX 5080 で測った例では、Q8_0 は Q4_K_M より VRAM の報告値が 3,201MiB 多く、生成速度は約36%低かった。回答の質は比べていないので、質の差はこの記事からは言えない。モデルが大きく、Q4_K_M でも GPU 上の合計が容量に近くなる場合は、ファイルが1つ小さい形式とも速さを比べる。
nvfp4 は RTX 40 シリーズでも使えるか
NVFP4 の高速な計算は、comfy-kitchen の説明では、RTX 50 シリーズなどの Blackwell 世代の GPU が要件だ。RTX 40 シリーズ以前の GPU で nvfp4 のファイルが動くか、動いたときの速さは、この記事では確かめていない。
ビット数の少ない形式ほど必ず速いか
そうとは限らない。画像生成の FLUX 3 Image Klein では、4ビットの nvfp4 が8ビットの int8 より遅かった。同じ8ビットどうしでも、動画生成の MiniMax H3 では、PyTorch が cu128 のとき INT8 が FP8 より遅くなった。ComfyUI の公式ブログも、NVFP4 は cu130 の PyTorch でないと FP8 より遅くなることがあると説明している。画像生成の2つのモデルでは、量子化した形式はどれも bf16 より短い時間だった。MiniMax H3 は bf16 を測っていないので、cu128 の INT8 が bf16 より遅いかどうかは分からない。
測定の条件と注意点
実測はすべて、Intel Core i7-14700F・メインメモリ96GB・Windows の測定機で行った。GPU は RTX 5080 (16GB) と RTX 5060 Ti (16GB) の2枚だ。RTX 5080 は画面表示に使っていて、PCI Express 5.0 の16レーンでつないでいる。RTX 5060 Ti は OCuLink（PCI Express の信号をケーブルで外へ引き出す接続規格。外付けの GPU をつなぐのに使われる）でつなぎ、負荷をかけたときのリンクは PCI Express 4.0 の4レーンで、画面出力には使っていない。
GPU で動いたことは、次の方法で確かめた。Llama-3.1-8B は、Ollama の報告で、4つの形式ともモデルの全体が GPU に置かれていた。Qwen3.8-27B は、llama.cpp の読み込みのログで全66層が GPU に割り当てられていて、生成中の GPU の使用率と VRAM を nvidia-smi で記録した (RTX 5080 の UD-Q4_K_M は、割り当てた分が VRAM に収まりきらなかった可能性がある)。ComfyUI の測定は、使う GPU を指定して ComfyUI を起動し、生成中の VRAM のピークを nvidia-smi で記録した。
表ごとの条件と、測った日は次のとおり。
- Llama-3.1-8B の量子化の形式ごとの測定 (2026年9月15日): RTX 5080・Ollama 0.34.0・Llama-3.1-8B (instruct) の量子化違い4つ。コンテキスト長は 8,192、KVキャッシュ（それまでの文脈から計算した途中の結果を保存しておき、同じ計算を繰り返さずに済むようにする仕組み。文脈が長いほど大きくなる）は f16、temperature (出力のばらつきを決める設定) は 0、seed は 42、生成するトークンの上限は 512、think の設定は false、Flash Attention は有効。プロンプトは、同じ質問文に回ごとの番号を付けて毎回変えた。この回ごとの番号は、慣らしと測定のどちらも、どの形式でも同じにした。応答は上限に届く前に終わっていて、長さは回によって違う (32〜322トークン)。生成の長さをそろえた比較ではないので、速度はこの条件での目安として読んでほしい。慣らしのあと3回ずつ測る組を二度行い、6回の中央値を生成速度とした。1回ごとの速度は、Ollama が応答と一緒に返す eval_count (生成したトークンの数) を、eval_duration (生成にかかった時間。単位はナノ秒) を秒に直した値で割ったものだ。モデルの読み込みやプロンプトの処理にかかった時間は含まない。形式を替えるときは、keep_alive (Ollama が、応答のあともモデルを VRAM に置いておく時間の設定) を 0 にして、測り終えたモデルを解放してから、次の形式を読み込んだ。VRAM の報告値は、Ollama が報告したモデルの VRAM 上の大きさで、GPU 全体の使用量ではない。1つのモデル・1枚の GPU・1つのコンテキスト長の結果で、回答の質は測っていない。
- Qwen3.8-27B の量子化3種の測定 (2026年8月25日): Qwen3.8-27B の GGUF 3種・llama.cpp (llama-server) b10356。全層を GPU に載せる設定で、コンテキスト長は 4,096、KVキャッシュは f16。GPU 上の合計は、llama.cpp が報告した内訳 (重み・KVキャッシュ・計算用の領域など) のうち GPU に置かれた分の合計。--parallel (同時に受け付ける会話の枠の数を決めるオプション) は指定しておらず、起動時のログでは、その枠 (スロット) が4つになっていた。KVキャッシュは 256MiB、このモデルが文脈の状態を持つ領域は 598.5MiB だった。生成速度は、llama-server の /completion (チャットのテンプレートを通さない経路) に毎回違うプロンプトを送り、3回測った中央値。1回ごとの速度には、llama-server が応答と一緒に返す timings の predicted_per_second を使った。これは、生成したトークンの数を生成にかかった時間で割った値だ。プロンプトの処理にかかった時間は含まない。3つのプロンプトは、どの形式にも同じものを同じ順で送った。サーバーを起動したあと、短いプロンプトで1回慣らし、その回は除いた。temperature は 0.7、top_p は 0.8、top_k は 20 で、seed は指定していない。llama-server は形式ごとに起動し直した。生成するトークンは128を上限にした短い応答で、長さは回によって違う。seed を固定していない短い応答3回の中央値なので、出力の長さや内容をそろえた比較ではない。速度は参考の値として読んでほしい。思考つきの対話で待つ時間とは、別の測り方だ。モデルのファイルは2026年8月25日に取得したもので、配布元で後から更新されていれば、いま配布されているファイルとは大きさが違うことがある。RTX 5080 の UD-Q4_K_M の生成速度は、測るたびに変わりやすかった (原因は切り分けていない)。
- Z-Image-Turbo の形式ごとの生成時間 (2026年10月2日〜3日): ComfyUI 0.38.0・PyTorch 2.14.0+cu130・1024×1024・8ステップ・サンプラーは res_multistep・スケジューラーは simple・CFG (プロンプトにどれだけ強く沿わせるかを決める設定) は 1。テキストエンコーダー (プロンプトの文章を読み取る部分) は bf16 で固定し、本体だけ形式を替えた。時間は、プロンプトを毎回変えて作った2枚目以降の3枚の、ComfyUI の実行時間の中央値。プロンプトと seed の並びは、どの形式でも同じにした。ComfyUI は形式ごとに起動し直し、同じ形式の中では起動したまま続けて作った。起動したあとの1枚目はモデルの読み込みを含むので、時間の集計から除いた。PSNR は、同じ GPU・同じプロンプト・同じ seed で作った 1024×1024 の画像を、大きさを変えずに bf16 の画像と RGB の画素ごとに比べた値 (10 × log10(255² ÷ 画素の差の2乗の平均))。3つの題材 × 2枚の GPU の6組を比べ、その最小から最大までを表に載せた。1つのモデルの結果。
- FLUX 3 Image Klein の形式ごとの生成時間 (2026年10月16日): ComfyUI 0.41.0・PyTorch 2.14.0+cu130・蒸留モデル・1024×1024・16ステップ・サンプラーは euler・スケジューラーは simple・CFG は 1。テキストエンコーダーは int8_convrot で固定し、本体だけ形式を替えた。4つの題材を seed を変えて3周、合わせて12回作り、初回を除いた11回の中央値を載せた。題材と seed の並びはどの形式でも同じで、ComfyUI は形式ごとに起動し直した。時間は、ComfyUI に送ってから画像を保存するまでの秒数。プロンプト拡張は使わず、あらかじめ書き直した説明文を入力した (拡張の時間は含まない)。拡張も動かした測定は、同じ回数で行った。本文の約8秒・約9秒は、拡張ありと拡張なしの中央値の差だ。1つのモデルの結果で、画像の違いは比べていない。
- MiniMax H3 の PyTorch 別の生成時間 (2026年9月25日): RTX 5060 Ti・ComfyUI 0.37.1・864×480・56フレーム・20ステップ。PyTorch だけを 2.14.0+cu130 と 2.9.1+cu128 で入れ替えた。本体のファイルは、FP8 が minimax_h3_fl2va_pruned_fp8_scaled.safetensors、INT8 が minimax_h3_fl2va_pruned_int8_convrot.safetensors で、どちらも Comfy-Org が Hugging Face で配布している。ファイル名の上では、モデルの系統 (fl2va) と pruned であることは同じで、違うのは量子化の形式 (fp8_scaled と int8_convrot) だ。ファイルの中身がほかに違わないかまでは確かめていない。LoRA は使っていない。サンプラーは res_multistep・スケジューラーは simple。文章のプロンプトだけから映像と音声を作った。参照用の画像・映像・音声は入力していない。CFG は使っていない (ComfyUI の BasicGuider というノードを使った)。この測定で替えたのは本体の形式 (FP8 か INT8 か) と PyTorch だけで、テキストエンコーダーと2つの VAE は、どの条件でも同じファイルを使った。テキストエンコーダーは qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors で、ファイル名では nvfp4 の形式になっている。VAE (生成の途中で作られた内部のデータを、映像や音声に戻す部分) は、映像用が minimax_h3_video_vae_fp16.safetensors、音声用が minimax_h3_audio_vae_fp32.safetensors。テキストエンコーダーを別の形式に替えた場合は測っていない。プロンプトはどの条件でも同じにした。seed は1本ごとに変え、その並びは、FP8・INT8 のどちらでも、PyTorch のどちらのバージョンでも同じにした。ComfyUI は、形式と PyTorch の組み合わせごとに起動し直し、1回の測定の中では起動したまま続けて作った。時間は ComfyUI の実行時間で、モデルを読み込んだあとの2本目以降5本の中央値。1つのモデル・1つの解像度・1つのテキストエンコーダーの結果で、RTX 5080 でも順番は同じだった。表の2行は PyTorch のバージョンも違う。RTX 5080 では、ComfyUI は同じ 0.37.1 のまま、同じ 2.9.1 の cu128 と cu130 も比べた。この比較の時間は2本目以降の中央値で、中央値に使った本数は、cu128 の FP8 が5本・INT8 が10本、cu130 の FP8・INT8 が各5本だった。10本の条件は、同じ seed の並びの測定を2度行った分を合わせている (2度とも ComfyUI を起動し直し、それぞれの1本目を除いた)。bf16 との比較と、形式ごとの映像・音の品質の比較はしていない。
測っていないこともある。LLM の回答の質は、形式ごとに比べていない。RTX 40 シリーズ以前の GPU では、どの表も測っていない。FLUX 3 Image Klein の画像の違いと、MiniMax H3 の映像・音の違いは比べていない。画像・動画生成では、生成中の VRAM のピークを記録したが、この記事には載せておらず、形式どうしで比べてもいない。VRAM 8GB・12GB の GPU でも測っていない。
表どうしは、モデル・設定・測った日が違う。別の表の数値どうしは比べられない。
本記事の実測値は、2026年8月25日〜10月16日に計測したもの。測定機と設定は「測定の条件と注意点」の節に書いたとおり。
参考資料
- llama.cpp quantize ツールの README
- llama.cpp: K が付く量子化の方式を導入したときの説明 (Pull Request 1684)
- Hugging Face Hub ドキュメント: GGUF
- NVIDIA Developer Blog: Introducing NVFP4 for Efficient and Accurate Low-Precision Inference
- ComfyUI Blog: New ComfyUI Optimizations for NVIDIA GPUs
- comfy-kitchen (GitHub)
- ComfyUI の README (2026年11月13日に確認)
- FLUX 3 Image Klein のモデルカード (Hugging Face)
- Comfy-Org による MiniMax H3 の配布ページ (Hugging Face)
