複数GPUが認識されても使われない時の切り分け｜Windows+OCuLinkで2枚目が使われる条件

nvidia-smiを叩けば2枚とも表示される。デバイスマネージャにも並んでいる。それなのに推論を走らせると、片方のGPU使用率が0%のまま動かない。VRAM占有もほぼゼロ。増設した意味がないように見えます。疑うとすればまず配線か設定ですが、当サイトの実測では故障でも設定ミスでもないケースが出ました。

nvidia-smiには2枚映るのに、片方の使用率が0%のまま

対象にする症状はこれです。2枚目のGPUがデバイスとしては見えていて、ドライバも当たっている。それでもLLM推論やComfyUIの生成を回している最中、そのカードの使用率とVRAM占有が動かない状態。この症状の原因は、主に次の系統に分かれます。

ひとつは物理的・ドライバ的な失敗。リンクが確立していない、電源が足りていない、ドライバが片方にしか当たっていないケース。次にランタイム側の設定で1枚に絞られているケース。残る2つはどちらも壊れていない側です。3つ目が、分割する必要がないから分割していないケース。4つ目が、そのランタイムがそのワークロードを分割しない仕様のケースです。

「認識されている」と「使われている」は別の話

nvidia-smiに2枚並ぶのは、NVIDIAドライバがそのデバイスを認識・列挙できたことを示すだけです。推論ソフトからそのデバイスが見えるか、見えたうえで使うかは、そこから2段階別の話になります。判断の主体はソフト側にあり、そのソフトが「1枚で足りる」と判断すれば2枚目は待機したまま。

当サイトの検証環境で計測した内訳を見ると、この分離がはっきり出ています。2枚とも見える状態で走らせたQwen3 14Bの行では、RTX 5080側のVRAM占有がデスクトップ表示分の1233MiBにとどまり、モデルは載っていませんでした。2枚とも列挙されていて、ソフトからも2枚見えている。それでも推論に使われたのは1枚だけ、という状態が内訳の数値として残っています。

3層に分けて上から潰す

原因を当てにいくとき、闇雲に環境変数をいじっても当たりません。層を決めて、1（OS・ドライバ）→2（ランタイムの候補選定）→3（モデル配置）の順に潰すほうが早い。

1の層で落ちていれば、その先のどんな設定も無意味。逆に1と2が通っているなら、残るのは「そもそも分割が必要ない」か「そのランタイムがそのワークロードを分割しない仕様」のどちらかです。前者が今回の中心で、当サイトの実測でもこのパターンが出ました。

前提｜必要VRAMは1枚の空きVRAMに収まるのか

切り分けに入る前に、判断材料になる見積りを押さえておきます。Ollamaの場合、2枚目がモデル配置に使われるかどうかを分ける大きな基準が「モデルの必要VRAMが1枚の空きVRAMに収まるか」だからです。2枚目を検討する主な理由も容量です。速度が欲しいなら1枚を上位に替えたほうが手間が少ない。それでも枚数を増やすのは、1枚のVRAMに載らないモデルクラスへ手を伸ばしたいからです。

容量クラスとモデルクラスの対応

StorageReviewは「Best Local LLM Tools in 2026」で、ローカルAIのハードウェア支出はまずメモリの決定であるとして、16GBのVRAMまたは32GBのユニファイドメモリで7〜8Bクラス、24〜32GBのVRAM（あるいは48GBのユニファイドメモリ）で30Bクラス、96〜128GBのユニファイドメモリで100B超のクラスという階層を示しています。買いすぎても体感しにくい速度を買うだけで、買い足りなければ狙ったモデルクラスがそもそもロードできない、という整理です。

この階層で見ると、16GBのカードを1枚持っている人が次に欲しくなるのは24〜32GB帯。ここで取れる道は主に3つ。1枚を大容量に買い替える、2枚目を足す、そして次節のとおり量子化やMoEの選択で必要量そのものを下げる。ハードウェアを増やす側の2つのうち、後者がこの記事の対象です。同社はQ4量子化のダウンロードサイズとしてPhi-4 14Bが9.1GB、Qwen3 30B-A3Bが19GBという具体値を挙げています。ダウンロードサイズで比べる限りでは前者は16GBのカード1枚の容量に収まり、後者は超える側です（実際に必要な量は後述のとおり作業用メモリ分が上乗せされます）。

