ローカルLLMの「CUDA out of memory」エラーの解決法

ローカルLLMをGPUで動かしていると、突然こんなエラーが出て止まることがあります。「CUDA error: out of memory」。直訳すれば「メモリ不足」ですが、このメモリはパソコンのRAMではなく、GPU上のVRAMのことです。

結論から言うと、量子化（Quantization）レベルを下げたモデルに切り替えるのが最も効果的です。本記事では、実際に Ollama 0.30.8 の API を叩いて、同じモデルを量子化レベル違いでロードし、確保されるメモリ量を1バイト単位で実測しました。FP16（フル精度）と Q4_K_M を比べると、確保メモリが 55.4% も減ることが数字で確認できました。想像ではなく実測データで、順番に解説していきます。

この記事のポイント

「CUDA out of memory」はVRAM不足が原因。パソコンのRAMとは別物
量子化モデル（Q4_K_M）に切り替えると確保メモリが55.4%減る（qwen2.5 0.5Bで実測）
コンテキスト長 num_ctx を 16384→512 にすると約580MB節約できる（llama3.2:1bで実測）
nvidia-smi や Ollama の /api/ps でメモリ使用量をリアルタイムに確認できる
GPUに載らない場合は OLLAMA_NUM_GPU で一部をCPUにオフロードできる

動作確認環境

本記事のメモリ実測は Ollama 0.30.8 の /api/ps が報告する確保メモリ量（size_vram）を計測したものです（2026-06-15）。CUDA/nvidia パッケージのバージョンは docker run --rm ubuntu:22.04 / ubuntu:24.04 で実測しています。なお nvidia-smi のスクリーンショットと CUDA OOM エラー画面は、NVIDIA GPU の典型的な出力を再現したもの（再現UI）です。量子化によるメモリ削減率はGPUの種類に依存しない普遍的な指標なので、そのまま参考にできます。

「CUDA out of memory」とはどういうエラーか
まずメモリ使用量を確認する
解決策1: 量子化モデルを選ぶ（一番効果的）
1. ①量子化モデルの指定方法（Ollama）
2. ②モデルサイズ別の早見表（実測）
解決策2: コンテキスト長を減らす（num_ctx）
解決策3: GPUレイヤー数を調整する（OLLAMA_NUM_GPU）
解決策4: 他プロセスのGPU使用を確認・終了する
解決策5: スワップ領域を増やす（CPU実行時のメモリ不足対策）
Ubuntu の CUDA 関連パッケージバージョン（実測）
解決策のまとめ・優先順位
よくある追加エラーと対処法
まとめ

「CUDA out of memory」とはどういうエラーか

LLM（大規模言語モデル）をGPUで動かすとき、モデルのウェイト（重み）はVRAM上に展開されます。VRAMはメインメモリ（RAM）とは別の、GPU専用のメモリです。RTX 3080なら10GB、RTX 4090なら24GBといった具合に上限が固定されています。

モデルが要求するメモリが搭載VRAMを上回ると、CUDAがエラーを返します。これが「CUDA out of memory」です。正直、最初に見たときは「何が足りないの？」と詰まるエラーですが、仕組みがわかれば対処は難しくありません。

上の例では70Bモデル（Q8_0量子化）をロードしようとして失敗しています。70Bクラスは Q8_0 でも数十GBのVRAMを要求するため、10GB前後のGPUでは到底足りません。一方で、後述するように 8B クラスの Q4_K_M なら5GB以下に収まります。「モデルを小さくする」のではなく「同じ系統のモデルを軽い精度で動かす」のがコツです。

まずメモリ使用量を確認する

エラーに遭遇したら、最初に現在のメモリ使用量を確認しましょう。NVIDIA GPUなら nvidia-smi コマンドが基本です。

「9856 MiB / 10240 MiB」のように使用量が上限近くになっていれば、そのプロセスがVRAMをほぼ独占しています。別のOllamaプロセスや他のAIアプリが残っていれば、それを終了してから再試行しましょう（具体的な終了手順は後述します）。

さらに、Ollamaを使っているなら /api/ps エンドポイントが便利です。いまロードされているモデルが実際に何バイトのメモリを確保しているかを正確に教えてくれます。

注目すべきは size_vram の値です。これがロードされたモデルが確保したメモリ量（バイト）で、GPU利用時はそのままVRAM消費量に対応します。上の例では 479954205 バイト、つまり約457.7MBでした。この数値を基準に、次から「どうすれば減らせるか」を見ていきます。

解決策1: 量子化モデルを選ぶ（一番効果的）

CUDA OOMへの対処として最も効果的なのが、量子化（Quantization）レベルを下げたモデルへの切り替えです。量子化とは、モデルの重み（浮動小数点数）を低いビット精度で表現することでサイズを削減する技術です。FP16（16ビット）を Q8_0（8ビット相当）や Q4_K_M（4ビット相当）にすると、その分メモリが減ります。

どれくらい減るのか、実際に測りました。同じ qwen2.5 0.5B（494.03M パラメータ）を、量子化レベルだけ変えて Ollama に順番にロードし、/api/ps が返す size_vram を比較したのが次のグラフです。

