AI開発 ガイド

Docker / Podman でローカルLLM を運用する完全ガイド 2026年版：NVIDIA GPU pass-through と docker compose で Ollama / vLLM / Open WebUI を本番同等に立てる

ローカルLLM をベアメタルで動かすと環境が壊れやすく、Ollama / vLLM / Open WebUI の同居も難しくなります。Docker / Podman + NVIDIA Container Toolkit で GPU pass-through を有効化し、docker compose 1 つで Ollama バックエンド・vLLM 高速サービング・Open WebUI フロントを本番同等に立てる構成を、GPU モデル別（RTX 5090 / RTX 4090 / Strix Halo）に整理します。

  • #Docker
  • #Podman
  • #NVIDIA Container Toolkit
  • #Ollama
  • #vLLM
  • #Open WebUI
  • #docker compose
  • #ローカルLLM
  • #GPU pass-through
  • #CDI

本記事は Amazon.co.jp および各販売店のアフィリエイトリンクを含む場合があります。推奨は性能・コスパ・実機ベンチマーク基準で編集判断しており、提供記事は受け付けていません。詳細は プライバシーポリシー をご覧ください。

Docker / Podman でローカルLLM を運用する完全ガイド 2026：NVIDIA GPU pass-through と docker compose で Ollama / vLLM / Open WebUI を立てる

結論：ローカルLLM を「開発機で長く使う」なら、初日から Docker / Podman + NVIDIA Container Toolkit でコンテナ化しておくのが正解です。ホスト OS を汚さず、Ollama / vLLM / Open WebUI を docker compose 1 ファイルで同居させ、モデルは named volume に永続化する構成なら、CUDA / ドライバのバージョン地獄から解放されます。RTX 5090（Blackwell）は CUDA 12.6+、Strix Halo は ROCm コンテナ、Apple Silicon は Docker Desktop で GPU pass-through 不可（ネイティブ運用が必要）という 3 点さえ押さえれば、あとはほぼ同じ構成で回せます。

ローカルLLM を触り始めると、たいてい次の順番で環境が壊れます。Ollama をインストール、vLLM を pip install したら CUDA バージョンが競合、Open WebUI を Docker で動かそうとして nvidia-docker が入っていないと気づき、直そうとして CUDA ドライバを消したら X が起動しなくなる。ベアメタル運用は 3 ヶ月以内に必ずこのループを踏みます。

対策はシンプルで、LLM 関連は全部コンテナに閉じ込める。ホストには NVIDIA ドライバと NVIDIA Container Toolkit（旧 nvidia-docker2）だけ入れ、Ollama / vLLM / Open WebUI はイメージから起動する構成に切り替えます。モデルファイルは named volume に置き、コンテナを作り直してもモデルの再ダウンロードは不要にします。

本記事では、この「本番同等のローカルLLM 運用スタック」を Docker / Podman どちらでも組めるよう、GPU モデル別に整理します。ホスト OS は Ubuntu 24.04 LTS / Debian 13 を主軸に、Windows（WSL2）と Apple Silicon の制約も明記します。

なぜコンテナ化するか：ベアメタル運用が破綻する 3 つの理由

コンテナ化の理由は、実務の痛みから来ています。大きく 3 つあります。

CUDA / cuDNN / PyTorch のバージョン競合が地獄です。 Ollama は CUDA 12.4 で安定、vLLM 0.6 系は CUDA 12.1 前提、SGLang は CUDA 12.6 推奨、といった具合に、LLM 系ツールは求める CUDA バージョンがバラバラです。ホストに 1 つの CUDA を入れると、どれかは動かなくなります。コンテナなら各ツールが自分の CUDA を持ち込むので競合が起きません。

ホスト OS のパッケージが汚れます。 pip install で PyTorch / Transformers / vLLM を入れると、依存が数百パッケージ増え、他の Python プロジェクトと衝突します。venv や conda を使っても、CUDA / cuDNN の native ライブラリはシステム側に残るため完全には切り離せません。コンテナは OS ごとイメージなので、まっさらに戻せます。

モデルの永続化と共有が難しくなります。 Ollama と llama.cpp と vLLM で、同じモデル（例：Llama 3.1 70B Q4、40GB）を別々にダウンロードすると、SSD が一瞬で埋まります。コンテナで named volume を共有する構成にすれば、1 つのモデルファイルを複数のツールから参照できます。

Ollama と vLLM / llama.cpp の性能・用途の違いは「Ollama と llama.cpp、どう違う？ 2026年版：性能・使いやすさ・API 互換性で比較」に、vLLM / SGLang / TensorRT-LLM の使い分けは「vLLM / SGLang / TensorRT-LLM サービング比較 2026年版」にまとめています。

NVIDIA Container Toolkit のセットアップ（Ubuntu 24.04 / Debian 13）

コンテナから NVIDIA GPU を使う入口は、NVIDIA Container Toolkit です。旧 nvidia-docker2 の後継で、Docker と Podman 両方に対応します。

