デュアルGPUでローカルLLMを動かす｜Ollama自動分散の実測と二枚目が遊ぶ落とし穴（RTX 5080+5060 Ti）

ローカルで大きめの言語モデルを動かそうとすると、最初にぶつかる壁が VRAM の容量だ。16GB のグラフィックボード一枚では、配布サイズで 24GB あるようなモデルはそのままでは載りきらない。利用可能な GPU の VRAM に収まりきらず CPU オフロードが発生すると、システム RAM 側の処理がボトルネックになり、生成速度が大きく落ちやすい。

そこで「もう一枚足してデュアル GPU（2 枚構成）にし、二枚分の VRAM に載せればいいのでは」と考える。筆者の RTX 5080（16GB）+ RTX 5060 Ti（16GB、Oculink 接続）で実際に試したところ、結論はシンプルだった。Ollama は特別な設定をしなくても、一枚に載らない大型モデルを自動で二枚の GPU に分散してロードする。実測で qwen3.5:35b-a3b が約 93 tokens/sec、gemma4:26b が約 109 tokens/sec 出た。この記事では、その実測値と測定条件を示したうえで、検証の途中で筆者がハマった「二枚挿しているのに二枚目が遊んでしまう」落とし穴も共有する。

先に結論

• 16GB 一枚に載らないサイズのモデルでも、Ollama は設定なしで自動的に複数 GPU へ分散する。これは Ollama 公式 FAQ の説明どおりで、実測でも確認できた。
• 複数 GPU へ広げる OLLAMA_SCHED_SPREAD=1 という設定はあるが、今回の構成・モデル・単独実行の条件では付けても付けなくても速度はほぼ同じだった（別の GPU 構成や同時ロード状況では変わり得る）。
• むしろ注意したいのは、複数の Ollama サーバや別の GPU 負荷が併存する状態では、期待どおりに二枚へ分散されず、CPU オフロードを伴って大幅に遅く見える場合があること。筆者環境でも、余分なサーバを終了したあとに 100% GPU で安定動作することを確認した（この遅さを一度「設定の効果」と誤認しかけた）。

測定環境と測定条件

後述するとおり、この手の測定は環境の影響を強く受ける。条件を開示しておく。

コンテキスト長を固定したのは、Ollama が使える VRAM 量に応じて既定のコンテキスト長を変える（24GiB 未満で 4K、24〜48GiB で 32K など）ため、条件をそろえないと比較が崩れるからだ。

測ったモデル：配布サイズと実測 VRAM は別物

今回測ったのは、いずれも 16GB 一枚には収まらないサイズの二モデルだ。配布されているモデルファイルのサイズと、実際に動かしたときの VRAM 使用量は別である点に注意したい。実行時にはモデルの重みに加えて、コンテキスト長に応じた KV キャッシュや実行用バッファが乗る。

どちらも MoE（混合エキスパート）型で、総パラメータのうち毎回使われるのは一部だけ、という構造だ。配布サイズの時点で 16GB を超えているため、一枚には載りきらない。

設定なしでも、Ollama は自動で二枚に分散していた

環境変数を何も指定しない既定のまま、二モデルを動かしたときの実測がこれだ。GPU 別の VRAM 使用量は nvidia-smi、GPU/CPU の割合は ollama ps の PROCESSOR 列で確認している。

二枚目の RTX 5060 Ti にもしっかり VRAM が割り当てられ、ollama ps は 100% GPU と表示された。つまり 一枚に載らないモデルは、設定をしなくても二枚に分散され、CPU に落ちることなく動いている。これは Ollama 公式 FAQ の「単一 GPU に収まらない場合は利用可能な複数 GPU に分散する」という説明と一致する。生成速度も 3 回測定で範囲が ±2 程度に収まり、安定していた。

OLLAMA_SCHED_SPREAD は付けても変わらなかった

複数 GPU へモデルを広げる設定として OLLAMA_SCHED_SPREAD=1 がある。これを付けて同じ条件で測り直したが、結果はほとんど変わらなかった。

