Ollamaのトラブルシューティングガイド｜接続エラー・モデル読み込み失敗・GPU認識問題をLinuxで解決する手順

宮崎智広 この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
ＨＯＭＥ ＞ Linux技術 リナックスマスター.JP（Linuxマスター.JP） ＞ ローカルLLM ＞ Ollamaのトラブルシューティングガイド｜接続エラー・モデル読み込み失敗・GPU認識問題をLinuxで解決する手順
「Ollamaを起動したのにAPIに接続できない」「pull コマンドを叩いたらエラーで止まってしまう」
「GPU搭載のサーバーなのに推論がCPUで動いていて異様に遅い」

そんなトラブルに詰まっているLinux管理者は多い。Ollamaは導入がシンプルな分、エラーが出たときの情報が少なく、調べ方を知らないと手探りのまま時間を溶かしがちだ。
この記事では、Ollama運用で頻出する典型的なトラブルをカテゴリ別に整理し、原因の診断コマンドから設定修正・動作確認まで、実際に手を動かしながら解消できる手順を解説する。systemdサービス・WSL2・Dockerそれぞれの環境差にも対応した切り分け方法を網羅している。

この記事のポイント

・systemctl status ollamaとjournalctl -u ollama -n 50で起動エラーの原因を素早く特定できる
・GPU非認識の主因はNVIDIAドライバ・CUDAバージョン不一致。nvidia-smiとOllamaログで確認する
・接続拒否（connection refused）はポートバインドかsystemd起動順序ミスが多い
・環境別（systemd/WSL2/Docker）で症状が同じでも原因が異なる。切り分け手順を必ず踏むこと


Ollamaのトラブルシューティングガイド｜接続エラー・モデル読み込み失敗・GPU認識問題をLinuxで解決する手順

「このままじゃマズい」と感じていませんか？
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら

Ollamaトラブルシューティングの基本：まずここを確認する

Ollamaのトラブルは「起動・通信系」「モデル管理系」「GPU・ハードウェア系」「パフォーマンス系」の4カテゴリに分類できる。闇雲に設定を変える前に、どのカテゴリに属するかを特定するのが解決への近道だ。

設定を複数箇所同時に変更すると原因の特定が難しくなる。変更は1箇所ずつ、効果を確認しながら進めるのが鉄則だ。まず以下3つの確認コマンドをセットで実行する。

1. 3点確認コマンドを実行する

# Ollamaサービスの状態確認
$ systemctl status ollama

# 直近50行のログを確認
$ journalctl -u ollama -n 50 --no-pager

# APIが応答しているかをチェック
$ curl http://localhost:11434/api/tags
`systemctl status` でActive欄が `active (running)` であれば起動は正常だ。
`curl` のレスポンスが `{"models":[...]}` 形式のJSONで返れば、APIも正常に動いている。
この2点が揃えば通信系の問題は除外できる。

2. ログで頻出するエラーメッセージを把握する

Ollamaのログで多く見るエラーメッセージは、次の3種類が大半を占める。

・`listen tcp ... address already in use` → ポート競合
・`no GPU detected` または `no nvidia devices found` → GPU認識失敗
・`context deadline exceeded` → タイムアウト・応答過負荷

このあとの各章でそれぞれの対処手順を説明する。

本記事は Ubuntu ServerでローカルLLMを構築する方法｜Ollamaで機密データを外に出さず業務AIを動かす完全ガイド でOllamaをインストール済みの環境を前提としている。まだ構築していない場合は先にそちらを参照してほしい。

Ollamaが起動しない・「connection refused」エラーの対処

`curl http://localhost:11434/api/tags` を実行して `curl: (7) Failed to connect to localhost port 11434: Connection refused` が返ってくる場合、Ollamaプロセスが起動していない状態だ。

まずサービスの状態を確認し、停止していれば起動する。

1. サービスの起動状態を確認する

# サービスの状態を確認
$ systemctl status ollama

# 起動していなければ手動で起動
$ sudo systemctl start ollama

# 起動後にActive状態を確認
$ systemctl is-active ollama
`systemctl start` を実行してもすぐに終了してしまう場合は、ログで原因を確認する。

2. ポート競合を解消する

