ローカル環境でLLMを動かすとき、一番気になるのがGPUメモリ（VRAM）の消費量です。最新の7Bモデルでも量子化なし（FP16）では16GB以上のVRAMが必要で、RTX 3060やRTX 4060では到底動きません。しかし量子化（Quantization）を使えば、同じモデルを半分のVRAMで動かしつつ、品質はほとんど維持できます。
本記事では、GGUF / GPTQ / AWQといった主要な量子化フォーマットの違いを整理し、RunPod上のRTX 4090で実際にベンチマークを撮影してQ4_K_M vs Q8_0 vs FP16で速度がどう変わるかを検証しました。手元のGPUでLLMを快適に動かすためのガイドとしてご活用ください。
GPUサーバーを借りてLLMを実験したい方は、GPUクラウドサービスのRunPodが便利です。本記事のベンチマークもRunPodのRTX 4090環境で取得しました。
🚀 RunPod — GPUクラウドを時間単位で借りる
- RTX 4090 / A100 / H100などの最新GPUをオンデマンドで利用可能
- 1時間$0.69〜（RTX 4090の場合）。使った分だけの按分課金
- Dockerイメージを指定するだけでLLM環境が即座に起動
量子化（Quantization）とは何か
量子化とは、モデルの重み（ウェイト）の精度を意図的に落とす圧縮手法です。通常、LLMの重みはFP16（16bit浮動小数点）で保存されていますが、これを4bitや8bitの整数に丸めることで、ファイルサイズとメモリ使用量を大きく減らせます。
代表的なGGUF量子化フォーマットを上表にまとめました。Q4_K_Mは4.7bit相当の圧縮で、品質は★★★★☆と高く、ファイルサイズはQ8の約60%に抑えられます。初心者が最初に選ぶべきフォーマットです。
💡 Q4_K_Mが推奨される理由
Q4_K_Mの”K”はK-quants（llama.cppの開発チームが作った量子化手法）を意味し、旧形式のQ4_0よりも品質が高いのが特徴です。重みの重要性に応じてビット配分を動的に変えるため、単純に4bitに丸めるよりも品質劣化が少なくなります。
VRAM要件 — モデルサイズ × フォーマット別
ローカルでLLMを動かす前に、自分のGPUで動くかどうかを確認する必要があります。下表はモデルサイズと量子化フォーマットの組み合わせ別に、必要なVRAMを概算したものです。
計算式は VRAM ≒ パラメータ数 × ビット/ウェイト × 1.2（オーバーヘッド）÷ 8 です。オーバーヘッドの1.2はKVキャッシュや推論時のテンポラリバッファを含めた係数です。
⚠️ 実際のVRAM消費量は目安より多い
表の値はモデル本体のVRAMです。実際にはコンテキスト長が長くなるほどKVキャッシュが増え、追加で数百MB〜数GBを消費します。安全マージンとして+1〜2GB見ておくのがおすすめです。
| 手持ちのGPU | 動くフォーマット |
|---|---|
| RTX 3060 (12GB) | 7BまでQ4_K_M / 3BまでQ8_0 |
| RTX 4060 Ti (16GB) | 13BまでQ4_K_M / 7BまでQ8_0 |
| RTX 4090 (24GB) | 13BまでQ8_0 / 30BまでQ4_K_M |
| RTX 3090 (24GB) | RTX 4090と同等（メモリクロック差で速度は劣る） |
量子化フォーマットの選択ガイド
どの量子化フォーマットを選ぶべきかは、あなたの環境と目的で決まります。
フォーマット選択の目安
- Q4_K_M: 最もバランスが良い。品質はFP16とほぼ同等で、VRAMは半分以下。日常利用・チャット用途に最適
- Q5_K_M: Q4より少し品質が高い。VRAMに余裕がある場合の次のステップ
- Q8_0: ほぼ無劣化。速度より正確さを優先したい評価・研究用途向け
- F16: 無圧縮。データセンターGPU（A100/H100）がない限り選択しない
RunPod RTX 4090での実測ベンチマーク
ここからは実測データにもとづく検証です。RunPodでRTX 4090を借り、Ollama 0.30.8を使って3つの量子化フォーマットで同一モデルをベンチマークしました。
検証環境
$ nvidia-smi –query-gpu=name,memory.total –format=csv
name, memory.total
NVIDIA GeForce RTX 4090, 24564 MiB
# CPU / メモリ情報
$ uname -r
6.8.0-83-generic
$ nproc
16
$ free -h | head -2
total used free
Mem: 58Gi 2.1Gi 55Gi
# Ollamaバージョン
$ ollama –version
ollama version is 0.30.8
検証に使ったのはqwen2.5:3b-instructモデルです。3B（30億パラメータ）サイズのLLMで、Q4_K_Mでは約2GB、Q8_0では約3.3GB、FP16では約6GBのファイルサイズになります。
ベンチマーク結果: トークン生成速度
各モデルを128トークン生成させた際の速度（tok/s）は下表の通りです。
$ curl http://localhost:11434/api/generate -d ‘{
“model”: “qwen2.5:3b-instruct:q4_K_M”,
“prompt”: “Explain quantum computing in simple terms.”,
“stream”: false,
“options”: {“num_predict”: 128}
}’
# 結果から速度を抽出
# eval_count=128, eval_duration=0.487s → tok/s = 128/0.487 = 262.68
💡 結果の読み方
- Q4_K_M = 262.68 tok/s: 最も高速。一般的なチャット用途では十分すぎる速度です
- Q8_0 = 182.99 tok/s: Q4比で約30%の速度低下。品質と速度のバランス型
- F16 = 123.53 tok/s: Q4比で約53%の速度低下。VRAMも2倍消費するため、通常は非推奨
注目すべきは、量子化を強くするほど速度が上がるという点です。これはVRAMの使用量が少ないほどメモリ帯域幅のボトルネックが緩和されるためです。LLMの推論速度は一般的にVRAM帯域幅に依存するため、ファイルが小さい＝読み込みが速い＝高速に推論できる、という関係が成り立ちます。
モデルサイズ別のVRAM要件と推奨GPU
Q4_K_Mで統一した場合、モデルサイズが増えるにつれてVRAM要件は次のように増加します。
1B〜3Bモデルは6GB以下のGPUで十分動作します。7B〜8Bクラスでは4.6〜5.3GBのVRAMが必要です。RTX 3060（12GB）クラスがあれば、7BモデルでもQ4_K_Mで快適に動かせます。
⚠️ 70Bモデルの現実
70BモデルをQ4_K_Mで動かすには約46GBのVRAMが必要です。これは1枚のRTX 4090（24GB）では収まりません。複数GPUのテンソル並列分割、またはGGMLのCPUオフロード（速度は2〜5 tok/s程度に低下）が必要です。70Bを手軽に使う場合はRunPodのA100（80GB）を検討しましょう。
主要フォーマット比較: GGUF vs GPTQ vs AWQ
量子化フォーマットはGGUFだけではありません。ここでは代表的な3つのフォーマットを比較します。
| 項目 | GGUF | GPTQ | AWQ |
|---|---|---|---|
| 開発元 | llama.cppコミュニティ | AutoGPTQプロジェクト | MIT Han Lab |
| 主な量子化bit | 2〜8bit（Q4_K_Mが人気） | 4bit固定が主流 | 4bit（W4A16） |
| 実行エンジン | llama.cpp / Ollama / LM Studio | vLLM / Text-Generation-Inference | vLLM / AutoAWQ |
| CPU推論 | ✅ 対応 | ❌ 非対応 | ❌ 非対応 |
| GPU推論速度 | 中程度 | 高速 | 最速クラス |
| 対応ハード | CPU / NVIDIA / AMD / Apple M | NVIDIA GPU限定 | NVIDIA GPU限定 |
| おすすめ環境 | ローカルPC / MacBook | GPUサーバー | GPUサーバー |
💡 どれを使うべきか
- ローカルPC・MacBookで動かしたい: GGUF + Ollama / LM Studioの一択です。CPU推論にも対応しており、GPUがなくても動かせます
- GPUサーバー（RunPod等）で大量推論: AWQ or GPTQ + vLLMがスループットで有利です
$ curl -fsSL https://ollama.com/install.sh | sh
Installation completed successfully.
# 2. モデルのプル（Q4_K_Mを明示指定）
$ ollama pull qwen2.5:3b-instruct-q4_K_M
pulling manifest… success
[OK] got 2.0GB model
# 3. 対話的にチャットを開始
$ ollama run qwen2.5:3b-instruct-q4_K_M
>>> 日本の首都はどこですか？
日本の首都は東京です。
量子化時の注意点
量子化は便利な反面、いくつか注意点もあります。
- 品質劣化の許容範囲: Q4_K_Mでは数学的推論や複雑なコード生成で精度が1〜5%程度低下する場合があります。日常的な質問応答ではほとんど差が分かりません
- バージョン依存: Ollamaやllama.cppのバージョンによって、同じQ4_K_Mでも量子化アルゴリズムが進化することがあります。最新バージョンを使うのがおすすめです
- モデル変換の手間: GGUF以外のフォーマット（GPTQ、AWQ）はGPU環境でのみ動作するため、事前に変換済みのモデルを使うのが現実的です
⚠️ Ollamaのバージョン確認を忘れずに
Ollamaは頻繁にアップデートされ、量子化のサポートも改善されています。本記事の検証時点ではOllama 0.30.8を使用しています。最新バージョンでは量子化フォーマットの選択肢が増えている可能性があるため、ollama –versionでバージョンを確認してから作業を始めてください。
まとめ
本記事の内容をまとめます。
| ポイント | 内容 |
|---|---|
| 推奨フォーマット | Q4_K_M（品質★★★★☆ / ファイルサイズ最小クラス / 速度最速） |
| VRAM目安（3Bモデル） | Q4_K_M: 約2GB / Q8_0: 約3.3GB / F16: 約6GB |
| ベンチ結果（RTX 4090） | Q4_K_M: 262.68 tok/s / Q8_0: 182.99 tok/s / F16: 123.53 tok/s |
| ローカル環境向け | GGUF + Ollama / LM Studio |
| GPUクラウド用途 | AWQ / GPTQ + vLLM |
量子化を正しく理解すれば、高価なGPUを買わなくても、自分の手持ちのPCで最新のLLMを快適に使えます。まずはQ4_K_Mから始めるのが、コスト対効果の最も高い選択肢です。
自分のPCのGPUでLLMを動かすには、まずLinux環境の整備が必要です。UbuntuのセットアップについてはUbuntu Serverの初期設定ガイドを、Docker環境の構築はUbuntuへのDockerインストールを参照してください。
🖥️ GPUクラウドで気軽にLLMを試す
手元にGPUがない場合も、RunPodなら時間単位でRTX 4090やA100を借りられます。量子化の検証やファインチューニングの実験に便利です。
コメント