GPU Memory

概要

GPU Memory（GPU専用メモリ）は、VRAMとも呼ばれ、ローカルLLM運用において最も重要なハードウェア要素です。モデルサイズ、処理速度、同時実行可能なタスク数を決定する主要な制約要因となります。

容量だけでなく、メモリ帯域幅、レイテンシ、効率的な使用法がAI推論性能に直結します。特にOllama、LM Studio、llama.cppといったローカルLLM実行ツールでは、量子化フォーマット（GGUF形式のQ4_K_MやQ5_K_M等）を選択することでGPUメモリの使用量を大幅に圧縮し、限られたVRAM容量でもより大きなモデルを動かせるようにする工夫が一般的になっています。

「GPUメモリが足りているか」は、単純に「モデルサイズ ≦ VRAM容量」では判断できません。推論時にはモデルの重みに加えて、会話履歴を保持するKVキャッシュ、演算の一時バッファ（アクティベーション）、CUDAコンテキストのオーバーヘッドなどが同時にVRAMを消費するため、実務では余裕を見た容量設計が定石です。

GPUメモリの仕組み

GPUメモリはCPUが使う「システムRAM」とは物理的に独立したメモリで、GPUダイの直近に実装されることで極めて高い帯域幅を実現しています。CPUに内蔵されるメモリコントローラー経由のRAMアクセスと比較して、GPU-VRAM間のアクセスは専用のメモリバス（256bit〜384bit幅など）を介して行われるため、一度に転送できるデータ量が桁違いに大きくなります。

ローカルLLMの推論（テキスト生成）は、一般に「メモリバウンド」な処理だと説明されます。これは、GPUの演算コア（CUDAコア・Tensorコア）の計算能力そのものよりも、モデルの重みパラメータをメモリから読み出す速度がボトルネックになりやすいという意味です。トークンを1つ生成するたびに、モデルの全パラメータ（あるいは活性化しているレイヤー分）を一度メモリから読み出す必要があるため、メモリ帯域幅（GB/s）が直接トークン生成速度（tokens/秒）に影響します。逆に、プロンプト全体をまとめて処理する「プロンプト処理（prefill）」フェーズは行列演算量が多く、比較的コンピュートバウンドになりやすいという違いもあります。

近年は「統合メモリ（Unified Memory）」を採用するアーキテクチャも増えています。Apple SiliconのMシリーズ（M2、M2 Ultra等）は、CPUとGPUが同一の物理メモリプールを共有する設計を採っており、専用VRAMの容量制限を受けずに大容量メモリ（192GB等）を丸ごとLLM推論に使えるのが特長です。一方でこの方式は、GDDR6X/HBMのような専用GPUメモリに比べると帯域幅の面で不利になりやすく、同じモデルでもディスクリートGPUのVRAMより生成速度が遅くなる傾向があります。

GPU別メモリ仕様

代表的なGPUのメモリ容量とメモリ帯域幅の目安は以下の通りです。数値はメーカー公表値に基づく目安であり、製品世代や個体差で変動する場合があります。

AMD GPUはコンシューマ向けではVRAM容量あたりの価格が比較的安い一方、CUDAではなくROCmでの実行が前提となるため、ツールやモデルによっては対応状況の確認が必要です（詳細は関連用語のROCmを参照）。Apple Silicon勢は「専用VRAM」という概念を持たず、統合メモリの容量がそのままLLMに使える上限になる点がディスクリートGPUと大きく異なります。

メモリ容量と LLM 対応

GGUF形式（llama.cpp系ツールで標準的に使われる量子化フォーマット）を基準にした、VRAM容量ごとの実用的なモデルサイズの目安は次の通りです。tokens/秒の値はコミュニティで報告されている代表的な数値からの目安であり、CPU性能、コンテキスト長、同時実行数、ドライバのバージョンなどで大きく変動します。

Ollama・LM Studio・llama.cppはいずれもGGUF形式を第一級でサポートしており、量子化レベルを切り替えるだけでVRAM使用量とモデル品質のバランスを調整できます。Ollamaはモデル取得時に自動的に量子化済みGGUFを取得し、GPUメモリに収まる範囲を自動判定してレイヤーを配置します。LM Studioはモデル一覧画面で各量子化バリエーションごとの推定ファイルサイズ・推定VRAM必要量が表示されるため、非エンジニアでも容量に応じたモデル選択がしやすい設計です。llama.cppは-ngl（--n-gpu-layers）オプションでGPUにオフロードするレイヤー数を手動指定できるため、最も細かい制御が可能です。

