ローカルLLMを2枚のGPUのVRAMプールで動かす｜OCuLink接続の帯域ボトルネックを見極める

1枚のGPUに載りきらないモデルは、2枚のGPUのVRAMを束ねれば動く（どのモデルが16GBに収まるかはVRAM 16GBで動かすローカルLLMの早見表で確認できる）。ただしOCuLink接続では「どの方式で2枚に分けるか」で速度が変わり、実機で測ると直感に反する結果が出る。この記事では、RTX 5080とRTX 5060 Ti（16GB版・OCuLink接続）の実機でレイヤー分割とテンソル並列を測り比べ、どちらをいつ選ぶかを整理する。なお本稿では分かりやすさのため「VRAMプール」と呼ぶが、これは16GB＋16GBが透明な32GBの単一VRAMとして見える仕組みではなく、モデルの重みやキャッシュを複数GPUへ分割配置する方式を指す。容量を足す話と、速度を分ける話は分けて扱う。

1枚に載らないモデルを2枚のGPUで動かす仕組み

VRAMプールとは、複数のGPUに搭載されたメモリを使って、単体GPUには収まらないモデルを動かす構成です（16GBであふれるモデルを2枚目のGPUで解消し速度が回復した実測は別記事の16GBあふれ→デュアル化の実測で扱っています）。ただしOSやCUDAが16GB＋16GBを透明な32GBの単一VRAMとして提供するわけではありません。実体は、モデルの重み・KVキャッシュ・計算バッファーをGPUごとに分割配置する方式で、テンソル並列では重みとKVがGPU間で分割され、レイヤー分割では各GPUが担当レイヤーを保持します。したがって単純合計の32GBをすべて自由に使えるわけではなく、実際に使える容量は分割方法やGPUごとの作業領域によって少なくなります。

増えるのは主に載せられるモデル容量であり、2枚のVRAM帯域が1本の巨大な帯域として合算されるわけではありません。RTX 5080ならオンボードのメモリ帯域は約960GB/s、RTX 5060 Ti（16GB版）なら約448GB/s（NVIDIA公式仕様およびメーカースペックによる。末尾の参考資料を参照）で、各GPUは自分のVRAM内部帯域で計算します。ただし、計算そのものを2枚で並列化できる方式では、単一リクエストの生成速度や複数リクエストの処理量が改善する場合があります。本稿で比較するのは、同じ2枚構成の中で、その並列化のさせ方によって速度がどう変わるかです。

モデルを2枚に分けた瞬間に、GPUをまたいでデータが移動する経路が生まれます。この移動は2枚をつなぐ外部リンク（ここではOCuLink）を通り、その太さと、分割方式ごとに「何を・どれだけ」リンクへ流すかで、実際の速度が決まります。Intelのニュースルーム論説も、AIシステムではアクセラレータの演算性能だけでなく、CPUやアクセラレータへデータを十分な速さで供給できるかが重要だと指摘しています。ただし同記事が主に扱うのはXeonのホストメモリ帯域で、本稿が比較するGPU内のVRAM帯域やGPU間のPCIeリンク（今回のOCuLinkで約8GB/s級）とは別の経路です。共通するのは、演算器だけでなくデータ移動の経路もボトルネックになり得る、という点です。

OCuLink接続の帯域をVRAM帯域と並べて見る

OCuLink（SFF-8611/8612）は、PCIe信号をケーブルで延長するための物理規格（コネクタ・ケーブル側）です。それ自体が常に「PCIe 4.0 x4・約8GB/s」を保証するわけではなく、実際のリンク速度はホスト側のレーン・アダプター・BIOS・ケーブル・GPUとのネゴシエーションで決まり、環境によってGen3やx2に落ちることもあります。今回の構成は、5060 Ti 側の実リンクが PCIe 4.0 x4（nvidia-smi で Gen4・幅x4 を確認）で、理論帯域は約7.9GB/s・方向です。

このOCuLinkの帯域を、GPU内部のVRAM帯域と並べると差がはっきりします。

接続経路ごとの帯域

