【2026年版】VPSで「CUDA out of memory」が出た時の対処法とプラン変更の目安

最初に結論を書きます

OOMが出ても、いきなりプランを上げるのだけは待ってください。

正直に言うと、int4量子化を試しただけで解決したケースが体感7〜8割です。Llama-3-8Bで言えば、fp32で約32GB必要だったVRAMがint4で約4GBになる。8倍近く減る。それだけで「足りなかったVRAM」が「余るVRAM」に化けることがある。

プランアップグレードを考えるのは、量子化・バッチサイズ調整・キャッシュ解放を全部やって、それでもOOMが出てから。この順番を間違えると、毎月数千円を不要に払い続けることになります。月7,000円のGPUプランを12ヶ月使えば84,000円。量子化5分で解決できたものに84,000円払うのはさすがにもったいない。これだけ最初に言わせてください。

GPU VPSでAIモデルを動かしていると、ある日突然こんなエラーが出ます。

torch.cuda.OutOfMemoryError: CUDA out of memory.
Tried to allocate 2.50 GiB (GPU 0; 15.78 GiB total capacity;
13.25 GiB already allocated; ...)

「VRAMが足りない」というシンプルなエラーなんですが、対処の順番を間違えるとコストが跳ね上がります。この記事では原因の切り分けから、コードレベルの対処法、それでもダメなときのプランアップグレード判断まで、実際に試行錯誤した経験ベースで書きます。

CUDA OOMが発生する主な原因

はっきり書いておきます。「モデルサイズが大きすぎる」と「キャッシュが蓄積している」がほとんどのケースで原因です。複数プロセスの競合は、自分で意図して何かを立ち上げていなければまず関係ない。最初の2つを疑うだけで十分で、4番目まで全部調べようとするのは時間の無駄になりやすい。

まず確認：現在のVRAM使用状況

# GPUの使用状況を確認する
nvidia-smi

# 1秒ごとにリアルタイム監視する
watch -n 1 nvidia-smi

# Pythonから確認する
python3 -c "
import torch
print(f'VRAM総量: {torch.cuda.get_device_properties(0).total_memory / 1024**3:.1f} GB')
print(f'使用中: {torch.cuda.memory_allocated() / 1024**3:.2f} GB')
print(f'予約済み: {torch.cuda.memory_reserved() / 1024**3:.2f} GB')
"

nvidia-smi を見て「VRAM総量の何%を使っているか」を最初に把握する。90%を超えていたらその時点で危険水域。安定して動かすなら50〜60%くらいに収まっているのが理想です。

自分の場合、OOMが出たらまずこれを見る習慣をつけてから、「とりあえずプランを上げる」という無駄な出費をしなくなりました。状況を数字で把握するだけで、次に何をすべきかが見えてくる。感覚で動くより、まず nvidia-smi 1コマンドです。

XServer VPS →のGPUプランは nvidia-smi でVRAM使用量をリアルタイム監視でき、何が問題かすぐに切り分けられます。

対処法1：量子化でモデルの使用VRAMを削減する

これが一番効きます。正直、まずここから試してほしい。他の対処法は後でいい。

量子化（Quantization）とは、モデルの精度を少し下げることでVRAM消費を大幅に削減する技術です。fp32 → fp16 → int8 → int4 の順に精度を下げるほどVRAM消費が減ります。

from transformers import AutoModelForCausalLM, BitsAndBytesConfig
import torch

# int8量子化（VRAMをfp32の約半分に削減）
model = AutoModelForCausalLM.from_pretrained(
    "meta-llama/Llama-3-8B",
    load_in_8bit=True,
    device_map="auto"
)

# int4量子化（さらに半分、品質低下はわずか）
bnb_config = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_quant_type="nf4",
    bnb_4bit_compute_dtype=torch.float16,
)
model = AutoModelForCausalLM.from_pretrained(
    "meta-llama/Llama-3-8B",
    quantization_config=bnb_config,
    device_map="auto"
)

量子化によるVRAM削減効果（Llama-3-8Bの場合）

自分の場合、テキスト生成の用途でint4とfp16の出力を見比べても正直わからないレベルでした。「品質が落ちるから使いたくない」という気持ちはわかります。ただ、使ってみる前から諦めるのはもったいない。まず試して、自分の用途で問題があるかどうかを確かめてから判断する。その順番で考えてください。プランを上げるのはそれからでも全然遅くない。

対処法2：バッチサイズを減らす

バッチサイズを半分にすると、VRAM消費も概ね半分になります。

# Before: バッチサイズ32で OOM
dataloader = DataLoader(dataset, batch_size=32)

# After: バッチサイズを1まで下げて様子を見る
dataloader = DataLoader(dataset, batch_size=1)

# 勾配累積で実効バッチサイズを維持する
accumulation_steps = 16  # batch_size=1 × 16ステップ = 実効batch_size 16
optimizer.zero_grad()
for i, (inputs, labels) in enumerate(dataloader):
    outputs = model(inputs)
    loss = criterion(outputs, labels) / accumulation_steps
    loss.backward()
    if (i + 1) % accumulation_steps == 0:
        optimizer.step()
        optimizer.zero_grad()

「バッチサイズ1にしたら遅くなる」という懸念はその通りです。でも勾配累積を使えば、実効的なバッチサイズを維持したまま1バッチあたりのVRAM消費を抑えられます。学習用途なら特にこの組み合わせが有効。「速度を犠牲にしてVRAMを確保する」という割り切りをどこかでする必要が出てくることはあります。ただそれでも、プランを上げる前に試す価値は十分にある。

対処法3：推論後にGPUキャッシュを解放する

推論ループ内でキャッシュが溜まり続けることがあります。

import torch
import gc

def run_inference(model, inputs):
    with torch.no_grad():
        outputs = model(**inputs)

    # 推論後にキャッシュを明示的に解放する
    del inputs
    torch.cuda.empty_cache()
    gc.collect()

    return outputs

これを入れていないコードをよく見かけます。torch.cuda.empty_cache() はワンライナーで追加できるので、推論ループを書くときは最初から入れておく習慣をつけた方がいい。後から「なんでVRAMがじわじわ増えるんだ」と30分悩む時間が省けます。自分もこれで一度ハマっていて、原因がわかったときは普通に笑いました。ハマる前に入れておいてください。

さくらのVPS →はGPUプランへのプランアップグレードが可能で、上記の対処を全部やってもVRAMが足りなかった場合の移行先として検討できます。

それでも解決しない場合：プランアップグレードの判断基準

コードレベルの対処を全部試してもOOMが続く場合は、プランアップグレードを検討します。

誤解されたくないので書いておく。ここに来るまでに上の3つを全部やってから判断してください。「OOMが出た→プランを上げた」という流れは、コスト的に損をしやすいパターンです。量子化・バッチサイズ調整・キャッシュ解放、この3つを全部試した上でもまだ駄目なら、そこで初めてプランアップグレードが選択肢に入る。順番が大事です。

アップグレードすべき目安

VPS GPU プラン別VRAM比較

月7,000円はそれなりの金額です。1日あたり約230円、1時間あたり約9.7円。毎日がっつり使い倒すなら納得できる金額ですが、週に数回しか触らないなら計算が合わなくなってきます。

自分の使用頻度と照らし合わせて、「月に何時間使うか」を一度計算してみてください。週2回・1回2時間なら月16時間。月7,000円を16時間で割ると1時間あたり437円。その金額を払う価値が用途にあるかどうかを、アップグレードボタンを押す前に考えてほしい。「とりあえず上げてみるか」は一番もったいない判断です。

まとめ：あなたの使い方で選ぶ判断テーブル

体感として、量子化だけで解決するケースが体感7〜8割です。プランを上げる前に必ず試してください。それで解決しなかったときに初めてアップグレードを考えればいい。「どうせVRAMが足りないんだろう」と最初から決めつけてプランを上げるのが、一番もったいないパターンです。

XServer VPS →

さくらのVPS →

これが最終回答じゃないので、まずint4量子化を5分試してみてください。ダメだったらその時点でまた考えればいい。試してから判断する、この順番だけで無駄なコストをかなり減らせます。自分もそうやって試行錯誤しながらやっています。一緒にやっていきましょう。

あわせて読みたい

• AIツール（Claude Code / Codex）向けVPS比較ランキング初心…
• 失敗しないGPUサーバー選び：VRAM 24GB以上を格安で確保できるVPSラン…
• GPU搭載VPSを「必要な時だけ」時間単位で借りて画像生成AIをお試しする方法
• あなたに合うVPSを30秒で診断する