`listen tcp 0.0.0.0:11434: bind: address already in use` と表示される場合、11434番ポートを別プロセスが使用している。 
# 11434番ポートを使用しているプロセスを確認
$ ss -tlnp | grep 11434

# 確認したPIDの詳細を調べる
$ ps aux | grep 

# 不要なプロセスであれば停止
$ sudo kill -9 

# Ollamaを再起動
$ sudo systemctl restart ollama
ポート番号を変更したい場合は `override.conf` に環境変数を追記する。 
# override.confを作成・編集
$ sudo mkdir -p /etc/systemd/system/ollama.service.d/
$ sudo nano /etc/systemd/system/ollama.service.d/override.conf

# 以下を記述（ポートを11435に変更する例）
[Service]
Environment="OLLAMA_HOST=0.0.0.0:11435"

# 設定を反映して再起動
$ sudo systemctl daemon-reload
$ sudo systemctl restart ollama

3. 権限エラーを確認する

`permission denied` がログに出る場合、`ollama` ユーザーやモデル保存ディレクトリの権限問題が原因だ。 
# ollamaユーザーの存在確認
$ id ollama

# モデル保存ディレクトリの権限確認
$ ls -la /usr/share/ollama/

# 権限が崩れている場合は修正
$ sudo chown -R ollama:ollama /usr/share/ollama/
公式インストールスクリプトで導入している場合、`ollama` ユーザーと `/usr/share/ollama` は自動作成される。手動インストール・バイナリ直置きの場合は手動での作成が必要になる。

モデルのpullが失敗・ダウンロードが途中で止まるときの対処法

`ollama pull llama3.3:8b-instruct-q4_0` でダウンロードが途中で止まる・失敗するトラブルは、ストレージ容量不足かネットワーク環境が原因であることが多い。

まずは順番に確認していく。

1. ディスク空き容量を確認する

# モデル保存先のディスク空き容量を確認
$ df -h /usr/share/ollama

# OLLAMA_MODELSを変更している場合は変更先を確認
$ echo $OLLAMA_MODELS
$ df -h $OLLAMA_MODELS

# 現在インストール済みのモデル一覧とサイズを確認
$ ollama list
主要モデルのファイルサイズ目安:
・Llama3.3:8b-instruct-q4_0 → 約4.7GB
・Mistral:7b-instruct-q8_0 → 約7.7GB
・Gemma 3:9b-q4_0 → 約5.5GB
・Llama3.3:70b-instruct-q4_K_M → 約43GB

空き容量が不足している場合は不要なモデルを削除する。 
# 不要なモデルを削除してディスクを解放
$ ollama rm mistral:latest

# 削除後に容量を再確認
$ df -h /usr/share/ollama

2. ダウンロードのリジュームと再試行

Ollamaにはダウンロードの自動リジューム機能がある。途中で止まっても `ollama pull` を再実行すれば途中から再開できる。同一コマンドを再実行するだけでよい。

ネットワークが不安定な環境ではタイムアウトが頻発する。`journalctl -u ollama -f` でリアルタイムログを見ながら状況を確認するとよい。

3. プロキシ環境での設定

社内プロキシ経由でインターネットに出る環境では、環境変数を `override.conf` に追記する。 
# override.confにプロキシ設定を追加
[Service]
Environment="HTTPS_PROXY=http://proxy.example.com:8080"
Environment="HTTP_PROXY=http://proxy.example.com:8080"
Environment="NO_PROXY=localhost,127.0.0.1,192.168.0.0/16"

# 設定を反映
$ sudo systemctl daemon-reload
$ sudo systemctl restart ollama
モデルの選定で迷っている場合は、ローカルLLMのモデルを比較する方法｜Llama3.3・Mistral・Gemma・Phi-4をUbuntuで使い分けるポイント を参考に、VRAMとユースケースに合ったモデルを選んでほしい。

GPUが認識されずCPUのみで動いているときの診断と修正手順

Ollamaは起動しているが推論が異様に遅い場合、GPUではなくCPUで演算している可能性が高い。7Bパラメータのモデルで1トークン/秒以下という場合はほぼCPUフォールバックが起きている。

1. GPUの利用状況を確認する

# モデルを起動
$ ollama run llama3.3:8b-instruct-q4_0 "テスト" &