FP16では1026.4MBだった確保メモリが、Q8_0で584.8MB（-43.0%）、Q5_K_Mで479.0MB（-53.3%）、デフォルトの Q4_K_M では457.7MB（FP16比 -55.4%）まで下がりました。モデルの中身（パラメータ数）は同じなのに、精度を落とすだけで確保メモリが半分以下になるわけです。数値で並べると次のとおりです。

実際にこの計測を走らせたときの実行ログがこちらです。4つの量子化版を順にロードして、それぞれの確保メモリを読み取っています。

①量子化モデルの指定方法（Ollama）

Ollamaでは、モデル名の末尾に量子化レベルを指定できます。OOMが起きたら、まず重いタグ（fp16 など）になっていないか確認しましょう。

ubuntu@gpu-server: ~

$ # ❌ FP16 は重い（qwen2.5 0.5B でも約1GBを確保する）
$ ollama run qwen2.5:0.5b-instruct-fp16

$ # ✅ Q4_K_M に切り替える（確保メモリが約45%まで縮む）
$ ollama run qwen2.5:0.5b
>>> Send a message (/? for help)
# 末尾にタグを付けない qwen2.5:0.5b はデフォルトで Q4_K_M

Ollamaのデフォルトモデル（例: ollama pull llama3.1:8b）はQ4_K_Mが選ばれます。OOMが起きた場合は、まずモデル名に fp16 や q8_0 などの重いタグが付いていないか確認してください。

②モデルサイズ別の早見表（実測）

手元の Ollama に pull 済みのモデルを /api/tags から取得し、実サイズを並べたのが次の表です。0.5Bクラスから8Bクラスまで、Q4_K_M中心で比較しています。

注目したいのは、日本語特化の8Bモデル（Llama-3-ELYZA-JP-8B）でも、Q4_K_M なら約4.7GBに収まっている点です。VRAM 8GBクラスのGPUでも、8B Q4_K_M なら十分動かせる目安になります。逆にこれをFP16で動かそうとすると単純計算で倍以上、OOMの原因になります。

解決策2: コンテキスト長を減らす（num_ctx）

コンテキスト長は「一度の会話で何トークン分を記憶するか」を決める値です。この値を増やすと、その分だけKVキャッシュ（会話履歴を保持する領域）のメモリが増えます。Ollamaのデフォルトは num_ctx=4096 です。

どれくらい効くのか、これも実測しました。llama3.2:1b を num_ctx だけ変えてロードし、確保メモリの変化を測ったのが次のグラフです。

num_ctx=512 で1324.9MBだった確保メモリが、4096で1440.4MB、8192で1636.4MB、16384では1908.4MBまで増えました。512 と 16384 の差は約580MBです。日常的なチャットなら 1024〜2048 で足りることが多く、デフォルトの4096から下げるだけでも数十〜100MB単位で節約できます。「あと少しでVRAMに収まりそう」というときに効く一手です。

ubuntu@gpu-server: ~

$ # コンテキスト長を短くして実行（Ollama CLI）
$ ollama run llama3.2:1b –num-ctx 1024
>>> Send a message (/? for help)

$ # Modelfile で永続的に設定する場合
$ cat Modelfile
FROM llama3.2:1b
PARAMETER num_ctx 1024

$ ollama create mymodel -f Modelfile
success
$ ollama run mymodel

Open WebUI を使っている場合は、モデルの「詳細設定」から num_ctx を変更できます。正直、量子化と合わせて最初に試す価値があります。

解決策3: GPUレイヤー数を調整する（OLLAMA_NUM_GPU）

モデルがVRAMに収まらない場合、一部のレイヤーをCPU（メインRAM）で処理させることができます。速度は落ちますが、とりあえず動かしたいときに有効です。

ubuntu@gpu-server: ~

$ # 全レイヤーをCPUで実行（GPUを使わない）
$ OLLAMA_NUM_GPU=0 ollama serve

$ # 一部をGPU、残りをCPUにオフロード（数値はモデルの総レイヤー数より少なくする）
$ OLLAMA_NUM_GPU=20 ollama serve

# Modelfile で設定する場合（num_gpu パラメータ）
PARAMETER num_gpu 20

# 確認: ロード後に /api/ps を見ると size_vram と size の差でCPU側の量がわかる
$ curl -s http://localhost:11434/api/ps | python3 -m json.tool

注意: CPU実行は大幅に遅くなります

OLLAMA_NUM_GPU=0 にするとすべてのレイヤーがCPUで処理されるため、トークン生成速度が大きく低下します。テスト目的なら有効ですが、日常使いには量子化モデルを選ぶ方が現実的です。

解決策4: 他プロセスのGPU使用を確認・終了する

バックグラウンドで別のAIプロセスや以前の ollama serve セッションが動いていると、VRAMが専有されたままになります。

ubuntu@gpu-server: ~

$ # GPUを使っているプロセスを確認
$ nvidia-smi –query-compute-apps=pid,process_name,used_memory –format=csv,noheader
2847, /usr/bin/ollama, 9820 MiB
1234, python3, 350 MiB

