Prompt cache může zlevnit agenta o 41

Prompt cache nastavte tak, aby požadavky agenta začínaly stejnými definicemi nástrojů a instrukcemi; uživatelský dotaz, aktuální údaje a nové výsledky nástrojů připojujte až za ně. V experimentu na DeepResearch Bench snížily testované strategie cache náklady na API o 41–80 % a dobu do prvního tokenu o 13–31 % proti provozu bez cache. Rozmezí popisuje dlouhé agentní úlohy napříč poskytovateli, nikoli zaručenou úsporu v každé aplikaci.

Začněte hranicí za poslední částí, kterou další požadavky skutečně sdílejí. Dokumentace OpenAI popisuje opětovné použití shodného prefixu, upozorňuje, že samotné zachování relace zásah cache nezaručuje, a u modelů GPT-5.6 a novějších stanoví minimum 1 024 viditelných vstupních tokenů pro uložitelný prefix. Změna před hranicí může zkrátit znovu použitelnou část, i když zbytek instrukcí zůstane významově stejný.

Sestavte požadavek od stálého obsahu k proměnlivému

V agentním požadavku může poskytovatel zpracovat definice nástrojů ještě před textem instrukcí. Stabilní prefix proto začíná už jejich seznamem: stejnými názvy, popisy, schématy a pořadím. Za nimi mají následovat pravidla agenta, požadovaný formát odpovědi a referenční obsah, který se opakuje mezi úlohami. Identifikátor relace nebo čas vložený doprostřed této části by společný začátek přerušil.

Udržujte shodný model a nastavení, která ovlivňují podobu zpracovaného vstupu.
Posílejte stálou sadu definic nástrojů ve stejném pořadí.
Navazujte verzovanou šablonou instrukcí a společnými příklady, pokud je agent potřebuje.
Hranici cache položte za poslední stabilní blok.
Za hranici připojte dotaz, aktuální kontext a nové výsledky nástrojů.

Verzovaná šablona usnadní rozlišit úmyslnou změnu pravidel od náhodného rozdílu při sestavování požadavku. Shoda se týká skutečně zpracovaného začátku, takže nestačí, aby dva texty říkaly totéž jinými slovy. Stejně může zasáhnout změna výstupního schématu nebo parametrů uvažování: model pak dostane odlišný kontext ještě před vlastním dotazem. Proměnlivé hodnoty proto vkládejte do pozdější zprávy, nikoli do společné šablony.

Vyberte hranici podle možností API

Na podporovaných novějších modelech lze použít automaticky umístěnou hranici nebo výslovně označit konec stabilního obsahového bloku a zvolit režim používající jen výslovné hranice. Automatický režim se hodí, když pokračující konverzace opakovaně přidává zprávy ke stejnému začátku. Výslovná hranice dává větší kontrolu tam, kde se za společnými instrukcemi rychle střídají data různých úloh a zápisy proměnlivého obsahu by se nevyužily.

V Responses API se výslovná značka připojuje k podporovanému obsahovému bloku; samostatné horní pole instructions ji nepřijímá. Starší modely výslovné hranice nepodporují, ale stejné pořadí vstupu jim stále pomáhá zachovat opakovatelný prefix. Krátké instrukce uměle neprodlužujte jen kvůli minimální délce pro cache. Přidané tokeny se musí zpracovat a jejich cena může převýšit přínos budoucího opakovaného použití.

Výsledky nástrojů ponechte za stabilní hranicí

Výsledek vyhledávání nebo databázového dotazu obvykle patří konkrétní úloze. Uložit jej jako součást společného prefixu znamená vytvořit zápis pro obsah, který další nezávislá úloha pravděpodobně nepoužije. U agenta s mnoha různými dotazy je proto rozumným výchozím nastavením cachovat společné instrukce a nové výstupy nástrojů ponechat za zvolenou hranicí. Právě zbytečné zápisy proměnlivého kontextu mohou zhoršit dobu do prvního tokenu, přestože cena vstupu klesá.

Pokračující konverzace má jinou vlastnost: starší zprávy včetně dřívějších výsledků nástrojů mohou zůstat beze změny a při dalším kroku tvořit delší společný prefix. Nemažte tedy potřebnou historii jen proto, že obsahuje výstup nástroje. Rozhodující je, zda se tentýž úsek skutečně znovu objeví před novým vstupem. Pokud aplikace předchozí zprávy shrne nebo přepíše, shoda od prvního změněného místa skončí; agent pak může ztratit část očekávané úspory.

Cache miss hledejte od začátku požadavku

Nejdřív porovnejte model a nastavení obou volání, potom definice nástrojů a nakonec posloupnost zpráv. Častým zdrojem rozdílu je změněné schéma funkce, jiné pořadí nástrojů nebo časová značka přidaná do instrukcí. V diagnostice prompt cache OpenAI lze porovnat aktuální odpověď s dřívější pomocí comparison_response_id a zjistit například změnu nástrojů či vstupu. Srovnání vyžaduje vhodnou dokončenou odpověď jako základ.

Diagnostické označení zásahu samo neříká, kolik tokenů se opravdu přečetlo z cache. Po opravě rozdílu zopakujte reprezentativní požadavek a sledujte také usage.input_tokens_details.cached_tokens v nové odpovědi. Nízká hodnota může znamenat, že se shodoval jen krátký začátek, že opakovaný obsah nedosáhl potřebné délky nebo že záznam už nebyl dostupný. U náhodných rozdílů v sestavování požadavků opravujte první změněné místo; úpravy až za ním zásah neobnoví.

Vyhodnoťte cenu a čas do prvního tokenu společně

Pro každé volání ukládejte celkový počet vstupních tokenů, počet tokenů přečtených z cache, případné zápisy do cache, cenu vstupu a čas od odeslání požadavku do prvního tokenu odpovědi. Tokenovou míru opakovaného použití počítejte jako součet tokenů přečtených z cache dělený součtem vstupních tokenů ve sledované skupině. Podíl požadavků označených jako zásah nestačí: jedno volání může využít dlouhý společný začátek a současně zpracovat rozsáhlý nový konec.

Porovnávejte běžné relace při stejném modelu a podobné zátěži, včetně zápisů do cache a správnosti odpovědí na stejných úlohách. Strategie s nejnižší cenou nemusí mít nejkratší odezvu, zvlášť když zapisuje obsah, který se později nečte. Pokud přibývají zápisy a čas do prvního tokenu se prodlužuje, posuňte hranici zpět ke skutečně sdílenému bloku. Smyslem nastavení je opakovaně využít drahý stabilní začátek, zatímco agent bez omezení zpracuje aktuální data své úlohy.

Přečtěte si také: