RAM requirements

概要

RAM requirements（メモリ要件）は、ローカルLLM運用において「どの量子化レベルのどのモデルサイズを、どの程度のRAM/VRAMを積んだマシンで動かせるか」を判断するための実務的な指標です。クラウドAPIと違い、ローカル実行ではメモリ不足が即座に「実行不可（OOM）」または「極端な速度低下」として表面化するため、購入前・導入前の見積もりが特に重要になります。

必要なRAM容量は主に3つの要素で決まります。①モデルのパラメータ数（7B・13B・70Bなど）、②量子化レベル（FP16・INT8・4bit GGUFなど）、③コンテキスト長とKVキャッシュのサイズです。同じ7Bモデルでも、FP16で読み込めば約14GB、4bit量子化（GGUF Q4_K_M相当）なら約4〜5GBまで圧縮でき、必要RAM容量は3倍以上変わります。

また「RAM」と「VRAM」は役割が異なります。VRAMはGPU推論を高速化する専用メモリ、RAMはCPU推論やGPUに載り切らない層（オフロード分）を保持する汎用メモリです。Ollama・LM Studio・llama.cppといった代表的なローカルLLM実行ツールは、いずれもVRAMとRAMを併用する「ハイブリッド推論」に対応しており、GPUが非力な環境でもRAM容量さえ確保できればモデルを動かせます（ただし速度はVRAM単独実行より大幅に低下します）。

仕組み：モデルサイズ・量子化・コンテキスト長の関係

モデルサイズ別推奨RAM（量子化なし〜軽量量子化）

精度別メモリ使用量（1パラメータあたり）

• FP32: 4 bytes/parameter
• FP16 / BF16: 2 bytes/parameter
• INT8: 1 byte/parameter
• INT4: 0.5 bytes/parameter

GGUF量子化レベル別の実測目安（7Bモデル基準）

llama.cpp・Ollama・LM Studioで広く使われるGGUF形式は、量子化レベルごとにファイルサイズと必要RAMの目安が公開されています。一般に「Kクォンツ」（Q4_K_M、Q5_K_Mなど）は単純な4bit・5bit丸めより精度劣化が少なく、実務でのデフォルト選択肢になっています。

13B・70Bモデルは上記のサイズをおおむねパラメータ比（13Bなら約1.86倍、70Bなら10倍）でスケールさせて見積もれます。ただし語彙サイズや層構成の違いで多少前後するため、実際にダウンロードするGGUFファイルのサイズ表示を最終判断材料にするのが確実です。

コンテキスト長とKVキャッシュの影響

モデル本体のメモリに加えて見落とされがちなのがKVキャッシュ（Key-Valueキャッシュ）です。会話履歴や長文プロンプトを扱う際、コンテキスト長が伸びるほどKVキャッシュのメモリ消費も線形に増加します。7BクラスのモデルでコンテキストをQ4量子化KVキャッシュ込みで4Kトークンから32Kトークンまで拡張すると、追加で数百MB〜数GB単位のRAM/VRAMが必要になることがあります。長文要約やRAG用途で32K〜128Kコンテキストを扱う場合は、モデル本体の見積もりに加えて1〜4GB程度の余裕を上乗せしておくと安全です。

具体例：モデル別メモリ計算（Llama 2の例）

Llama 2 7B の例

# Llama 2 7B メモリ使用量計算
パラメータ数: 7B (7,000,000,000)

# 精度別メモリ使用量
FP32: 7B × 4 bytes = 28GB
FP16: 7B × 2 bytes = 14GB
INT8: 7B × 1 byte = 7GB
INT4: 7B × 0.5 bytes = 3.5GB

# 実際の推奨システムRAM（オーバーヘッド込み）
FP16実行: 32GB RAM推奨
INT8実行: 16GB RAM推奨
INT4実行: 16GB RAM推奨

Llama 2 70B の例

# Llama 2 70B メモリ使用量計算
パラメータ数: 70B (70,000,000,000)

# 精度別メモリ使用量
FP32: 70B × 4 bytes = 280GB
FP16: 70B × 2 bytes = 140GB
INT8: 70B × 1 byte = 70GB
INT4: 70B × 0.5 bytes = 35GB

# 実際の推奨システムRAM
FP16実行: 160GB+ RAM必要
INT4実行: 64GB+ RAM推奨

推論速度（tokens/秒）の目安

