Optimizacija stroškov: hitro predpomnjenje

Dobički:

• Pojasnite logiko ujemanja predpone pri predpomnjenju pozivov
• Poveča zadetek predpomnilnika tako, da najprej postavi fiksni kontekst in za njim spremenljiv kontekst
• Lahko izračuna ekonomičnost pisanja/branja predpomnilnika in točko preloma

Izdelek LLM je v prototipu videti poceni; Ko stopiš na lestvico, račun preseneti. Pri večini delovnih obremenitev večina računa prihaja iz istega fiksnega konteksta, ki se vedno znova pošilja z vsako zahtevo: dolg sistemski poziv, pravilnik, referenčna dokumentacija. Hitro predpomnjenje odpravi natanko to zapravljanje. V tej enoti se boste naučili, kako deluje predpomnilnik, kako urediti poziv za zadetek in kako izračunati prag rentabilnosti predpomnilnika. Ob pravilni namestitvi lahko sam zmanjša vaš račun za polovico ali celo manj.

Kako deluje predpomnilnik? Eno nespremenljivo pravilo

Pozivno predpomnjenje je ujemanje predpone. Ponudnik začasno shrani žetone, ki jih je obdelal od začetka vašega poziva. Če se poziv pri naslednji zahtevi začne z isto predpono, se ta skupni del ne izračuna znova; Branje je veliko cenejše kot predpomnilnik.

Iz tega sledi eno nespremenljivo pravilo: če se en sam bajt spremeni kjer koli v predponi, postane celoten predpomnilnik od te točke naprej neveljaven. To pomeni, da mora biti fiksna vsebina na začetku, spremenljiva vsebina pa na koncu. Če na začetek sistemskega poziva postavite vrstico, ki se spreminja z vsako zahtevo, na primer »Današnji datum: 18.07.2026«, vse, kar je za njo, ne bo moglo vstopiti v predpomnilnik.

Vrstni red obdelave je običajno: orodja → sistemski poziv → sporočila. Točko predpomnilnika (prekinitveno točko) postavite na konec fiksnega odseka.

Ekonomija predpomnilnika

Cache ima tri cenovne stopnje:

• Pisanje v predpomnilnik: Prvo shranjevanje. ~1,25-kratna običajna vhodna cena (za 5-minutno shranjevanje).
• Branje v predpomnilniku: Branje na naslednjih zahtevah. ~0,1-kratnik običajne vhodne cene – to je ena desetina.
• Običajni vnos: del, ki ne vstopi v predpomnilnik in se vsakič obdela po polni ceni.

Točka preloma: prva zahteva plača premijo za pisanje (1,25 ×). Od druge zahteve pride v poštev odčitek (0,1×). V grobem boste na vratu na vrat na dve zahtevi; Po tem so neto prihranki. Večji kot je fiksni kontekst in več zahtev kot je ponovno uporabljenih, večji je dobiček.

Scenarij

Ali predpomnilnik deluje?

Velik fiksni sistemski poziv, na tisoče zahtev

Da — največji zaslužek

Veliko vprašanj o istih referenčnih dokumentih

ja

Za vsako zahtevo popolnoma drugačen kratek tekst

Ne — bonus za pisanje je zapravljen

Enkratna zahteva

Ne — sploh ne berem

Datum/ID se spreminja z vsako zahtevo v sistemskem pozivu

Ne — predpona je pokvarjena, zadetek je nič

Korak za korakom: Kako nastaviti poziv za zadetek?

1. Ločite konstanto in spremenljivko. Katera vsebina se nikoli ne spremeni (sistemski poziv, pravilnik, dokumentacija)? Kaj se spremeni z vsako zahtevo (vprašanje uporabnika, datum, ID)?
2. Konstanto postavite na začetek. Med obdelavo mora biti del, ki je prvi (orodja, sistem), stabilen.
3. Spremenljivko postavite na konec. Uporabnikovo trenutno vprašanje, zadnje.
4. Znak postavite na konec meje. Postavite točko predpomnilnika v zadnji blok fiksnega dela.
5. Preveri zadetek. Preverite, ali je cache_read_input_tokens večji od nič v polju za uporabo v odgovoru. Če je nič, je v predponi skrit motilec.

