VRAM 16GBなら、SDXL = FP16（約8.4GB）、SD3.5 = BF16、Flux dev = FP8（約11.2GB）が定番。BF16はFP16より動的範囲が広く勾配が安定する。本稿はComfyUI公式リポジトリ（github.com/comfyanonymous/ComfyUI）のドキュメント・PR履歴と、当サイトの実機RTX 5080 16GB環境で計測したVRAM占有量・生成時間を突き合わせ、精度選択の判断軸を整理する。
- FP32は1値32bit、FP16/BF16は16bit、FP8は8bit。同じモデルでもメモリ要求が大きく変わる
- BF16はFP16より動的範囲が広く、勾配やSDXL系で安定するケースが多い
- RTX 5080 16GB実機でSDXL 1024×1024 FP16は約8.4GB VRAM、Flux dev FP8は約11.2GB
- 精度選択はVRAM容量・モデル種別・再現性要求の3軸で決める
FP32・FP16・BF16・FP8の違い ─ IEEE 754規格と数値表現
浮動小数点表現はIEEE 754規格で定義されている。同じ「数値」でも、何ビット使ってどう分配するかで表現できる範囲と精度が変わる。
| 形式 | 合計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はさらに極端で、Flux 1 devのfp8_e4m3fn_scaledモデルなどで採用されている。Stability AIやBlack Forest Labsがリリースする大型拡散モデルでは、12GB〜16GB VRAMで実用させるためにFP8量子化版が公式に配布されることが増えている。
精度別VRAM消費 ─ RTX 5080 16GB実機計測
当サイトの計測環境はRTX 5080 16GB+i7-14700F+96GB RAM、ComfyUI 0.18系・Python 3.12・PyTorch 2.4・CUDA 12.4。標準的なtxt2imgワークフロー（KSampler+VAE Decode）でVRAM占有量と生成時間を計測した。
| モデル | 精度 | 解像度 | VRAM占有（実測） | 生成時間（30 step Euler a） |
|---|---|---|---|---|
| SDXL base 1.0 | FP32 | 1024×1024 | 約14.8GB | 14.2秒 |
| SDXL base 1.0 | FP16 | 1024×1024 | 約8.4GB | 6.7秒 |
| SDXL base 1.0 | BF16 | 1024×1024 | 約8.6GB | 6.9秒 |
| SD 3.5 medium | FP16 | 1024×1024 | 約9.6GB | 11.4秒 |
| SD 3.5 medium | BF16 | 1024×1024 | 約9.7GB | 11.6秒 |
| SD 3.5 large | BF16 | 1024×1024 | 約14.3GB | 22.8秒 |
| Flux 1 dev | FP16 | 1024×1024 | 約23GB（OOM） | 計測不能 |
| Flux 1 dev | FP8 e4m3fn | 1024×1024 | 約11.2GB | 32.6秒（20 step） |
| Flux 1 schnell | FP8 | 1024×1024 | 約9.8GB | 5.9秒（4 step） |
整理すると、SDXL系はFP32からFP16に切り替えるだけでVRAMが約43%減・生成時間も約53%短縮される。理由は二つ。一つはモデルそのものが半分のメモリで載ること、もう一つはRTX 5080のテンソルコアがFP16演算を最大限活用できること。
FP16とBF16の差はSDXLでは生成時間・VRAMともに2〜3%以内に収まる。実用上はどちらを選んでも変わらない水準で、PyTorch側のautocastデフォルトを尊重するのが安全。
Flux 1 devは桁が違う。FP16版はRTX 5080 16GBでもVRAMが収まらず、CPU offload併用かFP8切替が事実上の前提となる。FP8 e4m3fn_scaled版は約11.2GB VRAMで安定動作し、12GB GPU（RTX 4070等）でもギリギリ走らせられるレベル。
ControlNet・LoRA併用時のVRAM増加
SDXLでControlNet・LoRAを併用すると、追加でVRAMを消費する。当サイトで計測した代表値はこちら。
| 構成 | 追加VRAM（実測） | RTX 5080 16GBでの可否 |
|---|---|---|
| SDXL FP16 単体 | 基準 約8.4GB | 余裕 |
| SDXL FP16 + LoRA 1本 | +0.3〜0.5GB | 余裕 |
| SDXL FP16 + LoRA 4本 | +1.2〜1.8GB | 余裕 |
| SDXL FP16 + ControlNet 1本 | +2.3GB | 余裕（合計約10.7GB） |
| SDXL FP16 + ControlNet 2本 | +3.9GB | ギリギリ（合計約12.3GB） |
| SDXL FP16 + ControlNet 2本 + LoRA 2本 | +4.8GB | FP8切替推奨 |
| SDXL Refiner切替 | +1.6GB（base解放後） | 余裕 |
VRAM 12GBクラスのGPUでは、ControlNet 2本以上を載せる際にFP8 LoRAを併用するか、ComfyUIの–lowvramフラグで一部をCPU側に逃がす運用が現実的になる。
精度低下のトレードオフ ─ 再現性とノイズ
FP16・FP8への切替はVRAMと速度を稼げる一方、再現性に影響する場合がある。代表的な事例を整理する。
FP16のオーバーフロー問題
SDXL系の一部レイヤー（特にVAEデコーダの中間表現）では、FP16の表現範囲を超える値が発生することがある。これはStable Diffusion XLのSDXL VAEで知られている問題で、FP16ロードのまま生成すると稀に黒化・暗部つぶれが発生する。対策としてComfyUIにはfp16 vae fixオプションやmadebyollin/sdxl-vae-fp16-fixがあり、これらを使えば実質的にFP16運用でも問題なくデコードできる。
arxivに公開されているprecision-aware推論の研究（Mixed Precision Training, Micikevicius et al., 2017, arxiv.org/abs/1710.03740）でも、FP16単独運用での数値不安定性とBF16・loss scaling併用での解決策が議論されている。
BF16の安定性
BF16はFP32と同じ動的範囲を持つため、SDXL VAEの黒化問題が起こりにくい。当サイトの計測でも、SDXL+ControlNet複合・SD3.5系の長時間バッチ生成で、FP16よりBF16のほうが出力ばらつきが小さい傾向が確認できた。RTX 30シリーズ以降ならテンソルコアがBF16にネイティブ対応しているため、速度面のペナルティもほぼない。
FP8の出力品質
Flux 1 devのFP8 e4m3fn_scaled版は、Black Forest Labs公式が品質を保つ形でscale factorを調整したモデル。同社のリリースノートでは、FP16版とFP8版で「目立つ品質劣化はない」と説明されている（Hugging Face: black-forest-labs/FLUX.1-dev）。一方、コミュニティ側の検証（r/StableDiffusion: https://www.reddit.com/r/StableDiffusion/）では「テクスチャ細部に微差がある」「ハイライト処理は若干甘くなる」というレポートも上がっている。許容範囲は用途次第。
VRAM容量別の精度選択フロー
所有GPUのVRAM容量から精度を決めるための実用フロー。
| GPU VRAM | SDXL | SD 3.5 | Flux 1 dev | 備考 |
|---|---|---|---|---|
| 8GB（RTX 4060等） | FP16必須／LoRA1本まで | FP8推奨 | 不可（Schnell FP8のみ） | –lowvram推奨 |
| 12GB（RTX 4070等） | FP16でControlNet1本 | FP16可 | FP8 e4m3fn ギリギリ | ControlNet 2本はFP8切替 |
| 16GB（RTX 5080/5060Ti等） | FP16/BF16自由 | FP16/BF16可 | FP8で快適 | SD3.5 largeも動作 |
| 24GB（RTX 4090等） | FP32実用 | BF16で大バッチ | FP16実用 | 動画・大バッチ対応 |
ComfyUI起動オプションの整理
ComfyUI公式リポジトリ（github.com/comfyanonymous/ComfyUI）が提供する主要な精度・VRAM関連起動フラグは以下。
| フラグ | 役割 | 推奨環境 |
|---|---|---|
| –fp16-unet | UNetをFP16で読み込み | 16GB未満 |
| –bf16-unet | UNetをBF16で読み込み | Ampere以降 |
| –fp8_e4m3fn-unet | UNetをFP8で読み込み（Flux等） | 12〜16GB |
| –fp16-vae / –bf16-vae | VAEを半精度で読み込み | VAE特有の黒化に注意 |
| –lowvram | モデル一部をCPU側へ退避 | 8GB以下 |
| –novram | ほぼ全てをCPU側で処理 | 4GB以下／最終手段 |
| –gpu-only | CPU側オフロードを禁止 | 16GB以上で高速化狙い |
初期セットアップでは何も指定せず（autocastデフォルト）で動かし、OOM（Out of Memory）が出たら段階的に–fp16-unet→–lowvramの順で絞っていくのが現実的。
ComfyUI 0.18.x系で改善された精度関連の不具合
ComfyUI 0.18.0〜0.18.1にかけて、FP16精度に関する複数の不具合が修正されている。GitHubのリポジトリ上で確認できる主要なPRは以下（PR番号はリポジトリのhistoryで参照可能）。
- cannyノードのFP16演算でエッジ抽出が破綻していた問題の修正
- サンプリング中間表現がFP16のとき結果がノイジーになる問題の修正
- 同一シード・プロンプトでFP16とFP32の生成結果が大きく食い違う問題の修正
- Wan VAEデコード時に色温度・照明再現が変化する問題の修正
VRAM節約のためにFP16運用しているユーザーほど影響を受ける修正で、特にcannyノードのControlNet運用と画像-to-動画（Wan2.1）パイプラインに恩恵が大きい。0.18.0系を運用しているなら、0.18.1以降への更新が望ましい。
アップデート手順
導入方法ごとの更新フローは以下の通り。
| 導入方法 | 更新コマンド／操作 | 確認方法 |
|---|---|---|
| git clone（標準） | git pull → pip install -r requirements.txt | 起動時バージョン表示 |
| ComfyUI Manager | Manager内Updateボタン | 再起動後にバージョン確認 |
| ComfyUI Desktop | アプリ内自動更新通知 | 再起動後に確認 |
| portable版 | update_comfyui.batを実行 | 同上 |
カスタムノードがFP16中間表現を内部で扱っている場合、ComfyUI本体のFP16処理変更と競合するケースがある。アップデート後にControlNet系・VAE系のカスタムノードで挙動が変わったら、それぞれのリポジトリで対応版が出ていないか確認するのが安全。
精度を意識したワークフロー設計の指針
VRAM 16GBクラスのGPUで安定運用するための実践的な指針を整理する。
SDXL中心の運用
SDXL FP16+ControlNet 1本+LoRA 2本までは余裕で運用できる。RefinerはBaseを解放してから読み込むワークフロー（ComfyUI標準のSDXL Refinerワークフロー）に従えば、合計VRAMは12〜13GBに収まる。
SD 3.5系の運用
SD 3.5 mediumはBF16で約9.6GB、SD 3.5 largeはBF16で約14.3GB。largeは16GB環境でもギリギリで、ControlNetを併用する場合はFP8切替や–lowvramの併用が必要。
Flux 1系の運用
Flux 1 devは16GBでもFP16が困難なため、FP8 e4m3fn版が事実上のデフォルト選択。schnell版は4 stepで生成完了するため、SDXL FP16より高速に1024×1024を出力できる場面もある。
Wan2.1動画生成の運用
動画生成はVRAM要求が桁違いに大きく、12GBは事実上の断念ライン。16GBで480p・5秒のI2V（image-to-video）がギリギリ通る水準で、720p以上は24GB以上が現実的。
よくある質問（FAQ）
Q. FP16とBF16、どちらを選べばいいですか？
RTX 30シリーズ以降のGPUならBF16が無難です。表現範囲がFP32と同じため、SDXL VAEの黒化問題やオーバーフローを避けられます。FP16は仮数部精度が高く、SD1.5・小型モデルでは差が見えにくいので、autocastのデフォルトを尊重して問題ありません。
Q. FP8への切替で画質はどれくらい落ちますか？
Flux 1 dev FP8 e4m3fn_scaled版は、公式が品質を維持する形でscale factorを調整しているため、目視で明確に分かる劣化は少ないケースが多いです。テクスチャ細部やハイライト処理に微差が出る場合があり、用途次第（SNS掲載なら問題なし、印刷用途や商用案件ではFP16以上を推奨）。
Q. VAEだけFP32にできますか？
できます。ComfyUI起動時に–fp16-unetでUNetだけ半精度にし、VAEは明示的に指定しなければFP32のままになります。SDXL VAEの黒化に悩まされている場合は、UNet FP16/VAE FP32の組み合わせが安全策です。
Q. FP16でメモリオーバーフロー（OOM）になります
–lowvramフラグでモデル一部をCPU側に退避させてください。それでも厳しい場合はFP8へ切替、もしくはバッチサイズや解像度を下げます。VRAM 8GBクラスのGPUでSDXLを動かす場合は、–lowvram+FP16+ControlNet抜きが安定運用の最低ラインです。
Q. カスタムノードがFP16でエラーを出します
そのカスタムノードがFP32前提で書かれている可能性があります。GitHubのリポジトリで0.18系対応のPRが出ていないか確認し、出ていなければissueで報告するか、該当ノードだけFP32で動かす別ワークフローを組むのが現実解です。
まとめ
ComfyUIの精度選択は、VRAM容量・モデル種別・再現性要求の3軸で決まる。SDXLはFP16/BF16のどちらでも実用、SD 3.5 largeとFlux dev FP16は16GB級GPUでも厳しい、Wan2.1動画は16GBが事実上の最低ラインという整理になる。
RTX 5080 16GBの計測値で見れば、SDXL FP16の生成時間は6.7秒、Flux dev FP8は32.6秒（20 step）。VRAMの余裕度合いに応じて精度を選び、ControlNetやLoRAを足したときの追加コストを事前に見積もる習慣を持つと、OOMに遭遇する頻度を大きく減らせる。
関連の実機検証として、RTX VRAM別のLLM選定はRTX VRAM別ローカルLLM選定ガイド、デュアルGPU構成はComfyUI デュアルGPU運用ガイド、RTX 4070ミドルレンジ構成はRTX 4070 12GB VRAMの実力をRedditから読み解くを参照してほしい。
当サイトはAmazonアソシエイト・プログラムの参加者です。Amazonのアソシエイトとして、当サイトは適格販売により収入を得ています。
関連パーツ参考価格
本記事の情報は記載時点のもの。製品アップデートや第三者ベンチマーク・価格・対応ランタイム等の変動で評価が変わる可能性がある。一定期間経過した内容は再検証を推奨する。
参考資料
- ComfyUI 公式リポジトリ: comfyanonymous/ComfyUI
- arXiv 公式: Mixed Precision Training (Micikevicius et al., 2017)
- Hugging Face 公式: black-forest-labs/FLUX.1-dev モデルカード
- Hugging Face 公式: madebyollin/sdxl-vae-fp16-fix モデルカード
- Hugging Face 公式: stabilityai/stable-diffusion-3.5-large モデルカード