具体例・ユースケース

実際の運用でGPUメモリがどう効いてくるか、代表的なケースで見てみます。

ケース1: RTX 4060 Ti 16GB + Ollamaで8Bモデルを常用

Llama 3.1 8BやGemma 2 9B程度のモデルをQ4_K_M量子化で動かす場合、モデル本体は5GB前後に収まり、KVキャッシュや会話履歴分の余裕を含めても16GB VRAMには十分な空きが残ります。コーディング支援チャットや社内向けQ&A用途で、コンテキスト長を8K〜16K程度まで広げても実用速度を維持しやすい構成です。

ケース2: RTX 3090（24GB、中古）+ llama.cppで30B級モデルを検証

中古市場で入手性の良いRTX 3090は24GBのVRAMを持ち、30B前後のモデルをQ4系量子化で動かす検証用途に人気があります。--n-gpu-layersで全レイヤーをGPUにオフロードしきれない場合でも、一部レイヤーをCPU側に残す「部分オフロード」でひとまず動作させ、速度と品質のバランスを見ながら量子化レベルを調整する、という進め方が実務ではよく取られます。

ケース3: MacBook Pro（Apple M2、統合メモリ）+ LM Studioで大型モデルを試す

ディスクリートGPUを持たないMacでも、統合メモリの容量が大きい構成（32GB〜96GB等）であれば、LM Studioを使って13B〜70B級のモデルをGGUF形式で動かせます。専用VRAMの上限に縛られない代わりに、GDDR6XやHBMほどの帯域幅は出ないため、生成速度は同容量のディスクリートGPU構成より控えめになる点は理解した上で選ぶ必要があります。

ケース4: VRAM不足時のCPUオフロード

8GB VRAMのGPUで13B以上のモデルを試したい場合、モデル全体をGPUに載せきれないため一部レイヤーをシステムRAM側で処理する「CPUオフロード」が使われます。この場合、生成速度はVRAM完全収容時より大幅に低下する（数分の1程度になることも珍しくない）ため、まずは量子化レベルを下げる、あるいはモデルサイズを見直す方が実務的な解決になることが多いです。

メモリ使用量計算

基本的な計算式

# メモリ使用量 = パラメータ数 × 精度(bytes) + オーバーヘッド

# Llama 2 7B の例
パラメータ数: 7B
FP32: 7B × 4 bytes = 28GB
FP16: 7B × 2 bytes = 14GB
INT8: 7B × 1 byte = 7GB
INT4: 7B × 0.5 bytes = 3.5GB

# 実際の使用量（オーバーヘッド+20%）
FP16実際: 14GB × 1.2 = 16.8GB
INT8実際: 7GB × 1.2 = 8.4GB

GGUF量子化レベルとビット幅の目安

Ollama・LM Studio・llama.cppで使われるGGUF形式には複数の量子化レベルがあり、1パラメータあたりの平均ビット幅が異なります（Kクオンツ系は層ごとにビット幅を変えるため「平均」の目安です）。

• Q2_K: 平均2〜3bit程度。最軽量だが品質劣化が目立ちやすい
• Q4_0 / Q4_K_M: 平均4〜5bit程度。速度と品質のバランスが良く、最も一般的に使われる
• Q5_K_M: 平均5〜6bit程度。Q4系よりやや高品質でVRAM消費も増加
• Q6_K: 平均6bit程度。FP16に近い品質を保ちつつやや軽量化
• Q8_0: 8bit。量子化による品質劣化が最小限だがファイルサイズは大きい
• F16 / FP16: 16bit。量子化なしの元精度に近い状態

コンテキスト長の影響

• 2K tokens: 基本メモリ使用量
• 4K tokens: +10-15% メモリ増加
• 8K tokens: +20-30% メモリ増加
• 16K tokens: +40-60% メモリ増加

KVキャッシュのサイズはコンテキスト長にほぼ比例して増加するため、長いコンテキストを扱うほどモデル本体以外の消費が無視できなくなります。llama.cppやOllamaではKVキャッシュ自体を量子化（例: q8_0やq4_0でのKVキャッシュ圧縮）する機能もあり、長文コンテキストを扱う際のVRAM節約に有効です。

メモリ最適化技術

量子化によるメモリ削減（Python/transformers）

