Dlaczego twój lokalny agent kodujący wlecze się w miejscu — i sześć poprawek, które działają

Narzekanie prawie nigdy nie brzmi „mam mało tokenów na sekundę”. Brzmi „proszę o coś i przez dwadzieścia sekund nic się nie dzieje”. To dwa różne problemy z różnymi rozwiązaniami, a mylenie ich wysyła ludzi na zakupy po kartę, której mogą wcale nie potrzebować.

Każda tura agenta ma dwie fazy. Prefill przetwarza cały prompt — prompt systemowy, schematy narzędzi, plik z regułami, wszystkie pliki w kontekście, całą dotychczasową rozmowę — zanim powstanie choć jeden token wyjścia. Potem dekodowanie produkuje odpowiedź token po tokenie. W czacie dominuje dekodowanie, dlatego to właśnie tam liczą się tokeny na sekundę. W pracy agentowej dominuje prefill, bo prompt jest ogromny, a odpowiedzią bywa krótkie wywołanie narzędzia. To odwrócenie tłumaczy, dlaczego agent potrafi się wlec na sprzęcie, który wygodnie prowadzi czat, i dlaczego największe zyski przychodzą z nieprzeliczania tego, co już zostało policzone.

Prompt agenta z tury na turę jest w większości identyczny: ten sam prompt systemowy, te same narzędzia, ten sam plik z regułami, te same pliki, plus odrobina nowej rozmowy na końcu. Przeliczanie tego niezmienionego prefiksu w każdej turze to czysta strata — i dokładnie to dzieje się domyślnie w części konfiguracji.

llama.cpp i to, co z niej wyrasta, trzymają cache KV dla wspólnego prefiksu i przetwarzają wyłącznie nowy sufiks, zamieniając kilkusekundowy prefill w jego ułamek. Warto wiedzieć, co to ponowne użycie psuje:

• Cokolwiek zmieni się na początku promptu, unieważnia wszystko, co po nim. Znacznik czasu w prompcie systemowym, plik z regułami generowany od nowa, lista narzędzi w niedeterministycznej kolejności — każde z osobna wyrzuca cały cache w każdej turze.
• Kompaktowanie też go resetuje. Jest konieczne, ale oznacza, że tura zaraz po kompaktowaniu jest droga. Kompaktowanie rzadziej, za to gruntowniej, bije ciągłe przycinanie.
• Przełączanie się między dwoma modelami na jednym serwerze wypycha cache tego drugiego. Trzymaj jeden model na sesję.

Treść zmienną — bieżące zadanie, najnowsze wyjście narzędzia — umieszczaj na końcu promptu, a początek trzymaj identyczny co do bajtu. To nic nie kosztuje, a przy długiej sesji decyduje o tym, czy da się z tego korzystać.

Czas prefillu skaluje się z długością promptu, więc każdy token, którego nigdy nie potrzebowałeś, kosztuje cię w każdej turze. Przy pętli agentowej te oszczędności kumulują się w sposób, jaki w czacie nigdy nie zachodzi.

Trzy największe źródła, wszystkie opisane szerzej w innych miejscach tego działu:

• Schematy narzędzi z podłączonych serwerów MCP — potencjalnie dziesiątki tysięcy tokenów na żądanie, w większości opisujące narzędzia, po które to zadanie nie sięgnie (MCP).
• Nieograniczone wyjście narzędzi — cały log testów albo rekurencyjne wypisanie katalogu wklejone w kontekst, a potem przetwarzane od nowa w każdej kolejnej turze.
• Całe pliki tam, gdzie wystarczyłby fragment (context engineering).

Jest jeszcze subtelniejsze ustawienie: przydzielenie kontekstu 32K, gdy używasz 8K, wciąż kosztuje VRAM, który mógł pójść na lepszą kwantyzację. Dobierz serwowane okno do tego, ile faktycznie zużywasz, a bilans sprawdź w kalkulatorze VRAM.

Najlepsze przyspieszenie po stronie generowania, jakie da się mieć na lokalnym sprzęcie. Mały model szkicujący (draft model) proponuje kilka tokenów do przodu; pełny model weryfikuje je w jednym przebiegu, przyjmując te, z którymi się zgadza. Wyjście jest identyczne jak przy samym dużym modelu — to nie jest przybliżenie — a typowe przyspieszenie wynosi 1,5–3×.

Na kodzie sprawdza się wyjątkowo dobrze. Kod jest w małej skali wysoce przewidywalny: nawiasy, wcięcia, boilerplate, powtarzające się identyfikatory. Malutki model szkicujący trafia długie serie takich fragmentów, więc współczynnik akceptacji jest wysoki.

# llama.cpp: model docelowy 27B z małym modelem szkicującym z tej samej rodziny
llama-server -m qwen3.6-27b-q4_k_m.gguf \
  -md qwen3-coder-1.5b-q4_k_m.gguf \
  --draft-max 16 --draft-min 4 \
  --ctx-size 32768 --port 8080

