GPU 2枚挿しでローカルAIを使い倒す〜RTX 3090+RTX 3060の同時運用実例
先に、この記事で使っている2枚を挙げておきます。どちらも中古で入手したものです。
【中古】MSI GeForce RTX 3090 GAMING X TRIO 24GB:Amazon楽天市場Yahoo! 【中古】ELSA GeForce RTX 3060 12GB:Amazon楽天市場Yahoo!2枚挿しで何ができるのか
GPUを2枚挿したとき、実際に使えるパターンは大きく3つあります。 パターン1: タスクの分離 GPU0(RTX 3060)でOllamaの8Bチャットモデルを動かしながら、GPU1(RTX 3090)でComfyUIの画像生成を同時に回す。これが私の日常的な使い方です。チャットしながら画像を待てるので、作業効率が段違いです。 パターン2: モデルの同時実行 GPU0(RTX 3060)で8Bモデル、GPU1(RTX 3090)で27Bモデルを同時に立ち上げる。軽い質問は8Bに投げて、込み入った相談は27Bに投げる。用途に応じた使い分けが1台のPCで完結します。 パターン3: 大型モデルの分散ロード 24GBに収まらないモデルを、Ollamaが自動的に2枚のGPUに分散して載せる。これについては次のセクションで詳しく説明します。 重要な点を1つ。VRAMは統合されません。 RTX 3090の24GBとRTX 3060の12GBが合体して36GBになる、ということは起こりません。各GPUは独立したメモリ空間を持っています。NVLinkで接続すればVRAMプールを共有できるケースもありますが、RTX 3090とRTX 3060の組み合わせではNVLinkは使えません。VRAMは統合されないが、Ollamaは自動分散する
VRAMが統合されないなら、24GBを超えるモデルは動かないのか。答えは「Ollamaなら動く」です。 たとえば qwen3.5:27b は、モデル全体で約17.4GBのVRAMを必要とします。RTX 3090の24GBには収まりますが、RTX 3060の12GBには入りません。では2枚挿し環境でロードするとどうなるか。 Ollamaはモデルのレイヤーを自動的に複数GPUに分配します。qwen3.5:27b の場合、RTX 3090に17.9GB、RTX 3060に8.4GB、合計26.2GBとして分散ロードされました。これはユーザーが設定で指定するのではなく、Ollamaが空きVRAMを見て自動的に判断します。 この仕組みのおかげで、1枚のGPUに収まらないような巨大モデルでも、2枚に分散すれば動くのです。ただし2枚のGPU間でデータを転送する必要があるため、1枚に全部載る場合と比べるとオーバーヘッドが発生します。このオーバーヘッドがどの程度なのかは、次のベンチマークデータで確認できます。ollama run qwen3.5:27b と打つだけで、勝手に最適な配分でロードされます。実測データ: 基本性能
私のPCにはRTX 3090とRTX 3060が挿さっています。 各GPU・各モデルの基本的な性能データです。| GPU | モデル | VRAM使用 | 生成速度 (tok/s) | コールドスタート | システム消費電力 |
|---|---|---|---|---|---|
| RTX 3090 | gemma4 | 21.6GB | 133.0 | 11.0秒 | ~299W |
| RTX 3090 | qwen3.5:27b | 18.2GB(分散) | 25.5 | – | ~258W |
| RTX 3090 | qwen3:8b | 10.3GB | 126.4 | 2.1秒 | ~295W |
| RTX 3060 | qwen3:8b | 5.5GB | 60.1 | 2.1秒 | ~170W |
| RTX 3060 | qwen3.5:9b | 7.9GB | 46.6 | 7.2秒 | ~337W |
| 同時実行 | 3060:8B + 3090:27B | 8.4+18.2GB | 119+25.5 tok/s | – | ~374W |
衝撃の並列テスト結果
qwen3:8b on RTX 3090 の並列テスト
| 並列数 | 1リクエストあたり tok/s | 合計スループット (tok/s) | 速度低下 |
|---|---|---|---|
| 1 | 126.4 | 126 | baseline |
| 8 | 125.8 | 1,006 | -0.5% |
| 16 | 127.2 | 2,035 | +0.6% |
| 32 | 125.7 | 4,021 | -0.6% |
| 64 | 125.5 | 8,034 | -0.7% |
| 128 | 125.6 | 16,081 | -0.6% |
qwen3.5:27b の並列テスト(RTX 3090 + RTX 3060 の2GPU分散)
| 並列数 | 1リクエストあたり tok/s | 合計スループット (tok/s) | 速度低下 |
|---|---|---|---|
| 1 | 25.5 | 26 | baseline |
| 4 | 26.1 | 105 | なし |
| 8 | 26.2 | 209 | なし |
なぜこんな結果になるのか
この「並列数を増やしても速度が落ちない」という挙動は、LLMの推論がどう動いているかを理解すれば納得できます。 モデルの重み(パラメータ)はGPU上に1回だけロードされます。 10.3GBのモデルデータは、1リクエストだろうが128リクエストだろうが同じ10.3GBです。増えるのは各リクエストのKVキャッシュ(会話の文脈を記憶するためのメモリ)だけで、短い会話なら1リクエストあたり数MB程度にとどまります。 LLM推論のボトルネックは、GPUの演算能力ではなくメモリ帯域です。モデルの重みをVRAMから読み出す速度がボトルネックになっています。複数リクエストがあっても、重みの読み出しは1回で済むため、並列数が増えても1リクエストあたりのコストがほとんど増えないのです。並列処理のトレードオフ: コンテキスト長
「並列数を増やしても速度が落ちない」と書きましたが、速度が落ちる要因はあります。並列数ではなく、プロンプト(入力文)の長さです。qwen3:8b on RTX 3090: プロンプト長と速度の関係
| プロンプト長 | 日本語文字数の目安 | 生成速度 (tok/s) | 変化 |
|---|---|---|---|
| 57 tok | ~60字 | 127.8 | baseline |
| 381 tok | ~400字 | 126.3 | -1.2% |
| 1,821 tok | ~1,800字 | 119.7 | -6.3% |
| 3,621 tok | ~3,600字 | 115.8 | -9.4% |
| 7,221 tok | ~7,200字 | 108.2 | -15.3% |
| 18,021 tok | ~18,000字 | 91.1 | -28.7% |
マルチターン会話の場合
実際のチャットでは、1回の入力が長いのではなく、短いやり取りが何度も積み重なります。15ターン(4,557トークン)の会話を行ったところ、速度低下はわずか-0.6%でした。 これはOllamaのKVキャッシュ再利用のおかげです。過去の会話履歴を毎回ゼロから処理し直すのではなく、キャッシュされた結果を再利用するため、ターン数が増えてもオーバーヘッドが小さく抑えられます。コンテキスト上限に達したらどうなるか
Ollamaにはモデルごとのコンテキスト上限があります。この上限に達したときの挙動は、意外と知られていません。 セッションは止まりません。エラーも出ません。 上限を超えると、Ollamaは古い会話履歴を黙って捨てます。警告なしに、会話の冒頭から順に削除されていきます。ユーザーから見ると「さっき話したこと覚えてないな」という形で表面化します。 コンテキスト上限はVRAMの空き容量で実質的に決まります。モデル本体のVRAM使用量を引いた残りが、KVキャッシュに使える容量にあたります。そしてここに、並列処理とのトレードオフが生まれます。27Bモデルの並列数 vs コンテキスト長
qwen3.5:27b(ロード時合計26.2GB、KVキャッシュ用の空き約10GB)の場合:| 並列数 | 1リクエストあたりのコンテキスト上限 | 日本語文字数の目安 |
|---|---|---|
| 1 | ~24,000 tok | ~24,000字 |
| 4 | ~6,000 tok | ~6,000字 |
| 8 | ~3,000 tok | ~3,000字 |
グラフ: 並列数と合計スループット
このグラフの見方: バーが長いほど合計スループット(1秒間に全リクエストが生成するトークンの合計)が大きい。並列数を増やしてもバーが比例して伸びている=ほぼ完璧な線形スケーリングを意味します。128並列で16,081 tok/sは圧巻です。 ★ qwen3:8b on RTX 3090(24GB)で計測。2026年4月実測。 27Bモデル(qwen3.5:27b、RTX 3090+3060分散)でも同じ傾向で、8並列で合計209 tok/s、1リクエストあたりの速度低下はゼロでした。 「128並列で16,081 tok/s」という数字はベンチマーク上の最大値であり、実際に128人が同時にチャットすることは家庭利用では考えにくいです。しかし、8〜16人の同時利用なら現実的で、その範囲で速度低下が1%以下というのは、小規模なチーム利用にも十分耐えうることを示しています。コスト比較: ローカルAI vs クラウドAI
最後に、コストを比較します。「GPUに投資する意味が本当にあるのか」を数字で検証します。2026年4月時点の価格をもとにしています。| 構成 | 初期費用 | 月額コスト | 同時ユーザー数 | モデル品質 |
|---|---|---|---|---|
| ChatGPT Plus × 1人 | 0円 | 3,000円 | 1人 | GPT-5系 |
| ChatGPT Plus × 8人 | 0円 | 24,000円 | 8人 | GPT-5系 |
| RTX 3090中古 + RTX 3060中古 | ~17万円 | 電気代 ~5,000円 | 8人(27B)/ 128人(8B) | 27B or 8B |
年間コスト比較(8人利用の場合)
【中古】MSI GeForce RTX 3090 GAMING X TRIO 24GB:Amazon楽天市場Yahoo! 【中古】ELSA GeForce RTX 3060 12GB:Amazon楽天市場Yahoo!- ChatGPT Plus × 8人: 月24,000円 × 12ヶ月 = 年間288,000円
- ローカルAI(2枚挿し): 初期費用17万円 + 電気代 月5,000円 × 12ヶ月 = 初年度23万円、2年目以降6万円
- 差額: 初年度で5.8万円、2年目以降は22.8万円お得
- プライバシーが重要: 社内文書や個人情報を含むデータを外部に送りたくない
- 多人数で使う: 家族やチームの人数分だけサブスクが増えるクラウドに対し、ローカルは何人使っても追加費用ゼロ
- オフライン利用: ネット環境が不安定でも確実に動く
- カスタマイズ: モデルの選択やファインチューニングが自由
2枚挿しで、GPU以外に必要になるもの
GPUを買い足すと、それだけでは動きません。実際に自分がつまずいた順に挙げます。
電源が足りなくなります。RTX 3090単体で350W、そこに3060を足すと合計で700Wを超える構成になります。電源の容量は、GPUの消費電力を合計したうえで余裕を見て選ぶことになります。
ストレージが思ったより早く埋まります。効いてくるのは、たいていモデルではなく作ったもののほうです。画像生成を回すと1日で数百枚、動画に手を出すと一気に数十GB単位で消えます。モデル自体は2〜3本置けば足りることが多く、何十本も抱えるのは私のように比較をやる場合の話です。
2枚挿すと熱がこもります。ケース内のエアフローと、GPUを外して戻すときのグリスも要ります。
そして、埃がたまります
ファンが増えるということは、吸い込む空気の量が増えるということです。GPUを2枚にしてから、ヒートシンクの隙間に埃が詰まるのが早くなりました。詰まれば温度が上がり、温度が上がればクロックが下がります。
まず、飛ばすもの。ガス缶は手軽ですが、使い続けると本数がかさみます。
飛ばしただけだと、埃は部屋の中を回って戻ってきます。吸う側も要ります。
ヒートシンクの間に詰まったものは、風では抜けません。かき出す道具と、拭くものです。
そもそも埃を吸わせない、という手もあります。タワー型を床に直接置いていると、いちばん埃の多い高さから吸い込みます。少し浮かせるだけでも違いますし、動かせると掃除そのものが楽になります。
セットアップ手順
2枚挿し環境を実際に構築する手順を簡潔にまとめます。OSはLinux(Ubuntu)を前提としていますが、基本的な考え方はWindowsでも同じです。1. GPU割り当ての設定(CUDA_VISIBLE_DEVICES)
OllamaがどのGPUを使うかは、環境変数CUDA_VISIBLE_DEVICES で制御します。systemdのサービスファイルで指定するのが確実です。
# Ollamaのsystemdサービスファイルを編集 sudo systemctl edit ollama # 以下を追記 [Service] Environment="CUDA_VISIBLE_DEVICES=0,1"GPU0とGPU1の両方をOllamaに認識させる場合は
0,1 を指定します。ComfyUIを特定のGPUに固定したい場合は、ComfyUI側の起動スクリプトで CUDA_VISIBLE_DEVICES=1 のように指定します。
# 例: ComfyUIをGPU1(RTX 3090)専用にする場合 CUDA_VISIBLE_DEVICES=1 python main.py --listen
2. Open WebUIでLAN内共有
家族やチームメンバーがブラウザからアクセスできるようにするには、Open WebUIが便利です。# Dockerで起動(ポート3000をLAN内に公開) docker run -d --name open-webui -p 3000:8080 -e OLLAMA_BASE_URL=http://host.docker.internal:11434 --add-host=host.docker.internal:host-gateway --restart always ghcr.io/open-webui/open-webui:mainLAN内の他のPCやスマホから
http://<サーバーのIPアドレス>:3000 にアクセスすれば、ChatGPTのようなUIでローカルAIが使えます。ユーザーごとにアカウントを作れるので、会話履歴も個別に管理されます。
3. 起動確認
# GPUの認識状況を確認 nvidia-smi # Ollamaのモデル一覧 ollama list # モデルの動作確認 ollama run qwen3:8b "こんにちは" # 現在ロード中のモデルとGPU使用状況 ollama ps
nvidia-smi で2枚のGPUが表示されること、ollama ps でモデルが意図したGPUにロードされていることを確認すれば、セットアップ完了です。
まとめ
2枚挿しの実測データから見えてきたことを整理します。 2枚挿しの3つの利点:- VRAMの拡張: Ollamaの自動分散で、1枚には載らない大型モデル(27B)が動く
- タスクの分離: チャットと画像生成を同時に、異なるGPUで干渉なく実行できる
- 並列処理: 128並列でも速度低下1%以下。家族やチーム全員が同時に使える
- VRAMは統合されない(24+12=36GBにはならない)
- 並列数を増やすと1人あたりのコンテキスト長が短くなる
- コンテキスト上限に達するとOllamaは警告なしに古い会話を捨てる
この記事で使用したGPU
- ローカルLLMベンチマーク比較(準備中)
- ComfyUI導入ガイド(準備中)
あわせて読みたい
GPUを増やす前に、値段と電気代も見ておくと迷いません。







ディスカッション
コメント一覧
まだ、コメントがありません