PCIe 4.0は1レーンあたり約2GB/s（理論値。実効ペイロードはプロトコルのオーバーヘッドで下がる）。OCuLinkはx4なので片方向約7.9GB/s、送受信を同時に行った場合の理論合計は約15.8GB/sですが、一方向へ16GB/sを流せる意味ではありません。GPU内部の448〜960GB/sと比べると数十倍から100倍以上の開きがあり、GPUの中でデータが動く速さと、2枚のGPU間でデータが動く速さには2桁の差があります。なお2枚目GPUの帯域はマザーボードのPCIeレーン構成にも左右されます。配線・スロットの選び方はAI用PCのマザーボードとPCIeレーンの選び方で整理しています。OCuLink端子を使っていても環境によってPCIe世代やレーン数が異なるため、結果を比較するときは実際のリンク速度（nvidia-smi -q -d PCI やGPU-Z）を確認してください。2枚目を物理スロットへ直挿ししている場合も考え方は同じで、表のOCuLink行を自分のスロットの帯域に置き換えれば以降の判断はそのまま使えます。

ここで一つ、直感的な予想が立ちます。「これだけ細いリンクなら、GPU間の通信が多い方式は遅くなるはず」。ところが実機で測ると、その予想は生成速度については当てはまりませんでした。

分割方式で生成速度がどう変わるか（実測）

モデルを2枚に分ける方式には大きくレイヤー分割とテンソル並列があります。RTX 5080 + RTX 5060 Ti（OCuLink）の実機で、16GBに収まらない2種類のモデルを両方式で測った結果が次の表です。生成（デコード＝1トークンずつ出力する速度）とプロンプト処理（入力をまとめて読む速度）を分けて示します。いずれも単一ストリーム（1リクエスト）での測定です。

目を引くのは、生成速度でテンソル並列がレイヤー分割を上回った点です。とくに dense（全パラメータが毎回動く）32Bでは約1.3倍。「細いリンクを頻繁に使う方式ほど遅い」という予想と逆の結果でした。理由は、それぞれの方式が1トークンを作る間にGPUをどう動かすかにあります。

単一ストリームのレイヤー分割では、GPUが順番に動く

レイヤー分割は、各GPUが連続したレイヤー群をまるごと担当する方式です。GPU0が先頭からN層、GPU1が残りの層を持ちます。1本の会話を低バッチで生成するとき、GPU0の担当レイヤーが終わってからGPU1の担当レイヤーへ進むため、両GPUの計算を同じ瞬間に使い切りにくくなります。これが「2枚積んだのに2枚目が待ちに入る」と言われる状態です（デュアルGPUで二枚目が遊ぶ落とし穴もこの一種です）。一方、複数のリクエストや大きなバッチを処理するサーバー用途では、異なるマイクロバッチを各GPUのレイヤーへ流してパイプラインを重ねられるため、「レイヤー分割は常にGPUを遊ばせる」とは限りません。公式ドキュメントでも、レイヤー（パイプライン）分割はバッチのスループット最大化向け、テンソル並列は単一処理のレイテンシ短縮向けと位置づけられています。

レイヤー分割で発生する主なGPU間通信は担当レイヤーの境目で、テンソル並列より通信は少なく、公式にも低速なインターコネクトに比較的耐えやすい方式とされます。今回の単一ストリームでは、リンク通信よりも、2枚が順番にしか動かない待ち時間の影響が大きかったと考えられます。

テンソル並列は両GPUが同時に動く

テンソル並列は、1つのレイヤーの計算そのものを2枚で分担する方式です。同じ層を両GPUが同時に計算し、その都度おたがいの結果を突き合わせて（集約して）次へ進みます。両方のGPUが並行して働くため、演算が重いモデルほど手空きが減り、速くなります。dense 32Bで効果が大きかったのはこのためです。逆にMoE 35B-A3Bで差がつかなかったのは、毎回動くパラメータが約3Bと少なく、dense 32Bほど並列演算の利得を得にくいことが一因と考えられます。ただしハイブリッド構造や通信処理、異種GPU構成の影響も含まれるため、今回の結果だけで原因を一つに絞ることはできません。

テンソル並列は、レイヤーごとにGPU間の集約（リダクション）を複数回行うため、公式の機構上もインターコネクトの帯域やレイテンシの影響を受けやすいとされます。デコードでは一度に扱うトークン数が少ないため、今回の環境ではGPU間通信のコストより並列演算の利得が上回りました。一方プロンプト処理では、入力の多数トークンを一度に流すぶん集約するデータ量も増え、テンソル並列がレイヤー分割より14〜16%遅くなりました。この低下は、PCIe 4.0 x4というリンク制約が表れた可能性と整合します。ただしx16接続などとの比較は行っていないため、低下量のすべてをOCuLinkだけに帰属させるものではありません。集約通信の経路はNCCLやCUDA P2Pの有無でも変わります。今回のWindows環境ではNCCLを使用せず、GGML_CUDA_P2Pも未設定だったため、llama.cppの直接P2P転送は有効化していません。したがって今回の結果には、ホストメモリを介する通信経路の影響も含まれます。

