ローカル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枚にするか

2枚目で増えるのは、まず載せられる量です。使いたいモデルが1枚に収まっているなら、2枚目を足しても、既定の分け方では、速いほうのカード1枚で動かすより速くはなりません。当サイトのRTX 5080とRTX 5060 Ti 16GB（OCuLink接続）で、1枚と2枚を測り比べた値を並べます。

モデルごとに測り方が違います。14B級の2本はOllama（文脈長は既定のまま。1枚と2枚は計測日もOllamaの版も違う）、Qwen3.8-27Bはllama.cpp b10356のllama-bench（1枚と2枚を同じ版・同じ設定で測った値）、27〜32B級のDenseと30〜35B級のMoEはOllama 0.32.3・文脈8,192で、1枚と2枚を同じ設定で測った値です（計測日は分かれています）。比べられるのは同じモデルの1枚と2枚だけで、モデルをまたいで速さを比べることはできません。

測った範囲では、分かれ目はモデルと文脈の枠を合わせた量が、1枚の空きに収まるかどうかでした（空きは16GBより小さく、画面出力に使うカードではさらに減ります）。収まるなら、2枚にしても速いほうの1枚を上回らず、Qwen3.8-27BではRTX 5080 1枚より遅くなりました。あふれていた27〜32B級のDenseと30〜35B級のMoEでは、2枚にすると1枚の約2.2〜3.5倍に上がりました。ただし1枚と2枚では容量だけでなく演算資源やメモリ帯域も同時に変わるので、速さの差を「全部載ったこと」だけの効果とは言い切れません。32GBでも収まらない大きさ（70B級など）は、2枚にしても全部は載りません。

同じモデルでも、文脈の枠を広げれば1枚からあふれます。表と同じQwen3.8-27B（UD-Q3_K_XL）をllama-serverで起動すると、RTX 5060 Ti 1枚では文脈の枠を4,096から65,536へ広げただけで、29.02 tok/sから7.67 tok/sに落ちました。2枚に分けた構成は、262,144の枠でも35.32 tok/sで回っています（この枠では、起動時に2枚目のバッファ確保に一度失敗し、小さく取り直して起動しました）。どちらも枠を確保しただけで、長文を実際に流した測定ではありません。量子化を上げたUD-IQ4_XSとUD-Q4_K_Mは、2枚でも262,144の枠では起動しませんでした。この段落の値は、起動時に文脈の枠を確保して測ったもので、表のQwen3.8-27Bの値（llama-bench）とは測り方が違います。

RTX 5060 Tiを2枚そろえる構成は、当サイトでは測っていません。載せられる量は合計32GBで同じ目安ですが、表で2枚に分けて載せたモデル（Qwen3.8-27B、27〜32B級のDense、30〜35B級のMoE）の速さは、表の2枚の値より下がると見ています。Ollamaやllama.cppの既定の分け方（層単位）では、1本の会話を生成するあいだ2枚が順番に計算するので、表の構成でRTX 5080が受け持っていた層も、RTX 5060 Tiの速さで進むことになるためです（VRAM帯域はRTX 5080が約960GB/s、RTX 5060 Tiが約448GB/s）。14B級の2本は、Ollamaが1枚に収まると見て分けずに片方だけで動かしたので、RTX 5060 Ti 2枚でもRTX 5060 Ti 1枚の値のままです（llama.cppは、収まるモデルでも既定で2枚に分けます。表のQwen3.8-27Bがその例です）。