量子化とMoEで見積りが非線形に動く

パラメータ数から必要メモリを逆算する発想は、ここで外れます。StorageReviewの整理では、パラメータ数だけではハードウェア要件を予測できません。量子化によって重みはおよそ4分の1に縮みます。一方MoEは、推論時に活性化するパラメータが少ないぶん速度は活性パラメータ側に近づきますが、必要メモリは総パラメータ側に比例します（同社は「memory scales with total parameters but speed scales closer to active parameters」と明記しています）。実際、後述の実測でも活性3B級のqwen3-coder:30bとqwen3.6:35b-a3bは、どちらも1枚には収まらず2枚に分割されました。MoEだからメモリが軽くなるわけではありません。

さらに、重みが載れば終わりではありません。実行にはモデルサイズを超える作業用メモリが必要で、エージェント的なワークロードではコンテキストが伸びるぶん追加のメモリ負荷が乗ります。同社はこれを、多くのサイジングガイドが飛ばしている項目として挙げています。

だから「16GB＋16GBだから32GB相当」という足し算だけで判断すると、二重に外します。ひとつは実際に必要な量が量子化とアーキテクチャで大きく動く点。もうひとつは、後述のとおり、そもそも2枚が1つの連続したメモリ空間として振る舞うわけではない点です。

切り分け1｜OS・ドライバ層で2枚目が正しく立っているか

最下層から始めます。ここが通っていなければ、この先の環境変数もランタイム設定も全部無駄になるためです。

nvidia-smiで見るべき列

まず列挙されているかを確認します。

nvidia-smi --query-gpu=index,name,memory.total,pcie.link.gen.current,pcie.link.width.current,memory.used,utilization.gpu --format=csv

見るのは5点。indexが0と1の両方出ているか、nameが期待どおりのカード名になっているか、memory.totalが公称容量どおりか、リンクの世代と幅が使っている接続の仕様どおりか、そして推論を回した状態でmemory.usedとutilization.gpuが動くか。列挙されていてリンクも仕様どおりなのに使用量が動かない場合、この層はひとまず通っていて、原因はその先の層にあります。増設側でリンクが仕様を下回っているなら、その先の設定を触る前に接続と電源を疑います。

推論中の推移を見たいなら、一定間隔で回します。

nvidia-smi --query-gpu=index,name,memory.used,utilization.gpu,power.draw --format=csv -l 2

power.drawはボード単位の値です。2枚構成では、稼働していないカードでもアイドル分の電力を引き続けます。電力の内訳だけを見て「両方動いている」と判断しないこと。実際、当サイトの計測ではアイドル状態のRTX 5080が50W台を引いている行が並んでいます。

VRAM占有の非対称も、この層で押さえておく価値があります。当サイトの検証環境では、画面出力を担当しているRTX 5080はデスクトップ表示に約1.2GB取られており、ロード前の空きVRAMは14.9GB。一方、表示出力を持たないRTX 5060 Ti側は、ロード前の時点でほぼ全量が空いていました。同じ16GBのカードでも、モデルをロードする前の時点で1GB以上の差がついている状態です。モニタを繋いでいるカードは、その分だけロード前の空きが減ります。どちらに載るかを予測したいなら、推論を始める前にmemory.usedを両方見て実際の空きを比べておくこと。

OCuLink接続で追加される確認項目

外付けGPUをOCuLinkで繋いでいる場合、確認項目が増えます。当サイトの検証機はRTX 5080をマザーボードのPCIe 5.0 x16スロットに、RTX 5060 Ti 16GBをMINISFORUM DEG1経由のOCuLink（PCIe 4.0 x4）で接続した構成。DEG1の接続仕様はPCIe 4.0 x4で、メーカー表記の最大転送レートは64GT/sです。GT/sは転送レートであって、そのままGB/sの帯域を表す値ではありません。ATX/SFX電源に対応し、RTX 4090やRX 7900 XTXクラスまでのGPUをサポートする旨も同社の製品ページにあります。参考価格は本社サイト表示で109.90ドル、公式ストア表示ではセール109.00ドル／通常139.00ドル（いずれも2026年8月時点の表示で、在庫状況により変動。日本国内の実売価格・保証条件は未確認）。