3 回測定の範囲は重なっており、今回の測定条件では OLLAMA_SCHED_SPREAD=1 による実用上明確な速度向上は確認できなかった。設定なしで既に二枚へ自動分散されているのだから、当然ともいえる。OLLAMA_SCHED_SPREAD=1 はモデルを利用可能な複数 GPU にまたがって配置するための設定として実在するが、今回のように一枚に収まらないモデルを、空いている二枚の GPU で単独実行する条件では、設定なしでも自動分散され、速度差はほとんど見られなかった。必要性は、Ollama のバージョン、GPU 構成、同時にロードされているモデルや利用可能 VRAM の状態によって変わり得る。

落とし穴：二枚目が使われないときは、余分な Ollama サーバーや GPU 負荷を疑う

ここが、この記事でいちばん共有したい部分だ。実は筆者は最初、まったく逆の結論を出しかけていた。「設定なしだと二枚目が使われず遅い、設定を入れたら速くなった」と。後から測り直して、それが測定環境の誤りだったと分かった。

振り返ると、測定環境を汚していたことが影響したとみられる。常駐している既定のサーバ（ポート 11434）に加えて、検証用に別ポート（11500 など）のサーバをいくつか起動したままにしていた。複数の Ollama サーバが同時に存在する状態で、対象モデルが二枚に正しく載らなくなっていた。なお、以下の比較では、生成リクエストと Ollama 側の状態確認（ollama ps / API）を同じサーバのエンドポイント（http://localhost:11500）に対して行った。nvidia-smi はポート単位の確認ではなく、システム全体で各 GPU の VRAM 使用量とプロセス状況を見るために用いている。余分なサーバが残っていた状態と、すべての Ollama を終了して対象サーバを一つだけにした状態を、同じモデル・同じ条件で比べたのが次だ。

# 余分なサーバが残っていた状態
# 生成リクエストと ollama ps / API の対象: http://localhost:11500
# nvidia-smi はシステム全体の各 GPU 使用状況を確認
ollama ps : qwen3.5:35b-a3b   45%/55% CPU/GPU
nvidia-smi: RTX 5080 使用 / RTX 5060 Ti = 0 MB（システム全体）
生成速度  : 8〜17 tok/s（測定ごとに 2.8〜17 と乱高下）

# 他の Ollama をすべて終了し、サーバ一つだけで再測定
# 生成リクエストと ollama ps / API の対象: http://localhost:11500
ollama ps : qwen3.5:35b-a3b   100% GPU
nvidia-smi: RTX 5080 = 14.3 GB / RTX 5060 Ti = 13.0 GB（システム全体）
生成速度  : 93.7 tok/s（93.6〜95.6 で安定）

特定ポートのサーバだけを確認したいときは、OLLAMA_HOST で対象を指定して問い合わせるとよい。次のようにすると、そのポートのサーバ上で動いているモデルの状態だけを確認できる。

$env:OLLAMA_HOST = "http://localhost:11500"
ollama ps
# または
Invoke-RestMethod http://localhost:11500/api/ps

同じポート・同じモデルでも、余分なサーバを落とすだけで二枚目に VRAM が乗り、CPU オフロードが消えて速度が安定した。この結果から、検証中に併存していた Ollama サーバや GPU の利用状態が、二枚への分散配置を妨げていた可能性が高い。ただし、取得したログだけでは、どのプロセスがどの GPU のメモリを占有し、なぜ二枚目への配置が行われなかったのかまでは切り分けきれていない。原因の確定にはもう一段の調査が要る、というのが正直なところだ。それでも実用上の教訓ははっきりしている。「二枚目が使われない」「遅い」と感じたら、まず Ollama のサーバが二重に起動していないかを疑う。確認は ollama ps の PROCESSOR 列（100% GPU になっているか）と、nvidia-smi で各 GPU の VRAM 使用量・プロセス状況を見るのが有効だ。ただし原因の特定までは、Ollama のログやプロセス単位の確認も要る場合がある。設定をいじる前に、まずここを押さえたい。

Oculink x4 接続でも実用速度は出た

二枚目を Oculink（MINISFORUM DEG1、PCIe 4.0 x4）でつないでいる点を気にする人もいるだろう。理論帯域でいえば、同世代の PCIe 4.0 x16 接続と比べれば約 4 分の 1、GPU 0 側の PCIe 5.0 x16 接続と比べれば約 8 分の 1 にあたる。

