SERIES — 計算資源 #17

巨大LLMは1台で動かすべきか? 複数GPU・複数PCの分散推論を考える

公開: 2026.10.20 | 更新: 2026.10.20 広告・PR

1つの巨大LLMを複数GPU・複数PCへ分割する「分散推論」と、制作PCとAI PCで役割を分ける「2台分業」はどう違うのか。並列化の仕組み・通信の壁・2026年時点の実装環境から、選ぶべき構成の順序を整理します。

同一PC内の複数GPU構成と、複数PCをネットワーク接続した分散推論・通信制約の概念図
※画像はイメージです。実際の製品・ネットワーク構成とは異なる場合があります。
計算資源シリーズ(第17回)

スペック表の数値比較にとどまらず、「計算資源をどう持ち、何に使い、どのような価値へ変換するか」を用途から考えるシリーズです。前回の第16回(MoEとGPU・大容量RAMの役割分担)に続き、第17回では「1つの巨大LLMを複数GPU・複数PCへ分割する分散推論」と「2台分業」の違い、通信の壁、現実的な導入順序を整理します。

計算資源シリーズ一覧を見る →
CONCLUSION FIRST|30秒で分かる結論 分散推論とPC構成の判断順序

まず結論|大きなモデルを動かすためだけに、PCを増やす必要はない

大規模なローカルLLMを動かそうとすると、最初に壁になるのがメモリ容量だ。RTX 5090には32GBのVRAMがあるが、もっと大きなモデルでは1枚に収まらないことがある。そこで浮かぶのが「GPUを2枚使えばいいのではないか」「別のPCのメモリも使えないか」という疑問だ。

技術的には、1つのモデルを複数GPUや複数PCへ分割して推論する方法がある。しかし、使えるメモリが増えることと、生成速度が速くなることは同じではない。 分散するほど、計算結果をやり取りする通信と同期が必要になるためだ。

結論を先に整理すると、次のようになる。

状況 まず検討したい構成 主な理由
希望モデルが1枚のGPUに収まる GPU 1枚 分散通信が不要で、構成が単純
VRAMは不足するが、RAMが十分にある GPU+システムRAM 追加GPUの前にCPUオフロード等を検証できる
複数GPUで1台の筐体に収められる 同一PC内の複数GPU ネットワーク越しの分散を避けやすい
1台ではどうしてもモデルを保持できない 複数PCによる分散推論 通信とソフトウェアの対応を条件に検討
制作とLLMを並行させたい RTX機+大容量メモリPCの2台分業 異なる仕事を独立して実行できる

ここでいう「分散推論」と、CORE SPECが紹介してきた「2台分業」は、最初に区別しておきたい。

1. 「1つのモデルの分散」と「2台で仕事を分ける」は違う

例えば、AのPCでTouchDesignerやComfyUIを動かし、BのPCでローカルLLMを実行する場合を考えよう。2台はネットワーク越しにAPIで連携してもよいが、それぞれが別の仕事を担当している。これはワークフローの分業だ。

一方、ひとつの巨大LLMの重みやレイヤーをPC AとPC Bに分け、1回の回答生成のために両者が協調するのがモデルの分散推論だ。

比較 2台分業 分散推論
処理する仕事 別々の処理 1つのモデルの同じ推論処理
PC間で主にやり取りするもの プロンプト、結果、APIリクエスト 中間表現、同期に必要なデータなど
ネットワークへの依存 API通信の量・頻度次第 モデル分割方式に強く依存
導入目的 制作・推論の負荷分離 1台に収まらないモデルの実行、条件次第で性能拡張
故障・停止の影響 担当タスクに影響 ひとつの推論全体が止まる場合がある
ARCHITECTURE DISTINCTION 混同しやすい3つのマルチ構成の整理
方式 A|同一PCの複数GPU
1台の筐体内でモデルを分割

PCIeやGPU間接続を使い、同一マザーボード上の複数GPUで1つのモデル(または複数リクエスト)を処理する。

方式 B|複数PCの分散推論
ネットワーク越しに1モデルを分割

複数台のPCへ重みやレイヤーを分け、1回の回答生成のためにネットワーク経由で中間データや同期通信をやり取りする。

