AI用途にGPUは2枚必要か｜RTX 5080 + 5060 Ti + OCuLink外付けで2枚目の効果を実測

Ollamaを既定設定で使う構成では、AI用途の2枚目GPUは計算を並列化して速くする手段ではなく、VRAM容量と同時実行を増やす手段になる。

単体16GBに収まりきっているモデルなら、2枚目のGPUを足しても生成速度は上がりません。Ollamaの既定では、1枚に収まるサイズのモデルはそもそも2枚に分かれず、どちらか片方のカードだけで動くからです。llama.cppを直接設定して収まるモデルをあえて分割した場合にどうなるかは、本記事では測っていません。当サイトの検証環境では外付け側の遅いカードが選ばれる場面があり、その場合は単体より遅くなりました。それでも2枚化に意味があるのは、単体では載らない大きいモデルが動くようになり、LLM推論と画像生成のように別々の処理を同時に回せるようになるからです。この記事では、RTX 5080にRTX 5060 TiをOCuLink外付けで足した実機構成で、その「速くはならないが載る・同時にこなせる」という2枚目の効果を、当サイトの検証環境の数値で確かめていきます。基礎知識から接続構成、推論エンジンごとの帯域の効き方、そして実測データまで、AI用途でGPUを2枚にすべきか迷う読者が、用途に応じて判断できるところまで一本で扱います。

AI用途でGPU2枚は「必要」なのか — 結論から

「必要かどうか」は用途で割れます。ChatGPTやClaudeをブラウザやAPIで使うだけなら、そもそも高性能なGPUは要りません。ローカルで8Bや14Bクラスのモデルを1つ動かす程度なら、VRAM 16GBの単体GPUで足ります。ここに2枚目を足しても、体感が大きく変わることは少ないでしょう。

一方で、単体16GBには収まらない大きめのモデルを動かしたい、あるいはLLMの推論を回しながら別のGPUで画像生成も並行させたい、という段階に入ると話が変わります。ここで2枚目がはじめて効いてきます。効き方は「速くなる」ではなく「載る」「同時に回せる」という方向です。

産業全体のトレンドも、AI性能を伸ばす方向はGPUとVRAMの積み増しに向かっています。HP Z8 Fury G6iのようなプロ向けAIワークステーションは、1基のXeonに最大4枚のNVIDIA RTX PRO 6000 Blackwell Max-Qを組み合わせ、合計384GBという桁違いのVRAMに到達します。数百GB級のVRAMを1筐体に詰め込むのは、大きなモデルを丸ごと載せ、複数の処理を同時にさばくため。加えて、テンソル並列やパイプライン並列、学習、推論サーバーの多重化といった目的も企業側にはあります。個人がこの規模を再現するのは非現実的ですが、容量と同時実行のためにGPUを足すという一点は、個人の2枚化とも重なります。

単体16GBで足りる用途／2枚目が効く用途の線引き

単体16GBで足りるのは、次のような使い方です。8B前後のモデルでチャットやコード補完を回す。SDXLやそれに近い画像生成を1枚ずつ生成する。API経由のクラウドLLMを使い、ローカルGPUは補助的にしか使わない。こうした用途では、GPUのVRAMが枯渇せず処理が1つで完結するため、2枚目の出番がありません。

2枚目が効いてくるのは、VRAMが足りなくなった瞬間からです。量子化しても16GBに収まらない大型モデルを動かしたい。長い文脈を扱ってKVキャッシュ（会話履歴の途中計算をVRAMに保持する領域）が膨らみ、あふれてしまう。あるいはLLMサーバーを常駐させたまま、別途ComfyUIで画像生成も走らせたい。片方のGPUが手一杯のとき、もう1枚あれば処理を逃がせます。ここが分岐点です。用途がどちら側にあるかを見極めれば、2枚目を買うべきかの判断はかなりはっきりします。

2枚化の効果を3つに分ける（載る・同時実行・速くする）

2枚目の話が噛み合わないのは、「速くなる」「容量が増える」「同時にできる」がひとまとめに語られるからです。この3つを分けて考えると、2枚化の実像がくっきりします。

1つ目は「載る」。VRAMは各GPUに物理的に分かれていますが、レイヤー分割という方式を使えば、モデルの前半の層を1枚目に、後半の層を2枚目に置いて、単体では収まらないサイズのモデルを動かせます。RTX 5080（16GB）とRTX 5060 Ti（16GB）を組み合わせれば、レイヤー分割で層を各GPUに振り分けることで、物理VRAMの合計は16GB×2＝32GBですが、これは単一のプールではありません。表示やランタイム、KVキャッシュにも使われるため、モデルに回せる実容量は32GBより小さくなります。実際の上限はモデル構造・分割の粒度・文脈長・各GPUの空きで変わります。ここで注意したいのが、これは各GPU個別に16GBが2枚あるという意味で、1枚で32GBを持つGPUとは別物だという点。モデルは層ごとに分かれて各GPUに載るだけで、2枚のVRAMがGPUをまたぐ一つの「プール」になるわけではありません。

2つ目は「同時実行」。2枚あれば、1枚目でLLM推論を回しながら、2枚目で画像生成を走らせる、といった別々のワークロードを並行してさばけます。合計のスループット（単位時間あたりの処理量）を稼ぐ使い方です。1枚でもVRAMとソフトウェアが許せば同時に走らせること自体はできますが、2枚あれば別々のGPUへ固定してVRAMの取り合いを減らせます。なお当サイトは同時実行時の合計スループットや待ち時間を測っていないため、改善幅は未評価です。