{ "system": [ { "type": "text", "text": "{{large_constant_system_promptu_and_rules}}", "cache_control": { "type": "ephemeral" } } ], "messages": [ { "role": "user", "content": "{{user_current_question}}" } ]}

Namig: ne ugibajte zadetkov predpomnilnika, temveč jih izmerite. Če je usage.cache_read_input_tokens pri zaporednih zahtevah še vedno nič, se izvaja tihi prekinjevalnik (datetime.now() v sistemskem pozivu, neurejen JSON, seznam orodij, ki se spreminja z vsako zahtevo). Primerjajte neobdelani poziv obeh zahtev bajt za bajtom in poiščite razliko.

Tihi motilci

Tipični vzorci, ki nevede poškodujejo predpomnilnik:

# BREAKER: vdelava informacij v sistemski poziv, ki se spremeni z vsako zahtevo "Današnji datum: {{zdaj}}. Vi ste pomočnik ..." ← predpona se spremeni z vsako zahtevo, zadetek je nič# TRUE: premaknite spremenljivko v sistem sporočil: "Ste pomočnik ..." ← konstanta vnese sporočila predpomnilnika: [{vloga: uporabnik, vsebina: "Danes je {{zdaj}}. Vprašanje: ..."}] ← spremenljivka na koncu

Drugi prekinjevalci: JSON je razvrščen drugače pri vsaki zahtevi (ključi se ohranijo v fiksnem vrstnem redu), seznam orodij se razlikuje glede na uporabnika (orodja se najprej obdelajo; nič ne gre v predpomnilnik, če se spremenijo), spreminjanje modela med pogovorom (predpomnilniki so specifični za model).

Šibek poziv/močan poziv (struktura, ki je prijazna do predpomnilnika)

# WEAK (cache busting build) sistem: "Datum: 18.07.2026 14:32. Uporabnik: Ahmet (id 8842). Ste podporni bot. Pravila: ...(2000 žetonov)..."

# STRONG (cache-prijazna struktura)sistem: "Ste podporni bot. Pravila: ...(2000 žetonov, nikoli se ne spremeni)..." [cache sign]sporočila: [ { vloga: uporabnik, vsebina: "Datum: 18.07.2026 14:32. ID uporabnika: 8842. Vprašanje: kako sprožim vračilo?" }]

V šibki različici se blok pravil 2000 žetonov ob vsaki zahtevi obdela po polni ceni. V močni različici se isti blok enkrat zapiše in prebere na vseh naslednjih zahtevah za desetino cene.

Trije mini kovčki

Primer 1 – Predpomnilnik pravilnika. Računovodska avtomatizacija je vsakemu računu dodajala pravilnik o 12.000 žetonih; 5.000 zahtevkov na dan. Vnos brez predpomnilnika stane ~180 USD na dan. Ohranjali so nespremenjen pravilnik in ga shranili v predpomnilnik: prve zahteve so plačale premijo za pisanje, naslednje branje 0,1×. Vhodni stroški so padli za ~90 % na ~18 USD na dan.

2. primer – Stroški skrite datumske vrstice. Ena ekipa je postavila predpomnilnik, vendar ni dosegla zadetkov; cache_read_input_tokens je bil vedno nič. Razlog: V prvi vrstici sistemskega poziva je bil datetime.now(), predpona se je spreminjala z vsako zahtevo. Ko smo premaknili datum v uporabniško sporočilo, se je stopnja zadetkov nenadoma povečala z 0 % na 94 %.

Primer 3 – Napačen predpomnilnik. Iskalna aplikacija je ob vsaki zahtevi pošiljala popolnoma drugačne kratke poizvedbe; Nestrpno so dodali znak zakladnice. Brez skupne predpone je vsaka zahteva plačala samo premijo za pisanje, brez branja - kar je povečalo stroške. Odstranili so znak. Lekcija: predpomnilnik se izplača le, če obstaja velika in konstantna predpona, ki se ponovno uporabi.

Pogoste napake

