Kaszowanie promptów (Prompt Caching & KV Cache Reuse)

1. Przegląd koncepcji i problem systemowy

W nowoczesnym rozwoju z wykorzystaniem agentów (np. Claude Code czy Cursor) każda rozmowa składa się z dziesiątek iteracji. Przy tym 90–95% informacji w każdym żądaniu jest całkowicie statyczne:

• Systemowy prompt z regułami projektu (5 000 tokenów).
• Schematy 20 podłączonych narzędzi MCP (10 000 tokenów).
• Zaindeksowane pliki dokumentacji i kodu (40 000 tokenów).

Bez cache’owania przy każdej replice dewelopera serwer musi na nowo przetwarzać wszystkie 55 000 statycznych tokenów przez macierze transformera (faza Prefill):

1. Wysoki koszt finansowy: Płacisz pełną cenę za odczyt tych samych 55 000 tokenów 30 razy podczas jednej sesji.
2. Duże opóźnienie (High TTFT): Czas do pojawienia się pierwszego znaku odpowiedzi rozciąga się na 5–10 sekund, zabijając poczucie interaktywnego vibe codingu.
3. Marnowanie zasobów GPU: Moc obliczeniowa kart graficznych spalana jest na powtarzanie deterministycznych obliczeń.

Prompt Caching eliminuje ten narzut: serwer raz oblicza stan uwagi dla statycznego prefiksu, zapisuje go w ultraszybkiej pamięci HBM i natychmiast przejmuję gotowy stan przy kolejnych wywołaniach.

2. Taksonomia architektoniczna i model mentalny

Architektura cache’owania promptów budowana jest wokół następujących warstw koncepcyjnych:

• 1. Struktura prefiksów (Prefix Hierarchy): Prompt projektowany jest jak „matrioszka” od najbardziej statycznego do najbardziej dynamicznego: [Static System Prompt] -> [MCP Tool Definitions] -> [Cached Project Context] -> [Dynamic Turn History] -> [User Input].
• 2. Ekonomia stanów cache:
  • Cache Write: Pierwsze odwołanie lub zapis po zmianie prefiksu. Kosztuje o 25% więcej niż standardowy input, ponieważ wymaga utrwalenia stanu w pamięci.
  • Cache Hit / Read: Ponowne odwołanie do niezmienionego prefiksu. Daje rabat 80–90% od bazowej ceny tokenów wejściowych.
• 3. Punkty zapisu (Breakpoints): Specyficzne markery w strukturze żądania, które informują silnik inferencji, gdzie dokładnie kończy się stabilny blok podlegający zapisowi.
• 4. Mechanizmy wyszukiwania cache:
  • Radix Tree / Prefix Trie: Struktura danych w pamięci serwera inferencyjnego (np. w vLLM / SGLang), która natychmiast znajduje najdłuższy wspólny łańcuch tokenów wśród aktywnych sesji.

3. Pipeline techniczny i mechanika wewnętrzna

Cykl życia żądania z wykorzystaniem Prompt Caching:

1. Serializacja i weryfikacja hash (Hashing prefiksu): Klient wysyła tablicę wiadomości. Serwer pobiera sekwencję tokenów od początku do pierwszego punktu cache_control i oblicza kryptograficzny hash prefiksu.
2. Trie Lookup (Wyszukiwanie w drzewie cache): Menedżer pamięci GPU sprawdza, czy istnieje żywy blok KV-cache dla tego hasha.
   • Jeśli znaleziono (Cache Hit) – obliczenia Prefill są pomijane, a zapisane macierze $K$ oraz $V$ są natychmiast podłączane do grafu obliczeniowego.
   • Jeśli nie znaleziono (Cache Miss) – serwer wykonuje pełne obliczenia i asynchronicznie zapisuje wynik do bufora.
3. Przetwarzanie dynamicznego sufiksu (Suffix Processing): Transformer oblicza uwagę wyłącznie dla nowego fragmentu – ostatniej wiadomości użytkownika (np. 200 tokenów zamiast 50 000).
4. Natychmiastowe dekodowanie i odświeżanie TTL (Generacja): Model zaczyna generować odpowiedź już po 200–400 milisekundach, a timer życia cache resetuje się do nowego 5-minutowego interwału.

4. Praktyczne scenariusze inżynieryjne w produkcji

01. Wielokrokowe sesje developmentu w Claude Code i Cursor

Agent wykonuje złożony, 15-krokowy refactoring. Dzięki cache’owaniu baza kodowa projektu (100 000 tokenów) jest zapisywana w kroku 1. W krokach 2–15 użytkownik płaci tylko za deltę poprawek, oszczędzając do 85% całkowitego kosztu pracy wieczorem.

02. Cache’owanie dużych bibliotek narzędzi MCP

Podłączenie 30 złożonych korporacyjnych narzędzi wymaga szczegółowych schematów JSON zajmujących 12 000 tokenów. Cache’owanie bloku narzędzi gwarantuje, że deweloper nie przepłaca za ich opis przy każdym banalnym pytaniu w czacie.

03. Wysokoobciążeniowi asystenci korporacyjni z bazy wiedzy

Chatbot wsparcia wewnętrznego korzysta z jednego, cache’owanego dokumentu systemowego (regulaminy, instrukcje, FAQ) o objętości 50 000 tokenów. Tysiące pracowników wysyła zapytania jednocześnie, trafiając w tę samą warstwę cache na klastrze modeli, co zapewnia minimalny czas odpowiedzi.

5. Pułapki, typowe błędy i bezpieczeństwo

• Wyciek danych dynamicznych do prefiksu (Timestamp Invalidation): Najczęstszy błąd inżynierski to dodawanie dynamicznego ciągu typu Current Time: 2026-09-09 12:15:30 na początku systemowego promptu. To zmienia pierwsze tokeny co sekundę i w 100% łamie cache’owanie dla wszystkich następnych modułów. Przenoś zmienne dynamiczne do końcowych wiadomości.
• Zimny start po przestoju: Jeśli między krokami dewelopera minęło więcej niż 5 minut, cache wyparowuje. Kolejne żądanie jest ponownie rozliczane według taryfy Cache Write z opóźnieniem na inicjalizację.
• Mieszanie uprawnień dostępu (Multi-Tenant Cache Bleed): Na serwerach self-hosted (vLLM) upewnij się, że sesje różnych użytkowników nie korzystają ze wspólnego prefiksu zawierającego poufne dane osobowe.