llama.cpp のマルチ GPU 性能を実測する考え方：2x V100 16GB は単体 32GB より速いのか？

Sat, 09 May 2026 15:05:41 +0800

大まかな結論は、llama.cpp のマルチ GPU offload は「2 枚目を足せば性能がそのまま増える」ものではない、ということです。モデルが最初から 1 枚の 32GB GPU に完全に収まるなら、2x V100 16GB は単体 32GB より扱いにくく、場合によっては遅くなります。逆に、モデルが 1 枚の 16GB に収まらないなら、2 枚構成の主な価値は「モデルを GPU に載せられること」で、その効果はかなり大きくなります。

まず split mode を分けて考える

llama.cpp のマルチ GPU 利用では、主に --split-mode と --tensor-split が関係します。性能を考えるときは、まず次のモードを分けて見ます。

layer：層ごとに別の GPU へ分割する方式。互換性が高く、多くの場合は最初に試す選択肢です。
tensor：テンソル計算を複数 GPU に分割する方式。より並列計算に近い一方で、GPU 間の帯域とバックエンド対応に強く依存します。
row：古い行分割方式です。今でも見かけますが、新規構成で最初に選ぶ方式ではありません。

簡単に言えば、layer は「階ごとに別のカードへ置く」ようなものです。単一 token 生成時には、2 枚のカードを同時に常に使い切れるとは限りません。tensor は「同じ層を 2 枚のカードで一緒に計算する」形に近く、理論上は並列性がありますが、カード間通信がボトルネックになります。

単体 32GB に収まるなら、双 16GB が速いとは限らない

モデルと KV cache が 1 枚の 32GB GPU に完全に収まるなら、単体カードのほうが安定し、速いことも多いです。1x V100 32GB と 2x V100 16GB のような同世代ハードウェアでは、後者が必ず勝つとは言えません。

保守的に見ると、2x V100 16GB は単体 V100 32GB より 10% から 40% 遅くなることがあります。特に、一人でのチャット、Continue Agent、コード Q&A のように、1 回のリクエストで主に 1 つの回答を生成する用途ではそうなりやすいです。

理由は単純です。マルチ GPU は VRAM を単純に 1 つの高速なプールへ合体するわけではありません。layer 分割では推論が GPU 間を移動し、token 生成時に片方の GPU がもう片方を待つことがあります。tensor 分割では 2 枚で同時に計算できますが、中間結果の同期が必要になり、帯域と遅延がスループットに直接効きます。

つまり選択肢が次の 2 つなら、

1x V100 32GB
2x V100 16GB

対象モデルがすでに 1 枚の 32GB に完全に収まる場合、単体 32GB のほうが使いやすいことが多いです。

単体 16GB に収まらないなら、双カードの価値は大きい

一方で、モデルが 1 枚の 16GB に収まらず、2 枚の 16GB なら収まる場合は話が変わります。

このとき双カードの価値ははっきりしています。

1 枚の 16GB：大量の CPU offload が必要になり、速度が大きく落ちる可能性があります。
2x 16GB：重みをできるだけ GPU に残せるため、CPU/GPU 混在実行よりかなり速くなる可能性があります。

この場面では、2x V100 16GB が単体 32GB より速いとは限りません。それでも「1 枚 16GB と大量のシステムメモリ offload」より数倍速いことはあります。つまり双カードの第一の価値は加速ではなく、モデル重みを遅いシステムメモリへ落とさずに済むことです。

V100 PCIe と V100 SXM2 は大きく違う

マルチ GPU 推論で見落としやすいのがインターコネクトです。

V100 SXM2 で、マシンに NVLink がある場合、GPU 間通信帯域はかなり高くなります。NVIDIA の V100 資料では、NVLink の相互接続帯域は最大 300GB/s とされています。この環境なら、tensor や大きめの batch を使う場面で、単体カードに近い性能、あるいはそれを超える性能を狙いやすくなります。

V100 PCIe の場合は、もっと保守的に見るべきです。V100 PCIe の相互接続は主に PCIe Gen3 で、資料上の interconnect bandwidth は 32GB/s です。NVLink とは桁が違うため、PCIe 双カードでは「VRAM は足りるが速度は 2 倍にならない」ことがよくあります。

そのため 2x V100 16GB が価値ある構成かを判断するときは、VRAM を足して 32GB と見るだけでは足りません。PCIe 版なのか、SXM2/NVLink 版なのかも確認する必要があります。

実際にはどう選ぶか

モデルが 1 枚の 32GB GPU に収まるなら、まず単体カードを優先します。遅延、安定性、調整コストの面で有利なことが多いです。

モデルが 1 枚の 16GB には収まらず、2 枚の 16GB なら収まるなら、双カードは使う価値があります。この場合の目的は、重みをできるだけ GPU に残すことであり、性能が線形に倍増することを期待することではありません。

V100 PCIe の双カードなら、まず --split-mode layer を試し、「安定して動くこと」と「CPU に落とす量を減らすこと」を目標にします。

V100 SXM2/NVLink なら、tensor 関連のモードを試す価値が高くなります。特に prefill、大きい batch、同時リクエストの場面で有効です。

いつ 2x16GB を買い、いつ 1x32GB を買うか

一人で使い、主にチャット、コード補完、Continue Agent、長文コンテキスト Q&A を行い、対象モデルが 32GB に収まるなら、1x32GB のほうが一般的にはおすすめです。GPU 間スケジューリングがなく、遅延が安定し、問題切り分けも簡単です。

