Tensor Parallel vs Pipeline Parallel vs Data Parallel とは 2026年版：マルチGPU・マルチノードでローカルLLMを並列化する3方式を仕組みから比較

結論：Tensor Parallel（TP）は 1つの行列演算を GPU 間で分割する方式で「同一ノードの 2〜4 GPU、巨大モデルを1枚に収まらないから載せる」用途に最適、NVLink 無しの PCIe x8/x8 でも 70B クラスなら破綻しない。Pipeline Parallel（PP）はモデルの層を縦に分割し「マルチノードで超巨大モデル」を載せるための方式で帯域要求が低い代わりに bubble で生成速度が落ちる。Data Parallel（DP）はモデル全体を各 GPU に複製して別リクエストを同時処理する方式で「推論サーバーのスループットを稼ぎたい」用途専用。vLLM の --tensor-parallel-size、llama.cpp の --split-mode tensor、SGLang の TP 効率優位など、2026年の実装現実とあわせて選び分けを整理します。

vLLM や llama.cpp、SGLang のドキュメントで「--tensor-parallel-size 2」「Pipeline Parallel size」「Data Parallel replica」といった引数を見て、何がどう違うのか分からないまま雰囲気で使っている、というのは2026年でも珍しくありません。3つの並列化方式は どこをどう分割するか が根本的に違い、必要な GPU 間帯域・適する場面・vLLM/llama.cpp での書き方が全部変わります。

この記事は、マルチGPU でローカル LLM を動かすときに「TP・PP・DP のどれを選ぶか」を、行列計算の分割の仕方から比較します。シングル GPU の話は「ローカルLLM向け GPU 購入ガイド 2026年版」、PCIe レーンと帯域の話は「PCIe レーン x16 / x8 / x4 の違い 2026年版」が前提知識として読みやすいです。

3方式を1行で

まず最短で3方式を区別します。

• Tensor Parallel（TP）：1つの行列演算を「列方向 or 行方向」に GPU 間で分割。各 GPU が部分計算 → AllReduce で結果集約。1トークン生成中に GPU 間通信が走るため帯域命
• Pipeline Parallel（PP）：モデルの層（layer）を縦に分割。GPU 0 が層 1〜10、GPU 1 が層 11〜20…。GPU 間通信は層境界で1回だけ、帯域は要らないが bubble（待ち時間）が出る
• Data Parallel（DP）：モデル全体を各 GPU に複製、別々のリクエストを同時処理。学習で一般的、推論では vLLM/SGLang のレプリカスケールで使う

「同じモデルをどう分割するか」が違うので、TP と PP は1つのリクエストを GPU 間で協力して処理するのに対し、DP は GPU が増えても各リクエストはレプリカ内で完結する、という大枠の違いがまずあります。

Tensor Parallel：1つの行列を横に切る

LLM の重みは巨大な行列で、推論時はトークンごとに「行列 × ベクトル」を繰り返します。70B モデルなら attention の Q/K/V projection と FFN の up/down projection で、1層につき数枚の巨大行列を読み出します。

Tensor Parallel は、この 行列1枚を GPU 間で分割します。具体的には:

1. FFN の up projection 行列（例えば 8192 × 28672）を GPU 0 と GPU 1 に 列方向に半分ずつ持たせる
2. 各 GPU が入力ベクトルとの部分積を計算（並列）
3. その結果を down projection で 行方向に半分ずつ持たせた行列で受ける
4. 各 GPU の部分出力を AllReduce（足し合わせ）して最終出力にする

ポイントは「1トークン生成するために、各層で GPU 間通信（AllReduce）が走る」ことです。70B モデルは 80 層あるので、1トークンあたり 80 回 AllReduce が走ります。帯域が細いと、この通信が推論全体のボトルネックになります。

TP の帯域要求と NVLink 廃止後の現実

NVLink 世代（H100 SXM / A100 SXM / B200 SXM）では GPU 間が 900GB/s 級で直結されており、TP=2 / TP=4 で 0.92× / GPU のスケーリング効率が出ます。実質ロスなしです。

