Inne

Prompt Caching

2023AktywnyOpublikowano: 17 maja 2026Aktualizacja: 17 maja 2026Opublikowany

Mechanizm reuse'u wstępnie obliczonego KV-cache attention dla wspólnych prefiksów promptu pomiędzy zapytaniami. Eliminuje powtórny prefill, drastycznie obniża latency time-to-first-token i koszt tokenów wejściowych.

Kluczowa innowacja

Współdzielenie wstępnie obliczonego KV-cache (klucze i wartości attention) dla wspólnych prefiksów promptu pomiędzy wieloma zapytaniami — eliminacja powtórnego prefillu identycznego początku kontekstu redukuje latency TTFT i koszt API o 50–90% dla typowych workloadów (długi system prompt, duży kontekst RAG, wielokrotne zapytania na ten sam dokument).

Kategoria

Inne

Poziom abstrakcji

Pattern

Poziom operacji

InferencjaWdrożenieSystem

Zastosowania

Chatboty z dużym, statycznym system promptem (definicja persony, polityki, przykłady few-shot) — dziesiątki tysięcy tokenów cached raz, używane przez setki sesji.Agenci AI z dużymi definicjami narzędzi i schemami JSON — narzędzia statyczne między wywołaniami, prompt dynamiczny tylko po stronie historii.RAG z dużymi, rzadko zmiennymi dokumentami referencyjnymi — manuale, dokumentacja, kodeksy prawne wczytywane raz do cache.IDE AI (Claude Code, Cursor, Codex) — drzewo plików projektu cached, dynamiczne tylko zapytanie i bieżący widok edytora.Batch evaluation modelu na zestawie pytań z tym samym kontekstem (np. QA nad jednym dokumentem) — cache miss raz, hit dla wszystkich pozostałych pytań.Wielowarstwowe pipeline'y (system → tools → policy → user) gdzie warstwy z góry zmieniają się znacznie rzadziej niż z dołu.

Jak działa

1. Hashing prefiksu: silnik inferencji haszuje sekwencję tokenów prefiksu (np. SHA-256 lub szybszy xxHash). Hash służy jako klucz do tablicy cache w pamięci akceleratora.

2. Lookup: przed prefillem silnik sprawdza, czy KV-cache dla danego prefiksu (lub jego najdłuższego pasującego początku) jest już w pamięci. Trafienie = pominięcie obliczania attention dla tych tokenów.

3. Częściowe trafienie (prefix match): jeśli nowy prompt dzieli z cache'owanym pierwsze N tokenów, silnik reuse'uje KV dla tych N i prefilluje tylko ogon. Stąd wymóg statyczna-na-początku, dynamiczna-na-końcu layout.

4. Eviction policy: cache ma ograniczoną pojemność (LRU, LFU, lub explicit TTL). Anthropic używa 5-min/1-godz TTL z explicit `cache_control`. OpenAI automatycznie zachowuje cache przez minuty po ostatnim użyciu. vLLM/SGLang używają LRU na poziomie bloków pamięciowych (PagedAttention).

5. Rozliczenie kosztu: tokeny prefiksu zapłacone raz przy „cache write" (Anthropic: 1.25× normalnej ceny), kolejne odczyty znacznie tańsze (Anthropic 0.1×, OpenAI 0.5×, Google ~0.25×). Tokeny generowane (output) zawsze pełna cena.

6. Layout cache-friendly: aby zmaksymalizować trafienia, prompt projektuje się jako [system + tools + dokumenty + RAG] (statyczne, cached) || [pytanie użytkownika + history] (dynamiczne, prefill każdorazowo).

Rozwiązany problem

Prefill jest dominującym kosztem inferencji dla aplikacji z długim, powtarzającym się kontekstem: chatboty z dużym system promptem, agenci z definicjami narzędzi, RAG z masywnymi chunkami, IDE AI z całym monorepo w kontekście. Bez prompt cachingu każde zapytanie odpłaca ten sam rachunek za prefill, mimo że 95% kontekstu się nie zmienia. Prompt caching rozwiązuje ten problem przez „zapamiętanie" pracy włożonej w przetworzenie wspólnego prefiksu. Efekt: 50–90% redukcja kosztu i 5–10× szybsze TTFT dla zapytań trafiających w cache. Przy ścisłej kontroli layoutu promptu (static-then-dynamic) cache hit rate w produkcji rutynowo przekracza 80%.

Kluczowe mechanizmy

Persistencja KV-cache między requestami (a nie tylko w obrębie jednej generacji).

Hashing prefiksu jako klucz lookup; częściowe dopasowanie longest-prefix.

Block-level allocation (PagedAttention) umożliwiające współdzielenie i copy-on-write.

Tree-based indeks prefiksów (RadixAttention w SGLang) automatycznie wykrywający wspólne początki.

Eviction policy z TTL (explicit Anthropic, automatic OpenAI) lub LRU (vLLM/SGLang).

Mocne strony i ograniczenia

Mocne strony

✓50–90% redukcja kosztu tokenów wejściowych dla typowych workloadów z powtarzającym się kontekstem.

✓5–10× szybsze TTFT dla cache hits — kluczowe dla UX chatbotów i agentów.

