ComfyUIの–disable-pinned-memoryは速くなるのか｜公式見解とVRAM 8GBでの実測

要約

「MiniMax H3は --disable-pinned-memory を付けると速くなる」という話を見かけて試したものの、僕の環境では改善が見られませんでした。調べたところ、ComfyUI公式の位置づけはむしろ逆で、pinned memoryは既定で有効な高速化機能でした。RTX 3070（VRAM 8GB）/ RAM 32GBの環境で、画像・動画・音楽の7ケースを、記録しただけで151回測った結果と、公式の見解、他の人の実測例を並べます。ピークメモリは最大42.9%減り、生成時間への影響はモデルによって向きが違い、実行時間のばらつきは大きく縮みました。

はじめに

きっかけはXで見かけた「MiniMax H3は --disable-pinned-memory を付けると速くなる」という話でした。H3はVRAM 8GBで回すにはかなり重いモデルなので、起動オプション1つで速くなるなら試さない手はありません。

結論から書くと、僕の環境ではそこまでの改善は見られませんでした。 4パターンで測って、速くなったのは最小構成のときだけ、それも4.3%です。

ただ、試している最中にタスクマネージャーを見て、メモリの使われ方が条件によってまるで違うことに気づきました。オプションを付けずに生成しているときはこうなっています。

32GBのうち29.6GBが使用中で、利用可能は2.3GB。コミット済みは42.5GBで、物理RAMの32GBを超えています。オプションを付けると、同じワークフローでもここが13.9GB / 18.0GBになりました。

速度が変わらないのにメモリの使われ方だけこれだけ違うなら、何が起きているのか知りたくなります。というわけで測りました。記録しただけで151回になりました。

ComfyUIがメモリを使いすぎているように見える理由

ComfyUIは起動時に pinned memory（ページロックされたホストメモリ） を確保します。これはCPU側のメモリのうち、OSがディスクに追い出せないよう固定した領域のことです。

GPUはこの固定された領域からのほうが速くデータを読めます。ページアウトされる可能性がないぶん、CPUを介さずDMAで直接引っ張れるからです。VRAMに載りきらないモデルを何度もGPUに送り込む場面では、この差が効いてきます。つまりpinned memoryは高速化のための仕組みで、既定で有効になっています。

無駄に抱え込んでいるわけではなくて、VRAMに載りきらないモデルを扱うための正攻法です。メモリを使いすぎているように見えるのは、その先払いのぶんが乗っているからですね。

確保量はComfyUIのソースで決まっています。NVIDIAまたはAMDのGPUがある環境で、Windowsの場合は物理RAMの40%です。僕の環境は32GBなので、32GB × 0.40 = 12.76GB。起動時のログにも同じ数字が出ていました。

[INFO] Enabled pinned memory 13064.0

13064MBを1024で割ると12.76GB。計算どおりです。

公式はこのオプションをどう位置づけているか

測る前に、公式の説明を確認しておきます。

Comfy Orgのブログによると、pinned memoryとasync offloadを有効にすると サンプリング速度が無効時と比べて10〜50%向上するとのことです。ただし条件があって、モデルの重みがVRAMに収まりきらない場合に効くもので、収まるなら意味のある改善はしないと明記されています。

そして重要な但し書きがあります。性能向上はPCIeの世代とレーン数に直接相関する。公式のベンチマークはPCIe 4.0 x16で取られていて、4.0 x8では明確に劣るとも書かれています。

公式ドキュメントの推奨はシンプルです。

Only disable if you experience crashes or memory issues.
（クラッシュやメモリの問題が出たときだけ無効化してください）

つまり --disable-pinned-memory は、速くするためのオプションではなく、困ったときの逃げ道という位置づけです。試す前の僕の理解は逆でした。

測定した環境と条件

ここからが実測です。あくまで下の1環境での結果なので、そのつもりで読んでください。

PCIeを太字にしたのは、公式が「効果はPCIeの帯域に相関する」と書いているからです。この環境は公式ベンチ（PCIe 4.0 x16）の半分の帯域にあたります。ここが結果に効いている可能性は最後まで残ります。

まず比べたのはこの2条件です。違いは --disable-pinned-memory の有無だけにして、他のオプションは変えていません。

このあと関連するオプションを見つけたので、記事の後半では --fast-disk を加えた3条件で測り直しています。

ワークフローは7種類。VRAMに収まる軽いものから、RAMに大量にあふれるものまで並べました。

セットごとにComfyUIを再起動して30秒待ち、1回目をコールド、2回目以降をウォームとして分けて記録しています。測定中は他のアプリを閉じて、PCには触っていません。