一方、コンシューマ向けは RTX 3090 を最後に NVLink が廃止され、RTX 4090 / RTX 5090 では PCIe Gen5 x8/x8（約 32GB/s） が GPU 間通信路です。NVLink の 30 分の 1 以下で、ここがそのまま TP のオーバーヘッドになります。

GPU 組み合わせ	GPU 間帯域	TP=2 効率の目安
H100 SXM × 2（NVLink）	900 GB/s	約 0.92×/GPU（ほぼロスなし）
A100 SXM × 2（NVLink）	600 GB/s	約 0.88×/GPU
RTX 5090 × 2（PCIe Gen5 x8/x8）	32 GB/s	単体並み〜単体未満（モデル依存）
RTX 4090 × 2（PCIe Gen4 x8/x8）	16 GB/s	単体未満になりがち

「RTX 5090 2枚挿しでローカルLLM は本当に速くなるのか 2026年版」で実測したとおり、RTX 5090 を 2 枚にしても速度は速くならないのはこの帯域差が原因です。コンシューマ GPU で TP を使う意味は「速くする」ではなく、**「単体 VRAM に乗らないモデルを 2 枚で載せられるようにする」**ことに尽きます。

TP の長所と短所

• ◯ レイテンシが低い（1リクエストを並列処理）
• ◯ 70B / 120B など単体 VRAM に乗らないモデルを 2〜4 GPU に載せられる
• ◯ vLLM のデフォルト並列化方式
• ✗ GPU 間帯域がボトルネック（NVLink 無しだと効率激減）
• ✗ GPU 数は 2 / 4 / 8 など 2 の累乗が無難（モデル次元の割り切りやすさのため）

Pipeline Parallel：層を縦に切る

Pipeline Parallel は、モデルの層（layer）を縦に分割します。GPU 0 が層 1〜10、GPU 1 が層 11〜20… のように、各 GPU が連続した層のまとまりを担当します。

トークン生成のフローはこうなります:

1. GPU 0 が入力を受けて層 1〜10 を計算 → GPU 1 に出力を送る（PCIe 経由でも数 MB / 回）
2. GPU 1 が層 11〜20 を計算 → GPU 2 に渡す（さらにあれば）
3. 最終 GPU が出力ロジットを返す

GPU 間通信は「層の境界」で1回だけ、しかも送るデータは1トークン分の中間表現（数 MB）で済むため、TP に比べて帯域要求が桁違いに低くなります。PCIe x4 でも実用範囲です。

PP の bubble（待ち時間）問題

ただし PP には致命的に見える短所があります。GPU 0 が層 1 を計算している間、GPU 1 は遊んでいるのです。1リクエストだけを流すと、各 GPU の稼働率は 1/N（N GPU で 1/N）まで落ちます。

対策が micro-batching：複数リクエストや複数トークン分を細切れにして「パイプライン」のように GPU に流し込む方式です。GPU 0 が次のリクエストの層 1 を処理している間、GPU 1 が前のリクエストの層 11 を処理する、という形で同時稼働率を上げます。

実装は vLLM などが内部でやってくれますが、それでも「1リクエストの単一トークン生成」のレイテンシは N GPU で実質 N 倍に近くなります。PP は throughput を稼ぐ方式で、latency を稼ぐ方式ではない、という整理が必要です。

PP が刺さるユースケース

• マルチノードで超巨大モデル（DeepSeek V3 671B 等）を分散：1ノード 8 GPU でも乗らないモデルを、4ノード 32 GPU で載せる。ノード間は InfiniBand でも 200Gbps（25GB/s）程度で、TP では帯域不足。PP なら層境界の数 MB だけ送ればいい
• PCIe しかない自宅環境で、TP よりは安定：GPU 4 枚で 200B 級を「とにかく動かしたい」場合
• vLLM / SGLang の --pipeline-parallel-size で組み合わせ可：例えば 2 ノード × 4 GPU で --pipeline-parallel-size 2 --tensor-parallel-size 4 のような構成

