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

Autor: Jakub Rusinowski · Ostatnia aktualizacja 2026-08-04 · Wartości sprzętowe wyliczone naszym silnikiem VRAM

Lokalny agent kodujący zwykle wydaje się wolny przez prefill, nie przez generowanie: każda tura na nowo przetwarza wielki prompt, zanim pojawi się pierwszy nowy token. Poprawki, w kolejności opłacalności: ponowne użycie cache'u promptu i KV, żeby niezmienione prefiksy nie były przeliczane od nowa, mniejszy roboczy kontekst, dekodowanie spekulatywne dające 1,5–3× szybsze generowanie, utrzymywanie modelu w pamięci i osobny mały model do autouzupełniania. Razem zmieniają odczucia z pracy bardziej niż przeskok o jeden próg karty.

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.

Poprawka 1 — używaj ponownie cache'u promptu (największy pojedynczy zysk)

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ć.

Poprawka 2 — przestań płacić za kontekst, którego nie używasz

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.

Poprawka 3 — dekodowanie spekulatywne

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ść.

Poprawka 4 — trzymaj model w pamięci

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ść.

Poprawka 5 — dwa modele, dwa zadania

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 Qwen3-Coder 8B — 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.

Poprawka 6 — dobierz runtime do zadania

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.

Zmierz, zanim kupisz

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.

Nie masz sprzętu? Najpierw wynajmij kartę

Zanim kupisz kartę, żeby zbić opóźnienie, wynajmij na wieczór próg wyżej i przeprowadź tę samą sesję. Jeśli czas do pierwszego tokena ledwo drgnie, wąskim gardłem był rozmiar promptu albo brak ponownego użycia cache'u — a ta poprawka nic nie kosztuje.

RunPod — RTX 4090 ≈ $0.3–0.7/hr, A100/H100 by the hour; serverless per-second billing available
Vast.ai — Marketplace of hosted GPUs — often the cheapest per hour (interruptible options)
Lambda — On-demand A100/H100/B200 instances and clusters, per-hour billing

Pełna lista w katalogu chmurowej AI.

Najczęstsze pytania

Dlaczego mój lokalny agent kodujący tak długo zbiera się do odpowiedzi?

Przez prefill. Każda tura na nowo przetwarza cały prompt — systemowy, schematy narzędzi, plik z regułami, pliki w kontekście i dotychczasową rozmowę — zanim powstanie pierwszy token wyjścia. Prompty agentowe są wielkie, a odpowiedzi często krótkie, więc w pracy agentowej prefill dominuje w sposób, w jaki w czacie nigdy nie dominuje. Ponowne użycie cache'u promptu i skrócenie samego promptu uderzają w to wprost; szybsza karta tylko częściowo.

Czym jest dekodowanie spekulatywne i czy pomaga przy kodowaniu?

Mały model szkicujący proponuje kilka tokenów do przodu, a pełny model weryfikuje je w jednym przebiegu, dając identyczne wyjście przy zwykle 1,5–3× wyższym tempie. Na kodzie działa wyjątkowo dobrze, bo kod jest w małej skali bardzo przewidywalny — nawiasy, wcięcia, boilerplate — więc współczynnik akceptacji jest wysoki. Model szkicujący musi dzielić tokenizer z docelowym i musi zmieścić się w VRAM-ie, nie wymuszając gorszej kwantyzacji modelu głównego.

Jak sprawić, żeby model nie przeładowywał się między żądaniami?

Trzymaj go w pamięci: ustaw OLLAMA_KEEP_ALIVE na długość swojej sesji pracy albo przekazuj keep_alive przy żądaniu. Unikaj też przełączania modeli w trakcie sesji — przełączenie kosztuje i ponowne wczytanie wag, i utratę cache'u promptu, co u hostowanego dostawcy jest darmowe, a na własnym GPU drogie.

Czy cache promptu działa przy agentach?

Tak i to jest największy pojedynczy zysk — prompty agentowe z tury na turę są niemal identyczne. Haczyk polega na tym, że cokolwiek zmienia się na początku promptu, unieważnia cały cache po sobie, więc znacznik czasu w prompcie systemowym albo lista narzędzi w niedeterministycznej kolejności potrafią po cichu kosztować cię każdą turę. Trzymaj początek promptu identyczny co do bajtu, a treść zmienną umieszczaj na końcu.

Czy używać jednego modelu i do autouzupełniania, i do pracy agentowej?

Nie. Mają przeciwstawne wymagania: podpowiedź potrzebuje odpowiedzi w dziesiątkach milisekund z lokalnego kontekstu, a tury agentowe znoszą sekundy i potrzebują rozumowania. Do podpowiedzi w linii uruchom mały model dostrojony pod FIM, na przykład StarCoder2 3B albo Qwen3-Coder 8B, obok dużego modelu do czatu i pracy agentowej — na karcie 24 GB oba mieszczą się wygodnie.

Czy szybsza karta naprawi wolnego agenta kodującego?

Czasem, ale najpierw zmierz. Jeśli czas do pierwszego tokena przy powtórzonym prompcie jest tak samo długi jak przy zimnym, twój cache promptu nie jest używany ponownie i żadna karta tego nie naprawi. Jeśli twoje tokeny na sekundę zgadzają się z tym, co dla podobnego sprzętu pokazuje strona benchmarków, a mimo to jest za wolno jak na twój sposób pracy, wtedy uczciwą odpowiedzią jest wymiana sprzętu — a wynajem progu wyżej na jeden wieczór sprawdza to tanio.