Prompt caching w LLM: jak tańszy stały prefiks tnie rachunki

Asystent obsługi klienta z 1 800-tokenowym systemowym promptem i 600-tokenowym kontekstem z bazy wiedzy wysyła przy każdym z 15 000 zapytań miesięcznie łącznie 2 400 tokenów „stałej" części wejścia. To 36 mln tokenów miesięcznie za tekst, który się nie zmienia. Prompt caching likwiduje ten koszt bez jednej linii kodu biznesowego.

Modele językowe przetwarzają każde wywołanie od zera, chyba że provider zaimplementował mechanizm cache prefiksu. Przy pierwszym wywołaniu z danym prefiksem model oblicza tzw. klucze i wartości uwagi (KV-cache) dla tych tokenów i zapisuje je na serwerze. Każde kolejne wywołanie zaczynające się od identycznego prefiksu odczytuje KV-cache zamiast go przeliczać.

Warunek trafienia jest precyzyjny: prefiks musi być identyczny bajtowo od początku promptu do zdefiniowanego punktu podziału. Jeden zmieniony znak, przestawiona instrukcja albo inaczej sformatowana data w systemowym promptcie przerywa match. To fundamentalna różnica wobec cache semantycznego, który operuje na podobieństwie znaczeniowym i toleruje parafrazę.

Praktyczne konsekwencje tego mechanizmu: stały system prompt musi być na początku promptu (przed zmiennym kontekstem użytkownika), a zmienna część (zapytanie, świeży kontekst RAG, historia rozmowy) musi znajdować się po bloku, który chcesz cache'ować. Dostawcy API, którzy oferują tę funkcję (m.in. Anthropic, Google Gemini, niektóre warianty OpenAI), wymagają minimalnej długości cachowanego fragmentu, zwykle 1 024 tokeny, żeby cache był opłacalny po stronie infrastruktury.

Koszt trafienia w cache zależy od providera: Anthropic pobiera 10% ceny normalnego tokenu wejściowego za cache hit, Google Gemini w trybie context caching może zejść do 25% bazowej ceny. W obu przypadkach zapis do cache (pierwsze wywołanie) kosztuje 100-125% normalnej ceny wejściowej, więc rentowność zaczyna się od drugiego zapytania z tym samym prefiksem.

Te dwa mechanizmy działają na różnych warstwach i rozwiązują różne problemy. Warto je zestawiać, bo firmy wdrażające AI często mylą je lub wybierają jeden tam, gdzie potrzebują obu.

Prompt caching działa na poziomie inferencji: eliminuje koszt przetwarzania niezmiennej części wejścia. Nie dotyka odpowiedzi modelu, nie buforuje wyników. Każde zapytanie nadal trafia do modelu i dostaje unikalną odpowiedź. Zysk to wyłącznie redukcja kosztu tokenów wejściowych dla stałego prefiksu.

Cache semantyczny działa na poziomie odpowiedzi: przechwytuje parę (zapytanie, odpowiedź) i przy kolejnym semantycznie podobnym zapytaniu zwraca zapisaną odpowiedź bez udziału modelu. Zysk to zarówno koszt tokenów wejściowych, jak i wyjściowych, a nawet całkowite wyeliminowanie latencji modelu (10-30 ms zamiast 300-1500 ms).

Oba mechanizmy uzupełniają się: cache semantyczny obsługuje powtarzalne pytania FAQ bez modelu, a prompt caching obniża koszt wszystkich pozostałych zapytań, które i tak trafiają do modelu ze stałym prefiksem. W systemie z rozbudowanym RAG warto rozważyć oba równocześnie, co opisujemy szerzej w artykule o optymalizacji kosztów tokenów LLM.

Oszczędność jest wprost proporcjonalna do dwóch czynników: udziału stałego prefiksu w całkowitej długości promptu oraz wolumenu zapytań. Scenariusze z dużym przemnożeniem tych czynników to naturalne priorytety.

Asystent z długim systemowym promptem i dużym kontekstem RAG. Jeśli system prompt ma 2 000 tokenów, a do każdego wywołania doklejasz 1 500 tokenów dokumentów z bazy wiedzy jako stały kontekst produktowy, prefiks liczy 3 500 tokenów. Przy 10 000 zapytań miesięcznie to 35 mln tokenów wejściowych do wyeliminowania. Przy cenie 0,003 USD/1k tokenów oszczędność sięga 80-100 USD miesięcznie, przy modelu premium (0,015 USD/1k) przekracza 450 USD miesięcznie.

Przetwarzanie dokumentów w trybie batch. Analiza długiego dokumentu (raport, kontrakt, zestaw danych) podzielona na wiele wywołań analitycznych to klasyczny przypadek: dokument jest prefiksem, a pytania analityczne zmieniają się. Prompt caching redukuje koszt wielokrotnej analizy tego samego pliku o 60-80%.

Wieloetapowe pipeline'y agentów. W architekturze agenta wykonującego kilkanaście kroków w jednej sesji, gdzie każdy krok widzi ten sam systemowy prompt i historię dotychczasowych działań jako prefiks, cache kumuluje oszczędności po każdym dodatkowym kroku.