なお、重みをrow方向に割る旧実装（--split-mode row）は、テストしたverでは両モデルともロード自体に失敗し、選択肢になりませんでした。テンソル並列を試すなら新しい方式（--split-mode tensor）を使うことになりますが、公式ドキュメント上はまだ実験的（EXPERIMENTAL）な位置づけで、ビルドによる挙動差が出やすい点は踏まえておく必要があります。また今回の2枚は帯域の異なる組み合わせ（約960GB/s級と約448GB/s級）ですが、2枚の性能差がさらに大きい構成では遅い側が全体の足並みを決めるため、テンソル並列の優位が縮むこともあります。

実際に2枚でプールする設定と、自分の環境での測り方

2枚のGPUにモデルを分けて載せる設定は、使うランタイムで手数が変わります。まず「両GPUに正しく載ったか」を確認できる状態を作り、そのうえで分割方式を切り替えて速度を比べるのが実際的です。

ランタイムごとの分割方式の扱い

今回確認したOllama（バージョンは環境依存）ではレイヤー分割で動作し、テンソル並列を選ぶ公開設定は確認できませんでした。LM Studio は 0.4.15（2026年5月）で CUDA テンソル並列の対応が追加されており、設定画面から選べます（画面の名称や位置はバージョンで変わり得ます。LM Studioと他ツールの違いは姉妹サイトで解説）。推論エンジンごとの違い（Ollama・llama.cpp・LM Studio・vLLMの比較）も踏まえつつ、より細かく制御したい・自分で測って比べたい場合は、llama.cpp を直接使うと --split-mode で方式を指定できます。ただし llama.cpp は Ollama のような単一バイナリ配布ではないため、公式リリースページから CUDA 対応ビルドを入手するか、CUDA を有効にしてビルドしておく必要があります（CPU専用ビルドだと分割の比較になりません）。またテンソル並列は実験的機能で、Flash Attention前提・自動フィット非対応です。KVキャッシュは量子化形式（q8_0・q4_0など）が非対応で、f32・f16・bf16などの非量子化形式を使います（今回の実測はf16）。

# レイヤー／パイプライン分割（llama.cppの既定）
llama-cli -m model.gguf -ngl all -sm layer -p "テスト"

# テンソル並列（実験的・Flash Attention必須・今回はKVをf16指定）
llama-cli -m model.gguf -ngl all -sm tensor -fa on -ctk f16 -ctv f16 -p "テスト"

-ngl all は全層をGPUに載せる指定です（数値でも可）。--split-mode の値やビルドごとの対応は環境で変わるため、llama.cpp公式のmulti-gpuドキュメント（末尾の参考資料）の最新の記載に合わせてください。テンソル並列は自動フィットに対応しないため、メモリに収まらない場合はコンテキスト長などを手動で調整します。

自分のモデルで測って選ぶ

どちらが速いかはモデルの種類（denseかMoEか）と作業内容（生成中心かプロンプト処理中心か）で入れ替わるため、手元のモデルで一度測るのが確実です。llama.cpp付属の llama-bench なら、方式を変えて生成・プロンプト処理の速度をまとめて比較できます。掲載値はいずれも次のコマンド（両モード同条件）で測っています。

# 同条件で分割方式だけ変えて測り比べる（今回の掲載値の条件）
llama-bench -m model.gguf -ngl 99 -sm layer  -fa 1 -ctk f16 -ctv f16 -r 3
llama-bench -m model.gguf -ngl 99 -sm tensor -fa 1 -ctk f16 -ctv f16 -r 3

出力される tg（生成）と pp（プロンプト処理）を見比べれば、自分の使い方でどちらが得かが判断できます。両GPUにモデルが分かれて載ったかは nvidia-smi のメモリ使用量で確認できますが、これは「両方に何かが確保された」ことの確認で、正しい分割方式で有効に計算しているかまでは示しません。llama.cpp 起動ログのGPU別バッファー割り当てや split mode の表示も併せて見ると確実です。Ollamaを併用しているなら ollama ps でGPUに載っているかCPUへこぼれているかも読み取れます。

