Optimizacija troškova: brzo predmemoriranje

Dobici:

• Objasnite logiku podudaranja prefiksa promptnog predmemoriranja
• Povećava učitavanje predmemorije postavljanjem fiksnog konteksta na prvo mjesto, a promjenjivog konteksta nakon njega
• Može izračunati ekonomičnost pisanja/čitanja predmemorije i točku pokrića

LLM proizvod izgleda jeftino u prototipu; Kad stanete na ljestvicu, račun iznenadi. U većini radnih opterećenja, većina računa dolazi iz istog fiksnog konteksta koji se šalje iznova i iznova sa svakim zahtjevom: dugačak upit sustava, pravilnik, referentna dokumentacija. Brzo predmemoriranje eliminira upravo ovaj otpad. U ovoj jedinici naučit ćete kako predmemorija radi, kako urediti odzivnik za pogodak i kako izračunati točku pokrića ekonomije predmemorije. Ako se pravilno instalira, samo on može prepoloviti vaš račun ili čak niže.

Kako radi predmemorija? Jedno nepromjenjivo pravilo

Prompt caching je podudaranje prefiksa. Davatelj privremeno pohranjuje tokene koje je obradio od početka vašeg upita. Ako prompt počinje s istim prefiksom na sljedećem zahtjevu, ovaj zajednički dio se ne izračunava ponovno; Puno je jeftiniji za čitanje od predmemorije.

Jedno nepromjenjivo pravilo slijedi iz ovoga: Ako se jedan bajt promijeni bilo gdje u prefiksu, cijela predmemorija postaje nevažeća od te točke nadalje. Odnosno, fiksni sadržaj trebao bi biti na početku, a promjenjivi sadržaj trebao bi biti na kraju. Ako na početak odzivnika sustava stavite crtu koja se mijenja sa svakim zahtjevom, npr. "Današnji datum: 18.07.2026", sve što je iza toga neće moći ući u predmemoriju.

Redoslijed obrade obično je: alati → odzivnik sustava → poruke. Stavljate točku predmemorije (prijelomnu točku) na kraj fiksnog odjeljka.

Ekonomija predmemorije

Cache ima tri cjenovne razine:

• Zapisivanje u predmemoriju: Pohranjivanje prvi put. ~1,25x uobičajena ulazna cijena (za 5 minuta skladištenja).
• Čitanje predmemorije: Čitanje sljedećih zahtjeva. ~0,1 puta normalna ulazna cijena — to jest, jedna desetina.
• Normalni unos: Dio koji ne ulazi u predmemoriju i obrađuje se po punoj cijeni svaki put.

Točka rentabilnosti: prvi zahtjev plaća premiju za pisanje (1,25×). Od drugog zahtjeva dolazi u obzir očitanje (0,1×). Otprilike, bit ćete jednaki oko dva zahtjeva; Nakon toga, to je neto štednja. Što je veći fiksni kontekst i što se više zahtjeva ponovno koristi, dobitak postaje veći.

Scenarij

Radi li predmemorija?

Veliki fiksni upit sustava, tisuće zahtjeva

Da — najveća zarada

Mnogo pitanja o istim referentnim dokumentima

da

Za svaki zahtjev potpuno drugačiji kratki tekst

Ne — bonus za pisanje je izgubljen

Jednokratni zahtjev

Ne — uopće nema čitanja

Datum/ID se mijenja sa svakim zahtjevom na upit sustava

Ne — prefiks je pokvaren, pogodak je nula

Korak po korak: Kako postaviti hit prompt?

1. Odvojite konstantu i varijablu. Koji se sadržaj nikada ne mijenja (upozorenje sustava, pravilnik, dokumentacija)? Što se mijenja sa svakim zahtjevom (pitanje korisnika, datum, ID)?
2. Stavite konstantu na početak. Tijekom obrade dio koji je prvi (alati, sustav) mora biti stabilan.
3. Stavite varijablu na kraj. Trenutno pitanje korisnika, posljednje.
4. Stavite znak na kraj obruba. Stavite točku predmemorije u zadnji blok fiksnog dijela.
5. Potvrdi pogodak. Provjerite je li cache_read_input_tokens veći od nule u polju upotrebe u odgovoru. Ako je nula, postoji skriveni disruptor u prefiksu.

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