Dwa warunki do sprawdzenia, zanim zaczniesz liczyć na ten zysk. Model szkicujący musi dzielić tokenizer z docelowym — w praktyce: ta sama rodzina, dużo mniejszy rozmiar. I musi się zmieścić obok wszystkiego innego: 1,5B na Q4 to niewielki dodatek, ale na karcie już zapełnionej potrafi wymusić gorszą kwantyzację modelu głównego, co jest stratą na czysto. Przy ciasnym VRAM-ie odpuść.

Zimny start wczytuje gigabajty wag z dysku. Jeśli twój agent milczy przez kilka minut, a serwer zdążył go wyładować, następne żądanie za to zapłaci — i czyta się to jako „agent czasem się zawiesza”.

# Ollama: trzymaj wagi załadowane przez ośmiogodzinną sesję pracy
export OLLAMA_KEEP_ALIVE=8h
# Albo pojedynczo, przy żądaniu
curl http://localhost:11434/api/generate -d '{"model":"qwen3.6:27b-32k","keep_alive":"8h"}'

Z tym samym wiąże się druga rzecz: nie podmieniaj modeli w trakcie sesji, jeśli nie musisz. Przełączenie kosztuje ponowne wczytanie wag plus utratę cache'u promptu — nawyk darmowy u hostowanego dostawcy i drogi na własnym GPU. Wybieraj model na sesję, nie na wiadomość.

Autouzupełnianie i praca agentowa mają przeciwstawne wymagania. Podpowiedź musi odpowiedzieć w dziesiątkach milisekund i potrzebuje wyłącznie lokalnego kontekstu. Praca agentowa znosi sekundy i potrzebuje rozumowania. Obsługiwanie obu z jednego modelu 27B czyni podpowiedzi bezużytecznymi i marnuje duży model na trywialne sugestie.

Do podpowiedzi w linii uruchom mały model fill-in-the-middle — StarCoder2 3B albo StarCoder 2 7B — a duży model zostaw do czatu i tur agentowych. Na karcie 24 GB oba mieszczą się wygodnie; ten mały kosztuje parę gigabajtów i przewraca odczucia z pracy w edytorze z minuty na minutę. Szczegóły konfiguracji w lokalnych alternatywach dla Copilota.

Ollama to najprostszy start i spokojnie wystarcza przy pracy jednoosobowej. Przeprowadzkę uzasadniają dwie sytuacje:

• Wspólna maszyna zespołowa. vLLM albo SGLang znacznie lepiej wsadują równoległe żądania, więc czterech programistów uderzających w jeden serwer nie stoi w kolejce jeden za drugim. Zobacz przewodnik po vLLM.
• Chcesz mieć pokrętła. llama-server wystawia bezpośrednio modele szkicujące, kwantyzację cache'u, rozmiary wsadów i chunked prefill. Jeśli optymalizujesz, a nie po prostu używasz, zejdź warstwę niżej.

Dwa ustawienia warte wypróbowania wszędzie tam, gdzie twój runtime je obsługuje: flash attention, które zmniejsza pamięć zajmowaną przez uwagę i przyspiesza prefill długiego kontekstu, oraz 8-bitowy cache KV, który mniej więcej połowi zajętość cache'u, pozwalając utrzymać dłuższe okno bez schodzenia o poziom kwantyzacji niżej. Jedno i drugie zwykle sprowadza się do jednej flagi.

O tym, co naprawić, mówią trzy liczby, a ich zebranie zajmuje pięć minut:

1. Czas do pierwszego tokena przy pełnym prompcie agenta. Wysoki i rosnący wraz z długością sesji → prefill i ponowne użycie cache'u. To liczba, która najmocniej rządzi odczuciami. 2. Tokeny na sekundę w trakcie generowania. Niskie → dekodowanie spekulatywne, niższa kwantyzacja albo faktycznie więcej GPU. 3. *Czas do pierwszego tokena przy powtórzonym prompcie.* Jeśli jest taki sam jak przy zimnym, twój cache promptu nie jest używany ponownie — wróć do Poprawki 1, bo dopóki to nie zadziała, cała reszta jest drugorzędna.

Porównaj to ze zmierzoną przepustowością dla twojej karty i modelu na stronie benchmarków. Jeśli twoje wyniki są mocno poniżej tego, co raportuje podobny sprzęt, problemem jest konfiguracja, nie karta. Jeśli się zgadzają, a mimo to jest za wolno jak na sposób, w jaki chcesz pracować, wtedy rozmowa o sprzęcie jest uczciwa — progi rozpisuje najlepsze GPU do kodowania z AI, a wynajem na jeden wieczór sprawdza tę hipotezę za kilka dolarów.