Cドライブが満杯でComfyUIのモデルを外付けHDDに逃がしたら、生成が12倍遅くなった話

この記事には広告(アフィリエイトリンク)が含まれます。リンク経由で購入されると当社に収益が入りますが、紹介しているのは実際に使ったもの、または記事中の条件を満たすものだけです。効果の断定はせず、合わなかった点も書いています。

ある日、Cドライブの空きがなくなりました。

AIのモデルというのは、放っておくと際限なく増えます。数えたら、モデルだけで187ファイル、364GB。当然PC全体が重くなって、まともに作業できません。

なので、外付けドライブに逃がしました。この判断自体は、今でも正しかったと思っています。

そこから、生成が始まるまでの待ち時間が、やたら長くなりました。

おかしい。VRAMを節約するためにGGUFへ量子化した、軽いモデルを使っているのに。「量子化したせいで、展開処理が重くなっているんだろうか」——しばらく、そう考えていました。

測ってみたら、まったく違いました。

GGUFは無関係でした。モデルを置いたドライブが、単に遅かっただけです。

同じ手法で手元の4台を実測したところ、読み込み速度に12.3倍の差がありました。7.7GBのモデル1本を読む時間に直すと、62秒と5秒です。

先に結論

症状:軽くしたのに、立ち上がりが遅い

筆者の環境では、VRAM 12GB(RTX 4070)でComfyUIを回すために、FluxやWANのモデルをGGUFに量子化して使っています。

GGUF自体の効果には満足していて、通常版と比べて出力品質の差はほとんど感じません。VRAMが足りない環境では第一選択だと思っています。

ところが、生成が始まるまでが妙に長い。軽量モデルのはずなのに、体感でかなり待たされる。「量子化したせいで展開処理が重いのだろうか」と考えていました。

結論から言うと、それは見当違いでした。

なぜGGUFのせいではないのか

量子化が削るのは、モデルをVRAMに載せたときの占有量です。ファイルそのものは、当然ながらディスク上に実体として存在します。

そしてディスクから読み込む時間は、量子化とは何の関係もありません。7.7GBのファイルは、どんな形式であれ7.7GB読む必要があります。

つまり、こうです。

この2つは別の話です。VRAMが足りない問題を解決しても、読み込みが遅い問題は1ミリも解決しません。

実測:同じ方法で4台のドライブを測った

手元の4台のドライブで、2GBの連続読み込みにかかった時間を測りました。条件を揃えるため、すべて同じスクリプト・同じバッファサイズ(16MB)です。

ドライブ 接続 実測速度 7.7GBのモデル1本
BUFFALO HD-NRLD(HDD) USB 129 MB/s 約62秒
Kingston XS1000(SSD) USB 915 MB/s 約9秒
SUNEAST SEPS0002T(SSD) USB 1,434 MB/s 約6秒
INTEL SSDPEKNU010TZ(SSD) NVMe(内蔵) 1,586 MB/s 約5秒

外付けHDDと内蔵NVMeで12.3倍。時間にして57秒の差です。

そして重要なのは、ComfyUIはワークフローの中でモデルを切り替えるたびに読み直すという点です。1回の生成で完結する話ではありません。プロンプトを変え、モデルを変え、試行錯誤しているあいだ、切り替えのたびに1分待たされる計算になります。

1日に30回モデルを切り替えれば、それだけで30分です。

なお、上の表でUSB接続のSSDが915〜1,434MB/s出ている点にも注目してください。「外付けだから遅い」のではありません。HDDだから遅いのです。

自分の環境を測る方法

まず「そもそも自分のモデルがどこに置かれていて、そのドライブは速いのか」を確認してください。以下はWindowsのPowerShellで動きます。

1. そのドライブがHDDかSSDかを見る

Get-PhysicalDisk | Select-Object FriendlyName, MediaType, BusType, @{n='SizeGB';e={[math]::Round($_.Size/1GB)}}

MediaType が HDD と出たら、そこにモデルを置いている限り待ち時間は避けられません。