# 別ターミナルでGPU使用率をリアルタイム監視
$ watch -n 1 nvidia-smi
`nvidia-smi` の `GPU-Util` がOllama実行中に上昇（10%以上）すれば、GPUが正常に使われている。0%のままであればCPUのみで動作中だ。

2. NVIDIAドライバの状態を確認する

# NVIDIAドライバのインストール確認
$ nvidia-smi

# CUDAバージョンの確認
$ nvcc --version

# OllamaのログでGPU検出状況を確認
$ journalctl -u ollama -n 100 --no-pager | grep -i -E "gpu|cuda|nvidia"
`nvidia-smi` でドライバ情報が表示されない場合、ドライバが未インストールまたは破損している。Ubuntu Serverでは次の手順で修復できる。 
# 推奨ドライバを確認
$ ubuntu-drivers devices

# 推奨ドライバをインストール
$ sudo ubuntu-drivers autoinstall

# 再起動後に確認
$ sudo reboot
$ nvidia-smi

3. CUDAライブラリの整合性を確認する

ドライバは入っているのにOllamaがGPUを使わない場合は、CUDAライブラリのバージョン不一致が原因になっていることがある。

Ollamaは `/usr/local/cuda` または `LD_LIBRARY_PATH` にあるCUDAライブラリを参照する。バージョン不一致があると `no GPU detected` と表示される。
# CUDAライブラリのパスと存在確認
$ ls /usr/local/cuda/lib64/libcuda*
$ ldconfig -p | grep libcuda

# OllamaをCUDAデバッグモードで起動して確認
$ OLLAMA_DEBUG=1 ollama serve 2>&1 | grep -i cuda
`OLLAMA_DEBUG=1` を付けて起動すると、GPUの検出プロセスや使用するCUDAライブラリのパスが詳細に出力される。原因の特定に役立てよう。

VRAM不足・メモリ関連エラー（out of memory）の対処法

`CUDA out of memory` や `not enough VRAM to load model` といったエラーは、選択したモデルのサイズがGPUのVRAM容量を超えた場合に発生する。

1. 現在のVRAM使用量を確認する

# VRAM使用量をリアルタイム監視
$ watch -n 1 "nvidia-smi --query-gpu=name,memory.used,memory.free,memory.total --format=csv,noheader"

# GPU上のプロセスとVRAM使用量を確認
$ nvidia-smi --query-compute-apps=pid,name,used_memory --format=csv,noheader
他のプロセスがVRAMを占有している場合は、不要なプロセスを終了してからOllamaを再起動すると解決することがある。

2. 量子化精度を落としてVRAM消費を抑える

VRAM 8GBのGPUに70BパラメータのLlama3.3をロードしようとしたら当然エラーになる。モデルの量子化精度を下げることで、同一モデルをより少ないVRAMで動かせる。

・`q8_0`（高精度）→ `q4_K_M`（バランス）→ `q4_0`（省メモリ）の順でVRAM要件が下がる
・7Bクラスであれば `q4_0` タグで4GB程度のVRAMで動作する
# より軽量な量子化タグを指定してpull
$ ollama pull llama3.3:8b-instruct-q4_0

# 実行時に使用VRAMを確認
$ ollama run llama3.3:8b-instruct-q4_0 "テスト" &
$ nvidia-smi --query-gpu=memory.used --format=csv,noheader

3. CPUオフロードで大型モデルを動かす

VRAM不足でもCPU+RAMを使ったオフロード推論が可能だ。`OLLAMA_NUM_GPU` 環境変数で、何レイヤーをGPUで処理するかを制御できる。 
# num_gpuで一部レイヤーのみGPUを使うよう指定（0=CPU全量、-1=GPU全量）
$ OLLAMA_NUM_GPU=20 ollama run llama3.3:70b-instruct-q4_K_M "テスト"

# override.confに恒久設定する場合
[Service]
Environment="OLLAMA_NUM_GPU=20"
GPUレイヤー数を上げるとGPU側の処理が増え高速化する。VRAMが許す範囲で値を上げながら調整していく。

WSL2・Docker環境でOllamaが正常動作しないときの切り分け手順