MINISFORUM DEG1 の接続仕様は PCIe 4.0 x4、メーカー表記の最大転送レートは 64GT/s。ATX/SFX 電源に対応し、RTX 4090 / RX 7900 XTX クラスまでの GPU をサポートすると記載されている。（MINISFORUM 公式ストア: https://store.minisforum.com/products/minisforum-deg1-egpu-dock ）

追加で見るのはリンクと電源です。まずOSがカードを列挙できているか。次に電源系統。当サイトの検証機はメイン850WとOCuLink側750Wの2系統独立で、GPUドックの電源はマザーボードとは別に供給しています。この構成では、2系統を合算したTDP計算は成立しません。片方の電源が落ちていればカードは列挙されず、列挙されていてもリンクが不安定なら上位層の設定を触っても解決しないままです。

なお、Windowsの表示モード関連の設定が2枚目の未使用の原因になるかどうかは、当サイトでは検証していません。この層の確認は、列挙・ドライバ・電源・リンクの4点に絞るのが確実です。

切り分け2｜ランタイムが2枚目を候補に入れているか

最下層が通っているなら、次はソフトから何枚見えているか。ここは環境変数ひとつで結果が反転する層です。

環境変数で1枚に絞られていないか

CUDA_VISIBLE_DEVICESは、アプリケーションから見えるNVIDIAデバイスを指定する環境変数です。デバイスIDをカンマ区切りで書き、そこに書いたデバイスだけがアプリから見えるようになります。マスクとしてだけでなく列挙順の変更にも使えて、指定した順にCUDAランタイム側の番号が振り直される仕様。

厄介なのは、この変数がシステム全体に設定されている場合です。当サイトの環境ではシステム全体のCUDA_VISIBLE_DEVICESが0に設定されており、明示的に0,1を渡さない限りPyTorchからは1枚しか見えない状態でした。この状態でどれだけランタイム側の分割オプションを叩いても、候補が1枚しかないので分割は起きません。

REM コマンドプロンプト (cmd.exe)
echo %CUDA_VISIBLE_DEVICES%
set CUDA_VISIBLE_DEVICES=0,1

# PowerShell
$env:CUDA_VISIBLE_DEVICES
$env:CUDA_VISIBLE_DEVICES = "0,1"

OllamaもこのCUDA_VISIBLE_DEVICESを、見えるNVIDIAデバイスを指定する環境変数として扱います。つまりOllamaを起動しているシェルやサービスの環境に0だけが入っていれば、その時点で2枚目は候補から外れています。

ランタイムごとの既定挙動の違い

候補として2枚見えていても、どう使うかはランタイムごとに違います。公式の仕様として確認できる範囲を整理します。

Ollama公式FAQは複数GPUへのロード規則を明記しています。モデルの必要VRAMを現在の空きと突き合わせ、いずれか1枚に全部収まるならそのGPUに載せる（PCIe越しの転送を減らすため）、1枚に収まらない場合は利用可能な全GPUへ分散する、という挙動です。つまり「1枚に収まるモデルが片方にしか載らない」のは仕様で、後述の実測もこれと一致しました。全GPUへ常に広げたい場合に使うのがOLLAMA_SCHED_SPREADです。

llama.cppの-sm／--split-modeは、公式ドキュメント（2026年8月時点）では、noneが1枚のみ使用、layerが既定で層とKVキャッシュをGPU間に分ける、そのほかにrowとtensorを取ります。ただしrowは公式のマルチGPUドキュメントでDeprecatedと明記されており、tensorへ置き換えられています。そのtensorもEXPERIMENTAL扱いです。-mg／--main-gpuは、split-modeがnoneのときにモデルを載せるGPU、rowのときは中間結果とKVの置き場を指定する引数で、既定値は0。各GPUへ振る割合はカンマ区切りの-ts／--tensor-splitで指定します。

# ソフトから見えているデバイスの一覧
llama-server --list-devices

# 層とKVキャッシュを2枚へ均等に振る (既定の layer)
llama-server -m model.gguf -sm layer -ts 1,1

# 分割せず1枚だけ使う (-mg で使うGPUを指定)
llama-server -m model.gguf -sm none -mg 0

