メインコンテンツへスキップ
When your model does not fit on a single GPU — or you need more throughput than 1 GPU delivers — you split the workload across multiple GPUs. The 2 main strategies are tensor parallelism (TP) and pipeline parallelism (PP). They solve different problems, and picking the wrong one wastes hardware.

​
簡単な結論

単一ノード内で複数のGPUを利用する場合はテンサー並列化を、複数ノードを利用する場合はパイプライン並列化を使用すること このルールがほとんどの構成に当てはまる

​
テンサー並列化の概要説明

テンサー並列化では各レイヤーの重み行列を複数のGPU間で分割する。順伝播処理の際、各GPUが行列乗算の一部を同時に計算し、その後NVLinkやPCIe、InfiniBandといった高帯域幅の相互接続を通じて同期を行う
主な特性：
  • 各GPUは各レイヤーの一部を担当する
  • すべてのGPUが各トークンの処理に参加する
  • 高帯域幅の相互接続が不可欠であり、NVLinkはPCIeよりも優れている
  • 各レイヤーごとに同期処理のオーバーヘッドが生じるが、各トークンごとのレイテンシは低く抑えられる
  • vLLM calls this --tensor-parallel-size
最適な利用例： 2台のDGX Sparkが 200ギガビット/秒のQSFP接続で連携する場合、または 2台のRTX 4090がPCIe経由で接続される場合、あるいはGPU同士が高速バスで共有される単一ノード構成でも有効だ

​
パイプライン並列処理の仕組みについて

パイプライン並列処理では異なるレイヤーが各GPUに割り当てられる。GPU 0はレイヤー 0～15を、GPU 1はレイヤー 16～31を担当する。順伝播処理は組立ラインのように進行し、GPU 0が入力を処理した後、活性化値をGPU 1へ渡して処理を継続させる
主な特性：
  • 各GPUは連続したレイヤー群を担当する
  • 各トークン処理時には常に 1台のGPUのみが稼働し、他のGPUは待機状態か別のトークンを処理している
  • 相互接続の速度が低くても問題なく、活性化値のサイズは重み行列全体よりも小さいからだ
  • パイプライン内にアイドル時間を設けることでリソース利用率を下げることができる
  • vLLM calls this --pipeline-parallel-size
適している環境： ノード間が 10ギガビットイーサネットから 100ギガビットイーサネットネットワークで接続されているマルチノードクラスター、またはテンソル並列処理だけではモデルを収容できない場合

​
判断用マトリックス

戦略を選ぶためには以下の質問に答えてください：
  1. モデルは 1個のGPUに収容可能か？
    • はい → 並列処理は不要。より高いスループットが必要な場合はデータ並列処理を利用する。
    • いいえ → 次の質問へ進む。
  2. すべてのGPUは同一マシン内にあるか？
    • はい → テンソル並列処理が最適（レイテンシが低く、デコードスループットも向上する）。
    • いいえ → 次の質問へ進む。
  3. GPUは 2台以上のマシンに分散しているか？
    • はい → ノード間での パイプライン並列化 が可能です。各ノードに 2個以上のGPUがある場合は、各ノード内でTPを実施し、ノード間でPPを実施するのが最適です。
  4. モデル規模が非常に大きい（405B個以上）でしょうか？
    • Yes → hybrid TP + PP. Example: TP=2 within each DGX Spark, PP=2 across 2 Sparks.

​
ハードウェア固有の推奨設定

​
データ並列処理およびエキスパート並列処理

特定のシナリオ向けに他にも二つの戦略が存在する： データ並列処理（DP） — 各GPU上にモデル全体を複製し、受信したリクエストを分散処理する。モデルが既に1個のGPUに収まっており、より多くのユーザーを同時に処理したい場合に適している。vLLMではこれが標準的にサポートされており、ロードバランサーの背後で複数のインスタンスを起動するだけで実現可能だ。 エキスパート並列処理（EP） — MoEモデル専用の手法である。各GPUが異なるエキスパート群を保持しており、トークンが特定のエキスパートに割り当てられるとその活性化情報が該当GPUへ送信される。TPのみでは非活性なエキスパート分のメモリが無駄になるほど巨大なMoEモデル向けに有効だ。

​
設定例

​
テンサー並列処理を用いたvLLM

