zisky:
- Vysvětlete logiku porovnávání předpon při ukládání do mezipaměti výzvy
- Zvyšuje přístup do mezipaměti tím, že na první místo umístí pevný kontext a poté proměnný kontext
- Dokáže vypočítat ekonomiku zápisu/čtení mezipaměti a bod zvratu
Produkt LLM vypadá v prototypu levně; Když stoupnete na váhu, účet překvapí. Ve většině pracovních zátěží pochází většina faktury ze stejného pevného kontextu, který je zasílán znovu a znovu s každým požadavkem: dlouhá systémová výzva, kniha pravidel, referenční dokumentace. Rychlé ukládání do mezipaměti eliminuje přesně toto plýtvání. V této lekci se naučíte, jak cache funguje, jak uspořádat výzvu k zásahu a jak vypočítat bod zvratu ekonomiky cache. Při správné instalaci může sám o sobě snížit váš účet na polovinu nebo ještě nižší.
Jak Cache funguje? Jediné neměnné pravidlo
Ukládání výzvy do mezipaměti je shoda předpony. Poskytovatel dočasně ukládá tokeny, které zpracoval od začátku vaší výzvy. Pokud výzva při příštím požadavku začíná stejnou předvolbou, tato společná část se nepřepočítává; Čtení je mnohem levnější než cache.
Z toho plyne jedno neměnné pravidlo: Pokud se kdekoli v prefixu změní jediný bajt, od tohoto okamžiku se celá mezipaměť stává neplatnou. To znamená, že pevný obsah by měl být na začátku a proměnný obsah by měl být na konci. Pokud na začátek systémové výzvy vložíte řádek, který se mění s každým požadavkem, například „Dnešní datum: 18.07.2026“, vše za ním nebude moci vstoupit do mezipaměti.
Pořadí zpracování je obvykle: nástroje → systémová výzva → zprávy. Bod mezipaměti (bod přerušení) umístíte na konec pevné sekce.
Ekonomika mezipaměti
Cache má tři cenové úrovně:
- Zápis do mezipaměti: Ukládání poprvé. ~1,25x normální vstupní cena (za 5 minut úložiště).
- Čtení z mezipaměti: Čtení při následných požadavcích. ~0,1násobek běžné vstupní ceny — tedy desetina.
- Normální vstup: Část, která nevstupuje do mezipaměti a je pokaždé zpracována za plnou cenu.
Bod zvratu: První žádost zaplatí ážio (1,25×). Od druhého požadavku přichází na řadu čtení (0,1×). Zhruba na dvě žádosti budete hrdí; Poté jsou to čisté úspory. Čím větší je pevný kontext a čím více požadavků je znovu použito, tím větší je zisk.
Scénář
Funguje cache?
Velký pevný systém prompt, tisíce požadavků
Ano – nejvyšší výdělky
Mnoho otázek na stejné referenční dokumenty
Ano
Pro každý požadavek úplně jiný krátký text
Ne – bonus za zápis je promarněný
Jednorázová žádost
Ne – vůbec žádné čtení
Datum/ID se mění s každým požadavkem na výzvu systému
Ne – prefix je nefunkční, zásah je nulový
Krok za krokem: Jak nastavit výzvu k přístupu?
- Samostatná konstantní a proměnná. Jaký obsah se nikdy nemění (systémová výzva, kniha pravidel, dokumentace)? Co se mění s každým požadavkem (dotaz uživatele, datum, ID)?
- Dejte konstantu na začátek. Při zpracování musí být díl, který je na prvním místě (nástroje, systém), stabilní.
- Dejte proměnnou na konec. Aktuální otázka uživatele, poslední.
- Umístěte značku na konec hranice. Umístěte vyrovnávací bod do posledního bloku pevné části.
- Ověřte zásah. Zkontrolujte, zda je cache_read_input_tokens v poli použití v odpovědi větší než nula. Pokud je nula, je v prefixu skrytý disruptor.
{ "system": [ { "type": "text", "text": "{{large_constant_system_promptu_and_rules}}", "cache_control": { "type": "efemérní" } } ], "messages": [ { "role": "user", "content": "{{user_current_question"
Tip: Nehádejte zásahy do mezipaměti, měřte je. Pokud je use.cache_read_input_tokens stále nula na po sobě jdoucích požadavcích, běží tichý jistič (datetime.now() na systémovém řádku, neuspořádaný JSON, seznam nástrojů se mění s každým požadavkem). Porovnejte základní výzvu dvou požadavků bajt po bajtu a najděte rozdíl.
Tiché disruptory
Typické vzory, které nevědomky poškozují mezipaměť:
# BREAKER: vkládání informací do systémové výzvy, které se mění s každým požadavkem "Dnešní datum: {{nyní}}. Jste asistent..." ← předpona se mění s každým požadavkem, zásah je nula# TRUE: přesuňte proměnnou do systému zpráv: "Jste asistent..." ← konstanta vstupuje do mezipaměti zpráv: [{role: user, content: "Dnes na konci je proměnná: {{}} ←
Další breakery: JSON seřazený odlišně na každý požadavek (uchovávejte klíče v pevném pořadí), seznam nástrojů se liší podle uživatele (nástroje jsou zpracovány jako první; do mezipaměti nic nevstoupí, pokud se změní), změna modelu uprostřed konverzace (mezipaměti jsou specifické pro model).
Slabá výzva / silná výzva (struktura přátelská mezipaměti)
# SLABÝ (sestavení vynechání mezipaměti) systém: "Datum: 18.07.2026 14:32. Uživatel: Ahmet (id 8842). Jste bot podpory. Pravidla: ...(2000 tokenů)..."
# SILNÝ (struktura vhodná pro mezipaměť) systém: "Jste robot podpory. Pravidla: ...(2000 tokenů, nikdy se nemění)..." [znak mezipaměti]zprávy: [ { role: uživatel, obsah: "Datum: 18.07.2026 14:32. ID uživatele: 8842. Otázka: jak zahájím vrácení peněz?" }]
Ve slabé verzi je blok pravidel 2000 tokenů zpracován za plnou cenu na každý požadavek. V silné verzi je stejný blok zapsán jednou a přečten při všech následujících požadavcích na desetinu ceny.
Tři mini pouzdra
Případ 1 – Ukládání do mezipaměti knihy pravidel. Účetní automatizace přidávala 12 000 tokenových pravidel ke každé faktuře; 5 000 požadavků za den. Vstup bez mezipaměti stojí ~ 180 $ za den. Udrželi knihu pravidel konstantní a uložili ji do mezipaměti: první požadavky zaplatily prémii za zápis, další čtení 0,1×. Vstupní náklady klesly o ~90 % na ~18 $ za den.
Případ 2 — Náklady na skrytou datovou linii. Jeden tým vytvořil mezipaměť, ale nezískal žádné zásahy; cache_read_input_tokens byla vždy nula. Důvod: V prvním řádku systémového řádku byl datetime.now(), předpona se měnila s každým požadavkem. Když jsme datum přesunuli do uživatelské zprávy, návštěvnost se náhle zvýšila z 0 % na 94 %.
Případ 3 – Chybně umístěná vyrovnávací paměť. Vyhledávací aplikace odesílala s každým požadavkem úplně jiné krátké dotazy; Dychtivě přidali znak keše. Bez společné předpony každý požadavek zaplatil pouze prémii za zápis, žádné čtení – což zvyšuje náklady. Odstranili ceduli. Lekce: Mezipaměť se vyplatí pouze v případě, že existuje velká a konstantní předpona, která je znovu použita.
Časté chyby
- Směšovací konstanta a proměnná: Když je obsah proměnné v prefixu, zásah se resetuje.
- Datum/ID vložení do systémové výzvy: Nejběžnější tichý disruptor.
- Neměření zásahu: Pokud není zaškrtnuto políčko cache_read_input_tokens, plýtvání nebude zaznamenáno.
- Přidání mezipaměti, když neexistuje žádný veřejný prefix: Platíte pouze prémii za zápis, náklady se zvyšují.
- Změna seznamu vozidel nebo modelu: Předpona je přerušena od začátku; vše je přepsáno.
- Zapomenutí minimální velikosti mezipaměti: Velmi krátké mezipaměti (pod ~1–4k tokenů v závislosti na modelu) nevstoupí do mezipaměti tiše.
Deeper: Návrh mezipaměti podle typu zátěže
Skutečný přínos ukládání do mezipaměti se liší v závislosti na povaze vaší pracovní zátěže; tak nejprve zjistěte svůj provoz. Tři typické vzory a správná instalace:
Běžná systémová výzva, různé otázky. Nejběžnější podnikový vzor: velká systémová výzva (role, pravidla, možná referenční dokument) se stovkami různých uživatelských otázek. Zde je pevná část (systém) zpočátku ukládána do mezipaměti; každá nová otázka platí plnou cenu pouze za svou malou část. Zisk je velmi vysoký, protože velká část je opakovaně recitována za desetinu ceny.
Vícekolový monolog. Jak se konverzace vleče, každé nové kolo navazuje na předchozí historii. Pokud vložíte příznak mezipaměti na konec posledního kola, každý požadavek znovu použije předponu předchozí konverzace; hity se hromadí, jak konverzace roste. To dramaticky snižuje náklady na dlouhé sezení asistenta.
Sdílená předpona je poslední bit, který se má změnit. Více požadavků sdílí velkou sadu pevných priorit (vzorová sada, instrukce), ale jsou odděleny jedinou otázkou na konci. Ukazatel mezipaměti umístíte na konec sdílené části; V opačném případě by si každý požadavek zapsal vlastní samostatnou mezipaměť a nic z toho by nebylo načteno.
Jedno upozornění: cache závisí na modelu a určité minimální velikosti. Velmi malé předpony (pod několik tisíc tokenů, v závislosti na modelu) nevstoupí tiše do mezipaměti, i když je označíte — cache_creation_input_tokens zůstává nula. Změna modelu uprostřed konverzace také zneplatní celou mezipaměť; Pokud jiný úkol vyžaduje levný model, ponechte hlavní tok v jednom modelu a vedlejší úkol vložte do samostatného hovoru.
V souhrnu
Ukládání výzvy do mezipaměti je shoda prefixu: pevný obsah by měl být na začátku, proměnný obsah by měl být na konci. U velkého, znovu použitého kontextu jsou náklady na čtení desetina plné ceny, což je zhruba ve dvou požadavcích. Nejčastější chybou je poškození prefixu vložením proměnných dat do systémového řádku; Zásah ověříte měřením v poli použití.
Aplikační úkol
Vyberte si pracovní náplň. (1) Rozdělte obsah do dvou sloupců: „nikdy se nemění“ a „mění se s každým požadavkem“. (2) Překreslete strukturu výzvy, dejte konstantní část na začátek a proměnnou část na konec. (3) Odhadněte velikost tokenu pevné části a porovnejte měsíční náklady s/bez mezipaměti. (4) Všimněte si, ze kterého pole (cache_read_input_tokens) ověříte zásah.
kontrolní seznam
- [ ] Mohu vysvětlit, že mezipaměť je shoda prefixů a jediné neměnné pravidlo.
- [ ] Mohu zvýšit přesnost tím, že pevný obsah umístím na začátek a proměnnou na konec.
- [ ] Umím psát/číst ekonomii a bod zlomu dvou požadavků.
- [ ] Dokážu rozpoznat tiché disruptory (datum, neuspořádaný JSON, měnící se seznam vozidel).
- [ ] Mohu ověřit přístup pomocí use.cache_read_input_tokens.