Ubuntu 24.04 での基本手順は次の通りです。ホストには先に NVIDIA ドライバ（RTX 50 系なら 570 番台以降）を入れておきます。

# NVIDIA repository を追加
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey \
  | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list \
  | sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' \
  | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list

sudo apt update
sudo apt install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

動作確認は 1 コマンドです。

docker run --rm --gpus all nvidia/cuda:12.6.0-base-ubuntu24.04 nvidia-smi

nvidia-smi の出力が返ってくれば GPU pass-through は成功です。ここまでで、コンテナから NVIDIA GPU が見えるようになります。

2026 年時点では CDI（Container Device Interface）方式が推奨になっています。従来の --gpus all は Docker 独自の実装で、Podman では動作しません。CDI は仕様統一で、Docker 25+ / Podman 5+ の両方が対応します。

# CDI 仕様を生成
sudo nvidia-ctk cdi generate --output=/etc/cdi/nvidia.yaml

# Docker で CDI を使う
docker run --rm --device nvidia.com/gpu=all nvidia/cuda:12.6.0-base-ubuntu24.04 nvidia-smi

# Podman で CDI を使う
podman run --rm --device nvidia.com/gpu=all nvidia/cuda:12.6.0-base-ubuntu24.04 nvidia-smi

新規に組むなら CDI 方式で統一するのが将来性の面で有利です。

docker compose で Ollama + Open WebUI + vLLM を立てる

ここからが本題です。3 つのサービスを 1 つの docker-compose.yml にまとめ、named volume でモデルを永続化する構成です。

services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    restart: unless-stopped
    volumes:
      - ollama-models:/root/.ollama
    ports:
      - "127.0.0.1:11434:11434"
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]

  vllm:
    image: vllm/vllm-openai:latest
    container_name: vllm
    restart: unless-stopped
    volumes:
      - hf-cache:/root/.cache/huggingface
    ports:
      - "127.0.0.1:8000:8000"
    ipc: host
    command:
      - "--model=Qwen/Qwen2.5-7B-Instruct-AWQ"
      - "--dtype=auto"
      - "--max-model-len=8192"
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]

  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    restart: unless-stopped
    depends_on:
      - ollama
    volumes:
      - open-webui-data:/app/backend/data
    ports:
      - "3000:8080"
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
      - OPENAI_API_BASE_URL=http://vllm:8000/v1
      - OPENAI_API_KEY=dummy-key

volumes:
  ollama-models:
  hf-cache:
  open-webui-data:

docker compose up -d で 3 サービスが立ち上がります。ブラウザで http://localhost:3000 を開くと Open WebUI が表示され、Ollama バックエンドと vLLM の両方にアクセスできます。Ollama のモデルは docker exec ollama ollama pull llama3.1:8b で追加します。

この構成の勘所は volume の切り分けです。ollama-models は Ollama 独自のモデル形式（GGUF 化されたバイナリと manifest）を保存、hf-cache は vLLM が使う Hugging Face のオリジナル形式を保存します。両者は形式が違うため共有できませんが、それぞれ named volume に隔離しておくと、コンテナを作り直してもモデルの再ダウンロードは不要です。

ports は 127.0.0.1: で localhost に縛っています。LAN や外部に公開する場合は、必ずリバースプロキシ（Caddy / Traefik / nginx）と認証を挟んでください。Open WebUI 自体の運用ノウハウは「Open WebUI / LibreChat でローカルLLM チャット UI を作る 2026年版」に整理しています。

Podman rootless で GPU を渡す

セキュリティ要件が厳しい環境や、Docker デーモン特権を避けたい場合は Podman rootless を選びます。Podman 5.x + CDI で GPU pass-through が rootless でも動くようになりました。

# rootless 環境で CDI 仕様を生成（ユーザ側）
nvidia-ctk cdi generate --output=$HOME/.config/cdi/nvidia.yaml

# rootless Podman で GPU コンテナを起動
podman run --rm --device nvidia.com/gpu=all \
  --security-opt=label=disable \
  nvidia/cuda:12.6.0-base-ubuntu24.04 nvidia-smi

--security-opt=label=disable は SELinux 環境で必要になる場合があります。RHEL 9 / Fedora 41 での運用では特に効きます。

Podman は docker-compose.yml を podman-compose で読めるほか、podman generate systemd で systemd unit にできるため、常時稼働の LLM サーバを systemd で管理する運用と相性が良い点も強みです。

GPU モデル別の注意点

同じ docker compose 構成でも、GPU が変わると罠が変わります。主要 3 パターンを整理します。

RTX 5090 / 5080（Blackwell 世代）

CUDA 12.6 以降が必須です。イメージのタグを nvidia/cuda:12.6.0-* 以降に揃え、Ollama / vLLM のイメージも Blackwell 対応を確認します。Ollama は 2025 年後半のリリースで Blackwell 対応が入りました。vLLM は 0.7 系以降で FlashAttention 3 + Blackwell の組み合わせがサポートされます。古い CUDA イメージ（11.x や 12.1）は起動時に no kernel image available エラーで落ちます。

