ComfyUI デュアルGPU運用ガイド｜RTX 5080+RTX 4070 Superで検証した並列処理と限界

RTX 5080で画像生成を回しながら、裏でもう1枚のGPUに別の生成タスクを投げたい。ComfyUIを日常的に使っていると、そんな場面に出くわすことがある。筆者の環境ではメインPCにRTX 5080（16GB）、MINISFORUM DEG1経由のOculink接続でRTX 4070 Super（12GB）を増設し、デュアルGPU構成で運用している。ComfyUIのデュアルGPU運用は「できること」と「できないこと」の差が極端に大きい。この記事では実測データをもとに、何が実用的で何が不可能なのかを整理する。

ポート分離方式の並列処理 ― 最も実用的なデュアルGPU運用

デュアルGPU環境でComfyUIを使うなら、最初に検討すべきはポート分離方式だ。やることは単純で、GPU1台につきComfyUIのインスタンスを1つずつ起動し、それぞれ別のポートを割り当てる。メインGPUはポート8188、サブGPUはポート8189、のように分けるだけ。ブラウザで2つのタブを開けば、それぞれ独立した生成環境として動作する。

起動時の設定ポイント

メインGPU（RTX 5080）側の起動オプションで押さえるべき点は、–port 8188 –cuda-device 1 –normalvram –reserve-vram 1.5 –bf16-unet –bf16-text-enc あたり。サブGPU（RTX 4070 Super）側は set CUDA_VISIBLE_DEVICES=0 の環境変数に加え、–port 8189 –cuda-device 0 –bf16-unet –bf16-text-enc –normalvram を指定する。

起動オプションの詳細仕様は ComfyUI 公式リポジトリ の main.py の引数定義から確認できる。–bf16-unet と –bf16-text-enc は重みの精度を BF16 に落としつつ Tensor Core を活用する設定で、Ampere 以降のアーキテクチャ（RTX 30/40/50 系）で安定動作する。Tensor Core での BF16 サポート範囲は NVIDIA Mixed Precision Training ドキュメント に整理されている。

CUDA_VISIBLE_DEVICES と –cuda-device の番号対応

CUDA_VISIBLE_DEVICES 環境変数は、CUDA ランタイムから「見える」GPUを絞り込む仕組み。set CUDA_VISIBLE_DEVICES=0 を指定したプロセスからは、物理 GPU の 1 番目だけが見え、ComfyUI の –cuda-device 0 はその「見えている GPU のインデックス」を指す。物理デバイス番号と論理デバイス番号が分かれる点で混乱が起きやすい。

GPU の列挙順を制御するには CUDA_DEVICE_ORDER 環境変数を併用する。デフォルトでは FASTEST_FIRST（性能順）で列挙されるため、デュアルGPU構成だと意図せず順序が入れ替わる場合がある。PCI バス順に固定したい場合は CUDA_DEVICE_ORDER=PCI_BUS_ID を設定する。仕様の根拠は NVIDIA CUDA C++ Best Practices Guide に明記されている。

この方式の最大の利点は、メインGPUで作業中にサブGPUの生成処理が割り込まない点。速度差のあるGPU同士でも問題にならない。メモリ使用量が2インスタンス分になるのはデメリットだが、RAM 32GB以上の環境なら実用上の障害にはならないはず。

実測データ: 並列実行時の速度

当サイトの検証環境（i7-14700F / 96GB RAM）で、両GPUに同時に生成タスクを投入した結果が以下の通り。

押さえておきたいのは、並列実行時でも互いの速度に干渉している兆候がなかった点。PCIe x16とOculink（PCIe x4）で帯域が異なるものの、画像生成はGPU内のVRAMで完結する処理が大半であり、バス帯域の取り合いはほぼ発生しない。Oculink経由のRTX 4070 Superでも単体実行時と同等の速度が出ていた。

マルチGPUノードによる同時処理 ― 上級者向けの選択肢

ComfyUIには、複数GPUを単一ワークフロー内で活用するためのカスタムノードがいくつか公開されている。ただし、現状では「万能な高速化ツール」とは言い難い。

