「VRAMに余裕があるはずなのに、モデルが毎回アンロードされて読み込みのたびに30秒待たされる」
そんな悩みを抱えるLinuxサーバー管理者は多いはずです。Ollamaはデフォルト設定のままでも動作しますが、複数人が使う本番環境では環境変数のチューニングが欠かせません。この記事では、
OLLAMA_NUM_PARALLEL（並列リクエスト数）・OLLAMA_MAX_LOADED_MODELS（VRAM上のモデル保持数）・OLLAMA_KEEP_ALIVE（アンロード制御）の3変数を中心に、Ubuntu Server上でOllamaのスループットを最大化する設定手順を解説します。ollama psとnvidia-smiを使ったリアルタイム監視の方法、よくあるパフォーマンス低下の原因と対処法もあわせてカバーします。
この記事のポイント
・OLLAMA_NUM_PARALLEL・OLLAMA_MAX_LOADED_MODELS・OLLAMA_KEEP_ALIVEの3変数がチューニングの核心
・環境変数はsystemdのoverride.confに記述し、daemon-reload→restartで確実に永続化する
・ollama psでモデルのVRAM使用量とアンロードタイマーをリアルタイム確認できる
・量子化モデル（q4_0 vs q8_0）の選択でVRAM消費を抑えながら並列数と速度を両立できる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
チューニングを始める前に確認すること
パフォーマンスチューニングの前に、まずベースラインを把握する必要があります。環境が整っていない状態でパラメータを変えても、何が効いたのか判断できません。Ollamaの初期セットアップや前提となるUbuntu Server環境の構築については、Ubuntu ServerでローカルLLMを構築する方法で詳しく解説しています。すでに`ollama serve`が動いている状態を前提に、以下の手順で現状を確認します。
1. Ollamaのバージョンを確認する
環境変数の一部は特定バージョン以降でしか効かないものがあります。まずバージョンを確認します。$ ollama --version ollama version is 0.5.4
$ curl -fsSL https://ollama.com/install.sh | sh
2. 現在のモデルの稼働状態を確認する
`ollama ps` コマンドでVRAMにロードされているモデルとアンロードまでの残り時間を確認できます。$ ollama ps NAME ID SIZE PROCESSOR UNTIL llama3.3:70b-instruct-q4_0 abc123def456 43 GiB 100% GPU 4 minutes from now
Ollamaのパフォーマンスを左右する3つの要因
Ollamaのレスポンス速度と安定性は大きく3つの要因で決まります。設定変更の前にこの構造を理解しておくと、パラメータの効果が見えやすくなります。 **① モデルのロード・アンロードのタイミング**デフォルトでは、最後のリクエストから5分が経過するとモデルがVRAMからアンロードされます。次のリクエストが来たとき再ロードが発生し、70Bクラスのモデルでは30秒以上の待機が生じます。チームで使う環境では、このアンロードを抑制するかキープ時間を延長するのが基本対策です。
**② 並列リクエストの上限**
Ollamaは1つのモデルインスタンスで複数のAPIリクエストを同時処理できます。`OLLAMA_NUM_PARALLEL` のデフォルトはGPU環境で4です。チームの同時利用者数がこれを超えると、リクエストがキューで待機し始めます。
**③ VRAM上のモデル保持数**
`OLLAMA_MAX_LOADED_MODELS` のデフォルトはGPU環境で1です。2種類のモデルに交互にリクエストが来る場合、毎回モデルの入れ替えが発生します。VRAMに余裕があれば複数モデルを同時保持することで切り替えコストをゼロにできます。
チューニングで使う主要環境変数の一覧
以下の変数を組み合わせてチューニングします。用途ごとに整理すると、どれをいつ触るかが明確になります。| 環境変数 | デフォルト値 | 役割 |
|---|---|---|
| OLLAMA_NUM_PARALLEL | 4（GPU）/ 1（CPU） | 1モデルあたりの最大同時リクエスト数 |
| OLLAMA_MAX_LOADED_MODELS | 1（GPU）/ 3（CPU） | VRAMに同時保持できる最大モデル数 |
| OLLAMA_KEEP_ALIVE | 5m | 最終リクエストからアンロードまでの待機時間 |
| OLLAMA_NUM_THREAD | 自動検出 | CPU推論時のスレッド数 |
| OLLAMA_GPU_OVERHEAD | 0 | GPU上に確保する予約領域（バイト） |
| OLLAMA_FLASH_ATTENTION | 0 | Flash Attentionを有効化（1=有効） |
| OLLAMA_HOST | 127.0.0.1:11434 | OllamaがリッスンするIPアドレスとポート |
systemdのoverride.confで環境変数を永続化する手順
Ollamaをsystemdサービスとして動かしている場合、環境変数は `/etc/systemd/system/ollama.service.d/override.conf` に記述します。直接 `ollama.service` を編集するとパッケージ更新で上書きされるため、必ずdropinファイルを使います。1. dropinディレクトリを作成する
$ sudo mkdir -p /etc/systemd/system/ollama.service.d
2. override.confを作成・編集する
$ sudo nano /etc/systemd/system/ollama.service.d/override.conf
[Service] Environment="OLLAMA_NUM_PARALLEL=4" Environment="OLLAMA_MAX_LOADED_MODELS=2" Environment="OLLAMA_KEEP_ALIVE=30m"
3. systemdを再読み込みしてOllamaを再起動する
$ sudo systemctl daemon-reload $ sudo systemctl restart ollama $ systemctl status ollama
$ systemctl show ollama | grep -i environment Environment=OLLAMA_NUM_PARALLEL=4 OLLAMA_MAX_LOADED_MODELS=2 OLLAMA_KEEP_ALIVE=30m
並列リクエスト数とVRAM使用量の関係を把握する
`OLLAMA_NUM_PARALLEL` を増やすと、1リクエストあたりのVRAM使用量が増加します。同時処理数に比例してKVキャッシュ（Key-Valueキャッシュ）がVRAMを消費するためです。モデルサイズだけでなく、コンテキスト長（デフォルト2048トークン）とパラレル数の積がVRAMを圧迫します。`llama3.3:70b-instruct-q4_0`（約43 GiB）を並列4で動かす場合、KVキャッシュ分として追加で数 GiB を消費します。80 GiB（例: H100）のVRAMがあれば問題ありませんが、24 GiB（例: RTX 4090）では並列数を2以下に下げないとOOMエラーが発生することがあります。
| VRAMサイズ | モデルの規模 | 推奨OLLAMA_NUM_PARALLEL |
|---|---|---|
| 8 GiB以下 | 7Bクラス（q4_0） | 1～2 |
| 16 GiB | 13B～14Bクラス（q4_0） | 2～4 |
| 24 GiB | 32Bクラス（q4_0）または7B複数 | 2～4 |
| 48 GiB以上 | 70Bクラス（q4_0） | 4以上 |
複数モデルをVRAMに保持してレスポンスを高速化する
`OLLAMA_MAX_LOADED_MODELS=2` に設定すると、2種類のモデルをVRAMに同時保持できます。たとえばコード生成用に `llama3.3:70b-instruct-q4_0`、要約・質問応答用に `gemma3:12b-instruct-q8_0` を使い分けるチームであれば、モデル切り替えのたびに発生する30秒以上の読み込み待ちをなくせます。注意点は **VRAMの合算が物理搭載量を超えないこと** です。2モデルのサイズ合計がVRAM容量を超えると、Ollamaは自動的にモデルをディスクにスワップします。スワップが発生するとかえって速度が落ちるため、必ず `ollama ps` でVRAM使用量の合算を確認しながら設定します。
社内で複数の業務にローカルLLMを展開する場合の判断軸については、機密データを守るローカルLLMという選択肢も参考になります。
OLLAMA_KEEP_ALIVEはシステム全体のデフォルト値を設定しますが、APIリクエスト単位で個別に上書きすることもできます。
# リクエスト単位でkeep_aliveを60分に指定する例 $ curl http://localhost:11434/api/generate -d '{ "model": "llama3.3:70b-instruct-q4_0", "prompt": "Linuxのinodeとは何ですか", "keep_alive": "60m" }'
ollama psとnvidia-smiで稼働状況をリアルタイム監視する
チューニングの効果は実測で確認します。変更前後の数値を記録しておくことで、設定がスループットにどう影響したかを客観的に評価できます。1. ollama psでモデル状態を確認する
`ollama ps` は現在VRAMにロードされているモデルの一覧を表示します。$ ollama ps NAME ID SIZE PROCESSOR UNTIL llama3.3:70b-instruct-q4_0 abc123def456 43 GiB 100% GPU 29 minutes from now gemma3:12b-instruct-q8_0 def789abc012 12 GiB 100% GPU 28 minutes from now
2. nvidia-smiで物理VRAMをリアルタイム確認する
`nvidia-smi` を `watch` と組み合わせることで、VRAMの使用量を2秒ごとに自動更新して監視できます。$ watch -n 2 nvidia-smi --query-gpu=name,memory.used,memory.free,memory.total \ --format=csv,noheader,nounits NVIDIA RTX 4090, 55800, 3192, 24268
3. APIの応答速度（tokens/s）を計測する
実際のトークン生成速度はAPIレスポンスの `eval_rate` フィールドで確認できます。$ curl -s http://localhost:11434/api/generate \ -d '{"model":"llama3.3:70b-instruct-q4_0","prompt":"Hello","stream":false}' \ | python3 -c "import sys,json; d=json.load(sys.stdin); print(round(d.get('eval_rate',0),1), 'tokens/s')" 12.4 tokens/s
よくあるパフォーマンス低下のトラブルと対処法
チューニングを試みても改善しない場合、以下の原因を順番に確認します。1. モデルが毎回ロードされる（KEEP_ALIVEが効いていない）
**症状**: リクエストのたびに数十秒の待機が発生する。**原因**: OLLAMA_KEEP_ALIVEが反映されていないか、override.confの書式が誤っている。
**対処**: `systemctl show ollama | grep -i environment` で変数を確認する。`"` の位置が正しいか再チェックする。daemon-reloadを忘れている場合も多い。
2. OOMでOllamaがクラッシュする
**症状**: Ollamaが突然停止し `journalctl -u ollama -n 50` に `out of memory` または `cudaMalloc failed` が記録される。**原因**: OLLAMA_NUM_PARALLELが高すぎてKVキャッシュがVRAMを圧迫している。
**対処**: OLLAMA_NUM_PARALLELを半分に下げ、より量子化率の高いモデル（`llama3.3:70b-instruct-q4_0`）に切り替えてVRAM消費を減らす。
3. 複数モデルが保持されず毎回切り替わる
**症状**: `ollama ps` に常に1モデルしか表示されない。**原因**: VRAMが足りず自動的に保持数が1に制限されている。または設定が反映されていない。
**対処**: `ollama ps` でSIZEの合算を確認し、`nvidia-smi` の `memory.total` と比較する。合算が物理容量を超えている場合は小さいモデルに変更するか、OLLAMA_MAX_LOADED_MODELSを1に戻す。
4. CPU推論が想定より遅い（GPUなし環境）
**症状**: GPUなし環境でトークン生成速度が1 token/s以下。**原因**: OLLAMA_NUM_THREADが自動検出に任せているが、実際のコア数より少ない値が割り当てられている。
**対処**: `nproc` で論理コア数を確認し、OLLAMA_NUM_THREADに物理コア数を明示設定する。
# 論理コア数を確認する $ nproc 16 # override.confに追記（物理コア数=論理コア数÷2が安定する場合が多い） Environment="OLLAMA_NUM_THREAD=8"
まとめ
Ollamaのパフォーマンスチューニングは、3変数の理解と計測の繰り返しで完結します。設定変更→`ollama ps`確認→`nvidia-smi`監視→tokens/s計測のサイクルを回すことで、自分の環境に合ったパラメータが見つかります。| 環境変数 | チューニングの目的 | 変更例 |
|---|---|---|
| OLLAMA_NUM_PARALLEL | 同時リクエスト処理数を増やす | デフォルト4 → チーム規模に合わせて2～8 |
| OLLAMA_MAX_LOADED_MODELS | 複数モデルをVRAMに保持しモデル切替コストをゼロにする | デフォルト1 → 2（VRAM容量が許す範囲） |
| OLLAMA_KEEP_ALIVE | モデルのアンロードを防いで読み込み待ちをなくす | デフォルト5m → 30m または -1（常時保持） |
| OLLAMA_NUM_THREAD | CPU推論のスレッド数を最適化する | 自動検出 → nproc確認のうえ物理コア数を指定 |
ローカルLLMの本番チューニングを実機で習得する
環境変数の設定や並列処理の調整は、手元のGPUで実際に動かしながら学ぶのが一番の近道です。頭で理解したつもりでも、VRAMが足りなくてOOMが出たときの対処は実機でしか身につきません。実機GPU環境で手を動かしながら習得したい方向けに、「ローカルAIマスターセミナー」を開催しています。
少人数（最大8名）ZOOMハンズオン形式で実施しています。
・Ubuntu ServerでローカルLLMを構築する方法｜Ollamaで機密データを外に出さず業務AIを動かす完全ガイド
・社内でChatGPTが使えないときの代替手段｜機密データを守るローカルLLMという選択肢
・ローカルLLMのモデルを比較する方法｜Llama3.3・Mistral・Gemma・Phi-4をUbuntuで使い分けるポイント
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます