9月26日、Vetted Consumerが「Does a Second GPU Make Your Local LLM Faster? Layer Split vs Tensor Parallel, Explained」と題した記事を公開した。この記事では、ローカルLLM推論においてGPUを2枚構成にした場合に実際に速度が上がるのか、レイヤー分割とテンソル並列という2つのモードの仕組みと理論値・実測値の違いについて詳しく紹介されている。
「2枚目のGPUで速くなる」は半分正しい
GPUを複数枚使ってローカルLLMを動かす場合、「枚数が増えれば速くなる」と思いがちだ。だが実際には、llama.cppのほぼ誰も触っていない分散方式の設定によって、結果は大きく異なる。
llama.cppには、モデルを複数GPUに分散させる方式が2種類ある。
- レイヤー分割(
--split-mode layer、デフォルト):2枚のGPUが交互に動く。メモリ容量は2枚分になるが、1ユーザーの生成速度はほぼ1枚分のまま。 - テンソル並列(
--split-mode tensor):全レイヤーで両GPUが同時に計算する。単一ストリームの速度を最大2倍近くにできるが、レイヤーごとに同期処理(all-reduce)が必要で、GPU間の帯域が重要になる。
レイヤー分割:「順番待ち」の構造
デフォルトのレイヤー分割では、GPU1が担当する40層を処理し、その結果をGPU2に渡して次の40層を処理する。どの時点でも片方は待機状態だ。GPUのトークン生成速度はメモリ帯域律速(TFLOPSではなく帯域が支配する)であるため、2枚が順番に半分ずつ読んでも、1枚がすべてを読む場合と所要時間は変わらない。
以下は元記事が示す理論上限の試算であり、著者自身の実測値ではなくメモリ帯域からの算術値である。Llama 70BのQ4_K_Mは約42GBの重み。RTX 3090のメモリ帯域は936GB/sなので、デュアル3090でのレイヤー分割の理論上限は936÷42≒22トークン/秒。r/LocalLLaMAのオーナー報告(実測値)では短いコンテキストで17.9トークン/秒、32Kコンテキストでは7.9トークン/秒という数字が出ている。これは48GB搭載の単一カードと同等の数値であり、「2枚目が買ったのはモデルをロードする容量であって、速度ではない」というのが結論だ。
ただし利点もある。GPU間でやり取りするデータは1トークンあたり約16KB(70Bクラスのhidden state)と極めて小さく、マイニングリグ用のPCIe x1ライザーでも問題ない。サイズの異なるカードの混在(例:3090+3060)も--tensor-splitで比率調整できる。
テンソル並列:2枚が同時に動く
テンソル並列はMegatron-LM(Shoeybi et al., 2019)に由来する手法で、各レイヤーの行列積を列・行に分割し、アテンションはヘッド単位で分割する。両GPUが同時に自分の担当重みを読むため、帯域の理論上限は2倍になる。
代償はall-reduceの回数だ。80層の70Bモデルでは1トークン生成につき160回の同期が走る。1回の転送量は同じ16KB程度と小さいが、160回の往復レイテンシが積み上がる。vLLMの並列スケーリングガイドはNVLinkを持たないノードではテンソル並列よりパイプライン並列(レイヤー分割相当)を推奨している。
llama.cppの新しいテンソル並列モード
従来の--split-mode rowは「すべての演算後に同期が必要」という設計で、P40のような旧世代カード向けだった。2026年4月9日にマージされたpull request 19378が、計算グラフから分割を推論し数学的に必要な箇所のみ同期する真のテンソル並列モードtensorを追加した。llama.cppはオープンソースのローカルLLM推論ライブラリとして活発に開発が続いており、このPRもその継続的な改善の一環だ。現在rowはdeprecated、tensorはexperimentalとして扱われる。
利用上の制約:
- NVIDIAのみ実用的。 CUDAバックエンドのみ最適化済み。AMDはレイヤー分割を下回り、Vulkanは性能が悪い。
- NCCLが必要。 NCCL(NVIDIA Collective Communications Library)なしでは「multi GPU performance will be suboptimal」と警告が出る。
- 量子化KVキャッシュ不可。 フラッシュアテンションとF16/BF16/F32キャッシュが必須。q8_0キャッシュによる長コンテキスト節約はできなくなる。
- 対応アーキテクチャに制限あり。 DeepSeek2、Mistral4、Mambaハイブリッドなど、2026年に注目の大型MoEファミリーの一部が未対応。
実測値:理論の半分が現実
ik_llama.cpp discussion 1247のベンチマークが最も整理された公開データだ。なおこれらの数値は1名のフォーク管理者の環境による実測値であり、mainlineのテンソルモードはexperimentalラベルのままである点に留意が必要だ。
| 構成 | モデル | mainline -sm tensor |
ik_llama.cpp graph mode |
|---|---|---|---|
| 4× RTX 3090 | Llama 3 70B, Q4_0, 空コンテキスト | 約48トークン/秒 | 約50トークン/秒 |
| 4× RTX 3090 | gpt-oss-120B, MXFP4, 空コンテキスト | 約123トークン/秒 | 約164トークン/秒 |
| 4× RTX 3090 | gpt-oss-120B, MXFP4, 57Kコンテキスト | 約99トークン/秒 | 約126トークン/秒 |
Llama 3 70BのQ4_0(約4.5bit/weight)は4枚並列での理論上限が約95トークン/秒(メモリ帯域からの算術値)。実測は48トークン/秒と理論値の約半分だ。同期コストが残り半分を食っている計算になる。それでもデュアル3090のレイヤー分割(実測約17.9トークン/秒)の2倍以上であり、レイテンシ重視の1ユーザー向けには初めて実用的な選択肢になった。
NVLinkの効果
Himesh P.のvLLMベンチマーク(Qwen2.5-7B、電力220W制限)では以下の結果が示されている。
| GPU数 | NVLink | 出力トークン/秒 | 総スループット |
|---|---|---|---|
| 2枚 | あり | 715 | 6,790 |
| 2枚 | なし | 483 | 4,583 |
| 4枚 | あり | 535 | 5,093 |
| 4枚 | なし | 490 | 4,669 |
2枚ではNVLinkが**約48%**のゲインをもたらしている。一方、このサイズのモデルでは4枚が2枚より遅くなっており、3090のNVLinkブリッジはペア間のみ接続でペア間はPCIeになるためスケールしない。「枚数を増やせば必ず速くなる」わけではない。
前述のLlama 70Bベンチマークと対象モデル・計測環境が異なるため直接比較はできないが、NVLinkの有無がall-reduce帯域に与える影響を示す参考値として読むと有益だ。
用途別の選び方
- モデルが1枚に収まらず、1人でチャット:どのスロット・どの組み合わせでもレイヤー分割で十分。速度は1枚分と割り切る。
- 70B密モデルを1ユーザーで速く動かしたい:同一NVIDIA GPU、x8/x16スロット、NCCL込みビルドで
-sm tensor。アーキテクチャ対応を事前確認。 - 複数ユーザー・エージェントを捌く:NVLinkあり同一カードでvLLM+テンソル並列。バッチがall-reduceコストを吸収し、スケールが効く。
- 大型MoEモデル:アクティブパラメータのみ読む特性からレイヤー分割でも高速。かつllama.cppのテンソルモード未対応のファミリーが多い。容量優先。
詳細はDoes a Second GPU Make Your Local LLM Faster? Layer Split vs Tensor Parallel, Explainedを参照していただきたい。