Autor: Jakub Rusinowski · Ostatnia aktualizacja 2026-08-04 · Wartości sprzętowe wyliczone naszym silnikiem VRAM
Context engineering to dobieranie najmniejszego zestawu tokenów o największej wartości informacyjnej, jaki agent widzi w danej turze. Lokalnie dochodzi wymiar, którego użytkownicy API nie znają: kontekst to VRAM. Każdy token okna kosztuje cache KV konkurujący z wagami, więc zadaniem jest zbudżetowanie okna, za które płacisz sprzętem — i kompaktowanie, zanim jakość spadnie, co w lokalnym modelu następuje na długo przed zapełnieniem okna.
W modelu hostowanym kontekst jest abstrakcyjnym limitem z ceną za token. Na twoim własnym GPU jest fizyczny: cache KV długiej rozmowy z agentem to gigabajty tego samego VRAM-u, w którym siedzą wagi. Podwojenie kontekstu może oznaczać zejście o poziom kwantyzacji albo o próg modelu — kompromis, przed którym żaden użytkownik API nigdy nie stoi.\n\nTo zmienia całą dyscyplinę. Chmurowa rada brzmi „masz 200K, korzystaj”. Lokalna jest odwrotna: wyznacz okno na podstawie swojego VRAM-u, a dopiero potem wciśnij w nie zestaw roboczy agenta. Zrób to na odwrót, a spotkasz dwie najczęstsze awarie lokalnych agentów: ciche ucięcie promptu i błąd braku pamięci w połowie zadania, które zaczęło się dobrze.
Zanim zaczniesz optymalizować, poznaj rachunek. Typowa tura agenta w VS Code, w połowie zadania, na repozytorium umiarkowanej wielkości:\n\n| Składnik | Typowa liczba tokenów | Uwagi |\n|---|---|---|\n| Prompt systemowy harnessu | 2000 – 10 000 | Ogromnie zależy od narzędzia. Aider jest na dolnym końcu, pełne agenty na górnym |\n| Schematy narzędzi i MCP | 500 – 25 000+ | Każdy podpięty serwer MCP dokłada całą swoją listę narzędzi, w każdym żądaniu. Typowy cichy zabójca |\n| Plik z regułami (AGENTS.md) | 300 – 1500 | Tanie, o dużej dźwigni — i niech tak zostanie |\n| Mapa repozytorium / drzewo plików | 1000 – 5000 | Mapa repozytorium Aidera albo dowolny indeks, który wstrzykuje twój agent |\n| Pliki w zestawie roboczym | 2000 – 20 000 | Ta część, która faktycznie dotyczy twojego zadania |\n| Rozmowa i wyniki narzędzi | rośnie bez ograniczeń | Logi testów, grepy, wyjście builda. Tu umierają okna |\n| Miejsce na odpowiedź | 1000 – 4000 | Zarezerwuj je jawnie albo model zostanie ucięty w połowie diffa |\n\nDwa wiersze dominują: schematy narzędzi i skumulowane wyniki narzędzi. Żaden z nich nie jest twoim promptem i żadnego nie widać w interfejsie czatu — dokładnie dlatego ludzie dochodzą do wniosku, że model jest głupi, podczas gdy 70% ich okna to narzut.
Cache KV skaluje się liniowo z długością kontekstu i z rozmiarem modelu, a dokłada się do wag. Z grubsza wygląda to tak na karcie 24 GB z 27B na Q4: wagi zajmują jakieś trzy czwarte karty, a każde kolejne 8K kontekstu zabiera następny kawałek — dlatego 32K się mieści, a 128K już nie, w modelu, którego karta reklamuje 256K.\n\nZamiast ufać tabelce, policz to: kalkulator VRAM wylicza wagi plus cache KV dla konkretnego modelu, kwantyzacji i długości kontekstu, tym samym silnikiem co każda liczba na tej stronie. Trzy praktyczne konsekwencje:\n\n- Reklamowany kontekst to nie twój kontekst. Model z natywnym oknem 256K na karcie 16 GB jest w praktyce modelem 16K–32K. Nic się nie zepsuło; po prostu nie stać cię na ten cache.\n- Kwantyzacja cache'u KV daje odczuwalne miejsce. llama.cpp i to, co z niej wyrasta, potrafią trzymać cache w 8 bitach, mniej więcej połowiąc jego zajętość niewielkim kosztem jakości — często to właśnie różnica między 16K a 32K na tej samej karcie.\n- Dłuższy kontekst spowalnia każdą turę. Prefill rośnie razem z promptem, więc rozdęte okno kosztuje opóźnienie w każdej iteracji pętli, nie tylko pamięć.\n\nJeśli liczby mówią, że docelowy kontekst się nie mieści, uczciwe opcje to niższa kwantyzacja, mniejszy model albo wynajem większego GPU — a nie liczenie na to, że nikt nie zauważy ucięcia.
Zapełnianie okna nie działa tak, że model degraduje się dopiero przy 100%, a poniżej trzyma formę. Jakość uwagi spada w miarę zapełniania okna i narastania nieistotnych treści — to zjawisko zwykle nazywa się context rot. Lokalne modele, na ogół mniejsze i często trenowane na mniejszej ilości danych z długim kontekstem niż modele z czołówki, trafiają na nie wcześniej: praktyczna reguła mówi, że lokalny agent kodujący zaczyna zauważalnie tracić gdzieś między połową a dwiema trzecimi serwowanego okna.\n\nObjawy, w kolejności, w jakiej zwykle się pojawiają:\n\n1. Przestaje trzymać się pliku z regułami (te tokeny są najdalej i najbardziej rozcieńczone).\n2. Czyta ponownie pliki, które już przeczytał, bo wcześniejszy odczyt został zasypany.\n3. Odwołuje się do funkcji, które nie istnieją — często z wcześniejszego, porzuconego planu.\n4. Edycje zaczynają kłócić się z edycjami, które zrobił dwadzieścia tur wcześniej.\n\nLekarstwem nie jest większe okno. Jest nim usuwanie tokenów: kompaktowanie, podagenty albo restart. Świeża sesja z jednoakapitowym przekazaniem rutynowo bije zdegradowaną sesję z pełną historią — a lokalnie nie kosztuje nic poza prefillem.
1 · Ustaw serwowane okno świadomie. To nie tyle technika kontekstowa, ile warunek wstępny dla wszystkich pozostałych. Ollama po cichu ucina do swojej wartości domyślnej; wariant z długim kontekstem to dwie linijki:
cat > Modelfile <<'EOF'
FROM qwen3.6:27b
PARAMETER num_ctx 32768
EOF
ollama create qwen3.6:27b-32k -f ModelfilePotem wybierz ten wariant w agencie i przed zaufaniem mu potwierdź kalkulatorem, że cache faktycznie się mieści.
2 · Przycinaj wyniki narzędzi u źródła. Pełny log testów albo rekurencyjne wypisanie katalogu to dziesiątki tysięcy tokenów szumu. Zachowuj ogon porażek (tam siedzi asercja), ograniczaj grepy do pasujących linii z odrobiną otoczenia i nigdy nie wpuszczaj do okna surowego find ani ls -R. Większość harnessów wystawia limit; ustaw go na tyle, ile twoje okno przeżyje.
3 · Kompaktuj świadomie, nie przy 95%. Harnessy produkcyjne kompaktują etapami — najpierw odrzucają nieświeże wyjścia narzędzi, potem streszczają stare tury, na końcu odbudowują zestaw roboczy. Cokolwiek oferuje twoje narzędzie, uruchamiaj to wcześniej niż domyślnie: progi zaprojektowane pod okno 200K z czołówki są stanowczo za późne dla lokalnych 32K. Co musi przetrwać kompaktowanie: cel, podjęte już decyzje, bieżący diff i otwarte problemy. Co nie powinno: surowe logi, nieaktualne plany, zawartość plików, które już zostały zmienione.
4 · Zestaw roboczy dobieraj ręcznie. Jawne dodawanie plików bije pozwalanie agentowi na ich odkrywanie — jest szybsze, tańsze i dramatycznie poprawia trafność małych modeli. Podstawowe narzędzia to /add i /drop w Aiderze, jawne wzmianki o plikach w Cline i reguły ignorowania per projekt. Trzy właściwe pliki biją trzydzieści prawdopodobnych.
5 · Izoluj podagentami albo osobnymi sesjami. Wzorzec, który się skaluje: podzadanie działa we własnym oknie i zwraca krótkie podsumowanie zamiast całego zapisu rozmowy. Nawet bez wbudowanej obsługi podagentów zrobisz to ręcznie — hałaśliwą eksplorację („które pliki dotykają uwierzytelniania?”) przeprowadź w jednej sesji, a sesję z edycją zacznij od trzywierszowej odpowiedzi. To najskuteczniejsza lokalna technika przy długich zadaniach, bo trzyma główne okno małym na stałe.
Marketing długiego kontekstu podpowiada, żeby wkleić całą bazę kodu. Dla lokalnych agentów to zły odruch podwójnie: nie stać cię na ten cache, a trafność zwykle *spada*, gdy istotny plik jest zakopany wśród pięćdziesięciu nieistotnych.\n\nDziałającą alternatywą jest wyszukiwanie, nie upychanie. Agenty kodujące opierające się na grep czy ripgrep i na drzewie plików — czytające tylko to, co zwróci wyszukiwanie — wypadają zwykle lepiej niż te, które wstępnie ładują kontekst, i są znacznie tańsze w przeliczeniu na turę. W praktyce:\n\n- Pozwól agentowi szukać, a potem przeczytać te dwa czy trzy pliki, które znalazł.\n- Zamiast zawartości plików trzymaj mapę repozytorium (zwartą listę plików z ich kluczowymi symbolami).\n- Jeśli chcesz wyszukiwania semantycznego po dużej bazie kodu, zindeksuj ją osobno i podawaj z powrotem fragmenty — lokalny pipeline RAG stosuje się do kodu bez zmian.\n\nKontekst całoplikowy zasługuje na swoje miejsce przy pliku, który jest właśnie edytowany, i rzadko poza nim.
Konkretny punkt wyjścia, przy założeniu serwowanego okna 16K na 16 GB i 32K na 24 GB:\n\n| Wycinek | Okno 16K | Okno 32K |\n|---|---|---|\n| Prompt harnessu plus schematy narzędzi | do 4K (lekki harness, mało narzędzi) | do 8K |\n| Plik z regułami | do 1K | do 1,5K |\n| Pliki zestawu roboczego | 4–6K (2–3 pliki) | 10–14K (4–6 plików) |\n| Bieżąca rozmowa i wyniki narzędzi | 3–4K, agresywnie kompaktowane | 6–8K |\n| Rezerwa na odpowiedź | 2K | 3K |\n\nJeśli same schematy rozsadzają pierwszy wiersz — typowy przypadek przy kilku podpiętych serwerach MCP — to właśnie jest twoja poprawka i większa wygrana niż jakiekolwiek przepisywanie promptu. Szczegóły w MCP przy lokalnych agentach kodujących.