メモリ使用量はどれくらい変わるのか

ピーク時のコミット済みメモリ、ウォームの中央値です。

7ケース全部で下がりました。 下がり幅は、モデルの重みをどれだけRAMに置くかとおおむね対応しています。

実感に近いのは空きメモリのほうです。

動画系では空きが2GBを切ります。無効化した状態で同じワークフローを回すとこうなります。

使用中が29.6GB（93%）から13.9GB（44%）に、利用可能が2.3GBから18.0GBになりました。GPU使用率はどちらも8割を超えていて、生成そのものは動いています。

Wan2.2で3回続けて生成したときの推移も出しておきます。同じワークフローを同じ順で回しているので波形の形は一致していて、違うのは高さだけです。

なお、コミット済みが42GBに達してもページファイルの使用率は3%止まりでした。確保はしてあるけれど実際には書き出していない、ということのようです。

生成時間はモデルによって向きが違う

pinned memoryを切ると何%変わるかで読んでください。プラスが「切ると遅い」、マイナスが「切ると速い」です。

差が無いケース、遅くなるケース、速くなるケースが混在しました。

目についたのは、モデルの積み替え回数が多いケースほど既定のほうが速いという並びです。積み替え回数は、ComfyUIのログに出る Requested to load の回数を数えたものです。ACE-Step 1.5XLは7回で最多、差も最大の+65.5%。SDXL素は3回で、差はほぼゼロ。

pinned memoryが「CPU→GPU転送を速くするもの」である以上、転送が頻繁なワークフローほど得をする、という筋は通ります。公式が言う「10〜50%」とも同じ向きで、僕の環境ではACE-Stepがそれを超えました。

そして、この表で1つだけ逆を向いているのがMiniMax H3でした。

MiniMax H3で「切ると速い」を確かめた

冒頭で書いたきっかけがこれです。上の測定でも実際にその向きに出ました。ただ、このときのウォームは1条件あたり2サンプルしかありません。効果量が10%程度のものを2サンプルで判断するのは危ういので、H3だけ切り出して測り直しました。

基準の構成から変数を1つずつ動かしています。各条件6回（コールド1回 + ウォーム5回）、合計48回です。

4パターン中3つで、切ると遅くなりました。 速くなったのは最小構成のときだけで、それも−4.3%です。前の測定で出た−10.0%は再現しませんでした。

原因は測定側にありました。既定の条件はもともとばらつきが大きく、2サンプルのうち1本がたまたま遅い側（40.2秒）を引いていたためです。同じ設定を5サンプルで測り直すと−4.3%に縮みました。

「切ると速くなる」という話はどこから来たのか

自分の環境で再現しないからといって、元の話が間違いとは限りません。調べてみると、説明のつく話がいくつか出てきました。

バージョン固有の不具合だった可能性があります。 MiniMax H3の解説記事に、ComfyUI 0.30.x系にpinned memoryのリグレッションがあり、モデルの読み込みが極端に遅くなる。--disable-pinned-memory を付けると読み込みの速さが戻るという記述がありました。僕が測ったのは 0.32.0 です。リグレッションが直ったあとのバージョンなら、再現しなくても不思議はありません。

PCIeの帯域で効果量が変わります。 前述のとおり公式は「性能向上はPCIeの世代とレーン数に直接相関する」としています。僕の環境はPCIe 3.0 x16で、公式ベンチのPCIe 4.0 x16の半分です。pinned memoryの恩恵が小さければ、切ったときの損失も小さく出ます。逆に帯域が太い環境なら、切ったときの落ち込みはもっと大きいはずです。

pinned memoryが効いたという実測報告もあります。 GitHubのissueには、RTX 5060 Ti 16GB / RAM 64GB / PCIe Gen3 x8の環境で、Wan2.2のI2Vワークフローが約19分から16分程度に短縮された（約16%）という報告がありました。pinned memoryを有効にした側が速い、という向きです。

つまり 「切ると速くなる」も「切ると遅くなる」も、条件次第でどちらも起こりうるというのが今の理解です。僕の環境では後者でしたが、これを一般化するつもりはありません。

いちばん変わったのは生成時間のばらつき

速度の中央値より、こちらのほうが大きな差でした。ウォーム5回の最小値から最大値までを帯で、中央値を縦線で示しています。

既定は6.4〜27.6%、無効化は0.9〜1.5%。一桁違います。

