Vo väčšine produkčných LLM aplikácií tvorí systémový prompt, kontextová dokumentácia alebo história konverzácie väčšinu vstupného textu pri každom volaní. Ak má váš systémový prompt tisíc tokenov a denne obslúžite desaťtisíc požiadaviek, zaplatíte za desať miliónov tokenov — z ktorých väčšina je zakaždým ten istý text. Prompt caching tento problém rieši na úrovni infraštruktúry: provider uloží KV reprezentáciu opakujúcich sa prefixov a pri ďalšom volaní ich znovu nevypočítava.
Tento článok vysvetlí, ako prompt caching funguje pod kapotou, za akých podmienok výrazne zníži cenu aj latenciu, čo konkrétne cachovať a kedy naopak caching nepomôže — alebo dokonca pridá náklady. Súvisí to tiež s tým, ako navrhnúť prompty, ktoré sa dobre cachovajú, čo je téma, ktorú mnohé tímy prehliadnu.
Ako prompt caching funguje
Keď posielate request na LLM API, model na každý vstupný token vypočíta tzv. KV cache (key-value vektory) — to je základ mechanizmu self-attention, cez ktorý model vyhodnocuje súvislosti medzi tokenmi. Tento výpočet nie je zadarmo: je to práca GPU, ktorá priamo ovplyvňuje cenu aj čas do prvého tokenu (TTFT).
Prompt caching (nazývaný tiež context caching alebo prefix caching) hovorí: ak je začiatok promptu — prefix — rovnaký naprieč viacerými volaniami, provider vypočíta jeho KV reprezentáciu raz, uloží ju na serveri a pri ďalších requestoch ju jednoducho načíta namiesto prepočtu. Z pohľadu volajúceho sa to javí transparentne — odpovede sú rovnako správne, len lacnejšie a rýchlejšie.
Čo to znamená v číslach:
- U Anthropic: cache read = 10 % bežnej ceny vstupného tokenu (90 % úspora); cache write = 125–200 % bežnej ceny vstupného tokenu (mierne predraženie pri prvom zápise)
- U OpenAI: automatické, cache read = 50 % bežnej ceny; bez explicitného kódu zo strany volajúceho
- Reálna úspora v produkcii: typicky 50–70 % celkových nákladov na vstupné tokeny pri workloade s dlhými opakujúcimi sa prefixmi
Ekonomika teda vyzerá takto: prvé volanie za cache write zaplatíte trochu viac, ale každé ďalšie čítanie rovnakého prefixu je výrazne lacnejšie. Zisk nastáva od druhého čítania, pri tisícoch volaní denne je úspora podstatná.
TTL a konzistencia prefixu
Kešovaný prefix nevydrží večne. Anthropic ponúka TTL (time-to-live) 5 minút alebo 1 hodinu — po uplynutí sa cache invaliduje a pri ďalšom volaní sa prefix znovu prepočíta (opäť cache write). OpenAI má automatickú správu TTL bez explicitného nastavenia.
Z toho plynú dve praktické dôsledky. Prvý: ak máte workload, kde prichádzajú requesty s rovnakým prefixom v krátkom čase (napríklad v priebehu sekúnd alebo minút), caching funguje dobre. Ak sú requesty rozložené cez celý deň s hodinovými prestávkami a používate 5-minútový TTL, cache sa bude pravidelne invalidovať. Druhý: prefix musí byť byte-for-byte identický. Aj malá zmena (iná medzera, inak zformátovaný dátum v systémovom prompte) zneplatní celú kešovanú reprezentáciu a spustí nový cache write.
Čo má zmysel cachovať
Nie každý text v prompte sa cacheovať oplatí. Výber vychádza z jednoduchej logiky: cachovať má zmysel to, čo je dlhé, statické a opakovane používané.
Systémový prompt. Najzrejmejší kandidát. Ak máte 500–2000 tokenov systémových inštrukcií (rola, kontext, pravidlá správania, príklady few-shot), tieto sa vo väčšine aplikácií nemenia vôbec alebo len zriedka. Uložte ich ako pevný prefix na začiatku promptu — caching ich pokryje automaticky.
Zdieľané dokumenty a normy. Ak každý request obsahuje tú istú technickú príručku, ISO normu, firemné predpisy alebo právny dokument ako referenčný kontext, je to ideálny kandidát. Videli sme nasadenia, kde sa 300-stranová technická dokumentácia vkladá do každého volania zákazníckeho chatbota — caching tam znížil náklady o viac ako 80 %.
Dlhá historia konverzácie. Pri multi-turn chatoch posiela aplikácia celú predchádzajúcu históriu s každým novým requestom. Staršia časť histórie sa nemení — je to rastúci stabilný prefix. Caching tu funguje, pokiaľ aplikácia konverzáciu konzistentne formátuje a nepreusporadúva správy.
Few-shot príklady. Ak používate v systémovom prompte niekoľko dlhých príkladov vstup–výstup (tzv. few-shot prompting), aj tieto sú statické a opakovateľné. Zaraďte ich do cacheovaného prefixu.
Čo naopak cachovať nemá zmysel:
- Krátke alebo jednorazové prompty — cache write zaplatíte viac, ale nikdy nevyberete zisk
- Prompty, kde sa každý request líši od začiatku (napríklad generovanie variabilných reportov bez spoločného prefixu)
- Systémy s nekonzistentným formátovaním — náhodná zmena poradia parametrov v systémovom prompte stačí na invalidáciu cache
Ako navrhnúť prompty pre caching
Jedno z najčastejších opomenutí, s ktorým sa stretávame pri revízii existujúcich aplikácií: tímy zapnú caching, ale štruktúra promptu nie je navrhnutá tak, aby ho efektívne využívala.
Základné pravidlo: statické pred dynamickým. Caching pokrýva prefix — začiatok promptu. Preto všetko, čo sa mení per-request (konkrétna otázka používateľa, variabilné parametre, aktuálny dátum), musí byť na konci promptu. Ak vložíte dynamický element doprostred statického kontextu, prefix sa zakaždým zmení a caching nezaberie.
Príklad nesprávneho poriadku:
Systémový prompt (statický)
↓
Aktuálny dátum a meno používateľa (dynamické — mení sa pri každom requeste)
↓
Technická príručka (statická, 800 tokenov)
↓
Otázka používateľa (dynamická)V tomto príklade dynamický element v strede zneplatní caching pre celú technickú príručku nižšie.
Správny poriadok:
Systémový prompt (statický)
↓
Technická príručka (statická, 800 tokenov)
↓
Aktuálny dátum a meno používateľa (dynamické)
↓
Otázka používateľa (dynamická)Statický blok je teraz súvislý prefix — provider ho kešuje a dynamické elementy ho neovplyvnia.
Stabilné formátovanie. Ak váš systémový prompt generuje kód, vyhýbajte sa vkladaniu premenlivých hodnôt (timestamp, verzia) priamo do statickej časti. Namiesto Aktuálna verzia systému: 2.4.1 (nasadená 2026-03-20) použite Aktuálna verzia systému: {version} a hodnotu vložte až do dynamickej časti alebo, lepšie, v user message.
Na on-prem (vLLM, SGLang) platia rovnaké princípy. vLLM aj SGLang implementujú prefix caching vlastnou cestou — SGLang cez RadixAttention (LRU strom KV kešov), vLLM cez PagedAttention s prefix-aware blokovým manažmentom. Oba frameworky automaticky rozpoznajú opakujúce sa prefixy a neopakujú ich výpočet. Detaily líšia, ale dizajnový princíp — statické pred dynamickým — platí rovnako. Viac o výbere serving frameworku nájdete v vLLM vs SGLang vs Ollama.
Kedy caching výrazne pomôže — a kedy nie
Jednoduchý test: spočítajte, koľko percent vstupných tokenov tvorí opakujúci sa statický prefix. Ak je to nad 50 %, caching je pravdepodobne zmysluplná investícia. Ak je každý request unikátny, caching nepomôže.
Scenáre s vysokou úsporou:
- RAG s dlhým kontextom. Aplikácie, ktoré pri každom volaní vkladajú tú istú zdieľanú dokumentáciu ako kontext (firemné predpisy, príručky, normy). Kešovaný kontext sa načíta za 10 % ceny.
- Zákaznícka podpora s dlhými systémovými promptami. Typický produkčný zákaznícky chatbot má systémový prompt 500–1500 tokenov popisujúci produkt, pravidlá, tón a príklady. Pri tisícoch volaní denne je úspora podstatná.
- Multi-turn agenti s akumulujúcou históriou. Konverzačné relácie, kde sa história zapisuje do kontextu. Staršia čast histórie sa stáva stabilným prefixom — caching tu rastie organicky s dĺžkou konverzácie. Priamo súvisí s tým, ako riadiť náklady AI agenta v produkcii.
- Batch processing dokumentov so spoločnými inštrukciami. Ak spracovávate tisíce faktúr, servisných zápisníkov alebo objednávok s rovnakými inštrukciami extrakcie, inštrukcie sa kešujú a platíte len za samotné dokumenty.
Scenáre s nízkou alebo nulovou úsporou:
- Generatívne one-shot úlohy. Napíšte mi anotáciu k tomuto videu, preložte tento text, vygenerujte správu — každý request je unikátny aj v systémovej časti. Cache write zaplatíte navyše, ale nikdy z neho nevyberete.
- Workload s nízkym objemom. Ak aplikácia robí sto volaní za deň, absolútne úspory sú malé. Overhead na implementáciu (refaktoring promptov, monitorovanie hit rate) sa nemusí vrátiť.
- Krátke systémové prompty. Ak máš systémový prompt 50 tokenov, minimálna veľkosť pre cachovanie (Anthropic vyžaduje prefix dlhý aspoň 1024 tokenov) ani nie je splnená.
Meranie efektívnosti cacheovania
Nasadenie bez merania je navigácia naslepo. Tri metriky, ktoré sledovať:
Cache hit rate. Pomer requestov, kde sa prefix načítal z cache, voči celkovým requestom. U Anthropic vráti API v odpovedi cache_read_input_tokens a cache_creation_input_tokens. OpenAI vracia cached_tokens v usage objekte. Cieľ: pri správne štruktúrovaných promptoch by hit rate mal byť 80–95 % pri stabilnom workloade.
Priemer vstupných tokenov per request. Ak caching funguje, efektívna cena vstupných tokenov klesne — cache read tokeny sa účtujú lacnejšie. Sledujte pohyblivý priemer nákladov na vstup per request v čase.
TTFT (Time to First Token). Cached prefix eliminuje prepočet, čo skráti TTFT. Ak vidíte bimodálne rozdelenie latencie (niektoré requesty rýchlejšie, iné pomalšie), je to pravdepodobne dôsledok rozdielov medzi cache hit a cache miss.
Tieto metriky zaraďte do vášho observability pipeline — napríklad cez štruktúrované logy alebo sledovanie v agent observability a tracing.
Porovnanie cloudových providerov
Prístupy sa líšia aj v detailoch implementácie, čo ovplyvňuje, ako caching dizajnujete.
Anthropic (Claude): Explicitné — v requeste musíte označiť bloky, ktoré chcete kešovať pomocou cache_control parametra. Dáva vám kontrolu nad tým, čo presne sa kešuje. TTL 5 minút alebo 1 hodina (podľa nastavenia). Minimum pre kešovanie: 1024 tokenov. Cache write je 125–200 % ceny bežného vstupného tokenu; cache read je 10 %.
OpenAI (GPT): Implicitné — automatické, bez kódu. Provider sám rozpoznáva opakujúce sa prefixy a kešuje ich. Cache read = 50 % ceny vstupného tokenu. Jednoduchšie na zapnutie, menej kontroly nad tým, čo sa kešuje.
Google (Gemini): Explicit context caching cez API, podobné Anthropic. Dlhší TTL — hodiny až dni. Vhodné pre veľmi stabilné dlhé kontexty (celé príručky, kódové bázy).
On-prem (vLLM, SGLang): Prefix caching je vstavaný a beží automaticky pri opakujúcich sa prefixoch. Neplatíte extra za write — compute náklady sú vaše, ale pri opakovaných prefixoch serving framework ušetrí GPU čas, čo zvýši throughput a zníží latenciu. Táto výhoda je kľúčová pri privátnom nasadení s vlastným hardvérom.
Časté otázky
Je prompt caching bezpečný — ostávajú moje dáta na serveri providera?
Áno, kešovaná KV reprezentácia ostáva na serveroch providera počas TTL okna. Pre väčšinu firiem to nie je problém — API volania tam aj tak idú. Pre organizácie s prísnymi požiadavkami na data residency (nemocnice, banky, regulované odvetvia) je on-prem serving s vLLM alebo SGLang lepšou voľbou, kde cache ostáva plne pod vašou kontrolou. Viac v on-prem LLM pre regulované odvetvia.
Môže sa caching negatívne podpísať na kvalite odpovedí?
Nie — caching ovplyvňuje len to, ako rýchlo sa KV vektory pre prefix dostanú do pamäte, nie to, aké hodnoty majú. Model dostane identický kontext či sa prefix vypočítal nanovo alebo načítal z cache. Odpovede sú rovnaké.
Oplatí sa caching pre malú aplikáciu s pár stovkami volaní denne?
Záleží na dĺžke systémového promptu a cene modelu. Pre 1000-tokenový systémový prompt a 500 volaní denne s frontierovým modelom sú mesačné úspory rádovo jednotky eur — na hranici toho, či sa oplatí kód refaktorovať. Pri 50 000 volaniach denne a 2000-tokenovom prompte sú úspory rádovo stovky eur mesačne a vyššie — tam zmysel dáva jednoznačne.
Čo ak môj systémový prompt treba každú hodinu aktualizovať (napríklad vkladám aktuálny čas alebo stav skladu)?
To je klasická pasca. Ak je dynamická hodnota vo vnútri kešovaného bloku, každá jej zmena zneplatní cache. Riešenie: vytiahnite dynamickú hodnotu z kešovaného prefixu do user message alebo do nekešovaného bloku na konci promptu. Kešovaný systémový prompt sa nemení, dynamická hodnota ide vedľa neho.
Funguje prompt caching aj pri použití štruktúrovaného výstupu (JSON mode)?
Áno. Caching je nezávislý od formátu výstupu. Kešovaný prefix môže byť kombinácia systémových inštrukcií a JSON schémy, pokiaľ je statická — model podľa nej generuje, cache hit rate sa nezmení. Viac o štruktúrovanom výstupe v structured outputs a JSON mode.
Záver
Prompt caching nie je revolúcia — je to infraštruktúrna optimalizácia, ktorá funguje ticho a spoľahlivo, pokiaľ aplikáciu navrhnete tak, aby ju využívala. Kľúčové sú tri veci: identifikovať statický prefix vo svojich promptoch, umiestniť ho konzistentne na začiatok a merať hit rate. Pri workloadoch s tisícmi volaní denne a dlhými spoločnými kontextmi dokáže táto zmena znížiť faktúru za LLM API o desiatky percent bez akéhokoľvek zásahu do logiky aplikácie.
*V MP Industrial Solutions pri revízii LLM aplikácií klientov pravidelne narážame na promptové štruktúry, kde caching nie je využitý — alebo kde dynamický element uprostred statického kontextu celý efekt zmaří. Ak chcete, aby sme sa pozreli na vašu aplikáciu a identifikovali konkrétne úspory, radi sa stretneme na konzultácii.*