3つ目が「速くする」。ここが誤解されやすいところです。まず、1枚に収まるサイズのモデルはそもそも2枚に分かれません。Ollamaは収まるなら片方のカードにまとめて載せるため、もう1枚は待機したままです。分割が起きるのは1枚に収まらないモデルだけで、その場合もレイヤー分割では処理がバケツリレーのように進むため、片方が計算している間もう片方は待っています。どちらにしても、単一生成の速度は足し算になりません。すでに単体でGPUに載りきっているモデルの単一生成を、2枚目で速くすることはできません（単体であふれている場合だけは、GPUに載りきることで結果的に速くなります＝後述の実測②）。prefillやバッチのように多数のトークンをまとめて処理する場面のスループットは別の話で、本記事では測っていません。

なぜ「2枚=2倍速」にならないのか（分割方式で挙動が変わる）

GPUを2枚使う分け方には、大きく「レイヤー分割」と「テンソル並列」の2種類があります。挙動がまったく違うため、どちらを使うかで2枚目の意味も別物です。

レイヤー分割は、モデルの層をグループに分けて各GPUに配置します。トークンを1つ生成するとき、データは1枚目の層を通ってから2枚目の層へ渡り、そこを通り終えて結果が出ます。パイプライン（流れ作業）のように直列で処理が進むため、2枚目が計算しているとき1枚目は次の入力を待っている、という構図になります。1つのトークンを生成する経路としては直列なので、単一の生成を2枚で分担して2倍にする方式ではありません。ただしllama.cppはこの分割をパイプライン並列と位置づけており、プロンプトのprefillやバッチのように多数のトークンをまとめて処理する場面ではスループット側に効きます。1リクエストであっても、長いプロンプトの読み込みならこちらに当たります。本記事が測ったのは1シーケンスの生成（decode）速度なので、以降の「速くならない」はその範囲の話です。なお、Ollamaの既定ではこの分割が起きるのはモデルが1枚に収まらないときだけです。収まるモデルは分割されず片方のカードだけで動くので、層をまたぐオーバーヘッドはそもそも発生しません（環境変数 OLLAMA_SCHED_SPREAD を指定すれば、収まるモデルでも全GPUへ広げられます）。

テンソル並列は、1つの層の計算そのものを2枚で分担します。理屈上は並列に計算できて速くなりますが、層ごとにGPU同士が計算結果をつき合わせる通信（all-reduce）が発生し、その通信量が膨大です。これを支えるには非常に太いGPU間接続が要ります。GPU間の帯域が太いほど有利な方式で、データセンター向けのNVLinkがその代表です（H100世代の第4世代NVLinkで双方向900GB/s。世代が上がるとさらに増えます）。後述するようにOCuLink外付けの狭い帯域とは相性が良くありません。

つまり、すでにGPUに載りきっているモデルの単一生成を複数GPUで並列化してレイテンシを縮める代表的な方式が、テンソル並列です。ただしGPU間通信が多く、OCuLink x4のような低帯域接続では通信ボトルネックになりやすいため、この構成の主目的には向きません。後述の実測②で出る2倍前後は、計算の並列化ではなくCPUオフロードが消えたことによる回復で、原因が別です。だからOCuLink構成で個人が2枚化する場合、狙うのは速度ではなく容量と同時実行になる、というのがこの記事の骨格です。

OCuLink外付け（DEG1）で2枚目をつなぐ構成

2枚目を内蔵スロットに挿せない場合の選択肢が、OCuLinkによる外付けです。OCuLinkはPCIe 4.0 x4の信号を外部に引き出す規格で、Minisforumの表記ではリンク速度が最大64GT/s。PCIe 4.0 x4の理論上のデータ帯域は、片方向で約8GB/sです。マザーボード上のM.2スロットやOCuLinkポートから信号を取り、外付けのGPUドックへつなぐ形です。

当サイトの検証環境では、Minisforum DEG1という外付けGPUドックを使っています。DEG1はOCuLink 4i（PCIe 4.0 x4）のアップリンクとPCIe x16スロットを備え、GPUの電源はATXまたはSFX電源を別途つなぐ構成です。実売はおよそ109〜139ドルで、比較的安価に2枚目の置き場所を用意できます。検証機の電源は、メイン850WとOCuLink側専用750Wの2系統を独立させています。GPU負荷時に電力が足りないとPCが落ちるため、外付け側にも余裕のある電源を割り当てるのが安全策です。

接続後は、2枚目が正しく認識されているかを確認します。Windows・Linuxとも、まずはnvidia-smiでGPUが2基見えているかをチェックするのが基本です。

# GPUが2基認識されているか確認
nvidia-smi --query-gpu=index,name,memory.total --format=csv

# 出力例（2基が見えていればOK）
# index, name,                  memory.total
# 0,     NVIDIA GeForce RTX 5080,   16384 MiB
# 1,     NVIDIA GeForce RTX 5060 Ti, 16384 MiB

モデル全体がGPUに載ったかはOllamaの稼働状態で、どのカードに載ったかはnvidia-smiで確認します。

# モデル全体がGPUに載ったかを確認（PROCESSOR 列が 100% GPU かどうか）
# ※古い版では部分オフロード時の比率表示がずれることがあるため、その版の値は割り引いて見る
ollama ps

# どのカードに載ったかは ollama ps では分からない。
# モデルを読み込む前後で nvidia-smi の memory.used を比べ、増えたカードを見る
nvidia-smi --query-gpu=index,name,memory.used --format=csv

OCuLinkはThunderbolt経由の外付けと比べると中間コントローラが少なく、一般にプロトコルのオーバーヘッドを抑えやすい点が利点です。準ダイレクトなPCIe接続として扱えます。ただし帯域そのものは内蔵のPCIe x16より狭い。この「狭さ」が何にとって問題になり、何にとって問題にならないのかを次章で切り分けます。

OCuLink x4の帯域が問題になる場面・ならない場面

