Kostnadsoptimering: Snabbcachning

Vinster:

• Förklara prefixmatchningslogiken för promptcache
• Ökar cacheminnet genom att sätta fast kontext först och variabel kontext efter
• Kan beräkna cache skriv/läs ekonomi och brytpunkt

En LLM-produkt ser billig ut i prototyp; När du kliver upp på vågen överraskar notan. I de flesta arbetsbelastningar kommer det mesta av räkningen från samma fasta sammanhang som skickas om och om igen med varje begäran: en lång systemprompt, en regelbok, referensdokumentation. Snabb cachning eliminerar exakt detta avfall. I den här enheten kommer du att lära dig hur cachen fungerar, hur man ordnar prompten för att slå och hur man beräknar nollpunkten för cacheekonomin. När den är korrekt installerad kan den bara halvera din räkning eller ännu lägre.

Hur fungerar cache? Den enda oföränderliga regeln

Snabbcachelagring är en prefixmatchning. Leverantören lagrar tillfälligt de tokens som den har bearbetat sedan början av din prompt. Om prompten börjar med samma prefix vid nästa begäran, räknas inte denna gemensamma del om; Det är mycket billigare att läsa än cache.

En oföränderlig regel följer av detta: Om en enda byte ändras någonstans i prefixet, blir hela cachen ogiltigt från den punkten och framåt. Det vill säga, fast innehåll ska vara i början och variabelt innehåll ska vara i slutet. Om du sätter en rad i början av systemprompten som ändras med varje förfrågan, till exempel "Dagens datum: 18.07.2026", kommer allt bakom den inte att kunna komma in i cachen.

Bearbetningsordningen är vanligtvis: verktyg → systemuppmaning → meddelanden. Du lägger cachepunkten (brytpunkten) i slutet av den fasta sektionen.

Cacheekonomi

Cache har tre prisnivåer:

• Cache-skriv: Lagrar för första gången. ~1,25x normalt ingångspris (för 5 minuters lagring).
• Läs cache: Läser på efterföljande förfrågningar. ~0,1 gånger det normala insatspriset - det vill säga en tiondel.
• Normal input: Den del som inte kommer in i cachen och bearbetas till full kostnad varje gång.

Break-even punkt: Första begäran betalar skrivpremie (1,25×). Från den andra begäran kommer läsningen (0,1×) in i bilden. Ungefär, du kommer att vara nack och hals på två förfrågningar; Därefter är det nettobesparingar. Ju större det fasta sammanhanget är och ju fler förfrågningar det återanvänds, desto större blir vinsten.

Scenario

Fungerar cachen?

Stor fast systemprompt, tusentals förfrågningar

Ja – högsta inkomster

Många frågor om samma referensdokument

Ja

Helt olika kort text för varje förfrågan

Nej – skrivbonus är bortkastad

Engångsförfrågan

Nej – ingen läsning alls

Datum/ID ändras med varje begäran vid systemprompten

Nej – prefixet är brutet, träffen är noll

Steg för steg: Hur ställer jag in en träffprompt?

1. Separera konstant och variabel. Vilket innehåll ändras aldrig (systemuppmaning, regelbok, dokumentation)? Vilka ändras med varje begäran (användarfråga, datum, ID)?
2. Sätt konstanten i början. Under bearbetningen måste den del som kommer först (verktyg, system) vara stabil.
3. Sätt variabeln i slutet. Användarens aktuella fråga, sist.
4. Placera skylten i slutet av gränsen. Placera cachepunkten i det sista blocket av den fasta delen.
5. Verifiera träffen. Kontrollera om cache_read_input_tokens är större än noll i användningsfältet i svaret. Om noll finns det en dold störare i prefixet.