モデルの大きさとは別に、LLMを動かしながら画像生成も回したいなら、仕事をカードごとに分けられる2枚が向いています（同時に回したときの速さは、当サイトでは測っていません）。表の値を測った条件の詳しいところは、27〜35B級の5本を1枚と2枚で測った記事、Qwen3.8-27Bを16GBで測った記事、2枚目の効果を用途別に測った記事にあります。ここから先は、2枚に分けると決めたあとの話です。分け方と接続の帯域で速度がどう変わるかを見ていきます。

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枚のGPUを直接つなぐ専用リンクではありません。今回のOCuLinkは5060 Tiとホスト側のPCIeルートを結ぶ区間で、しかも GGML_CUDA_P2P を有効にしていないため、GPU間のコピーはシステムメモリを経由します。実際の経路には、OCuLink側のPCIe区間、ホストブリッジとRAM、5080側のPCIe区間、そして同期処理が含まれます。この経路の太さと、分割方式ごとに「何を・どれだけ」流すかで実際の速度が決まるので、本稿の結果はOCuLink単体ではなく、ホスト側を含む構成全体の結果です。Intelのニュースルーム論説も、AIシステムではアクセラレータの演算性能だけでなく、CPUやアクセラレータへデータを十分な速さで供給できるかが重要だと指摘しています。ただし同記事が主に扱うのはXeonのホストメモリ帯域で、本稿が比較するGPU内のVRAM帯域やGPU間のPCIeリンク（今回のOCuLinkで約8GB/s級）とは別の経路です。共通するのは、演算器だけでなくデータ移動の経路もボトルネックになり得る、という点です。

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

OCuLink は、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）を確認してください。このときCurrentとMaxを区別します。NVIDIAの公式ドキュメントはCurrentの世代・幅について「GPUを使っていないときは下がることがある」と書いているので、アイドルのまま読むとGen1などを実力と取り違えます。負荷をかけている最中のCurrentを見てください。2枚目を物理スロットへ直挿ししている場合も考え方は同じで、表のOCuLink行を自分のスロットの帯域に置き換えて同じように並べれば、見方は使えます。ただし開きの大きさは変わります。今回ほど極端な差になるとは限らないので、置き換えた行で自分の比を見てください。ただしこのあとの実測値はPCIe 4.0 x4での結果で、より広いリンクでは特にプロンプト処理の差が縮む可能性があります（本稿はx16との比較をしていません）。

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

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

モデルを2枚に分ける方式には大きくレイヤー分割とテンソル並列があります。RTX 5080 + RTX 5060 Ti（OCuLink）の実機で、16GBに収まらない2種類のモデルを両方式で測った結果が次の表です。生成（デコード＝1トークンずつ出力する速度）とプロンプト処理（入力をまとめて読む速度）を分けて示します。いずれも同時に流すリクエストが1本だけの状態で測っています。ただし pp と tg は llama-bench の別々のマイクロベンチで、512トークン入れてから128トークン返す1回の応答を測ったものではありません（その形で測るには -pg を使います）。

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

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

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

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

テンソル並列は仕様上、1つの層を両GPUで分担する

テンソル並列は、1つのレイヤーの計算そのものを2枚で分担する方式です。公式の仕様上は同じ層を両GPUが並行して計算し、その都度おたがいの結果を突き合わせて（集約して）次へ進みます。今回の dense 32B では、その並行処理や、2枚のローカルVRAMから重みを同時に読めたことによる利益が、通信と同期のコストを上回った可能性があります。ただしGPU使用率もメモリ帯域もPCIe転送量もカーネル時間も同期待ちも測っていないので、速くなった原因は特定していません。逆にMoE 35B-A3Bでは方式間の差が -2.4%（2.8 tok/s）でした。llama-bench が出した3回の標準偏差はレイヤー分割 ±0.64／テンソル並列 ±2.48で、差はテンソル並列側のばらつきと同じ桁です。3回ずつしか回していないので、この差が方式によるものかどうかは判断できません。毎回動くパラメータが約3Bと少ないことが関係している可能性はありますが、ハイブリッド構造や通信処理、異種GPU構成の影響も混ざるため、原因を一つに絞ることはできません。そもそもこの2本は世代も量子化も構造も違うので、「denseだから」「MoEだから」と読める比較にはなっていません。