ComfyUIは--cuda-deviceで、そのインスタンスが使うCUDAデバイスIDをカンマ区切りで指定します。単一ワークフローを複数GPUへ振る組み込みノード（MultiGPU CFG Split）もコアに実装されています。ただし公式のノードドキュメントは、対応構成を「Ampere以降の同一GPU2枚」とし、異なる型番の混在は非対応と明記しています。またCFGが1のワークフローでは効果が出ないとも書かれています。当サイトの構成は異なる型番の2枚なので、この条件からは外れます（異種構成での動作は当サイトでは未検証です）。ただし異種構成でも打つ手が無いわけではありません。公式の組み込みノードにはSelectModelDeviceがあり、1つのワークフローの中でモデルを載せるデバイスをgpu:0からgpu:7のように指定できます。こちらには同一GPUという条件は付いていません。ほかにインスタンスごとにカードを割り当てる使い方もあります。

バックエンドが想定と違う経路に落ちていないか

Ollamaはビルドや設定によってCUDA以外の経路（VulkanやCPU）を選ぶことがあります。この場合カードは列挙されているのに使用率が上がらないため、症状だけを見ると候補選定層の問題と区別がつきません。ollama serveのログでどのライブラリが選ばれたかを確認するのが早い。関係する環境変数はOLLAMA_VULKAN、GGML_VK_VISIBLE_DEVICES、OLLAMA_LLM_LIBRARY、VRAMの予約量はOLLAMA_GPU_OVERHEADです。当サイトの環境でも、旧Vulkan設定が残っていた時期にRTX 5060 Ti側が無音でCPU実行に落ちていたことがあります。これは本記事の中心である「分割不要だから載らない」とは別系統の原因です。

ツール層はまだ横並びになっていない

ここまで見たとおり、デバイスの指定方法も分割の制御も、ランタイムごとにバラバラ。StorageReviewはローカルAIのソフトウェア側について、ハードウェア側ほど成熟が進んでおらず、検索で薦められているツールのうち相当数が既に使えなくなっていると指摘しています。マルチGPU周りは特にこの影響を受けやすい領域です。

対策は2つ。使っているランタイムの公式ドキュメントで、そのバージョンのオプション名を直接確認すること。そして--list-devicesのような一覧コマンドで、ソフトから実際に何が見えているかを毎回確認することです。切り分けが済んで2枚目が動くようになったら、ツール側の構成まで含めた組み上げ手順は別記事にまとめています（OpenJarvisでローカルAIアシスタントを作る完全手順）。

なお、GPU間のP2P転送やNCCLを使う構成での2枚構成の挙動は当サイトでは未検証です（計測時はいずれも未設定）。この記事の記述は、それらを使わない既定に近い状態での観測に限られます。

切り分け3｜必要VRAMが1枚に収まっていれば2枚目は使われない（Ollamaの場合）

1と2の層が通っているのに2枚目が動かない場合、Ollamaでまず疑うのは「分割する必要がないから分割していない」。異常ではなく正常動作です。

ただしこれはOllamaの話です。ComfyUIなど画像生成側にも単一ワークフローを複数GPUへ振る仕組みはありますが、MultiGPU CFG Splitは対応構成が同一GPU2枚に限られるため、異種構成では対象外です。その場合はSelectModelDeviceなどでワークフロー内の処理を特定GPUへ配置するか、インスタンスを分けてGPUを割り当てる方法があります（切り分け2）。llama.cppも既定が-sm layerで層とKVを2枚に分ける側なので、Ollamaとは逆に「1枚に収まるのに2枚へ分かれている」状態のほうが既定です。

同一バッチ3条件の実測結果

当サイトの検証環境で、同じモデルを1枚のみ／2枚とも見える状態／2枚目単体の3条件で走らせ、GPU別のVRAM占有内訳を取りました。計測はRTX 5080（PCIe 5.0 x16）とRTX 5060 Ti 16GB（OCuLink PCIe 4.0 x4）の構成、Ollama 0.32.3、NVIDIAドライバ610.47、think=falseで統一、コンテキスト長は8192、計測日は2026年8月17日です。以下は単発計測の参考値であり、3回試行の集計ではありません。