RAM容量が足りていても、CPU推論のみの場合はメモリ帯域幅（メモリバス）が速度上限を決めます。以下はGGUF・Q4_K_M量子化モデルを想定した、環境別のtokens/秒のおおよその目安です（実際の数値はCPU世代・メモリチャネル数・GPU有無で大きく変動するため参考値としてご覧ください）。

目安として、GPUのVRAMにモデル全体が収まっている状態では快適な対話速度（数十tokens/秒以上）が出やすく、CPU・RAMのみに頼る構成では体感速度が大きく低下します。一部の層だけをRAM側にオフロードする「部分オフロード」は、VRAM不足時の妥協案として有効ですが、オフロード比率が増えるほど速度は線形以上に低下する傾向があります。

具体例：システム構成別のRAM/VRAM推奨

NVIDIA GPU環境

Apple Silicon環境

• M2 (8-24GB): 統合メモリのため16-24GB
• M2 Pro (16-32GB): 統合メモリ24-32GB推奨
• M2 Ultra (64-192GB): 大規模モデル対応

Apple SiliconのUnified Memoryは、CPUとGPUが同一の物理メモリ空間を共有する方式です。搭載メモリの一部をVRAM相当として動的に割り当てるため、「VRAM容量」という概念自体がNVIDIA環境と異なります。一般に総メモリの一部（OS予約分を除く大半）までをGPUタスクに割り当て可能とされており、大容量メモリ搭載モデルほど大きなLLMを動かしやすくなります。

主要ツールのメモリ管理・量子化対応状況

同じ「RAM要件」でも、使用するツールによってメモリ管理方式や対応量子化形式が異なります。導入前に自分の使いたいツールがどこまで自動化してくれるかを把握しておくと、見積もりの精度が上がります。

初めてローカルLLMを試す場合はOllamaかLM Studioでのメモリ自動管理から始め、細かいチューニングが必要になった段階でllama.cppのオプションを直接触る、という順序が実務上スムーズです。

具体例：予算別・用途別の構成例

エントリーレベル（予算15万円以下）

ミドルレンジ（予算30万円）

ハイエンド（予算100万円+）

予算を決めてから逆算する場合は、「まず動かしたいモデルサイズと量子化レベルを決め、そこから逆算してVRAM/RAM容量を決める」順序がおすすめです。後からRAMだけを増設するのは比較的容易ですが、GPUのVRAM容量は後から拡張できないため、GPU選定の段階で余裕を持たせておくことが重要です。

メリット・デメリット

RAM要件を正しく見積もって運用することには明確な利点がある一方、量子化やオフロードで容量を切り詰めることにはトレードオフが伴います。導入前に両面を理解しておくことで、後悔の少ない構成選びができます。

メリット

• コスト最適化: 必要なRAM容量を事前に把握することで、過剰なメモリ投資を避け、モデルサイズに見合った構成に予算を配分できる
• 安定運用: OOM（メモリ不足によるクラッシュ）やスワップ発生による極端な速度低下を事前に回避できる
• プライバシー・オフライン性の確保と両立: クラウドAPI利用時のようなネットワーク遅延やAPI利用料を気にせず、手元のマシンのメモリ容量に応じたモデル選択で継続的に運用できる
• スケールの見通しが立つ: 7B→13B→70Bと段階的にモデルを大きくする際、必要なRAM増加量を事前に見積もれるため、将来の増設計画が立てやすい

デメリット・注意点

• 量子化による精度低下: RAM容量を抑えるために量子化レベルを下げる（Q4→Q3、Q2等）と、特に複雑な推論・コード生成・数値計算タスクで出力品質が目に見えて劣化することがある
• 速度とのトレードオフ: RAM/CPUオフロードでメモリ不足を補う場合、VRAM単独実行に比べて推論速度が大幅に低下する（体感で数分の1〜十分の1程度になることもある）
• 見積もりのブレ: OSやバックグラウンドプロセス、他のアプリケーションが使用するメモリを考慮しないと、理論値どおりの容量では不足することがある
• 拡張性の制約: GPUのVRAMは後から増設できないため、当初の見積もりが甘いとGPU自体の買い替えが必要になる場合がある（RAMより投資額へのインパクトが大きい）
• 長いコンテキストでの想定外の消費: KVキャッシュのメモリ消費を見落とし、長文処理時に想定より早くメモリ上限に達するケースがある

混同されやすい用語・類似技術との違い

「メモリ」という言葉が指す対象は文脈によって異なり、初学者が混同しやすいポイントです。それぞれの役割の違いを整理します。