同時に押さえておきたいのは、既定の最速値はどのパターンでも無効化の最速値より速いという点です。12ステップのパターンなら65.41秒対73.28秒で、8秒近い差があります。高速化そのものは効いていて、ただ毎回それが出るわけではない、ということですね。

ばらつきの理由を探してメモリ側を見ると、既定では4パターンすべてで空きメモリが2.0GBちょうどに張り付いていました。 解像度もフレーム数もステップ数も変えているのに、行き着く先は同じです。常にOSがメモリを回収する縁で走っているので揺れているのではないか、と考えていますが、因果までは確かめていません。

生成中に他のソフトを使えるかも測った

メモリが18GB戻るなら、生成中に他のことができるはずです。そこも測りました。

Brave（YouTubeライブ配信）/ VSCode（4ディレクトリのワークスペース）/ Discord / Chrome（スプレッドシート2タブ）/ デュアルディスプレイ。全部起動したまま操作せずに放置し、別ウィンドウで1080p60の動画を再生して、そのフレームレートを測っています。

差は出ませんでした。 既定はコミット済みが約50GB、空きRAMが0.92GBまで落ちていますが、それでも1080p60は破綻していません。

一方で、生成時間のほうは影響を受けました。

他アプリなしでは既定が速かったのに、実アプリを開くと差がほぼ消えます。ただし各条件6サンプルで、無効化側に45.4秒という外れ値が1本あります。傾向として見るくらいがちょうどいい数字です。

メモリが足りなくても生成結果は変わらない

「メモリが足りないと出力がおかしくなるのでは」と気になったので、そこも確かめました。

同じワークフロー・同じシードで、メモリの圧迫具合だけを変えて生成し、出力ファイルのSHA256を突き合わせます。シードを固定すると実行キャッシュに当たるので、1回ごとにComfyUIを再起動しました。

11回すべて、1ビットも違いませんでした。 空きメモリを2.77GBまで追い込むと生成時間は32.4秒から46.7秒（+44%）まで伸びますが、出てくる画像は同一です。

メモリが足りないと遅くなるだけで、結果は変わりません。 裏で重い作業をしていて生成物がおかしく見えたときは、別の原因を探したほうがよさそうです。

--fast-disk という別のオプション

調べている途中で、関連しそうなオプションを見つけました。

--fast-disk   Prefer disk-backed dynamic loading and offload over unpinned RAM.
              Can be faster for users with fast NVME disks.

何をするオプションか

ソースを追うと、ディスクから読み直せる重みについて、RAMにピン留めしたコピーを持たず、モデルファイルから直接読むものでした。

ComfyUIは重みごとに「元のファイルから読み直せるか」を判定しています。既定ではその判定が付いた重みでもRAM側にピン留めしたコピーを作って、次回以降はそこからGPUへ送ります。--fast-disk を付けるとこのコピーを作りません。

# comfy/ops.py
if signature is None or not args.fast_disk or args.high_ram:
    comfy.pinned_memory.pin_memory(m, subset=subset, size=size)

ピン留めの予算管理も変わります。既定は「実際の空きRAM」を見て足りなければピンを追い出しますが、--fast-disk は「固定の上限値」だけを見ます。空きRAMを気にしないのは、足りなければディスクから読めばいいという前提だからですね。

3ケースで測った結果

MiniMax H3・Wan2.2 14B・ACE-Step 1.5XLの3つを、同一ベースラインで3条件ずつ測りました。

3ケース中2つで最速、1つで既定より遅くなりました。 ACE-Stepが−19.8%、MiniMax H3が−12.6%、一方でWan2.2は+10.1%です。モデルによって向きが変わります。

最初はMiniMax H3だけで測っていて、そのときは「速くなるオプション」と書きかけました。Wan2.2を足して逆転を見つけたので、1ケースで判断しなくてよかったです。

メモリの余裕は3段階にきれいに並びます。既定（2〜4GB）＜ --fast-disk（5.8〜14.2GB）＜ --disable-pinned-memory（18〜21GB）。--fast-disk は速度とメモリの中間を取る選択肢になっています。

タスクマネージャーで見るとこうです。同じMiniMax H3の生成中で、--fast-disk を付けた状態です。

冒頭の既定（利用可能2.3GB）と、無効化したとき（18.0GB）のちょうど間にあります。ディスク0（NVMe）が34%動いているのも、重みをファイルから読んでいるこのオプションらしいところです。

なぜ向きが変わるのか（推測）

この環境はピン留めの上限が12.76GBなのに対して、ACE-Stepは54.6GB、MiniMax H3は約40GBの重みを扱います。上限に収まらないので、ピン留めと追い出しが繰り返されるはずです。--fast-disk はその出入りをやめてNVMeから読むぶん、往復の管理コストが消えます。