Kiedy efekt jest marginalny: systemy z krótkimi promptami (poniżej 1 024 tokenów stałego prefiksu nie kwalifikuje się na cache u większości providerów), systemy z dużą zmiennością kontekstu (gdzie „stały" prefiks zmienia się co kilkanaście zapytań) oraz single-shot wywołania, gdzie każdy prompt jest unikalny.

Kolejność bloków w prompcie to decyzja inżynierska z bezpośrednim wpływem na TCO systemu. Praktyczna zasada: od najbardziej stałego do najbardziej zmiennego.

Struktura zoptymalizowana pod cache:

1. System prompt (instrukcje roli, ton, zasady, guardrails) — najbardziej stały, zmienia się raz na tygodnie lub miesiące.
2. Stały kontekst wiedzy (dokumenty produktowe, FAQ, glosariusz firmowy) — zmienia się przy aktualizacji bazy wiedzy, nie przy każdym zapytaniu.
3. Historia rozmowy (poprzednie tury) — zmienia się co kilka tur, ale w ramach sesji rośnie stopniowo.
4. Zapytanie użytkownika — zmienne, na końcu.

Błędy strukturalne niszczące cache: wstrzykiwanie daty lub timestampa do systemprompta (zmienia się co sekundę, prefiks nigdy nie trafi w cache), umieszczanie zmiennego kontekstu użytkownika przed stałymi instrukcjami, dynamiczne przeformatowywanie stałych bloków przy każdym wywołaniu.

Warto wprowadzić separatory tokenowe między blokami, jeśli API na to pozwala, żeby zdefiniować punkt podziału. Niektóre SDK (Anthropic Python SDK od wersji 0.28) wspierają annotację cache_control: {"type": "ephemeral"} na poziomie wiadomości, co pozwala oznaczyć dokładny punkt podziału stałego i zmiennego segmentu.

Szczegółowe wzorce budowania systemowego promptu, w tym kolejność elementów i struktura instrukcji, opisujemy w artykule o prompt engineeringu dla firm.

Prompt caching to funkcja infrastruktury po stronie serwera. Modele uruchamiane lokalnie przez Ollama, vLLM lub llama.cpp mogą obsługiwać ten mechanizm, ale zależy to od konkretnej implementacji serwera inferencji.

vLLM (od wersji 0.4.0) wspiera prefix caching automatycznie dla wszystkich modeli, o ile enable_prefix_caching=True jest ustawiony przy starcie. llama.cpp z parametrem --cache-prompt zapisuje i ładuje KV-cache między sesjami w tym samym procesie. Ollama (stan na 2026) nie eksponuje tej opcji przez publiczne API, ale mechanizm jest obecny w warstwie llama.cpp, na której bazuje.

Dla self-hostingu kluczowy jest dodatkowy wymóg pamięci: KV-cache dla 2 000-tokenowego prefiksu modelu 70B zajmuje 0,5-2 GB VRAM (zależy od precyzji kwantyzacji). Zanim włączysz prefix caching na infrastrukturze lokalnej, sprawdź, czy masz rezerwę VRAM. Oszczędność na czasie GPU i przepustowości bywa jednak znacząca przy dużym wolumenie zapytań do tego samego prefiksu.

Analizę progu opłacalności między API a self-hostingiem, uwzględniającą koszty sprzętu i prompt caching po obu stronach, przeprowadzisz w artykule o kosztach utrzymania agenta AI.

Zależy od providera. U Anthropic musisz oznaczyć bloki cache_control w SDK lub bezpośrednio w żądaniu API, co wymaga kilku linii kodu. Google Gemini Context Caching ma osobny endpoint do zapisania kontekstu przed wywołaniem. OpenAI (wybrane modele) cachuje prefiksy automatycznie bez adnotacji, ale tylko przy ponownym użyciu dokładnie tego samego prefiksu. W każdym przypadku zmiana dotyczy warstwy wywołań API, nie logiki biznesowej asystenta.

Czas życia cache (TTL) różni się między providerami. Anthropic określa TTL na 5 minut dla standardowego cache, z możliwością odświeżenia przez kolejne wywołanie. Google Gemini Context Caching pozwala ustawić własny TTL (od kilku minut do kilku godzin) i liczy oddzielną opłatę za przechowywanie cache per godzinę. Przy niskim wolumenie zapytań (poniżej kilku na minutę) TTL 5 minut może powodować częste cache missy i zmniejszać efektywną oszczędność.

Tak, cache prefiksu jest przechowywany po stronie providera przez czas TTL. Jeśli system prompt lub kontekst RAG zawiera dane osobowe lub poufne dane firmowe, zastosowanie prompt caching oznacza, że te dane są przechowywane na serwerach providera dłużej niż pojedyncze wywołanie. Zanim włączysz cache, sprawdź umowę DPA (Data Processing Agreement) z providerem oraz oceń, czy zawartość prefiksu wymaga DPIA. Jeśli dane wrażliwe nie mogą opuszczać lokalnej infrastruktury, rozważ self-hosting z vLLM prefix caching.

Tak i jest to jeden z wymiernych efektów ubocznych. Wyeliminowanie przeliczania KV-cache dla dużego prefiksu skraca czas do pierwszego tokenu odpowiedzi o 15-40% dla typowych rozmiarów systempromptów. Efekt jest widoczny zwłaszcza przy prefiksach powyżej 2 000 tokenów i modelach z długim kontekstem (100k+), gdzie pełne przetwarzanie prefiksu zajmuje kilkaset milisekund.

Tak, to częsty wzorzec optymalizacji. Router modeli kieruje zapytania do modeli różnych klas (tanie/szybkie vs. drogie/dokładne). Prompt caching warto włączyć osobno dla każdej klasy modelu, bo prefiks systemowy jest różny dla różnych modeli w routerze. Routery zbudowane na n8n lub własnym kodzie mogą przekazywać identyfikator modelu do warstwy zarządzania promptem, żeby klucz cache zawierał wersję modelu i unikać trafień między różnymi modelami używającymi podobnych systemowych promptów.