Data Parallel：モデルを複製して別リクエストを処理

Data Parallel は、モデル全体を各 GPU に複製して、別々のリクエストを並列処理します。GPU 0 がユーザー A のチャットを、GPU 1 がユーザー B のチャットを、互いに無関係に処理する、という方式です。

学習の世界では DDP（Distributed Data Parallel） として最も一般的な並列化方式で、各 GPU が別データバッチを処理して勾配を AllReduce する形でした。推論ではこの「勾配 AllReduce」は不要なので、各 GPU レプリカは完全独立で動きます。

推論サーバーでの DP

vLLM や SGLang は内部で DP を「レプリカスケール」として扱います。vllm serve --data-parallel-size 4 のように指定すると、同じモデルが 4 GPU に複製され、リクエストはロードバランサ的に振り分けられます。

• 長所：GPU 数に対して スループットが線形にスケール（同時 4 ユーザーなら 4 倍）、GPU 間通信ゼロなので帯域不要
• 短所：単体 GPU に乗るサイズのモデルしか使えない（モデルを分割しないため）
• 使い分け：20B 級 / 70B Q4 を 24〜32GB VRAM 単体に乗せて、社内 50 人で同時利用するような用途に最適

TP + DP のハイブリッドも一般的

実運用では「TP=2 で 70B を 2 GPU に乗せ、それを DP=2 で複製して 4 GPU で並列処理」のような TP × DP 構成が定番です。vLLM なら --tensor-parallel-size 2 --data-parallel-size 2。社内 ChatGPT のような用途では、これが効率最大の組み方になります。

判断軸：用途別の選び方

3方式の使い分けを1枚にまとめます。

やりたいこと	おすすめ方式	構成例
単体 VRAM に乗らない 70B を 2 GPU で動かしたい	TP	RTX 5090 × 2 + TP=2、または H100 SXM × 2
マルチノードで 200B〜671B を分散	PP（+ ノード内 TP）	4ノード × 8 GPU = PP=4, TP=8
社内 ChatGPT を高同時接続で運用	DP（+ 必要なら TP）	RTX PRO 6000 × 4、DP=4
1ユーザーの対話を最速にしたい	TP 単体（GPU 1〜4 / NVLink あり）	H100 SXM × 2 + TP=2
PCIe しかなく速度より「動くこと」優先	PP（帯域要求低）	RTX 4090 × 4 + PP=4

「同一ノードの 2〜4 GPU、巨大モデル」→ TP。「マルチノード超巨大モデル」→ PP。「同時接続スループット」→ DP。この3つの軸で迷ったら、まずこの早見表に戻ってください。

2026年実装の現実：vLLM / SGLang / llama.cpp

主要ランタイムでの並列化の指定方法を整理します。

vLLM

vLLM の流儀は TP がデフォルト、PP は補助。

# TP=2 で 70B を 2 GPU に乗せる
vllm serve meta-llama/Llama-3.3-70B-Instruct --tensor-parallel-size 2

# TP=2 + PP=2 で 4 GPU、超巨大モデル
vllm serve deepseek-ai/DeepSeek-V3 \
  --tensor-parallel-size 4 \
  --pipeline-parallel-size 2

# DP（レプリカ複製）
vllm serve meta-llama/Llama-3.3-70B-Instruct \
  --tensor-parallel-size 2 \
  --data-parallel-size 2

vLLM 公式は「ノード内は TP、ノード間は PP」を推奨しています。TP は AllReduce が重いので NVLink / InfiniBand のような高帯域が前提、PP は層境界の軽量通信なので Ethernet / PCIe でも回る、という素直な棲み分けです。

SGLang

SGLang は vLLM と引数名がほぼ同じで、--tp-size / --dp-size を持ちます。実装上の特徴は RadixAttention によるプレフィックスキャッシュで、TP の効率が vLLM より高いと報告されており、H100 ベンチで vLLM 12,500 tok/s に対して SGLang 16,200 tok/s（約 29% 優位） とされます。RAG・マルチターン対話のように同じプレフィックスを使い回す用途では特に強いです。

