Oculink接続のGPUがOllamaに認識されない原因｜デュアル GPU 化で初めて出る現象と OLLAMA_SCHED_SPREAD

.key-facts-table{border-collapse:collapse;width:100%;margin:1.2em 0;font-size:.95em;background:#fff;border:1px solid #e5e7eb;border-radius:6px;overflow:hidden} .key-facts-table th,.key-facts-table td{padding:.6em .85em;border-bottom:1px solid #eef0f3;vertical-align:top;text-align:left} .key-facts-table tr:last-child th,.key-facts-table tr:last-child td{border-bottom:none} .key-facts-table tr.kf-section th{background:#eef2ff;font-weight:600;border-bottom:2px solid #c7d2fe;color:#1e1b4b;padding:.75em .85em;font-size:1em} .key-facts-table tr:not(.kf-section) th{width:32%;font-weight:500;color:#555;background:#fafbfc;font-size:.93em} .key-facts-table tr:not(.kf-section) td{color:#222} .key-facts-table code{background:#f1f5f9;padding:.05em .35em;border-radius:3px;font-size:.92em;font-family:Consolas,monospace;color:#0f172a}

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

NVIDIAドライバが2枚のGPUを正しく認識しているのに、Ollamaは1枚目しか使わない。Oculink増設環境で頻発する現象です。当サイトの検証環境（RTX 5080 16GB + Oculink DEG1経由のRTX 5060 Ti 16GB / i7-14700F / RAM 96GB）でも、ollama ps 出力に2枚目のGPUが現れず、レイヤー分散が成立しないまま単発GPUで推論する状態が再現しました。Ollama 0.22.1・NVIDIAドライバ 596.21・Windows 10という最新の組み合わせでも同じ挙動が観測できました。

RTX 5060 TiがOllamaから見えない「DUAL_GPU_NOT_CONFIGURED」現象

検証環境を組んだ直後、nvidia-smiでは2枚のGPUがどちらも認識されるのに、Ollamaの推論ジョブは1枚目しか使わない。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。同じ構成でモデルサイズを変えても、デフォルト設定のまま2枚目を使わせる挙動には誘導できませんでした。

公式ドキュメントとGitHub issueから見えてくる既知問題

複数GPU環境ではCUDA_VISIBLE_DEVICESとUUID指定で明示認識させる手順が Ollama 公式 GPU ドキュメント に示されている。一方GitHub issue #13163では、Blackwell世代（Compute Capability 12.0）が自動認識されない既知問題が報告されています。今回の現象はOculink固有ではなく、新世代GPU+Ollamaのスケジューラ仕様の組み合わせで発生している、と判断できます。各世代のCompute Capabilityは NVIDIA CUDA GPUs 公式一覧 で参照できます。

回避手順｜3つの環境変数を段階的に検証する

回避策は3段構え。最小構成はCUDA_VISIBLE_DEVICESの指定だけで動くケースもあるが、Ollamaのスケジューラがレイヤー分散を選ばない場合はOLLAMA_SCHED_SPREADも追加する必要があります。

CUDA_VISIBLE_DEVICESとUUID指定（公式推奨）

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

num_gpu_split / OLLAMA_SCHED_SPREADの役割

num_gpu_split はモデルロード時にレイヤーを何分割で配置するかを指定するパラメータ。OLLAMA_SCHED_SPREAD=1 はOllamaのスケジューラに「複数GPUへの分散を優先せよ」と指示する環境変数。前者がモデル単位、後者がジョブ単位の挙動制御という棲み分けです。num_gpu_splitの記述形式は Ollama Modelfile リファレンス のPARAMETER節で定義されており、Modelfileに記述してビルドし直すか、APIリクエストのoptionsで都度指定する形になります。

設定組み合わせの動作可否

3段階目（OLLAMA_SCHED_SPREAD有効化）まで進めて初めて、RTX 5060 Tiにレイヤーが配置されました。これは公式ドキュメントの推奨フローと一致します。

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

CUDA_VISIBLE_DEVICES と OLLAMA_SCHED_SPREAD はプロセス起動時に評価されるため、Ollama をサービスとして動かしている場合、ユーザー環境変数を更新しただけでは反映されない。Ollama 公式 FAQ では、Windows では setx でシステム環境変数を設定した後にサービスを再起動する手順、Linux では systemctl edit ollama.service でユニットファイルに Environment= を追加する手順がそれぞれ示されています。

Windows サービスとして登録した Ollama を停止 → 環境変数編集 → 再起動する流れは、PowerShell から net stop ollama; setx OLLAMA_SCHED_SPREAD 1 /M; net start ollama の三段で完結します。/M フラグはシステム全体のスコープに書き込む指示で、これを付けないとログオフ時に消えるユーザースコープ扱いになり、サービス側の環境では参照できません。

Modelfile 経由で num_gpu_split を埋め込んだカスタムモデルをビルドする場合は、ollama create でタグを切り直し、推論時にそのタグを指定する流れになる。コマンドラインから一回限り適用したいケースでは、APIリクエストの options に { “num_gpu_split”: [16, 16] } を渡す方法でも同じ効果が得られます。

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

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

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

70Bクラス：VRAM拡張で初めて動かせる

70BパラメータのモデルはGGUF Q4量子化でも約40GBを必要とする。RTX 5080単体（VRAM 16GB）では絶対に乗らないため、Oculink経由で2枚目を増設してVRAM 16GB+16GB＝合計32GB相当に拡張すれば、ようやく動作可能になります。tokens/secは単発時より落ちますが、そもそも単発では動かないので「動くか動かないか」のレイヤーで意味があるという話。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枚使う＝速くなる」という直感が逆転するゾーン。

128B級モデル（Mistral Medium 3.5など）も登場しており、VRAM 32GB相当を必要とするユースケースは確実に増えている。70B〜128B級を「自宅で動かしたい」という需要側の文脈は、デュアルGPU化の動機を下支えする要因の1つ。一方で、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枚目が見えない、レイヤー分散が成立しないケースでは、以下の順序で原因を切り分けると効率的。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：ollama psとOLLAMA_DEBUGログを取得

モデルロード中に別ターミナルで ollama ps を叩き、PROCESSOR列にGPU割当が表示されるかを確認。GPU割当が「100% GPU」や「partial offload」のみで複数GPU名が出ていなければ分散していない。OLLAMA_DEBUG=1 を設定してOllamaを起動し直すと、起動時のスケジューラログにどのGPUを検出したか、各GPUのVRAM空き容量、Compute Capabilityがどう判定されたかが順に出力されます。Ollama FAQ のログ取得セクション にデバッグ手順が記載されています。

手順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のOculinkデュアルGPU構成は「自動では成立しない」が前提。CUDA_VISIBLE_DEVICESでデバイスを明示し、OLLAMA_SCHED_SPREADで分散を強制し、必要に応じてnum_gpu_splitで比率調整する3段階を踏んでようやく動く仕組み。70B級でVRAM拡張効果が得られる一方、14B級では単発GPUの方が速いというトレードオフを把握した上で、自分のワークロードに合うかを判断するのが現実的な使い方です。

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

参考資料

• Ollama 公式 GPU ドキュメント（複数GPU・CUDA_VISIBLE_DEVICES設定）
• Ollama FAQ（環境変数の永続化・デバッグログ取得）
• Ollama Modelfile リファレンス（num_gpu_split等のPARAMETER）
• Ollama 公式モデルライブラリ（各モデルのVRAM要件）
• NVIDIA CUDA GPUs 一覧（Compute Capability）
• NVIDIA GeForce RTX 50 シリーズ公式仕様

当サイトはAmazonアソシエイト・プログラムの参加者です。Amazonのアソシエイトとして、当サイトは適格販売により収入を得ています。

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