For 2× DGX Spark connected via 200Gb/s QSFP:

​
vLLMにおけるパイプライン並列化の利用方法

​
ハイブリッド型TP＋PP方式（大規模モデル、複数ノード環境）

For a 405B model across 2× DGX Spark (TP within each node, PP across nodes):

​
テンサー並列化機能を備えたSGLangの利用法

特定のワークロードにおいては、デュアルGPU構成下でもSGLangはvLLMと同等の性能を発揮する：

​
NCCL用の環境変数の設定方法

複数GPU間の通信を行う際には、起動前にこれらの設定を行う必要がある：
On DGX Spark clusters connected via 200Gb/s QSFP, NCCL automatically selects the optimal transport. You typically do not need to override NCCL_IB_DISABLE or NCCL_SOCKET_IFNAME unless you are debugging connectivity issues.

​
性能比較の結果

Based on community benchmarks for 70B-class dense models:
vLLM delivers 5.9× more tokens/s than Ollama at 50 concurrent users on the same hardware. If you serve models to a team, the inference engine matters as much as the parallelism strategy.

​
並列処理を使用すべきでないケース

すべてのセットアップにおいてGPUを複数台使い分けることが有益だとは限りません。
  • モデルが 1基のGPUに十分収まる場合 — 並列処理はオーバーヘッドを生み出します。その場合は 1基のGPUのみでデータ並列処理を行い、スループットを高めるべきです。
  • コンシューマー向けGPUで小規模なモデル（7B～13B程度）を運用する場合 — テンソル並列処理における同期処理のオーバーヘッドにより、小規模モデルでは 2倍のGPUを使っても 1倍のGPUを使う場合より処理速度が遅くなる可能性があります。SGLangでもこの点で性能低下が確認されています。
  • 単一ユーザー向けの推論処理 — モデルが物理的に収まらないケースを除き、1基のGPUを使う方が構成が簡単で、多くの場合処理速度も速くなります。
  • ノード間のネットワーク帯域が 10GbE未満の場合 — 低速なネットワークではパイプライン並列処理が十分に機能しません。まずはネットワーク環境の改善を行ってください。

​
よくある問題のトラブルシューティング

​
vLLMを使用した際に複数GPU環境でメモリ不足が発生する問題

vLLM reserves memory for CUDA graphs and KV cache aggressively. On 2× RTX 3090 (48GB total), a 32B model may OOM even though Ollama handles it fine. Reduce --gpu-memory-utilization from the default 0.90:

​
NCCL接続の失敗に関する問題

GPU間で通信ができない場合は以下を確認してください。
  1. nvidia-smi topo -m — NVLinkやPCIeの接続構成を確認してください。
  2. NCCL_DEBUG=INFO — NCCLがどの通信手段を選択しているかを確認してください。
  3. ポート 29500 におけるファイアウォール設定（NCCL用のデフォルトレンデブズポート）

​
異なる種類のGPUの混在利用

vLLMでは異種GPU構成もサポートされていますが、スループットは最も速度の遅いGPUに左右されます。最適な結果を得るためには同じ仕様のGPUを使用することを推奨します。どうしても混在させる場合は、不均等なステージ割り当てを用いたパイプライン並列化により、より高速なGPUに多くのレイヤーを割り当ててください。

​
Tokiosを通じてマルチGPUデプロイを公開する

TPやPPのいずれを利用しても、vLLMまたはSGLangサーバーはローカルホスト上にOpenAI互換の /v1 APIを提供します。同じマシン上でTokiosコネクターを実行すれば、インバウンドポートを開放することなく、どのデバイスやエージェント、チームメンバーからもデプロイ内容にアクセス可能になります。
詳細な手順については vLLMリモートアクセスガイド をご参照ください。

​
次に行うべきこと

モデルの提供とスケーリング

推論エンジンがメモリやバッチ処理、KVキャッシュをどのように管理するかを理解する

DGX Sparkの利用事例

DGX Sparkまたは 2-Sparkクラスター上でTokiosをセットアップする

vLLMのリモートアクセス

どこからでも安全にあなたのvLLMサーバーへアクセスできるように設定しましょう。

量子化に関するガイド

並列処理を利用する前に、より少ないGPUでも収まるようモデルを小型化する方法をご紹介します。