Build Hour: Prompt Caching — jak zrychlit a zlevnit AI aplikace pomocí kešování promptů

Obsah

• 🧠 Základní principy prompt caching
• ⚙️ Co se skutečně ukládá v cache a jak to funguje technicky
• 💸 Proč se kešování vyplatí: snížení nákladů a latence
• 🛠️ Praktický developer playbook — co dělat a proč
• 📊 Příklady a metriky z praxe
• 🚀 Případová studie: Warp — jak to dělají agenti
• ✅ Kontrolní seznam pro případ, že cache "nefunguje"
• 📈 Jak měřit, sledovat a validovat dopad kešování
• ❓ Časté otázky a mýty
• 🔑 Závěr — co bych doporučil nasadit hned

🧠 Základní principy prompt caching

Kešování promptů (prompt caching) je v jádru opětovné využití výpočetních výsledků. Když opakovaně posíláte modelu požadavky, které sdílejí stejný úvodní kontext — tzv. prefix — systém může přeskočit znovupočítání již provedených maticových operací a použít uložené mezivýsledky. To vede k nižším nákladům a kratší latenci, aniž by utrpěla kvalita odpovědí.

Klíčové body, které si pamatuji:

• Prefix znamená vše, co modelovi pošlete před tím, než začne generovat novou odpověď — systémové instrukce, obrázky, audio, předchozí zprávy atd.
• Keš začíná fungovat, jakmile je prefix alespoň 1 024 tokenů. Pod tímto prahem implicitní caching neprobíhá.
• Cache je organizovaná do bloků po 128 tokenech, přičemž validita cache vyžaduje kontinuitu — přesně stejný pořad a stejný obsah.
• Kešování je multimodální: funguje pro text, obrázky i audio a standardně se děje implicitně bez zásahu do kódu.
• Výchozí doba uložení je krátkodobá (paměťový cache 5–10 minut), ale je možné aktivovat rozšířenou prompt caching až na 24 hodin.

⚙️ Co se skutečně ukládá v cache a jak to funguje technicky

Mnohdy to pomůže nahlédnout pod kapotu. Transformery pracují hlavně díky mechanice attention. Každý token během inferencí projde vrstvami, kde se vytvářejí tři vektory — query, key a value — a model počítá podobnosti mezi nimi. Právě tento výsledek, známý jako key-value (KV) cache, je to, co se ukládá.

Attention is all you need.

To znamená několik věcí:

• Keš neobsahuje surový text, tokeny nebo embedingy. Ukládají se numerické tensory — mezivýsledky z pozornosti.
• Při novém požadavku systém nejprve zahashuje prvních 256 tokenů prefixu a podle toho zvolí engine (výpočtový stroj), na který request dopadne.
• Po výběru engine se porovnávají následující 128 tokenové bloky, dokud se nenajde první neshoda. Vše před touto neshodou se využije z cache, zbytek model dopočítá klasicky.
• Po vygenerování výstupu se cache aktualizuje tak, aby příští request měl možnost znovu použít i nově vytvořené mezivýsledky.

Tento postup vysvětluje, proč jsou dvě podmínky nutné pro efektivní kešování: stejný prefix a routování na stejný engine. Pokud se data nebo pořadí změní, nebo požadavky skončí na různých enginech, keš se nevyužije.

💸 Proč se kešování vyplatí: snížení nákladů a latence

Hlavní motivace pro cache je trojí: snížení nákladů, zrychlení odpovědí a zachování stejné inteligence modelu. Kešování samo o sobě nemění kvalitu odpovědí — pokud je prefix identický, výsledky z hlediska modelu jsou deterministicky stejné. Rozdíl je čistě v tom, že nepočítáme znovu práci, kterou už jsme jednou udělali.

Konkrétní dopady, které se osvědčily v praxi:

• Diskont tokenů u vstupu: starší modely měly menší slevy, novější rodiny modelů (řada 5.x) už nabízejí až 90 % slevu na kešované tokeny. Pro některé speech-to-speech scénáře je to až ~99 %.
• Latence: u velmi dlouhých vstupů (desítky tisíc tokenů) může být zrychlení Time-to-First-Token až o 67 % nebo více. Pro krátké prefixy je rozdíl menší.
• Ušetřené prostředky: v demonstrovaných příkladech dávkového zpracování obrázků šlo o snížení ceny z ~35 centů na zpracování spousty položek na ~21–23 centů díky keši. To se škáluje lineárně s počtem dotazů.