Qwen3 14B（Ollama: qwen3:14b）のRTX 5080側1233MiBは、デスクトップ表示に取られている分とほぼ一致します。つまりモデルは載っていません。必要VRAMが5060 Ti側の空きVRAMに収まったため、Ollamaは片方のカードだけに全部載せたわけです。「2枚あるのに片方のVRAMが動かない」という症状が、ここで再現しています。ただし当サイトで止まっていたのは増設した5060 Ti側ではなく、画面出力を持つRTX 5080のほうでした。今回の環境では、表示出力によるVRAM占有が少なくロード前の空きが多かった5060 Ti側にモデルが載っています。カード番号だけで配置先が決まる挙動ではありませんでしたが、空きVRAMの多いGPUを優先すること自体は公式仕様として確認できていません。

速度でも同じ結論が出ました。Qwen3 14B（Ollama: qwen3:14b）は2枚構成で43.42 tok/s、RTX 5060 Ti単体で43.56 tok/s、RTX 5080単体で80.2 tok/s。2枚構成の値は5060 Ti単体とほぼ一致していて、5080単体より遅い。Gemma 4 12B（Ollama: gemma4:12b）でも同じ現象が再現し、2枚構成46.37 tok/sに対して5060 Ti単体46.44 tok/sとほぼ一致しています。

一方、1枚には収まらないqwen3-coder:30bは様子が変わります。2枚構成で157.83 tok/s、RTX 5080単体では72.45 tok/s。単発計測どうしの比較ですが、2倍以上の差が出ました。この差の理由は内訳に出ています。2枚構成ではGPU常駐率が100%で、重み19.7GBがそのままVRAMに載っています。対してRTX 5080単体の行は常駐率74%、VRAMに載った重みは14.5GBにとどまり、残りはVRAMの外へ退避していました。単体側は全部をGPUに載せられておらず、2倍以上の差はこれで説明が付きます。

分割が起きる境界はどこか

目安になるのは、量子化後の重みと作業用メモリの合計が1枚の空きVRAMに収まるかどうかです。基準は配布ファイルのサイズではありません。当サイトの計測でも、配布サイズ9.3GBのqwen3:14bが実際には15634MiB、7.6GBのgemma4:12bが14046MiBを占有しており、ファイルサイズの1.7〜1.9倍でした。

ただし「収まる」側の余裕は大きくありません。分割されなかったqwen3:14bでも5060 Ti側の占有は15634MiB（16GBカードの約95%）で、ぎりぎり収まった状態です。載った後のVRAM占有量そのものは判別材料になりません。当サイトの計測でも、重み9.3GBのqwen3:14bが15634MiBを占有しており、重みのサイズから占有量は読めませんでした。この差分の内訳は本記事では確定していません（Ollamaはコンテキスト長を明示しない場合、VRAM量に応じた既定値を使う仕様ですが、今回の計測はnum_ctx=8192を固定しています）。Ollamaが突き合わせているのは公式FAQの表現でいう「必要VRAM」、つまり重みと作業用メモリの合計です。配布サイズ9.3GBのqwen3:14bは片方だけに載り、19.7GBのqwen3-coder:30bは収まらず分割されました。ただし今回の4モデルは、重みだけで判定しても必要量で判定しても同じ側に落ちる並びなので、どちらの量で切れているかはこの計測からは分離できていません。分割が起きる正確な閾値も確定していません。

もう一点、どちらのカードに載るかにも偏りが出ました。1枚に収まるモデルは、空きVRAMの多い5060 Ti側へ載っています。表示出力による占有の非対称が影響したと考えられますが、Ollamaが「空きVRAMの多いGPUを選ぶ」という配置規則そのものは公式ドキュメントで確認できていません。今回の観測から推定した挙動であり、仕様として断定はできない範囲です。

1と2の層が通っているなら、次に確認するのはモデルの実占有量です。重みと作業用メモリの合計が1枚の空きVRAMに収まっているなら、2枚目が0%でも正常。2枚目にモデルを載せたいなら、1枚の空きに収まらないサイズのモデルを選ぶか、OLLAMA_SCHED_SPREADのように全GPUへ広げる設定を明示するか、別プロセスをそのカードへ割り当てるか、いずれかに寄せることになります。ただし「載る」と「速くなる」は別です。当サイトの実測では、1枚に収まるモデルを2枚構成で回した値は遅いほうのカード単体と同水準でした。SPREADで強制的に広げた場合の速度は今回未計測です。

