Ollama パフォーマンス最適化の実践：量子化・バッチ処理・メモリ調整の完全ガイド

2026-06-08 更新：Ollama 公式ドキュメントで環境変数を再確認——GPU レイヤー数はモデルパラメータ num_gpu で指定します（OLLAMA_GPU_LAYERS は存在しません）。VRAM の予約は OLLAMA_GPU_OVERHEAD（バイト）、KV Cache 量子化は OLLAMA_KV_CACHE_TYPE。ベンチマークは参考値で、バージョンやハードウェアで変動します。

14B モデルは起動したのに、推論速度はわずか 10 tokens/s しか出ない？　それとも、いきなり OOM エラーで落ちてしまう？　GPU のファンが全力で回り、画面は真っ暗。

よくある場面です。意気込んで llama3 8B をダウンロードし、ollama run と打ち込んだら、VRAM が足りない。エラーで落ちるか、カタツムリのように遅いか。Q4 量子化版に換えると動くようにはなったものの、心の中ではモヤモヤが残ります。「これ、品質はどれくらい落ちたんだろう？」と。

Ollama を使い始めたころ、こうした落とし穴をいくつも踏みました。8GB の VRAM で 14B モデルを動かそうとし、起動さえできればいいと安易に考えていたのです。結果は CUDA out of memory か、一語ずつポツポツと吐き出されるだけ。

問題はハードウェアではありません。設定が足りていないのです。

この記事では、3 つの中心的な最適化技術について話します。量子化の選択、バッチ処理の設定、メモリ調整です。この 3 つを理解すれば、ローカル LLM の性能は少なくとも倍になります。マーケティング的な「倍増」ではなく、実測の tokens/s が本当に上がるという意味の倍増です。

一、量子化技術 — Q4 から FP16 までの品質と速度のトレードオフ

1.1 量子化とは？　なぜ GGUF が主流なのか

まずは分かりやすく言いましょう。量子化とは、モデルを「小さく圧縮する」ことです。

ダウンロードした大規模モデルの元のパラメータは FP16（16 ビット浮動小数点）です。7B モデルを FP16 で計算すると、パラメータだけで 14GB の VRAM を必要とします。では、各パラメータを 16 ビットから 4 ビットに圧縮したらどうなるでしょう？　理論上は 3.5GB まで縮められます。これが量子化の核心となる論理です。より少ないビット数で元の数値を表現し、メモリ使用量の削減と推論速度の向上と引き換えにするのです。

もちろん代償もあります。精度の低下です。4K の写真を 720P に圧縮するようなもので、細部は確実に失われますが、ほとんどの場面では「使える」レベルです。

GGUF 形式が主流になった理由は、ひとことで言えば「手軽さ」です。これは llama.cpp チームが専用に設計した形式で、メモリマッピング（mmap）に対応しています。モデルの読み込み時にすべてをメモリに読み込む必要がなく、必要に応じて読み出します。つまり、16GB メモリのマシンでも 13B モデルを動かせるということです。従来の形式では考えられないことでした。

1.2 量子化タイプの詳細：Q4_0、Q4_K_M、Q5_K_M、Q8_0 の比較

ここが多くの人を悩ませる部分です。Q4_0、Q4_1、Q4_K_M、Q5_K_M、Q8_0……選択肢が山ほどあって、結局どれを選べばいいのか？

よく使う量子化タイプを比較表にまとめました。

量子化タイプ	圧縮率	メモリ使用量（7Bモデル）	品質低下	適した場面
Q4_0	約 4.5x	約 4.0GB	やや大きい	VRAM が極端に厳しく、品質要求が低い
Q4_K_M	約 4.5x	約 4.7GB	とても小さい	コスパ最優先、日常的に推奨
Q5_K_M	約 3.5x	約 5.8GB	極めて小さい	品質優先、VRAM に余裕あり
Q8_0	約 2x	約 7.2GB	ほぼ無損失	最高品質を求め、VRAM が十分大きい
FP16	1x	約 14GB	無損失	学術研究、ハイエンド GPU

シンプルに言えば、Q4_K_M がコスパ最優先です。品質低下はほとんど感じられず、メモリ使用量も最も低い。何度も試しましたが、Q4_K_M と FP16 の回答の違いは、顕微鏡であら探しでもしない限り、日常会話ではまったく感じ取れません。