それでも今回の測定では、この Oculink 接続の二枚目に 13GB 前後を載せた状態で qwen3.5:35b-a3b が 93 tok/s 出ている。少なくとも今回の構成では、Oculink 接続の二枚目を使いながら、対象モデルを CPU オフロードなしで動かし、実用的と感じられる生成速度を確認できた。

ただし注意したいのは、本記事では同じ GPU を PCIe x16 で直結した場合との比較は行っていないことだ。そのため、Oculink の帯域が性能にまったく影響していない、とまでは断定できない。各層の行列そのものを二枚で割って同時計算するテンソル並列のような方式では、GPU 間の通信量が増えて帯域の影響が出やすいとされるが、これは本記事では実測していないため一般的な傾向の紹介にとどめる。今回確認できたのは、あくまで「モデルが二枚に分散して配置され、CPU オフロードなく動いた」ことである。

一枚に収まるモデルは、無理に二枚へ広げなくてよい

ここまでは「一枚に載らない」モデルの話だった。逆に、最初から 16GB 一枚に収まるサイズのモデル（量子化された 12B 前後まで）なら、二枚に広げる意味は薄い。Ollama 公式も、単一 GPU に完全に収まる場合は、PCIe 越しの転送を減らせるぶん通常は一枚に載せたほうが高性能だと説明している。分散はあくまで容量が足りないときの手段で、収まるものは素直に一枚で動かすのがよい。

大容量カード一枚と、16GB 二枚はどちらが得か

VRAM を増やすだけが目的なら、48GB を積んだプロ向けカード一枚という手もある。一枚で完結するなら分散にまつわる気遣い（サーバの二重起動による取り合いなど）はそもそも不要で、運用もシンプルだ。問題は価格で、48GB クラスの単体カードは 16GB のコンシューマ機を二枚そろえるより大幅に高くつく。

判断の分かれ目は「すでに一枚持っているか」だろう。手元に 16GB のボードがあって、もう一枚足すだけで大型モデルに手が届き、追加コストや電源・接続条件を満たせるなら、筆者環境では二枚構成が実用になった。費用対効果は、既存パーツや地域ごとの価格、電源・筐体・接続機材の有無で変わる。今回の RTX 5080 + RTX 5060 Ti のように、世代もグレードも違う二枚でも、Ollama が自動で分散して問題なく動いた。逆に一から組むなら、予算が許せば大容量カード一枚に寄せたほうが後々シンプルではある。

まとめ

• 16GB 一枚に載らない大型モデルでも、Ollama は設定なしで自動的に二枚の GPU へ分散してロードする（公式 FAQ どおり）。実測で qwen3.5:35b-a3b が約 93 tok/s、gemma4:26b が約 109 tok/s（num_ctx=4096、筆者環境）。
• OLLAMA_SCHED_SPREAD=1 は今回の測定条件では速度に大きな差が出ず、追加設定なしで自動分散が機能した（必要性は GPU 構成や同時ロード状況で変わり得る）。
• 「二枚目が使われない・遅い」と感じたら、まず余分な Ollama サーバや別の GPU 負荷が残っていないかを ollama ps と nvidia-smi で確認する。筆者はこの遅さを設定効果と誤認しかけた。
• Oculink（PCIe 4.0 x4）接続の二枚目でも実用速度は出たが、x16 直結との比較はしていないため帯域の影響は断定しない。
• 数値は Ollama 0.23.3・特定構成での結果であり、バージョンや構成で変わり得る。

関連記事も参考にしてほしい。二枚構成での Ollama の認識・スケジューリングはOculink GPU の認識・設定、Oculink（PCIe 4.0 x4）の帯域実測はMINISFORUM DEG1 の実機レビュー。単一 GPU での VRAM 消費と速度の基準値はRTX 5080 での推論モデル実測、RTX 5060 Ti 単体の LLM 性能はRTX 4070 Super vs RTX 5060 Ti の実測比較。大型モデルをローカルで動かす個別ガイドはQwen3.6-27B をローカル GPU で動かすや低 VRAM で大型 MoE を動かす、実行基盤の前提はllama.cpp 対応プラットフォーム、画像生成側の二枚運用はComfyUI のデュアル GPU 運用ガイド。そもそもローカル LLM をなぜ動かすのかはローカル LLM 入門（Ollama × Gemma）も合わせてどうぞ。