🛠️ Praktický developer playbook — co dělat a proč

V praxi je kešování efektivní jen tehdy, když aplikaci navrhnete se záměrem maximalizovat cache hit rate. Níže najdete konkrétní zásady a techniky, které doporučuji implementovat.

Prompt cache key — váš nejrychlejší win

prompt_cache_key je volitelný parametr, který se přihashuje spolu s prvních 256 tokeny a pomáhá usměrnit, na který engine budou requests routovány. To je klíčové, protože každý engine stíhá omezený počet požadavků za minutu (přibližně 15 RPM) a bez shardování se traffic rozpráší na více enginech a keš není sdílená.

Doporučení:

• Pro vysokou opakovatelnost použijte prompt_cache_key a určete granularitu: per-task, per-conversation nebo per-user podle toho, co dává smysl.
• Neudělejte klíč příliš jemný — over-sharding vede k rozdrobení cache a menšímu využití.
• Příklady dopadu: u jednoho zákazníka kešovací míra stoupla z 60 % na 87 % poté, co začal používat dobře zvolený prompt_cache_key.

Responses API místo Chat Completions (pokud používáte reasoning modely)

Pokud používáte modely, které interně generují chain-of-thought (vnitřní řetězec myšlení), tyto tokeny jsou přenášeny pouze skrze Responses API. Chat completions tyto skryté reasoning tokeny neudržuje, což vede k horšímu cache hit rate a zároveň ztrátě důležité informace pro kvalitu. Přechod na Responses API tak může výrazně zvýšit cache z ~40 % na ~80 % tam, kde má význam reasoning.

allowed_tools — měňte dostupné nástroje bez rozbití cache

Nastavení nástrojů běžně patří do prefixu a změna nástrojů invaliduje cache. Parametr allowed_tools umožňuje dynamicky omezovat nebo rozšiřovat soubor nástrojů pro konkrétní request bez změny prefixu, takže keš zůstane zachována.

Batch API versus Flex processing

Pro dávkové zpracování existují dvě cesty:

• Batch API — klasický endpoint pro dávkové úlohy.
• Flex processing — parametr service_tier=flex na Responses API. Nabízí stejný diskont jako batch, ale můžete ho použít per-request s možností přidat prompt_cache_key a extended prompt caching. Flex je vhodný pro asynchronní workflow, které potřebují flexibilitu a nižší latenci.

Extended prompt caching — udržujte keš až 24 hodin

Implicitní in-memory cache je krátkodobá. Pokud potřebujete, aby se keš udržela mezi relacemi nebo dlouhodobě, aktivujte prompts_cache_retention (24h). Server přesune KV cache z paměti na lokální GPU úložiště a výrazně zvýší pravděpodobnost, že první dotaz po delším čase bude také hit.

Poznámka ohledně ochrany dat: in-memory cache je kompatibilní s politikou Zero Data Retention. Extended cache ukládá KV tensory na disk GPU a není ZDR-eligible, protože se jedná o perzistentní uložení mezivýsledků.

Context engineering: kdy ořezat a kdy sumarizovat (compaction)

Kešování a context engineering jsou částečně v rozporu: keš funguje, když je prefix stejný; dobrá správa kontextu často znamená měnit kontext. Zvolte, kde je přínos inteligence větší než náklady na invalidaci cache.

Dvě zásadní strategie:

• Truncation (ořezávání) — jednoduše odstraníte starší části konverzace. Časté ořezávání může ale dělat cache neefektivní, pokud se provádí při každém requestu.
• Summarization / Compaction — místo odstraňování shrnete starší část konverzace do kompaktního záznamu, který si model ponechá. OpenAI nabízí server-side compaction a samostatný endpoint responses/compact pro zašifrované compact výsledky.

