Czym jest prompt caching? Jak powtarzający się prompt jest ponownie wykorzystywany

Prompt caching oznacza, że API zapamiętuje początek Twojego żądania i używa go ponownie, gdy następnym razem wyślesz ten sam początek. Nadal wysyłasz cały tekst przy każdym wywołaniu, ale dostawca może pominąć pracę polegającą na ponownym odczytaniu powtarzającej się części, a niektórzy dostawcy rozliczają tę część po niższej stawce. Działa to tylko na początku żądania i tylko wtedy, gdy ten początek jest identyczny.

Bot wsparcia, który w kółko czyta tę samą stronę#

Załóżmy, że prowadzisz bota wsparcia z 2 000 zgłoszeń dziennie. Każde żądanie zaczyna się od tych samych 3 000 tokenów: ton głosu, zasady zwrotów, polityka wysyłki. Potem przychodzi jednolinijkowa wiadomość klienta, coś w rodzaju „Gdzie jest moje zamówienie?”. (Jeśli tokeny wciąż są dla Ciebie niejasne, zacznij od czym jest token.)

Bez cachowania dostawca odczytuje ponownie wszystkie 3 000 tokenów zasad dla zgłoszenia numer 1, zgłoszenia numer 2 i zgłoszenia numer 2 000. Ta sama strona, czytana 2 000 razy. Z cachowaniem pierwsze żądanie płaci pełną cenę za jej odczyt, a późniejsze żądania zaczynające się od tego samego tekstu mogą ponownie wykorzystać tę pracę.

Przewodnik po API DeepSeek (sprawdzony 24 października 2026) opisuje dokładnie to: cachowanie kontekstu jest domyślnie włączone, nie wymaga zmian w kodzie, a późniejsze żądanie z nakładającym się prefiksem liczy się jako „trafienie w cache”. Cachowane są tylko dane wejściowe. Odpowiedź jest generowana od nowa za każdym razem.

Co liczy się jako „to samo”: reguła prefiksu#

Cache dopasowuje od pierwszego znaku. W momencie, gdy Twoje żądanie różni się od cachowanego, wszystko po tym punkcie jest nowe. Dlatego kolejność w żądaniu ma większe znaczenie niż jego długość.

Oto błąd, który po cichu zabija cachowanie. Programista chce, żeby bot znał czas, i umieszcza go na górze:

Current time: 14:03:22
You are a support assistant for a shop...
(3,000 tokens of rules)

Czas zmienia się co sekundę, więc już pierwsza linia różni się przy każdym żądaniu i nic po niej nie może się dopasować. Rozwiązaniem jest przeniesienie tego, co się zmienia, na koniec:

You are a support assistant for a shop...
(3,000 tokens of rules)
Current time: 14:03:22
Customer: Where is my order?

Teraz 3 000 tokenów zasad jest na początku i pozostaje identyczne. Ta sama logika obejmuje dwa pozostałe typowe przypadki: długi czat wysyła całą swoją historię przy każdej turze, więc stare wiadomości są gotowym, powtarzającym się początkiem (więcej na ten temat w dlaczego długi czat kosztuje więcej), a agent powtarza swoje definicje narzędzi i instrukcje przy każdym kroku.

Cachowanie jest też najlepszym wysiłkiem. DeepSeek mówi, że zbudowanie cache zajmuje kilka sekund, trafienie wymaga pełnego dopasowania istniejącej jednostki prefiksu cache, nie ma gwarantowanego współczynnika trafień, a nieużywane cache są czyszczone, zwykle w ciągu godzin do dni. Więc drugie żądanie wysłane pół sekundy po pierwszym może jeszcze nie trafić, a trafienie może obejmować mniej niż cały Twój prefiks.

Jak to zobaczyć: pola cache w usage#

Nie musisz zgadywać, czy zadziałało. Każdy dostawca raportuje to w części usage odpowiedzi, pod własnymi nazwami pól.

DeepSeek używa dwóch pól:

• prompt_cache_hit_tokens — tokeny wejściowe znalezione w cache
• prompt_cache_miss_tokens — tokeny wejściowe, których nie znaleziono

Załóżmy, że Twoje pierwsze zgłoszenie wsparcia wraca z prompt_cache_hit_tokens: 0 i prompt_cache_miss_tokens: 3200, a zgłoszenie minutę później pokazuje prompt_cache_hit_tokens: 3000 i prompt_cache_miss_tokens: 200. 3 000 tokenów zasad zostało ponownie wykorzystanych; od zera odczytano tylko nową wiadomość klienta i kilka tokenów. Jeśli liczba trafień pozostaje zerowa przy każdym wywołaniu, spójrz na początek swojego żądania: coś tam się zmienia.

Anthropic działa inaczej, ponieważ to Ty oznaczasz, co ma być cachowane. Dodajesz cache_control z typem ephemeral do żądania lub do bloku treści:

{
  "model": "your-model-id",
  "max_tokens": 300,
  "system": [
    {
      "type": "text",
      "text": "You are a support assistant... (long rules)",
      "cache_control": {"type": "ephemeral"}
    }
  ],
  "messages": [{"role": "user", "content": "Where is my order?"}]
}

Zgodnie z dokumentacją prompt caching Anthropic (sprawdzoną 24 października 2026) odpowiedź raportuje trzy liczby: cache_creation_input_tokens (zapisane do cache teraz), cache_read_input_tokens (odczytane z niego) i input_tokens (to, co przyszło po ostatnim punkcie przerwania cache). Załóżmy, że pierwsze wywołanie pokazuje cache_creation_input_tokens: 10000, cache_read_input_tokens: 0; drugie pokazuje 0 i 10000. To zapis do cache, po którym następuje odczyt z cache.