RTX 4090 / 4080（Ada Lovelace 世代）

CUDA 12.1 以降で問題なく動きます。最も枯れた構成で、docker compose の設定例をそのまま使えます。24GB VRAM で 32B Q4 まで、12B Q8 まで載ります。

Strix Halo / Radeon（ROCm）

AMD 側は NVIDIA Container Toolkit のかわりに ROCm コンテナを使います。Ollama は ROCm 対応の公式イメージ ollama/ollama:rocm があり、Radeon RX 9070 XT や Ryzen AI MAX+ 395（Strix Halo）で動きます。

services:
  ollama:
    image: ollama/ollama:rocm
    devices:
      - /dev/kfd
      - /dev/dri
    group_add:
      - video
    security_opt:
      - seccomp:unconfined
    volumes:
      - ollama-models:/root/.ollama

vLLM の ROCm 対応は 2026 年時点で発展途上で、AMD 公式の rocm/vllm イメージを使う運用が現実的です。Strix Halo ミニ PC の Docker 運用ノウハウは「Ryzen AI MAX+ 395（Strix Halo）ローカルLLM 推論ベンチマーク 2026年版」で補完しています。

Apple Silicon（M4 / M3 / M2 系）

Docker Desktop for Mac では GPU pass-through は使えません。 Metal は Docker からアクセスできず、CPU 推論に落ちるため実用速度になりません。Apple Silicon でローカルLLM を回すなら、Ollama / LM Studio をネイティブアプリとしてインストールし、コンテナ運用は諦めるのが正解です。OrbStack の GPU 実験機能もありますが、2026 年時点では本番運用に耐える段階ではありません。

Mac Studio でのローカルLLM 運用は「Mac Studio M3 Ultra 512GB でローカルLLM を動かす完全ガイド 2026年版」にまとめています。

Windows は WSL2 経由

Windows は Docker Desktop for Windows + WSL2 backend で GPU pass-through が動きます。ホスト Windows に NVIDIA ドライバ（Windows Studio 版）を入れれば、WSL2 側からは自動で GPU が見えます。Ubuntu WSL2 で nvidia-smi が動けば OK です。

Docker Desktop 4.30 以降は WSL2 GPU サポートが安定しました。ただし WSL2 のディスク I/O は Linux ネイティブより 20〜30% 遅い場合があり、モデルの初回ロードでは差が出ます。開発機として Windows を使い続けるなら妥協点として許容できますが、常時稼働のサーバ用途では Ubuntu / Debian のベアメタル + Docker が無難です。WSL2 での初期セットアップは「Windows WSL2 でローカルLLM を動かすセットアップガイド 2026年版」を参照してください。

運用の落とし穴：初回モデル pull・OOM Killer・アップグレード

構成が動き出してから、実際にハマる 3 点を先に共有します。

初回モデル pull は数十分〜数時間かかります。 Llama 3.1 70B Q4 は約 40GB、Qwen 2.5 72B は約 45GB。1Gbps 回線でも 10〜20 分は覚悟が必要です。docker compose up の直後は healthcheck が失敗し続けるように見えますが、モデルさえ落ちてくれば動きます。healthcheck の start_period は 300s 程度に伸ばしておくのが安全です。

OOM Killer の発火に注意します。 コンテナに --memory 制限を強く付けると、KV キャッシュが伸びたタイミングで OOM Killer に殺されます。LLM 用コンテナはメモリ制限を付けないか、ホスト搭載量の 80% 程度に緩く設定するのが実運用の落とし所です。

イメージのアップグレードは Watchtower に任せず手動にします。 Ollama や vLLM のマイナーバージョンアップは、たまに CUDA 要件やモデル形式が変わります。Watchtower で自動更新にすると、朝起きたら Open WebUI が Ollama に繋がらない状態、という事故が起きます。週次で docker compose pull && docker compose up -d を手動で回すか、CI で staging → production の 2 段構成にするのが安全です。

自宅で 24 時間 LLM サーバを回すネットワーク構成は「自宅ローカルLLM サーバのネットワーク構築ガイド 2026年版：Wi-Fi 7 と 10GbE」で扱っています。

私の見立て：docker compose 1 ファイルが「LLM 開発機の OS」になる

コンテナ化のメリットは、Ollama / vLLM / Open WebUI が単発で動くだけに留まりません。docker-compose.yml 1 ファイルが「あなたの LLM 開発機の OS」になる点にこそ真価があります。マシンを買い替えても、compose ファイルと named volume の中身をコピーすれば、同じ環境が数分で再現します。Ollama を llama.cpp に差し替えたくなったら、compose の 1 サービスを書き換えるだけで済みます。

初日に 30 分かけて compose を書いておくと、半年後に「あの設定どこだっけ」と探す時間が消えます。ローカルLLM は 3〜6 ヶ月で必ずツール構成が変わるジャンルなので、変更を吸収する仕組みを最初に入れておく価値は大きい、というのが私の見立てです。

入手先・関連商品

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

本ガイド想定の GPU / マシン

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

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

→ 診断スタート

関連記事