WSL2とDockerはそれぞれ固有のネットワーク・デバイス仮想化レイヤーを持つ。ネイティブLinuxと同じ症状でも原因が異なるため、環境別の切り分けが必要だ。

1. WSL2でGPUが使えない場合

WSL2でGPUを使うには、Windows側にNVIDIA WSL2対応ドライバが必要だ。Linux側にCUDA Toolkitを別途インストールする必要はなく、`nvidia-smi` がWSL2から呼び出せれば十分だ。 
# WSL2からGPUが見えているか確認
$ nvidia-smi

# 見えない場合はWindowsドライバのバージョンを確認
# Windows PowerShellで実行: nvidia-smi
# CUDA Versionが表示されていなければドライバを更新する

2. WSL2でsystemdが動作しない場合

WSL2でOllamaをsystemdサービスとして動かせない場合、systemdが有効になっていないことが原因だ。 
# WSL2でのsystemd有効化設定を確認
$ cat /etc/wsl.conf

# [boot] セクションにsystemd=trueが必要
# なければ以下を追記
$ sudo bash -c 'cat >> /etc/wsl.conf << EOF
[boot]
systemd=true
EOF'

# PowerShellでWSLを再起動（Windowsターミナルで実行）
# wsl --shutdown
# wsl

3. DockerでGPUが使えない場合

Dockerコンテナ内でOllamaのGPU推論が動かない場合は、`nvidia-container-toolkit` の有無を確認する。 
# nvidia-container-toolkitのインストール確認
$ dpkg -l | grep nvidia-container

# GPUを使うコンテナの動作テスト
$ docker run --rm --gpus all nvidia/cuda:12.2-base-ubuntu22.04 nvidia-smi

# OllamaコンテナにGPUを渡す実行例
$ docker run -d --gpus all -v ollama:/root/.ollama -p 11434:11434 ollama/ollama
Docker内のOllamaから外部に接続できない場合は `OLLAMA_HOST=0.0.0.0` の設定を確認する。コンテナ内では `localhost` でバインドしても外部から到達できない。

社内チームへのOllama提供にあたって情シス担当者が気をつけるべきセキュリティ・運用体制については 社内でChatGPTが使えないときの代替手段｜機密データを守るローカルLLMという選択肢 も参考にしてほしい。

レスポンスが極端に遅い・タイムアウトするときの原因と対処

APIはつながるが1トークン/秒以下と異様に遅い場合、多くはCPUのみで推論していることが原因だ。GPU認識の確認は前述の手順で行う。

1. コンテキスト長が過大でないか確認する

GPU認識は正常でも遅い場合、`num_ctx`（コンテキストウィンドウ）が大きすぎることがある。デフォルトの2048から大きく変更している場合は設定を見直す。 
# num_ctxを明示して速度を比較する
$ curl http://localhost:11434/api/generate \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "llama3.3:8b-instruct-q4_0",
    "prompt": "テスト",
    "options": {"num_ctx": 2048}
  }'

2. 並列リクエストによるキュー詰まりを解消する

複数ユーザーが同時にリクエストを送る環境では、キューが積み上がってタイムアウトが発生することがある。`OLLAMA_NUM_PARALLEL` と `OLLAMA_MAX_LOADED_MODELS` で制御できる。 
# override.confに設定を追記する例（VRAM 24GB環境）
[Service]
Environment="OLLAMA_NUM_PARALLEL=2"
Environment="OLLAMA_MAX_LOADED_MODELS=2"
Environment="OLLAMA_KEEP_ALIVE=10m"

# 反映して再起動
$ sudo systemctl daemon-reload
$ sudo systemctl restart ollama
`OLLAMA_KEEP_ALIVE` はモデルをVRAMに保持する時間だ。デフォルトは5分で、アンロード・リロードのオーバーヘッドが頻発する場合は延ばしておくとよい。

3. クライアント側のタイムアウトを延ばす

クライアント側のタイムアウト設定が短すぎることも原因になる。`curl` であれば `--max-time` で明示的に延ばして試す。 
# タイムアウトを300秒に延ばして確認
$ curl --max-time 300 http://localhost:11434/api/generate \
  -H 'Content-Type: application/json' \
  -d '{"model": "llama3.3:8b-instruct-q4_0", "prompt": "テスト", "stream": false}'

よくある設定ミスと環境変数チェックリスト