# bitsandbytesでのINT8量子化
from transformers import BitsAndBytesConfig
import torch

quantization_config = BitsAndBytesConfig(
    load_in_8bit=True,
    llm_int8_threshold=6.0,
    llm_int8_enable_fp32_cpu_offload=False
)

model = AutoModelForCausalLM.from_pretrained(
    "meta-llama/Llama-2-13b-chat-hf",
    quantization_config=quantization_config,
    device_map="auto",
    torch_dtype=torch.float16
)

llama.cpp / Ollamaでのレイヤーオフロード

# llama.cppで全レイヤーをGPUにオフロード
./llama-cli -m model.Q4_K_M.gguf -ngl 999 -c 4096

# 一部レイヤーのみGPUに載せる（VRAMが足りない場合）
./llama-cli -m model.Q4_K_M.gguf -ngl 20 -c 4096

# Ollamaで実行中モデルとメモリ使用状況を確認
ollama ps

Ollamaは内部的にllama.cppと同様のエンジンを使っており、モデルロード時にGPUメモリの空き容量を見てオフロードするレイヤー数を自動調整します。手動で細かく制御したい場合はllama.cppを直接使う方が柔軟性が高く、GUIで手軽に確認・調整したい場合はLM StudioのGPUオフロードスライダーが分かりやすい選択肢です。

その他のメモリ効率化手法

• Gradient Checkpointing: 学習時のメモリ使用量削減（推論では通常不要）
• Model Parallel / Tensor Parallel: 複数GPUへのモデル分散配置
• CPU Offload: 一部処理をシステムRAM・CPU側に逃がす
• Flash Attention: メモリ効率的なアテンション計算
• KVキャッシュ量子化: 長いコンテキストでのVRAM消費を抑制
• mmap（メモリマップ）ロード: llama.cppがモデルファイルをOSのページキャッシュ経由で扱い、初回ロードを高速化

メリット・デメリット（注意点）

メリット

• 圧倒的な速度: システムRAM＋CPU推論と比べ、VRAMに収まったモデルはメモリ帯域幅の差からトークン生成速度が大きく向上する
• 低レイテンシ: GPU-VRAM間のアクセスは低遅延で、対話的なチャット用途に向く
• 量子化との組み合わせで柔軟: GGUF量子化を使えば、限られたVRAMでも工夫次第でより大きなモデルを動かせる

デメリット・注意点

• コスト: 大容量VRAM搭載GPU（24GB以上）は価格が高く、投資回収を考える必要がある
• 拡張性の乏しさ: システムRAMと異なり、GPUメモリは基本的に後から増設できない（購入時の容量が上限）
• 消費電力・発熱: 高VRAM・高帯域幅なGPUほど消費電力が大きくなりやすく、常時稼働では電気代・排熱対策も考慮点になる
• 量子化による品質劣化: VRAM節約のために量子化レベルを下げすぎると、応答品質（特に複雑な推論や長文生成）が目に見えて低下する場合がある
• 「見た目の空き容量」に惑わされる: OS上の表示だけでなく、他のアプリ（ブラウザのGPUアクセラレーション等）がVRAMを消費している場合があり、実際に使える容量はカタログ値より少ないことが多い

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

GPUメモリ（VRAM） vs システムRAM

システムRAM（DDR4/DDR5等）はCPUが主に使う汎用メモリで、GPUメモリよりも大容量・低価格ですが帯域幅は大きく劣ります。LLM推論でシステムRAMのみに頼ると（例: GPUオフロードなしのCPU推論）、同じモデルでもVRAM完全収容時より生成速度が大幅に遅くなるのが一般的です。

VRAM vs 統合メモリ（Unified Memory）

Apple Siliconに代表される統合メモリは、CPUとGPUが1つの物理メモリを共有する設計です。「専用VRAM」という区分自体が存在せず、システム全体のメモリ容量がそのままGPU処理にも使えます。大容量モデルを動かせる反面、専用GDDR/HBMほどの帯域幅は出にくく、速度面ではトレードオフがあります。

GPUメモリ容量 vs メモリ帯域幅

「容量が大きい＝速い」ではありません。容量は「そのモデルが載るかどうか」を決め、帯域幅は「載った後にどれだけ速く生成できるか」を決めます。例えばVRAM容量は同じ24GBでも、GDDR6X搭載GPUとHBM搭載GPUでは帯域幅が数倍異なり、生成速度に明確な差が出ます。