帯域8GB/sという数字だけを見ると心もとなく映りますが、効くかどうかは「GPU間でどれだけデータをやり取りするか」で決まります。

問題になりにくいのは、モデルのロードとレイヤー分割推論です。モデルをVRAMに読み込むときは一度だけ大きなデータが流れますが、これは起動時の一過性のコスト。推論中に層をまたいで転送されるのは、各トークンの中間データ（活性値）だけで、モデルの重み全体を毎回やり取りするわけではありません。転送量は活性値のぶんに限られる（その大きさはモデルやバッチ、文脈長で変わります）ため、8GB/sの帯域でも詰まりにくいのです。

問題になりやすいのは、テンソル並列と学習です。テンソル並列は層ごとに大量の通信が走り、学習では勾配（モデルを更新するための微分値）を頻繁にやり取りします。どちらもGPU間の通信量が桁違いに多く、x4の帯域では通信待ちがボトルネックになりかねません。同じ2枚構成でも、レイヤー分割推論なら帯域の狭さはほぼ表面化せず、テンソル並列や学習なら表面化する。用途によって帯域の効き方が正反対になるのがOCuLink外付けの勘所です。

レイヤー分割推論（llama.cpp/Ollama）は帯域に鈍感

ローカルでLLMを動かす人の多くが使うllama.cppやOllamaは、既定の多GPUモードがレイヤー分割です。これがOCuLink外付けと相性が良い理由を、もう少し掘り下げます。

レイヤー分割では、モデルの各層をGPUに順番に割り当てます。たとえば前半の層をRTX 5080に、後半の層をRTX 5060 Tiに置く。トークン生成のとき、データは5080側の層を通過し、その出力が5060 Ti側へ転送されて、残りの層を通って結果になります。外付けの5060 Ti側ではPCIe 4.0 x4のOCuLink区間を通りますが、GPU間の実際の転送経路はPCIeトポロジやCUDA P2Pの可否によって変わります（llama.cppのCUDA P2Pは GGML_CUDA_P2P=1 で明示的に有効化するopt-inで、無効ならシステムメモリを経由します）。ここで転送されるのは層の境界の活性値のみで、モデルの重み（パラメータ本体）はGPU間を移動しません。重みは最初に各GPUのVRAMへ配置されたまま動かないので、推論中の転送量は活性値のぶんだけに抑えられます。

この転送量の小ささが、帯域の狭さを吸収します。llama.cppの多GPUドキュメントも、レイヤー分割（layer）を低速なインターコネクトでも許容できる方式として位置づけています。同時に、この方式はパイプライン並列として複数トークンを扱う場面ではスループット側にスケールするとも説明されており、「速くできない方式」という意味ではありません。単一の生成が速くならない、という本記事の範囲と混同しないでください。

転送量がこれだけ小さいなら、単一生成の速度についてはGPU間の接続を太くしても効き幅は限られる、という理屈になります（prefillやバッチのように多数のトークンを処理する場面では、前述のとおりスループット側に効きます）。ただし当サイトは、同じ2枚構成でリンク幅だけを変えた対照測定を行っていません。OCuLink x4が実用に足ると判断しているのは、この機構の説明と、後半の実測②で2枚化が正味で効いた結果からであって、x4による損失そのものの大きさは本記事では測っていません。

レイヤー分割で「単体では載らないモデル」が動く仕組み

レイヤー分割のいちばんの恩恵は、速度ではなく容量です。単体16GBには重みが収まらないモデルでも、層を2枚に分けて配置すれば、各GPUの16GBを合わせて置き場所を作れます。単純加算では32GB分の置き場所になりますが、表示やランタイム、KVキャッシュにも消費されるため、モデルと文脈に実際に回せる量はこれより小さくなります。

ここで起きるのは、CPUオフロードの回避です。VRAMに収まりきらないモデルを単体GPUで無理に動かすと、あふれた部分（モデルの一部の層やKVキャッシュ）はシステムRAM（CPU側のメモリ）へ逃がされ、その計算をCPUが肩代わりします。こうしたCPUオフロードが起きると、推論速度が大きく落ちます。GPUに比べてCPUの処理は遅く、しかもデータがGPUとRAMを往復するためです。2枚目を足してVRAMの置き場所を増やせば、このオフロードが解消され、モデルがGPUだけで動くようになります。

つまり「載る」ことは、副次的に「オフロードで遅くなっていた状態から解放される」という速度改善も連れてきます。ただしこれは「2枚で純粋に速くなった」のとは違う。単体であふれていたモデルが、2枚でようやくGPU内に収まった結果です。この現象は、後半の実測②で具体的な数値を確認します。

テンソル並列（vLLM）と学習は別物 — 帯域が効く領域

レイヤー分割が帯域に鈍感なのに対して、テンソル並列と学習は帯域が効く領域です。混同すると「OCuLink外付けでvLLMを回せば速い」という誤った期待につながるため、線引きをはっきりさせます。

vLLMなどが使うテンソル並列は、1つの層の行列計算を複数GPUで分担する方式です。各GPUが担当ぶんを計算したあと、結果を全GPUで突き合わせるall-reduce通信が層ごとに走ります。この通信は頻度も量も多く、GPU間接続が細いと通信待ちで全体が停滞します。vLLMの公式ドキュメントによれば、テンソル並列はPCIe接続でも実行できますが、低帯域の接続では通信コストが性能を制約しうるとされています。NVLinkのない構成では、モデルや負荷によってはパイプライン並列のほうが高いスループットになる場合もあります。双方向合計で揃えると、H100世代のNVLinkがおよそ900GB/s、PCIe 4.0 x16がおよそ63GB/s、OCuLink（PCIe 4.0 x4）がおよそ15.8GB/s。NVLinkとOCuLink x4の差はおよそ57倍あります。ですから、テンソル並列を外付けで回すのは筋が良くないと考えています（当サイトの実測ではなく、帯域の桁差からの判断です）。

