Ollamaのモデルをベンチマークする方法｜応答速度・トークン/秒・VRAM使用量を実測してLinuxサーバーの最適構成を判断する手順

この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）

ＨＯＭＥ＞ Linux技術リナックスマスター.JP（Linuxマスター.JP）＞ローカルLLM ＞ Ollamaのモデルをベンチマークする方法｜応答速度・トークン/秒・VRAM使用量を実測してLinuxサーバーの最適構成を判断する手順

「Ollamaでモデルをいくつか入れてみたが、どれが速いのか感覚でしか判断できていない」
「VRAM不足でプロセスが落ちることがあるが、どのモデルが何GBを消費しているのか数字で把握できていない」

そんな状況に直面しているLinuxサーバー管理者は多いはずです。この記事では、Ollamaの `/api/generate` が返すレスポンスフィールドと `nvidia-smi` コマンドを組み合わせて、応答速度・トークン/秒・VRAM消費量を実測する手順を解説します。さらに複数モデルをシェルスクリプトで一括ベンチマークしてCSV保存する方法まで、本番サーバーでモデルを根拠を持って選定できる状態にするのが目標です。

この記事のポイント

・Ollama APIの `/api/generate` レスポンスに含まれる `eval_count` と `eval_duration` を使えば外部ツール不要でtokens/secを算出できる
・`nvidia-smi dmon` をバックグラウンドで走らせながらAPIを叩くことでモデル別のVRAM消費量を記録できる
・シェルスクリプトでモデルを順番に切り替えてCSVに保存し比較判断に使う一連の手順を示す
・初回実行はVRAMロード時間が混入するため、ウォームアップ後の値を使うのがベンチマークの鉄則

Ollamaのモデルをベンチマークする方法｜応答速度・トークン/秒・VRAM使用量を実測してLinuxサーバーの最適構成を判断する手順

「このままじゃマズい」と感じていませんか？

参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。

姓・名・メールの3つだけ／30秒／解除は3秒／詳細はこちら

ベンチマークが必要な理由と計測する3つの軸

Ollamaはモデルを手軽に切り替えられる反面、感覚論でモデル選定が終わりがちだ。チームサーバーに展開する前に、数字で判断できる状態を作っておく必要がある。

計測する軸は3つに絞ると整理しやすい。

・**応答速度（tokens/sec）**: 1秒あたりに生成できるトークン数。体感スループットに直結する最重要指標。
・**VRAM・RAM消費量**: 複数モデルを同時起動するときのキャパシティ計画に不可欠。VRAMが足りなければCPUオフロードが発生して速度が大幅に低下する。
・**プロンプト処理時間（prompt eval duration）**: 長い入力を与えたときの前処理時間。RAGで長いドキュメントを渡す用途では生成速度と同様に重要になる。

これら3軸をモデルごとに揃えれば、「Llama3.3:70b-instruct-q4_0 と Phi-4:14b-q8_0 のどちらを社内APIに採用するか」という判断を根拠付きで行える。

Ubuntu ServerでローカルLLMを構築する方法｜Ollamaで機密データを外に出さず業務AIを動かす完全ガイドでOllamaが動いている前提で話を進める。まだ構築が済んでいない場合はそちらを先に確認してほしい。

事前準備｜計測に使うツールとOllamaの動作確認

ベンチマークに必要なツールはどれも標準的なLinux環境で即入手できるものばかりだ。

・`curl`: Ollama REST APIとの通信
・`jq`: JSONレスポンスのパース
・`nvidia-smi`: NVIDIA GPU搭載サーバーでのGPU/VRAM計測
・`free`: CPU専用サーバーでのRAM使用量確認
・`bc`: シェル内での浮動小数点計算

まずOllamaが起動済みかどうかを確認する。

ollama list

モデル一覧が返れば正常だ。次にcurlでAPIが応答するかを確認する。

# curlでOllama APIの疎通確認 $ curl http://localhost:11434/api/tags | jq '.models[].name' "llama3.3:70b-instruct-q4_0" "phi4:14b-q8_0" "mistral:7b-instruct-q4_0"

モデル名が出力されれば計測の準備は完了だ。`jq` が入っていない場合は `sudo apt install jq` でインストールする。

1. Ollama APIのレスポンスからtokens/secを算出する

`/api/generate` エンドポイントは `"stream": false` を指定すると、最後に統計フィールドを含む単一のJSONを返す。

計測に使う主なフィールドは以下の4つだ。

・`eval_count`: 生成したトークン数
・`eval_duration`: 生成にかかったナノ秒数
・`prompt_eval_count`: プロンプトのトークン数
・`prompt_eval_duration`: プロンプト処理にかかったナノ秒数