主要なカスタムノードの整理

ComfyUI-MultiGPUは、UNet・CLIP・VAEといったモデルの各コンポーネントを異なるGPUに割り当てるノード。処理自体は逐次実行だが、1枚のGPUにすべてを載せる必要がなくなるためVRAM節約になる。FLUX、LTX Videoにも対応済み。実装の詳細は ComfyUI-MultiGPU 公式リポジトリ を参照。

ComfyUI-Distributedは異なるアプローチで、同一ワークフローを複数GPUで並列実行する仕組み。異なるシードで同時に生成できるため、スループットが向上する。1枚あたりの速度は変わらないが、単位時間あたりの出力枚数が増える。

ComfyUI-ParallelAnythingはバッチを分割して各GPUに振り分けるノード。ただし各GPUにモデルのフルコピーが必要で、VRAM消費は2倍。同速度のGPU 2枚が前提の設計になっている。

筆者がポート分離方式を採用している理由もここにある。RTX 5080とRTX 4070 Superでは処理速度に約1.5倍の差があり、同時処理系のノードを使うと遅い方がボトルネックになってしまう。速度差の大きいGPU同士では、独立して動かす方が合理的だ。

VRAMは共有できない ― デュアルGPU最大の誤解

「RTX 5080の16GBとRTX 4070 Superの12GBを足して28GBとして使えないのか？」。デュアルGPU構成を検討する際、最も多い誤解がこれだろう。結論として、ComfyUIではVRAMの合算利用は不可能。NVIDIAのGPU VRAMは各カードに物理的に独立しており、複数GPU間でメモリ空間を統合する仕組みがコンシューマー向けカードには存在しない。

NVLink / SLI / NVSwitch の整理

NVLink は GPU 間の高帯域相互接続技術で、RTX 3090 がコンシューマー向け最後のサポート世代だった。RTX 40 シリーズ以降は NVIDIA GeForce RTX 40 シリーズ公式ページ でも NVLink の記載が消えており、廃止が確定している。データセンター向けの H100 / A100 では NVSwitch を介した統合メモリアドレッシングが可能で、複数 GPU 間で疑似的に単一メモリ空間を扱える設計になっているが、コンシューマー製品には降りてこない。

NVLink および NVSwitch はデータセンター GPU 向けに最適化された相互接続技術であり、複数 GPU 間で高帯域・低レイテンシのメモリアクセスを実現する。

かつてNVLinkという高帯域GPU間接続がコンシューマー向けにも提供されていた時期があった。RTX 3090がNVLinkをサポートした最後の世代で、RTX 40シリーズ以降は廃止。現在、統合メモリアドレッシングが使えるのはA100やH100といったデータセンター向けGPUのみ。「SLIでVRAM共有」という話も見かけるが、SLIはゲーム用のフレーム分割技術であり、VRAM共有とは無関係。帯域も2 GB/s（16 Gbps相当）で、AI演算には実用外だ。

筆者も実際にRTX 5080のVRAMオフロード先としてRTX 4070 Superを指定しようと試みたが、ComfyUIの仕組み上これは不可能だった。大規模モデルを動かしたいなら、そのモデルが収まるVRAMを持つ単一GPUを用意するしかない。

例外: OllamaならVRAMを「疑似共有」できる

ComfyUIではVRAM合算が不可能と書いたが、LLM推論ツールのOllamaはまったく事情が異なる。Ollamaはパイプライン並列（テンソル並列とは別の方式）でトランスフォーマーの各層を複数GPUに分散配置できる。データが層を順番に流れていく仕組みで、結果として16GB + 12GB ≒ 28GBのモデルをロードできてしまう。

パイプライン並列の利点は GPU 間通信を最小化できる点。テンソル並列（同じ層を複数 GPU で分担）と異なり、レイヤー間の中間活性化のみを次の GPU に転送するため、PCIe 帯域への依存が低い。Oculink (PCIe x4) のような低帯域接続でも実用範囲に収まる根拠は Ollama 公式 GPU ドキュメント の Multi-GPU 動作仕様で確認できる。

デュアルGPU時の実測ベンチマーク

当サイトの検証環境での計測結果を以下にまとめた。

Qwen3 8Bはもともと単体GPUに収まるサイズだが、デュアルGPUでは層の分散によりメモリ帯域が拡大し32%の速度向上。一方のGemma3 12Bはほぼ変化なしで、モデルサイズとGPU間の分散比率によって効果にばらつきがある。

最も劇的な差が出たのはQwen3 32B。RTX 5080単体だとVRAM 16GBに収まりきらず、CPUメモリへのオフロードが発生して5.69 tok/sまで落ち込む。それがデュアルGPUでは両カードのVRAMに分散されてオフロードが解消し、11.24 tok/sとほぼ倍速。「VRAMが足りなくてCPUに溢れるモデル」こそがデュアルGPUの恩恵を最も受けるケースだ。

ただし注意点もある。速度差のあるGPU間ではデータ転送がボトルネックになり得る。特にOculink（PCIe x4）接続の場合、プロンプト入力時のprefill処理でレイテンシが増加する傾向を確認している。トークン生成（eval）速度は良好でも、最初の応答までの待ち時間が長くなることがある。

デュアルGPUが向いているケースと向いていないケース

ここまでの検証結果を踏まえ、デュアルGPU構成の適性を整理する。

向いている用途

ポート分離で別タスクを同時実行する場合。メインGPUで作業しながらサブGPUで画像生成を回す、といった運用には最適。互いの処理に干渉しないため、速度差も問題にならない。

Ollamaなど LLM推論で大型モデルを動かす場合。単体GPUに収まらないモデルをCPUオフロードなしで動かせるのは大きなメリット。Qwen3 32Bの例で示した通り、CPUオフロード発生時との速度差は顕著だ。

同速度のGPU 2枚でスループットを倍にする場合。同じモデルのGPU 2枚なら、ComfyUI-DistributedやParallelAnythingでバッチの並列処理が有効に機能する。

向いていない用途

1枚の画像生成を高速化したい場合。単一のデノイジングステップをGPU間で分割する技術は現時点で存在しない。

VRAMを合算して大型モデルを載せたい場合。ComfyUIではGPU間のVRAM共有は不可能。SDXLやFluxでVRAMが足りないなら、より大容量のGPU 1枚に買い替えるのが正解だ。

速度差の大きいGPU同士で同時処理を狙う場合。マルチGPUノードを使った同時処理では、遅い方のGPUがボトルネックになる。RTX 5080 + RTX 4070 Superのような組み合わせでは、ポート分離で独立運用した方が総合的な効率は高い。

電力 / 電源構成の考慮

デュアルGPU 運用でしばしば見落とされるのが電源構成。RTX 5080 の TGP は 360W、RTX 4070 Super は 220W。CPU の i7-14700F も最大 219W を消費する仕様のため、瞬間的にはシステム全体で 800W 近い電力が走る場面が出てくる。

筆者の環境では Oculink 接続のサブGPU 用電源を別系統（独立 PSU）として完全分離している。eGPU ドックの MINISFORUM DEG1 が独立した ATX 電源を要求する構造のため、メイン PSU と Oculink 側 PSU の負荷が物理的に分かれており、片方の負荷変動がもう片方に伝播しない。デュアル PSU 構成は配線の手間こそ増えるが、長時間の生成タスクで PSU が温度上昇しても片側で吸収できるため、熱マージンに余裕が出る。単一 PSU で組む場合は両 GPU + CPU の合計に対して 1000W クラスの 80PLUS Platinum 以上が目安になる。

トラブルシュート FAQ

Q1: ComfyUI 起動時に「No CUDA device available」エラー

CUDA_VISIBLE_DEVICES の指定と –cuda-device の番号がずれている可能性が高い。CUDA_VISIBLE_DEVICES=0 を設定した状態で –cuda-device 1 と指定すると、見えている GPU は 1 枚（インデックス 0）なのに 1 番を要求するため失敗する。両方ともインデックス 0 で揃えるか、CUDA_VISIBLE_DEVICES 自体を外して物理番号で指定する。