Q5_K_M は VRAM にまだ余裕があり、品質にこだわりがある場合に向いています。Q8_0 は考えなくていいでしょう。24GB 以上の VRAM があるなら別ですが、その条件があるなら、もっと大きなパラメータのモデルを動かしたほうがいいはずです。

1.3 量子化選択の決定ツリー

シンプルな判断ロジックを示します。

Step 1：VRAM を見る

• VRAM ≤ 8GB：Q4_K_M 一択。7B モデルでギリギリ、14B は CPU オフロードが必要
• VRAM 12〜16GB：Q4_K_M で 14B も問題なし。7B なら Q5_K_M も可
• VRAM ≥ 24GB：自由。Q5_K_M でも Q8_0 でもよく、70B モデルさえ動かせる

Step 2：用途を見る

• 日常会話、コーディング：Q4_K_M で十分
• 翻訳、品質に敏感な文章作成：Q5_K_M
• 学術研究、ベンチマーク比較：Q8_0 または FP16

実際のデータを参考までに。

• 7B モデル Q4_K_M：約 4.7GB の VRAM
• 14B モデル Q4_K_M：約 9GB の VRAM
• 70B モデル Q4_K_M：約 40GB の VRAM

私のおすすめは？　まず Q4_K_M から試すこと。回答の品質に違和感を覚えたら、Q5_K_M に換えればいい。最初から「無損失」を追い求めないことです。多くの場合、それは気のせいなのですから。

1.4 指定した量子化版をダウンロードする方法

Ollama はデフォルトで Q4_K_M 量子化版をダウンロードします。別の版を指定したい場合は？

# デフォルトは Q4_K_M をダウンロード
ollama run llama3

# Q5 量子化を指定
ollama run llama3:70b-q5

# Q8 量子化を指定
ollama run llama3:70b-q8

すべてのモデルにすべての量子化版があるわけではありません。Ollama 公式のモデルライブラリで確認するか、次のコマンドで利用可能なタグを調べられます。

# ローカルにあるモデルを確認
ollama list

# モデルの詳細（量子化情報を含む）を確認
ollama show llama3 --modelfile

ちなみに、ヘビーユーザーなら、自分でモデルを量子化するのも一つの道です。llama.cpp は完全な量子化ツールチェーンを提供しており、精度やパラメータを自分で制御できます。ただしこれは上級者向けの遊び方なので、本記事ではここでは展開しません。

二、バッチ処理の設定 — スループットを 50〜150% 向上させる

2.1 バッチ処理の原理：なぜ速くなるのか？

バッチ処理という概念は、多くの人がよく分かっていません。説明しましょう。

スーパーのレジ会計を想像してください。毎回 1 人の客の商品だけを処理すると、レジ係は頻繁に切り替え・スキャン・会計を繰り返すことになり、効率が悪い。でも、10 人分の商品をまとめてスキャンしたら？　レジ係の動作が連続的になり、効率は自然と上がります。

GPU 推論も同じ理屈です。単一トークンの推論時、GPU はほとんどの時間をメモリ転送の待機に費やしており、計算ユニットは空回りしています。バッチ処理は複数のトークンをまとめて計算することで、GPU をフル稼働させるのです。

注意：バッチ処理が向上させるのはスループットであって、単一リクエストのレイテンシではありません。どういう意味か？　あなた 1 人で使う場合は、体感の差は小さい。しかし API サービスを運用していて、複数のリクエストを同時に処理する場合、スループットは倍、あるいはそれ以上になります。

2.2 num_batch パラメータの詳細

num_batch は Ollama の中心的なバッチ処理パラメータで、デフォルト値は 512 です。

この値が大きいほど GPU 使用率が高まり、スループットが増します。代償として VRAM 使用量が 20〜40% 増加します。

どう調整するか？　VRAM の余裕しだいです。

VRAM の状況	推奨 num_batch	期待される効果
VRAM が厳しい	512（デフォルト）	安全だが、やや遊んでいる可能性あり
VRAM がほどほど	1024	スループット 50〜80% 向上
VRAM が潤沢	2048	スループット 100〜150% 向上

私の経験では、RTX 3080（10GB）で 7B Q4_K_M を動かす場合、num_batch を 1024 に設定すれば安定します。2048 にすると、ときどき OOM が出ます。RTX 4090 で 14B を動かすなら、2048 でも余裕です。

2.3 num_ctx と KV Cache

num_ctx はコンテキストウィンドウのサイズで、デフォルトは 2048 です。このパラメータが影響するのは KV Cache のメモリ使用量です。

