Prompt caching
Jak platforma LLM taniej przetwarza powtarzalny początek promptu
.NET Developer | I build applications from concept to production. On my blog, I share practical examples (.NET “by example”) and thoughts on software architecture and bridging technology with business.
Wstęp
W poprzednim artykule "Jak efektywnie zarządzać kontekstem agentów AI w .NET" opisałem jak można zarządzać liczbą tokenów wysyłanych do LLM po stronie naszych aplikacji kontrolując koszty i czas generowania odpowiedzi dużych modeli językowych.
Zmiana rozmiaru kontekstu nie jest jednak jedynym sposobem ograniczania wydatków i przyśpieszania przetwarzania zapytań. Platformy LLM takie jak OpenAI, Azure, Anthropic czy Gemini wprowadzają również własne optymalizacje. W tym artykule omówię jedną z nich - prompt caching.
Jak działa prompt caching
Nasza aplikacja przy każdym wywołaniu LLM zwykle przesyła cały wymagany kontekst w jednym żądaniu. Zawiera on historię rozmowy, a w przypadku agentic AI również wyniki narzędzi oraz dane pośrednie utrzymywane przez agenta. Prowadzi to do szybkiego wzrostu liczby przetwarzanych tokenów wejściowych.
Prompt caching pozwala ograniczyć koszt wynikający z tego wzrostu. Mechanizm rozpoznaje wspólny prefiks kolejnych żądań i wykorzystuje zapisane wyniki fazy przetwarzania wejścia (prefill). Dzięki temu platforma może pominąć ponowne przetwarzanie zapisanej części promptu i skupić obliczenia na nowej części zapytania.
W przeciwieństwie do klasycznego cache trafienie nie powoduje zwrócenia wcześniej wygenerowanego wyniku. Model nadal generuje odpowiedź, dlatego dwa identyczne wywołania nie muszą zwrócić takiego samego rezultatu. Mechanizm wpływa wyłącznie na koszt i czas przetwarzania tokenów wejściowych, nie zmieniając procesu ani kosztu generowania tokenów wyjściowych.
Prompt caching w praktyce
W celu sprawdzenia działania prompt cachingu w praktycznym scenariuszu ponownie wykorzystałem asystenta sklepu z katalogiem laptopów stworzonego w .NET Semantic Kernel i opisanego w poprzednim artykule. Dodałem zapis do pliku CSV metryki CachedInputTokens zwracanej przez platformę w odpowiedzi na wywołania LLM. Następnie uruchomiłem wariant bazowy aplikacji, w którym pełna historia rozmowy między klientem sklepu a agentem oraz wyniki narzędzi były przesyłane przy każdym żądaniu. Wykorzystałem 21 pytań przygotowanych w artykule dotyczącym zarządzania kontekstem.
Warto dodać, że każda platforma LLM stosuje własne zasady działania prompt cachingu i oferuje różny poziom kontroli nad tym mechanizmem w zapytaniach oraz SDK. W eksperymencie użyłem GPT-5 na platformie Azure OpenAI. Szczegółowe wymagania dotyczące cache można znaleźć w dokumentacji. Aby prompt cache został wykorzystany, wspólny prefiks musi zawierać co najmniej 1024 tokeny.
Poniżej przedstawiono wyniki eksperymentu dla wybranych tur:
| Turn | Input Tokens | Cached Input Tokens | Uncached Input Tokens | Cached input Ratio |
|---|---|---|---|---|
| 1 | 790 | 0 | 790 | 0% |
| 2 | 2936 | 0 | 2936 | 0% |
| 3 | 6880 | 4864 | 2016 | 70.7% |
| 4 | 4477 | 4352 | 125 | 97.2% |
| 10 | 9118 | 8960 | 158 | 98.3% |
| 11 | 9376 | 9088 | 288 | 96.9% |
| 20 | 13617 | 13312 | 305 | 97.8% |
| 21 | 13844 | 13568 | 276 | 98.0% |
Cached Input Ratio = CachedInputTokens / InputTokens — udział tokenów wejściowych obsłużonych przez prompt cache.
Wnioski z pomiarów prompt cache
Wyniki eksperymentu pokazują, że gdy kolejne zapytania zawierały wspólny prefiks, większość tokenów wejściowych była obsługiwana przez prompt cache. W trzeciej turze Cached Input Ratio wyniósł 70,7%, a w kolejnych utrzymywał się zwykle na poziomie 96–98%. Oznacza to, że tylko niewielka część promptu wymagała pełnego przetworzenia, mimo że aplikacja nadal przesyłała cały kontekst agenta.
Efekt został osiągnięty bez zmian w sposobie zarządzania kontekstem. Aplikacja nadal przesyłała pełną historię rozmowy oraz wyniki narzędzi przy każdym wywołaniu, a optymalizacja wynikała wyłącznie z mechanizmu prompt cache po stronie platformy LLM.
Przykładowo w 10. turze aplikacja wysłała 9118 tokenów wejściowych, z czego 8960 zostało obsłużonych przez cache. Tylko 158 tokenów wymagało pełnego przetworzenia według standardowej stawki input (1,25 USD / 1 mln tokenów), podczas gdy pozostała część została rozliczona jako cached input według niższej stawki (0,13 USD / 1 mln tokenów). Warto zwrócić uwagę, że mechanizm nie wpływa na koszt tokenów wyjściowych. Output tokens nadal są rozliczane według standardowej stawki modelu GPT-5 (10 USD / 1 mln tokenów).
Podsumowanie
Prompt caching pozwala ograniczyć koszt i czas ponownego przetwarzania powtarzających się fragmentów zapytań bez konieczności zmniejszania rozmiaru kontekstu wysyłanego przez aplikację. Jest szczególnie wartościowy w scenariuszach agentowych, gdzie instrukcje systemowe, definicje narzędzi oraz historia rozmowy często pozostają niezmienne pomiędzy kolejnymi wywołaniami.
Mechanizm nie zastępuje zarządzania kontekstem. Przy bardzo długich rozmowach techniki takie jak summarization czy ograniczanie historii nadal mogą być potrzebne ze względu na limit context window. Prompt caching pozwala natomiast ograniczyć koszt przetwarzania stabilnych fragmentów wejścia, pozostawiając aplikacji pełną kontrolę nad sposobem budowania kontekstu.
Warto uwzględnić prompt caching już na etapie projektowania aplikacji opartych o LLM. Przy odpowiedniej strukturze zapytań i spełnieniu wymagań danej platformy może on przynieść znaczące oszczędności bez konieczności wdrażania dodatkowych mechanizmów zarządzania kontekstem po stronie aplikacji. Rzeczywiste wykorzystanie cache warto monitorować za pomocą dostępnych metryk, takich jak CachedInputTokens.