テンソル並列は、レイヤーごとにGPU間の集約（リダクション）を複数回行うため、公式の機構上もインターコネクトの帯域やレイテンシの影響を受けやすいとされます。デコードでは一度に扱うトークン数が少なく、今回の結果は、GPU間通信のぶんを含めてもテンソル並列のほうが総処理時間が短かったことを示しています。ただし通信量もリンク利用率も同期待ちも直接は測っていないので、差の内訳までは分かりません。一方512トークン入力のプロンプト処理では、入力の多数トークンを一度に流すぶん集約するデータ量も増え、テンソル並列がレイヤー分割より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枚で消費電力も測った——denseでは中央値が倍以上違うが、観測された最大値は下がらない

上の速度表は2026年7月に測ったもので、このときはGPU側の観測（電力・温度）を記録していませんでした。2026年9月9日に同じ2枚・同じ設定で測り直し、実行中のボード電力を記録したのが次の表です（7月は -p と -n を既定値に任せていたので、9月は同じ pp512・tg128 を明示して指定しています）。中央値と最大値を分けて示します。

目につくのは、denseのレイヤー分割だけが2枚の中央値の和で225Wと突出し、残る3条件は84〜89Wに収まったことです。dense 32Bでは、この回も生成はテンソル並列のほうが速く、そのうえで電力の中央値は低く出ています。MoE 35B-A3Bのほうはレイヤー分割84W対テンソル並列86Wで、方式を変えてもほとんど動きませんでした。

ただしここから「テンソル並列のほうが省電力」と読むのは早計です。denseの最大値で見ると、5080側はレイヤー分割177W対テンソル並列177Wでほぼ同じ、5060 Ti側はむしろテンソル並列のほうが高く（レイヤー分割130W対テンソル並列147W）なりました。中央値が下がったのは窓の中で電力の低い時間帯が長かったということで、観測された最大値そのものは下がっていません。そしてこの表の最大値を、電源容量の見積もりにそのまま使わないでください。これは今回のllama-benchで拾えた範囲の上限であって、カードの定格（TGP）でも瞬間の上限でもありません。NVIDIAの公表値はRTX 5080が360W、RTX 5060 Ti 16GBが180Wで、今回の観測最大はそれぞれの約49%・約82%にあたります。乖離の幅が2枚で揃っていないので、表の最大値を何倍かして電源を見積もる、という使い方もできません。電源の余裕を考えるときに問題になるミリ秒級のスパイクも、1秒平均を読んでいるこの測り方では拾えず、2枚のピークが同じ瞬間に出た保証もありません。電源はカードの定格とドックの仕様から見積もるもので、このあと触れる電源の確認も、実測表の値ではなく定格に基づく話です。分割方式を変えても省けません。

なお、前の項に書いた「テンソル並列は1つの層を両GPUで分担するので手空きが減る」という仕様上の像からは、電力はむしろ上がりそうに見えます。今回の中央値は、denseではその逆に出ました（MoEでは方式による差がほとんどありません）。GPU間の集約待ちで両方が止まっている時間が長いのか、それとも、ロードを含むこの窓のうち実際に計算していた時間が半分を割り、中央値が低いほう（ロード中の水準）へ落ちただけなのか、この測定からは分けられません。観測として出すにとどめ、原因を一つに決めることはしていません。

留保は2つあります。ひとつは、サンプリングの窓が推論の区間だけを切り出したものではなく、モデルのロードからプロンプト処理・生成までを含む走行全体だということ。窓の長さも条件ごとに違うので、ここでの中央値は「推論中の平均消費電力」ではなく、走行全体の窓で採ったサンプルを値の順に並べたときの中央値です。もうひとつは、各条件とも1走行ぶんの観測であること（-r 3 は推論の繰り返し回数で、電力を3回測り直したわけではありません）。合計欄も各GPUの中央値を足したもので、同じ瞬間の2枚合計を測った値でも、ワットチェッカーで測ったシステム全体の消費電力でもありません。

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

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

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

