Ollamaが2枚目のGPUを使わない理由｜nvidia-smiでは認識済みなのにVRAMが増えないとき

Oculink接続デュアルGPUとは、PCIe 4.0 x4の外付け規格で2枚目のGPUを増設する構成のこと。

NVIDIAドライバが2枚のGPUを正しく認識しているのに、Ollamaは片方にしかモデルを載せない。本検証で観測したのはこの状態です。当サイトの検証環境（RTX 5080 16GB + Oculink DEG1経由のRTX 5060 Ti 16GB / i7-14700F / RAM 96GB）でも、nvidia-smiで見ると2枚目のRTX 5060 TiのVRAM使用量が0のまま動かず、レイヤー分散が成立しないまま単発GPUで推論する状態が再現しました。Ollama 0.22.1・NVIDIAドライバ 596.21・Windows 10という計測時点（2026年5月初旬）の構成でも同じ挙動が観測できました。

RTX 5060 Tiにモデルが配置されない｜2枚目が使われないまま推論が走る現象

検証環境を組んだ直後、nvidia-smiでは2枚のGPUがどちらも認識されるのに、Ollamaの推論ジョブは片方しか使わない。VRAM使用量を見ると、RTX 5080側だけが埋まり、RTX 5060 Tiは0%で放置されたまま。レイヤー分散が起きず、モデルがVRAMに収まらないとシステムRAMにオフロードされる挙動でした。

検証環境と再現条件

当サイトのテスト環境はRTX 5080がメインボードのPCIe 5.0 x16、RTX 5060 Tiは外付けOculink DEG1経由でPCIe 4.0 x4接続。OSはWindows 10、Ollamaは0.22.1、NVIDIAドライバは596.21。本検証で扱ったのは1枚のVRAMに収まるサイズのモデルで、その範囲ではデフォルト設定のまま2枚目へ配置される挙動は観測できませんでした。

公式FAQで確認する複数GPUの既定動作

Ollama公式FAQは、モデルが利用可能ないずれか1枚に収まる場合は転送を避けてその1枚へ載せ、収まらない場合は利用可能な全GPUへ分散すると説明しています。つまり本検証で見たのは仕様どおりの挙動で、認識の失敗ではありません。公式GPUドキュメントの CUDA_VISIBLE_DEVICES と UUID 指定も、Ollamaが使えるGPUを限定・固定するための設定であって、GPUを認識させるための設定ではありません。

回避手順｜3つの設定を段階的に検証する

本検証で試した順に並べます。CUDA_VISIBLE_DEVICESは使うGPUを限定・固定する設定、OLLAMA_SCHED_SPREADは1枚に収まるモデルも含めて全GPUへ配置させる設定、num_gpuはGPUへ送る総レイヤー数の指定です。役割が違うので、目的に応じて使い分けます。

CUDA_VISIBLE_DEVICESとUUID指定（公式ドキュメント記載）

使うGPUを固定したいときに確実なのは、nvidia-smiで2枚のGPUのUUIDを取得し、CUDA_VISIBLE_DEVICES=GPU-uuid1,GPU-uuid2 の形でOllamaを起動する方式。デバイス番号（0,1）でも動きますが、PCIe接続状態で番号が入れ替わるケースがあるため、UUID指定の方が安定します。UUIDの取得は nvidia-smi -L で一覧表示されたGPU-から始まる文字列をそのまま使う。

num_gpu / OLLAMA_SCHED_SPREADの役割

num_gpu は、モデル全体でGPUへオフロードするレイヤー数を指定するオプションで、GPUごとの配分を決めるものではありません。OLLAMA_SCHED_SPREAD=1 は、1枚に収まる場合も含めてモデルを利用可能な全GPUへ配置させるスケジューラ設定です。両者は「モデル単位とジョブ単位」という関係ではなく、総オフロード層数と配置方針という別の軸です。なお num_gpu は環境変数ではありません。APIリクエストのoptionsに渡すか、Modelfileに書いてビルドし直すことで指定します。ただし扱いには注意が要ります。2026年8月9日時点の公式Modelfileリファレンスには、PARAMETER一覧にnum_gpuの記載がありません（載っているのはnum_ctx・num_predict・temperature・top_k・top_p・min_pなど）。以前は記載があったものが消えた状態で、公式リポジトリには記載の復活を求めるIssue #13986がopenで立っています。実装としては現在も有効で、公式リポジトリのAPIドキュメントにあるリクエスト例にも "num_gpu": 1 が含まれます。確実なのはoptions経由で渡す方法です。

本検証での設定別結果