速度が出ないときの見極め手順

2枚にしたのに速くならないときは、当てずっぽうで設定をいじる前に、次の順で切り分けると原因に早く届きます。

まず、モデルが本当に両GPUに分割ロードされているかを確認します。前章のとおり nvidia-smi と起動ログで両方に載っているかを見て、片方だけなら -ngl の層数と配分設定を見直す。ここが崩れていると、そもそも2枚を活かせていません。

次に、分割方式が使い方に合っているかを見ます。1本の会話を速く生成したいのに2枚目が待ちに入っているなら、テンソル並列を試す価値があります（とくにdense系モデル）。逆に、多数リクエストのバッチ処理や、長い入力を一度に読ませる用途が中心なら、レイヤー分割が向く場面があります。上の実測のとおり、正解はモデルと作業内容で入れ替わるため、両方を測って比べるのが近道です。

最後に、一部のレイヤーがCPU側に置かれていないかを見ます。-ngl が足りずGPUに載りきらない層があると、その分はCPUで計算され、速度が大きく落ちます（VRAMとシステムRAM・SSDの役割分担はローカルAIのSSD・メモリ選びで整理）。またコンテキスト長を大きくするとKVキャッシュの確保量が増え、モデルロード時のVRAM不足・GPUに載せられる層数の減少・OOMにつながります。とくにテンソル並列は自動フィットに対応しないため、収まらない場合はコンテキスト長やバッチ設定を手動で調整する必要があります。

ここで扱ったのは速度と容量の観点であって、モデルの出力品質や特定タスクへの適性は別の話です。分割して動いたとして、それがコーディングや事実確認にどれだけ使えるかは、この見極めの範囲外。品質面はご自身のタスクで実際に試して確認してください。

別解＝大容量ユニファイドメモリという選び方

すでに2枚構成で動かしているなら、この節は読み飛ばして構いません。まだハードウェアを決めていない場合の比較材料です。2枚のGPUをプールする方式に対して、もう1つの選択肢が大容量ユニファイドメモリを積んだAPU構成です。GPU間の細いリンクを持たず、1つの共有メモリ空間に大型モデルをまるごと載せる設計。プールとは違う土俵で同じ「1枚に載らない問題」を解こうとするアプローチです。

現行世代では、AMDのRyzen AI Max+ 395がこのタイプの代表例で、128GBのユニファイドメモリを搭載します（ただしGPUが利用できる量は製品・BIOS・OS・ランタイム設定に依存し、128GB全部がGPU用になるとは限りません）。CPU・GPUが同じメモリ空間を共有するため、ディスクリートGPUを2枚つなぐときのリンク帯域の問題がそもそも発生しません。さらに大容量の後継として、最大192GBのユニファイドメモリ（LPDDR5X-8533）を積むRyzen AI Max+ PRO 495も控えています。AMDが2026年5月に正式発表済み（コードネームGorgon Halo）で、HP・LenovoなどのOEMから2026年第3四半期の投入が予定されていますが、実際の店頭販売の時期は各OEMの発表を確認してください。

ユニファイドメモリ方式の利点は、リンク帯域を気にせず巨大なモデルを1つのメモリに載せられること。一方でトレードオフもあります。共有メモリの帯域はディスクリートGPUのGDDR7ほど広くなく、演算性能もハイエンドGPUとは性格が異なる。つまり「容量は稼げるが、GPU内部のVRAM帯域や演算力では専用GPUに譲る」構図です。

どちらが向くかは用途で分かれます。すでにGPUを1枚持っていて、容量だけ足したい・段階的に拡張したいなら2枚プール。演算力より容量最優先で、超大型モデルを1台で完結させたいならユニファイドメモリ。手持ちの資産と、動かしたいモデルの規模で選ぶのが現実的な判断です。

まとめ

整理すると、RTX 5080＋RTX 5060 Ti を PCIe 4.0 x4 の OCuLink 構成で接続し、今回のllama.cppビルドと2モデルを単一ストリームで測ったところ、dense 32Bのデコードではテンソル並列がレイヤー分割より約32%速く（25.6→33.7 tok/s）、一方プロンプト処理では14〜16%遅くなりました。「細いOCuLinkだからGPU間通信の多いテンソル並列は不利」という直感は、少なくとも今回の単一ストリーム生成では覆ったことになります。この結果はテンソル並列がインターコネクトに敏感という公式の機構と整合しますが、x16接続などとの比較はしておらず、低下量のすべてをOCuLinkだけを原因として分離した実測ではありません。