Pro real-time audio modely se osvědčil parametr retention_ratio. Např. nastavením 0.7 říkáte: pokud se blížíme limitu kontextu, udělej větší jednorázové zkrácení a zachovej 70 % informace. Tím se vyhnete častému invalidování cache při menších průchodech do limitu.

Měřítka a thunb-of-rules

• Nastavujte compaction většinou kolem ~80 % kapacity kontextu, pokud používáte dlouhé kontexty.
• Otestujte frekvenci kompakce vůči ztrátě inteligence na konkrétních evalech — někdy je lepší jednou rozbít cache a zbavit kontext ruchu, než trvale hrát méně přesný model s velkou kontextovou hmotou.
• Pro dávkové zpracování zvažte flex processing s extended caching — v testech to zvýšilo cache hit rate o ~8.5 % a snížilo input token cost o ~23 %.

📊 Příklady a metriky z praxe

Výrazně jasnější obraz dává porovnání v konkrétních usecasech. Uvedu dvě praktické situace, na kterých jsem pracoval nebo které byly demonstrovány v analogických testech.

Batch image processing — AI styling assistant

Scénář: mám 2 000 tokenů dlouhý standardní prompt pro zpracování obrázku a do něj posílám jen měnící se obrázky.

• Varianty testu: cache broken (úmyslně vložen timestamp), cache implicitní bez prompt_cache_key, cache s prompt_cache_key.
• Výsledky: cache broken → 0% hit; implicit cache → ~75% hit; cache s key → ~83% hit.
• Cena na proccessing dávky: bez cache ~35 centů, s implicit cache ~22.7 centů, s cache key ~21 centů.
• Latence u krátkého prefixu (2 000 tokenů) nebyla výrazně ovlivněna — hlavní win je v nákladech.

Branching chat — podpora a styling flow

Scénář: live chat, uživatelé směřují buď do supportu, nebo do stylingu. Prefix obsahuje velkou část společného statického kontextu a pak větvení s odlišnými 5 000 tokeny pro každý flow.

• Simulace: 30 uživatelů, 15 do supportu, 15 do stylingu, 5 kol konverzace.
• Varianty: cache broken, cached bez key, cached s prompt_cache_key (dva klíče: support a styling).
• Výsledky: cache broken → 0% hit, cached bez key → nižší míra, cached s key → zlepšení až o ~7 % cache hits, což vedlo k ~7 % nákladové úspory v testu.
• Praktické doporučení: v aplikacích s větvením použijte prompt_cache_key podle větví, abyste nasměrovali příslušné větve na stejné engine a maximalizovali reuse.

🚀 Případová studie: Warp — jak to dělají agenti

Warp používá agentickou platformu pro vývojáře, kde agenti provádějí cykly čtení souborů, spouštění příkazů, generování patchů a podobně. To přirozeně generuje dlouhé, přírůstkové trace, které jsou ideální pro prompt caching.

Klíčové praktiky Warp:

• Scopes — cache dělí do tří vrstev: global, user a task. Global pro systémové instrukce, user pro uživatelskou konfiguraci a task pro samotnou interakci, kde je největší re-use.
• Konistence prefixů — systémové instrukce jsou co nejvíce statické, dynamické konfigurace se vkládají až po nich jako samostatné zprávy, aby nezničily globální cache.
• Prompt cache key — nasadili task-scoped klíče; výsledkem bylo zdvojnásobení cache hit rate v určitém období (testy ukázaly velmi výrazné zlepšení).
• Příklad číslem: bez kešování by požadavek s 10 000 tokeny systémového promptu a 5 000 tokenech toolů stál ~2,5 centu; s kešováním klesl výpočetní náklad na ~0,2 centu.

Warp také upozorňuje na situace, kdy je rozumné keš rozbít — například když načtený soubor do kontextu obsahuje rušivá data a je lepší ho z kontextu odstranit, i když to krátkodobě zvýší náklady.

✅ Kontrolní seznam pro případ, že cache "nefunguje"

Když se setkám s nízkým cache hit rate, projdu systematicky tento seznam:

