拡散モデルの精度フラグを切り替えると何が起きるかは、モデルによって違う。RTX 5080 16GBで5モデルを測ったところ、VRAMが減ったモデルもあれば、フラグを変えてもVRAMピークがほぼ動かなかったモデルもあり、--fp8_e4m3fn-unetへの切り替えで速度向上を確認できたモデルはなかった。本稿は当サイトがRTX 5080 16GB環境で測った実測と、ComfyUI公式リポジトリのドキュメントを突き合わせ、精度の選び方を整理する。精度を落とすのはたいてい、通常版が重くて扱いにくいから少しでも扱いやすくしたいときだろう。そのつもりで読むと結果は素直ではない。VRAMが減る場合でも生成時間まで短くなるとは限らず、SDXLではむしろ伸びた。
- FP32は1値32bit、FP16/BF16は16bit、FP8は8bit。同じモデルでもメモリ要求が大きく変わる
- BF16はFP16より動的範囲が広い。ただし出力の安定性は本記事では測っていない
- RTX 5080 16GBで5モデルを実測した。
--fp16-unetから--fp8_e4m3fn-unetへ切り替えてVRAMピークが下がったのは、そのうち2モデルだけだった - 下がったモデルでは、生成時間が伸びるか、ほぼ変わらなかった。この切り替えで速度向上を確認できたモデルはない
- FLUX.2 Klein 9B（Q8_0 GGUF）では
--fp16-unetのほうが速くVRAMも少なかった。ただしGGUFは重みの形式がファイル側に固定されており、他の4モデルと同じ意味での精度指定とは限らない - 下がった2モデルと下がらなかった3モデルでは配布ファイル総量の大小が結果と一致したが、5例を見たあとで引いた線であって、理由を確かめたわけではない
- 精度を落として何が得られるかはモデルによって違う。VRAMが足りないときの手段であって、速くするための手段ではない
FP32・FP16・BF16・FP8の違い ─ bit配分と数値表現
FP32とFP16はIEEE 754で標準化された浮動小数点形式で、BF16とFP8は深層学習向けに設計・普及した低精度形式である（BF16はGoogleが定義した16bit形式、FP8のE4M3は最大有限値が±448で無限大を持たない）。同じ「数値」でも、何ビット使ってどう分配するかで表現できる範囲と精度が変わる。
| 形式 | 合計bit | 符号 | 指数部 | 仮数部 | 表現範囲 | 主な用途 |
|---|---|---|---|---|---|---|
| FP32（single） | 32 | 1 | 8 | 23 | ±3.4×10^38 | 従来の学習・推論基準 |
| FP16（half） | 16 | 1 | 5 | 10 | ±6.5×10^4 | 推論加速・VRAM節約 |
| BF16（bfloat16） | 16 | 1 | 8 | 7 | ±3.4×10^38（FP32同等） | 学習・大規模モデル推論 |
| FP8 E4M3 | 8 | 1 | 4 | 3 | ±448 | 大規模モデル推論（Flux等） |
| FP8 E5M2 | 8 | 1 | 5 | 2 | ±5.7×10^4 | 推論・勾配計算 |
FP16とBF16はいずれも16bitだが、内訳が異なる。FP16は仮数部10bitで精度が高い一方、表現範囲が±65,504で狭い。深層学習で勾配が小さくなりすぎたり大きくなりすぎたりするとオーバーフロー・アンダーフローを起こしやすい。
これに対しBF16は指数部をFP32と同じ8bitとし、表現範囲を維持した代わりに仮数部を7bitに削った。Googleが学習用に開発した形式で、NVIDIA Ampere（A100、RTX 30シリーズ）以降のテンソルコアがネイティブ対応している。Hugging FaceのDiffusers・PyTorch 2系・ComfyUIのいずれも、SDXL・SD3.5系のロード時にはBF16を選択肢として提供している。
FP8はさらに極端で、Comfy-Orgが配布するFlux 1 devのFP8チェックポイントなどで採用されている。Comfy-OrgやBlack Forest Labsからは、大型モデルを低精度化したFP8チェックポイントが配布されている。
精度を変えると何が変わるか ─ 5モデルの実測
計測環境はRTX 5080 16GB＋i7-14700F＋96GB RAM、ドライバ610.47、ComfyUI 0.31.1、PyTorch 2.9.1+cu128。DynamicVRAMと非同期ウェイトオフロードはいずれも無効化していない（後者はNVIDIA環境では既定で有効）。2026年8月24日に計測した。1モデルの中で変えたのは拡散モデル側の精度フラグだけで、解像度・ステップ数・サンプラー・シードの振り方はそのモデルの中で固定してある（テキストエンコーダには触れていない）。※解像度もステップ数もサンプラーもモデルごとに違うので、モデルをまたいで生成時間を比べることはできない。見るのは各モデルの中での3条件の差である。seedはrunごとに変えている——同じseedで投げるとComfyUIが結果を再利用して生成が走らず、2回目以降が1秒で返ってしまうためである。時間は各条件のwarm run（1条件あたり5〜6回）の中央値。5モデルとも、ComfyUIを起動し直した2回のセッションに分けて測っている。VRAMは生成中にnvidia-smiで拾ったピークをGiBへ換算した値で、デスクトップ表示ぶん（1〜2GiB）を含む。
| モデル | 精度フラグ | 生成時間の中央値 | VRAMピークの中央値 |
|---|---|---|---|
| SDXL base 1.0（一式6.5GiB） 1024×1024・30ステップ |
--fp16-unet |
6.05秒 | 約11.5GiB |
| SDXL base 1.0 | --bf16-unet |
6.05秒 | 約11.6GiB |
| SDXL base 1.0 | --fp8_e4m3fn-unet |
7.04秒 | 約7.3GiB |
| SD 3.5 medium（fp8_scaled版・一式10.8GiB） 1024×1024・30ステップ |
--fp16-unet |
10.05秒 | 約14.7GiB |
| SD 3.5 medium | --bf16-unet |
10.07秒 | 約13.5GiB |
| SD 3.5 medium | --fp8_e4m3fn-unet |
10.07秒 | 約11.1GiB |
| Flux 1 dev（FP8版・一式16.1GiB） 1024×1024・20ステップ |
--fp16-unet |
20.27秒 | 約15.2GiB |
| Flux 1 dev | --bf16-unet |
23.12秒 | 約15.2GiB |
| Flux 1 dev | --fp8_e4m3fn-unet |
20.09秒 | 約15.2GiB |
| FLUX.2 Klein 9B（Q8_0 GGUF版・一式17.7GiB） 1024×1024・4ステップ |
--fp16-unet |
4.04秒 | 約12.7GiB |
| FLUX.2 Klein 9B | --bf16-unet |
5.04秒 | 約13.9GiB |
| FLUX.2 Klein 9B | --fp8_e4m3fn-unet |
5.04秒 | 約13.9GiB |
| MiniMax H3（fp8_scaled版・画像→動画・一式39.5GiB） 864×480・56フレーム・20ステップ |
--fp16-unet |
61.35秒 | 約15.2GiB |
| MiniMax H3 | --bf16-unet |
65.51秒 | 約15.2GiB |
| MiniMax H3 | --fp8_e4m3fn-unet |
62.23秒 | 約15.2GiB |
Flux 1 devとMiniMax H3の生成時間は、条件間の差より測定ごとの振れのほうが大きく、3条件の速さの順位を判定できなかった値である。中央値は載せているが、順位の根拠にはならない。なお「一式」は拡散モデル・テキストエンコーダ・VAEの配布ファイルを合計した実サイズ。
同じ--fp8_e4m3fn-unetを指定しても、5モデルで起きたことが違った。VRAMが下がったのはSDXLとSD 3.5 mediumだけで、Flux 1 devとMiniMax H3は3条件とも動かず、FLUX.2 Klein 9Bでは--fp16-unetのほうが速くVRAMも少なかった。※ただしKleinだけQ8_0のGGUFで、重みの形式はファイル側に固定されている。フラグの切り替えに対する出方が他の4モデルと違った、という以上のことは言えない。
--fp16-unetを基準に--fp8_e4m3fn-unetへ切り替えてVRAMピークが下がったのは、5モデル中SDXLとSD 3.5 mediumの2モデルだった。以下「下がった/下がらなかった」はすべてこの切り替えについて、VRAMピークが下がったかどうかを指す（FP16とBF16はどちらも16bitで単純な上下関係にはないので、精度そのものの上下という意味ではない）。Kleinだけ出方が違う点については、この4ステップの蒸留版だけ読み込み経路が別で、Q8_0のGGUFをGGUF専用のローダー（UnetLoaderGGUF）が読む、という違いはある。ただしそれが理由なのかは本記事では確かめていない。なおKleinのVRAMピークは12.7〜14.0GiBで16GBの上限には届いていないので、「上限で頭打ちになったから差が出なかった」という説明はKleinには当てはまらない。
MiniMax H3はComfyUIを起動し直して2回測った。1回目は--fp8_e4m3fn-unetが3条件の中で最も速く（中央値59.33秒、FP16が65.36秒、BF16が68.90秒）、2回目は同じ条件が最も遅かった（中央値70.32秒、FP16が59.37秒、BF16が63.36秒）。同じ設定で順位が入れ替わるので、この3条件に速度差があるとは言えない。手元で試すときも、1回の測定で順位を決めないほうがいい。Flux 1 devも同様で、3条件とも17〜35秒に散っており順位は判定できなかった。
今回の5例で結果と一致した特徴の一つは、配布ファイル総量が16GiB未満かどうかだった。VRAMピークの低下を観測した2モデルはいずれも16GiB未満で、観測しなかった3モデルはいずれも16GiBを超えていた。※ファイルの総量と実行時のVRAM占有量は別物なので、これは容量の一致であって「収まるから効く」という話ではない。※ただし5モデルは一式のサイズ以外もそろっていない——保存形式、ローダー、DynamicVRAMやオフロードの効き方が同時に違う（FLUX.2 Klein 9Bだけ読み込み経路そのものが別である）。SDXLは6.5GiB、SD 3.5 mediumは10.8GiBで収まる。残る3つは収まらない——Flux 1 devが16.1GiBでちょうど境界上、FLUX.2 Klein 9Bが拡散モデル9.3GiB＋テキストエンコーダ8.1GiB＋VAE 0.3GiBで計17.7GiB、MiniMax H3にいたっては拡散モデルだけで19.5GiB・一式39.5GiBある。※ただしこれは5例の結果を見たあとで引いた線であって、これが理由だと確かめたわけではない。言えるのは、配布形式では説明がつかないということである——SD 3.5 mediumとMiniMax H3はどちらもfp8_scaled版なのに、前者は下がり後者は動かなかった。またFlux 1 devとMiniMax H3の約15.2GiBについては、モデルが要る量なのか、DynamicVRAMが空いているぶんまで使った結果なのかを本記事では切り分けていない（容量の違うカードやDynamicVRAM無効での対照を取っていない）。いずれにせよ見たのは生成時間とVRAMの挙動であって、モデル内部の保持形式を直接確認したわけではない。
減るとも限らず、どのフラグでいちばん少なくなるかもモデルによって違った。なおFP32での実行は本記事では測っていない。
本記事の実測では、SDXLは--fp16-unetと--bf16-unetで生成時間が同じ6.05秒、SD 3.5 mediumも10.05秒と10.07秒でほぼ同じだった。Flux 1 devとMiniMax H3は測定ごとのばらつきが大きく、順位を判定できなかった。例外はFLUX.2 Klein 9Bで、--fp16-unetが4.04秒・--bf16-unetが5.04秒と、6runとも同じ向きに約1秒開いた。5モデルのうちこの1つだけ、FP16とBF16の差がはっきり出た。それ以外では、特別な理由がなければ精度を強制せずComfyUI側の自動選択に任せておくのが扱いやすい（PyTorchのautocastはCUDAでの既定がFP16で、GPUに応じてBF16を選び分ける仕組みではない）。
なお本記事はControlNetやLoRAを併用した場合の追加VRAMを測っていない。併用時にどれだけ増えるかは構成によって変わるため、手元の環境で確かめてほしい。
フラグより配布版の選択のほうが大きく効くこともある
本記事が扱ったのは、すでに配布されている重みに起動フラグを与えたときの挙動である。どの精度で配布された版を選ぶかは、フラグより大きく効くことがある。※以下は別記事で測った値で、計測日も条件も違ううえ、測っている量の種類も違う（実行時のVRAMピークではなく、モデル本体のファイルサイズ）。上の表と同じ列で比べられる値ではない。
Krea 2の場合、コミュニティのFP8配布ページの表示では、量子化元のBF16版が本体だけで24.76GiB、そこから約12.01GiBまで下がって16GB級で動かせる範囲に入る（Krea公式は本体を26.3GBと表示しており、出所が違うと数字も少し変わる）。本記事の表で起動フラグが動かしたVRAMは最大でも約4.2GiB（SDXL）だったので、配布版の選択のほうが大きい。詳しくはKrea 2をローカルで動かす要件とライセンスにまとめている。
精度低下のトレードオフ ─ 再現性とノイズ
同じ重みをより少ないbit数の形式で保持できれば、理論上の重み容量は減る。ただし本記事が測ったのは、すでに配布されている重みに対してフラグを与えた場合である。その範囲では、--fp8_e4m3fn-unetでVRAMを減らせたのはSDXLとSD 3.5 mediumの2モデルで、Flux 1 dev・FLUX.2 Klein 9B・MiniMax H3では減らなかった。--fp16-unetは5モデル中4モデルでVRAMを減らす手段にならなかったが、Q8_0のGGUFで持つFLUX.2 Klein 9Bだけは、この指定のときが最も少なかった。速度についても、ComfyUIの--fp8_e4m3fn-unetは拡散モデルの重みをFP8で保持する指定であって、演算全体が速くなることを保証するものではない。いずれも再現性に影響する場合がある。代表的な事例を整理する。
FP16のオーバーフロー問題
SDXL系の一部レイヤー（特にVAEデコーダの中間表現）では、FP16の表現範囲を超える値が発生することがある。これはStable Diffusion XLのSDXL VAEで知られている問題で、FP16で実行すると内部の値がFP16の範囲を超えてNaNになり、黒画像が出ることがある。対策は、VAEだけBF16かFP32で回すか（--bf16-vae / --fp32-vae）、FP16向けに調整されたVAE（sdxl-vae-fp16-fix）へ差し替えるか。--fp16-vaeは対策ではなく、ComfyUI公式のヘルプ自身が「黒画像が出ることがある（might cause black images）」と注意書きしている。
FP16単独運用の数値不安定性とその対処は 論文「Mixed Precision Training」（Micikevicius et al., 2017）で扱われている。ただし同論文が使うのはIEEE FP16で、示している対策はFP32のマスター重みとloss scalingであり、BF16は扱っていない。BF16をFP32と同じ動的範囲を持つ形式として検討したのは 論文「A Study of BFLOAT16 for Deep Learning Training」（Kalamkar et al., 2019）のほうになる。
BF16の安定性
BF16はFP32と同じ動的範囲を持つため、SDXL VAEの黒化問題が起こりにくい。RTX 30シリーズ以降のAmpere系GPUはBF16のテンソルコア対応を持つ。速度差については上の実測表のとおりで、はっきり差が出たのはFLUX.2 Klein 9Bだけだった。出力のばらつきは測っていないので、安定性そのものを数値で比べることはできていない。
FP8の出力品質
本記事で計測したのはComfy-Orgが配布しているFlux 1 devのFP8チェックポイントである。なお現在はBlack Forest Labs自身も FLUX.1-dev-FP8 を公開している。ComfyUI公式のチュートリアルは、Comfy-Org版のFP8チェックポイントについて「フル版と比べて画質はわずかに落ちる（image quality is slightly reduced compared to the full version）」と明記している。これはFP8版チェックポイントとフル版の比較であって、起動フラグの話ではない。本記事はフル版を測っていないので、FP8配布版でどれだけVRAMを削れているかは本記事からは言えない（測ったFP8版は精度フラグによらず約15.2GiBだった）。画質を少し譲る位置づけを許容できるかは用途次第。
どのVRAMまで測ったか
実測と、そこから言えることを分けて置く。
| VRAM | 本記事の測定 | そこから言えること |
|---|---|---|
| 8GB・12GB | 未測定 | 16GBでの実測値から直接は可否を判断できない。VRAMピークにはデスクトップ表示ぶん（1〜2GiB）が含まれ、テキストエンコーダやVAEの扱いも構成で変わる |
| 16GB（RTX 5080で実測） | 5モデルとも生成できた。VRAMピークはSDXLが約7.3〜11.6GiB、SD 3.5 mediumが約11.1〜14.7GiB、FLUX.2 Klein 9Bが約12.7〜13.9GiB、Flux 1 devとMiniMax H3がいずれも約15.2GiB | SDXLとSD 3.5 mediumはFP8指定で余裕が増える。Flux 1 devとMiniMax H3は3条件とも16GBの上限付近に張り付いた（要求量なのか割り当て側の挙動なのかは切り分けていない）。FLUX.2 Klein 9Bは上限に届いておらず、その中で--fp16-unetのときが最も少なかった |
| 24GB以上 | 未測定 | VRAM側の余裕は増える方向。ただし本記事はFP32での実行も、Stability AI公式の通常版のSD 3.5も、フル版のFlux 1 devも測っていない |
※この表はVRAM容量ごとの可否を決めるものではない。本記事が測ったのは16GBのカード1枚での5モデルだけで、8GB・12GB・24GB以上は測っていない。
ComfyUI起動オプションの整理
ComfyUI公式リポジトリが提供する主要な精度・VRAM関連の起動フラグは以下のとおり。
| フラグ | 役割 | 目安・補足 |
|---|---|---|
--fp16-unet |
拡散モデルをFP16で実行 | 本記事の実測ではSDXLとSD 3.5で--bf16-unetと生成時間がほぼ同じ。FLUX.2 Klein 9Bではこの指定が最も速くVRAMも最小だった（Flux 1 devとMiniMax H3はばらつきが大きく判断できない） |
--bf16-unet |
拡散モデルをBF16で実行 | Ampere以降 |
--fp8_e4m3fn-unet |
拡散モデルの重みをFP8 E4M3FNで保持 | 効き方はモデル次第。本記事の実測ではSDXLとSD 3.5 mediumでVRAMが下がり、Flux 1 dev・FLUX.2 Klein 9B・MiniMax H3では下がらなかった |
--fp16-vae / --bf16-vae |
VAEを半精度で読み込み | VAE特有の黒化に注意 |
--lowvram |
DynamicVRAMが有効なら何もしない。無効な場合はテキストエンコーダをCPUで実行 | DynamicVRAM無効時 |
--novram |
--lowvramでも足りない場合に使う |
公式に容量の閾値は示されていない |
--gpu-only |
テキストエンコーダ等も含め全てGPUに置いて実行 | VRAMに余裕があり、GPU上に保持したい場合 |
--cpu |
全てCPUで実行（低速） | GPUを使わない場合 |
現行のComfyUIはDynamicVRAMと非同期のウェイトオフロードを備え、後者はNVIDIA環境では既定で有効。まずは何も指定せずに動かし、OOM（Out of Memory）が出たら--fp8_e4m3fn-unetでモデル側を軽くできないか見る、という順になる。本記事の実測では、--fp16-unetがVRAMを減らす手段になるかはモデルによって違った。SDXLでは--fp8_e4m3fn-unetより約4GiB多く使った一方、FLUX.2 Klein 9Bではこの指定のときが最も少なかった。--lowvramをまず足す運用は、DynamicVRAMが効いている環境では効果がない。なお--reserve-vramはOSや他アプリのために空けておくVRAM量を指定するもので、増やすとComfyUIが使える量はむしろ減る。
ComfyUI 0.18.x系で改善された精度関連の不具合
ComfyUI 0.18.0〜0.18.1にかけて、FP16精度に関する複数の不具合が修正されている。GitHubのリポジトリ上で確認できる主要なPRは以下（PR番号はリポジトリのhistoryで参照可能）。
- CannyノードがFP16で正常に動作しない問題の修正
- サンプリング処理がFP16の中間表現で問題を起こすケースの修正
- FP16の中間表現で生成結果が変わる問題の修正（ノイズ生成をCPUのFP32に統一）
- Wan VAEデコード時に照明・色が変化する問題の修正（PRではWan 2.2のI2V/T2Vで回帰テストされている）
VRAM節約のためにFP16運用しているユーザーほど影響を受ける修正である。これらはv0.18.1で修正済みである。本記事の計測はこれより新しい0.31.1で行っている。
なお、カスタムノードがFP16中間表現を内部で扱っている場合、ComfyUI本体のFP16処理変更と競合するケースがある。アップデート後にControlNet系・VAE系のカスタムノードで挙動が変わったら、それぞれのリポジトリで対応版が出ていないか確認するのが安全。
モデル別に分かったこと
本記事が測った5モデルについて分かったことと測っていないことを並べ、最後に測っていないWan2.1を公式値のみ参考として置く。
SDXL中心の運用
SDXLは本記事が測った5モデルの中で配布ファイルが最も小さく（一式6.5GiB）、VRAMピークも最も低かった。RefinerはBaseを解放してから読み込むワークフロー（ComfyUI標準のSDXL Refinerワークフロー）に従うとVRAMの山を二つに分けられる。
SD 3.5系の運用
本記事が測ったのはComfy-Orgが配布するfp8_scaled版のSD 3.5 mediumで、生成時間は精度フラグを変えてもほとんど動かず、VRAMピークだけが下がった。Stability AI公式の通常版（配布元が利用条件への同意を求める形で公開されている）は本記事では入手していないため、その構成での必要VRAMは測っていない。largeも未測定である。
Flux 1系の運用
本記事が測ったFlux 1 devはFP8で配布されている版で、1024×1024・20ステップが20秒台で完走し、VRAMピークは精度フラグによらず約15.2GiBだった。16GBのカードでは上限近くまで使う形になるため、12GB級で動かせるかどうかは本記事からは言えない。DynamicVRAMやCPUオフロードを含む構成なら動くという報告はあるが、テキストエンコーダ・VAE・OS側の確保分で実効の余裕が変わる。schnell版は測っていない。
FLUX.2 Klein 9Bの運用
本記事が測ったのはコミュニティが配布するQ8_0のGGUF版で、GGUF専用のローダー（UnetLoaderGGUF）から読み込んでいる。1024×1024・4ステップの生成は--fp16-unetで4.04秒・約12.7GiB、--bf16-unetと--fp8_e4m3fn-unetではどちらも5.04秒・約13.9GiBだった。5モデルの中でこのモデルだけ、3つの起動フラグに対する出方が他と違った。起動し直した2回の測定で6runとも同じ向きだった。※ただしこれを「精度を下げた結果」と読むことはできない。GGUFの重みはQ8_0のままファイルに固定されており、ローダーは実行時に必要な形式へ戻す構造になっている。起動フラグが何を変えてこの差になったのかは、本記事では確認していない。safetensorsで配布されたモデルに対する精度指定と同じ現象とは限らない。公式配布の非GGUF版は測っていない。16GB環境での実用手順はFLUX.2 Klein 9BをVRAM 16GBで実測にまとめている。
MiniMax H3の運用
本記事が測った5モデルの中で唯一の動画生成（画像から動画）で、拡散モデルだけで19.5GiB、テキストエンコーダとVAEを合わせると一式39.5GiBある。VRAMピークは約15.2GiBなので、拡散モデルの全体が同時に載っているわけではない。864×480・56フレーム・20ステップの生成は、精度フラグを変えてもVRAMピークが約15.2GiBから動かず、時間は58〜72秒に散って3条件の順位が測定のたびに入れ替わった。この構成では、精度フラグはVRAMを減らす手段にならなかった。別記事では同じ16GB環境で、拡散モデルをFP8で持つ版とINT8で持つ版を比べており、中央値でINT8がFP8の約1.86倍の時間がかかった（本記事とは条件が違う測定である）。保持形式の選び方が生成時間に出た例で、起動フラグより効いている。その比較や16GB環境での動かし方はMiniMax H3をVRAM 16GBで動かすを参照してほしい。
Wan2.1動画生成の運用（本記事では未測定・公式値のみ）
Wan2.1はモデルの規模で要求が大きく変わる。公式リポジトリはT2V-1.3Bについて必要VRAMを8.19GBとし、RTX 4090で5秒480Pの生成が約4分としている。VRAMが効いてくるのは14B級のほうで、解像度を上げるならさらに余裕が要る。OOMが出る場合、公式は--offload_model Trueと--t5_cpuの併用を案内している。
まとめ
精度フラグを変えて何が変わるかは、モデルごとに違った。RTX 5080 16GBの実測で--fp8_e4m3fn-unetによってVRAMピークが下がったのは、SDXLとSD 3.5 mediumの2モデルだけである。SDXLはその代わりに生成時間が伸びた。Flux 1 devとMiniMax H3は3条件ともVRAMが動かず、時間の差もばらつきに埋もれて判定できなかった。FLUX.2 Klein 9Bでは--fp16-unetが最も速くVRAMも最も少なかったが、このモデルだけQ8_0のGGUFで、他の4モデルと同じ土俵で「精度を下げた結果」として比べられる値ではない。
したがって--fp8_e4m3fn-unetは「速くするための指定」というより「載せるための指定」に近い。※ただし低下を観測できたのは、配布ファイル総量が16GiB未満の2モデルに限られた。配布ファイル総量が16GiBを超える3モデルでは低下を観測しておらず、うちFLUX.2 Klein 9BはGGUF専用のローダーを使っているので、同じ機構として比較することもできない。手元のモデルで効くかどうかはモデルによるので、VRAMが足りない場面で試して、生成時間とVRAMの両方を見て判断したい。Wan2.1のような本記事が測っていないモデルについては、公式が示す必要量を出発点にする。
※この結論が当てはまるのは、本記事が測った範囲である。5モデルのVRAMピークは約7.3〜15.2GiBで、いずれも16GBのカードの中に収まっていた。ただし配布ファイル総量が16GiB未満なのは5モデルのうち2つで、残る3つはそれを超えており、重みをすべて同時にVRAMへ載せた状態では動いていない。8GB・12GB・24GB以上のカードは測っていない。
関連の実機検証として、RTX VRAM別のLLM選定はRTX VRAM別ローカルLLM選定ガイド、デュアルGPU構成はComfyUI デュアルGPU運用ガイド、RTX 4070ミドルレンジ構成はRTX 4070 12GB VRAMの実力をRedditから読み解くを参照してほしい。
この記事の扱う範囲と関連記事
本記事の情報は記載時点のもの。製品アップデートや第三者ベンチマーク・価格・対応ランタイム等の変動で評価が変わる可能性がある。一定期間経過した内容は再検証を推奨する。
軽量GPUでLoRA学習まで試したい場合は、6GB VRAMから動くLoRAトレーナーを実測したAnima TrainFlow とはも参考になる。
参考資料
- ComfyUI 公式リポジトリ: Comfy-Org/ComfyUI
- GitHub: city96/ComfyUI-GGUF（GGUF形式を読み込むカスタムノード）
- Hugging Face: Comfy-Org/MiniMax-H3（本記事が使った再パッケージ版の配布元）
- Hugging Face 公式: black-forest-labs/FLUX.1-dev モデルカード
- Hugging Face 公式: madebyollin/sdxl-vae-fp16-fix モデルカード
- Hugging Face 公式: stabilityai/stable-diffusion-3.5-medium モデルカード
- Micikevicius et al., Mixed Precision Training (2017)
- Kalamkar et al., A Study of BFLOAT16 for Deep Learning Training (2019)
精度フラグ以外のVRAM関連オプション（dynamic VRAM・--lowvram・--novram など）の扱いは、ComfyUIの起動オプション実測ガイドで扱っている。
当サイトはAmazonアソシエイト・プログラムの参加者です。Amazonのアソシエイトとして、当サイトは適格販売により収入を得ています。
