W większości produkcyjnych aplikacji LLM prompt systemowy, dokumentacja kontekstowa lub historia konwersacji stanowią większość tekstu wejściowego przy każdym wywołaniu. Jeśli prompt systemowy liczy tysiąc tokenów, a dziennie obsługujecie dziesięć tysięcy zapytań, płacicie za dziesięć milionów tokenów — z których większość to za każdym razem ten sam tekst. Prompt caching rozwiązuje ten problem na poziomie infrastruktury: dostawca zapisuje reprezentację KV powtarzających się prefiksów i przy kolejnym wywołaniu zamiast przeliczać je od nowa, po prostu je odczytuje.
Ten artykuł wyjaśni, jak prompt caching działa pod maską, w jakich warunkach realnie obniży cenę i latencję, co konkretnie cachować i kiedy caching nie pomoże — albo wręcz dołoży kosztów. Wiąże się to też z projektowaniem promptów, które dobrze się cachują — kwestią, którą wiele zespołów pomija.
Jak działa prompt caching
Kiedy wysyłacie request do API LLM, model dla każdego tokenu wejściowego oblicza tzw. KV cache (wektory klucz-wartość) — to fundament mechanizmu self-attention, przez który model ocenia zależności między tokenami. Ten obliczenie nie jest bezpłatne: to praca GPU, która bezpośrednio wpływa na cenę i czas do pierwszego tokenu (TTFT).
Prompt caching (zwany też context caching lub prefix caching) polega na tym: jeśli początek promptu — prefiks — jest taki sam w wielu wywołaniach, dostawca oblicza jego reprezentację KV raz, zapisuje ją na serwerze i przy kolejnych requestach po prostu ją wczytuje zamiast przeliczać. Z punktu widzenia wywołującego jest to przezroczyste — odpowiedzi są tak samo poprawne, tylko tańsze i szybsze.
Co to oznacza w liczbach:
- U Anthropic: odczyt z cache = 10% zwykłej ceny tokenu wejściowego (oszczędność 90%); zapis do cache = 125–200% zwykłej ceny tokenu wejściowego (nieznaczne przepłacenie przy pierwszym zapisie)
- U OpenAI: automatyczne, odczyt z cache = 50% zwykłej ceny; bez dodatkowego kodu po stronie wywołującego
- Realna oszczędność w produkcji: typowo 50–70% łącznych kosztów tokenów wejściowych przy workloadzie z długimi, powtarzającymi się prefiksami
Ekonomia wygląda więc tak: pierwsze wywołanie za cache write zapłacicie trochę więcej, ale każdy kolejny odczyt tego samego prefiksu jest znacząco tańszy. Zysk pojawia się od drugiego odczytu; przy tysiącach wywołań dziennie oszczędności są istotne.
TTL i spójność prefiksu
Zakeszowany prefiks nie trzyma się wiecznie. Anthropic oferuje TTL (time-to-live) 5 minut lub 1 godzinę — po upływie cache się unieważnia i przy kolejnym wywołaniu prefiks jest przeliczany od nowa (ponowny cache write). OpenAI zarządza TTL automatycznie, bez konieczności jawnego ustawiania.
Z tego wynikają dwa praktyczne wnioski. Po pierwsze: jeśli masz workload, gdzie requesty z tym samym prefiksem przychodzą w krótkich odstępach (na przykład w ciągu sekund lub minut), caching działa dobrze. Jeśli requesty są rozłożone przez cały dzień z godzinnymi przerwami i używacie 5-minutowego TTL, cache będzie się regularnie unieważniać. Po drugie: prefiks musi być identyczny co do bajtu. Nawet drobna zmiana (inna spacja, inaczej sformatowana data w prompcie systemowym) unieważnia całą zakeszowaną reprezentację i wywołuje nowy cache write.
Co ma sens cachować
Nie każdy tekst w prompcie warto cachować. Dobór wynika z prostej logiki: cachować ma sens to, co jest długie, statyczne i wielokrotnie używane.
Prompt systemowy. Najbardziej oczywisty kandydat. Jeśli macie 500–2000 tokenów instrukcji systemowych (rola, kontekst, reguły zachowania, przykłady few-shot), w większości aplikacji nie zmieniają się wcale lub rzadko. Umieśćcie je jako stały prefiks na początku promptu — caching pokryje je automatycznie.
Współdzielone dokumenty i normy. Jeśli każdy request zawiera ten sam podręcznik techniczny, normę ISO, regulaminy firmowe lub dokument prawny jako kontekst referencyjny, to idealny kandydat. Widzieliśmy wdrożenia, gdzie 300-stronicowa dokumentacja techniczna jest wstawiana do każdego wywołania chatbota obsługi klienta — caching obniżył tam koszty o ponad 80%.
Długa historia konwersacji. W chatach wieloturowych aplikacja wysyła całą dotychczasową historię z każdym nowym requestem. Starsza część historii się nie zmienia — to rosnący, stabilny prefiks. Caching tu działa, o ile aplikacja spójnie formatuje konwersację i nie przestawia kolejności wiadomości.
Przykłady few-shot. Jeśli w prompcie systemowym używacie kilku długich przykładów wejście–wyjście (tzw. few-shot prompting), też są statyczne i powtarzalne. Włączcie je do zakeszowanego prefiksu.
Czego natomiast cachować nie warto:
- Krótkich lub jednorazowych promptów — za cache write zapłacicie więcej, ale nigdy nie wyciągniecie zysku
- Promptów, gdzie każdy request różni się od samego początku (np. generowanie zmiennych raportów bez wspólnego prefiksu)
- Systemów z niespójnym formatowaniem — przypadkowa zmiana kolejności parametrów w prompcie systemowym wystarczy, żeby unieważnić cache
Jak projektować prompty pod caching
Jedno z najczęstszych przeoczęń, na które trafiamy przy przeglądzie istniejących aplikacji: zespoły włączają caching, ale struktura promptu nie jest zaprojektowana tak, żeby go efektywnie wykorzystywać.
Podstawowa zasada: statyczne przed dynamicznym. Caching obejmuje prefiks — początek promptu. Dlatego wszystko, co zmienia się per-request (konkretne pytanie użytkownika, zmienne parametry, bieżąca data), musi być na końcu promptu. Jeśli wstawimy dynamiczny element w środku statycznego kontekstu, prefiks zmieni się przy każdym wywołaniu i caching nie zadziała.
Przykład złej kolejności:
Prompt systemowy (statyczny)
↓
Bieżąca data i nazwa użytkownika (dynamiczne — zmienia się przy każdym requeście)
↓
Podręcznik techniczny (statyczny, 800 tokenów)
↓
Pytanie użytkownika (dynamiczne)W tym przykładzie dynamiczny element w środku unieważni caching dla całego podręcznika technicznego poniżej.
Właściwa kolejność:
Prompt systemowy (statyczny)
↓
Podręcznik techniczny (statyczny, 800 tokenów)
↓
Bieżąca data i nazwa użytkownika (dynamiczne)
↓
Pytanie użytkownika (dynamiczne)Blok statyczny tworzy teraz spójny prefiks — dostawca go keszuje, a elementy dynamiczne nie mają na niego wpływu.
Stabilne formatowanie. Jeśli prompt systemowy jest generowany przez kod, unikajcie wstawiania zmiennych wartości (timestamp, wersja) bezpośrednio do statycznej części. Zamiast Aktualna wersja systemu: 2.4.1 (wdrożona 2026-03-20) użyjcie Aktualna wersja systemu: {version} i wstawcie wartość do części dynamicznej lub, lepiej, w wiadomości użytkownika.
Na on-prem (vLLM, SGLang) obowiązują te same zasady. vLLM i SGLang implementują prefix caching własną drogą — SGLang przez RadixAttention (drzewo LRU z keszami KV), vLLM przez PagedAttention z blokami świadomymi prefiksu. Oba frameworki automatycznie rozpoznają powtarzające się prefiksy i nie przeliczają ich ponownie. Szczegóły się różnią, ale zasada projektowania — statyczne przed dynamicznym — jest taka sama. Więcej o wyborze frameworku do serwowania modeli znajdziecie w artykule vLLM vs SGLang vs Ollama.
Kiedy caching bardzo pomaga — a kiedy nie
Prosty test: policzcie, jaki procent tokenów wejściowych stanowi powtarzający się, statyczny prefiks. Jeśli powyżej 50%, caching jest prawdopodobnie sensowną inwestycją. Jeśli każdy request jest unikalny, caching nie pomoże.
Scenariusze z wysoką oszczędnością:
- RAG z długim kontekstem. Aplikacje, które przy każdym wywołaniu wstawiają tę samą współdzieloną dokumentację jako kontekst (regulaminy firmowe, instrukcje, normy). Zakeszowany kontekst jest wczytywany za 10% ceny.
- Obsługa klienta z długimi promptami systemowymi. Typowy produkcyjny chatbot obsługi klienta ma prompt systemowy liczący 500–1500 tokenów opisujący produkt, zasady, ton i przykłady. Przy tysiącach wywołań dziennie oszczędności są istotne.
- Wieloturowi agenci z narastającą historią. Sesje konwersacyjne, gdzie historia jest zapisywana do kontekstu. Starsza część historii staje się stabilnym prefiksem — caching rośnie tu organicznie z długością konwersacji. Bezpośrednio wiąże się to z zarządzaniem kosztami agenta AI w produkcji.
- Przetwarzanie wsadowe dokumentów ze wspólnymi instrukcjami. Jeśli przetwarzacie tysiące faktur, protokołów serwisowych lub zamówień z tymi samymi instrukcjami ekstrakcji, instrukcje są keszowane i płacicie tylko za same dokumenty.
Scenariusze z niską lub zerową oszczędnością:
- Generatywne zadania jednorazowe. Napisz mi adnotację do tego wideo, przetłumacz ten tekst, wygeneruj raport — każdy request jest unikalny, łącznie z częścią systemową. Za cache write zapłacicie extra, ale nigdy tego nie odrobicie.
- Workload o niskim wolumenie. Jeśli aplikacja wykonuje sto wywołań dziennie, oszczędności bezwzględne są niewielkie. Nakład na implementację (refaktoryzacja promptów, monitorowanie hit rate) może się nie zwrócić.
- Krótkie prompty systemowe. Jeśli prompt systemowy liczy 50 tokenów, minimalna długość wymagana do cachowania (Anthropic wymaga prefiksu co najmniej 1024 tokenów) w ogóle nie jest spełniona.
Mierzenie efektywności cachowania
Wdrożenie bez pomiaru to nawigacja na ślepo. Trzy metryki do śledzenia:
Cache hit rate. Stosunek requestów, w których prefiks został wczytany z cache, do łącznej liczby requestów. Anthropic zwraca w odpowiedzi API pola cache_read_input_tokens i cache_creation_input_tokens. OpenAI zwraca cached_tokens w obiekcie usage. Cel: przy poprawnie ustrukturyzowanych promptach hit rate powinien wynosić 80–95% przy stabilnym workloadzie.
Średnia liczba tokenów wejściowych na request. Jeśli caching działa, efektywny koszt tokenów wejściowych spada — tokeny odczytane z cache są naliczane taniej. Śledźcie ruchomą średnią kosztu wejścia na request w czasie.
TTFT (Time to First Token). Zakeszowany prefiks eliminuje jego przeliczanie, co skraca TTFT. Jeśli widzicie bimodalne rozkład latencji (część requestów szybsza, część wolniejsza), to prawdopodobnie efekt różnicy między cache hit a cache miss.
Włączcie te metryki do swojego pipeline'u obserwowalności — na przykład przez strukturyzowane logi lub monitorowanie opisane w artykule o agent observability i tracingu.
Porównanie dostawców chmurowych
Podejścia różnią się też w szczegółach implementacji, co wpływa na sposób projektowania cachingu.
Anthropic (Claude): Jawne — w requeście musicie oznaczyć bloki do keszowania parametrem cache_control. Daje wam kontrolę nad tym, co dokładnie jest keszowane. TTL 5 minut lub 1 godzina (do wyboru). Minimum dla keszowania: 1024 tokeny. Cache write to 125–200% ceny zwykłego tokenu wejściowego; cache read to 10%.
OpenAI (GPT): Niejawne — automatyczne, bez dodatkowego kodu. Dostawca sam rozpoznaje powtarzające się prefiksy i keszuje je. Cache read = 50% ceny tokenu wejściowego. Prostsze w uruchomieniu, mniej kontroli nad tym, co jest keszowane.
Google (Gemini): Jawny context caching przez API, podobnie jak Anthropic. Dłuższy TTL — od godzin do dni. Odpowiednie dla bardzo stabilnych, długich kontekstów (całe instrukcje obsługi, bazy kodu).
On-prem (vLLM, SGLang): Prefix caching jest wbudowany i działa automatycznie przy powtarzających się prefiksach. Nie płacicie extra za write — koszty obliczeniowe są wasze, ale przy powtarzających się prefiksach framework serwujący oszczędza czas GPU, co zwiększa throughput i obniża latencję. Ta zaleta jest kluczowa przy prywatnym wdrożeniu na własnym sprzęcie.
Najczęstsze pytania
Czy prompt caching jest bezpieczny — czy moje dane zostają na serwerach dostawcy?
Tak, zakeszowana reprezentacja KV pozostaje na serwerach dostawcy przez czas TTL. Dla większości firm nie stanowi to problemu — wywołania API i tak tam trafiają. Dla organizacji ze ścisłymi wymaganiami dotyczącymi rezydencji danych (szpitale, banki, branże regulowane) lepszym wyborem jest serwowanie on-prem z vLLM lub SGLang, gdzie cache pozostaje w pełni pod waszą kontrolą. Więcej w artykule o on-prem LLM dla branż regulowanych.
Czy caching może negatywnie wpłynąć na jakość odpowiedzi?
Nie — caching wpływa wyłącznie na to, jak szybko wektory KV prefiksu trafiają do pamięci, nie na to, jakie mają wartości. Model otrzymuje identyczny kontekst bez względu na to, czy prefiks był przeliczany od nowa, czy wczytany z cache. Odpowiedzi są takie same.
Czy caching opłaca się dla małej aplikacji z kilkuset wywołaniami dziennie?
Zależy od długości promptu systemowego i ceny modelu. Dla promptu systemowego liczącego 1000 tokenów i 500 wywołań dziennie na modelu frontier miesięczne oszczędności są rzędu kilku euro — na granicy opłacalności refaktoryzacji kodu. Przy 50 000 wywołań dziennie i 2000-tokenowym prompcie oszczędności są rzędu setek euro miesięcznie i więcej — tam sens jest jednoznaczny.
Co jeśli mój prompt systemowy musi być aktualizowany co godzinę (np. wstawiam bieżący czas lub stan magazynu)?
To klasyczna pułapka. Jeśli dynamiczna wartość znajdzie się wewnątrz keszowanego bloku, każda jej zmiana unieważni cache. Rozwiązanie: wyciągnijcie dynamiczną wartość z keszowanego prefiksu do wiadomości użytkownika lub do niekeszowanego bloku na końcu promptu. Keszowany prompt systemowy pozostaje niezmieniony, a dynamiczna wartość trafia obok niego.
Czy prompt caching działa przy użyciu wyjścia strukturyzowanego (JSON mode)?
Tak. Caching jest niezależny od formatu wyjścia. Keszowany prefiks może być kombinacją instrukcji systemowych i schematu JSON, o ile jest statyczny — model generuje odpowiedź zgodnie ze schematem, a hit rate cache się nie zmienia. Więcej o wyjściu strukturyzowanym w artykule o structured outputs i JSON mode.
Podsumowanie
Prompt caching to nie jest rewolucja — to optymalizacja infrastrukturalna, która działa cicho i niezawodnie, o ile zaprojektujecie aplikację tak, żeby z niej korzystała. Trzy kluczowe rzeczy: zidentyfikujcie statyczny prefiks w swoich promptach, umieśćcie go spójnie na początku i mierzcie hit rate. Przy workloadach z tysiącami wywołań dziennie i długimi, wspólnymi kontekstami ta zmiana może obniżyć rachunek za LLM API o kilkadziesiąt procent bez żadnej ingerencji w logikę aplikacji.
*W MP Industrial Solutions podczas przeglądów aplikacji LLM klientów regularnie trafiamy na struktury promptów, w których caching nie jest wykorzystywany — albo gdzie dynamiczny element w środku statycznego kontekstu niweluje cały efekt. Jeśli chcecie, żebyśmy przyjrzeli się waszej aplikacji i wskazali konkretne oszczędności, chętnie spotkamy się na konsultacji.*