Ollama の返答が空になる・途中で切れる（finish_reason が length）原因は既定の context 4096

先に結論

返答が空になって、usage の合計がちょうど 4096、finish_reason が length なら、context があふれている。
呼び出し側のシステムプロンプトが長いと、既定の 4096 は数往復で埋まる。既定は VRAM の量で変わり、4096 になるのは VRAM が 24 GiB 未満のとき。
num_ctx を上げた別名のモデルを作り、そのアプリだけをそこへ向ける。グローバルの設定は変えない。
直したあと、返答は切れなくなり、初回応答も約 6 秒から 0.1〜0.5 秒になった。

ローカルの AI コンパニオン（AIRI のデスクトップ版）を Ollama の qwen3.5:9b につないで使っていた。テストを繰り返すうちに、LLM の返答が空になった。

Ollama の応答はこうだった。

初回応答まで、毎回約 6 秒かかっていた。

最初は音声合成（TTS）や、計測用に足した fetch のフックが応答を壊したと考えた。フックが二重にかかってイベントが重複していたこともあって、切り分けに時間がかかった。

決め手は、usage の合計がちょうど 4096 になっていたことと、finish_reason が length だったこと。中身が壊れたのではなく、長さで止まっていた。

この環境では、Ollama の既定の context は 4096 だった。一方、AIRI のシステムプロンプトは約 4k トークンある。

これだけで上限の近くまで埋まる。履歴が数往復増えると上限に達し、返答は 26 トークンほどで切れて空になる。

既定の値はどの環境でも 4096 というわけではない。いまの公式文書では、既定は VRAM の量で決まる。

この環境の GPU は 12 GB なので、4k の側に入る。VRAM の大きい環境では、同じ長さのシステムプロンプトでもこの症状は出にくいはず。

記録では、あふれた分を切り詰めるのでプロンプトキャッシュも効かず、毎回約 4000 トークンを計算し直していた、と見ている。cached_tokens が 0 で毎回約 6 秒かかっていたのは、これと合う。

元のモデルを土台にして、context だけを広げた別名を作る。別名の中身はこの二行。

FROM qwen3.5:9b
PARAMETER num_ctx 16384

この内容で別名のモデル（記録では qwen3.5-airi:9b）を作り、そのアプリの LLM の設定をその名前に向けた。重みは元のモデルと共有している。

グローバルの OLLAMA_CONTEXT_LENGTH は使わなかった。同じ Ollama を使うほかのアプリにも効いてしまうからだ。別名にしておけば、そのアプリだけが変わる。

元に戻すときは、別名を消せばいい。

ollama rm qwen3.5-airi:9b

qwen3.5:9b は、full attention の層が 8 層で、KV ヘッドは 4 つしかない。KV キャッシュは 1 トークンあたり約 32 KB で、16k に広げても VRAM は約 5.2 GB から約 5.7 GB に増えただけだった。

これはこのモデルの構成での話。ほかのモデルで同じとは限らないので、広げる前に見ておくといい。

見るところは、直す前に原因を見つけたときと同じ。応答の usage と finish_reason を見て、合計が上限に張り付いていないか、finish_reason が length になっていないかを確かめる。

モデルを読み込んだあとに ollama ps を打つと、CONTEXT の列に割り当てられた context の長さが出る（公式文書による）。自分の環境の既定がいくつかは、ここで見るのが早い。

この環境では、直したあと返答切れはなくなり、LLM の初回応答は 0.1〜0.5 秒になった。

項目	内容
GPU	RTX 5070 12 GB（音声合成・文字起こしと同居）
モデル	qwen3.5:9b（別名で num_ctx 16384）
呼び出し側	AIRI のデスクトップ版（システムプロンプト約 4k トークン）

Ollama の版は記録に残っていない。