KV Cache とは何か？　簡単に言えば、モデルが推論時に過去の計算結果をキャッシュし、重複計算を避ける仕組みです。コンテキストが長いほど、キャッシュも大きくなります。

メモリ使用量の概算式は次のとおりです。

KV Cache メモリ ≈ 2 × レイヤー数 × 隠れ次元 × num_ctx × 精度バイト数

実際の数値を参考までに。

• 7B モデル、num_ctx=4096：追加で約 1〜2GB
• 14B モデル、num_ctx=8192：追加で約 3〜4GB

ですから、長いコンテキスト（たとえば 32K、128K）で動かすと、VRAM 消費がぐんぐん増えます。モデルパラメータが VRAM を埋め尽くしていると思いがちですが、実は KV Cache が大半を食っているのです。

落とし穴：一部のモデルはデフォルトの num_ctx がとても大きい。たとえば llama3 は 128K まで対応しますが、本当にそんなに大きく設定すると VRAM が一発で爆発します。日常使用なら、4096 か 8192 で十分です。

2.4 バッチ処理設定の実践

さっそく設定例を見ましょう。

方法一：Modelfile での設定

# ベースモデルから作成
FROM llama3

# バッチサイズを設定
PARAMETER num_batch 1024

# コンテキストウィンドウを設定
PARAMETER num_ctx 4096

# システムプロンプトを切り詰められないように保持
PARAMETER num_keep 128

Modelfile として保存し、新しいモデルを作成します。

ollama create my-llama3 -f Modelfile
ollama run my-llama3

方法二：API options での設定

curl http://localhost:11434/api/generate -d '{
  "model": "llama3",
  "prompt": "量子コンピュータについて説明して",
  "options": {
    "num_batch": 1024,
    "num_ctx": 4096
  }
}'

パフォーマンス比較データ（RTX 3080、7B Q4_K_M）：

num_batch	スループット（tokens/s）	VRAM 使用量
512	45	5.2GB
1024	72	6.1GB
2048	98	7.4GB

ご覧のとおり、num_batch を 512 から 1024 に上げると、スループットは 60% 増え、VRAM は 1GB 弱しか増えません。十分に割の合う取引です。

三、メモリ調整 — OOM を解決する 3 つの戦略

3.1 GPU メモリの割り当てメカニズム

Ollama の GPU メモリ管理は、実はなかなか賢い。次のように自動判断します。

1. VRAM はモデルを収めるのに足りるか？
2. 足りるなら、すべて GPU に載せる
3. 足りないなら、一部のレイヤーを自動的に CPU へオフロードする

ただし「賢い」は「完璧」を意味しません。ときに判断ミスをしたり、境界ケースの処理がうまくいかなかったりすると、OOM を引き起こします。

中心となるパラメータは num_gpu です。これはモデルの何レイヤーを GPU に載せるかを制御します。デフォルトの -1 は自動判断を意味します。手動で指定することもでき、たとえば num_gpu: 20 なら、先頭の 20 レイヤーだけを GPU に載せ、残りは CPU で処理するという意味です。

3.2 戦略一：量子化のダウングレード

これは最もシンプルで直接的な方法です。OOM が出た？　より小さな量子化に換えましょう。

ダウングレードの経路：

Q8_0 → Q5_K_M → Q4_K_M → Q4_0

1 段階ダウングレードするごとに、おおよそ 20〜25% の VRAM を節約できます。

例を挙げましょう。14B モデル Q5_K_M を動かすのに 11GB の VRAM が必要で、OOM が出たとします。Q4_K_M に換えれば 9GB で済みます。VRAM 使用量は 18% 下がりましたが、品質の低下は？　正直なところ、日常会話ではまず感じ取れません。

私は以前、8GB の VRAM で 7B Q4_K_M を動かしましたが、まったく問題ありませんでした。14B を動かしたい場合は？　Q4_K_M でギリギリですが、コンテキストが大きくなると OOM します。最終的な妥協案は 14B Q4_0 で動かすことで、品質は少し落ちますが、使えました。

3.3 戦略二：CPU オフロードによるハイブリッド推論

VRAM がどうしても足りない？　CPU に一部を分担させましょう。

num_gpu パラメータが GPU のレイヤー数を制御します。たとえば 32 レイヤーのモデルで num_gpu: 24 と設定すると、後ろの 8 レイヤーは CPU で計算されます。

