Prompt Caching: Ako znížiť náklady na API volania až o 90 percent

Prompt caching je technika, ktorá umožňuje opakovane použiť už vypočítanú časť kontextu LLM namiesto jej prepočítavania pri každom volaní — výsledkom sú dramaticky nižšie náklady a kratšia latencia pre každú produkčnú AI aplikáciu.

1. Prečo je prompt caching dôležitý

Každé volanie LLM API stojí peniaze za tokeny na vstupe. V reálnych aplikáciách sa však veľká časť tohto vstupu opakuje:

  • Systémový prompt — inštrukcie, persona, guardrails — zvyčajne niekoľko stoviek až tisíc tokenov, identický v každom volaní
  • Dokumenty a znalostná báza — keď aplikácia posiela rovnaké súbory pre odpovede na otázky
  • História konverzácie — v dlhých chatoch staré správy sa neustále opakujú na začiatku každého requestu
  • Agentické slučky — agent volá model viackrát za úlohu so stálym kontextom (systémový prompt + nástroje + doterajší priebeh)

Bez caching každé volanie prepočíta všetky vstupné tokeny od nuly. Pri modeli s cenou $3 na milión tokenov a aplikácii s 1 000 requestmi denne, kde systémový prompt má 2 000 tokenov — to je $6 denne, $180 mesačne len za opakujúci sa prefix. Prompt caching tento náklad redukuje na zlomok.

2. Ako prompt caching funguje

LLM pri spracovaní vstupu vypočíta pre každý token tzv. KV cache (kľúče a hodnoty v attention mechanizme). Táto výpočtová práca je najdrahšia časť inferencie.

Bez cachingu:

Request 1: [systém: 2000 tok] + [otázka: 50 tok] → LLM prepočíta 2 050 tokenov
Request 2: [systém: 2000 tok] + [otázka: 60 tok] → LLM prepočíta 2 060 tokenov

S cachingom:

Request 1 (cache miss):  prepočíta 2 050 tok, prefix uloží do cache
Request 2 (cache hit):   načíta prefix z cache, prepočíta len 60 tok

Cache funguje ako snímka KV stavu po spracovaní prefixu. Kľúčová podmienka: prefix musí byť tokenovo identický — aj jedna zmena na začiatku promptu zneplatní celú cache.

Existujú dve hlavné implementačné filozofie:

  • Explicitné caching (Anthropic): Vývojár označí miesta v prompte špeciálnym parametrom cache_control, čím presne určí, kde má provider uložiť snímku.
  • Automatické caching (OpenAI): Provider sám detekuje opakujúce sa prefixy a cachuje ich bez akýchkoľvek zmien v kóde klienta.

3. Porovnanie u hlavných poskytovateľov

Poskytovateľ Modely TTL cache Zľava na cachovanie Min. tokeny Typ
Anthropic Claude 3.5+, Claude 4.x 5 min (refresh pri hite) −90 % z ceny vstupu 1 024 Explicitný
OpenAI GPT-4o, GPT-4o mini 1 hodina −50 % z ceny vstupu 1 024 Automatický
Google Gemini 1.5+, Gemini 2.x 1 hodina (konfig.) −75 % z ceny vstupu 32 768 Explicitný (Context Caching API)

Dôležité nuansy:

  • Anthropic účtuje jednorazový poplatok za zápis cache — prvý request, kde sa cache vytvára, je o ~25 % drahší. Pri každom ďalšom hite platíte len 10 % pôvodnej ceny vstupu.
  • Google Context Caching je samostatné API s osobitnou správou životného cyklu — vhodné pre veľmi dlhé dokumenty, minimálny limit je však výrazne vyšší.
  • OpenAI automatický caching funguje bez zmeny kódu, čo je výhodou pri integrácii do existujúcich projektov.

4. Praktická implementácia

Anthropic — explicitné cache_control:

import anthropic

client = anthropic.Anthropic()

system = [
    {
        "type": "text",
        "text": "Si odborný asistent na analýzu právnych dokumentov...\n" + dlhy_pravny_kontext,
        "cache_control": {"type": "ephemeral"}  # označenie konca cachovaného prefixu
    }
]

response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    system=system,
    messages=[{"role": "user", "content": pouzivatelska_otazka}]
)

# response.usage obsahuje:
# cache_creation_input_tokens: 2000  (prvý request — zápis)
# cache_read_input_tokens: 2000      (ďalšie requesty — čítanie)

Kedy caching najviac pomáha:

  1. RAG aplikácie — rovnaké dokumenty posielané ku každej otázke
  2. Chatboty s dlhými systémovými promptmi — inštrukcie, guardrails, persony
  3. Agentic workflows — agent volá model desaťkrát za úlohu so stálym kontextom
  4. Nástroje na analýzu kódu — veľký kódový kontext + krátka otázka
  5. Batch spracovanie — rovnaký prompt template na veľkom počte vstupov

Praktické pravidlo: ak viac ako 50 % vašich vstupných tokenov je identických naprieč requestmi, prompt caching je pravdepodobne rentabilná optimalizácia.

5. Limity, riziká a smer vývoja

Technické obmedzenia:

  • Presnosť prefixu: Cache funguje len pri tokenovo identickom prefixe. Aj zdanlivo neviditeľná zmena (medzera navyše, iné poradie parametrov v JSON) spôsobí cache miss a celý prefix sa prepočíta od nuly.
  • TTL expirácia: Ak requesty prichádzajú s dlhšou pauzou ako je životnosť cache, snímka expiruje. Nočný batch processing môže mať zásadne iný hit rate než real-time chat.
  • Izolácia: Cache nie je zdieľaná medzi rôznymi verziami modelu ani medzi rôznymi API kľúčmi — každý účet má vlastnú cache.
  • Len vstupné tokeny: Caching neovplyvňuje cenu za generovanie výstupu. Pre aplikácie s dlhými odpoveďami je úspora proporcionálne nižšia.

Čo caching nerieši:

Pre krátke prompty pod minimálny limit (1 024 tokenov u Anthropic a OpenAI) caching jednoducho nefunguje. Taktiež nepomáha pri vysoce variabilných promptoch, kde sa prefix mení pri každom volaní — v takom prípade je hit rate blízky nule.

Smer vývoja:

Trendom je posun k plne automatickému cachingu bez nutnosti akýchkoľvek anotácií v kóde — podľa vzoru OpenAI. Anthropic experimentuje s dlhšími TTL a inteligentnejšou správou cache pre agentické workflowy. Objavujú sa tiež diskusie o zdieľanom cache pre verejné systémové prompty — keby napríklad všetci používatelia rovnakého open-source projektu zdieľali cache identického systémového promptu, úspora pri scale by bola rádovo vyššia. Tento model zatiaľ nie je v produkcii, ale smeruje k nemu ekosystém inference-as-a-service platforiem.

Zhrnutie: Prompt caching je dnes jedna z najefektívnejších optimalizácií pre produkčné LLM aplikácie — s minimálnym implementačným úsilím a potenciálom ušetriť 50 až 90 % nákladov na opakujúce sa vstupné tokeny pri každej aplikácii, ktorá odosiela rovnaký kontext viackrát za deň.