Ollamaの公式FAQは「1枚に収まるなら、そのGPUへ載せる。PCIバスを越えるデータが減るぶん、たいていはこれが一番速い。収まらないなら、使えるGPUへ分散する」と説明しています。ただしレイヤー分割とテンソル並列を利用者が選ぶ設定は見当たりません（2026年9月16日に確認。手元のOllamaはv0.32.11）。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前提・自動フィット非対応です。加えて全アーキテクチャに実装されているわけではなく、未対応のモデルでは LLAMA_SPLIT_MODE_TENSOR not implemented for architecture というエラーで止まります。設定ミスと区別がつきにくいので、そのときはレイヤー分割に戻してください。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 なら、方式を変えて生成・プロンプト処理の速度をまとめて比較できます。上の速度表は次のコマンド（両モード同条件）で測っています（9月の電力表の走行だけは、同じ pp512・tg128 を明示指定しています）。

# 分割方式を変えて測り比べる（今回の掲載値の条件）
# --tensor-split は未指定なので、方式を変えると2枚への配分規則も変わる（layer=搭載メモリ比例／tensor=均等）
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枚目が待ちに入っているなら、テンソル並列を試す価値があります（今回大きく伸びたのは Qwen3-32B Q4_K_M の1ファイルで、dense系一般の話ではありません）。逆に、多数リクエストのバッチ処理が中心なら、レイヤー分割が向く場面があります（公式の位置づけもパイプライン分割＝バッチのスループット向けです）。一度に読ませる入力が長い用途は今回測っていないので、512トークンで見えた差がそのまま伸びるかは分かりません。上の実測のとおり、正解はモデルと作業内容で入れ替わるため、両方を測って比べるのが近道です。

最後に、一部のレイヤーが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のユニファイドメモリに対応します（何GB載るかは製品次第で、型番だけで128GBが決まるわけではありません。さらにGPUが利用できる量は製品・BIOS・OS・ランタイム設定に依存し、128GB全部がGPU用になるとは限りません）。CPU・GPUが同じメモリ空間を共有するため、ディスクリートGPUを2枚つなぐときのGPU間PCIe転送は発生しません（共有メモリ自体の帯域という制約は残ります）。さらに後発の大容量モデルとして、Ryzen AI Max PRO 400シリーズに、最大192GBのユニファイドメモリ（LPDDR5X-8533）に対応するRyzen AI Max+ PRO 495があります（395は Ryzen AI Max 300シリーズで、AMDが直接の後継として並べているわけではありません）。AMDが2026年5月に正式発表済み（コードネームGorgon Halo）です。搭載機の最大メモリも販売時期もOEM・製品ごとに違うので、買う前にその機種が何GBまで載るのかを個別に確認してください。

ユニファイドメモリ方式の利点は、リンク帯域を気にせず巨大なモデルを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）、一方512トークン入力のプロンプト処理では14〜16%遅くなりました（それより長い入力は測っていません）。「細いOCuLinkだからGPU間通信の多いテンソル並列は不利」という直感は、少なくとも今回の単一ストリーム生成では覆ったことになります。このうちプロンプト処理の低下は、テンソル並列がインターコネクトに敏感という公式の機構と整合しますが、x16接続などとの比較はしておらず、低下量のすべてをOCuLinkだけを原因として分離した実測ではありません。

選び方は用途で分かれます。単一ストリームのデコード重視ならテンソル並列を試す（llama.cppで指定・Ollamaには方式を選ぶ公開設定が見当たらない（2026年9月16日時点・v0.32.11）・LM Studio 0.4.15+は対応あり）、多数リクエストやバッチのスループット重視ならレイヤー分割が有利な可能性、512トークンぶんのプロンプト処理なら今回の構成ではレイヤー分割が速い、という3軸です。ただし今回測ったのはコンテキスト深度0・pp512・tg128での処理速度で、llama-benchの数値にはトークナイズとサンプリングの時間が入りません。長い入力、初トークンまでの時間、会話全体の応答時間は測っていないので、そこは自分の使い方で確かめてください。今回のMoEでは方式間の差が3回のばらつきと同じ桁で判断がつかず、テンソル並列は実験的機能で環境差も出やすいため、最後は手元のモデルで llama-bench を回して確かめるのが確実です。

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