以下はRTX 5080 + Oculink経由のRTX 5060 Ti、Ollama 0.22.1、NVIDIAドライバ 596.21、Windows 10で、1枚のVRAMに収まるサイズのモデルを使ったときの結果です。モデルサイズ・量子化・コンテキスト長が変われば挙動も変わるため、一般仕様ではなく本検証固有の記録として読んでください。

本検証では、OLLAMA_SCHED_SPREADを有効にした時点でnvidia-smi上のRTX 5060 Ti側のVRAMが埋まり始めました（当サイト実機での観測。2枚に分かれたかどうかは ollama ps の PROCESSOR 列では判定できないため、各GPUのVRAM使用量で見ています）。OLLAMA_SCHED_SPREADは「すべてのGPUにモデルを分散配置する」ためのOllamaの環境変数ですが、公式GPUドキュメントが段階手順を推奨フローとして明示しているわけではないため、nvidia-smiでの各GPUのVRAM使用量とOLLAMA_DEBUGのログで、分散の成否を確認してください。

環境変数の永続化と適用範囲

CUDA_VISIBLE_DEVICES と OLLAMA_SCHED_SPREAD はプロセス起動時に評価されるため、Ollama をサービスとして動かしている場合、ユーザー環境変数を更新しただけでは反映されない。Windows は公式 FAQ が「タスクバーの Ollama を終了 → 設定（Windows 11）またはコントロールパネル（Windows 10）で environment variables を検索 → ユーザー環境変数を編集または新規作成 → Ollama を起動し直す」という流れを案内しています。Linux も同じく公式 FAQ のとおり systemctl edit ollama.service でユニットファイルに Environment= を追加する手順です。

Windows 既定のトレイ常駐アプリなら、上の公式手順そのままで足ります。タスクバー右下の Ollama アイコンから終了し、設定アプリ（Windows 10ならコントロールパネル）の環境変数 GUI でユーザー環境変数として OLLAMA_SCHED_SPREAD に 1 を設定し、スタートメニューから起動し直す。管理者権限は要りません。setx OLLAMA_SCHED_SPREAD 1 /M のようにシステムスコープへ書く必要があるのは、Ollama を Windows サービスとして動かしている場合や、別ユーザーのセッションから起動させる場合に限られます（/M には管理者として実行したコマンドプロンプトが必要）。サービス化している場合は net stop ollama / net start ollama で再起動できます。

Modelfile 経由で num_gpu を埋め込んだカスタムモデルをビルドする場合は、ollama create でタグを切り直し、推論時にそのタグを指定する流れになる。コマンドラインから一回限り適用したいケースでは、APIリクエストの options に { “num_gpu”: 30 }（GPUに載せるレイヤー数）を渡す方法でも調整できます。

デュアルGPU化の損得｜モデルサイズで結果が逆転する

実機検証で見えてきたのは「VRAM拡張は得、速度向上は条件付き」という構図。「VRAM expansion first, performance second」というOllamaのMulti-GPU設計方針と一致する結論です。

マルチGPU推論は基本的にVRAM拡張機能であり、スループット倍増の仕組みではない。レイヤー分割推論ではデバイス間のPCIe転送オーバーヘッドが発生し、単一ストリーム生成では並列計算で得られる利得を相殺するか上回ることがある。 — Ollama GPU ドキュメントの趣旨を要約

70Bクラス：RAMへ逃がす量を減らせる

70BパラメータのモデルはGGUF Q4量子化でも約40GBを必要とする。RTX 5080単体（VRAM 16GB）には到底乗らない。Oculink経由で2枚目を増設してVRAM 16GB+16GB＝合計32GBにしても約40GBには届かず、VRAM内だけでは完結しない。ただし不足分はCPU/システムRAMにオフロードされるため、RAMを十分に積んだ環境（当サイト実機はRAM 96GB）であれば、2枚への分散とRAMオフロードの併用で起動・動作する。RAMを十分に積んでいれば1枚でもCPUオフロードで起動はします。ただし40〜44GBのうちVRAMに載るのは16GB分だけで、残り24〜28GBをRAM側で処理することになる。2枚にすると常駐分が32GBまで増え、RAM側は8〜12GBまで減ります。全層GPU常駐には遠く及びませんが、1枚構成よりは明確に速くなる、というのがデュアル化の実利です。Llama 3.1 70B、Qwen 2.5 72B、Mixtral 8x22B などが具体的な対象モデルで、各モデルのVRAM要件は Ollama 公式モデルライブラリ の各モデルページに掲載されている数値と整合します。

14Bクラス：単発GPUの方が速い

逆に14B級（Q4で約9〜10GB）は単発のRTX 5080に余裕で収まる。ここをデュアル化すると、PCIe x4経由のレイヤー間通信オーバーヘッドが上乗せされ、結果としてtokens/secは単発より低下します。「2枚使う＝速くなる」という直感が逆転するゾーン。

