Context Caching: Co To Jest Cache Kontekstu w AI?
Context caching (cache kontekstu, po stronie Anthropic nazywany prompt caching) to funkcja API dużych modeli językowych, która zapamiętuje część zapytania – system prompt, załączony dokument albo wcześniejsze tury rozmowy – po stronie dostawcy, dzięki czemu kolejne zapytania z tym samym początkiem (prefiksem) kosztują nawet o 90% mniej i odpowiadają szybciej. To jedna z najbardziej opłacalnych optymalizacji, jakie można wdrożyć przy pracy z API OpenAI, Anthropic czy Google – szczególnie w agentach AI i systemach RAG, gdzie ten sam duży kontekst wraca w każdym zapytaniu.
Poziom: intermediate/advanced (dla developerów i osób budujących produkty na API AI). Sekcje wprowadzające są przystępne dla każdego, kto korzysta z API i chce zrozumieć, dlaczego jego rachunek wygląda tak, a nie inaczej.
Czym jest context caching?
Context caching to mechanizm, w którym dostawca modelu przechowuje obliczony stan (aktywacje) dla powtarzalnej części zapytania i wykorzystuje go ponownie zamiast liczyć wszystko od zera. W praktyce oznacza to, że system prompt, definicje narzędzi, załączony dokument czy historia rozmowy – jeśli powtarzają się bajt w bajt między zapytaniami – trafiają do cache’u i są rozliczane w niższej stawce.
Google wprowadziło context caching dla Gemini API 27 czerwca 2024 roku, najpierw dla Gemini 1.5 Pro i 1.5 Flash, a później rozszerzyło je na kolejne generacje modeli. Anthropic udostępnia analogiczną funkcję pod nazwą prompt caching, ustawianą parametrem cache_control typu „ephemeral”, a OpenAI dodało automatyczne cachowanie promptów dla GPT-4o i modeli o-series 1 października 2024 roku. Wszyscy trzej najwięksi dostawcy cache’ują dokładny, identyczny prefiks zapytania i rozliczają trafienia w cache’u po 10-50% standardowej stawki za tokeny wejściowe – różnią się jednak zachowaniem TTL, minimalnymi progami tokenów i tym, czy cachowanie wymaga jawnego włączenia.
Dlaczego dostawcy API w ogóle to oferują?
Architektura transformera liczy uwagę (self-attention) na całym wejściu przy każdym przebiegu, więc koszt inferencji rośnie mniej więcej liniowo z długością promptu w fazie prefill. W miarę jak workloady produkcyjne przesunęły się w stronę długich, współdzielonych system promptów, odpowiedzi opartych na dokumentach (RAG) i wieloturowych agentów, coraz większa część tokenów wejściowych zaczęła się powtarzać dosłownie między zapytaniami. Bot obsługi klienta wysyła ten sam 8-tysięczny dokument z polityką firmy przy każdym pytaniu użytkownika; asystent do kodu dołącza te same pliki projektu do każdej tury długiej sesji.
Wewnętrzna optymalizacja, która pozwala pojedynczemu krokowi dekodowania ponownie użyć już obliczonych tensorów klucz-wartość, to KV cache – trzymany w pamięci GPU i kasowany po zakończeniu zapytania. Context caching to wyższy poziom tej samej idei, widoczny dla klienta: dostawca utrzymuje stan obliczonego prefiksu między zapytaniami, pobiera jednorazową opłatę za zapis, a potem serwuje trafienia w cache’u po głęboko obniżonej cenie. Mechanizm ten jest ściśle powiązany z architekturą, o której pisaliśmy w artykule o transformerach i architekturze MoE – to właśnie sposób liczenia uwagi w tej architekturze sprawia, że cache’owanie się w ogóle opłaca.
Context caching a KV cache – to nie to samo
To rozróżnienie myli najwięcej osób. KV cache to wewnętrzna optymalizacja pojedynczego zapytania: przechowuje tensory klucz-wartość wyliczone przez każdą głowę uwagi w każdej warstwie transformera dla już przetworzonych tokenów, aby faza dekodowania (generowania kolejnych tokenów) nie musiała ponownie przeliczać wektorów uwagi dla tokenów, które model już przetworzył w fazie prefill. Jest alokowany w pamięci GPU na start zapytania, rośnie liniowo z długością sekwencji i jest zwalniany, gdy zapytanie się kończy.
Context caching to natomiast trwała, widoczna dla klienta abstrakcja działająca ponad wieloma zapytaniami. Gdy dostawca mówi, że serwuje trafienie w cache’u, zwykle materializuje lub szybko odtwarza te same tensory KV, które model musiałby policzyć podczas prefillu – ale robi to z zapisanej migawki, a nie licząc je od nowa z tokenów wejściowych.
| Cecha | KV cache | Context caching |
|---|---|---|
| Widoczny dla developera | Nie (wewnętrzny) | Tak (billing, pola usage) |
| Trwa między zapytaniami | Nie | Tak |
| Klucz cache’u | Pozycja w bieżącym zapytaniu | Hash prefiksu wejścia |
| Czas życia | Pojedyncza inferencja | Minuty do 24 godzin |
| Redukcja kosztu | Tylko opóźnienie | Opóźnienie i cena w dolarach |
| Miejsce przechowywania | VRAM GPU | Infrastruktura dostawcy |
Jak działa context caching krok po kroku
Każda komercyjna implementacja używa klucza cache’u opartego o dokładny prefiks: dostawca hashuje początkowe bajty zserializowanego zapytania (łącznie z system promptem, definicjami narzędzi, załączonymi plikami i wcześniejszymi wiadomościami) i sprawdza, czy istnieje wcześniej obliczony stan aktywacji pod tym samym hashem. Każda zmiana w prefiksie – inna kolejność narzędzi, zmieniony jeden wyraz w system message – unieważnia cache. Warto pamiętać, że wystarczy naprawdę drobna różnica: nawet jedna dodatkowa spacja albo zmiana kolejności ról w strukturze JSON-a rozbija cache tak samo skutecznie, jak zupełnie inny prompt.
Ponieważ dopasowanie jest czysto leksykalne, prompty trzeba projektować tak, żeby treść zmienna (pytanie użytkownika, dynamicznie pobrane fragmenty z RAG) trafiała na koniec zapytania, a treść stabilna (instrukcje, przykłady, duże załączone dokumenty) – na początek. Google jednoznacznie rekomenduje taki układ, radząc umieszczać duże i wspólne treści na początku promptu, a to, co zmienia się z każdym zapytaniem – na końcu.
Przy trafieniu w cache (cache hit) klient płaci obniżoną stawkę tylko za tę część promptu, a model musi jedynie rozszerzyć zapamiętany stan o nowy fragment zapytania. Przy chybieniu cache’u (cache miss) model przetwarza wszystko w standardowy sposób, a dostawca zapisuje wynikowe aktywacje prefiksu do ponownego użycia – klient płaci wtedy opłatę za zapis, która jest albo równa standardowej stawce (Google explicit, OpenAI), albo jej wielokrotnością (Anthropic: zapis na 5 minut kosztuje 1,25x podstawowej stawki, zapis na godzinę – 2x). Anthropic dodatkowo odświeża TTL przy każdym trafieniu, więc stale aktywny cache może żyć znacznie dłużej niż jego nominalny czas życia.
Czas życia cache’u (TTL) u każdego dostawcy
TTL (time to live) to maksymalny czas, przez jaki dostawca obiecuje trzymać wpis w cache’u, zanim go usunie. Trzy główne implementacje różnią się tu wyraźnie:
| Dostawca | Domyślny TTL | Konfigurowalny | Maksimum |
|---|---|---|---|
| Google Gemini (explicit) | 1 godzina | Tak, ustawiany przez developera | Do limitu kontekstu modelu, rozliczane wg czasu przechowywania |
| Google Gemini (implicit, 2.5+) | Do 24 godzin, automatycznie | Nie | 24 godziny |
| OpenAI | 5-10 minut bezczynności | Nie (do GPT-5.1) | 1 godzina w pamięci; 24 godziny z prompt_cache_retention="24h" na GPT-5.1 i nowszych |
| Anthropic ephemeral 5m | 5 minut, odświeżane przy trafieniu | Tak, wybór TTL | 5 minut między trafieniami |
| Anthropic ephemeral 1h | 1 godzina | Tak, przez "ttl": "1h" | 1 godzina między trafieniami |
Google Gemini nalicza dodatkowo godzinową opłatę za przechowywanie cache’u explicit: około 1,00 USD za milion tokenów na godzinę dla modeli z rodziny Flash i do 4,50 USD za milion tokenów na godzinę dla modeli Pro. OpenAI i Anthropic nie pobierają osobnej opłaty za przechowywanie – odzyskują koszt przez mnożnik zapisu.
Minimalny próg tokenów
Wszystkie trzy implementacje odmawiają cache’owania zapytań poniżej pewnego progu wielkości – poniżej niego narzut na obsługę cache’u przewyższa oszczędności. Aktualne minima:
- Google Gemini: różnią się w zależności od modelu, zwykle 1024-4096 tokenów w zależności od wersji (np. wyższy próg dla najnowszych modeli Pro i Flash niż dla wcześniejszych generacji Flash).
- OpenAI: 1024 tokeny, z cache’owanym prefiksem rosnącym w krokach po 128 tokenów powyżej tego progu.
- Anthropic: 512 tokenów dla najnowszych, najlżejszych modeli; 1024 tokeny dla większości modeli Sonnet i Opus w bieżącej generacji; wyższe progi (2048-4096) dla starszych lub najcięższych modeli.
W praktyce próg 1024 tokenów osiąga się bardzo szybko – dla modeli z rodziny Claude Sonnet wystarczy średniej wielkości system prompt plus kilka definicji narzędzi, żeby go przekroczyć, więc w realnych aplikacjach cachowanie włącza się niemal zawsze, gdy tylko projektujemy prompt z myślą o tym progu.
Zapytania poniżej progu są przetwarzane bez cache’owania, a dostawca zwraca zero zcache’owanych tokenów w polu usage – bez błędu. Warto to sprawdzić dla konkretnego modelu przed projektowaniem architektury promptów, bo progi zmieniają się między wersjami.
Ile kosztuje context caching w praktyce
Poniżej orientacyjne stawki, potwierdzone w dokumentacji dostawców w połowie 2026 roku. Dokładne ceny warto zawsze zweryfikować na oficjalnej stronie cennika przed wdrożeniem produkcyjnym, bo zmieniają się kwartalnie – podobnie jak przy każdym innym API opisanym w naszym artykule o cenach ChatGPT Plus i API.
| Dostawca | Zapis do cache’u | Odczyt z cache’u (trafienie) | Opłata za przechowywanie |
|---|---|---|---|
| Google Gemini | Cena standardowa (explicit i implicit) | ok. 10% ceny standardowej (90% zniżki) | 1,00-4,50 USD / mln tokenów / godzinę (tylko explicit) |
| OpenAI | Brak dodatkowej opłaty | 50% ceny standardowej (starsze modele), do 90% zniżki przy 24h retention na nowszych | Brak |
| Anthropic (TTL 5 min) | 1,25x ceny standardowej | 0,1x ceny standardowej (90% zniżki) | Brak |
| Anthropic (TTL 1h) | 2x ceny standardowej | 0,1x ceny standardowej (90% zniżki) | Brak |
Warto zauważyć dwa różne modele biznesowe. Google pobiera cenę bliską standardowej przy zapisie, ale odzyskuje koszt operacyjny przez opłatę godzinową za przechowywanie. Anthropic nie liczy przechowywania, tylko podnosi mnożnik zapisu – różnica między TTL 5-minutowym a godzinnym to kluczowy kompromis dla developera optymalizującego architekturę pod rzadkie, ale regularnie powtarzające się zapytania. OpenAI nie pobiera nic za zapis i po prostu obniża cenę odczytu, polegając na oportunistycznym dopasowaniu prefiksu wobec ostatniego ruchu.
Dla workloadu, który wysyła 100 000-tokenowy współdzielony prompt, a potem przez 30 minut odpytuje go raz na sekundę krótkim pytaniem, matematyka faworyzuje wszystkie trzy cache’e o rząd wielkości względem cen bez cachowania. Przykładowo, przy modelu Anthropic z TTL godzinnym: pierwsze wywołanie kosztuje 2x standardowej stawki, a każde kolejne z 1799 wywołań w tej godzinie – 0,1x, co daje łączny koszt równoważny około 182 zapytaniom bez cachowania zamiast 1800.
Jak wdrożyć context caching w praktyce
Rozmowa wieloturowa (chat). Naturalną strategią jest umieszczenie punktu cache’owania po ostatniej wiadomości asystenta. Na Anthropic to tryb „automatic caching” – biblioteka lub middleware przesuwa punkt cache’owania co turę, tak żeby cała historia do (ale nie włącznie z) nową wiadomością użytkownika trafiała w cache. Na OpenAI dzieje się to automatycznie: każda nowa tura współdzieli prefiks z poprzednią i wywołuje zniżkę bez zmian w kodzie.
Dokumenty i RAG. Dla systemów RAG (retrieval-augmented generation), które dołączają ten sam korpus lub niewielki zbiór dokumentów do wielu zapytań, największe oszczędności dają cache’owanie payloadu dokumentów. Rekomendowany wzorzec: dokumenty na samej górze promptu, zaraz po system message; pobrane fragmenty (które zmieniają się co zapytanie) – poniżej; pytanie użytkownika – na samym końcu. Więcej o kompromisach między RAG a dostrajaniem modelu piszemy w artykule RAG kontra dostrajanie modelu.
Agenci AI i tool use. Pętle agentowe wywołują model wielokrotnie w ramach jednego zadania, często ze stabilnym system promptem, definicjami narzędzi i wcześniej widzianymi obserwacjami środowiska. Rozszerzony TTL Anthropic (1 godzina) i 24-godzinne przechowywanie OpenAI powstały właśnie z myślą o takich zastosowaniach – długo działający agent programistyczny, wywołujący model dziesiątki razy na godzinę, może utrzymać ciepły kontekst projektu bez płacenia pełnej ceny za każde wywołanie. To szczególnie istotne przy budowie systemów wieloagentowych opisanych w naszym poradniku o architekturze CrewAI oraz przy integracjach przez Model Context Protocol, gdzie definicje narzędzi i zasoby wracają w każdym wywołaniu.
Przykład włączenia cache’owania po stronie Anthropic (Claude API, jak opisujemy w naszym przewodniku po Claude 4.6 i planach Claude Pro):
{
„system”: [
{
„type”: „text”,
„text”: „Długi, stabilny system prompt lub dokument…”,
„cache_control”: {„type”: „ephemeral”}
}
],
„messages”: […]
}
Ograniczenia i pułapki context cachingu
Zależność od dokładnego prefiksu. Ponieważ klucz cache’u to bajt w bajt zgodny prefiks, nawet drobne różnice (zaktualizowany znacznik czasu w system prompcie, przestawione definicje narzędzi, zmiana białych znaków) unieważniają cache. Systemy produkcyjne muszą „zamrozić” wiodącą część promptu – wprowadzenie zmienności powyżej punktu cache’owania niweczy cachowanie.
Izolacja między klientami. Cache’e są izolowane per organizacja lub projekt. Różne organizacje nigdy nie współdzielą cache’u, nawet jeśli używają identycznych promptów – w niektórych implementacjach izolacja schodzi nawet do poziomu poszczególnych workspace’ów w ramach jednej organizacji.
Best-effort, nie gwarancja. Wszyscy trzej dostawcy opisują cachowanie jako działanie najlepszego wysiłku (best-effort). Krótsze prompty nie mogą być cache’owane, nawet jeśli oznaczono je parametrem cache_control – takie zapytania są po prostu przetwarzane bez cachowania, bez błędu.
Koszt przechowywania. Explicit cache Google’a nalicza godzinną opłatę za przechowywanie, która przy dużych cache’ach trzymanych długo może przewyższyć oszczędności z trafień. Analiza break-even pokazuje, że milion tokenów w cache’u trzymany godzinę na droższym modelu Pro może kosztować kilka dolarów samego przechowywania – odzyskuje się to dopiero po kilku tysiącach odczytów.
Nawał ruchu (cache stampede). Przy bardzo dużym ruchu na ten sam klucz prefiksu zapytania mogą trafiać na serwery bez ciepłego cache’u, co podnosi wskaźnik chybień. Aplikacje o wysokim ruchu często przypinają zapytania do jednego wdrożenia lub używają nagłówków sticky routing, żeby to ograniczyć.
Context caching czy prompt caching – to samo?
Terminy „context caching” i „prompt caching” są w branży w dużej mierze wymienne. Google używa nazwy „context caching”, Anthropic – „prompt caching”, a OpenAI – „Prompt Caching”. Wszystkie trzy opisują ten sam mechanizm bazowy: cache’owanie zserializowanego prefiksu wejścia po stronie dostawcy, tak by kolejne zapytania z tym samym prefiksem płaciły mniej.
Różnice leżą w szczegółach implementacji: Anthropic pozwala na do czterech punktów cache’owania w jednym zapytaniu (co umożliwia zagnieżdżone cache’e z różnymi TTL), podczas gdy explicit cache Google’a i automatyczny cache OpenAI obsługują tylko jeden prefiks na zapytanie. OpenAI jest w pełni automatyczny, Google oferuje zarówno tryb automatyczny (implicit), jak i ręczny (explicit), a Anthropic wymaga jawnego oznaczenia parametrem cache_control.
FAQ – najczęstsze pytania o context caching
Czy context caching to to samo co KV cache?
Nie. KV cache to wewnętrzny mechanizm pojedynczego zapytania, trzymany w pamięci GPU i kasowany po jego zakończeniu. Context caching to trwała, widoczna dla klienta funkcja billingowa, działająca ponad wieloma zapytaniami i oparta na tej samej idei co KV cache.
Ile można zaoszczędzić dzięki context cachingowi?
Typowo 50-90% kosztu tokenów wejściowych na cache’owanej części zapytania, w zależności od dostawcy i wybranego TTL. Google i Anthropic oferują zwykle 90% zniżki na trafienia w cache’u, OpenAI – 50% na starszych modelach i wyższe wartości przy dłuższym przechowywaniu na nowszych.
Czy muszę zmieniać kod, żeby korzystać z context cachingu?
Zależy od dostawcy. Na OpenAI cachowanie jest w pełni automatyczne – nie trzeba nic zmieniać. Na Google działa zarówno tryb automatyczny (implicit), jak i ręczny (explicit) wymagający utworzenia obiektu cache. Na Anthropic trzeba jawnie dodać parametr cache_control do treści, którą chcemy cache’ować.
Kiedy context caching się nie opłaca?
Przy krótkich promptach (poniżej minimalnego progu tokenów), przy bardzo niskim wolumenie zapytań (gdzie opłata za zapis rzadko się zwraca) oraz gdy treść promptu zmienia się przy każdym zapytaniu, więc nie ma stabilnego prefiksu do cache’owania.
Czy context caching wpływa na prywatność danych?
Cache’e są izolowane per organizacja (a u niektórych dostawców nawet per workspace), więc różni klienci nigdy nie współdzielą cache’u. Warto jednak sprawdzić politykę retencji danych konkretnego dostawcy, jeśli pracujemy z danymi wrażliwymi lub w trybie zero data retention.
