WindowsでローカルLLMを複数GPUで動かす方法｜VRAM・runtimeの選び方

結論：VRAMの容量を足しただけでは動作は決まらない

1台のPCに複数GPUを取り付けても、VRAMがWindows共通の一枚のメモリになるわけではありません。推論runtimeがモデルの重みや処理をGPUごとに割り振ることで、1つのモデルが単体GPUより大きなVRAM範囲を使える場合があります。複数GPUを認識しないruntimeでは、2枚挿しても1枚分しか使われません。

「モデルが載るか」と「速くなるか」は別の判断です。モデルの重みだけでなく、contextに応じたKV cache、runtimeの作業領域、起動中の他アプリがVRAMを使います。2枚の合計容量を、そのままモデルに使える容量と見積もらず、load時に空いている領域とruntimeの割り当てを確認してください。

• GPUオフロードの基本 - 一つのGPU内でCPUとGPUへ処理を分ける仕組みを見る
• 複数PCでローカルAIを使うNVIDIA PAIR - PC間の独立したrequest振り分けとの違いを確認する

Ollamaとllama.cppはGPUの割り当て方が違う

複数GPUへの割り当てはWindowsの共通設定ではなく、推論runtimeの機能です。たとえば現在のOllama FAQは、必要なVRAMが一枚のGPUに収まる場合はそのGPUに載せ、どの一枚にも収まらない場合は利用可能なGPUへ分散すると説明しています。llama.cppはdeviceと分割方式を持ち、同じPCのGPUを明示して使えます。これらの挙動を他のGUIアプリやbackendにも当てはめないでください。

llama.cppの公式multi-GPU guideではlayer方式が既定です。tensor方式は実験的とされ、対応architectureやbackendに制約があり、GPU間の接続が遅いと単一GPUより遅くなる場合があります。tensorを選べば常に速い、という意味ではありません。LM Studioの公式docsはmodel単位のGPU offloadなどを設定できると説明していますが、それだけで特定版の複数GPU分割まで確認できるわけではありません。

• Ollama公式FAQ: 複数GPUへの配置とollama ps - 空きVRAMに応じた配置とCPU/GPU表示を確認する
• LM Studio per-model defaults - model単位のload設定を確認し、device分割とは分けて考える
• llama.cpp公式multi-GPU guide - split mode、device選択、制約を使用中の版で確認する
• Windowsでllama.cppを使う方法 - Windows用binaryとbackendの選び方を見る

2枚目を買う前にPC側の条件を確認する

2枚目のGPUは、カードそのものだけでなく、マザーボードの空きslotとlane、電源容量と補助電源、ケース内の寸法、排熱、driver、必要なbackendをまとめて確認します。片方のGPUが画面出力や他のアプリにも使われていれば、推論開始時の空きVRAMも変わります。

• Windowsのデバイス一覧でGPUの型番とdriverを確認し、推論アプリが対応するbackendを持つか調べる。
• マザーボードの説明書で、2枚を同時に挿した時のslotとPCIe laneの割り当てを調べる。
• 電源の定格、必要な補助電源端子、ケースのカード長とslot幅、吸排気の余裕を確認する。
• 異なるGPUを組み合わせる場合は、使用するruntime/backendが両方を同時に認識するか先に確認する。
• モデルが現在の1枚に収まるなら、まず単一GPUの基準を測り、2枚目が解決する具体的な問題を決める。

購入後にカードが認識されることと、想定どおりの分割でモデルが動くことは別です。先にruntime側でdeviceが見えるかを確かめてから、model loadと負荷の確認へ進みます。

• ローカルAI用PCスペックの見方 - RAM、GPU、VRAM、電源と用途を整理する
• eGPUでローカルAIを使う前の確認 - ノートPCのUSB4・Thunderboltとケースを照合する
• 中古PC・GPU構成を購入前に確認 - PC全体の条件を買う前に見直す

単一GPUと複数GPUを同じ条件で比べる

比較する時はmodel、quantization、context長、prompt、出力token数をそろえます。modelをloadできたか、生成速度、peak VRAM、system RAM、回答が完了したかを別々に記録してください。複数GPUでは起動時間やGPU間通信も加わるため、単一GPUの結果より遅くても、容量が必要なmodelを載せる目的は達成できる場合があります。

1. GPUごとの型番、driver、runtime/binaryの版、backendを記録する。
2. 一枚のGPUで動く同じmodelと短いpromptを使い、単一GPUのbaselineを測る。
3. multi-GPUのdevice認識と実際の割り当てを確認し、memory使用量をGPUごとに記録する。
4. 同じmodel、quantization、context、promptで複数回測り、初回loadと定常生成を分ける。
5. 起動可否、model容量、生成速度、安定性のどれが改善したかを個別に判定する。

llama.cppの分割方式やGPU間転送は計測結果に影響します。CUDAのpeer-to-peer設定など低レベルのoptionを、不安定時の回避策として盲目的に有効化しないでください。使用するbackendとmotherboard/BIOSの公式条件を照合し、小さな同一テストで確認します。

• ローカルAIの速度・RAM・VRAMを測る方法 - 同じ条件で速度とmemoryを記録する方法を見る
• ローカルAI用PCスペック - model、RAM、GPUの容量を用途から見直す

GPUを認識しない・遅い時の切り分け

GPU使用率が一時的に上がったことだけでは、モデル全体が複数GPUに適切に分散したとは判断できません。runtimeのload表示と各GPUのmemory、同一promptの生成結果を合わせて見ます。

• OllamaでGPUが使われない時 - GPU backend全般の確認へ進む
• ローカルAIのトラブル解決ハブ - 起動、load、速度の症状別に切り分ける