代償は速度低下です。CPU 推論は GPU より 10 倍以上遅い。それでも、いきなり OOM で動かないよりはマシです。

設定方法：

# Modelfile
FROM llama3
PARAMETER num_gpu 24

あるいは API 経由で：

curl http://localhost:11434/api/generate -d '{
  "model": "llama3",
  "prompt": "こんにちは",
  "options": {
    "num_gpu": 24
  }
}'

ハイブリッド推論の速度参考（14B Q4_K_M、RTX 3080 10GB + i7-12700K）：

num_gpu	推論速度	VRAM 使用量
40（全GPU）	OOM	12GB（爆発）
30	18 tokens/s	9.2GB
20	12 tokens/s	6.5GB
0（純CPU）	4 tokens/s	0.5GB

ご覧のとおり、num_gpu=30 のとき、速度はまだ許容範囲で、VRAM も爆発しません。これがハイブリッド推論の価値です。

3.4 戦略三：KV Cache の最適化

KV Cache はしばしば見落とされますが、VRAM の大食らいになり得ます。

方法一：Flash Attention を有効化する

Flash Attention は最適化されたアテンション計算方式で、VRAM 使用量を大幅に削減できます。

# 環境変数を設定
export OLLAMA_FLASH_ATTENTION=1

# または Docker 起動時に
docker run -e OLLAMA_FLASH_ATTENTION=1 ollama/ollama

効果：KV Cache の VRAM 使用量が 30〜50% 減少します。強くおすすめします。

方法二：num_ctx を小さくする

コンテキストが長いほど KV Cache は大きくなります。32K のコンテキストが必要ないなら、小さめに設定しましょう。

PARAMETER num_ctx 2048  # デフォルト 2048、日常会話には十分

方法三：num_keep でシステムプロンプトを保持する

num_keep パラメータは、何トークンを切り詰めずに保持するかを制御します。システムプロンプトの長さに合わせて設定すれば、コンテキストのスライド時にシステムプロンプトが食われるのを防げます。

PARAMETER num_keep 128

3.5 OOM 実践の解決フロー

OOM に遭遇したら、このフローで切り分けましょう。

Step 1：VRAM 使用量を確認

nvidia-smi

VRAM をどれだけ使い、どれだけ残っているかを一目で確認します。

Step 2：モデルのパラメータを確認

ollama show llama3 --modelfile

num_ctx や num_batch などのパラメータが大きすぎないかを確認します。

Step 3：段階的にダウングレード

• まず num_batch を下げる：1024 → 512
• 次に num_ctx を下げる：4096 → 2048
• 最後に量子化を下げる：Q5_K_M → Q4_K_M

Step 4：CPU オフロードを有効化
num_gpu を総レイヤー数の 70〜80% に設定します。

Step 5：最終手段 — 純 CPU 推論
VRAM がどうしても足りなければ、CPU を使うしかありません。遅いことは遅いですが、使えます。

# モデルパラメータ num_gpu=0 で純 CPU を強制（API または Modelfile）
curl http://localhost:11434/api/generate -d '{"model":"llama3","prompt":"こんにちは","options":{"num_gpu":0}}'

正直なところ、純 CPU 推論の速度は GPU のおよそ 1/10 しかありません。しかし、たまに使うだけ、あるいはバッチ処理のタスクを回すだけなら、許容できます。

四、パフォーマンスベンチマークとハードウェア参考

4.1 ハードウェアごとの推論速度表

さまざまなハードウェア構成での推論速度データをまとめました。自分の状況と照らし合わせるのに役立ちます。

NVIDIA GPU（7B モデル Q4_K_M）

GPU 型番	VRAM	tokens/s	備考
RTX 3060	12GB	52	コスパの王者
RTX 3080	10GB	68	安定した選択
RTX 3090	24GB	95	14B Q4 も動く
RTX 4070 Ti	12GB	78	新アーキテクチャの強み
RTX 4090	24GB	120	ハイエンド構成

NVIDIA GPU（14B モデル Q4_K_M）

GPU 型番	VRAM	tokens/s	備考
RTX 3060	12GB	28	ギリギリ動く
RTX 3080	10GB	OOM	CPU オフロードが必要
RTX 3090	24GB	55	快適
RTX 4090	24GB	72	非常に速い

Apple Silicon（Metal アクセラレーション）

デバイス型番	メモリ	7B tokens/s	14B tokens/s
M2 Air 8GB	8GB	35	OOM
M2 Pro 16GB	16GB	48	22
M2 Max 32GB	32GB	58	32
M2 Ultra 64GB	64GB	65	45