Wan2.2で遅くなったのは、重みが13.6GBとピン上限に近く、追い出しの往復がそれほど起きていないからかもしれません。だとするとディスク読み込みが純粋な上乗せになります。いずれも未検証です。

どちらを使うか

測った範囲でのまとめです。VRAM 8GB / RAM 32GB / PCIe 3.0という条件での話になります。

1本でも速く回したいなら、まず既定のまま。 公式が言うとおり、pinned memoryは高速化のための機能です。--disable-pinned-memory は3ケースとも既定以上に速くはならず、ACE-Step 1.5XLでは+72.8%まで遅くなりました。

NVMeにモデルを置いているなら、--fast-disk を比べてみる価値はあります。 3ケース中2つで既定より速く、ACE-Stepは−19.8%でした。ただしWan2.2では+10.1%と逆に遅くなっているので、自分が普段使うモデルで測ってみるのが確実です。

裏で他の作業もしたいなら、--disable-pinned-memory で空きメモリが2GBから18GB台に戻ります。 今回の測定では動画再生に差が出ませんでしたが、それはこの負荷では現れなかったというだけです。ただし裏で作業をすると生成時間のほうが1〜2割伸びるので、急いでいるときは生成に専念したほうが速いです。

生成時間を見積もりたいなら、フラグを付けたほうが読めます。 既定の実行時間の幅は最大49.0%（Wan2.2）でしたが、--disable-pinned-memory では0.9〜3.0%に収まりました。何本もまとめて回すときは、少し遅くても一定であることのほうが役に立ちます。

なお、これはあくまで1環境での結果です。手元の環境の余裕がどのくらいかはAI画像生成のPC環境ガイドに、ローカルで足りないと感じたときの比較はConoHa AI CanvasでのComfyUI速度比較にまとめてあります。

測定でつまずいたところ

同じことを試す人がいるかもしれないので、引っかかった点も残しておきます。

同じプロンプトを投げるとComfyUIは実行キャッシュを返します。 最初の測定では、各セットの2回目以降が Prompt executed in 0.00 seconds で終わっていました。ウォームを測ったつもりでキャッシュヒットを測っていたわけです。反復ごとにシードを変えて、その並びを両条件で共通にする形に直しました。シードを固定したい場合は、1回ごとにComfyUIを再起動するしかありません。

リンク接続されたシードはウィジェットの値が無視されます。 ACE-Stepのワークフローは seed が PrimitiveInt ノードからのリンク接続になっていて、シードを書き換えたつもりで効いていませんでした。

ComfyUI 0.32.0は loaded partially を出しません。 オフロード量の目印として数えるつもりでいたのですが、代わりに出るのは Model WAN21 prepared for dynamic VRAM loading. 13628MB Staged. の形式でした。

よくある質問

まとめ

「MiniMax H3が速くなる」と聞いて試したオプションでしたが、僕の環境ではその話を再現できませんでした。

• 公式の位置づけは高速化機能。pinned memoryとasync offloadで無効時比10〜50%、ただしVRAMに収まらないモデルの場合のみ、効果量はPCIeの帯域に相関する
• 僕の環境（PCIe 3.0 x16 / ComfyUI 0.32.0）では、切っても速くならなかった。3モデルで測り直して+3.1%〜+72.8%
• 「切ると速い」という話は、0.30.x系のリグレッション下で報告されていたものらしい。バージョンが違えば結果も変わる
• ピークメモリは全7ケースで減少（−11.6%〜−42.9%）、空きメモリは2.0GBから18GB台に回復
• 実行時間のばらつきは最大49.0%から0.9〜3.0%に縮小
• --fast-disk は3モデル中2つで既定より速く、1つで遅かった。ACE-Step −19.8% / MiniMax H3 −12.6% / Wan2.2 +10.1%
• メモリが足りなくても生成結果は変わらない。11回すべてハッシュ一致
• 151回の測定でOOMは一度も起きなかった

「速くなる裏技」ではなく、速度とメモリの余裕を交換するオプションという理解が近いと思います。pinned memoryが悪さをしているわけではなく、VRAMに載りきらないモデルを扱うための正攻法です。VRAMやRAMに余裕がある環境なら、既定のまま使えばいいはずです。

ただ、VRAM 8GB / RAM 32GBという環境では、その先払いのぶんが「他のソフトを動かす余地」をちょうど食っていました。そこを交換するかどうかは、その日の使い方で決めればいいと思います。