Ollama nie ma stałego okna 4096 tokenów

Chciałem pokazać, jak wygląda ucięcie promptu. Zbudowałem prompt na 12 685 tokenów i pytanie, na które odpowiedź jest wyłącznie w pierwszej sekcji — czyli tam, gdzie ucinanie zaczyna pracę.

Nic się nie stało. Model przeczytał 11 907 tokenów i odpowiedział poprawnie. W logu Ollamy ani śladu ostrzeżenia. Powód znalazł się w tym samym logu:

msg="llama-server model fits alongside existing models"
    predicted_num_ctx=32768 available="11.5 GiB" gpu_free="16.1 GiB"
llama_context: n_ctx = 32768

Okno kontekstu nie jest stałą. Ollama 0.32 dobiera je przy każdym ładowaniu modelu do tego, ile ma wolnej pamięci. Ten sam model dostał tego samego dnia raz 8192, a raz 32768 tokenów — na tej samej maszynie. Powtarzana wszędzie liczba 4096 nie jest dzisiejszą wartością domyślną.

Presja pamięci nie zmniejsza okna

Spróbowałem wymusić ucięcie inaczej: załadowałem obok model na 17 GB, żeby zabrakło pamięci. Też nie wyszło, i to jest osobna informacja — Ollama wolała wyrzucić duży model niż zmniejszyć okno małemu.

Dopiero jawne num_ctx pokazuje mechanizm

Ten sam prompt, dwa przebiegi:

okno	model przeczytał	czas	odpowiedź
32768 (dobrane samo)	11 907 z 12 685	56,1 s	poprawna
2048 (narzucone)	1026 z 12 685	5,4 s	pewna i błędna

W drugim wierszu przepadły 92% promptu. Model nie zgłosił żadnego problemu: odpowiedział w żądanym formacie, jednym zdaniem, z konkretnym numerem wersji. HTTP 200, finish_reason: stop. Nie zignorował wklejonej dokumentacji — po prostu jej nie zobaczył, a odpowiedź dopasował do tego, co przetrwało.

Dwie rzeczy warte zapamiętania.

Zła odpowiedź przyszła dziesięć razy szybciej. Krótki czas reakcji nie znaczy „sprawnie”, tylko „mniej materiału do przeczytania”.

Jedyny sygnał po stronie klienta to prompt_eval_count zestawiony z własnym szacunkiem długości. Nic więcej nie dostajesz.

Przy okazji: num_ctx przechodzi tylko przez natywne /api/chat. Endpoint zgodny z OpenAI nie ma pola options — to nie brak w Ollamie, tylko granica zgodności z cudzym API.