Na ekranie jest jedna pułapka. Prompty krótsze niż minimum modelu (512, 1 024 lub 4 096 tokenów, w zależności od modelu) są przetwarzane bez cachowania i bez błędu. Zobaczysz zera w obu polach cache i żadnego ostrzeżenia. Domyślny czas życia to 5 minut, odświeżany bezpłatnie przy każdym użyciu; opcjonalny ttl o wartości 1h utrzymuje go dłużej.

Co to robi z Twoim rachunkiem#

Cachowanie zmienia cenę powtarzającej się części, więc warto to raz policzyć. Anthropic podaje mnożniki względem bazowej ceny wejścia: zapis do cache z 5-minutowym czasem życia kosztuje 1,25×, odczyt kosztuje 0,1× (0,05× dla Opus 5.5 i Sonnet 5.5). Weźmy prefiks 10 000 tokenów używany ponownie w 20 żądaniach w oknie 5 minut, przy standardowym odczycie 0,1×:

10 000 × 20 = 200 000 tokenów po cenie bazowej bez cachowania

10 000 × 1,25 = 12 500 dla pierwszego żądania, które zapisuje cache

19 × 10 000 × 0,1 = 19 000 dla 19 żądań, które go odczytują

12 500 + 19 000 = 31 500 ekwiwalentów tokenów z cachowaniem

Zatem powtarzająca się część kosztuje znacznie mniej niż jedną piątą kwoty bez cachowania. Haczyk: jeśli między żądaniami minie 5 minut, następne żądanie ponownie zapisze cache po 1,25×, a rzadko używany prefiks może ostatecznie kosztować więcej niż brak cachowania.

Teraz bot z początku, jako zwykła linia bazowa po pełnej cenie. 2 000 żądań dziennie, 3 000 tokenów wejściowych i około 300 tokenów wyjściowych każde:

2 000 × 3 000 = 6 000 000 tokenów wejściowych dziennie

2 000 × 300 = 600 000 tokenów wyjściowych dziennie

Tabela wycenia ten dzienny wolumen pracy na każdym dostępnym modelu CheapTokens obok OpenRouter:

DeepSeek-V4-Flash jest tańszy niż OpenRouter łącznie, licząc wejście i wyjście razem, a wolumen pracy mieści się z łatwością: kontekst 380K i do 32 768 tokenów wyjściowych na odpowiedź. To koszt wolumenu pracy po pełnej cenie: tokeny wejściowe × cena za token. Długi, stabilny prefiks to miejsce, gdzie udział wejścia jest największy.

Wypróbuj sam w pięć minut#

Plan: wyślij ten sam długi prompt systemowy dwa razy z różnymi pytaniami i sprawdź usage. Wstaw własny tekst zasad do support_rules.txt (wystarczy strona lub dwie tekstu). Endpoint to zgodne z OpenAI API CheapTokens, a klucz możesz pobrać ze swojego konta.

from openai import OpenAI

client = OpenAI(base_url='https://api.cheaptokens.dev/v1', api_key='YOUR_API_KEY')

SYSTEM = open('support_rules.txt').read()  # long, never changes

for question in ['Where is my order?', 'Can I change the address?']:
    r = client.chat.completions.create(
        model='deepseek-ai/DeepSeek-V4-Flash-0731',
        messages=[
            {'role': 'system', 'content': SYSTEM},
            {'role': 'user', 'content': question},
        ],
        max_tokens=300,
    )
    print(r.usage)

Co sprawdzić w wydruku: prompt_tokens mówi, jak duże jest Twoje żądanie. Oba żądania zawierają ten sam tekst SYSTEM, więc większość tej liczby powtarza się z jednego żądania do następnego — w przybliżeniu to rozmiar Twojego pliku zasad. Ten powtarzający się początek to część, którą dostawca z cachowaniem, jak API DeepSeek lub Anthropic powyżej, może ponownie wykorzystać. Teraz ćwiczenie z kolejności: dodaj linię z bieżącym czasem (datetime.now()) na górze SYSTEM i uruchom ponownie. Oba żądania nie dzielą już początku, ponieważ różnią się od samej pierwszej linii. Umieść tę samą linię na końcu promptu, a wspólny początek wraca.

Krótka lista kontrolna dla własnych promptów:

1. Najpierw stabilny tekst: instrukcje, zasady, definicje narzędzi, przykłady.
2. Zmienny tekst na końcu: data, nazwa użytkownika, najnowsza wiadomość.
3. Utrzymuj prefiks identyczny co do bajtu — liczy się nawet dodatkowa spacja.
4. Sprawdź minimalny rozmiar dostawcy, zanim zaczniesz się zastanawiać, dlaczego nic nie jest cachowane.
5. Spójrz na pola usage po zmianie, nie przed.

Aby wycenić własny wolumen pracy, otwórz stronę z cennikiem i wpisz swoje rozmiary wejścia i wyjścia, albo zacznij od strony DeepSeek. Gdy pierwsze żądanie zadziała, ta sama estymacja zajmie minutę dla dowolnego promptu, który napiszesz. Aby dowiedzieć się, ile kosztują obie strony żądania, zobacz tokeny wejściowe vs wyjściowe.