ただし、USB接続の外付けドライブは Unspecified としか表示されないことがあります。筆者の環境でも、実際にはHDDなのに Unspecified でした。判別できない場合は、次の実測に進んでください。

2. 実際の読み込み速度を測る

$p に、実際に置いてあるモデルファイルのパスを入れて実行します。2GB読み込んで速度を出します。

$p = "D:\ComfyUI_models\unet\flux1-dev-Q5_K_S.gguf"   # ← 自分のモデルのパスに変える

$sw = [Diagnostics.Stopwatch]::StartNew()
$fs = [IO.File]::Open($p,'Open','Read','Read')
$buf = New-Object byte[] (16MB); $total = 0
while($total -lt 2GB){ $r = $fs.Read($buf,0,$buf.Length); if($r -eq 0){break}; $total += $r }
$fs.Close(); $sw.Stop()

$mb = $total/1MB; $sec = $sw.Elapsed.TotalSeconds
"{0:N0} MB/s" -f ($mb/$sec)

目安

3. シンボリックリンクで別ドライブを参照していないか確認する

ComfyUIの models フォルダを、シンボリックリンクやジャンクションで別ドライブに逃がしている場合、エクスプローラ上はCドライブにあるように見えます。実体がどこにあるかは、こう確認できます。

Get-Item "C:\AI\ComfyUI\models" | Select-Object LinkType, Target

Target に別ドライブが出たら、そこが本当の置き場所です。

なぜこうなったか:容量のために速度を犠牲にしていた

筆者の場合、経緯はこうでした。

  1. もともとモデルはCドライブ(内蔵NVMe)に置いていた — このときは速かった
  2. Cドライブが満杯になり、PC全体が重くなった
  3. 対処として、モデル一式を外付けHDDへ移した(ジャンクションで参照)
  4. 結果、生成の立ち上がりが激遅になった

ここで強調したいのは、②から③の判断自体は正しいということです。Cドライブが満杯のままではPC全体が重くなりますし、AIモデルは放っておくと際限なく増えます。筆者の環境では、モデルだけで187ファイル・364GBあります。逃がすという判断は間違っていません。

問題は、逃がす先をHDDにしたことだけでした。

「容量を確保する」という目的は達成できていたので、速度を犠牲にしていることに気づかないまま使い続けていたわけです。そして遅さの原因を、まったく関係のないGGUFに帰属させていました。

では、どこに置くべきか

理想は内蔵NVMeですが、モデルは平気で数百GBになるので、内蔵に全部置くのは現実的ではありません。実際に選ぶなら、優先順位はこうなります。

  1. 内蔵NVMeの空きに、今使っているモデルだけ置く(最速。ただし容量との相談)
  2. 外付けSSDに全部置く(実測915〜1,434MB/s。HDDの7〜11倍で、実用上ほぼ困らない)
  3. 外付けHDDは「保管庫」として使う(今使っていないモデルの置き場としては十分。容量単価は圧倒的に安い)

全部を1箇所に置く必要はありません。 よく使うモデルだけSSD側に置き、たまにしか使わないものはHDDに残す。これがいちばん費用対効果が高い構成です。

ストレージを選ぶとき、AIモデル用途では容量単価よりも読み込み速度を見てください。動画や写真の保管なら容量単価が正義ですが、モデルは「毎回読み込むファイル」なので、速度がそのまま待ち時間になります。

混同しやすい「VRAM不足」との切り分け

最後に、よくある混同を整理しておきます。ComfyUIが快適に動かない原因には、まったく別の壁が2つあります。

ディスクが遅い(この記事) VRAMが足りない
症状 生成が始まるまでが長い 生成中にエラーで落ちる/そもそもロードできない
待たされる場所 モデル読み込み中 生成処理中
対処 速いドライブに置く モデルを小さくする(14B→5B・量子化)
GPUを買えば解決するか しない する

「生成が始まるまでが長い」ならディスク、「生成中に落ちる」ならVRAMです。前者にGPUを買っても、1秒も速くなりません。

まとめ

GPUを買い替える前に、確認する価値のある場所です。