llama.cpp

llama.cpp は CLI 引数 --split-mode で並列化方式を切り替えます。

• --split-mode layer（旧デフォルト）：Pipeline Parallel 相当。層を分割、互換性が広い
• --split-mode row：旧来の Tensor Parallel 相当、性能は限定的、新規利用は非推奨
• --split-mode tensor：2026年4月にマージされた新しい TP 実装。CUDA バックエンド前提で、行 / 列の真の TP を実現。プロンプト処理 / トークン生成の両方で 3〜4× の速度向上が報告

# llama.cpp 新 TP モード
llama-cli -m gpt-oss-120b.gguf --split-mode tensor -ngl 99

# 互換性重視の従来 PP モード
llama-cli -m llama-3.3-70b-q4.gguf --split-mode layer -ngl 99

新しい --split-mode tensor は CUDA / Vulkan / Metal の対応状況がバックエンド依存で、まだ揺れています。vLLM / SGLang の TP と同じ感覚で使うには「対応バックエンドかつ NVLink あり」が無難。詳細は「ローカルLLMランタイム比較（Ollama / LM Studio / llama.cpp / vLLM）2026年版」が補足します。

マルチGPU で組むハード側の準備

TP を本気でやるなら、PCIe レーンと CPU の選び方が問題になります。

• TP を 2 GPU で組む → コンシューマ Ryzen / Core では PCIe Gen5 x8/x8 が上限。NVLink 無いので帯域は 32GB/s で頭打ち
• TP を 4 GPU で組むなら HEDT 必須：Threadripper / Threadripper PRO / Xeon W で PCIe Gen5 x16 × 4 を確保。詳細は「Threadripper 9000 でローカル LLM・AI 開発 2026年版」
• CPU メモリ帯域もボトルネック：GPU が空くと CPU 側にオフロードされるので、CPU 側 DDR5-6400 8ch のような構成が望ましい

PCIe の x16 / x8 / x4 が何をどう変えるのかは「PCIe レーン x16 / x8 / x4 の違い 2026年版」で詳細を扱っています。

まとめ：3方式を使い分けて、ハマる用途に最短ルートで合わせる

• TP（Tensor Parallel）：行列を切る、帯域命、レイテンシ低、同一ノード 2〜4 GPU
• PP（Pipeline Parallel）：層を切る、帯域要求低、bubble あり、マルチノード超巨大モデル
• DP（Data Parallel）：モデル複製、GPU 間通信ゼロ、スループット線形、推論サーバー

「マルチGPU = 自動で速くなる」は誤解で、何をどう分割するか で速くなるケースと遅くなるケースが両方あります。NVLink 廃止後のコンシューマ環境では「速さは TP で買えない、容量は TP で買える、スループットは DP で買える」と頭の中で線を引いておくと、機材投資の判断ミスが減ります。

巨大モデルを「動かすこと」が目的なら、TP で 2 枚に分けるよりも RTX PRO 6000 96GB 単体 や Mac Studio M3 Ultra 256GB Unified Memory のように GPU 間通信そのものを発生させない構成が、結果として安く・速く・静かに着地することも多いです。その辺りの比較は「Apple Silicon の Unified Memory と NVIDIA VRAM、ローカルLLM では何が違うのか 2026年版」が参考になります。

---

あなたに合うPCを診断する

用途や予算をもう少し細かく入力すると、3つの候補構成を提案します。

→ 診断スタート

関連記事

• RTX 5090 2枚挿しマルチGPUでローカルLLMは本当に速くなるのか 2026年版
• PCIe レーン x16 / x8 / x4 の違い 2026年版
• Threadripper 9000 でローカルLLM・AI 開発 2026年版
• ローカルLLMランタイム比較（Ollama / LM Studio / llama.cpp / vLLM）2026年版