学習・ファインチューニングも同様です。勾配の同期でGPU間通信が大量に発生するため、帯域がボトルネックになりやすい。個人がOCuLink外付けの2枚でやるべきは、帯域に鈍感なレイヤー分割推論であって、帯域が効くテンソル並列や本格的な学習は、この構成の得意分野ではありません。断定を避けて言えば、外付けx4でもテンソル並列や小規模な学習が「動かない」わけではなく、帯域が効くために評価軸が別になる、ということです。

個人がOCuLink外付けでやるべきでない用途

外付け2枚で無理をしないほうがいい用途を、あらかじめ整理しておきます。まず、vLLMのテンソル並列で大型モデルの推論スループットを最大化したいケース。これはGPU間の太い接続がある環境でこそ生きる方式で、OCuLink x4では通信がボトルネックになりやすいでしょう。次に、複数GPUをまたいだ本格的な学習・ファインチューニング。勾配同期の通信が帯域を食うため、外付けの狭い帯域では効率が落ちます。

逆に言えば、これら以外のローカルLLM推論（llama.cpp/Ollamaのレイヤー分割）や、GPUごとに別ワークロードを割り当てる同時実行は、外付け2枚の得意分野です。目的が「大きいモデルを載せて推論する」「別々の処理を並行させる」なら外付け2枚が向き、「1モデルをテンソル並列で最速化する」「マルチGPU学習を回す」なら向かない。この線引きを持っておくと、構成選びで迷いません。

実測①｜1枚に収まるモデルは、2枚挿しても片方しか使わない

ここからは当サイトの検証環境の数値で確かめます。検証環境はRTX 5080（16GB）を内蔵、RTX 5060 Ti（16GB）をOCuLink外付けで接続した2枚構成。NVIDIA driver 610.47。Ollamaの版は計測日によって異なり、6月18日が0.30.7、7月5日が0.31.1、7月24日・7月30日・8月14日が0.32.3です。thinkモードは全モデルでthink=falseに統一し、各モデルを3回計測した中央値を採用しています。計測日はモデルごとに異なるため、比較する数値は同じ日・同じ計測手法で取った組み合わせだけを並べます。

速度の前に確かめるべきことがあります。2枚見せた状態でモデルを読み込んだとき、そのモデルは本当に2枚へ分かれているのかという点です。2026年8月14日に、カード別のVRAM増分を取って確認しました。Phi-4 14B（Ollama: phi4:14b）を読み込むと、増分はRTX 5080が0MiB、RTX 5060 Tiが10,354MiB。片方にしか載っていません。一方、qwen3-coder:30bでは9,897MiBと9,314MiBに分かれました。Ollamaは1枚に収まるモデルを分割せず、どちらか一方のカードへまとめて載せます。なお、当サイトがカード別の増分で配置を直接確認したのはこの2モデルです。それ以外は次に挙げる消費電力の内訳から判断しています。またこの配置確認を行ったときのOllamaのバージョンは記録に残していないため、バージョンによって挙動が変わる可能性は否定できません。

この違いは過去の計測ログにも残っていました。2枚を見せた状態で取った22件のうち12件は、RTX 5080の消費電力が52.9〜58.3Wとアイドルのまま、RTX 5060 Tiだけが123〜173Wで動いています。残る10件は両方が91〜142Wで、こちらは2枚へまたがった計測と見られます。前者の12件は「2枚構成」ではなく、実質的にRTX 5060 Tiの単体測定だったと考えられます。ただしカード別のVRAM増分まで直接確認したのは前述の2モデルで、残りは消費電力からの判断であることは断っておきます。

そうなると、確かめるべき問いも変わります。「2枚にすると速くなるか」ではなく、「どちらのカードに載ったかで速度がどれだけ変わるか」です。以下は同じ日・同じ計測手法で、それぞれのカード単体に載せたときの生成速度です。いずれも単体でのVRAM使用量が11.5〜14.1GiBと16GBに余裕をもって収まっており、CPUへのオフロードは起きていません。つまりこの差は、オフロードの有無ではなくカードそのものの性能差です。

いずれも2026年7月24日、同一の計測手法で取得しています。ここで効いているのはカードの素の性能差です。RTX 5080はCUDAコア10752基・メモリ帯域約960GB/s、RTX 5060 TiはCUDAコア4608基・448GB/s。生成速度はメモリ帯域におおむね沿って開きます。

条件をひとつ断っておきます。この3組はコンテキスト長をOllamaの既定値のまま測っています。既定値は空きVRAMに応じて決まるため、ディスプレイ常駐を抱えるRTX 5080側と、常駐のない外付けRTX 5060 Ti側とで厳密に同一とは限りません。どちらも16GB 1枚という同じ土俵ではありますが、コンテキスト長を固定した測り直しは行っていません。

そして、この5060 Ti側の数値（2026年7月24日・RTX 5060 Tiだけを見せた1枚構成で取得）が、それ以前に「2枚構成」として記録していた値（2026年6月18日・2枚とも見せた状態で取得）とほぼ一致します。見せたGPUの枚数が違う2つの計測が一致するということは、少なくともこの2モデルについては、2枚見せた側でも実際に動いていたのは5060 Tiだけだった、ということです。

差は0.3と0.1 tok/s、いずれも1%未満です。つまり「2枚にしたら遅くなった」の正体は、層をまたぐ待ち時間ではありません。モデルが丸ごと遅いほうのカードに載っただけです。2枚目のGPUは、この間ずっと何もしていません。

