OllamaをDockerで動かす：CPU・GPU・ボリューム・API確認

OllamaをDockerで動かすと何が変わるか

通常のOllamaはローカルサービスとして動きます。コマンドで実行環境を起動し、モデルファイルはマシン上に置かれ、クライアントはポート11434を呼び出します。Dockerはこのサービスを独自のファイルシステム、プロセス名前空間、ネットワーク規則、ライフサイクルを持つコンテナで包みます。再現性の高いデプロイに便利ですが、/root/.ollamaをボリュームで永続化しないと、コンテナ内で取得したモデルがコンテナ削除時に消えることがあります。

そのため、Dockerコマンドが動くだけでは構成は完成しません。Dockerを唯一のOllama実行環境にするのか、ホストアプリや別コンテナから呼び出すのか、モデルのダウンロードをアップグレード後も残すのかを決めます。OpenCode、MCPホスト、Web UI、リモートクライアントを追加する前に、境界を見える形にしておきましょう。

CPU・NVIDIA GPU・AMD GPUを選ぶ

ネットワーク、ボリューム、新しいホストを検証する段階では、まずCPU構成を使います。変更点が少なく、モデルの読み込み時間や応答速度を比べる基準になります。APIが動いたら、別の環境からコピーした不明なDockerオプションを足すのではなく、ホストに合ったアクセラレーター用コマンドへ切り替えてください。

NVIDIAコンテナでは、通常、ホスト側のドライバーとNVIDIA Container Toolkitが必要です。AMD構成は異なるイメージタグやデバイス設定を使うことがあり、対応状況はOS、ランタイム、現在のOllama案内に依存します。GPUは最適化の層として扱い、エンドポイント、ボリュームの場所、基本的なヘルス確認は変えないようにします。

docker version

docker run --rm --gpus=all nvidia/cuda:12.0.0-base-ubuntu22.04 nvidia-smi

モデルを永続化するボリュームを作る

名前付きボリュームはOllama Docker構成の初期値として扱いやすい方法です。保存場所をDockerが管理し、モデルファイルを手動で移さずにコンテナを交換できます。公式イメージはOllamaのデータを/root/.ollamaに保存するため、そこへ一貫してボリュームをマウントしてください。初回起動とアップグレードで別のボリュームを作ると、意図せず新しいモデルライブラリになります。

バインドマウントは、ディスク使用量を確認したい場合、決めたホストディレクトリをバックアップしたい場合、特定のドライブへモデルを置きたい場合に便利です。一方で権限やパスの判断が増えます。初回デプロイでは、名前付きボリュームのほうが説明しやすく壊しにくいでしょう。

docker volume create ollama-data

docker run -d --name ollama -p 11434:11434 -v ollama-data:/root/.ollama ollama/ollama

docker exec -it ollama ollama pull <model-name>

コンテナを起動してAPIを確認する

docker runがコンテナIDを返したら、大きなモデルを取得する前に状態を確認します。docker psでプロセスが動いているかを確認し、docker logsでポート、権限、ランタイムのエラーを調べます。その後、ホストから/api/tagsを呼び出します。tagsの応答が成功しても、すべてのモデルが読み込めることや、すべてのクライアントに利用権限があることまでは証明しません。

2つ目の確認として、小さなモデルで1回リクエストします。これにより、HTTPリスナーが生きているだけの状態と、モデル経路まで動作している状態を分けられます。APIは応答するのにモデルリクエストが失敗する場合は、ネットワーク設定を変える前に、モデル名、空き容量、メモリ、コンテナログを確認してください。

1. プロセスを確認

   コンテナがUp状態で、公開ポートが意図したものになっていることを確認します。

2. エンドポイントを確認

   ポート11434を公開した同じマシンから/api/tagsを呼び出し、ステータスコードを記録します。

3. モデルを確認

   小さなモデルを取得または使用し、エディターやエージェントを接続する前に安全なプロンプトを1回実行します。

docker ps --filter name=ollama

docker logs ollama --tail 100

curl http://127.0.0.1:11434/api/tags

docker exec -it ollama ollama list

localhostを混同せずにホストアプリを接続する

正しいOllama URLはクライアントの実行場所で決まります。Dockerがポートを公開している同じホスト上のデスクトップアプリは、通常http://127.0.0.1:11434を呼び出せます。同じDockerネットワークの別コンテナは、Composeのサービス名とポート、たとえばhttp://ollama:11434を使います。コンテナ内の127.0.0.1はそのコンテナ自身を指し、Windows、macOS、Linuxのホストを自動的に指すわけではありません。

リモートクライアントには、明示的に保護したアドレスとファイアウォール規則を使います。テストアプリを接続するためだけにポート11434をインターネットへ公開しないでください。リモートエンドポイントが必要なら、経路、認証またはプライベートネットワークの境界、アクセスを許可するモデルサービスを記録します。

モデル、コンテキスト、公開範囲を安全に保つ

Dockerに入れたからといって、Ollamaサービスが自動的に非公開になるわけではありません。コマンドやホストの既定値によっては、公開ポートがすべてのインターフェースへバインドされます。ホストだけで試す場合は、他のマシンからのアクセスが不要なら-p 127.0.0.1:11434:11434のようなループバックバインドを優先します。Composeサービスが内部からAPIを使う場合は、プライベートネットワークに置き、必要な場合以外はホストポートを公開しません。

モデルのコンテキスト長、同時実行数、GPUメモリは、コンテナが使うRAMやVRAMの量を変えます。一度に1つの変数だけを増やし、docker stats、ホストメモリ、モデルの応答を観察してください。秘密情報をイメージ、シェル履歴、スクリーンショット、バージョン管理されたComposeファイルへ入れないでください。ローカルモデルのエンドポイントと外部検索ツールでは、プライバシーの境界が異なります。

ヘルス、GPU、ボリューム、APIの障害を切り分ける

Ollama Docker構成が失敗したら、層を1つずつ変更します。まずDocker自体が簡単なコンテナを起動できるかを確認し、次にOllamaコンテナが動き続けるかを調べます。その後にボリューム、API、モデル、最後にクライアントアプリを確認します。エラーのたびにコマンド全体を入れ替えると、どの境界で失敗したのか分からなくなります。

GPUの失敗は、Ollama APIよりもホスト側のランタイムに原因があることが多いです。GPUが渡されていない、ドライバーが互換性を持たない、選んだイメージがホストに合わない、といった場合、コンテナが/api/tagsに応答していてもCPUを使っていることがあります。モデルが再作成後に見つからない場合は、再取得する前にdocker inspectの結果とマウント先を比較してください。

docker inspect ollama

docker stats ollama

docker stop ollama && docker rm ollama