Czym jest Prompt Caching?
Prompt Caching (buforowanie promptu) to technika, dzięki której model językowy przechowuje tymczasowo pośrednie wyniki obliczeń dla stałej, powtarzalnej części zapytania. Zamiast przetwarzać ten sam kontekst przy każdym kolejnym wywołaniu API, system może sięgnąć po gotowe, "obliczone" reprezentacje i wrócić jedynie do przetworzenia nowej, zmiennej części wejścia.
Jest to narzędzie czysto infrastrukturalne — nie zmienia zachowania modelu, nie wpływa na jakość generowanego tekstu, nie dodaje pamięci do modelu. Działa wyłącznie jako cache warstwy obliczeniowej, zwiększając efektywność kosztową i szybkość odpowiedzi w scenariuszach, gdzie te same dane trafiają do modelu wielokrotnie.
Termin funkcjonuje pod różnymi nazwami u różnych dostawców: Anthropic nazywa go _prompt caching_ (z mechanizmem `cache_control`), OpenAI stosuje _prompt caching_ automatycznie bez żadnej konfiguracji ze strony dewelopera, a Google Gemini oferuje _context caching_ jako osobny zasób API z dedykowaną nazwą i TTL.
Kto za tym stoi?
Mechanizm Prompt Caching wprowadził Anthropic dla swoich modeli Claude w sierpniu 2024 roku. OpenAI uruchomił własną implementację automatycznego cachingu dla modeli GPT-4o i o1 w październiku 2024 roku. Google Gemini oferuje Context Caching jako osobną funkcję API dla modeli Gemini 1.5 Pro i Flash od połowy 2024 roku.
Każdy z tych dostawców opracował niezależną implementację, dostosowaną do architektury swoich systemów — choć koncepcja bazowego mechanizmu, czyli KV cache (Key-Value cache), pochodzi z badań nad efektywnością Transformerów i była dobrze znana w środowisku badawczym na długo przed komercyjnym wdrożeniem.
Jak to działa?
Technicznie Prompt Caching opiera się na KV Cache (Key-Value Cache) — strukturze danych tworzonej podczas przetwarzania sekwencji tokenów przez Transformer. Dla każdej warstwy modelu i każdego tokenu wejściowego obliczane są wektory klucza (K) i wartości (V). W standardowym przetwarzaniu te wektory są liczone od nowa przy każdym wywołaniu API.
Mechanizm cachingu pozwala zachować te wektory dla stałego, początkowego fragmentu promptu. Jeśli kolejne zapytanie zaczyna się od identycznego prefiksu, system pomija jego obliczenia i od razu przechodzi do przetwarzania nowej części wejścia.
W praktyce wygląda to następująco:
- Pierwsze wywołanie: model przetwarza cały prompt (stały prefiks + zmienne zapytanie użytkownika), kosztuje pełną cenę za tokeny wejściowe.
- System tworzy i zapisuje KV Cache dla stałego prefiksu.
- Kolejne wywołania z tym samym prefiksem: model odczytuje cache, przetwarza tylko zmienną część — koszt tokenów z cache wynosi ułamek standardowej stawki.
Kluczowym wymogiem jest kolejność tokenów — cache jest tworzony dla prefiksu, czyli tokenów na początku promptu. Każda zmiana choćby jednego tokenu w stałej części powoduje unieważnienie cache.
Z jakich elementów się składa?
Implementacje Prompt Caching różnią się między dostawcami, ale każda zawiera kilka wspólnych elementów:
Stały prefiks (cacheable prefix) — fragment promptu, który pozostaje identyczny we wszystkich wywołaniach. Najczęściej to instrukcja systemowa, długi dokument, zestaw przykładów few-shot lub baza wiedzy.
Zmienna część (variable suffix) — zapytanie użytkownika lub dynamiczne dane. Ta część zawsze jest liczona jako standard input.
TTL (Time to Live) — czas przez jaki cache jest przechowywany:
- Anthropic Claude: 5 minut (z możliwością odświeżenia przez kolejne wywołanie); modele z rozszerzonym cache (beta) mogą trzymać go dłużej
- OpenAI: od kilku minut do kilku godzin (zależnie od obciążenia serwerów, dokumentacja nie podaje stałej wartości)
- Google Gemini Context Caching: od 1 minuty do 1 godziny (konfigurowane przez dewelopera)
Minimalny próg tokenów — cache nie jest opłacalny dla krótkich promptów:
- Anthropic: minimum 1024 tokeny dla Claude 3.5 Sonnet, minimum 2048 dla starszych modeli
- OpenAI: minimum 1024 tokeny
- Google Gemini: minimum 32 768 tokenów dla Gemini 1.5 Pro (znacznie wyższy próg)
Stawki za tokeny z cache — koszt odczytu z cache jest niższy niż standardowe przetwarzanie:
- Anthropic: tokeny odczytane z cache kosztują ok. 10% standardowej ceny wejściowej (90% taniej)
- OpenAI: tokeny z cache kosztują 50% standardowej ceny wejściowej (50% taniej)
- Google Gemini: tokeny z cache kosztują ok. 25% standardowej ceny wejściowej (75% taniej), ale doliczany jest koszt przechowywania per godzinę
Cache write i cache read
Łatwo pomyśleć, że skoro caching obniża rachunek, to sam cache jest darmowy. Tak nie jest — z mechanizmem wiążą się dwa odrębne koszty:
- Zapis cache (cache write) — jednorazowa opłata za utworzenie cache przy pierwszym przetworzeniu prefiksu. U Anthropic zapis jest nawet droższy od zwykłego inputu (ok. 25% więcej, czyli ~1,25× ceny wejściowej).
- Odczyt cache (cache read) — znacznie tańszy koszt ponownego użycia zapisanego cache w kolejnych wywołaniach (u Anthropic ok. 10% ceny wejściowej).
Przy pierwszym użyciu dostawca musi utworzyć cache, co wiąże się z dodatkową opłatą; dopiero kolejne odwołania korzystają z tańszego odczytu. Dlatego caching opłaca się głównie wtedy, gdy ten sam kontekst będzie używany wielokrotnie — koszt zapisu trzeba zamortyzować odpowiednio dużą liczbą odczytów. To bardzo istotne z punktu widzenia architekta systemu.
Do czego może być używane?
Prompt Caching jest najbardziej opłacalny w scenariuszach, w których ten sam duży kontekst pojawia się w wielu kolejnych wywołaniach:
- Rozbudowane instrukcje systemowe — aplikacje, w których system prompt liczy kilka tysięcy tokenów (szczegółowe reguły zachowania, persona, format odpowiedzi). Zamiast płacić za te tokeny przy każdym zapytaniu użytkownika, są one buforowane raz.
- Analiza dokumentów w trybie wieloturowym (multi-turn) — scenariusz: użytkownik wgrywa kontrakt PDF i zadaje dziesiątki pytań o jego treść. Dokument jest cachowany raz, każde pytanie płaci jedynie za swoje tokeny.
- Few-shot learning z przykładami — gdy prompt zawiera dziesiątki przykładów uczących (np. pary wejście-wyjście dla konkretnego zadania klasyfikacji), te przykłady mogą być cachowane i ponownie używane we wszystkich kolejnych wywołaniach.
- Retrieval-Augmented Generation (RAG) — systemy RAG, które wstrzykują długie fragmenty bazy wiedzy do każdego promptu, mogą korzystać z cache gdy pobierają te same dokumenty.
- Chatboty z długim kontekstem rozmowy — w konwersacjach wieloturowych cała historia rozmowy może być potencjalnie cachowana, choć tu implementacja wymaga precyzyjnej kontroli.
- Agentic workflows — systemy agentowe, w których agent wielokrotnie wraca do tych samych zasobów kontekstowych (specyfikacja zadania, narzędzia, reguły).
Czym różni się od innych rozwiązań?
Warto odróżnić Prompt Caching od kilku powiązanych, ale różnych koncepcji:
- Vs. semantic caching — Prompt Caching działa na poziomie dokładnych tokenów — wymaga identycznych bajtów prefiksu. Semantic caching (np. stosowany w narzędziach jak GPTCache) działa inaczej: jeśli dwa pytania mają podobne znaczenie semantyczne (niekoniecznie identyczne tokeny), zwraca zachowaną odpowiedź. Semantic caching cachuje _wyjście_, Prompt Caching cachuje _obliczenia wewnętrzne_ modelu.
- Vs. fine-tuning — Fine-tuning "wbudowuje" wiedzę na stałe do wag modelu, eliminując potrzebę podawania jej w prompcie. Prompt Caching nie zmienia modelu — wiedza nadal musi być w prompcie, ale koszt jej podawania jest obniżony.
- Vs. przechowywanie historii konwersacji — Zarządzanie historią konwersacji to decyzja aplikacyjna — co i jak długo trzymać w oknie kontekstu. Prompt Caching to optymalizacja infrastrukturalna — jak efektywnie kosztowo ten kontekst przetwarzać.
- Vs. RAG — RAG to strategia doboru informacji (wyszukaj → wstaw → generuj). Prompt Caching to optymalizacja wykonania (jeśli wstawiasz te same dokumenty wielokrotnie, płać za nie raz). Oba mechanizmy mogą współistnieć.
Najważniejsze ograniczenia i wyzwania
- Wrażliwość na kolejność tokenów — Nawet jedna zmiana na początku promptu unieważnia cały cache. Oznacza to, że dynamiczne dane (np. data, ID sesji, zmienne systemowe) nie mogą pojawiać się w stałej części promptu.
- Zimny start — Pierwsze wywołanie zawsze płaci pełną cenę za tokeny wejściowe. W scenariuszach z małą liczbą zapytań oszczędności mogą być minimalne lub żadne.
- Dodatkowy koszt przechowywania (Google) — Google Gemini dolicza opłatę za każdą godzinę przechowywania cache. Przy rzadkich wywołaniach koszt przechowywania może przekroczyć oszczędności z tańszych tokenów.
- Brak gwarancji trafienia cache — OpenAI nie gwarantuje ile czasu cache będzie aktywny. Przy nieregularnym ruchu lub w przypadku zmian po stronie infrastruktury cache może nie być dostępny.
- Ograniczona kontrola u OpenAI — Automatyczny caching OpenAI działa bez konfiguracji ze strony dewelopera, co jest wygodne, ale uniemożliwia jawne sterowanie tym, co jest cachowane i na jak długo.
- Próg minimalny jako bariera — Wymóg minimum 1024 (lub 32 768 dla Gemini) tokenów sprawia, że cache nie jest dostępny dla krótkich promptów, co wyklucza część przypadków użycia.
Dlaczego to jest istotne?
Prompt Caching jest odpowiedzią na realne napięcie, które stało się widoczne wraz z upowszechnieniem modeli o długim oknie kontekstu. Modele takie jak Claude 3.5 Sonnet (200 000 tokenów) czy Gemini 1.5 Pro (1 milion tokenów) pozwalają "wczytać" do promptu całe bazy kodu, dokumenty prawne, historię korespondencji — ale każde kolejne wywołanie z tym samym kontekstem oznacza identyczny koszt obliczeniowy i finansowy.
Dla małych prototypów to akademicka kwestia. Dla aplikacji produkcyjnych obsługujących tysiące sesji dziennie — fundamentalna różnica w ekonomice. Aplikacja chatbota analizującego dokumenty medyczne, gdzie każdy prompt zawiera 50-stronicowy kontekst kliniczny, może dzięki cachingowi zredukować koszty tokenów wejściowych nawet o 80–90% przy wysokim ruchu.
Głębsza konsekwencja jest architektoniczna: Prompt Caching zmienia rachunek opłacalności dla rozwiązań opartych na długim kontekście versus RAG. Historycznie RAG był preferowaną strategią częściowo dlatego, że wstrzykiwanie dużych dokumentów przy każdym wywołaniu było zbyt kosztowne. Caching czyni "long context" realnie konkurencyjną alternatywą dla co najmniej części przypadków użycia, gdzie precyzja retrieval w RAG jest niepewna lub gdzie kompletny kontekst naprawdę jest potrzebny.
To również sygnał o kierunku, w którym zmierza rynek: dostawcy modeli aktywnie redukują barierę kosztową dla aplikacji wymagających bogatego kontekstu, co będzie stopniowo przesuwać punkt równowagi między minimalizmem promptów a pełną ekspresją kontekstową.