Ollamaが遅い時の確認順｜WindowsでCPU・GPU・context・tokens/sを切り分ける

30秒で結論：load・prompt eval・generationを分ける

Ollamaが遅い時は、返答開始前の待ち時間と、文字が出始めた後の生成速度を別に測ります。Ollama APIのusage fieldsには、total_duration、load_duration、prompt_eval_count、prompt_eval_duration、eval_count、eval_durationがあり、時間値はナノ秒で返されます。

• [公式] Ollama API Usage - total_duration、load_duration、prompt_eval_duration、eval_durationなどを確認します。
• [公式] Ollama Generate API - done、done_reason、使用量フィールド、ストリーミング最終チャンクを確認します。
• [公式] Ollama Chat API - チャットAPIの応答フィールドとストリーミング時の記録項目を確認します。

ollama psでPROCESSORとcontextを見る

公式FAQでは、ollama psのPROCESSORで100% GPU、100% CPU、CPU/GPUの一部処理を確認する方法が案内されています。GPU使用率の一瞬のグラフだけでなく、モデルがどこへロードされたか、contextが何になっているかを合わせて記録します。

ollama ps

• Ollama公式FAQ - PROCESSOR表示の意味を確認する
• Ollama APIの実行中モデル - size_vram、context_length、量子化をJSONで確認する

API usageを速度の原因切り分けに使う

usage fieldsは「自分の呼び出しでどこに時間がかかったか」を記録するための材料です。total_durationだけで遅いと判断せず、load_duration、prompt_eval_duration、eval_durationを入力・出力token数と一緒に残します。ストリーミングの場合は、usage fieldsがdone=trueの最終チャンクへ含まれると公式に説明されています。

POST http://localhost:11434/api/generate
model: 使用したモデル名
prompt: 短い固定プロンプト
stream: false

context lengthとメモリを先に確認する

Ollama公式のContext length Docsでは、contextはモデルがメモリ上で参照できる最大token数で、大きくすると必要メモリが増えると説明されています。確認時点の公式ページでは、VRAMが24GiB未満なら4k、24〜48GiBなら32k、48GiB以上なら256kという既定値が案内されていますが、表示や既定値は利用時点のDocsを優先します。

• [公式] Ollama Context length - context length、VRAM別の既定値、メモリ負荷、ollama psの見方を確認します。

• コンテキスト長とは - 長文・KV cacheとメモリの基本を読む
• メモリ8GB・16GB・32GBの目安 - Windows全体の空きメモリを含める

モデルサイズ・量子化・CPU fallbackを分ける

大きいモデルや重い量子化は、ロード時間やメモリ余白に影響しやすいものの、特定のPCでの速度をファイルサイズだけから保証できません。同じモデル系列、同じ量子化、同じcontextで比較し、GPUが使われない場合はCPU fallbackと断定する前にPROCESSORと公式GPU対応を確認します。

• ローカルAIの速度を測る方法 - ロード・TTFT・生成速度を同じ条件で測る
• モデルサイズ早見表 - モデル規模と安定性を分けて判断する
• Q4/Q5/Q8の違い - 量子化を安全ランクとみなさない

localモデルとcloudモデルを分ける

Ollamaという名前だけでは推論場所を決められません。localモデルとcloudモデルでは、PCのCPU/GPU、ネットワーク、サインイン、利用条件、ログやusageの見方が異なります。今回の記事の主対象はWindows上のローカルモデルです。

• Ollamaのローカルモデルとcloudモデルの違い - :cloudをPC内推論として扱わない
• Ollamaとは - 本体、local、cloud、APIの境界を読む

Windowsログでモデル以外の遅さを確認する

Ollama公式Windows Docsでは、%LOCALAPPDATA%\Ollamaにapp.log、server.log、upgrade.logが保存されると説明されています。Troubleshooting Docsではserver.logの確認や、必要な場合の追加debug loggingが案内されています。ログの全文を公開せず、日時、該当行、モデル名だけを安全に抜き出します。

• [公式] Ollama for Windows - Windows要件、localhost:11434、PATH、ログ保存場所、モデル保存場所を確認します。
• [公式] Ollama Troubleshooting - Windowsのserver.log、LLM library、追加ログ、GPU検出の切り分けを確認します。

同一条件での再現手順

1. モデル名、量子化、context、Ollamaの版、PC、GPU/VRAMを記録する。
2. ollama psでロード状態とPROCESSORを記録する。
3. 短い固定promptを1回だけ送り、初回と同じモデル再利用時を分ける。
4. APIならusage fieldsを保存し、CLIなら実行条件と終了状態を保存する。
5. context、モデル、GPU設定、同時実行を1つずつ変更して比較する。

この手順で得た値は、あなたのPC・モデル・条件の記録です。サイト記事へ実測値として転記したり、一般的な快適ラインとして断定したりしません。

やってはいけないこと

• 実測していないtokens/sや、特定モデルの秒数を作る。
• PROCESSORを見ずにタスクマネージャーのGPU使用率だけでCPU実行と断定する。
• context、モデル、driver、並列処理を同時に変更する。
• Ollamaが遅いだけでモデルフォルダやログを削除する。
• cloudモデルをローカルモデルの速度比較へ混ぜる。

次に読む順番

• Ollama症状別トラブルシュート - 起動・停止・GPUなど別症状へ戻る
• Ollamaの回答が途中で止まる - generation後の終了理由とログを読む
• Ollamaが起動しない・localhost:11434につながらない - tray、CLI、APIの接続問題を切り分ける
• OllamaでGPUが使われない - PROCESSORとGPU対応表を確認する
• ローカルAIをAPIで使う方法 - API接続とモデル速度を分ける