選び方は用途で分かれます。単一会話の生成レイテンシ重視ならテンソル並列を試す（llama.cppで指定・今回確認したOllamaではtensorを選ぶ公開設定なし・LM Studio 0.4.15+はGUI可）、多数リクエストやバッチのスループット重視ならレイヤー分割が有利な可能性、長いプロンプトの処理重視なら今回の構成ではレイヤー分割が速い、という3軸です。MoEのように毎回動く部分が小さいモデルでは差が出にくく、テンソル並列は実験的機能で環境差も出やすいため、最後は手元のモデルで llama-bench を回して確かめるのが確実です。

品質や用途適性は速度とは別問題で、各自のタスクで試すのが次のステップ。まず設定したら nvidia-smi と起動ログで、両GPUにモデルが載り、狙った分割方式で動いているかを最初に確かめてください。

よくある質問

Q. OCuLinkは帯域が細いので、GPU間通信の多いテンソル並列は避けるべきですか？

今回実測した2モデル（dense 32B・MoE 35B-A3B）の単一ストリーム生成では、避ける理由は見当たりませんでした。むしろdense 32Bではテンソル並列がレイヤー分割の約1.3倍。デコードでは一度に扱うトークン数が少なく、今回の環境ではGPU間通信のコストより、両GPUを並列に動かす利得が上回ったためです（通信量そのものを直接測った結果ではありません）。プロンプト処理ではテンソル並列が14〜16%遅くなり、リンク帯域やGPU間通信経路の制約が表れた可能性と整合しました。ただしx16接続との比較や通信量の直接測定はしていないため、この差をOCuLinkだけの影響として分離した結果ではありません。生成中心か入力処理中心か、また単発かバッチかで選ぶのが実際的です。

Q. Ollamaでテンソル並列は使えますか？

今回確認したOllamaではレイヤー分割で動作し、テンソル並列を選ぶ公開設定は確認できませんでした。LM Studioは0.4.15（2026年5月）以降、設定画面からテンソル並列を選べます。より細かく制御したい・自分で測りたい場合は llama.cpp を直接使い --split-mode tensor を指定します（実験的機能・Flash Attention前提）。速度がどちらで得かはモデルと用途で変わるため、llama-bench で両方を測って比べるのが確実です。

Q. OCuLinkでつなぐ2枚目のGPUの電源はどう用意すればいいですか？

2枚目GPUには独立した電力供給を確保してください。eGPUドックや別系統の電源から給電する構成では、GPU負荷時に電力が足りないと動作が不安定になります。主GPUと2枚目の合計消費電力に対し、電源系統に余裕があるかを先に確認しておくと安全です。

Q. VRAM 16GB×2枚は、32GBのGPU1枚と同じように使えますか？

容量は近づきますが同じではありません。2枚に分けると各GPUは自分のVRAM内部帯域（5060 Tiで約448GB/s、5080で約960GB/s）で計算し、レイヤーの境目やテンソル並列の集約だけはGPU間リンク（今回は約8GB/s級）を通ります。1枚32GBならこの通信自体が発生せず、同程度以上の演算性能とVRAM帯域を持つ32GB GPUなら、単一の会話を1本ずつ生成する用途ではGPU間通信がないぶん有利になりやすい（ただし実速度は1枚側GPUの演算性能とメモリ帯域にも左右されます）。本稿でテンソル並列が速いという結果は、あくまで2枚構成の中でレイヤー分割と比べた話で、1枚32GBと比べたものではありません。2枚構成の利点は生成速度そのものより、容量・コスト・段階的に拡張できる点にあります。

参考資料

• NVIDIA公式: GeForce RTX 5080 製品仕様
• Intel Newsroom: Memory Bandwidth May Be the Most Overlooked AI Performance Metric（Srini Krishna）
• llama.cpp 公式ドキュメント: Multi-GPU（split-mode の説明）
• AMD公式ブログ: Ryzen AI Max PRO 400 シリーズ発表（2026年5月）

同じOCuLink構成でレイヤー分割とテンソル並列を比べた例として、Muse Glimmer 30BをVRAM 16GBで動かす もある。