方式 C|2台ワークフロー分業
PCごとに異なる仕事を独立実行

制作アプリ(PC A)とローカルLLMサーバー(PC B)など別の役割を割り当て、APIリクエストと応答だけをやり取りする。

ネットワーク接続した2台のRAM容量やVRAM容量が、設定不要でひとつの高速メモリになるわけではない。「GPUが2枚あるから必ず2倍速い」ということもない。

2. 分散推論には何種類あるのか

Tensor Parallel(テンソル並列)は、ひとつの層の重みや計算を複数GPUで分担する考え方だ。層の処理中にも各GPUの計算結果を集める必要があり、通信と同期を頻繁に行う。高速なGPU間接続がある環境で効果を発揮しやすい。

Pipeline Parallel(パイプライン並列)は、モデルの層を前半・後半といった段階に分ける方法だ。GPU Aが前半、GPU Bが後半を担当する。層の境界でデータを渡す必要があり、1人が短い応答を生成するような条件ではGPU間の待ち時間が目立つこともある。一方、複数リクエストを流す場合は各段を稼働させやすくなる。

Data Parallel(データ並列)は、同じモデルの複製を複数GPUへ置き、別々のリクエストを処理する方法だ。1つのモデルをメモリ不足から救う方式ではなく、同時利用者や総処理件数を増やす目的に向く。

Expert Parallel(Expert並列)は、MoEのExpertを複数デバイスに分けて配置する方式だ。トークンを必要なExpertへ振り分けるため、デバイス間の送受信が発生する。MoEの活性パラメータが小さいからといって、通信負荷が必ず小さいわけではない。

方式 何を分けるか 重要な制約 適する方向性
Tensor Parallel 層内部の計算・テンソル 頻繁な通信と同期 高速接続の複数GPU
Pipeline Parallel モデルの層・段階 段間転送、待ち時間 大きなモデルの段階分割
Data Parallel 独立リクエスト モデルの複製分のメモリ 同時利用・総処理量
Expert Parallel MoEのExpert トークン配送、Expert負荷の偏り MoEに対応した分散処理

これらは排他的ではない。実際の大規模環境では、複数の方式を組み合わせる場合がある。

3. なぜ10GbEの数字だけでは速度を予測できないのか

例えば10GbEの通信速度は理論上10Gbps。バイトに換算すれば最大1.25GB/s相当になる。ただし、これはプロトコルの負担などを差し引く前の数字だ。

一方、GPU内の専用メモリは桁違いの帯域でデータを供給する。分散推論ではGPU内の演算をすべてネットワークへ置き換えるわけではないが、モデルの分け方によっては、GPUが相手側の処理や転送を繰り返し待つ。

通信を理解する際は次の3点を見る必要がある。

POINT 01
帯域

一度にどれだけのデータを送れるか。大きなデータを動かす際に重要。

POINT 02
レイテンシ

送信してから相手へ届くまでの時間。小さな通信を何度も繰り返す構成では無視できない。

POINT 03
同期回数とプロトコル

Tensor Parallelでは層ごとに通信が必要になる場合があり、TCP/IPとRDMAのような方式の違い、GPU間のP2P通信可否などが影響する。

NVIDIAのNCCLは、複数GPU間のAllReduceやAllGatherなどを支える通信ライブラリだ。ただし、NCCLを導入しただけで任意のPC同士が高速な分散推論システムになるわけではない。GPU構成、相互接続、フレームワークの対応が必要になる。

「同じメモリ容量を確保できる」なら、通信と設定の負担が小さい構成を先に比較する。 これが個人ユーザーにとって重要な考え方だ。

4. 2026年の実装環境はどこまで使えるのか

分散推論は研究上の概念ではなく、実際のソフトウェアに実装されている。ただし、対応範囲と導入難易度には大きな差がある。

ソフトウェア 主な位置づけ 導入前に確認すること
vLLM 複数GPU・複数ノードの本格的なモデル配備 対応GPU・OS、TP/PP設定、Ray等、モデル対応
llama.cpp RPC 異なるマシンの計算資源を利用する実験的方式 公式がProof of Conceptと注意、信頼できる閉域環境のみ
MLX Distributed MLXでの分散処理。Apple Siliconを含む環境で利用 バックエンド、接続、対応モデルと分散実装
exo 複数端末を束ねる分散AIプロジェクト 版・サポート環境・対応機器・実装の成熟度