tokens/sec は `eval_count ÷ (eval_duration ÷ 1,000,000,000)` で求められる。以下のコマンドで1回のベンチマークを実行してみる。

# Llama3.3:70bのtokens/secを算出する（ウォームアップ後2回目）
$ RESULT=$(curl -s http://localhost:11434/api/generate \
  -d '{
    "model": "llama3.3:70b-instruct-q4_0",
    "prompt": "Linuxのプロセス管理について200字程度で説明してください",
    "stream": false
  }')
$ EVAL_COUNT=$(echo "$RESULT" | jq '.eval_count')
$ EVAL_DURATION=$(echo "$RESULT" | jq '.eval_duration')
$ echo "scale=2; $EVAL_COUNT / ($EVAL_DURATION / 1000000000)" | bc
12.43

数値は環境によって大きく変わる。CPU専用で2～5、GPU搭載で20～80 tokens/sec が目安だ。

**最初の1回はモデルがVRAMにロードされる時間が `eval_duration` に混入**して実際の生成速度より大幅に遅い数値が出る。必ず2回以上実行してウォームアップ後の値を使うこと。

2. nvidia-smiでVRAMをリアルタイム記録する

GPUが搭載されているサーバーでは `nvidia-smi dmon` を使ってVRAM消費量をモデル別に記録する。

**ステップ1**: `nvidia-smi dmon` をバックグラウンドで起動する

# 1秒間隔でSM使用率とVRAMをログに記録する $ nvidia-smi dmon -s mu -d 1 > /tmp/gpu_bench.log & GPU_MON_PID=$! echo "nvidia-smi dmon started: PID $GPU_MON_PID"

**ステップ2**: Ollamaのベンチマークコマンドを実行する（前の節のcurlコマンドを実行）

**ステップ3**: 計測が終わったら `dmon` を停止してログを確認する

# バックグラウンドのnvidia-smi dmonを停止してVRAMを確認する $ kill $GPU_MON_PID $ head -5 /tmp/gpu_bench.log # gpu sm mem enc dec jpg ofa fb bar1 # 0 72 65 0 0 0 0 38219 234 # 0 81 70 0 0 0 0 39145 234

`fb` 列がフレームバッファ（VRAM使用量のMiB）を示す。計測中の最大値をモデルごとに記録しておく。CPUのみのサーバーは `free -h` を数秒おきに複数回実行して最大RAM使用量を記録する。

3. 複数モデルを一括ベンチマークするシェルスクリプト

手動で1モデルずつ計測するのは手間がかかるうえ、環境条件が変わって比較の公平性が崩れる。以下のスクリプトはモデルリストを順番にベンチマークし、結果をCSVに保存する。

#!/bin/bash
# benchmark_models.sh — Ollamaモデル一括ベンチマーク
PROMPT="Linuxのプロセス管理について200字程度で説明してください"
MODELS=(
  "llama3.3:70b-instruct-q4_0"
  "phi4:14b-q8_0"
  "mistral:7b-instruct-q4_0"
)
OUTPUT="/tmp/ollama_bench.csv"
echo "model,eval_count,eval_sec,tokens_per_sec,prompt_tokens,prompt_sec" > "$OUTPUT"

for MODEL in "${MODELS[@]}"; do
  echo "=== $MODEL ウォームアップ中 ==="
  curl -s http://localhost:11434/api/generate \
    -d "{\"model\": \"$MODEL\", \"prompt\": \"test\", \"stream\": false}" > /dev/null

  RESULT=$(curl -s http://localhost:11434/api/generate \
    -d "{\"model\": \"$MODEL\", \"prompt\": \"$PROMPT\", \"stream\": false}")

  EC=$(echo "$RESULT" | jq '.eval_count')
  ED=$(echo "$RESULT" | jq '.eval_duration')
  PC=$(echo "$RESULT" | jq '.prompt_eval_count')
  PD=$(echo "$RESULT" | jq '.prompt_eval_duration')
  EVAL_SEC=$(echo "scale=4; $ED / 1000000000" | bc)
  TPS=$(echo "scale=2; $EC / $EVAL_SEC" | bc)
  PROMPT_SEC=$(echo "scale=4; $PD / 1000000000" | bc)

  echo "$MODEL,$EC,$EVAL_SEC,$TPS,$PC,$PROMPT_SEC" | tee -a "$OUTPUT"
done
echo "結果を $OUTPUT に保存しました"

スクリプトを保存して実行する。

# スクリプトを実行してCSVを確認する $ chmod +x benchmark_models.sh && ./benchmark_models.sh $ cat /tmp/ollama_bench.csv model,eval_count,eval_sec,tokens_per_sec,prompt_tokens,prompt_sec llama3.3:70b-instruct-q4_0,278,22.36,12.43,32,3.21 phi4:14b-q8_0,312,9.84,31.70,32,0.98 mistral:7b-instruct-q4_0,289,6.12,47.22,32,0.57

ローカルLLMのモデルを比較する方法｜Llama3.3・Mistral・Gemma・Phi-4をUbuntuで使い分けるポイントでは各モデルの用途特性を詳しく解説している。ベンチマーク数値と合わせて参照すると判断材料が一気に揃う。

4. ベンチマーク結果の読み方と本番モデル選定の判断フロー

実測値が揃ったら、用途に応じて以下のフローで判断する。

**速度重視の用途（チャットbot・コード補完・Slack連携）**:
tokens/sec が高いモデルを優先する。Mistral:7b-instruct系はCPU専用サーバーでも実用的な速度を出せる。Llama3.3:70b-instructは品質は高いがGPUなしでは遅すぎて実用にならないケースが多い。

**品質重視の用途（文書要約・多段階推論・RAG）**:
tokens/sec よりも出力の正確さと文脈追従性を優先する。Llama3.3:70b-instruct-q4_0 か Phi-4:14b-q8_0 を候補に入れる。社内でChatGPTが使えないときの代替手段｜機密データを守るローカルLLMという選択肢でも触れているが、機密データを扱う用途では品質と速度のトレードオフを社内で合意した上で選定する。

**VRAMが限られる場合**:
`nvidia-smi` のVRAM使用量が搭載量の90%を超えているにもかかわらず tokens/sec が著しく低い場合、CPUオフロードが発生している可能性が高い。モデルを下げるか量子化レベルを変えて再計測する。

よくあるベンチマークのトラブルと対処法

**初回実行の値をそのまま採用する**:
Ollamaは初回アクセス時にモデルをVRAMにロードする。このロード時間が `eval_duration` に含まれて実際の生成速度より遅い数値が出る。必ずウォームアップ1回を捨て、2回目以降の値を使うこと。

**プロンプト長を変えて比較する**:
`prompt_eval_duration` は入力トークン数に比例して増加する。モデル間を比較するときはプロンプトを固定しないと不公平な比較になる。

**他のリクエストが並走している**:
別のプロセスがOllamaにリクエストを送っていると compute が分散してスコアが落ちる。計測中は他のOllamaリクエストを止めるか、単体テスト用の環境を分けて用意する。

**Ollamaのkeepaliveでモデルがアンロードされる**:
デフォルトでは5分間アクセスのないモデルはVRAMからアンロードされる。連続ベンチマークの間隔が長いと再ロードが発生して初回同様に遅い数値が出る。スクリプト内でモデルを切り替えるときは間隔を短くするか `OLLAMA_KEEP_ALIVE` 環境変数を調整する。

まとめ

Ollamaの `/api/generate` レスポンスに含まれるフィールドと `nvidia-smi` を組み合わせれば、外部の専用ベンチマークツールなしに本番に即した計測ができる。手順をまとめると以下のとおりだ。

ステップ	コマンド・ファイル	取得できる値
1. 疎通確認	curl http://localhost:11434/api/tags \| jq	起動済みモデル一覧
2. 単体計測	/api/generate (stream:false) + bc	tokens/sec・prompt処理時間
3. GPU記録	nvidia-smi dmon -s mu -d 1	VRAM最大使用量(MiB)
4. 一括ベンチ	benchmark_models.sh	モデル別CSV

速度・VRAM・品質の3軸で実測してからモデルを決める習慣を作ると、VRAMが足りずに本番が深夜に落ちるような事態を防げる。感覚論から脱して、数字でサーバー構成を選定してほしい。

ローカルLLMのベンチマークと本番選定を2日間のハンズオンで体験する

モデル選定・パフォーマンス計測・チームサーバーへの展開まで、実機GPU環境で手を動かしながら習得したい方向けに、「ローカルAIマスターセミナー」を開催しています。
少人数（最大8名）ZOOMハンズオン形式で実施しています。

＞＞ローカルAIマスターセミナーの詳細を確認する

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ／30秒／解除は3秒／詳細はこちら

Linux無料マニュアル（図解60P）名前とメールで30秒登録

この記事を書いた人

宮崎智広（みやざきともひろ）

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。

前のページへ：Ollamaとn8nを連携させる方法｜ローカルLLMでメール・Slack・CSVの業務フローを自動化する手順
この記事の属するカテゴリ：ローカルLLMへ戻る