特に混同されやすいのは「RAM容量さえ多ければVRAM不足を完全にカバーできる」という誤解です。RAMオフロードは実行を可能にする手段であって、VRAM単独実行と同等の速度を保証するものではありません。快適な対話速度を求めるなら、モデル全体がVRAMに収まる構成を優先し、収まらない場合のみRAMオフロードを補助的に使うのが実務上のセオリーです。

実務ポイント：メモリ最適化技術

CPU-GPU オフロード

# Transformersでのメモリ最適化
from transformers import AutoModelForCausalLM
import torch

# CPU-GPU間でのメモリ分散
model = AutoModelForCausalLM.from_pretrained(
    "meta-llama/Llama-2-70b-chat-hf",
    device_map="auto",  # 自動的にメモリ配分
    max_memory={
        0: "20GB",      # GPU 0: 20GB使用
        "cpu": "60GB"   # CPU RAM: 60GB使用
    }
)

# 低メモリモード
model = AutoModelForCausalLM.from_pretrained(
    model_name,
    torch_dtype=torch.float16,
    low_cpu_mem_usage=True,
    device_map="auto"
)

量子化による最適化

• 動的量子化: 実行時にINT8変換
• 静的量子化: 事前にINT8/INT4変換
• 混合精度: 重要な層のみFP16維持

llama.cpp / Ollamaでのオフロード調整例

# llama.cppでGPUオフロード層数を指定して起動
./llama-server -m model-Q4_K_M.gguf --n-gpu-layers 32 --ctx-size 8192

# Ollamaで実行（VRAM状況に応じて自動オフロード）
ollama run llama3:70b

# Ollamaのメモリ関連環境変数の例
OLLAMA_NUM_GPU=999   # 可能な限り多くの層をGPUに配置
OLLAMA_MAX_LOADED_MODELS=1  # 同時ロードするモデル数を制限してRAM消費を抑制

GPUオフロード層数（--n-gpu-layersや-ngl）は、VRAM容量が許す範囲で大きくするほど推論速度が向上します。VRAMが不足する場合は数値を段階的に下げて、OOMが発生しない上限を探るのが実務上の定石です。

実務ポイント：パフォーマンス監視とトラブルシューティング

メモリ不足時の影響

• スワップ発生: 大幅な速度低下
• OOM (Out of Memory): 処理停止
• バッチサイズ制限: 並列度低下
• モデル分割: レイテンシ増加

メモリ監視コマンド

# システムメモリ監視
free -h        # Linux: メモリ使用量確認
htop           # リアルタイム監視
vm_stat        # macOS: メモリ統計

# GPU メモリ監視
nvidia-smi     # NVIDIA GPU
watch -n 1 nvidia-smi  # 1秒間隔で更新

# Python内でのメモリ監視
import psutil
print(f"Available RAM: {psutil.virtual_memory().available // 1024**3} GB")

import torch
print(f"GPU Memory: {torch.cuda.memory_allocated() // 1024**3} GB")

メモリ不足の対処チェックリスト

• より小さいモデル、またはより低い量子化レベル（Q4→Q3等）への切り替え
• コンテキスト長（--ctx-size等）を必要最小限に絞ってKVキャッシュを削減
• 同時に読み込むモデル数を1つに制限（複数モデル常駐は避ける）
• スワップ領域の拡大（NVMe SSD推奨、HDDでは速度低下が顕著）
• 物理RAMの増設、またはApple Silicon MacのようなUnified Memory環境への移行

2025-2026年の最新動向

DDR5メモリの普及により、帯域幅が向上しCPU推論時のメモリボトルネックが緩和されています。DDR5-6400以上の高速メモリが一般化しています。

Apple Silicon M4シリーズのUnified Memoryが最大192GB程度まで拡大し、RAM/VRAM区別なく大規模モデルを実行できる環境として注目されています。

メモリ効率化技術（KV-cache量子化、PagedAttention等）の進化により、同じRAM容量でもより長いコンテキストの処理が可能になっています。

GGUFのKクォンツ量子化やIQ系量子化（Importance Matrixベースの量子化）の改良により、従来より低いビット数でも実用的な精度を維持しやすくなっており、同じRAM容量でより大きなモデルを動かせる余地が広がっています。Ollama・LM Studio・llama.cppはいずれもこうした新しい量子化形式への対応を継続的に進めています。

よくある質問（FAQ）

関連用語

外部リンク

• llama.cpp - メモリ効率的なLLM推論（GGUF形式・量子化対応）
• Ollama - ローカルLLM管理ツール（自動メモリオフロード対応）
• LM Studio - GUIでモデルロードとメモリ配分を調整できるツール