vLLMは、1台でモデルが収まるなら分散を避け、1台の複数GPUで収まるならTensor Parallel、多ノード環境ではTensor ParallelとPipeline Parallelを組み合わせる考え方を公式に案内している。

llama.cppのRPCも複数PCへ重みを配置する方式があるが、公式READMEでは実験段階であり、公開ネットワークや機密環境へRPCサーバーを置かないことが明記されている。ホームユーザーが気軽に標準機能として導入できると誤解させてはいけない。

MLX Distributedでは、TCPベースのRingや、対応環境でのThunderbolt/RDMA等の通信方式を利用できる。ただし、MLXが分散通信に対応することと、すべてのLLM・複数機器の組み合わせを簡単に運用できることは別だ。

exoのような選択肢も、プログラムの更新状況と対応環境を確認したうえで、研究・実験向けの位置づけから評価したい。

例外的に、2台接続を前提に設計された製品もある

例えばDGX Spark同士には、ConnectX-7を用いた接続と、対応構成のクラスタ設定を補助するNVIDIA Sync Cluster Assistantが用意されている。NVIDIA公式ガイドでは、対応するQSFPポートが最大200Gb/sであることや、複数台の接続・設定手順が説明されている。

これは、一般的なWindowsデスクトップ2台を10GbEで接続して分散推論するケースとは、前提となるハードウェアもサポートも異なる。もっとも、クラスタのネットワーク設定が容易になっても、使いたいモデルと推論フレームワークが分散処理に対応するか、十分な速度が出るかの検証は残る。

5. 複数GPUを導入する前に比較すべき4つの方法

① GPU 1枚のままモデルを小さくする

量子化や、必要な品質を満たすより小さいモデルへの変更でVRAM内に収まることがある。最も構成が簡潔で、追加機材が不要だ。ただし、回答品質や対応タスクに影響する場合がある。

② RTX+システムRAMを使う

CPUオフロードやMoEのExpert配置により、単一GPUのVRAMを超えるモデルを扱う方法だ。128GB・192GB・256GB RAMなどの価値は「保持できる容量」にあり、速度はCPU性能・RAM帯域・実装次第。設定を最適化する難易度も判断に含めたい。

③ 同一PCに複数GPUを搭載する

対応するソフトウェアなら、複数のVRAMを利用してモデルを分割できる。ただし、VRAMが無条件に1つの共有メモリとして合算されるわけではない。 PCケース、電源、冷却、PCIeレーン・スロット、GPU間接続、費用を考慮する。

④ 別のPCを追加する

この場合は、ひとつのモデルを分ける分散推論か、別の仕事を任せる2台分業かを最初に決めよう。RTX制作機と大容量メモリPCを分ける構成では、モデル全体を毎回PC間で通信する必要はない。日常運用では、役割が固定された2台分業の方が扱いやすいケースもある。

6. どんな人に分散推論は向くのか

向いている可能性がある人

単一機に収まらないモデルを使う必要があり、複数GPU・高速ネットワークを保有し、ランタイムの対応確認や性能測定に取り組める研究者・開発者。

最初からは勧めにくい人

ローカルLLMを日常的に使いたい初心者、制作中の操作感を重視するクリエイター、安定稼働を重視しているがGPU間通信を検証する余裕がない人。

導入前に、モデルの実メモリ量、Prefill時間、Decode速度、通信構成、再起動・障害時の復旧手順を比較したい。導入台数を増やすことは、必ずしも使いやすさの向上を意味しない。

7. 結論|分散は最後に選ぶ、という順序も合理的だ

巨大LLMを1台で動かすか、複数GPU・PCへ分散するか。判断は単純なGPUの枚数や合計VRAMでは決まらない。

まずモデルが1枚のGPUに収まるかを確認し、次にRAMオフロードや、単一筐体の複数GPUを検討する。そのうえで容量・速度・費用・運用条件を満たせない場合に、複数PCでの分散推論を比較する順序が現実的だ。

重要なのは、どれだけ多くの計算資源を並べるかではなく、その計算資源をどんな仕事に使い、どこで通信・待機が発生するかを把握すること。