{ "system": [ { "type": "text", "text": "{{large_constant_system_promptu_and_rules}}", "cache_control": { "type": "ephemeral" } } ], "meddelanden": [ { "role": "user", "content": "{{question]}}current

Tips: Gissa inte cacheträffar, mät dem. Om usage.cache_read_input_tokens fortfarande är noll vid på varandra följande förfrågningar, körs en tyst brytare (datetime.now() vid systemprompten, oordnad JSON, lista över verktyg som ändras med varje begäran. Jämför den råa prompten för de två begäranden byte för byte och hitta skillnaden.

Tysta störare

Typiska mönster som omedvetet korrumperar cachen:

# BREAKER: bädda in information i systemprompten som ändras med varje förfrågan "Dagens datum: {{nu}}. Du är en assistent..." ← prefixet ändras med varje förfrågan, träffen är noll# TRUE: flytta variabeln till meddelandesystemet: "Du är en assistent..." ← konstant skriver in cachemessages: {{RolenTo:day user, content:rownTo:} ..."}] ← variabel i slutet

Andra brytare: JSON sorteras olika på varje begäran (behåll nycklar i fast ordning), lista över verktyg som varierar beroende på användare (verktygen bearbetas först; ingenting går in i cachen om de ändras), ändrar modellen mitt i konversationen (cacher är modellspecifika).

Svag prompt / Stark prompt (cachevänlig struktur)

# WEAK (cache-busting build)-system: "Datum: 18.07.2026 14:32. Användare: Ahmet (id 8842). Du är en supportbot. Regler: ...(2000 tokens)..."

# STARKT (cachevänlig struktur)system: "Du är en supportbot. Regler: ...(2000 tokens, ändras aldrig)..." [cache-tecken]meddelanden: [ { roll: användare, innehåll: "Datum: 18.07.2026 14:32. Användar-id: 8842. Fråga: hur initierar jag min återbetalning?" }]

I den svaga versionen behandlas regelblocket med 2000 tokens till full kostnad på varje begäran. I den starka versionen skrivs samma block en gång och läses på alla efterföljande förfrågningar för en tiondel av priset.

Tre minifodral

Fall 1 — Cacha regelboken. En redovisningsautomatisering lade till regelboken med 12 000 token till varje faktura; 5 000 förfrågningar per dag. Cachelös inmatning kostar ~$180 per dag. De höll regelboken konstant och cachade den: första förfrågningar betalade en skrivpremie, efterföljande läsningar 0,1×. Inmatningskostnaden sjönk ~90 % till ~$18 per dag.

Fall 2 — Kostnad för dold datumrad. Ett lag skapade en cache men fick inga träffar; cache_read_input_tokens var alltid noll. Orsak: Det fanns datetime.now() i den första raden i systemprompten, prefixet ändrades med varje begäran. När vi flyttade datumet till användarmeddelandet ökade plötsligt träfffrekvensen från 0 % till 94 %.

Fall 3 — Felplacerad cache. En sökapplikation skickade helt olika korta frågor med varje begäran; De lade ivrigt till en cache-skylt. Utan något gemensamt prefix betalade varje förfrågan endast en skrivpremie, inga läsningar – vilket ökar kostnaderna. De tog bort skylten. Lärdom: cache betalar bara om det finns ett stort och konstant prefix som återanvänds.

Vanliga misstag

• Blandar konstant och variabel: När variabelinnehållet finns i prefixet återställs träffen.
• Inbädda datum/ID i systemprompt: Den vanligaste tysta störaren.
• Mäter inte träffen: Om cache_read_input_tokens inte är markerad kommer slöseri inte att märkas.
• Lägger till cache när det inte finns något publikt prefix: Du betalar bara skrivpremien, kostnaden ökar.
• Ändra fordonslistan eller modell: Prefixet är brutet från början; allt skrivs om.
• Att glömma den minsta cachestorleken: Mycket korta cacher (under ~1–4k tokens beroende på modell) kommer inte in i cachen tyst.

Deeper: Designa cache efter arbetsbelastningstyp

Den faktiska utdelningen av cachelagring varierar beroende på typen av din arbetsbelastning; så lär känna din trafik först. Tre typiska mönster och korrekt installation:

Gemensam systemprompt, olika frågor. Vanligaste företagsmönstret: en stor systemprompt (roll, regler, kanske referensdokument) med hundratals olika användarfrågor. Här cachelagras den fasta delen (systemet) initialt; varje ny fråga betalar endast fullt pris för sin egen lilla del. Vinsten är mycket hög eftersom den stora delen reciteras upprepade gånger till en tiondel av priset.

Flerrunda monolog. Allt eftersom en konversation drar ut på tiden bygger varje ny omgång på all tidigare historia. Om du sätter cacheflaggan i slutet av den sista omgången, återanvänder varje begäran det föregående konversationsprefixet; träffar ackumuleras när konversationen växer. Detta drar dramatiskt tillbaka kostnaderna för långa assistentsessioner.

Det delade prefixet är den sista biten att ändra. Flera förfrågningar delar en stor uppsättning fasta prioriteringar (provuppsättning, instruktioner) men är åtskilda av en enda fråga i slutet. Du sätter cachepekaren i slutet av den delade delen; Annars skulle varje begäran skriva sin egen separata cache och inget av det skulle läsas.

En varning: cachen beror på modellen och en viss minimistorlek. Mycket små prefix (under några tusen tokens, beroende på modell) kommer inte tyst in i cachen även om du flaggar dem - cache_creation_input_tokens förblir noll. Genom att ändra modellen mitt i konversationen ogiltigförklaras också hela cachen; Om en annan uppgift kräver en billig modell, håll huvudflödet i en modell och lägg sidojobbet i ett separat samtal.

Sammanfattningsvis

Cachning av prompt är en prefixmatchning: fast innehåll ska vara i början, variabelt innehåll ska vara i slutet. För en stor återanvänd kontext är läskostnaden en tiondel av det fulla priset, ungefär jämnt i två förfrågningar. Det vanligaste misstaget är att korrumpera prefixet genom att bädda in variabel data i systemprompten; Du verifierar träffen genom att mäta den i användningsfältet.

Applikationsuppgift

Välj en arbetsbelastning. (1) Dela upp innehållet i två kolumner: "ändras aldrig" och "ändras vid varje begäran". (2) Rita om promptstrukturen, sätta den konstanta delen i början och den variabla delen i slutet. (3) Uppskatta tokenstorleken för den fasta delen och jämför månadskostnaden med/utan cache. (4) Notera vilket fält (cache_read_input_tokens) du kommer att verifiera träffen från.

checklista

• [ ] Jag kan förklara att cache är prefixmatchning och den enda oföränderliga regeln.
• [ ] Jag kan öka noggrannheten genom att sätta det fasta innehållet i början och variabeln i slutet.
• [ ] Jag kan skriva/läsa ekonomi och brytpunkten för två begäranden.
• [ ] Jag kan känna igen tysta störare (datum, oordnad JSON, ändrad fordonslista).
• [ ] Jag kan verifiera träffen med usage.cache_read_input_tokens.