Kiedy dostawcy modeli ogłosili okna kontekstowe liczące miliony tokenów, wielu CTO-ów i liderów inżynierii zareagowało tak samo: „Świetnie — wrzucimy tam całą dokumentację i nie będziemy musieli zajmować się RAG." Reakcja zrozumiała. Mniej komponentów, mniej infrastruktury, mniej strojenia. Rzeczywistość produkcyjna jest jednak bardziej skomplikowana.
Duże okno kontekstowe to potężne narzędzie — ale ma swoje fizyczne i ekonomiczne ograniczenia. Ten artykuł wyjaśni, gdzie te ograniczenia leżą, pokaże, kiedy 1M tokenów naprawdę rozwiązuje problem, a kiedy jego użycie jest niepotrzebnie drogie — i niekiedy mniej precyzyjne niż dobrze zaprojektowany pipeline z agentic RAG.
Co właściwie oznacza „1M tokenów"
Okno kontekstowe to maksymalna długość tekstu — wejście plus wyjście — którą model widzi naraz podczas jednego wywołania. Token odpowiada mniej więcej 0,75 słowa w języku angielskim; w polskich i technicznych tekstach tokeny są nieco dłuższe.
Milion tokenów to około 750 000 słów — pełna przeciętna powieść, setki stron dokumentacji technicznej lub kompletny kod źródłowy projektu średniej wielkości. Dziś nie jest to już premium: Claude (wyższe tiery), Gemini 2.5/3.x i Llama 4 Maverick oferują 1M, a Llama 4 Scout sięga nawet 10M tokenów. Nie każdy model jest jednak tak „długi" — na przykład DeepSeek V3 ma 128K. Mimo to 1M kontekst nie jest już wyjątkową funkcją, lecz rozszerzonym standardem.
Problem nie tkwi w tym, czy model poradzi sobie z długim kontekstem. Problem polega na tym, ile to kosztuje i jak spada jakość odpowiedzi wraz z rosnącą długością kontekstu.
Jak rośnie koszt wraz z długością kontekstu
Koszt obliczeniowy przy inferencji nie rośnie z kontekstem liniowo — w rzeczywistości sytuacja jest bardziej złożona, ale do praktycznych decyzji wystarczy zrozumieć jeden mechanizm: KV cache.
Każdy token w kontekście wymaga przechowania tzw. wektorów klucz-wartość (key-value) w pamięci GPU (VRAM). Przy każdym kolejnym generowanym tokenie model sięga do całej tej pamięci podręcznej. Dla modelu 7B KV cache przy 128K tokenach wynosi około 16 GB, przy 1M tokenach przekracza 100 GB. Dla modelu 70B przy 128K tokenach sama KV cache zajmuje około 40 GB — i to bez wag modelu.
Praktyczny skutek: jeśli chcecie obsługiwać kilka równoległych żądań z długim kontekstem, potrzebujecie albo ogromnego sprzętu, albo będziecie kolejkować zapytania. W chmurowym API oznacza to po prostu wyższą cenę za wywołanie — modele frontierowe liczą za każdy token wejściowy, więc długi kontekst bezpośrednio przekłada się na wyższe koszty. W lokalnym wdrożeniu (on-prem) oznacza to konieczność posiadania większej liczby lub wydajniejszych GPU.
Istnieje ważna optymalizacja: prompt caching. Jeśli Wasz systemowy prompt, dokumentacja lub inna statyczna treść pozostaje taka sama w wielu wywołaniach, dostawca zachowuje jej reprezentację KV i przy ponownym odczycie płacicie tylko 10 % ceny tokenu wejściowego (u Anthropic). Zapis do cache jest natomiast nieco droższy — 125–200 % zwykłej ceny. Oszczędność następuje tylko wtedy, gdy ten sam prefiks czytacie wielokrotnie w krótkim czasie. Tę strategię omawiamy bardziej szczegółowo w artykule prompt caching a koszty.
„Lost in the middle" — kiedy model gubi wątek
Większość inżynierów zna technologiczny limit okna kontekstowego. Rzadziej mówi się o innym, subtelniejszym ograniczeniu: context rot — degradacji jakości odpowiedzi wraz z rosnącą długością kontekstu.
Badania pokazują, że modele mają tendencję do skupiania uwagi na początku i końcu kontekstu. Informacje zawarte w środku długiego dokumentu są w odpowiedziach reprezentowane mniej dokładnie — zjawisko to nazywa się „lost in the middle". Benchmark needle-in-a-haystack (szukanie jednego zdania ukrytego w długim tekście) mierzy wyłącznie zdolność do znalezienia izolowanego faktu. Rzeczywiste zadania produkcyjne są bardziej złożone — wymagają łączenia wielu informacji z różnych miejsc dokumentu i rozumowania wieloetapowego. Przy takich zadaniach degradacja jakości następuje wcześniej i jest wyraźniejsza.
W praktyce oznacza to: jeśli macie 500-stronicowy podręcznik techniczny i pytacie o zależność między sekcją 3 a sekcją 47, model mający całą książkę w kontekście niekoniecznie odpowie lepiej niż model, któremu podaliście tylko dwie odpowiednie sekcje przez RAG. A ten drugi przypadek jest znacznie tańszy.
Kiedy duży kontekst naprawdę pomaga
Mimo tych ograniczeń istnieją scenariusze, w których długi kontekst jest obiektywnie lepszym wyborem. Główne kategorie:
Analiza całego dokumentu z sekwencyjną zależnością. Jeśli chcecie podsumować protokół z trzygodzinnego spotkania, wyciągnąć decyzje z długiego dokumentu prawnego lub przeanalizować obszerny raport techniczny, gdzie wniosek zależy od kontekstu z wstępu — cały dokument w kontekście ma sens. Tu liniowość jest zaletą, nie słabością.
Długie konwersacje z pełną historią. Systemy czatowe z wieloma turami, gdzie każde pytanie zależy od poprzedniej odpowiedzi — obsługa klienta z historią, asystencja techniczna, gdzie jedno rozwiązanie jest dopracowywane przez dziesiątki wymian. Zachowanie całej historii w kontekście jest prostsze niż implementowanie wyrafinowanej pamięci.
Code review lub refaktoryzacja całego repozytorium. Gdy model musi naprawić zależność w wielu plikach jednocześnie, kontekst całego kodu eliminuje niespójności. Dokładnie tak działają nowoczesni agenci do kodowania — Cursor, Claude Code i podobne.
Jedno długie, jednorazowe pytanie. Jeśli przesyłacie 300-stronicową umowę raz w miesiącu i pytacie o klauzule dotyczące odpowiedzialności, ekonomika działa. Jedno wywołanie, jasny wynik, niska częstotliwość — cena jest akceptowalna.
Kiedy RAG jest tańszy i precyzyjniejszy
Większość produkcyjnych systemów LLM w firmach działa inaczej: rozległa baza wiedzy (dokumentacja techniczna, normy ISO, wewnętrzne przepisy, historia zapisów serwisowych), z której korzystają dziesiątki lub setki pracowników dziennie. Tu duży kontekst bez RAG przestaje mieć sens ekonomiczny.
Sytuacje, w których RAG jest właściwszym wyborem:
- Duża liczba wywołań z nakładającymi się źródłami. Jeśli stu operatorów dziennie pyta różne pytania o ten sam podręcznik, RAG wyciągnie tylko odpowiednie fragmenty i zapłacicie za ułamek tokenów.
- Baza rośnie. Okno kontekstowe jest stałe — jeśli Wasza dokumentacja liczy 10 milionów tokenów, nawet okno 1M nie wystarczy. RAG skaluje się wraz z rozmiarem bazy bez zmiany architektury.
- Potrzebujecie dokładnych lokalizacji źródła. RAG zwróci konkretne fragmenty z odniesieniami. Długi kontekst da Wam odpowiedź, ale bez atrybucji do konkretnego akapitu — ważne w środowiskach regulowanych.
- Kluczowa jest niska latencja. Czas do pierwszego tokenu (TTFT) rośnie wraz z długością kontekstu. Połączenie konwersacji w czasie rzeczywistym z wymaganiem poniżej 2 sekund i długiego kontekstu jest trudne do osiągnięcia.
Szczegółowe porównanie obu podejść znajdziecie w artykule RAG vs fine-tuning — podejmowanie decyzji, gdzie omawiamy też scenariusze kombinowane.
Podejście hybrydowe: kontekst + RAG
W praktyce najlepsze systemy produkcyjne nie stosują ani wyłącznie „całego kontekstu", ani „czystego RAG" — używają obu w zależności od sytuacji. Typowa architektura:
- 1.Systemowy prompt i globalne instrukcje — statyczne, cachowane przez prompt caching, tanie przy ponownym odczycie.
- 2.Dynamicznie pobierane fragmenty — odpowiednie ustępy z dokumentacji, dodawane do kontekstu na podstawie zapytania. Typowo 5–20 fragmentów, każdy po 200–500 tokenów.
- 3.Historia konwersacji — ostatnie N wymian, podsumowanie starszej historii jeśli jest potrzebna.
- 4.Cały dokument w kontekście — tylko jeśli dokument jest krótki (poniżej 50K tokenów) i zadanie wymaga całości.
Ta kombinacja utrzymuje efektywny rozmiar kontekstu przy typowych zapytaniach na poziomie 8–32K tokenów, co jest rzędami wielkości tańsze niż 500K+ przy naiwnym „wczytaj wszystko".
Praktyczne podejmowanie decyzji: pytania przed wdrożeniem
Zanim zdecydujecie się na architekturę, odpowiedzcie sobie na te pytania:
- Ile razy dziennie ta sama baza wiedzy będzie używana? Jeśli więcej niż 50 razy, RAG opłaca się ekonomicznie nawet przy wyższych kosztach konfiguracji.
- Czy baza jest większa niż 500K tokenów? Jeśli tak, długi kontekst nie wystarczy i RAG jest jedynym realistycznym wyborem.
- Czy odpowiedź zależy od sekwencyjnego przeczytania całego dokumentu? Jeśli tak, długi kontekst to uzasadniony wybór.
- Jaka jest tolerancja na latencję? Konwersacja w czasie rzeczywistym z wymogiem poniżej 2 sekund i długi kontekst trudno ze sobą pogodzić.
- Potrzebujecie cytowalnych źródeł? RAG da Wam fragment z odniesieniem, duży kontekst nie.
Jeśli na większość odpowiadacie „nie, nie, tak, wysoka, nie" — długi kontekst może być właściwym wyborem. Jeśli przeważa odwrotnie, RAG lub architektura hybrydowa będzie lepsza zarówno ekonomicznie, jak i jakościowo.
Prompt caching jako kompromis
Szczególnym przypadkiem jest sytuacja, gdy macie stosunkowo duży, ale statyczny kontekst — na przykład firmowy przewodnik stylistyczny, rozbudowany systemowy prompt z instrukcjami lub dokumentację referencyjną. Tu prompt caching oferuje atrakcyjną drogę środka:
- Pierwsze wywołanie: płacicie pełną cenę za zapis do cache (125–200 % zwykłej ceny wejściowej).
- Każde kolejne wywołanie w oknie TTL (5 minut lub 1 godzina u Anthropic): płacicie 10 % ceny tokenu wejściowego za część cachowaną.
- Przy dziesięciokrotnie powtórzonym statycznym prefiksie całkowite koszty są znacznie niższe niż bez cache.
Typowe oszczędności w produkcji przy odpowiednim workloadzie sięgają 50–70 % kosztów tokenów wejściowych. Nacisk na „odpowiedni workload" — jeśli każdy użytkownik przychodzi z zupełnie innym długim promptem, cache hit rate będzie bliski zera, a zapis do cache wręcz podroży całość.
Co to oznacza przy wyborze sprzętu i frameworku do serwowania
Jeśli decydujecie się na realnie długie konteksty w wdrożeniu on-prem, ważne jest zrozumienie konsekwencji sprzętowych.
KV cache dla długiego kontekstu potrzebuje dużo dodatkowego VRAM poza samymi wagami modelu. Dla modelu 70B przy kontekście 128K sama KV cache wynosi około 40 GB — do tego dochodzi ~140–168 GB dla wag modelu w FP16 (lub ~35–40 GB dla kwantyzacji Q4_K_M). To szybko przekracza pojemność jednej GPU i wymaga konfiguracji multi-GPU lub tensor parallelism.
Po stronie frameworków do serwowania: vLLM i SGLang implementują PagedAttention i RadixAttention — techniki, które zmniejszają fragmentację KV cache i umożliwiają efektywniejsze współdzielenie między równolegle przetwarzanymi żądaniami. Ollama świetnie sprawdza się na desktopie i w eksperymentach, ale do produkcyjnego serwowania wielu użytkowników z długimi kontekstami wydajność jest rzędami wielkości niższa. Więcej o porównaniu frameworków znajdziecie w artykule vLLM vs SGLang vs Ollama.
Grouped Query Attention (GQA), który implementuje większość nowoczesnych modeli, znacząco zmniejsza rozmiar KV cache w porównaniu z klasycznym multi-head attention — przy wyborze modelu do długiego kontekstu warto zatem sprawdzić, czy GQA jest obsługiwane.
Najczęstsze pytania
Czy milion tokenów całkowicie zastąpi RAG?
Dla większości systemów produkcyjnych nie. Ekonomika nie działa: 1M tokenów przy każdym wywołaniu jest rzędami wielkości droższe niż retrieval odpowiednich fragmentów. Dodatkowo degradacja jakości przy bardzo długim kontekście jest realna. Duży kontekst ma sens przy jednorazowych analizach długich dokumentów — nie w systemie, w którym ta sama baza jest odpytywana setki razy dziennie.
Jak bardzo spada jakość odpowiedzi przy długim kontekście?
Zależy od zadania. Przy prostym wyszukiwaniu jednego faktu (needle-in-a-haystack) nowoczesne modele są wiarygodne nawet przy 1M tokenów. Przy bardziej złożonych zadaniach — łączeniu informacji z wielu miejsc, rozumowaniu wieloetapowym — dokładność spada wyraźniej wraz z rosnącą długością. Zjawisko „lost in the middle" jest eksperymentalnie udokumentowane i należy je uwzględniać przy projektowaniu architektury.
Czy prompt caching jest zawsze opłacalny?
Nie. Jest opłacalny przy statycznym lub rzadko zmieniającym się prefiksie, który jest odczytywany wielokrotnie w oknie TTL (5 minut lub 1 godzina). Tokeny zapisu do cache są droższe niż zwykłe tokeny wejściowe (1,25–2× u Anthropic). Jeśli każdy użytkownik przynosi unikalny długi kontekst lub częstotliwość wywołań jest niska, cache hit rate będzie niski, a całkowite koszty mogą być wyższe niż bez cachowania.
Jakiego sprzętu potrzebuję do lokalnego wdrożenia z długim kontekstem?
Zależy od modelu i długości. Jako liczba orientacyjna: dla modelu 70B przy 32K tokenach potrzebujecie łącznie około 50–80 GB VRAM (wagi + KV cache przy kwantyzacji Q4). Przy 128K tokenach sama KV cache wynosi około 40 GB (dla 70B, FP16 KV). Dla modelu 7B sytuacja jest korzystniejsza — przy 128K tokenach poradzicie sobie na high-end GPU z 40–80 GB VRAM. Apple M-series ze zunifikowaną pamięcią (do 128–192 GB w M5 Ultra) to interesująca alternatywa on-prem dla 70B z długim kontekstem.
Czy te same zasady dotyczą modeli open-weight on-prem i chmurowego API?
Ekonomika jest inna, zasady są takie same. W chmurowym API płacicie bezpośrednio za tokeny. On-prem płacicie za sprzęt (CAPEX) i energię (OPEX) — ale KV cache, a tym samym wymagania pamięciowe GPU, rosną w ten sam sposób. Decyzja „long context vs RAG" nie sprowadza się wyłącznie do ceny tokenów, lecz do całościowej architektury sprzętu, rozmiaru batcha i latencji.
*Jeśli pracujecie nad architekturą systemu LLM i nie jesteście pewni, gdzie dla Was leży granica między długim kontekstem, prompt cachingiem a RAG, chętnie przyjrzymy się Waszemu konkretnemu przypadkowi w MP Industrial Solutions — wnosimy doświadczenia z wdrożeń przemysłowych, gdzie liczy się każde euro kosztów operacyjnych.*