GPU 2枚挿しでローカルAIを使い倒す：RTX 3090+RTX 3060の同時運用ガイド

2026年5月1日

PCに2枚のGPUを差して、ローカルAIを動かしています。Ollamaでチャット、いわゆるLLMを動かし、ComfyUIで画像生成、という組み合わせをしたり、LLMを複数起動させたりしています。本記事では、GPUを2枚挿す利点は本当にあるのか、実測データをもとに整理しました。 結論としては、2枚挿しの意味は間違いなくあります。ただし「VRAM 24+12=36GBになる」という期待は間違いです。2枚挿しの本当の価値は「タスクの同時実行」と「Ollamaの自動分散」にあります。さらに並列処理の実測データを取ったところ、予想をはるかに超える結果が出ました。 この記事の数値はすべて私の環境（RTX 3090 + RTX 3060 12GB、Linux、Ollama）での実測値です。2026年4月時点のデータです。

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の設定画面で指定するのではなく、Ollamaが空きVRAMを見て自動的に判断します。 この仕組みのおかげで、1枚のGPUに収まらないような巨大モデルでも、2枚に分散すれば動くということが起こります。ただし2枚のGPU間でデータを転送する必要があるため、1枚に全部載る場合と比べるとオーバーヘッドが発生します。このオーバーヘッドがどの程度なのかは、次のベンチマークデータで確認できます。

実測データ: 基本性能

私の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

★ = 筆者実測値（RTX 3090 / RTX 3060、2026年4月）。推定値の計算方法はGPU全機種スペック一覧を参照。 いくつか注目すべき点があります。 qwen3:8bはRTX 3090で126.4 tok/s、RTX 3060で60.1 tok/sです。 メモリ帯域の差（936 vs 360 GB/s）がそのまま速度に反映されています。RTX 3060でも60 tok/sは十分快適ですが、RTX 3090なら2倍速い。2枚挿しの場合、メインの処理をRTX 3090に任せ、サブタスクをRTX 3060で回す構成が効率的です。 gemma4の133.0 tok/sは体感で「瞬時」です。 私の環境では実用上の返答遅延をほぼ感じません。tok/sの体感目安としては、15 tok/s以下は遅い（待つ感じ）、30 tok/sで快適、40 tok/s以上はすぐ返ってくる感覚です。133 tok/sともなると、入力が終わった瞬間に文字が流れてきます。 同時実行時、27Bモデルの速度（25.5 tok/s）はシングル実行時と変わりません。 8Bモデル側（RTX 3090）は126→119 tok/sにわずかに低下していますが、体感では気になりません。2つの全く異なるモデルを同時に動かしても、実用上の性能低下はほぼないということです。

衝撃の並列テスト結果

ここからが本記事の核心です。「1つのモデルに対して、複数のリクエストを同時に投げたらどうなるか」を測りました。

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%

★ RTX 3090（24GB）で計測。baselineは単体実測値126.4 tok/s。2026年4月実測。 この結果には驚きました。128並列でも1リクエストあたりの速度がほぼ落ちていません。 合計スループットは126 tok/s → 16,081 tok/sへ、127倍に伸びています。ほぼ完璧な線形スケーリングです。

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	なし

★ RTX 3090 + RTX 3060 の2GPU分散で計測。2026年4月実測。 27Bモデルでも同様の傾向です。8並列でも速度低下なし。GPU2枚に分散した状態でも、並列処理のスケーリングは崩れません。

なぜこんな結果になるのか

この「並列数を増やしても速度が落ちない」という挙動は、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%

★ RTX 3090（24GB）で計測。2026年4月実測。 プロンプトが長くなるほど、KVキャッシュが大きくなり、処理するデータ量が増えるため速度が低下します。60字程度の短い質問では127.8 tok/sですが、18,000字（原稿用紙45枚分）を入力すると91.1 tok/sまで落ちます。 とはいえ、18,000字を入力しても91 tok/sは十分に快適な速度です。30 tok/sで「快適」、40 tok/s以上で「すぐ返ってくる」という体感基準で考えると、かなり長い文脈を入れても実用上の問題はありません。 トークンと日本語文字数の関係について補足します。 qwen3:8bで実測したところ、日本語では1トークンあたり約1〜1.2文字に対応していました。英語だと1トークン=約4文字ですが、日本語は1文字あたりのトークン消費が大きいです。記事中の「~60字」「~1,800字」といった表記は、この換算に基づいています。

マルチターン会話の場合

実際のチャットでは、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字

並列数が増えるとKVキャッシュを各リクエストで分け合うため、1リクエストあたりの使えるコンテキスト長が短くなります。1人で使うなら24,000字（原稿用紙60枚分）の文脈を維持できますが、8人で同時に使う場合は1人あたり約3,000字になります。 3,000字は「ちょっとした質問のやり取り10往復」くらいの量です。日常的なチャット用途なら十分ですが、長い文書の要約や、前の会話を大量に参照するような使い方には短いです。

グラフ: 並列数と合計スループット

このグラフの見方: バーが長いほど合計スループット（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-4o
ChatGPT Plus × 8人	0円	24,000円	8人	GPT-4o
RTX 3090中古 + RTX 3060中古	~17万円	電気代 ~5,000円	8人（27B）/ 128人（8B）	27B or 8B

年間コスト比較（8人利用の場合）

• ChatGPT Plus × 8人: 月24,000円 × 12ヶ月 = 年間288,000円
• ローカルAI（2枚挿し）: 初期費用17万円 + 電気代 月5,000円 × 12ヶ月 = 初年度23万円、2年目以降6万円
• 差額: 初年度で5.8万円、2年目以降は22.8万円お得

もちろん、GPT-4oとローカルの27Bモデルでは品質に差があります。最先端の推論能力やコーディング支援が必要なら、ChatGPT PlusやClaude Proに課金する価値は十分あります。 ローカルAIが真価を発揮するのは以下のようなケースです。

• プライバシーが重要: 社内文書や個人情報を含むデータを外部に送りたくない
• 多人数で使う: 家族やチームの人数分だけサブスクが増えるクラウドに対し、ローカルは何人使っても追加費用ゼロ
• オフライン利用: ネット環境が不安定でも確実に動く
• カスタマイズ: モデルの選択やファインチューニングが自由

セットアップ手順

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:main

LAN内の他の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つの利点:

1. VRAMの拡張: Ollamaの自動分散で、1枚には載らない大型モデル（27B）が動く
2. タスクの分離: チャットと画像生成を同時に、異なるGPUで干渉なく実行できる
3. 並列処理: 128並列でも速度低下1%以下。家族やチーム全員が同時に使える

注意が必要な点:

1. VRAMは統合されない（24+12=36GBにはならない）
2. 並列数を増やすと1人あたりのコンテキスト長が短くなる
3. コンテキスト上限に達するとOllamaは警告なしに古い会話を捨てる

並列性能は予想をはるかに超えていました。 128並列で合計16,081 tok/sというスループットは、クラウドAPIの従量課金と比べるとコスト面で圧倒的な優位性があります。「ローカルAIは1人で使うもの」というイメージは、このデータを見る限り完全に覆りました。 RTX 3090の中古が13〜15万円、RTX 3060 12GBの中古が約4万円。合計17〜19万円の投資で、8人以上が同時にAIチャットできる環境が手に入ります。年間のクラウド課金と比較すれば、初年度で元が取れる計算です。

この記事で使用したGPU