Gevinster:
- Forklar prefikssamsvarslogikken til promptbufring
- Øker hurtigbuffertreffet ved å sette fast kontekst først og variabel kontekst etter
- Kan beregne cache skrive/lese økonomi og break-even punkt
Et LLM-produkt ser billig ut i prototype; Når du går opp på skalaen, overrasker regningen. I de fleste arbeidsbelastninger kommer det meste av regningen fra den samme faste konteksten som sendes om og om igjen med hver forespørsel: en lang systemforespørsel, en regelbok, referansedokumentasjon. Rask bufring eliminerer akkurat dette avfallet. I denne enheten lærer du hvordan hurtigbufferen fungerer, hvordan du ordner ledeteksten for å treffe, og hvordan du beregner break-even-punktet for bufferøkonomien. Når den er installert på riktig måte, kan den alene halvere regningen eller enda lavere.
Hvordan fungerer cachen? Den ene uforanderlige regelen
Hurtigbufring er et prefiksmatch. Leverandøren lagrer midlertidig tokens den har behandlet siden begynnelsen av forespørselen din. Hvis ledeteksten starter med samme prefiks ved neste forespørsel, beregnes ikke denne fellesdelen på nytt; Det er mye billigere å lese enn cache.
En uforanderlig regel følger av dette: Hvis en enkelt byte endres hvor som helst i prefikset, blir hele cachen ugyldig fra det tidspunktet og utover. Det vil si at fast innhold skal være i begynnelsen og variabelt innhold skal være på slutten. Hvis du setter en linje i begynnelsen av systemmeldingen som endres med hver forespørsel, for eksempel "Datoens dato: 18.07.2026", vil ikke alt bak den kunne komme inn i cachen.
Behandlingsrekkefølgen er vanligvis: verktøy → systemmelding → meldinger. Du legger cachepunktet (breakpoint) på slutten av den faste delen.
Cache økonomi
Cachen har tre prisnivåer:
- Cache-skriv: Lagrer for første gang. ~1,25x normal inngangspris (for 5 minutters lagring).
- Cache lest: Lesing på påfølgende forespørsler. ~0,1 ganger normal inngangspris - det vil si en tidel.
- Normal input: Den delen som ikke kommer inn i cachen og behandles for full kostnad hver gang.
Break-even punkt: Første forespørsel betaler skrivepremie (1,25×). Fra den andre forespørselen kommer avlesningen (0,1×) inn. Omtrent, vil du være nakke og nakke på to forespørsler; Etter det er det netto sparing. Jo større den faste konteksten og jo flere forespørsler den gjenbrukes, desto større blir gevinsten.
Scenario
Fungerer cachen?
Stor fast systemforespørsel, tusenvis av forespørsler
Ja - høyest inntekt
Mange spørsmål om de samme referansedokumentene
Ja
Helt forskjellig kort tekst for hver forespørsel
Nei – skrivebonus er bortkastet
Engangsforespørsel
Nei – ingen lesing i det hele tatt
Dato/ID endres med hver forespørsel ved systemledeteksten
Nei – prefikset er brutt, treffet er null
Trinn for trinn: Hvordan sette opp en treffmelding?
- Skill konstant og variabel. Hvilket innhold endres aldri (systemmelding, regelbok, dokumentasjon)? Hvilke endringer med hver forespørsel (brukerspørsmål, dato, ID)?
- Sett konstanten i begynnelsen. Under behandlingen må delen som kommer først (verktøy, system) være stabil.
- Sett variabelen på slutten. Brukerens nåværende spørsmål, sist.
- Plasser skiltet på slutten av grensen. Sett cache-punktet i den siste blokken av den faste delen.
- Bekreft treff. Sjekk om cache_read_input_tokens er større enn null i bruksfeltet i svaret. Hvis null, er det en skjult forstyrrelse i prefikset.
{ "system": [ { "type": "text", "text": "{{large_constant_system_promptu_and_rules}}", "cache_control": { "type": "ephemeral" } } ], "meldinger": [ { "role": "bruker", "content": "{{queser]}}current
Tips: Ikke gjett cache-treff, mål dem. Hvis usage.cache_read_input_tokens fortsatt er null ved påfølgende forespørsler, kjører en stille bryter (datetime.now() ved systemledetekst, uordnet JSON, liste over verktøy som endres med hver forespørsel. Sammenlign den rå ledeteksten til de to forespørslene byte for byte og finn forskjellen.
Silent Disruptors
Typiske mønstre som uvitende ødelegger hurtigbufferen:
# BREAKER: innebygging av informasjon i systemmeldingen som endres med hver forespørsel "Dagens dato: {{now}}. Du er en assistent..." ← prefikset endres med hver forespørsel, treffet er null# TRUE: flytt variabelen til meldingssystemet: "Du er en assistent..." ← konstant skriver inn cachemessages: {{quension. "To:day user:" ..."}] ← variabel på slutten
Andre brytere: JSON sortert forskjellig på hver forespørsel (hold nøkler i fast rekkefølge), liste over verktøy som varierer etter bruker (verktøy behandles først; ingenting går inn i hurtigbufferen hvis de endres), endrer modellen midt i samtalen (cacher er modellspesifikke).
Svak forespørsel / sterk forespørsel (buffervennlig struktur)
# WEAK (cache busting build) system: "Dato: 18.07.2026 14:32. Bruker: Ahmet (id 8842). Du er en støtterobot. Regler: ...(2000 tokens)..."
# STERK (cache-vennlig struktur)system: "Du er en støtterobot. Regler: ...(2000 tokens, aldri endres)..." [cache-tegn]meldinger: [ { rolle: bruker, innhold: "Dato: 18.07.2026 14:32. Bruker-ID: 8842. Spørsmål: hvordan starter jeg refusjonen min?" }]
I den svake versjonen behandles regelblokken med 2000 tokens til full pris på hver forespørsel. I den sterke versjonen skrives samme blokk én gang og leses på alle påfølgende forespørsler for en tiendedel av prisen.
Tre minivesker
Tilfelle 1 — Bufre regelboken. En regnskapsautomatisering la til regelboken på 12 000 tokener til hver faktura; 5000 forespørsler per dag. Bufferløs inndata koster ~$180 per dag. De holdt regelboken konstant og bufret den: første forespørsler betalte en skrivepremie, påfølgende lesninger 0,1×. Inndatakostnaden falt ~90 % til ~$18 per dag.
Tilfelle 2 — Kostnad for skjult datolinje. Ett lag satte opp en cache, men fikk ingen treff; cache_read_input_tokens var alltid null. Årsak: Det var datetime.now() i den første linjen i systemprompten, prefikset ble endret med hver forespørsel. Da vi flyttet datoen til brukermeldingen, økte treffraten plutselig fra 0 % til 94 %.
Tilfelle 3 — Forlagt cache. En søkeapplikasjon sendte helt forskjellige korte søk med hver forespørsel; De la ivrig til et cache-skilt. Uten felles prefiks betalte hver forespørsel bare en skrivepremie, ingen lesninger – noe som øker kostnadene. De fjernet skiltet. Leksjon: cache betaler kun hvis det er et stort og konstant prefiks som gjenbrukes.
Vanlige feil
- Blanding av konstant og variabel: Når variabelinnholdet er i prefikset, tilbakestilles treffet.
- Innbyggingsdato/ID i systemprompt: Den vanligste stille forstyrreren.
- Måler ikke treffet: Hvis cache_read_input_tokens ikke er sjekket, vil avfall ikke bli lagt merke til.
- Legger til cache når det ikke er noe offentlig prefiks: Du betaler bare skrivepremien, kostnaden øker.
- Endre kjøretøylisten eller modellen: Prefikset er brutt fra begynnelsen; alt er skrevet om.
- Glem minimum cachestørrelse: Svært korte cacher (under ~1–4k tokens avhengig av modell) vil ikke gå inn i cachen stille.
Deeper: Designe cache etter arbeidsbelastningstype
Den faktiske utbetalingen av caching varierer avhengig av arten av arbeidsbelastningen din; så bli kjent med trafikken din først. Tre typiske mønstre og riktig installasjon:
Felles systemmelding, forskjellige spørsmål. Mest vanlig bedriftsmønster: en stor systemforespørsel (rolle, regler, kanskje referansedokument) med hundrevis av forskjellige brukerspørsmål. Her bufres den faste delen (systemet) innledningsvis; hvert nytt spørsmål betaler full pris kun for sin egen lille del. Gevinsten er veldig høy fordi den store delen blir resitert gjentatte ganger til en tidel av prisen.
Multi-rund monolog. Etter hvert som en samtale drar utover, bygger hver nye runde på toppen av all tidligere historie. Hvis du setter cache-flagget på slutten av siste runde, gjenbruker hver forespørsel det forrige samtaleprefikset; treff akkumuleres etter hvert som samtalen vokser. Dette reduserer kostnadene for lange assistentøkter dramatisk.
Det delte prefikset er den siste biten som skal endres. Flere forespørsler deler et stort sett med faste prioriteringer (prøvesett, instruksjoner), men er atskilt med ett enkelt spørsmål på slutten. Du setter cache-pekeren på slutten av den delte delen; Ellers ville hver forespørsel skrive sin egen separate hurtigbuffer og ingen av den ville bli lest.
En advarsel: cachen avhenger av modellen og en viss minimumsstørrelse. Svært små prefikser (under noen få tusen tokens, avhengig av modell) vil ikke stille inn i hurtigbufferen selv om du flagger dem - cache_creation_input_tokens forblir null. Endring av modellen midt i samtalen ugyldiggjør også hele hurtigbufferen; Hvis en annen oppgave krever en billig modell, hold hovedflyten i én modell og legg sidejobben i en egen samtale.
Oppsummert
Hurtigbufring er et prefiksmatch: fast innhold skal være i begynnelsen, variabelt innhold skal være på slutten. For en stor gjenbrukt kontekst er lesekostnaden en tidel av full pris, omtrent like i to forespørsler. Den vanligste feilen er å ødelegge prefikset ved å legge inn variable data i systemprompten; Du bekrefter treffet ved å måle det i bruksfeltet.
Søknadsoppgave
Velg en arbeidsmengde. (1) Del innholdet i to kolonner: "endrer aldri" og "endres med hver forespørsel". (2) Tegn forespørselstrukturen på nytt, sett den konstante delen i begynnelsen og den variable delen på slutten. (3) Estimer token-størrelsen til den faste delen og sammenlign den månedlige kostnaden med/uten cache. (4) Legg merke til hvilket felt (cache_read_input_tokens) du vil bekrefte treffet fra.
sjekkliste
- [ ] Jeg kan forklare at cache er prefiksmatching og den eneste uforanderlige regelen.
- [ ] Jeg kan øke nøyaktigheten ved å sette det faste innholdet i begynnelsen og variabelen på slutten.
- [ ] Jeg kan skrive/lese økonomi og break-even-punktet med to forespørsler.
- [ ] Jeg kan gjenkjenne lydløse forstyrrere (dato, uordnet JSON, endring av kjøretøyliste).
- [ ] Jeg kan bekrefte treffet med usage.cache_read_input_tokens.