どちらに載るかは自動で決まります。当サイトの検証環境では、ディスプレイ出力を持つRTX 5080に850〜930MBのデスクトップ常駐があり、外付けのRTX 5060 Tiは空という状態で、モデルは空いている5060 Ti側へ載りました。ただしOllamaがどの規則でGPUを選ぶかは実装依存で、当サイトはその規則自体を確認できていません。載る先を決め打ちにせず、実際にどちらへ載ったかを確認するのが確実です。速いカードで動かしたいなら、環境変数で見せるGPUを固定してしまうのが手堅い方法になります。

# どちらのカードに載ったかを確認する
nvidia-smi --query-compute-apps=pid,used_memory --format=csv
nvidia-smi --query-gpu=index,name,memory.used --format=csv

# 速いカード（この例ではindex 0）だけを見せて固定する
set CUDA_VISIBLE_DEVICES=0
ollama serve

なお、この記事のVRAM数値は性質が3種類あります。8月14日のカード別増分は、モデルを読み込む前後でnvidia-smiのmemory.usedの差を取ったもの。850〜930MBのデスクトップ常駐は、ディスプレイ出力を持つRTX 5080が常時使っている量です。そして表に載せたGPU全体の使用量は、モデル本体にデスクトップ描画などのベースラインを含んだ値で、2枚の場合は両GPUの合算になります。いずれもモデルのファイルサイズとそのまま一致するわけではありません。

「2枚目は使われない」が意味すること

1枚に収まるモデルにとって、2枚目のGPUは存在しないのと同じです。速度が上がらないどころか、載る先を選び損ねると単体より遅くなる。単一モデルの推論速度を上げたいなら、2枚目を足すよりも、より強い単体GPUへ載せ替えるほうが直接的です。RTX 5080単体で足りているモデルにRTX 5060 Tiを外付けで足しても、速度面のリターンはありません。

一方で、1枚に収まらない大型モデルでは話が完全に変わります。ここで初めてモデルが2枚へ分割され、単体ではCPUへあふれていた部分がGPUに載りきる。同じ2枚構成でも、モデルが16GBに収まるか、あふれるかで2枚目の意味が正反対になるということです。その効き方がどれだけのものか、どのサイズ・量子化から2枚目が要るのかを、次のパートで実測を見ていきます。

実測②｜VRAMに「載る」ことの効果を見る

境界線を分けるのは、モデルが16GBに収まるか、あふれるか。この一点に尽きます。前パートで見たのは収まる側で、2枚目は使われずじまいでした。ここでは逆の側、単体16GBからあふれるモデルで2枚目がどう効くかを、当サイトの検証環境（RTX 5080単体、およびRTX 5060 TiをOCuLink接続で追加した2枚構成）の実測で確認します。コンテキスト長の条件はモデルによって異なるため、表のあとで個別に断ります。

全モデル think=false で統一し、各3回計測の中央値。以下は単体と2枚を同じ日・同じ計測手法で取得できた組み合わせだけを並べています。あわせて、nvidia-smi が返すVRAM使用量が単体と2枚でどう変わるかも示します（2枚側は両GPUの合算）。

なお、2枚側の合算20.72〜24.17GiBは、同じモデルを1枚に載せたときの上限15.15〜15.43GiBを大きく超えています。1枚のカードでは到達できない量なので、2枚へまたがった配置とみて矛盾しません。ただしこの合算は nvidia-smi が返す全GPUの使用量で、ベンチ以外のプロセスが別カードで使っている分も含みます。合算値だけで配置を確定できるわけではありません（qwen3-coder:30bについては8月14日に9,897MiBと9,314MiBへ分かれることを直接確認しています）。

単体では60〜75 tok/s台にとどまっていたのが、2枚化で120〜160 tok/sまで伸びています。おおむね1.7〜2.2倍。ここで注目すべきはVRAMの列です。単体時は3モデルとも15.15〜15.43GiBで頭打ちになっています。16GBのカードにはデスクトップ描画などの常駐もあるので、これがこのカードで使いきれる上限です。ところが2枚にすると20.72〜24.17GiBまで使う。この差ぶんが、単体のときはCPU側へ追い出されていたと考えられます。2枚時にGPU総使用量が増え、同時に速度も上がったことは、CPUオフロードが減ったという説明と整合します。ただし memory.used にはKVキャッシュや各種バッファ、デスクトップ表示のベースラインも含まれ、コンテキスト長も一部揃っていないため、増えた分がそのまま追い出されていた重みだとは言えません。主因を確定するには条件を固定した再測定が要ります。前パートの1枚に収まるモデル群で2枚目が一切効かなかったのは、そちらは単体の時点で全部がGPUに載っていたからです。

同時に、この結果はOCuLink x4の帯域が、この効果を打ち消すほどの足かせにはなっていないことを示しています。分割されて層をまたぐ転送が発生してなお、CPUオフロードが消えた効果のほうが正味で上回りました。ただしx4と内蔵x16を同条件で比べた測定ではないので、帯域による損失がゼロだという意味ではありません。なお上表の3モデルはいずれもMoE型です（Ornith-1.0-35Bも公式にはMoEとして公開されています）。Dense型は別の記事で、27〜32B級の3本を、単体（RTX 5080）と2枚ともOllama 0.32.3・文脈8,192の同じ設定で測っています（計測日は別）。3本とも2枚で全部載り、約2.4〜3.5倍（到達した速度は25.7〜30.1 tok/s）になりました。計測日と条件がこの表とは違うので、この表の倍率と横に並べて比べることはできません（VRAM 32GBで何が変わるか）。