Q2: 片方の GPU だけ生成速度が極端に遅い

PCIe レーンの帯域不足が原因のことが多い。M.2 経由の Oculink は PCIe x4 接続になるケースが大半で、PCIe x16 接続の GPU と比べてモデルロード時間が長くなる。生成中の s/it 自体は VRAM 内処理なので大差ないが、初回のモデル切り替え時に体感差が出る。NVIDIA 公式の CUDA 開発者向けドキュメント でも PCIe 帯域とホスト・デバイス転送の影響は議論されている。

Q3: ブラウザでサブ GPU 側のタブが応答しない

–port 8189 の指定漏れか、Windows ファイアウォールでブロックされている可能性。netstat -ano | findstr 8189 で LISTEN 状態を確認、見当たらなければ起動オプションを再確認する。サブGPU側のコマンドプロンプトに「To see the GUI go to: http://127.0.0.1:8189」の行が出ていれば正常に listen している。

Q4: Ollama でモデルを片方の GPU だけに固定したい

環境変数 OLLAMA_NUM_GPU や OLLAMA_GPU_LAYERS で配分を制御できる。Ollama のサーバ起動前に環境変数を設定するか、systemd 経由なら override.conf に記載する。詳細は Ollama FAQ に記載がある。Windows 環境では setx ではなく現在のシェルで set コマンドを使う方が即時反映されやすい。

Q5: 並列実行中にメインGPU側だけ突然落ちる

電源の単一 PSU 構成で容量不足の可能性がある。GPU-Z や HWiNFO64 で瞬間電力を測定し、PSU の定格に対して 80% 以下に収まっているかを確認する。常時 80% を超える運用は寿命を縮めるため、容量不足が疑われる場合は PSU 増設または上位モデルへの交換を検討する。デュアル PSU で系統分離するのも合理的な選択肢。

まとめ

ComfyUIのデュアルGPU運用は、「ポート分離で独立した2つの生成環境を手に入れる」のが最も現実的な活用法だ。VRAMの合算やステップの分割といった「夢の機能」は現状では実現していない。速度差のあるGPU同士なら、無理に同時処理を狙うより別々のタスクを投げる方が合理的。

一方でOllamaのようなLLM推論では話が違い、パイプライン並列でVRAMの疑似統合が可能。用途によってデュアルGPUの価値は大きく変わるため、「何をやりたいのか」を先に明確にしてから構成を検討すべきだ。大規模モデルを1枚のGPUに載せたいだけなら、2枚構成に投資するより大容量VRAM搭載の単一GPU購入を勧める。

筆者が使用しているeGPUドック（MINISFORUM DEG1）については別記事で詳しくレビューしている。Oculink接続の実測データや設置環境の写真も掲載しているので、外付けGPU環境に興味がある方は参照してほしい。MINISFORUM DEG1レビュー

当サイトはAmazonアソシエイト・プログラムの参加者です。Amazonのアソシエイトとして、当サイトは適格販売により収入を得ています。

生成層への組み込み

• 複数 GPU を AI 自動化の生成層で活かす全体像 → 量産型AI自動化の4層構造 ─ ストックフォト動画系で動かしている中身

本記事は AIハードウェア図鑑 編集部 が記載時点の情報をもとに執筆。製品アップデートや第三者ベンチマーク・価格・対応ランタイム等の変動で評価が変わる可能性がある。一定期間経過した内容は再検証を推奨する。

参考資料

• ComfyUI 公式リポジトリ: main.py 起動オプション仕様
• NVIDIA 公式: Mixed Precision Training (BF16 / Tensor Core サポート)
• NVIDIA 公式: CUDA C++ Best Practices Guide (CUDA_VISIBLE_DEVICES / CUDA_DEVICE_ORDER)
• NVIDIA 公式: NVLink / NVSwitch 技術ページ
• Ollama 公式: GPU / Multi-GPU 動作ドキュメント