$ # 不要なプロセスを終了（PID指定）
$ kill 1234

$ # Ollamaサービスを再起動する場合
$ sudo systemctl restart ollama

$ # 再起動後にVRAMが解放されたか確認
$ nvidia-smi –query-gpu=memory.free –format=csv,noheader
10143 MiB

Ollamaは一定時間後にモデルをVRAMからアンロードします。このタイムアウトは OLLAMA_KEEP_ALIVE 環境変数で調整でき、たとえば OLLAMA_KEEP_ALIVE=0 にすると応答後すぐにアンロードされ、メモリを長く専有しなくなります（デフォルトは5分）。

解決策5: スワップ領域を増やす（CPU実行時のメモリ不足対策）

GPUを使わずCPUで大きなモデルを動かす場合、今度はシステムRAMが不足することがあります。そのときはスワップ（SSD上の仮想メモリ）を増やすことで動かせる場合があります。

注意: 以下は書き込みを伴うコマンドです

fallocate や mkswap はシステムにスワップファイルを作成します。誤ったパスを指定しないよう、コマンドはよく確認してから実行してください。

ubuntu@gpu-server: ~

$ # 現在のメモリ・スワップ状況を確認
$ free -h
total used free shared buff/cache available
Mem: 31Gi 14Gi 12Gi 1.2Gi 4.9Gi 15Gi
Swap: 2.0Gi 2.0Gi 0B
# スワップが枯渇している → 拡張が必要

$ # 16GBのスワップファイルを作成
$ sudo fallocate -l 16G /swapfile
$ sudo chmod 600 /swapfile
$ sudo mkswap /swapfile
$ sudo swapon /swapfile
Setting up swapspace version 1, size = 16 GiB

$ free -h
Swap: 18Gi 2.1Gi 15Gi

注意: スワップ実行は非常に遅い

SSDベースのスワップでも、VRAMやRAMと比べて大幅に低速です。テストや緊急時の回避策として使い、本番利用は量子化モデル＋GPU運用を推奨します。

Ubuntu の CUDA 関連パッケージバージョン（実測）

「CUDA error: no kernel image is available」のようなエラーは、CUDAとドライバのバージョン不整合が原因のことがあります。Ubuntu公式リポジトリでどのバージョンが入るのか、docker run --rm ubuntu:22.04 / ubuntu:24.04 で実測しました。

Ubuntu公式の nvidia-cuda-toolkit は、22.04 が CUDA 11.5系、24.04 が CUDA 12.0系でした。一方、ドライバ系の nvidia-utils-535 / nvidia-driver-535 はどちらも 535.309.01 で共通です。より新しいCUDA（12.3以降など）が必要な場合は、NVIDIA公式リポジトリを追加して cuda-toolkit-12-x を個別にインストールする必要があります。

ubuntu@linuxlab: ~

$ docker run –rm ubuntu:24.04 bash -c “apt-get update -qq && apt-cache policy nvidia-cuda-toolkit”
nvidia-cuda-toolkit:
Installed: (none)
Candidate: 12.0.140~12.0.1-4build4

$ docker run –rm ubuntu:22.04 bash -c “apt-get update -qq && apt-cache policy nvidia-cuda-toolkit”
nvidia-cuda-toolkit:
Candidate: 11.5.1-1ubuntu1
# 24.04 は CUDA 12.0系 / 22.04 は CUDA 11.5系

解決策のまとめ・優先順位

ここまでの解決策を、効果が大きく手軽な順に並べたチェックリストです。上から順に試すのがおすすめです。

よくある追加エラーと対処法

①「llm runner process has terminated: exit status 1」

OOMエラーの直前によく出るメッセージです。内部でモデルのロードプロセスがクラッシュしたことを示します。原因がVRAM不足であることが多く、量子化モデルへの切り替えで解決することがほとんどです。

②「CUDA error: no kernel image is available for execution on the device」

CUDAのバージョンとGPUドライバのバージョンが合っていないときに出ます。nvcc --version（CUDAツールキット側）と nvidia-smi 上部に表示されるCUDAバージョン（ドライバ側）が大きく食い違っていないか確認してください。軽微な差（例: 12.0と12.2）なら通常は問題ありません。

③「RuntimeError: CUDA out of memory. Tried to allocate xxx GiB」（PyTorch）

PyTorchで直接モデルを読み込む場合のエラーです。Ollamaとは別のツールチェーンですが、考え方は同じで、4bit量子化での読み込みが有効です。

ubuntu@gpu-server: ~

$ python3 -c “import torch; print(torch.cuda.get_device_properties(0))”
_CudaDeviceProperties(name=’NVIDIA GeForce RTX 3080′, major=8, minor=6,
total_memory=10240MB, multi_processor_count=68)

# bitsandbytes で 4bit 量子化して読み込む
$ pip install bitsandbytes transformers accelerate
model = AutoModelForCausalLM.from_pretrained(
“meta-llama/Llama-3.1-8B”,
load_in_4bit=True, # ← 4bit量子化でVRAM削減
device_map=”auto”
)