Savjet: nemojte pogađati pogotke iz predmemorije, izmjerite ih. Ako je usage.cache_read_input_tokens još uvijek nula na uzastopnim zahtjevima, izvodi se tihi razbijač (datetime.now() na odzivniku sustava, neuređeni JSON, popis alata koji se mijenja sa svakim zahtjevom). Usporedite neobrađeni upit dvaju zahtjeva bajt po bajt i pronađite razliku.

Tihi disruptori

Tipični uzorci koji nesvjesno kvare predmemoriju:

# BREAKER: ugrađivanje informacija u upit sustava koji se mijenja sa svakim zahtjevom "Današnji datum: {{now}}. Vi ste pomoćnik..." ← prefiks se mijenja sa svakim zahtjevom, pogodak je nula# TRUE: premjestite varijablu u sustav poruka: "Vi ste pomoćnik..." ← konstanta ulazi u predmemoriju poruka: [{uloga: korisnik, sadržaj: "Danas je {{sada}}. Pitanje: ..."}] ← varijabla na kraju

Ostali razbijači: JSON različito sortiran na svaki zahtjev (drži ključeve fiksnim redoslijedom), popis alata koji se razlikuje prema korisniku (alati se prvi obrađuju; ništa ne ide u predmemoriju ako se promijene), mijenjanje modela usred razgovora (predmemorije su specifične za model).

Weak prompt / Strong prompt (cache friendly structure)

# SLABO (izrada cache busting) sustav: "Datum: 18.07.2026 14:32. Korisnik: Ahmet (id 8842). Vi ste bot za podršku. Pravila: ...(2000 tokena)..."

# JAKI (struktura pogodna za predmemoriju)sustav: "Vi ste bot za podršku. Pravila: ...(2000 tokena, nikad se ne mijenja)..." [znak predmemorije]poruke: [ { uloga: korisnik, sadržaj: "Datum: 18.07.2026 14:32. ID korisnika: 8842. Pitanje: kako da pokrenem svoj povrat?" }]

U slaboj verziji, blok pravila od 2000 tokena obrađuje se uz punu cijenu na svaki zahtjev. U jakoj verziji, isti blok se piše jednom i čita na svim sljedećim zahtjevima za desetinu cijene.

Tri mini kućišta

Slučaj 1 — Spremanje pravilnika u predmemoriju. Računovodstvena automatizacija dodavala je pravilnik od 12.000 tokena svakoj fakturi; 5000 zahtjeva dnevno. Unos bez predmemorije košta ~180 USD dnevno. Držali su pravilnik konstantnim i spremili ga u predmemoriju: prvi zahtjevi plaćali su premiju za pisanje, kasnija čitanja 0,1×. Ulazni trošak pao je za ~90% na ~18 USD dnevno.

Slučaj 2 — Trošak skrivene datumske linije. Jedan tim je postavio skriveno spremište, ali nije bilo pogodaka; cache_read_input_tokens je uvijek bio nula. Razlog: bio je datetime.now() u prvom retku odzivnika sustava, prefiks se mijenjao sa svakim zahtjevom. Kada smo pomaknuli datum na korisničku poruku, stopa pogodaka odjednom je porasla s 0% na 94%.

Slučaj 3 — Zagubljena predmemorija. Aplikacija za pretraživanje slala je potpuno različite kratke upite sa svakim zahtjevom; Nestrpljivo su dodali znak cache. Bez zajedničkog prefiksa, svaki zahtjev plaćao je samo premiju za pisanje, bez čitanja - povećavajući trošak. Uklonili su znak. Lekcija: predmemorija se isplati samo ako postoji veliki i stalni prefiks koji se ponovno koristi.

Uobičajene greške

