Ollamaの回答が途中で止まる時の直し方｜done_reason・context・メモリ・ログ確認

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

「回答が途中で止まる」と見えても、モデルのpullが続いている、ロードに時間がかかっている、入力処理中、生成開始後に終了した、APIの接続が切れた、のどれかで対処が変わります。

CLIかAPIかを先に記録する

CLIの画面で止まったのか、/api/generateや/api/chatのレスポンスで終わったのかを分けます。APIでは、streamingならdone=trueの最終チャンクにusage fieldsが含まれると公式に案内されています。生成文字の途中だけを保存するのではなく、最後のJSONチャンクとHTTPエラーを残します。

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

doneとdone_reasonは記録するが、値を推測しない

Ollamaの公式Generate/Chat APIレスポンスにはdoneとdone_reasonが含まれます。Usageの公式例ではdone_reasonがstopとなるレスポンスも示されていますが、実際の値や終了条件はAPI、モデル、設定、バージョンによって変わり得ます。記事では未知の値を勝手に分類せず、レスポンスと公式仕様をそのまま確認します。

done: true
done_reason: 実際に返った値
total_duration: 実際に返った値
load_duration: 実際に返った値
prompt_eval_count: 実際に返った値
eval_count: 実際に返った値

• doneがtrueになったか、streamの最終chunkを確認する。
• done_reasonの文字列を保存し、公式API Docsに記載があるか確認する。
• 途中でclient側が切断した可能性と、server側が終了した可能性を分ける。
• レスポンス本文にAPI key、個人パス、機密promptがないか確認してから共有する。

contextとメモリを短い条件へ戻す

長い会話、長いsystem prompt、tool、長い文書、context設定の増加は、入力処理と生成中のメモリ条件を変えます。まず短い固定prompt、新規の状態、控えめなcontext、短い出力で完走するか試し、長い条件を1つずつ戻します。

• Ollama Context length公式 - contextとVRAM・メモリの関係を見る
• コンテキスト長とは - 長文・KV cacheの基本へ戻る
• メモリ8GB・16GB・32GBの目安 - Windows全体の空きメモリを含める

CPU/GPU分割とモデル条件を確認する

Ollama公式FAQのPROCESSOR表示では、100% GPU、100% CPU、CPU/GPUの部分処理を区別できます。回答が止まった時は、ollama psでモデルの状態を保存し、GPU対応表、driver、VRAM、context、モデルの量子化を同じ条件で確認します。

• [公式] Ollama FAQ - ollama psのPROCESSOR表示とCPU/GPU分割、環境変数の公式説明を確認します。
• [公式] Ollama Hardware support - NVIDIA、AMD Radeon、WindowsのGPU対応表とドライバー条件を確認します。
• [公式] Ollama List running models - 実行中モデルのsize_vram、context_length、quantization_levelなどを確認します。

Windowsのserver.logを確認する

Windows版Ollamaのserver.logには、サーバーやruntime、GPU検出などの手がかりが出る場合があります。公式Troubleshootingでは、%LOCALAPPDATA%\Ollamaやserver.logの場所、追加debug loggingの方法が案内されています。ログをすべて公開せず、再現時刻の周辺だけを伏せ字で保存します。

explorer %LOCALAPPDATA%\Ollama
explorer %LOCALAPPDATA%\Ollama\server.log

OLLAMA_DEBUGのような追加ログは、公式Troubleshootingの手順が必要な場合だけ、実行中のアプリを終了して一時的に使います。知らない環境変数を常用設定として追加しません。

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

モデル固有か、全モデル共通かを比較する

1. 同じPC、同じOllama、短い固定promptで、別の小さいモデルを1つだけ試す。
2. 同じモデルをCLIとAPIで試し、どちらだけ止まるかを分ける。
3. context、入力長、出力上限、同時実行を1つずつ戻す。
4. 別モデルでも同じ時刻に止まる場合は、server.logとPC負荷を先に見る。
5. モデル固有の問題と断定する前に、モデル配布元のModel Cardや更新情報を確認する。

再インストール・削除の前に残すもの

• ollama --version、モデル名、量子化、digest、context、PROCESSOR。
• CLIかAPIか、endpoint、stream設定、done/done_reason、usage fields。
• server.logの該当時刻、app.log、upgrade.log、直前の更新。
• RAM、GPU、VRAM、Windows版、同時実行、入力・出力の長さ。

モデルフォルダを最初に削除せず、保存場所と再現条件を残します。公式Windows Docsでは、OLLAMA_MODELSを変更していた場合のモデル取り扱いも案内されています。

やってはいけないこと

• done_reasonの値を確認せず、クラッシュやcontext超過と断定する。
• server.logやAPI最終chunkを残さず再インストールする。
• 長いcontext、複数request、大きいモデルを同時に有効にする。
• 非対応GPUへ危険なoverrideや未知の環境変数を無条件で設定する。
• 機密promptやユーザー名を含むログ全文を公開する。

次に読む順番

• Ollama症状別トラブルシュート - 起動・速度・GPUの入口へ戻る
• Ollamaが遅い - usage fieldsとPROCESSORで速度を分ける
• Ollamaが起動しない・localhost:11434につながらない - API接続やserver起動の問題へ進む
• OllamaでGPUが使われない - GPU対応とCPU/GPU分割を見る
• Ollamaのローカルモデルとcloudモデルの違い - ローカル推論とcloudを分ける