• Mešanje konstante in spremenljivke: Ko je vsebina spremenljivke v predponi, se zadetek ponastavi.
• Datum vdelave/ID v sistemski poziv: najpogostejši tihi motilec.
• Ni merjenja zadetka: če cache_read_input_tokens ni označen, potrat ne bo opažen.
• Dodajanje predpomnilnika, ko ni javne predpone: plačate samo premijo za pisanje, stroški se povečajo.
• Spreminjanje seznama vozil ali modela: Predpona je pokvarjena od začetka; vse je prepisano.
• Pozabljanje na najmanjšo velikost predpomnilnika: zelo kratki predpomnilniki (pod ~1–4k žetonov, odvisno od modela) ne bodo tiho vstopili v predpomnilnik.

Deeper: Oblikovanje predpomnilnika glede na vrsto delovne obremenitve

Dejanski izkupiček predpomnjenja se razlikuje glede na naravo vaše delovne obremenitve; zato najprej spoznajte svoj promet. Trije tipični vzorci in pravilna namestitev:

Skupni sistemski poziv, različna vprašanja. Najpogostejši vzorec podjetja: velik sistemski poziv (vloga, pravila, morda referenčni dokument) s stotinami različnih uporabniških vprašanj. Tukaj je fiksni del (sistem) prvotno predpomnjen; vsako novo vprašanje plača polno ceno samo za svoj majhen del. Dobiček je zelo visok, ker se velika porcija recitira večkrat za desetino cene.

Večkrožni monolog. Ko se pogovor vleče, vsak nov krog gradi na vsej prejšnji zgodovini. Če zastavico predpomnilnika postavite na konec zadnjega kroga, vsaka zahteva ponovno uporabi predpono prejšnjega pogovora; zadetki se kopičijo, ko pogovor raste. To dramatično zniža stroške dolgih pomočnikov.

Skupna predpona je zadnji bit, ki ga je treba spremeniti. Več zahtev ima velik nabor fiksnih predhodnih zahtev (nabor vzorcev, navodila), vendar so ločene z enim samim vprašanjem na koncu. Kazalec predpomnilnika postavite na konec dela v skupni rabi; V nasprotnem primeru bi vsaka zahteva zapisala svoj ločen predpomnilnik in nobena od njih ne bi bila prebrana.

Eno opozorilo: predpomnilnik je odvisen od modela in določene minimalne velikosti. Zelo majhne predpone (pod nekaj tisoč žetonov, odvisno od modela) ne bodo tiho vstopile v predpomnilnik, tudi če jih označite - cache_creation_input_tokens ostane nič. Poleg tega sprememba modela med pogovorom razveljavi celoten predpomnilnik; Če drugačna naloga zahteva poceni model, obdržite glavni tok v enem modelu in postavite stransko opravilo v ločen klic.

Če povzamem

Prompt caching je ujemanje predpone: fiksna vsebina mora biti na začetku, spremenljiva vsebina mora biti na koncu. Pri velikem, ponovno uporabljenem kontekstu je strošek branja desetina polne cene, kar je približno enako v dveh zahtevah. Najpogostejša napaka je pokvariti predpono z vdelavo spremenljivih podatkov v sistemski poziv; Zadetek preverite tako, da ga izmerite v polju uporabe.

Aplikacijska naloga

Izberite delovno obremenitev. (1) Vsebino razdelite v dva stolpca: »nikoli se ne spremeni« in »spremeni se z vsako zahtevo«. (2) Ponovno narišite strukturo poziva tako, da postavite stalni del na začetek in spremenljivi del na konec. (3) Ocenite žetonsko velikost fiksnega dela in primerjajte mesečne stroške z/brez predpomnilnika. (4) Upoštevajte, iz katerega polja (cache_read_input_tokens) boste preverili zadetek.

kontrolni seznam

• [ ] Lahko razložim, da je predpomnilnik ujemanje predpon in edino nespremenljivo pravilo.
• [ ] Natančnost lahko povečam tako, da postavim fiksno vsebino na začetek in spremenljivko na konec.
• [ ] Poznam ekonomiko pisanja/branja in točko preloma dveh zahtev.
• [ ] Znam prepoznati tihe motilce (datum, neurejen JSON, spreminjanje seznama vozil).
• [ ] Zadetek lahko preverim z usage.cache_read_input_tokens.