✓Bez zmian w treningu modelu — czysto runtime optimization, kompatybilna ze wszystkimi modelami autoregresywnymi.

✓Wsparcie u wszystkich major providers (Anthropic, OpenAI, Google, DeepSeek) i open-source (vLLM, SGLang, llama.cpp).

✓Wymusza dobrą higienę prompt engineering — statyczne na początku, dynamiczne na końcu.

Ograniczenia

✗Ścisłe wymaganie identycznego prefiksu — jeden token różnicy unieważnia cache.

✗Cache write premium — pierwsze użycie droższe niż normalny prefill.

✗Duże zużycie HBM — limituje liczbę jednoczesnych cached kontekstów.

✗TTL prowadzący do nieprzewidywalnych cache miss w aplikacjach z bursty traffic.

✗Brak interoperacyjności cache między dostawcami (Anthropic cache nieprzenośny do OpenAI).

✗Wymaga świadomego projektowania promptu — łatwo nieintencjonalnie zniweczyć cache (np. embedded timestamp).

Komponenty

KV-cache

Prefix hash / lookup index

Eviction policy

Block / page allocator

Cache-friendly prompt layout

Implementacja

Implementacje referencyjne

vLLM — automatic prefix caching (PagedAttention)

SGLang — RadixAttention

Anthropic Prompt Caching docs

OpenAI Prompt Caching docs

Google Vertex AI Context Caching

llama.cpp prompt caching (`--prompt-cache`)

Pułapki implementacyjne

Invalidacja przez jeden token w środku prefiksuWysoka

Cache działa tylko na ścisłym dopasowaniu prefiksu. Zmiana daty, znacznika czasowego lub user ID w środku system prompta unieważnia cały cache od tej pozycji. Mitigacja: zmienne dynamiczne zawsze przesuwać na koniec promptu.

Cache write premiumŚrednia

Pierwszy zapis do cache kosztuje więcej niż normalny prefill (Anthropic: 1.25×). Caching ma sens dopiero, gdy ten sam prefiks zostanie odczytany ≥2 razy w TTL.

VRAM jako wąskie gardłoWysoka

KV-cache 100k tokenów dla modelu 70B = dziesiątki GB HBM per cached prefix. Self-hosted vLLM/SGLang szybko wyczerpują pamięć przy wielu długich cache'ach jednocześnie.

TTL i unpredictable cache missŚrednia

Cache wygasa po TTL (Anthropic 5min/1h, OpenAI „minuty"). Aplikacje z nierównomiernym ruchem (sporadyczne zapytania) tracą cache i płacą za odbudowę. Mitigacja: keep-alive ping lub explicit `cache_control` 1h.

Cross-tenant cache poisoning (teoretyczne)Niska

Współdzielenie cache między tenantami (jeśli dostawca chmury naive'owo dzieli prefix cache między klientami) może wycieknąć timing-side-channel istnienia prefiksu w cache. Wszyscy major providers izolują cache per organization / API key.

Ewolucja

Oryginalny paper · 2023 · SOSP 2023 · Woosuk Kwon

Efficient Memory Management for Large Language Model Serving with PagedAttention

Woosuk Kwon, Zhuohan Li, Siyuan Zhuang, Ying Sheng, Lianmin Zheng, Cody Yu, Joseph E. Gonzalez, Hao Zhang, Ion Stoica

2019

GPT-2 (OpenAI) — standardowy KV-cache w obrębie pojedynczej generacji autoregresywnej.

Transformer (koncept)

2022

FlashAttention (Dao et al.) — IO-aware exact attention, sprzyja efektywnemu reuse KV w pamięci HBM.

2023

PagedAttention / vLLM (Kwon et al., UC Berkeley) — wprowadza block-level KV-cache management; podstawa automatic prefix caching.

2024

SGLang (Zheng et al., LMSYS) — RadixAttention: tree-based KV-cache sharing umożliwiające automatyczne wykrywanie i reuse wspólnych prefiksów wieloma zapytaniami.

2024

Anthropic (sierpień 2024) — explicit prompt caching z `cache_control`, 10× cheaper cached tokens, 5-min TTL.

LLM (koncept)

2024

OpenAI (październik 2024) — automatic prompt caching dla wszystkich modeli GPT-4o/o1, 50% rabat bez zmian w API.

LLM (koncept)

2024

Google Vertex AI / Gemini API — context caching z user-controlled TTL i explicit cache resource API.

2024

DeepSeek API — automatic prefix caching z agresywnymi rabatami (do 90% na cached tokens) jako element strategii kosztowej.

2025

Anthropic dodaje 1-hour TTL i extended cache (multi-tier) dla bardzo długich kontekstów; cache reuse staje się standardem w agentach Claude Code.

2025

llama.cpp i Ollama implementują automatic prefix caching dla lokalnej inferencji, demokratyzując technikę poza centra danych.

Paradygmat wykonania

Tryb główny

dense

Wzorzec aktywacji

all_paths_active

Równoległość

Poziom równoległości

fully_parallel

Zakres

inference

Ograniczenia

!Cache lookup i partial-prefix match są trywialnie równoległe per request. Współdzielenie cache między requestami jednego workera (vLLM, SGLang) wymaga synchronizacji na poziomie alokatora bloków, ale skaluje się dobrze w wielu strumieniach.