Apple Silicon の強みはユニファイドメモリで、VRAM が十分に大きいことです。ただし単一コアの性能はハイエンド GPU に及びません。

純 CPU 推論

CPU 型番	メモリ	7B tokens/s	14B tokens/s
i7-12700K	32GB	6	3
Ryzen 9 7950X	64GB	8	4
M2 Max（CPU only）	32GB	12	6

動きますが、遅い。バッチ処理のタスクには向きますが、リアルタイム会話には向きません。

4.2 バッチ処理によるスループット向上データ

この表は、num_batch の設定がスループットに与える影響を示しています。

テスト環境：RTX 3080、7B Q4_K_M、複数同時リクエスト

num_batch	単一リクエストのレイテンシ	同時実行スループット	VRAM 使用量
512	22ms/token	45 tokens/s	5.2GB
1024	22ms/token	72 tokens/s	6.1GB
2048	22ms/token	98 tokens/s	7.4GB

重要な発見：

• 単一リクエストのレイテンシはほぼ不変：バッチ処理は単一リクエストの応答速度に影響しない
• スループットが倍増：同時実行の場面では、num_batch=2048 は 512 より 118% 向上
• VRAM の代償は制御可能：118% のスループット向上に対し、増えた VRAM はわずか 2.2GB

4.3 環境変数設定のまとめ

Ollama が対応する環境変数のうち、よく使うものをまとめました。

# Flash Attention（強く推奨）
export OLLAMA_FLASH_ATTENTION=1

# KV Cache 量子化：f16(既定)/q8_0(約半分)/q4_0(約4分の1)、要 Flash Attention
export OLLAMA_KV_CACHE_TYPE=q8_0

# システム/他アプリ用に VRAM を予約（バイト、既定 0）
export OLLAMA_GPU_OVERHEAD=1073741824  # 1GB 予約

# モデルの保持時間（デフォルト 5 分）
export OLLAMA_KEEP_ALIVE=24h

# 既定のコンテキスト長（モデル既定を上書き）
export OLLAMA_CONTEXT_LENGTH=4096

# 同時リクエスト数の上限
export OLLAMA_MAX_QUEUE=512

# ログレベル
export OLLAMA_DEBUG=1

Docker Compose の完全な設定例：

version: '3'
services:
  ollama:
    image: ollama/ollama
    container_name: ollama
    restart: unless-stopped
    environment:
      - OLLAMA_FLASH_ATTENTION=1
      - OLLAMA_KEEP_ALIVE=24h
      - OLLAMA_MAX_QUEUE=512
    volumes:
      - ollama_data:/root/.ollama
    ports:
      - "11434:11434"
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]

volumes:
  ollama_data:

上記の設定を docker-compose.yml として保存し、次を実行します。

docker-compose up -d

関連記事

• Ollama GPU アクセラレーション完全設定ガイド
• Ollama ローカル Embedding と RAG 実践
• Llama 70B ローカルモデルのハードウェアガイド

まとめ

ここまで色々と話しましたが、3 ステップの最適化フローをお渡しします。

第一歩：量子化を選ぶ
まず VRAM の大きさを見て、適切な量子化版を選びます。Q4_K_M がコスパ最優先で、ほとんどの場合は十分です。VRAM に余裕があれば Q5_K_M を検討しましょう。

第二歩：バッチ処理を調整する
VRAM に余裕がある？　num_batch を 1024、さらには 2048 まで上げましょう。スループットが倍になり、代償は少しの VRAM だけです。

第三歩：OOM を解決する
まだ足りない？　Flash Attention を有効にし、num_ctx を小さくするか、CPU オフロードを使いましょう。順番に試せば、必ずバランスの取れる点が見つかります。

パフォーマンス最適化は一度で完結するものではありません。ハードウェア、モデルサイズ、利用シーンは人それぞれ違うので、段階的にチューニングする必要があります。私のおすすめは、量子化から始めて、まず動くことを確認し、次にバッチ処理のパラメータを調整し、最後に上級者向けの環境変数に手を付けるという順番です。

そうそう、もし具体的な問題に出くわしたら——あるモデルの設定方法や、あるエラーの解決方法など——コメントするか、Ollama 公式ドキュメントを当たってみてください。コミュニティには実践的な経験の共有がたくさんあり、理論的な解説よりずっと役に立ちます。