外付けで足すときのドック｜DEG1以外の機種と、確認箇所の違い

検証機はMINISFORUM DEG1だが、OCuLinkで2枚目を足すドックはこれだけではない。ドックによって切り分け1で見る「電源」「列挙」「リンク」の確認箇所が変わるため、機種ごとの違いを整理しておきます。逆に切り分け2以降（ランタイムの候補選定・モデル配置）は、機種を替えても同じ手順です。

仕様はいずれもメーカー公式ページの2026年8月時点の表示です。AOOSTARはAG01・AG02のいずれにも、RX 9070 XT搭載機器とは非対応という注記を出しています。非対応の組み合わせで何がどう失敗するか（列挙されない／リンクが張れない／不安定）は公式に書かれていないため、該当カードを使う予定なら購入前にメーカーへ確認すること。機種によっては品切れ・受注生産のことがあるため、価格と在庫も購入前に公式で確認すること。

GPD G1やONEXGPUは同じ「eGPUドック」の名前でも、グラフィックスカードを内蔵した製品です（GPD G1と初代ONEXGPUはRadeon RX 7600M XT、ONEXGPU 2はRadeon RX 7800Mを搭載）。手持ちの2枚目を挿す箱ではありません。本記事が扱うのは自分のカードを挿す構成なので、内蔵型は対象が変わります。挿すカードを選べないことに加えて、内蔵GPUがRadeonである以上、本記事で扱うCUDA_VISIBLE_DEVICESやOllamaのCUDA経路の話もそのままは当てはまりません。

OCuLinkより上の規格として、MCIO 8i（Mini Cool Edge IO / SFF-TA-1016）があります。コネクタ規格としてはPCIe 5.0対応品が流通しており、レーン数もOCuLinkの一般的なx4に対して8本です。デスクトップから使う場合は、PCIeスロットに挿すMCIO 8iのホストアダプタも流通しており、OCuLinkと同じようにスロットから引き出せます。

ただし実機で張られるリンクの世代と幅は製品の実装次第で、規格の上限がそのまま出るとは限りません。GPDがミニPCのBOXとeGPUドックのG2で採用しているMCIO 8iは、G2の公式スペック表ではPCIe 4.0 x8と記載されています（OCuLinkのPCIe 4.0 x4に対してレーンが2倍）。同社は当初PCIe 5.0相当と読める案内をしていたものを、他インターフェースとの干渉によりPCIe 5.0の速度には達しないとして訂正しています。アダプタもドックも、対応するPCIe世代は製品ごとに異なるため、繋いだあとは切り分け1と同じく pcie.link.gen.current と pcie.link.width.current で実値を確認すること。

G2は800WのATX 3.1電源を内蔵し、手持ちのRTX 50 / RX 9000シリーズのデスクトップカードを挿す形。価格は公式ストア表示で352.95ドル（2026年8月時点。販売状況は変動するため購入前に公式ストアで確認）で、109ドル前後のOCuLinkドックとは一段違います。なお理論上は、GPU間やホストとGPUの間の転送がボトルネックになる処理で広いリンクが有利になり得ます。ただし実際の改善量はPCIeのトポロジ、P2Pの可否、ランタイムの実装に依存し、当サイトはPCIe 4.0 x4以外のリンク幅を比較していないため未検証です。いずれにせよ、本記事の中心であるOllamaの既定の配置規則、つまり「必要VRAMが1枚に収まるモデルはその1枚に載せる」という挙動自体は、リンクの太さでは変わりません。

レーン配分やBIOS設定まで含めた構成の選び方はAI用PCのマザーボードとPCIeレーンの選び方で扱っています。

まとめ

2枚目のGPUが0%のまま動かないとき、疑う順番は1. OS・ドライバ層、2. ランタイムの候補選定層、3. モデル配置層。多くはこの順に潰せば原因の層に当たります。3段とも通っているのに解決しない場合は、そのランタイムがそのワークロードを分割しない仕様か、バックエンドが想定と違う経路に落ちていないか（切り分け2）を疑うこと。