マルチGPU構成での「合計VRAM」の誤解

24GB GPUを2枚搭載しても、単純に「48GBの1枚のGPU」として扱えるわけではありません。モデルを複数GPUに分散配置（Tensor ParallelやPipeline Parallel）するには対応したフレームワーク・設定が必要で、何も設定しなければ1枚分のVRAMしか使われません。llama.cppやOllamaでも複数GPUへの分割読み込みは可能ですが、GPU間の通信オーバーヘッドにより単純な容量の合算ほど性能が伸びない点は理解しておく必要があります。

共有GPUメモリ（Shared GPU Memory）との違い

WindowsのタスクマネージャーなどでVRAM容量を超えて表示される「共有GPUメモリ」は、システムRAMの一部をGPU用に予約したフォールバック領域です。実体はVRAMより大幅に遅いシステムRAM経由のアクセスになるため、LLM推論でこの領域に食い込むと生成速度が顕著に低下します。表示上の「合計GPUメモリ」を鵜呑みにしてモデルサイズを選ぶと、実運用で速度が出ないという事態になりがちです。

メモリ監視とデバッグ

NVIDIA GPU メモリ監視

# コマンドライン監視
nvidia-smi
watch -n 1 nvidia-smi  # 1秒間隔更新
nvtop                  # よりインタラクティブなGPU監視TUI

# Ollamaで実行中モデルとメモリ使用状況を確認
ollama ps

# Python内での監視
import torch

def print_gpu_memory():
    if torch.cuda.is_available():
        for i in range(torch.cuda.device_count()):
            print(f"GPU {i}:")
            print(f"  Allocated: {torch.cuda.memory_allocated(i) / 1024**3:.2f} GB")
            print(f"  Cached: {torch.cuda.memory_reserved(i) / 1024**3:.2f} GB")
            print(f"  Max allocated: {torch.cuda.max_memory_allocated(i) / 1024**3:.2f} GB")

print_gpu_memory()

メモリ不足対策

• 量子化レベルを下げる: Q5→Q4→Q2のように段階的にビット幅を下げてVRAM消費を圧縮
• GPUオフロードのレイヤー数を減らす: llama.cppの-ngl値を下げ、一部をCPU側に逃がす
• コンテキスト長を制限: 必要以上に長いコンテキスト設定を避ける
• バッチサイズ・同時実行数を削減: 複数リクエストを同時に処理させない
• 他プロセスのVRAM消費を確認: ブラウザやゲーム、他の推論プロセスが常駐していないかnvidia-smiで確認

用途別推奨構成

個人・学習用途

プロフェッショナル用途

実務では「まずOllamaで動かしてみて量子化レベルと速度のバランスを確認し、本番運用に耐える構成が見えたらllama.cppで細かくチューニングする」という段階的な進め方が定石です。GUIでの手軽さを求めるならLM Studio、自動化・API連携を重視するならOllama、最大限の制御と性能を求めるならllama.cppを直接使う、と役割分担して使い分けるのが実務的です。

2025-2026年の最新動向

GDDR7の登場でRTX 50シリーズが36Gbps以上の帯域幅を実現しており、メモリバウンドなLLM推論の速度向上に寄与しています。

HBM3eの搭載がデータセンター向けGPU（H200、B200等）で進み、5TB/s以上の帯域幅により超大規模モデルの推論が高速化されています。

大容量化と統合メモリの進化: コンシューマ向けGPUでも24GB超のモデルが増え、Apple Silicon系の統合メモリも大容量化が続いています。長期的には、ローカルLLM用途では「24GBが実用的な上限」という従来の常識が緩やかに変わりつつあり、32〜48GB級の構成がミドルレンジでも選択肢に入りつつあります。

量子化技術の進歩もGPUメモリの実効容量を押し上げています。GGUFのKクオンツ系（Q4_K_M等）やAWQ、GPTQといった量子化手法の改良により、同じVRAM容量でもより高品質なモデルを動かせるようになってきています。GPUを選ぶ際は、現在のカタログスペックだけでなく「量子化技術の進化でどこまで実効容量を伸ばせるか」という視点も踏まえ、長期的に使える容量に余裕を持たせる選び方が無難です。

よくある質問（FAQ）

関連用語

外部リンク

• NVIDIA GeForce公式
• JEDEC - メモリ規格団体
• llama.cpp（GitHub）
• Ollama 公式サイト
• LM Studio 公式サイト