• Miješanje konstante i varijable: kada je sadržaj varijable u prefiksu, pogodak se resetira.
• Datum/ID ugradnje u odzivnik sustava: najčešći tihi ometač.
• Ne mjeri se pogodak: ako cache_read_input_tokens nije označen, gubitak se neće primijetiti.
• Dodavanje predmemorije kada nema javnog prefiksa: plaćate samo premiju za pisanje, trošak se povećava.
• Promjena popisa ili modela vozila: Prefiks je pokvaren od početka; sve je prepisano.
• Zaboravljanje minimalne veličine predmemorije: Vrlo kratke predmemorije (ispod ~1–4k tokena, ovisno o modelu) neće tiho ući u predmemoriju.

Dublje: Dizajniranje predmemorije prema vrsti opterećenja

The actual payoff of caching varies depending on the nature of your workload; pa prvo upoznajte svoj promet. Tri tipična uzorka i ispravna instalacija:

Uobičajeni upit sustava, različita pitanja. Najčešći poslovni obrazac: veliki sistemski upit (uloga, pravila, možda referentni dokument) sa stotinama različitih pitanja korisnika. Ovdje se fiksni dio (sustav) inicijalno sprema u predmemoriju; svako novo pitanje plaća punu cijenu samo za svoj mali dio. Dobitak je vrlo velik jer se veliki dio recitira više puta po desetini cijene.

Multi-round monologue. Kako se razgovor razvlači, svaki novi krug nadograđuje se na svu prethodnu povijest. Ako stavite oznaku predmemorije na kraj zadnje runde, svaki zahtjev ponovno koristi prethodni prefiks razgovora; hitovi se gomilaju kako razgovor raste. To dramatično smanjuje troškove dugih pomoćnih sesija.

Zajednički prefiks zadnji je bit koji treba promijeniti. Višestruki zahtjevi dijele veliki skup fiksnih prethodnih (set uzoraka, upute), ali su odvojeni jednim pitanjem na kraju. Pokazivač predmemorije stavite na kraj dijeljenog dijela; U suprotnom, svaki zahtjev bi napisao svoju zasebnu predmemoriju i ništa od toga ne bi bilo pročitano.

Jedno upozorenje: predmemorija ovisi o modelu i određenoj minimalnoj veličini. Vrlo mali prefiksi (ispod nekoliko tisuća tokena, ovisno o modelu) neće tiho ući u predmemoriju čak i ako ih označite — cache_creation_input_tokens ostaje nula. Također, promjena modela usred razgovora poništava cijelu predmemoriju; Ako drugi zadatak zahtijeva jeftini model, zadržite glavni tok u jednom modelu i stavite sporedni posao u zaseban poziv.

Ukratko

Promptno predmemoriranje podudaranje je prefiksa: fiksni sadržaj treba biti na početku, promjenjivi sadržaj treba biti na kraju. Za veliki, ponovno korišteni kontekst, trošak čitanja je desetina pune cijene, što je otprilike jednako u dva zahtjeva. Najčešća pogreška je pokvariti prefiks ugrađivanjem varijabilnih podataka u odzivnik sustava; Pogodak potvrđujete mjerenjem u polju korištenja.

Zadatak aplikacije

Odaberite radno opterećenje. (1) Podijelite sadržaj u dva stupca: "nikad se ne mijenja" i "mijenja sa svakim zahtjevom". (2) Ponovno nacrtajte strukturu brzice, stavljajući konstantni dio na početak, a varijabilni dio na kraj. (3) Procijenite veličinu tokena fiksnog dijela i usporedite mjesečni trošak s/bez predmemorije. (4) Zabilježite iz kojeg polja (cache_read_input_tokens) ćete potvrditi pogodak.

popis za provjeru

• [ ] Mogu objasniti da je predmemorija podudaranje prefiksa i jedino nepromjenjivo pravilo.
• [ ] Mogu povećati točnost stavljanjem fiksnog sadržaja na početak, a varijabilnog na kraj.
• [ ] Znam ekonomiju pisanja/čitanja i točku pokrića s dva zahtjeva.
• [ ] Mogu prepoznati tihe ometače (datum, neuređeni JSON, mijenjanje popisa vozila).
• [ ] Mogu potvrditi pogodak s usage.cache_read_input_tokens.