100B超級のモデルも増えているが、下の表のとおりQ4でも約70〜80GBで、16GB×2＝32GBのデュアル構成には収まらない。デュアル化で変わるのは「収まるかどうか」ではなく、RAMへ逃がす量がどれだけ減るかという点。一方で、14B級で済むタスクなら単発GPU構成のままが効率的というトレードオフは変わりません。

モデルサイズ別VRAM要件と推奨GPU構成

LLMのパラメータ数と量子化レベルから必要VRAMが決まる。デュアルGPU化が意味を持つラインを把握しておくと、ハード投資の判断が早い。

表の数値はQ4・Q8量子化済みGGUFの重みサイズ目安。実機ロード時は num_ctx（コンテキスト長）の指定によってKVキャッシュ分の追加VRAMが必要になるため、表の値より2〜4GBの余裕を持たせる設計が現実的。コンテキスト長を32k以上に伸ばす場合はKVキャッシュだけで数GB単位のVRAMを消費するため、推奨欄の最小ラインでは収まらないケースが出てきます。

Oculink PCIe 4.0 x4はボトルネックか｜実測でわかった本当のボトルネック

Oculinkの帯域はPCIe 4.0 x4＝双方向約64Gbps。一見「PCIe 5.0 x16の8分の1」でボトルネックになりそうですが、実際にレイヤーを分散して動かしてみると、帯域不足を示す挙動は観測されませんでした。

帯域より電源と環境変数が効く

Multi-GPU推論の通信パターンは、層間で活性化テンソルを受け渡すだけ。トークン生成1回あたりの転送量は数MB単位で、PCIe 4.0 x4で十分捌ける量。電源は構成によって扱いが大きく変わる。Oculink ドック (MINISFORUM DEG1 等) は独立した ATX 電源を別途用意する仕様で、メイン PSU と完全に分離される。本検証環境ではメイン PSU 850W が RTX 5080 (TDP 360W) + i7-14700F + 周辺をまかない、Oculink 側は別 PSU 750W が RTX 5060 Ti (TDP 180W) を単独で給電する 2 系統構成。同時フル稼働でも各 PSU が独立に負荷を受け持つため、片側 PSU で合算 540W を負担することはない。一方、PCIe スロット 2 枚に内蔵する一体型構成 (Oculink を使わない場合) では合算 TDP が 1 PSU に集中するため、850W では余裕が薄く 1000W 級が望ましい。

構成別の電源容量目安

RTX 5080のTDPは360W、RTX 5060 Tiは180Wが NVIDIA GeForce RTX 50 シリーズ仕様ページ に記載された公式値。瞬間電力（transient power spike）はTDPの1.5〜2倍に達する場面があり、PSUは定格に加えて余裕を見込むべき。Oculink 2系統構成のメリットは、片側で電源トラブルが起きてもメイン環境を巻き込まないリスク分離にもあります。

マルチGPU環境はソフト設定側がボトルネックになりやすい

別フレームワークでも同じ構造の問題は起きている。たとえばvLLMでは、複数GPU環境で64kトークンを超える長文コンテキストでTTFTやトークン生成速度が急落する現象が報告されており、AITER Unified Attentionのバックエンドを環境変数で明示有効化しないと解消しないケースが知られています。OllamaのOLLAMA_SCHED_SPREADもこれと同型の問題で、ハードよりソフトの設定がボトルネックという構造は共通しているのが現状。

トラブルシューティング｜2枚目が使われないときの確認順序

設定を入れてもなお2枚目のVRAMが増えない、レイヤー分散が成立しないケースでは、以下の順序で切り分けると早いです。ドライバがGPUを列挙できているか（認識）と、Ollamaがそこへモデルを載せているか（配置）は別の問題なので、まずどちらの段階かを判定します。

手順1：nvidia-smiでGPU認識を確認

まず nvidia-smi -L で2枚のGPUがUUID付きでリストされるかを確認する。ここで1枚しか出ない場合は、ドライバ・物理接続・Oculinkドック側の電源のいずれかが原因。Ollama側の問題ではない。Oculinkドックの場合、本体電源を入れ忘れているケースが意外に多い。PCIeリンク状態は nvidia-smi --query-gpu=pcie.link.gen.current,pcie.link.width.current --format=csv で確認でき、Oculink経由なら Gen4 x4 が表示されればリンク正常です。2枚に分かれて動いているかどうかも、推論中に nvidia-smi で各GPUのVRAM使用量を見るのが確実。2枚目が0MBのままなら分散していません。

手順2：ollama psとOLLAMA_DEBUGログを取得