制作とAIを並行させたいなら2台分業が有力だ。複数エージェントを同時稼働させるPC構成については、次の第18回(複数AIエージェントを動かすPC構成)で詳しく扱う。

よくある質問

GPUを2枚にすればVRAMは単純に2倍になりますか? +
利用できるモデル容量を増やせる場合はあるが、2枚のVRAMが無条件でひとつの高速メモリとして使われるわけではない。対応ランタイムとモデル分割が必要だ。
10GbEなら分散推論は十分速いですか? +
帯域だけでは判断できない。転送量、往復遅延、同期回数、プロトコル、GPU構成によって実効速度が変わる。
Tensor ParallelとPipeline Parallelはどちらが速いですか? +
接続・モデル・リクエスト数による。TPは層内の頻繁な通信、PPは段間転送と待ち時間が課題になるため、無条件の優劣はない。
RTX PCとMac Studioをつなげば、両方のメモリを合算できますか? +
通常のAPI連携では合算できない。特定の対応フレームワークでモデルを分割する実装はあり得るが、動作・性能・OS間互換性の検証が必要だ。
分散推論と2台分業はどちらを選ぶべきですか? +
ひとつのモデルが1台に収まらない場合は分散推論を検討し、制作とAI推論など別の仕事を並行する目的なら2台分業を先に検討する。

公式情報・参考文献(一次情報)

※各ソフトウェアの対応範囲およびハードウェア仕様は、2026年10月時点の公式ドキュメントに基づきます。

UNIFIED MEMORY 大容量共有メモリ・ローカルAI

🧭 大容量AIメモリ選びの道標

容量、GPU演算、プラットフォーム、実機、配置。 今の迷いに合わせて、必要な判断へ移動できます。

01|理解する
ユニファイドメモリとは?

VRAM・RAMとの違いと、大容量共有メモリがローカルAIで注目される理由を理解する。

読む →
02|容量を決める
64GBと128GBはどちらを選ぶ?

モデルサイズ、コンテキスト、RAG・Agent運用から必要なメモリ容量を判断する。

読む →
02-B|128GBと192GBで動くLLMはどう変わる?
128GBと192GBはどちらを選ぶ?

70B〜100B超モデルや大規模MoEの量子化精度、長大コンテキスト、複数エージェント常駐から192GBの必要性を判断する。

読む →
03|演算方式を決める
128GB共有メモリ vs RTX 5090 32GB

モデルを収める容量と、高速に計算するGPU性能の違いから判断する。

読む →
04|環境・方式を決める
4つのユニファイドメモリ方式を比較

RTX Spark・Ryzen AI Max・DGX Spark・Mac Studio。CUDA・OS・メモリ特性から選ぶ。

読む →
04-B|代替可能性を判定する
RTX SparkはRTX 5090・Ryzen AI Max・Mac Studioの代わりになる?

最大128GBの共有メモリとCUDAを備えるRTX Spark。実行性能・制作アプリ互換性・価格から、既存の計算環境をどこまで置き換えられるか判断する。

読む →
05|実機を絞る
EVO-X2 vs EVO-X3

完成したAIノードか、OCuLinkで外へ拡張できるAIノードかを判断する。

読む →
06|配置を決める
RTX制作PC+128GB AIノード

1台へ集中するか、CUDA制作と大容量AIを別ノードへ役割分担するかを設計する。

読む →

この記事の編集・執筆

CORE SPEC編集部が、vLLM・NVIDIA NCCL・llama.cpp RPC・Apple MLX・NVIDIA DGX Spark等の公式一次資料を照合し、複数GPU・複数PCによる分散推論の仕組みと通信制約、1台構成や2台分業との判断基準を整理しました。

運営者情報・編集方針を見る
SERIES 計算資源シリーズ(全18回)
#01 RTX 5090とRTX PRO 6000を比較:32GB・2枚差し・96GB巨大空間 読む →

計算資源の「最上位対決」|民生用フラッグシップとプロ用ワークステーションの境界線

#02 GPUマイニングは終わったのか? 暗号資産と計算資源の現在地 読む →

計算資源の「価値・用途」|電力を計算を通じて価値へ変換する。主戦場がAIへ移った背景

