WSL2 でローカルLLMを動かす完全セットアップガイド 2026年版:Windows 11 で CUDA / Ollama / vLLM を Ubuntu 24.04 経由で動かすインストール手順

結論:Windows 11 の WSL2 で Ollama を Llama 3.3 70B Q4 まで動かすには、所要 40 分〜1 時間、必要ディスク 60GB。手順は「WSL2 有効化 → Ubuntu 24.04 導入 → .wslconfig でメモリ 48GB 割当 → NVIDIA CUDA on WSL の toolkit のみインストール(driver は入れない)→ Ollama インストール → flash attention と KV 量子化を最初から有効化」の 6 ステップです。速度は Linux native の 90〜100% で、実務上は WSL2 と Windows Native の差はほぼ感じません。ただし Ubuntu 側に NVIDIA driver を入れてしまう・.wslconfig でメモリを 8GB のままにしている・モデルを /mnt/c/ 経由で置く、この 3 つは初回セットアップで多くの人が踏む落とし穴で、それぞれ本文で回避手順を示します。

Windows で開発している方が「ローカルLLM を試したい」と思ったとき、選択肢は 3 つあります。Windows Native の Ollama / LM Studio、WSL2 の Ubuntu で llama.cpp / Ollama、そして vLLM / SGLang などの Linux 前提ツールです。私が推奨するのは、WSL2 を入れておいて必要に応じて Windows Native と使い分ける構成です。この記事では、WSL2 上で NVIDIA GPU パススルーを効かせて Ollama を動かし、さらに vLLM を追加で入れて OpenAI 互換 API サーバとして公開するまでを、実コマンド付きで通しで解説します。

WSL2 と Ubuntu native で速度差が出るかは Windows vs Linux でローカルLLM の tok/sec で扱っていて、結論は「NVIDIA GPU なら誤差レベル」です。この記事ではその結論を前提に、セットアップ手順そのものにフォーカスします。

事前準備:Windows 11 24H2 以降と NVIDIA ドライバ

まず環境の前提です。以下を満たしていることを PowerShell で確認してください。

# Windows のバージョン(24H2 = 26100 以降が推奨)
winver

# NVIDIA ドライバ(555 以降で WSL2 CUDA が安定)
nvidia-smi

• Windows 11 24H2 以降:WSL2 で systemd + GPU パススルーが安定するバージョン
• NVIDIA ドライバ 555 以降:CUDA 12.x on WSL2 で必要
• 物理メモリ 32GB 以上推奨:70B Q4 を回すなら 48GB の WSL 割当を確保したいので、システム全体で 48GB + Windows 用 16GB = 64GB 以上が理想

nvidia-smi が Windows 側で通ることが確認できれば、Ubuntu 側には driver を入れなくても WSL2 が透過してくれます。

ステップ 1:WSL2 と Ubuntu 24.04 の導入

PowerShell を管理者権限で起動して、以下を順に実行します。

# WSL 機能を有効化(初回のみ、再起動が必要)
wsl --install

# デフォルトを WSL2 に
wsl --set-default-version 2

# Ubuntu 24.04 をインストール
wsl --install -d Ubuntu-24.04

初回起動時にユーザ名とパスワードを設定します。ここで作るユーザは Ubuntu 内の管理者アカウントで、Windows のアカウントとは独立です。

.wslconfig でメモリ・CPU・swap を明示

WSL2 は既定で物理 RAM の 50% しか使いません。64GB の PC なら 32GB までしか WSL に回らず、70B Q4 の Ollama が OOM で落ちます。C:\Users\<ユーザ名>\.wslconfig を作成して以下を書きます。

[wsl2]
memory=48GB
processors=16
swap=0
autoMemoryReclaim=dropcache

• memory=48GB:自機の RAM に応じて調整(全体の 60〜75% が目安)
• processors=16:論理コア数を明示。指定しないと全論理コアを WSL2 が掴む
• swap=0:LLM でスワップに落ちると tok/sec が壊滅的に落ちるので無効化
• autoMemoryReclaim=dropcache:systemd と併用する場合、gradual は ls や apt update が固まる既知のバグがあるので dropcache を選ぶ

保存後、PowerShell で wsl --shutdown を打って WSL を落とし、wsl で再起動します。反映確認は Ubuntu 側で free -h して total が 48GB になっていれば OK です。

/etc/wsl.conf で systemd を有効化

Ubuntu 側で /etc/wsl.conf を作成し、systemd を有効化します。

sudo tee /etc/wsl.conf <<'EOF'
[boot]
systemd=true
EOF

再度 PowerShell で wsl --shutdown → wsl で再起動すると、systemd が pid 1 で走ります。systemctl status が動けば有効化成功です。

ステップ 2:NVIDIA CUDA on WSL のインストール

ここが一番落とし穴が多い箇所です。Ubuntu 側に driver を入れてはいけません。Windows ホスト側の driver を WSL2 が透過するので、Ubuntu 側は「toolkit」だけを入れます。

# 動作確認:これで GPU が見えていれば driver 透過は成功
nvidia-smi

# CUDA Toolkit のリポジトリを追加
wget https://developer.download.nvidia.com/compute/cuda/repos/wsl-ubuntu/x86_64/cuda-keyring_1.1-1_all.deb
sudo dpkg -i cuda-keyring_1.1-1_all.deb
sudo apt-get update

# toolkit のみをインストール(cuda-drivers メタパッケージは絶対に入れない)
sudo apt-get install -y cuda-toolkit-12-6

インストール後、.bashrc に PATH を通します。

echo 'export PATH=/usr/local/cuda-12.6/bin:$PATH' >> ~/.bashrc
echo 'export LD_LIBRARY_PATH=/usr/local/cuda-12.6/lib64:$LD_LIBRARY_PATH' >> ~/.bashrc
source ~/.bashrc

# 動作確認
nvcc --version
nvidia-smi

nvidia-smi の出力に自機の GPU が表示されて、nvcc --version が 12.6 と出れば toolkit のインストール完了です。

落とし穴:driver を入れると壊れる

Ubuntu の初心者向けドキュメントで「まず driver を入れる」と書いてあるものが多いですが、それは native Ubuntu 向けです。WSL2 では絶対に以下のパッケージを入れてはいけません。

# ❌ 絶対に入れない:これで GPU が見えなくなる
sudo apt install nvidia-driver-XXX  # NG
sudo apt install cuda-drivers        # NG
sudo apt install cuda                # NG(cuda-drivers を巻き込む)

もし間違って入れてしまった場合は、sudo apt purge '^nvidia-.*' 'cuda-drivers*' で削除して WSL を再起動すれば復旧します。

ステップ 3:Ollama を WSL2 に導入

Ollama の公式インストールスクリプトを走らせます。

curl -fsSL https://ollama.com/install.sh | sh

このスクリプトは Linux 向けバイナリを /usr/local/bin/ollama に置き、systemd unit ファイル(/etc/systemd/system/ollama.service)も作ります。systemd が有効化されていれば、そのまま常駐化できます。

flash attention と KV 量子化を最初から有効化

Ollama を単に起動しても、flash attention と KV キャッシュ量子化は既定で無効です。tok/sec と VRAM 効率のために、最初から有効化しておくのがおすすめです。unit ファイルを編集します。

sudo systemctl edit --force --full ollama.service

[Service] セクションに以下を追記して保存します。

Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"
Environment="OLLAMA_NUM_GPU=99"
Environment="OLLAMA_HOST=127.0.0.1:11434"

• OLLAMA_FLASH_ATTENTION=1:flash attention 有効化(KV 量子化の前提)
• OLLAMA_KV_CACHE_TYPE=q8_0:KV キャッシュを 8bit 量子化してコンテキスト用 VRAM を約半減
• OLLAMA_NUM_GPU=99:全層 GPU オフロード(VRAM に収まる限り)
• OLLAMA_HOST=127.0.0.1:11434:Windows ホストの localhost からのみ接続を受ける(LAN 公開したい場合は 0.0.0.0:11434)

各設定の詳細は ローカルLLM 推論を速くする llama.cpp / Ollama チューニング設定ガイド にまとめてあります。

反映と起動:

sudo systemctl daemon-reload
sudo systemctl enable ollama
sudo systemctl start ollama
sudo systemctl status ollama

active (running) が表示されれば起動成功です。

モデルを引く:70B Q4 の実例

# Llama 3.3 70B Q4_K_M(約 40GB)
ollama pull llama3.3:70b-instruct-q4_K_M

# 動作確認
ollama run llama3.3:70b-instruct-q4_K_M

初回 pull は 40GB のダウンロードで 10〜20 分かかります。以降のロードは SSD からで数十秒です。モデルは ~/.ollama/models(WSL2 内の VHDX ファイルシステム)に置いてください。/mnt/c/ 経由(Windows 側 NTFS)に置くとロード速度が数分の 1 に落ちます。

