Gevinster:
- Forklar præfiks-matching-logikken for prompt-caching
- Øger cache-hit ved at sætte fast kontekst først og variabel kontekst efter
- Kan beregne cache skrive/læse økonomi og break-even point
Et LLM-produkt ser billigt ud i prototype; Når du træder op på skalaen, overrasker regningen. I de fleste arbejdsbelastninger kommer det meste af regningen fra den samme faste kontekst, der sendes igen og igen med hver anmodning: en lang systemprompt, en regelbog, referencedokumentation. Hurtig caching eliminerer netop dette spild. I denne enhed lærer du, hvordan cachen fungerer, hvordan man arrangerer prompten til at ramme, og hvordan man beregner break-even-punktet for cache-økonomien. Når den er installeret korrekt, kan den alene halvere din regning eller endda lavere.
Hvordan fungerer cachen? Den ene uforanderlige regel
Prompt caching er et præfiksmatch. Udbyderen gemmer midlertidigt de tokens, den har behandlet siden begyndelsen af din prompt. Hvis prompten starter med det samme præfiks ved næste anmodning, genberegnes denne fælles del ikke; Det er meget billigere at læse end cache.
En uforanderlig regel følger heraf: Hvis en enkelt byte ændres hvor som helst i præfikset, bliver hele cachen ugyldig fra det tidspunkt og fremefter. Det vil sige, at fast indhold skal være i begyndelsen, og variabelt indhold skal være i slutningen. Hvis du sætter en linje i begyndelsen af systemprompten, der ændres med hver anmodning, såsom "Datoens dato: 18.07.2026", vil alt bagved ikke kunne komme ind i cachen.
Behandlingsrækkefølgen er normalt: værktøjer → systemprompt → meddelelser. Du sætter cachepunktet (breakpoint) i slutningen af den faste sektion.
Cache økonomi
Cache har tre prisniveauer:
- Cache-skriv: Lagrer for første gang. ~1,25x normal inputpris (for 5 minutters opbevaring).
- Cache læst: Læsning på efterfølgende anmodninger. ~0,1 gange den normale inputpris - det vil sige en tiendedel.
- Normal input: Den del, der ikke kommer ind i cachen og behandles til fuld pris hver gang.
Break-even punkt: Første anmodning betaler skrivepræmie (1,25×). Fra den anden anmodning kommer aflæsningen (0,1×) i spil. Omtrent, vil du være hals og hals på to anmodninger; Herefter er det nettobesparelse. Jo større den faste kontekst og jo flere anmodninger den genbruges, jo større bliver gevinsten.
Scenarie
Virker cachen?
Stor fast systemprompt, tusindvis af anmodninger
Ja - højeste indtjening
Mange spørgsmål om de samme referencedokumenter
Ja
Helt forskellig kort tekst for hver anmodning
Nej - skrivebonus er spildt
Engangsanmodning
Nej - slet ingen læsning
Dato/id ændres med hver anmodning ved systemprompten
Nej - præfikset er brudt, hit er nul
Trin for trin: Hvordan konfigurerer man en hit-prompt?
- Adskil konstant og variabel. Hvilket indhold ændres aldrig (systemprompt, regelbog, dokumentation)? Hvilke ændringer med hver anmodning (brugerspørgsmål, dato, ID)?
- Sæt konstanten i begyndelsen. Under behandlingen skal den del, der kommer først (værktøjer, system) være stabil.
- Sæt variablen til sidst. Brugerens aktuelle spørgsmål, sidst.
- Placer skiltet for enden af grænsen. Sæt cachepunktet i den sidste blok af den faste del.
- Bekræft hit. Tjek om cache_read_input_tokens er større end nul i brugsfeltet i svaret. Hvis nul, er der en skjult disruptor i præfikset.
{ "system": [ { "type": "text", "text": "{{large_constant_system_promptu_and_rules}}", "cache_control": { "type": "ephemeral" } } ], "messages": [ { "role": "bruger", "content": "{{question]}}current
Tip: Gæt ikke cache-hits, mål dem. Hvis usage.cache_read_input_tokens stadig er nul ved på hinanden følgende anmodninger, kører en tavs breaker (datetime.now() ved systemprompt, uordnet JSON, liste over værktøjer, der ændres med hver anmodning). Sammenlign den rå prompt af de to anmodninger byte for byte og find forskellen.
Silent Disruptors
Typiske mønstre, der ubevidst ødelægger cachen:
# BREAKER: indlejring af information i systemprompten, der ændres med hver anmodning "Datoens dato: {{nu}}. Du er en assistent..." ← præfikset ændres med hver anmodning, hit er nul# TRUE: flyt variablen til meddelelsessystemet: "Du er en assistent..." ← konstant indtaster cachemessages: [{rolleto:day user: ..."}] ← variabel i slutningen
Andre afbrydere: JSON sorteret forskelligt på hver anmodning (hold nøgler i fast rækkefølge), liste over værktøjer varierer efter bruger (værktøjer behandles først; intet går ind i cachen, hvis de ændres), ændring af modellen midt i samtalen (caches er modelspecifikke).
Svag prompt / stærk prompt (cachevenlig struktur)
# SWAG (cache-busting build)-system: "Dato: 18.07.2026 14:32. Bruger: Ahmet (id 8842). Du er en support-bot. Regler: ...(2000 tokens)..."
# STÆRK (cache-venlig struktur)system: "Du er en support-bot. Regler: ...(2000 tokens, ændres aldrig)..." [cache-tegn]beskeder: [ { rolle: bruger, indhold: "Dato: 18.07.2026 14:32. Bruger-id: 8842. Spørgsmål: hvordan starter jeg min refusion?" }]
I den svage version behandles regelblokken på 2000 tokens til fuld pris på hver anmodning. I den stærke version skrives den samme blok én gang og læses på alle efterfølgende forespørgsler til en tiendedel af prisen.
Tre mini etuier
Case 1 — Caching af regelbogen. En regnskabsautomatisering føjede 12.000 tokens regelbog til hver faktura; 5.000 anmodninger om dagen. Cacheløst input koster ~$180 pr. dag. De holdt regelbogen konstant og cachelagrede den: første anmodninger betalte en skrivepræmie, efterfølgende læsninger 0,1×. Inputomkostninger faldt ~90 % til ~$18 pr. dag.
Tilfælde 2 — Omkostninger ved skjult datolinje. Et hold oprettede en cache, men fik ingen hits; cache_read_input_tokens var altid nul. Årsag: Der var datetime.now() i den første linje af systemprompten, præfikset ændrede sig med hver anmodning. Da vi flyttede datoen til brugerbeskeden, steg hitraten pludselig fra 0 % til 94 %.
Tilfælde 3 — Forlagt cache. En søgeapplikation sendte helt forskellige korte forespørgsler med hver anmodning; De tilføjede ivrigt et cache-tegn. Uden fælles præfiks betalte hver anmodning kun en skrivepræmie, ingen læsninger - hvilket øgede omkostningerne. De fjernede skiltet. Lektion: cache betaler kun, hvis der er et stort og konstant præfiks, der genbruges.
Almindelige fejl
- Blanding af konstant og variabel: Når variabelindholdet er i præfikset, nulstilles hittet.
- Indlejring af dato/ID i systemprompt: Den mest almindelige stille forstyrrer.
- Måler ikke hit: Hvis cache_read_input_tokens ikke er markeret, vil spild ikke blive bemærket.
- Tilføjelse af cache, når der ikke er noget offentligt præfiks: Du betaler kun skrivepræmien, omkostningerne stiger.
- Ændring af køretøjslisten eller model: Præfikset er brudt fra begyndelsen; alt er skrevet om.
- Glemmer den mindste cachestørrelse: Meget korte caches (under ~1-4k tokens afhængigt af modellen) kommer ikke stille ind i cachen.
Deeper: Design af cache efter arbejdsbelastningstype
Det faktiske udbytte af cachelagring varierer afhængigt af arten af din arbejdsbyrde; så lær din trafik at kende først. Tre typiske mønstre og korrekt installation:
Fælles systemprompt, forskellige spørgsmål. Mest almindelige virksomhedsmønster: en stor systemprompt (rolle, regler, måske referencedokument) med hundredvis af forskellige brugerspørgsmål. Her cachedes den faste del (systemet) initialt; hvert nyt spørgsmål betaler kun fuld pris for sin egen lille portion. Gevinsten er meget høj, fordi den store portion reciteres gentagne gange til en tiendedel af prisen.
Multi-rund monolog. Som en samtale trækker ud, bygger hver ny runde oven på al tidligere historie. Hvis du sætter cache-flaget i slutningen af sidste runde, genbruger hver anmodning det forrige samtalepræfiks; hits ophobes, efterhånden som samtalen vokser. Dette begrænser dramatisk omkostningerne ved lange assistentsessioner.
Det delte præfiks er den sidste bit, der skal ændres. Flere anmodninger deler et stort sæt faste forudsætninger (prøvesæt, instruktioner), men er adskilt af et enkelt spørgsmål til sidst. Du sætter cache-markøren i slutningen af den delte del; Ellers ville hver anmodning skrive sin egen separate cache, og intet af det ville blive læst.
En advarsel: cachen afhænger af modellen og en vis minimumsstørrelse. Meget små præfikser (under et par tusinde tokens, afhængigt af modellen) vil ikke stille ind i cachen, selvom du markerer dem - cache_creation_input_tokens forbliver nul. Ændring af modellen midt i samtalen ugyldiggør også hele cachen; Hvis en anden opgave kræver en billig model, så hold hovedflowet i én model og læg sidejobbet i et separat opkald.
Sammenfattende
Prompt-caching er et præfiksmatch: fast indhold skal være i begyndelsen, variabelt indhold skal være i slutningen. For en stor, genbrugt kontekst er læseomkostningerne en tiendedel af den fulde pris, groft set lige i to anmodninger. Den mest almindelige fejl er at ødelægge præfikset ved at indlejre variable data i systemprompten; Du bekræfter hittet ved at måle det i brugsfeltet.
Ansøgningsopgave
Vælg en arbejdsbyrde. (1) Opdel indholdet i to kolonner: "ændrer aldrig" og "ændres med hver anmodning". (2) Tegn promptstrukturen igen, og sæt den konstante del i begyndelsen og den variable del i slutningen. (3) Estimer token-størrelsen af den faste del og sammenlign de månedlige omkostninger med/uden cache. (4) Bemærk hvilket felt (cache_read_input_tokens) du vil bekræfte hit fra.
tjekliste
- [ ] Jeg kan forklare, at cache er præfiksmatching og den eneste uforanderlige regel.
- [ ] Jeg kan øge nøjagtigheden ved at sætte det faste indhold i begyndelsen og variablen i slutningen.
- [ ] Jeg kender skrive-/læseøkonomi og break-even-punktet med to anmodninger.
- [ ] Jeg kan genkende lydløse forstyrrere (dato, uordnet JSON, skiftende køretøjsliste).
- [ ] Jeg kan verificere hittet med usage.cache_read_input_tokens.