モデルロード中に別ターミナルで ollama ps を叩き、PROCESSOR列を見る。ただしここに出るのは配置率であって、GPU名ではない。公式FAQのとおり「100% GPU」（全部GPUに載った）、「100% CPU」（全部システムメモリ）、「48%/52% CPU/GPU」（一部ずつ）のいずれかの形で表示される。つまりこの列だけでは「2枚に分散したか」までは判定できない（2枚に分散していても、全層が載っていれば「100% GPU」と出る）。知りたいことに応じて使い分ける。

• ざっくりGPUに載ったかだけ見たい → ollama ps のPROCESSOR列（ただし2枚に分かれたかは分からない）
• GPUに何割載ったか数字で見たい → curl http://localhost:11434/api/ps で返るJSONの size_vram を size で割る
• どのGPUに何を割り当てたか見たい → 次の OLLAMA_DEBUG ログ
• 2枚に分かれて動いているか見たい → 推論中に nvidia-smi で各GPUのVRAM使用量（2枚目が0MBのままなら分散していない）

OLLAMA_DEBUG=1 を設定してOllamaを起動し直すと、起動時のスケジューラログにどのGPUを検出したか、各GPUのVRAM空き容量、Compute Capabilityがどう判定されたかが順に出力されます。Ollama 公式トラブルシューティング（docs.ollama.com/troubleshooting）のログ取得手順に、OLLAMA_DEBUG=1 でのデバッグログ出力方法が記載されています。

手順3：Compute Capabilityの互換性確認

Blackwell世代（RTX 50シリーズ）はCompute Capability 12.0、Ada（RTX 40）は8.9、Ampere（RTX 30）は8.6。世代を跨いだ混在ではOllamaがより低い世代の機能セットに合わせるため、新世代側のテンソルコア最適化が部分的に活かせない場合があります。世代差を確認した上で、片方を別マシンに切り分けるかどうかを判断する材料になる。CUDAランタイムとドライバのバージョン整合も同時に確認すべきで、ドライバが古いとBlackwell側がそもそも認識されないケースがあります。

手順4：VRAM空き容量と他プロセスの干渉

2枚目のGPUに他プロセス（ブラウザのGPU支援、Stable Diffusion常駐、ゲームのバックグラウンドプロセスなど）がVRAMを掴んでいると、Ollamaがレイヤー配置を諦めるケースがある。nvidia-smi の VRAM 使用量と Process 一覧を確認し、不要なプロセスを終了させてから再ロードを試す。特にWindowsではDWM（Desktop Window Manager）が数百MB単位でVRAMを使うため、デュアル構成では2枚目をディスプレイ非接続にして純粋にCompute専用にする運用が安定します。

まとめ

Ollamaは、モデルが利用可能ないずれか1枚に収まればその1枚へ、収まらなければ全GPUへ自動で分散します。本検証で2枚目が使われなかったのは1枚に収まるモデルだったためで、全GPUへ広げたい場合に OLLAMA_SCHED_SPREAD が効きました。CUDA_VISIBLE_DEVICES は使うGPUを限定する設定、num_gpu は総オフロード層数の指定です。70B級ではVRAMに常駐できる割合が上がってRAM側の負担が減る一方、14B級では単発GPUの方が速いというトレードオフを把握した上で、自分のワークロードに合うかを判断するのが現実的な使い方です。

電源は構成で前提が変わります。Oculink (MINISFORUM DEG1 等) を介する場合はドック側に独立 ATX 電源 (本検証では 750W) を別途用意する仕様で、メイン PSU (本検証では 850W) は RTX 5080 と CPU の負荷だけを受け持つ 2 系統構成になる。両 PSU が独立しているため、合算 TDP が片方に集中することはない。逆に PCIe スロット 2 枚に内蔵する一体型構成では 1 PSU が合算約720W を捌くため、1000W が最低ライン・1200W で余裕が出ます。Oculink 帯域は思ったほどボトルネックにならず、ソフトの設定不足の方が現実的なボトルネック、というのが実機検証の結論。

参考資料

• Ollama 公式 GPU ドキュメント（複数GPU・CUDA_VISIBLE_DEVICES設定）
• Ollama FAQ（環境変数の永続化・デバッグログ取得）
• Ollama Modelfile リファレンス（PARAMETER の書式。2026-08-09 時点で num_gpu の記載なし）
• Ollama 公式リポジトリ Issue #13986（Modelfile パラメータとしての num_gpu の記載復活を求めるIssue・2026-08-09 時点で open）
• Ollama 公式モデルライブラリ（各モデルのVRAM要件）
• NVIDIA CUDA GPUs 一覧（Compute Capability）
• NVIDIA GeForce RTX 50 シリーズ公式仕様

計測時点: 2026-05-03 / 本ページの計測は上記時点のもの。製品アップデートや第三者ベンチマーク公表により評価が変わる可能性があります。30日以上経過した内容は再検証を推奨します。