すでに 16GB カードを 1 枚持っていて、低コストで 30B、32B、または高めの量子化モデルを動かしたいなら、2x16GB には意味があります。token/s が倍になるとは限りませんが、本来 CPU offload が必要だった重みを GPU に残せます。

新規に購入するなら、優先度は次のように考えられます。

単一モデル、単一ユーザー、応答遅延重視：1x32GB を優先。
モデルが単体カードに収まらず、予算が限られる：2x16GB を検討。
NVLink または SXM2 マシンがある：2x16GB の有用性は通常の PCIe 双カードよりかなり高い。
将来さらに長いコンテキストを使いたい：重みサイズだけでなく、KV cache 用の VRAM も残す。

layer split と tensor split の実用的な使い方

実用上のおすすめは、まず layer、次に tensor を測ることです。

layer は出発点に向いています。モデルを層単位で分配し、互換性が高く、PCIe 双カードにも比較的向いています。欠点は、生成段階がパイプラインのようになり、ある時点では片方のカードだけが忙しく、もう片方が待つことがある点です。

tensor は、V100 SXM2/NVLink のように相互接続帯域が高いマシンに向いています。同じ層の計算の一部を複数 GPU に分けるため、理論上は並列性があります。ただしカード間同期が増えます。PCIe 双カードでは、通信コストが利益を食いつぶす可能性があります。

実際のテストは、まず次のような組み合わせから始めます。

1
2
3

llama-bench -m model.gguf -ngl 99 --split-mode layer --tensor-split 1,1
llama-bench -m model.gguf -ngl 99 --split-mode tensor --tensor-split 1,1
llama-bench -m model.gguf -ngl 99 --split-mode layer --tensor-split 1,0

3 つ目は長期運用向けではありません。単体カードの参照値を取るためです。これにより、双カードが本当に速いのか、それとも単に VRAM 圧力を分散しているだけなのかを見分けられます。

prefill と decode で性能が違う理由

ローカル LLM の性能は、通常 2 つの段階に分けて見るべきです。

prefill：入力 prompt を処理します。代表的な指標は pp512 のような prompt processing スループットです。
decode：回答を token ごとに生成します。代表的な指標は tg128 のような token generation スループットです。

prefill は大きな batch の行列計算に近く、GPU を使い切りやすく、マルチ GPU 並列化の恩恵も受けやすいです。decode は 1 token ずつ生成するため、batch が小さく同期が頻繁です。そのためカード間通信とスケジューリング遅延が表に出やすくなります。

そのため、双カードで pp512 は良くなるのに、tg128 はほとんど改善しない、あるいは遅くなることがあります。チャットや Agent の体感は tg128 に近く、長文投入、batch prefill、同時リクエスト処理では pp512 も重要になります。

KV cache は第 2 の VRAM ボトルネックになるか

なります。多くの人はモデル重みだけを計算し、KV cache を忘れます。

モデル重みは「モデルをロードできるか」を決めます。KV cache は「必要なコンテキスト長を使えるか」を決めます。コンテキストが長く、同時実行が多く、batch が大きいほど、KV cache の占有は目立ちます。モデル本体は 32GB に収まるのに、32K や 64K コンテキストを開くと VRAM が足りなくなることがあります。

少なくとも次の分の VRAM 余裕を残して考えるべきです。

KV cache
CUDA graph またはバックエンドのランタイムオーバーヘッド
prompt batch と ubatch
デスクトップ、ドライバ、他プロセスの使用量

2x16GB を使う場合、VRAM は完全に等価な 32GB の大きなプールではありません。一部のバッファ、KV cache、中間テンソルは、単一カードの残り VRAM に制限される場合があります。長文コンテキストを測るときは、モデルが起動するかだけでなく、実際の --ctx-size と同時実行数でテストするのが安全です。

llama-bench で双カードを自分で測る

llama-bench は、直接チャットするよりハードウェア比較に向いています。prompt processing と token generation を分けて比較できるためです。公式 README の基本例は次の通りです。

`1`	`llama-bench -m model.gguf`

双 V100 なら、少なくとも次の組み合わせを測ります。

# Single-card baseline
CUDA_VISIBLE_DEVICES=0 llama-bench -m model.gguf -ngl 99

# Dual-card layer split
CUDA_VISIBLE_DEVICES=0,1 llama-bench -m model.gguf -ngl 99 --split-mode layer --tensor-split 1,1

# Dual-card tensor split
CUDA_VISIBLE_DEVICES=0,1 llama-bench -m model.gguf -ngl 99 --split-mode tensor --tensor-split 1,1

特に見るべき列は 2 つです。

pp512：prompt processing。長い入力や batch prefill に関係します。
tg128：token generation。単一ユーザーのチャットや Agent の体感に関係します。

テスト時は、モデル、量子化形式、コンテキスト長、batch、ドライババージョン、llama.cpp バージョンを固定します。各組み合わせを複数回実行し、一度だけの結果ではなく中央値で比べるほうが信頼できます。最後に、Continue Agent、OpenAI-compatible server、自分の RAG リクエストなど、実際のワークフローでも確認します。benchmark が良くても、対話体験が必ず良くなるとは限らないためです。

一言でまとめると

2x V100 16GB の強みは主に VRAM 容量であり、生成速度が必ず上がることではありません。モデルが単体カードに収まるなら、単体 32GB のほうが速く安定しやすいです。モデルが 1 枚 16GB に収まらないなら、双 16GB の価値は大きくなります。大量の CPU offload を避けられるためです。実際に速くなるかは、split mode、batch、モデルサイズ、そして 2 枚の V100 が PCIe でつながっているのか NVLink なのかで決まります。

参考資料：

V100 on KnightLiブログ