結論：VRAMからあふれた分は「1GBあたり約0.42秒/step」で買い戻せる
RTX 4070 Ti SUPER（16GB）で20B級の画像モデルを測ったところ、GPUに載り切らなかった重み1,000MiBにつき1ステップあたり約0.42〜0.60秒が上乗せされました。そして「量子化を上げると遅くなる」は誤りでした。同じあふれ量で比べると、より大きいQ6_Kのほうが速かったからです。遅いのは16GBに収まらなくなるからでした。
ComfyUIで大きなモデルを読むと、VRAMが足りなくても即エラーにはならず「なんとなく遅い」状態になります。この記事はその「なんとなく」を秒数に置き換えます。条件を固定し、あふれる量だけを人為的に変えて計測しました。
なぜVRAM不足でも動いてしまうのか
2026年のComfyUIは、VRAMが足りないと重みの一部をCPU側に置いたまま動かします。使うたびにGPUへ転送するので、落ちない代わりに遅くなります。
ダイナミックVRAMは既定でON。ただしGGUFは別経路
ComfyUIは2026年初頭にダイナミックVRAM（内部名 aimdo）を導入し、v0.18以降はNVIDIAのWindows／Linuxで既定ONです。有効な間 --lowvram は無視され、--reserve-vram が「空けておく余裕」として渡されます。
ただしGGUFを読む ComfyUI-GGUF は独自のモデルパッチャを挟み、ダイナミックVRAM用のクラスではなく従来の部分ロードを使います。この記事の数字はそちらのコストです。
# GGUF（従来の部分ロード）＝あふれた量が数字で出る
loaded partially; 13494.67 MB usable, 13469.21 MB loaded, 2684.21 MB offloaded
# safetensors（ダイナミックVRAM）＝あふれた量は出ない
Model QwenImage prepared for dynamic VRAM loading. 11960MB Staged.usable は空きVRAMそのものではなく、そのモデルの重みに割り当てられた予算です。読み込みのたびに計算し直されるので、同じ設定でも数十MB単位で揺れます。
測っているのは「申告されたあふれ量と時間の関係」
あふれた量はComfyUIがログに申告した値で、プロファイラで実転送量を測ったものではありません。転送そのものの帯域は示せません。
測り方：あふれる量だけを動かす
「Q4とQ6を比べる」では、量子化方式・重みの総量・あふれ量が同時に変わり、原因を切り分けられません。そこで同じモデルのまま --reserve-vram で予算だけを絞り、あふれる量を作りました。計算量は変えていません。
1ステップの測り方
APIが返す所要時間には、モデルの読み込み（ディスク速度に依存）とVAEデコードが含まれます。比較には使えません。ログの loaded … から Requested to load WanVAE までを切り出し、ステップ数で割っています。
測定環境：RTX 4070 Ti SUPER（VRAM 16GB）／ComfyUI 0.20.1（デスクトップ版）／Qwen-Image-2512 GGUF（20B級）／1024×1024・20ステップ・cfg 1.0・euler＋simple・同一シード。
実測：あふれた量と1ステップの関係
| あふれた量 | 測定回数 | 1ステップ（中央値） | ばらつき |
|---|---|---|---|
| 0（全部GPUに載る） | 8 | 1.950秒 | 5.1% |
| 約500 MiB | 3 | 2.250秒 | 2.2% |
| 約600 MiB | 3 | 2.350秒 | 2.1% |
| 約2,550 MiB | 3 | 3.200秒 | 1.6% |
| 約2,650 MiB | 3 | 3.200秒 | 1.6% |
0から約2,650 MiBで1ステップが1.950→3.200秒（+64%）。20ステップなら1枚25秒の差で、平均すると1,000 MiBあたり0.472秒です。
失敗談：最初の2点から外挿したら13.8%外した
0〜600 MiBの傾き（1,000 MiBあたり0.635秒）で2,650 MiBの点を予測し、3.64秒と書き留めてから測りました。実測は3.200秒。最初の数百MBがいちばん高くつき、その先は安くなります（0→500は0.600秒、600→2,550は0.436秒）。「あふれた量に比例する」は成り立ちません。
※ 月額1,100円〜（WebUIの無料時間つき・超過分は時間課金）・セットアップなし／ComfyUI・AUTOMATIC1111対応・公式の対応モデルはStable Diffusion 1.5/2.0/2.1/XL（この記事のQwen-Image（20B）は対応一覧に無い）「量子化を上げると遅くなる」は誤りだった
Q4_K_M（12.3 GiB）とQ6_K（15.7 GiB）を既定設定で比べると、1ステップは1.950秒→3.100秒で59%遅くなります。素直に読むと「量子化を上げたから重い」ですが、同じあふれ量に揃えると逆転します。
| モデル | 重みの総量 | あふれた量 | 測定回数 | 1ステップ（中央値） | レンジ |
|---|---|---|---|---|---|
| Q4_K_M | 12,739 MiB | 3,639〜3,748 MiB | 6 | 3.575秒 | 3.500〜3.600 |
| Q5_K_S | 13,744 MiB | 3,615〜3,721 MiB | 4 | 3.900秒 | 3.850〜3.950 |
| Q6_K | 16,153 MiB | 3,670〜3,778 MiB | 6 | 3.550秒 | 3.500〜3.650 |
あふれ量をほぼ同じに揃えると、Q6_KとQ4_K_Mの差は0.03秒でレンジも重なり、差を検出できません。Q6_Kは重みが27%多いのにです。いっぽうQ5_K_Sだけは0.33秒はっきり重く、レンジも重なりません。
つまりQ4→Q6で59%遅くなった分は、量子化方式ではなくあふれのぶんでした。重い・軽いの順序はQ5_K_S ＞ Q4_K_M ≒ Q6_Kで、ビット数の順番とは一致しません。
| 量子化 | あふれ1,000 MiBの単価 | 重み1 GiBあたりの計算コスト |
|---|---|---|
| Q4_K_M | 0.472秒 | 0.158秒 |
| Q5_K_S | 0.427秒 | 0.172〜0.175秒（重い） |
| Q6_K | 0.405秒 | 0.118〜0.129秒（軽い） |
あふれ1,000 MiBあたりの単価は3つともほぼ同じ（0.41〜0.47秒）で、違うのは素の計算コストのほうでした。
16GBならどの量子化を選ぶか
この機で全部GPUに載った最大の段はQ4_K_Mでした。ひとつ上のQ5_K_Sは実際に読み込ませたところ268 MiBあふれました。
| 量子化 | ファイル | 16GBでの挙動 |
|---|---|---|
| Q4_K_M | 12.3 GiB | 全部載る（実測・余裕 約730 MiB） |
| Q5_K_S | 13.3 GiB | 約268 MiBあふれる（実測） |
| Q5_K_M | 14.0 GiB | 約937 MiBあふれる（実測） |
| Q6_K | 15.7 GiB | 約2,684 MiBあふれる（実測） |
同一シードで画像を比べると、構図・配色は同じで、襟やフリルの形など細部が変わりました。どちらが良いかは主観なので判定しませんが、速度差は1.6倍あります。
自分の環境で測る手順
デスクトップ版は user/comfyui_8000.log。MB offloaded が出ていればあふれ、full load: True なら全部載っています。
設定ファイルの Comfy.Server.LaunchArgs に {"reserve-vram": "2.0"} と書くと --reserve-vram 2.0 として渡ります（この設定にGUIはありません）。反映は /system_stats の argv で確認します。再起動しただけでは変わっていないことがあります。
ダイナミックVRAMを切ると止まることがあります
--disable-dynamic-vram を付けて起動したところ、この機ではいちばん軽い6Bモデルの読み込み段階で応答しなくなり、33分待っても進みませんでした。OOMエラーは出ず、静かに固まります。1台での1回の観察なので「必ず止まる」とは言えませんが、切る理由は見つかりませんでした。
まとめ
VRAM不足は「動くか動かないか」ではなくいくら払うかの問題でした。あふれた1,000 MiBにつき1ステップ0.42〜0.60秒。16GBで20B級ならQ4_K_Mが実用点で、それ以上はVRAMを増やすかGPUを借りるかの二択です。判断材料はBTOの選び方とクラウドGPUの使い分けにまとめています。
VRAMが足りないとエラーになりますか？
量子化を上げると生成は遅くなりますか？
VRAM 16GBで20B級の画像モデルはどこまで載りますか？
--lowvram を付ければ改善しますか？
--lowvram は無視されます。より適応的な方策が既に働いているためです。あふれ量を調整したい場合は --reserve-vram を使い、反映されたかを /system_stats の argv で確認してください。
コメント