1. Přesvědčte se, že prefix má alespoň 1 024 tokenů. Pod tímto prahem není implicitní caching aktivní.
2. Zkontrolujte změny v prefixu. Nepřidáváte time-stamp, náhodné mezery, dynamické ID nebo jiný proměnný obsah na začátek promptu?
3. Nepřepisujete nebo neměníte systémové instrukce a nástroje. Tyto změny invalidují cache.
4. Too many requests? Příliš mnoho identických requests bez prompt_cache_key způsobí rozložení na více enginech a první request na novém enginu bude miss.
5. Batch API a modely před GPT-5: některé starší kombinace batch endpointů nejsou eligible pro implicitní caching — zvažte flex processing.
6. Časový faktor: implicitní cache vyprší (5–10 minut), bez extended prompt caching po delší neaktivitě keš zmizí.
7. Chat completions vs Responses API: pokud používáte reasoning modely, chat completions mohou mít nižší keš kvůli chybějícím chain-of-thought tokenům.

📈 Jak měřit, sledovat a validovat dopad kešování

Měření je klíčové. Nabízí se dvě hlavní cesty:

• Dashboard — platforma ukazuje rozpis tokenů: input, cached input a uncached tokens.
• Response fields — každá odpověď obsahuje pole s počtem tokenů a rozlišením, kolik bylo z cache vs kolik bylo dopočítáno. Tyto metriky můžete ingestovat do vlastního monitoringu.

Doporučený měřící postup:

1. Sledujte cache hit rate, input token cost a time-to-first-token pro různé typy požadavků.
2. A/B testujte změny: přidejte prompt_cache_key, zapněte extended cache, použijte responses API a porovnejte metriky.
3. Sledujte náklady před a po úpravách při reálném provozu — malé procentuální změny v cache hit rate mohou znamenat velké úspory při stovkách tisíc requestů.

❓ Časté otázky a mýty

Změní kešování odpověď modelu?

Ne. Pokud je prefix identický a request dopadne na stejný engine, použití KV cache neovlivní vygenerovaný výstup. Jediný rozdíl je v tom, že se nepočítá část inference opakovaně.

Je kešování bezpečné z hlediska dat?

Implicitní in-memory cache je kompatibilní s politickými nastaveními jako Zero Data Retention. Extended prompt caching ukládá KV tensory na GPU lokální úložiště a proto je z hlediska ZDR jiná. Nicméně se neukládá surový text, images ani audio — ukládají se numerické mezivýsledky.

Mám krátké prompty — má smysl je prodlužovat přes 1 024 tokenů?

Ano, experimenty ukazují, že pokud můžete rozumně přidat nesměšný, ale relevantní statický kontext, překročení hranice 1 024 tokenů umožní kešování a často přinese významné úspory. Příklad: zvýší-li se cache hit rate i jen na 50 %, může to snížit tokenové náklady až o třetinu.

🔑 Závěr — co bych doporučil nasadit hned

Pokud chcete rychle a efektivně snížit náklady a zlepšit latenci, začněte tímto minimálním seznamem úkolů. Já bych to udělal v tomto pořadí:

1. Přidejte prompt_cache_key pro identifikaci tasků nebo větví, kde máte vysoký objem podobných požadavků.
2. Přepněte na Responses API, pokud používáte reasoning modely.
3. Odstraňte jakoukoli dynamiku z počátečních systémových instrukcí; místo toho vkládejte dynamická data do zpráv později v prefixu.
4. Zvažte extended prompt caching pro scénáře, kde je důležitá první latence a kde se často opakují podobné velké kontexty.
5. Nastavte kompakci/sumarizaci kontextu chytře — používejte retention_ratio pro real-time audio a testujte frekvenci compaction pro jiné usecase.
6. Sledujte metriky v dashboardu a response polích, proveďte A/B testy a iterujte na základě reálných čísel.

Kešování promptů je jeden z nejsilnějších nástrojů, které máte k dispozici pro optimalizaci AI aplikací. Správná architektura promptů, promyšlené použití prompt_cache_key a kontextová strategie (ořezávání versus sumarizace) dokážou snížit náklady, zlepšit latenci a zároveň zachovat nebo dokonce zvýšit kvalitu odpovědí.

Pokud chcete pomoct s návrhem konkrétní strategie na míru vaší aplikaci, rád vám pomohu navrhnout první kroky a testy, které rychle odhalí potenciál úspor.