ステップ 4:Windows ホストから localhost:11434 で叩く

WSL2 は localhost を Windows 側に自動フォワードします。Windows 側の Chrome や Edge から http://localhost:11434 にアクセスすると、Ollama の応答(Ollama is running)が返ります。

Cursor / Continue.dev / Open WebUI などの Windows ネイティブアプリからも同じ localhost で接続できます。

# Cursor / Continue.dev の設定例
API endpoint: http://localhost:11434/v1
Model: llama3.3:70b-instruct-q4_K_M

LAN 内の他マシンから叩きたい場合

自宅サーバ的に使うなら、OLLAMA_HOST=0.0.0.0:11434 で起動し、Windows Defender ファイアウォールで 11434 を開けます。

# PowerShell(管理者)
New-NetFirewallRule -DisplayName "Ollama WSL2" -Direction Inbound -LocalPort 11434 -Protocol TCP -Action Allow

ただし、WSL2 は既定で NAT 型ネットワークを使うので、外部から <Windows のIP>:11434 に来たパケットを WSL2 に転送するために、追加で netsh interface portproxy が必要になります。ここは 自宅ローカルLLM サーバの組み方 で扱っている自宅サーバ構成の記事を参考にしてください。

ステップ 5:vLLM を導入する(本格運用向け)

Ollama は導入が楽ですが、複数リクエストの並列処理・PagedAttention による VRAM 効率で言うと vLLM が上です。API を叩く実運用や、複数クライアントから同時に使う場合は vLLM を並行導入します。

# Python 3.11 と uv の準備
sudo apt install -y python3.11 python3.11-venv
curl -LsSf https://astral.sh/uv/install.sh | sh
source ~/.bashrc

# 仮想環境を作って vLLM を入れる
uv venv --python 3.11 ~/vllm-env
source ~/vllm-env/bin/activate
uv pip install vllm

# 起動(HuggingFace のモデル ID を指定)
vllm serve meta-llama/Llama-3.1-8B-Instruct \
  --port 8000 \
  --gpu-memory-utilization 0.9

http://localhost:8000/v1 が OpenAI 互換のエンドポイントとして公開されます。

GPU が効いているか確認

別ターミナルで nvidia-smi -l 1 を叩き、vLLM のプロセスが GPU の VRAM と GPU-Util を消費していることを確認します。

watch -n 1 nvidia-smi

もし GPU-Util がずっと 0% のままなら、driver 透過に失敗している可能性があります。前段の CUDA インストール手順を見直してください。

ステップ 6:LM Studio と併存させる構成

LM Studio は Windows ネイティブの GUI クライアントとして便利で、モデル管理と会話を GUI で完結できます。WSL2 の Ollama / vLLM とはポートが違うので、併存させて用途で使い分ける構成が現実的です。

ツール	動作環境	ポート	用途
LM Studio	Windows native	1234(既定)	GUI で会話・簡易ベンチマーク
Ollama	WSL2(systemd 常駐)	11434	Cursor / Continue.dev などの IDE 連携
vLLM	WSL2(手動起動)	8000	OpenAI 互換 API サーバ(本格運用)

3 つとも同時に動かしても、モデルを同時ロードしなければ GPU の取り合いはコンテキストスイッチで済みます(それでも同時に大きいモデルを 2 つ載せると VRAM が足りずどちらかが落ちます)。実務的には「日中 Cursor + Ollama、動画閲覧時に LM Studio でチャット、夜間バッチ処理は vLLM」のように時間帯で切り替える使い方が回しやすいです。

落とし穴 5 選:初回セットアップで踏みやすい罠

私が実機で試して見つけた頻出のトラブルをまとめます。

1. .wslconfig でメモリ 8GB のまま 70B を回そうとする

症状:ollama run llama3.3:70b の途中で「out of memory」で落ちる。原因は WSL2 の memory 割当。前述の memory=48GB を .wslconfig に書いて wsl --shutdown してください。

2. Ubuntu 側に NVIDIA driver を入れて GPU が見えなくなる

症状:nvidia-smi が「NVIDIA-SMI has failed because it couldn’t communicate with the NVIDIA driver」を返す。復旧は sudo apt purge '^nvidia-.*' 'cuda-drivers*' → wsl --shutdown。以降は toolkit だけを入れてください。

3. モデルを /mnt/c/ に置いてロードが遅い