VRAM使用量は nvidia-smi の memory.used（デスクトップ描画などのベースラインを含むGPU全体の使用量）で、単体側と2枚側を同じ日・同じ手法で取得しています。なお当初はOllamaのAPI（/api/ps）が返す常駐率を根拠に使っていましたが、mmapを使う部分オフロード時にモデルサイズを二重計上する既知の不具合が、Ollama 0.30.7 を含む修正前の版で報告されているため、この記事では使っていません（修正は2026年6月24日にマージされています）。コンテキスト長は、qwen3-coder:30bの7月30日の計測だけが num_ctx=8192 固定で、他の2モデルはOllamaの既定値のままです。既定値は空きVRAMに応じて決まるため、2枚側のほうが大きなKVキャッシュ領域を確保していた可能性があります。上表は行の中（単体↔2枚）の比較として読んでください。行どうしは計測日もOllamaのバージョンも異なります。実測で確認できたのは記載のモデル・設定の範囲であり、それ以上のサイズや文脈長は未検証と考えてください。

どのモデルサイズ/量子化から2枚目が要るか

境界の目安を整理します。14B級までのモデルはQ4量子化なら16GBに余裕を持って収まり、2枚目は不要。26〜32BのDenseモデルは、別記事でQ4の3本（27〜32B級）を測ったところ、文脈8,192の時点ですでに16GBのカード1枚からあふれていました（Ollama 0.32.3が報告したモデルの大きさで16.3〜21.4GiB。この記事の表のVRAM使用量とは数え方が違います）。35BクラスのMoE（A3B型）は、1トークンで計算に使う活性パラメータが小さいぶん速度は出ますが、全エキスパートの重みは保持が要るので格納量は総パラメータ数と量子化で決まります。Ollama版の qwen3.5:35b-a3b（Q4_K_M）は約24GBあり、16GB 1枚には全量が載りません（同じQ4_K_Mでも配布元によってサイズは前後します）。上表の35B級2モデル（qwen3.6:35b-a3b・Ornith-1.0-35B）も同じ事情で、単体時のVRAM使用量が15GiB台で止まり、2枚にすると21.89〜24.17GiBまで伸びるのは、載りきらなかった分がCPUへオフロードされていた状況と整合します。速度が出ていても常駐しているとは限らないので、2枚目の効き方はここで変わります。

量子化を1段深くして押し込む手もありますが、精度への影響とのトレードオフになります。「16GBに収めるために品質を削る」か「2枚目で余裕を持って載せる」かは、用途次第の判断です。

同時実行スループット — 2つのタスクを並行で回す

2枚目のもう一つの主効果が同時実行。1枚のGPUで大きなモデルを速くすることはできませんが、2枚あれば別々のワークロードをそれぞれのGPUに割り当て、互いを待たせずに走らせられます。片方でローカルLLMの推論を回しながら、もう片方で画像生成を並行させる。こうした「稼働率を上げる」使い方です。

実装は難しくありません。GPUを明示的に固定するだけです。

set CUDA_VISIBLE_DEVICES=0
ollama serve

set CUDA_VISIBLE_DEVICES=1
python main.py   # ComfyUI 等のワークフロー

デバイス番号はドライバの認識順で変わることがあるため、nvidia-smi -L でどのGPUがどの番号かを先に確認しておくのが安全です。番号を取り違えると意図と逆のGPUに載ってしまいます。また、GPUの指定方法は使うソフトウェアやそのバージョンで異なり、環境変数だけでは期待どおりに割り当たらない場合もあります。導入するツールのドキュメントで指定方法を確認してください。

なお、本記事で速度実測を示したのはLLM推論のtok/sだけです。LLM推論と画像生成を同時に回したときの合計スループットや、画像生成そのものの秒数は測定条件が別軸になるため、ここでは数値を断定しません。ご自身が同時に走らせたい具体的なモデルの組み合わせで確認するのが確実です。原理として言えるのは、レイヤー分割の推論が帯域に鈍感なのと同じく、GPUを分けて別タスクに割り当てる構成もOCuLink x4の帯域ではボトルネックになりにくい、ということ。各GPUは受け持ちを独立して処理するため、GPU間で大量のデータをやり取りしないからです。

LLM推論＋画像生成を分けて回すユースケース

具体的な場面を挙げます。コーディング補助のためにローカルLLMを常駐させておき、その裏でComfyUIのバッチ画像生成を流す。LLMが5080、画像生成が5060 Ti、というふうに住み分ければ、片方の重い処理がもう片方をブロックしません。単体GPUだと画像生成中はLLMが待たされ、対話のレスポンスが途切れる。この「待ち」を消せるのが実利です。

ただし住み分けを選ぶと、LLMが使えるのは1枚ぶんのVRAMだけになります。前パートで見た「2枚にまたがってGPUに載りきる」高速化とは両立しません。当サイトの検証環境では、16GBに収まるPhi-4 14BならRTX 5080単体で74.3 tok/s。一方qwen3-coder:30bのように16GBを超えるモデルを1枚へ押し込むと、単体では15.23GiBまでしか載らず、同日・同手法で2枚に載せきったとき（合算20.72GiB）の159.4 tok/sから73.7 tok/sへ落ちます（74.3と73.7はモデルも計測日もOllamaのバージョンも違うので、この2つを並べて比べることはできません）。同時実行を狙うなら、LLM側は1枚に収まるサイズを選ぶのが現実的です。

クラウドの従量課金と手元の2枚構成、どちらが安いかは使用時間で変わります。継続的に回すなら手元のほうが総額で有利になりやすい一方、たまにしか使わないならクラウドで十分。この費用対効果の比較は姉妹サイトのGLM-5.2はローカルではなくクラウドで使うべきかで、料金の目安を含めて整理しています。

2枚目でボトルネックはCPU側へ移る