当サイトの検証環境（RTX 5080＋RTX 5060 Ti・OCuLink接続・Ollama 0.32.3・think=false・num_ctx=8192・単発計測の参考値／計測日2026-08-17）では、必要VRAMが1枚の空きVRAMに収まったQwen3 14B（Ollama: qwen3:14b）は片方のカードにだけ載り、1枚には収まらなかったqwen3-coder:30bで2枚に分かれました。2枚目にモデルが載るのは、分割が起きるサイズのモデルを使うか、全GPUへ広げる設定や別プロセスをそのカードへ明示的に割り当てた場合です（速度が上がるかは別問題で、本記事では分割が必要なサイズの場合しか計測していません）。

なお、この3段のうちOCuLink構成に固有なのは最下層のリンクと電源だけで、それより上の切り分けはバスの種類によらず同じ手順です。

よくある質問

Q. 2枚目のGPUが0%のままなのは故障ですか？

故障とは限りません。当サイトが検証したOllamaでは、公式FAQに「モデルが単一GPUに全部収まる場合はそのGPUに載せる」と明記されており、収まる限り分割しません。当サイトの検証環境でも、2枚とも見える状態でQwen3 14Bを走らせた際にRTX 5080側の占有はデスクトップ表示分の1233MiBにとどまり、モデルは載っていませんでした。ただしこれはランタイム共通の挙動ではなく、llama.cppは既定の-sm layerが層とKVをGPU間で分割する仕様です。故障を疑う前に、使っているランタイムの既定と、モデルサイズおよび空きVRAMを確認すること。

Q. Ollamaで2枚に広げるにはどうしますか？

Ollamaにはモデルを全GPUへ割り当てるOLLAMA_SCHED_SPREADが用意されており、全GPU利用は明示的に有効化する側の設定として定義されています。あわせてCUDA_VISIBLE_DEVICESが1枚だけに絞られていないかも確認が必要。当サイトの環境ではシステム全体の値が0に設定されており、明示的に0,1を渡すまで2枚目は候補に入りませんでした。

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

単純な足し算にはなりません。RTX 5080は表示出力に約1.2GB取られてロード前の空きが減り、表示出力を持たないRTX 5060 Ti側はほぼ全量が空いているという非対称な状態でした。分割時は当サイトの観測上、各カードの空き容量におおむね沿う形で層が振られていましたが、この配置規則は公式ドキュメントで確認できていません。いずれにせよカード間の転送は発生します。速度・VRAM以外の軸（生成品質や長時間運用の安定性）は本記事では未評価です。

参考資料

• NVIDIA 公式: GeForce RTX 5080 – 製品仕様
• NVIDIA 公式: Ultimate Guide to GeForce RTX 5060 Family
• NVIDIA Developer Blog: CUDA Pro Tip – Control GPU Visibility with CUDA_VISIBLE_DEVICES
• Ollama 公式: envconfig/config.go – 環境変数定義
• llama.cpp 公式: server README – split-mode / tensor-split 仕様
• ComfyUI 公式: cli_args.py – --cuda-device オプション
• MINISFORUM 公式ストア: DEG1 eGPU Dock – 接続仕様
• StorageReview: RAM, GPU, and Storage for Agentic AI – How Much You Actually Need
• ComfyUI: SelectModelDevice（ワークフロー内でのデバイス指定）
• ComfyUI: MultiGPU CFG Split（対応構成の条件）
• llama.cpp: docs/multi-gpu.md（split-mode の現行整理）
• AOOSTAR: EG01 OCuLink eGPU Dock（公式）
• GPD: G2 eGPU Dock（公式ストア）
• Ollama: Context length（VRAM量別の既定コンテキスト長）
• Ollama: FAQ（複数GPUへのロード規則・Windowsの環境変数設定）
• StorageReview: Best Local LLM Tools in 2026 – Runtimes, Apps, and Agents
• StorageReview: Best Desktops for Local AI in 2026 – Lab-Tested Leaderboard

ComfyUI に限れば、v0.34 以降の Windows が既定で1枚に絞る挙動がある。その確認方法と解除の指定はComfyUIで使うGPUを指定するで扱っている。