症状:ollama run の起動に 5〜10 分かかる。原因は Windows 側 NTFS 経由のクロスファイルシステムアクセスが遅いこと。~/.ollama/models は WSL2 の VHDX に置かれるので、そちらを使ってください。

4. autoMemoryReclaim=gradual で apt が固まる

症状:sudo apt update や ls が返ってこない。systemd との既知の相性問題です。.wslconfig の autoMemoryReclaim を dropcache に変更して WSL を再起動。

5. Docker Desktop の WSL2 backend と Ollama systemd の同居で GPU 競合

症状:docker run --gpus all が失敗する、または Ollama が GPU を認識しなくなる。Docker Desktop は独自の WSL2 ディストリビューションを使うので、Ollama を入れた Ubuntu-24.04 と分離しておくのが安全です。GPU は共有アクセスの形になるので、「両方が同時に大きなモデルを載せる」構成にすると VRAM で衝突します。

WSL2 と Windows Native の使い分け:実務判断

最後に、そもそも WSL2 を入れる意味があるかの判断軸を整理します。

• Windows Native で完結する用途:LM Studio で会話するだけ、Ollama for Windows で Cursor と繋ぐだけ
• WSL2 が必要になる用途:vLLM / SGLang / Python の Triton 系ライブラリ / 最新の llama.cpp ビルド / Docker で ML コンテナを回す / bash スクリプト前提の自宅サーバ運用

「WSL2 のほうが速い」は 2024 年頃までの認識で、2026 年時点では NVIDIA GPU の場合はほぼ差がありません(詳細は Windows vs Linux でローカルLLM の tok/sec)。差別化要因は速度差ではありません。**「Linux 前提のツールを使うか」**という 1 点に集約されます。

まとめ:6 ステップで WSL2 + Ollama + vLLM

• Windows 11 24H2 + NVIDIA ドライバ 555 以降 が前提。nvidia-smi が Windows で通ることを確認
• .wslconfig で memory=48GB / processors=16 / swap=0 / autoMemoryReclaim=dropcache を設定
• /etc/wsl.conf で systemd=true を有効化
• CUDA は toolkit-12-6 のみインストール、driver は絶対に入れない
• Ollama は systemd 常駐化 + flash attention + KV 量子化 + 全層 GPU の環境変数を最初から入れる
• モデルは ~/.ollama/models(WSL2 内)に置く、/mnt/c/ は使わない
• Windows ホストからは localhost:11434 で叩ける、LAN 公開時は portproxy が要る
• vLLM は Python 3.11 + uv で仮想環境、OpenAI 互換 API を 8000 番で公開
• LM Studio と併存、ポートが違うので用途で使い分け

セットアップに 40 分〜1 時間、必要ディスクは 60GB(Ubuntu + CUDA + Ollama + 70B Q4 モデル 1 個)。ここまで通せば、あとは何 B のモデルを回すか・チューニングをどこまで詰めるかの世界に入ります。モデル選びは ローカルLLM モデル選定ガイド、チューニングは 推論を速くする llama.cpp / Ollama チューニング を続けてどうぞ。

入手先・関連商品

当サイトは Amazon.co.jp アソシエイト・プログラムに参加予定です。下記リンク経由で購入された場合、紹介料を受け取ることがあります。読者の負担は増えません。リンクは記事評価とは独立しており、編集判断には影響しません。

WSL2 でローカルLLM を快適に回せる GPU 単体構成向け

• NVIDIA GeForce RTX 5090 (32GB) を Amazon.co.jp で見る

メモリ 48GB 以上を WSL2 に割り当てるための DDR5

• DDR5-6000 64GB (32GBx2) を Amazon.co.jp で見る

モデル置き場向けの高速 NVMe SSD(WSL2 の VHDX が置かれるドライブ)

• WD Black SN850X 2TB NVMe Gen4 を Amazon.co.jp で見る

---

あなたに合うPCを診断する

用途や予算をもう少し細かく入力すると、3つの候補構成を提案します。

→ 診断スタート

関連記事

• Windows vs Linux でローカルLLM の tok/sec 整理 2026:WSL2・Windows Native・Linux Native の速度差の答え
• ローカルLLM 推論を速くする llama.cpp / Ollama チューニング設定ガイド:動いた後の tok/sec 引き上げ
• ローカルLLM モデル選定ガイド 2026:何 B を動かすかの判断軸
• ローカルLLM を動かす PC の最低スペック 2026:WSL2 が動くハードウェア前提
• 自宅ローカルLLM サーバの組み方:LAN 公開まで踏み込む場合