GPUを増やすと、次に効いてくるのはGPUの外側。この視点はエンタープライズのAIインフラ設計でも同じ方向で語られています。GPUの稼働率を上げようとすると、モデルの前後で走るCPU側の処理（プロンプトの前処理、ツール実行、データの整形、トークナイズ）が相対的に重みを増し、そこで詰まるとせっかくのGPUが遊ぶ、という構図です。

個人環境でも縮図は起きます。当サイトの検証環境のCPUはIntel Core i7-14700Fで、LLM推論を回すだけなら十分な性能。ただしエージェント型のワークフローでコード実行やファイル操作を挟むと、その待ち時間はGPUではなくCPUとストレージが決めます。2枚目を足してGPU側に余裕を作ったなら、次に見るべきはCPUのコア数・メモリ帯域・SSDの速度、という順番になります。

OCuLink x4帯域と同時実行時のCPU負荷

OCuLink（PCIe 4.0 x4）の帯域は約8GB/s。内部スロットのPCIe x16と比べれば狭いのは事実です。ただしレイヤー分割推論や、GPUを分けた同時実行では、GPU間・GPU-ホスト間で流れるデータが小さいため、この8GB/sが問題になる場面は限られます。むしろ同時実行時に効いてくるのは、2つのタスクへデータを供給し続けるCPUとメモリの余力のほう。帯域を心配する前に、CPUが両方のパイプラインを回しきれているかを見るのが実態に合った順序です。

VRAM容量と帯域がローカルAIのボトルネックという業界文脈

ローカルAIの頭打ちがどこにあるか。多くの場面で答えはメモリです。モデルが載るかどうか、そして載ったモデルへ十分な速度でデータを送れるか。VRAMの容量と帯域が、ローカル推論の実効性能を大きく左右します。次世代のメモリ技術が容量と帯域を伸ばす方向へ進んでいるのも、AIワークロードのボトルネックがそこにあることの裏返しです。

この業界の向きと、個人が「2枚目でVRAMを足す」という判断は同じベクトルを向いています。高速な大容量メモリを1枚のGPUに積めるのが理想ですが、コンシューマ向けの現実的な選択肢では容量に上限がある。だから容量が足りないなら、GPUをもう1枚足して合算で稼ぐ、という近似解になります。

個人がHBMを使えない中でVRAMを増やす方法

データセンター級の高帯域メモリは個人には手が届きません。手元でできるのは、GDDR7を積んだコンシューマGPUを組み合わせ、レイヤー分割で「載る量」を増やすこと。RTX 5080（16GB・256bit・約960GB/s）とRTX 5060 Ti（16GB・128bit・448GB/s）を組み合わせれば、単純加算では32GB分のモデル領域になります。ここで注意したいのは、これはあくまでレイヤー分割で層を振り分けた結果の合算であって、1枚で32GBを扱えるわけではない点。表示やランタイム、KVキャッシュにも消費されるので、モデルに回せる実容量は32GBより小さくなります。各GPUはそれぞれ16GBずつを受け持ちます。

エンタープライズの多GPUワークステーションとの対比

「GPUを増やしてVRAMを合算する」という発想は、個人だけのものではありません。プロ向けの現場では、もっと大規模に同じことをやっています。StorageReviewがレビューしたHP Z8 Fury G6iは、1基のXeon 600プロセッサに最大4枚のNVIDIA RTX PRO 6000 Blackwell Max-Qを組み合わせ、合計384GBものVRAMに到達する構成です。RTX PRO 6000 Max-Qは1枚あたり96GB GDDR7・300Wで、送風型クーラーゆえ密集搭載に向きます。

価格帯はまるで違います。レビュー機（64コアのXeon 696X＋RTX PRO 6000 Max-Q 2枚で合計192GB VRAM）は52,139ドル、システムの開始価格でも約7,900ドル。CPU側もIntel Xeon 600シリーズはフラッグシップで86コア・128本のPCIe 5.0レーンに達し、多数のGPUを束ねる土台になっています。個人の2枚構成とは桁が違う世界です。

企業構成と個人2枚構成で共通する狙い

スケールは違えど、重なる部分があります。個人のOCuLink外付け2枚で効くのは「より大きなモデルを載せる」「複数のワークロードを同時に回す」の2点。企業が数百GB級のVRAMを1筐体に詰めるのは、これに加えてテンソル並列やパイプライン並列による大規模な推論・学習まで視野に入れるためです。狙いが丸ごと同じというより、容量と同時実行のためにGPUを積むという発想の一部が、価格帯を越えて共通している、と捉えるのが正確です。個人は、エンタープライズ構成のうち容量・同時実行にあたる部分を、外付けドックで安価に近似しているといえます。

2枚目を足すべき人・不要な人

用途別に判断を整理します。ここまでの実測と原理を、増設是非の早見表に落とし込みます。

どの行に当てはまるかで、答えは機械的に決まります。曖昧なのは「26〜35B級を載せたい」層で、ここが2枚化の最も分かりやすい恩恵を受けます。逆に、単一モデルを速くしたい人が2枚目に投資しても報われません。

予算別の現実的な選び方（2枚目 vs 単体上位）

手持ちがRTX 5080やRTX 5060 Tiで、追加予算がGPU1枚分あるとします。選択肢は2つ。既存GPUを残して安価な16GBカードを2枚目に足すか、単体の上位GPUへ載せ替えるか。大きいモデルを載せたい・同時実行したいなら、2枚目の追加が合理的。合算VRAMと並行処理が直接効きます。一方、すでに収まりきっている1タスクを速くしたい・構成をシンプルに保ちたいなら、24GBや32GBクラスの単体上位への載せ替えが素直な答えです。RTX 5060 Ti 16GBは実売9万円台から手が届き、OCuLink外付けならケース内の空きスロット制約を受けにくく、対応するM.2／OCuLink経路があれば追加しやすいのも、2枚目を足しやすい理由になっています。

まとめ

AI用途にGPUは2枚必要か——答えは用途で割れます。2枚目は、単体GPUに収まりきっているモデルの推論を速くする手段ではありません。当サイトの検証環境では、16GBに収まるモデルはそもそも2枚に分割されず、片方のカードだけで動いていました。遅いほうのカードに載れば、速度は単体より落ちます。効くのは、単体16GBからあふれる26〜35B級を合算VRAMで載せきる場面（当サイトの実測では30〜35B級のMoE型3モデルで、単体では15GiB台で頭打ちだったVRAM使用量が2枚化で20.7〜24.2GiBまで伸び、速度も1.7〜2.2倍へ回復。Dense型も別記事で27〜32B級の3本を測り、2枚で全部載って25.7〜30.1 tok/sになった。条件が違うので、上のMoEの数字とは並べて比べられない）と、LLM推論と画像生成のような別ワークロードを各GPUに分けて同時に回す場面です。

OCuLink（PCIe 4.0 x4・約8GB/s）の狭い帯域は、レイヤー分割推論や同時実行ではボトルネックになりにくく、2枚目の外付けが現実的な選択肢になります。ただしリンク幅だけを変えた対照測定はしていないため、x4による損失の大きさ自体は未評価です。ただしvLLMのテンソル並列や学習はGPU間の通信量が桁違いに多く、低帯域の接続では通信コストが性能を制約しうる領域です。当サイトはこの構成で実測していないため、外付け2枚で狙う対象としては勧めません。

次の一歩は単純です。まずollama psで、今使っているモデルが単体16GBに収まっているか（PROCESSOR が 100% GPU か）を確認する。収まっているなら2枚目は要りません。あふれているか、より大きなモデルを載せたい・同時に別タスクを回したいなら、2枚目が効く領域にいます。用途を早見表に当てはめて、増設の是非を決めてください。

よくある質問

Q. OCuLink x4だと2枚目のGPUは遅くなりますか？

用途によります。llama.cpp/Ollamaのレイヤー分割推論では、GPU間で流れるのは各層の境界の活性値だけで、モデルの重み全体を毎回転送するわけではありません。転送量が小さいぶん帯域の影響も出にくく、約8GB/sのOCuLink x4でも、当サイトの実測では2枚化が正味で効きました。ただしリンク幅だけを変えた対照測定はしていないため、x4による損失の大きさ自体は測っていません。一方、テンソル並列や学習は大量の相互通信が走るため、帯域が効きやすい領域です（当サイトはこの構成での実測はありません）。用途で分けて考えてください。

Q. VRAM 16GB×2は32GBとして使えますか？

1枚で32GBを扱えるわけではありません。RTX 5080（16GB）とRTX 5060 Ti（16GB）は、レイヤー分割でモデルの層を各GPUに振り分けた結果として、合算で32GB相当の領域を確保できます。各GPUはそれぞれ16GBずつを受け持つ形。単一の巨大テンソルが連続した32GBを要求する処理では、合算した容量を1枚ぶんのようには扱えません。

Q. 2枚目を足せば生成は速くなりますか？

単体16GBに収まるモデルなら、速くなりません。そうしたモデルは2枚に分割されず、どちらか片方のカードだけで動きます。当サイトの検証環境では外付けの遅いカード側に載って、単体より下がった例があります。速度を上げたいなら、より強い単体GPUへの載せ替えが直接的です。2枚目が効くのは、単体であふれてCPUオフロードが起きていたモデルが、GPUに載りきって本来の速度に戻る場合です。

Q. vLLMのテンソル並列でも外付け2枚は使えますか？

技術的に動かせても推奨しません。テンソル並列は各層でall-reduceが走り、GPU間の通信量が多いため、NVLinkなどの高速接続で本領を発揮します。PCIe接続やOCuLink x4（約8GB/s）でも動作はしますが、低帯域では通信コストが性能を制約しうるとされています。当サイトはこの構成でのvLLMを実測していません。外付け2枚が生きるのはレイヤー分割推論や、GPUを分けた同時実行のほうです。

Q. どのモデルサイズから2枚目が必要になりますか？

目安として、14B級までのモデルはQ4量子化なら16GBに余裕を持って収まり、2枚に分割されないため2枚目は不要です。26〜32BのDenseモデルは、別記事でQ4の3本（27〜32B級）を測ったところ、文脈8,192の時点で16GB 1枚からあふれていました。35B級のMoE型（A3B等）は活性パラメータが小さく速度は出ますが、重み全体は総パラメータ数で決まるため16GB 1枚には全量が載らず、CPUオフロードを伴います（Ollama版の qwen3.5:35b-a3b・Q4_K_M で約24GB）。ご自身のモデルで ollama ps の PROCESSOR 列を見て、全体がGPUに載っているかを確認するのが確実です。どのカードに載ったかまで知りたい場合は、読み込み前後の nvidia-smi のVRAM増分を見ます。

2枚目を挿す前提のマザーボード・PCIeレーンの選び方は、AI用PCのマザーボードとPCIeレーンの選び方で詳しく整理しています。

参考資料

• NVIDIA公式: GeForce RTX 5080 – 製品仕様
• llama.cpp公式ドキュメント: Multi-GPU（レイヤー分割の挙動）
• Minisforum公式: DEG1 eGPU Dock – 製品情報
• NVIDIA公式: RTX PRO 6000 Blackwell Max-Q Workstation Edition
• StorageReview: HP Z8 Fury G6i Review（多GPUワークステーション実機レビュー）

1枚のGPUで使えるVRAMを人為的に削るとどうなるかは、MiniMax Music 3をVRAM 16GBで動かすで音楽生成モデルを使って掃引している。