#03 クラウドGPUとローカルPCはどっちが安い? 月40・120・240時間の損益分岐点 読む →

計算資源の「所有・利用」|必要なときだけ借りるか、自分の環境として持つか。利用時間・VRAM・総コストから判断する

#04 Mac StudioとRTX搭載BTOはどっちがローカルLLM向き? 読む →

計算資源の「メモリ構造」|100GB超の大容量ユニファイドメモリと、高帯域なGDDR7専用VRAM。「載る容量」と「動かす速度」を分けて考える

#05 RAM 128GBでVRAM不足は補える? オフロードの限界 読む →

計算資源の「境界線」|「入る」と「速い」の違い、PCIeボトルネックとオフロードの現実

#06 ローカルLLMはロマン枠なのか? ChatGPT時代にGPUを所有する意味 読む →

計算資源の「哲学と自由」|買っているのはAIではない、AIを動かす自由だ。所有コストと依存コストの比較

#07 画像生成から動画生成へ。制作フローで考えるRTX 5080・5090・RTX PRO 6000の選び方 読む →

計算資源の「制作フロー」|16GB・32GB・96GBで変わるのは「できること」より「制約の数」

#08 AI時代にGPUはなぜ高い? AI需要・HBM・半導体製造から価格高騰を読み解く 読む →

計算資源の「コスト構造」|HBM・パッケージング・半導体製造の逼迫から見るGPU高騰の本質

#09 7B・14B・32B・70B・120BにはVRAM何GB必要? モデルサイズ別早見表 読む →

計算資源の「モデル逆算」|7B〜120Bのモデル規模・量子化・KVキャッシュから必要なVRAM容量を逆算する

#10 RTX 5090・RTX PRO 6000に必要な電力と冷却とは? GPUだけでは「計算資源」は完成しない 読む →

計算資源の「持続性」|GPUを動かし続ける電力・冷却・筐体・設置環境を考える

#11 Radeonは生成AIに使える? CUDA vs ROCmと対応ソフトを用途別に解説 読む →

計算資源の「互換性とソフトウェア制約」|GPU性能の数字だけでなく、CUDAとROCm、PyTorch、ComfyUI、TouchDesignerの制作フロー全体からGPUの本当の選び方を整理する

#12 ローカルLLM用PCは水冷が必要? エアフロー・空冷・水冷の選び方 読む →

計算資源の「冷却選定」|ローカルLLM用PCを選ぶとき、ケース・エアフロー・空冷・水冷のどこを見るか

#13 大容量ユニファイドメモリPCを比較 読む →

計算資源の「共有メモリと購入判断」|Ryzen AI Max+ 395・Mac Studioなど、大容量ユニファイドメモリを使えるPCを用途別に比較する

#14 128GBと192GB Unified Memory、動かせるLLMはどう変わる? 読む →

計算資源の「容量境界とモデル選択」|128GBと192GBで変わるLLMの収容可能性、量子化精度、推論速度、投資判断を整理する。

#15 AIに仕事のデータを入れて大丈夫? OpenCode・DeepSeek・主要AIの安全性 読む →

計算資源の「データ主権と境界設計」|ローカル実行・商用API・ZDR特約の違いから機密データの通り道を設計する

#16 巨大MoE時代、RTX 5090は主役になれるのか?|32GB VRAMと大容量RAMで動かすローカルLLM 読む →

計算資源の「モデル構造と役割分担」|MoEの仕組みと、32GB VRAM・大容量RAMの組み合わせで動かせるローカルLLMの現実を整理する

#17 巨大LLMは1台で動かすべきか? 複数GPU・複数PCの分散推論と通信の壁 この記事

計算資源の「分散推論と通信の壁」|1つの巨大LLMを複数GPU・複数PCで分割実行したときのボトルネックと1台集中の判断基準を整理する

#18 複数AIエージェントを動かすPC構成は? VRAM・RAM・2台分業で選ぶ 読む →

計算資源の「マルチエージェント同時稼働」|複数AIエージェントとツール実行環境を並行させる際のVRAM・KVキャッシュ・CPU/RAM負荷と1台/2台分業を整理する

この記事をシェアする

𝕏 Xでシェア f Share ● LINE