Ollamaのトラブルには設定の抜け漏れが起点になるものが多い。以下の確認手順で設定を洗い出す。

1. 現在の環境変数を確認する

# systemdに渡されている環境変数を確認
$ systemctl show ollama | grep Environment

# Ollamaのバージョンを確認
$ ollama --version

# 動作中のモデル一覧を確認
$ ollama ps

2. 主要な環境変数チェックリスト

確認すべき主な環境変数の一覧:
・`OLLAMA_HOST` — バインドアドレスとポート（例: `0.0.0.0:11434`）
・`OLLAMA_MODELS` — モデル保存先（デフォルト: `/usr/share/ollama/.ollama/models`）
・`OLLAMA_NUM_PARALLEL` — 並列推論数（デフォルト: 1）
・`OLLAMA_MAX_LOADED_MODELS` — 同時ロード可能なモデル数（デフォルト: 1）
・`OLLAMA_NUM_GPU` — GPUレイヤー数（-1でGPU全量利用、0でCPUのみ）
・`OLLAMA_KEEP_ALIVE` — モデルのVRAM保持時間（例: `10m`, `1h`, `-1` で永続）
・`OLLAMA_DEBUG` — デバッグログ出力（`1` で有効）

3. 設定変更後の必須手順

設定変更後に `systemctl daemon-reload` を忘れているケースがトラブルの中でも特に多い。`override.conf` を編集したら必ずこの手順を踏む。 
# 設定変更後の必須手順
$ sudo systemctl daemon-reload
$ sudo systemctl restart ollama

# 再起動後に設定が反映されているか確認
$ systemctl show ollama | grep Environment

# APIの動作確認
$ curl http://localhost:11434/api/tags
また、`/etc/systemd/system/ollama.service` を直接編集してしまうと、`ollama` パッケージのアップデート時に上書きされてしまう。設定変更は必ず `override.conf` で行うのが正しい運用だ。

まとめ

Ollamaのトラブルシューティングで重要なのは「ログを見る→カテゴリを絞る→最小手順で検証する」の順序だ。闇雲に設定を変えても原因の特定が遠のくだけだ。変更は1箇所ずつ、効果を確認しながら進めることを徹底してほしい。

症状まず実行するコマンド主な原因
connection refusedsystemctl status ollamaサービス未起動・ポート競合
pullが途中で止まるdf -h /usr/share/ollamaディスク容量不足・ネットワーク断
GPUが使われないnvidia-smiドライバ未対応・CUDA不一致
out of memorynvidia-smi --query-gpu=memory.used --format=csvモデルサイズ超過・他プロセス占有
レスポンスが極端に遅いwatch nvidia-smiCPUフォールバック・コンテキスト過大
WSL2でGPUが使えないnvidia-smi（WSL2から実行）Windowsドライバ未更新
設定変更が反映されないsystemctl show ollama | grep Environmentdaemon-reload忘れ・override.conf未設定
トラブル対処を一通り身につけたら、次はAPIを使った業務システム統合やチームへのセキュアな提供へとステップアップしていくとよい。Ollamaは構築後の安定運用こそが本番活用の鍵になる。

ローカルLLMの構築・運用・トラブル対処を2日間のハンズオンで体験する

「ログの読み方がわからない」「GPU環境が正しく動いているか自信がない」という方は、実機環境での設定確認から問題の切り分けまでを実践で身につけるのが確実だ。実機GPU環境で手を動かしながら習得したい方向けに、「ローカルAIマスターセミナー」を開催しています。
少人数（最大8名）ZOOMハンズオン形式で実施しています。

＞＞ ローカルAIマスターセミナーの詳細を確認する
ローカルLLMの構築・運用に関する関連記事もあわせて参考にしてください。

・Ubuntu ServerでローカルLLMを構築する方法｜Ollamaで機密データを外に出さず業務AIを動かす完全ガイド
・社内でChatGPTが使えないときの代替手段｜機密データを守るローカルLLMという選択肢
・ローカルLLMのモデルを比較する方法｜Llama3.3・Mistral・Gemma・Phi-4をUbuntuで使い分けるポイント

関連記事

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら

Linux無料マニュアル（図解60P） 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広（みやざき ともひろ）

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。