よくある質問

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

2026年7月に b10092 で測った2モデル（dense 32B・MoE 35B-A3B）の生成では、避ける理由は見当たりませんでした。ただしテンソル並列は公式にも実験的な位置づけで、現行の公開ビルドは当時から900以上進んでいます。いまの環境で同じ結果になるかは、測ってみないと分かりません。むしろdense 32Bではテンソル並列がレイヤー分割の約1.3倍。デコードでは一度に扱うトークン数が少なく、GPU間通信のぶんを含めてもテンソル並列のほうが総処理時間が短く出ました（通信量や同期待ちを直接測っていないので、差の内訳は特定していません）。512トークン入力のプロンプト処理ではテンソル並列が14〜16%遅くなり、リンク帯域やGPU間通信経路の制約が表れた可能性と整合しました（長い入力は測っていません）。ただしx16接続との比較や通信量の直接測定はしていないため、この差をOCuLinkだけの影響として分離した結果ではありません。生成中心か入力処理中心か、また単発かバッチかで選ぶのが実際的です。

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

2026年9月時点のOllama公式FAQは、1枚に収まるならそのGPUへ載せ（PCIバスを越えるデータが減るので通常はこれが最速）、収まらないなら使えるGPUへ分散する、と説明しています。分割方式を選ぶ設定は書かれていません（手元のOllamaはv0.32.11）。LM Studioは0.4.15（2026年5月）でCUDAのテンソル並列に対応しています（設定画面での指定方法は確かめていません）。より細かく制御したい・自分で測りたい場合は llama.cpp を直接使い --split-mode tensor を指定します（実験的機能・Flash Attention前提）。速度がどちらで得かはモデルと用途で変わるため、llama-bench で両方を測って比べるのが確実です。

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

2枚目GPUには独立した電力供給を確保してください。eGPUドックや別系統の電源から給電する構成では、GPU負荷時に電力が足りないと動作が不安定になります。電源に余裕があるかを先に確認しておくと安全です。ただし2枚の定格（RTX 5080が360W、RTX 5060 Ti 16GBが180W）を足した値が、そのままシステム全体の電源要件になるわけではありません。NVIDIAは製品ごとに推奨システム電源も示していて、RTX 5080が850W、RTX 5060 Ti 16GBが600Wです。これとコネクタの定格、ドックの仕様に合わせて選んでください。本文の実測表の最大値は使いません。あの表はllama-benchの走行中に拾えた範囲の上限です。

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

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

参考資料

• NVIDIA公式: GeForce RTX 5080 製品仕様
• Intel Newsroom: Memory Bandwidth May Be the Most Overlooked AI Performance Metric（Srini Krishna）
• llama.cpp 公式ドキュメント: Multi-GPU（split-mode の説明・実測したb10092時点）
• llama.cpp 公式ドキュメント: llama-bench（引数の既定値と、計測にトークナイズ・サンプリングを含まない旨・実測したb10092時点）
• NVIDIA公式: GeForce RTX 5060 ファミリー 製品仕様
• NVIDIA公式: nvidia-smi ドキュメント（電力の読みとPCIeリンクのCurrent／Max）
• Ollama公式: FAQ（複数GPUへの分散）
• AMD公式ブログ: Ryzen AI Max PRO 400 シリーズ発表（2026年5月）

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

同じ2枚構成で27〜35B級のモデルを5本測り、1枚であふれたときと全部載せたときの速度を並べた結果はVRAM 32GBで何が変わるかで扱っている。