Dobici:
- Objasnite logiku podudaranja prefiksa brzog keširanja
- Povećava pogodak u keš memoriji stavljanjem fiksnog konteksta na prvo mjesto, a promjenjivog konteksta poslije
- Može izračunati ekonomiku pisanja/čitanja keša i tačku rentabilnosti
LLM proizvod izgleda jeftino u prototipu; Kada se popnete na vagu, račun iznenađuje. 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čki sistemski prompt, pravilnik, referentna dokumentacija. Promptno keširanje eliminira upravo ovaj otpad. U ovoj jedinici ćete naučiti kako keš radi, kako organizirati prompt za hit i kako izračunati tačku rentabilnosti keš ekonomije. Kada je pravilno instaliran, sam može prepoloviti vaš račun ili čak niže.
Kako radi keš memorija? Jedno nepromjenjivo pravilo
Prompt caching je podudaranje prefiksa. Provajder privremeno pohranjuje tokene koje je obradio od početka vašeg upita. Ako prompt počinje sa istim prefiksom na sledećem zahtevu, ovaj zajednički deo se ne izračunava ponovo; Mnogo je jeftinije za čitanje od keširanja.
Iz ovoga slijedi jedno nepromjenjivo pravilo: Ako se jedan bajt promijeni bilo gdje u prefiksu, cijeli keš postaje nevažeći od tog trenutka nadalje. Odnosno, fiksni sadržaj treba da bude na početku, a promenljivi sadržaj na kraju. Ako stavite liniju na početak sistemske prompta koja se mijenja sa svakim zahtjevom, kao što je "Današnji datum: 18.07.2026", sve iza toga neće moći ući u keš memoriju.
Redoslijed obrade je obično: alati → sistemski prompt → poruke. Stavljate keš tačku (prelomnu tačku) na kraj fiksnog odeljka.
Cache Economy
Cache ima tri nivoa cijena:
- Upisivanje u keš memoriju: pohranjivanje po prvi put. ~1,25x normalna ulazna cijena (za pohranu od 5 minuta).
- Predmemorija čitanja: Čitanje narednih zahtjeva. ~0,1 puta normalne ulazne cijene — to jest, jedna desetina.
- Normalan unos: Dio koji ne ulazi u keš memoriju i svaki put se obrađuje po punoj cijeni.
Tačka rentabilnosti: Prvi zahtjev plaća premiju za pisanje (1,25×). Od drugog zahtjeva, očitavanje (0,1×) ulazi u igru. Otprilike, bit ćete vrat i vrat na dva zahtjeva; Nakon toga, to je neto ušteda. Što je veći fiksni kontekst i što se više zahtjeva ponovo koristi, to je veći dobitak.
Scenario
Radi li keš memorija?
Veliki fiksni sistemski prompt, hiljade zahteva
Da — najveća zarada
Mnogo pitanja o istim referentnim dokumentima
Da
Potpuno drugačiji kratki tekst za svaki zahtjev
Ne — bonus za pisanje je izgubljen
Jednokratni zahtjev
Ne — nema čitanja uopšte
Datum/ID se mijenja sa svakim zahtjevom u sistemskom promptu
Ne — prefiks je pokvaren, pogodak je nula
Korak po korak: Kako postaviti hit prompt?
- Odvojite konstantu i varijablu. Koji se sadržaj nikada ne mijenja (sistemski prompt, pravilnik, dokumentacija)? Što se mijenja sa svakim zahtjevom (korisničko pitanje, datum, ID)?
- Stavite konstantu na početak. Tokom obrade, dio koji je prvi (alati, sistem) mora biti stabilan.
- Stavite varijablu na kraj. Korisnikovo trenutno pitanje, posljednje.
- Postavite znak na kraj granice. Stavite keš tačku u posljednji blok fiksnog dijela.
- Potvrdi pogodak. Provjerite je li cache_read_input_tokens veći od nule u polju za korištenje u odgovoru. Ako je nula, postoji skriveni disruptor u prefiksu.
{ "system": [ { "type": "text", "text": "{{large_constant_system_promptu_and_rules}}", "cache_control": { "type": "efemeran" } } ], "messages": [ { "role": "user", "content": "{}user}_current"
Savjet: Ne pogađajte pogotke u keš memoriji, mjerite ih. Ako je usage.cache_read_input_tokens i dalje nula na uzastopnim zahtjevima, pokreće se tihi prekidač (datetime.now() na sistemskom promptu, neuređeni JSON, lista alata koja se mijenja sa svakim zahtjevom). Uporedite sirovi prompt dva zahteva bajt po bajt i pronađite razliku.
Silent Disruptors
Tipični obrasci koji nesvjesno oštećuju keš memoriju:
# BREAKER: ugrađivanje informacija u sistemsku promptu koja se mijenja sa svakim zahtjevom "Današnji datum: {{sada}}. Vi ste asistent..." ← prefiks se mijenja sa svakim zahtjevom, pogodak je nula# TRUE: premjestite varijablu u sistem poruka: "Vi ste asistent..." {← konstanta ulazi u keš poruke, [{role:w user is content: "To:w}}. ..."}] ← varijabla na kraju
Ostali razbijači: JSON različito sortiran za svaki zahtjev (ključeve držite u fiksnom redoslijedu), lista alata koja se razlikuje od korisnika (alati se prvo obrađuju; ništa ne ide u keš ako se promijeni), promjena modela usred razgovora (kešovi su specifični za model).
Slaba prompt / Jaka prompt (struktura prilagođena keš memoriji)
# SLABO (izgradnja cache busting) sistem: "Datum: 18.07.2026 14:32. Korisnik: Ahmet (id 8842). Vi ste bot za podršku. Pravila: ...(2000 tokena)..."
# STRONG (struktura prilagođena keš memoriji) sistem: "Vi ste bot za podršku. Pravila: ...(2000 tokena, nikada se ne mijenja)..." [cache sign]mess: [ { role: user, content: "Datum: 18.07.2026. 14:32. Korisnički ID: 8842. Pitanje: kako da pokrenem povrat novca?" }]
U slaboj verziji, blok pravila od 2000 tokena se obrađuje po punoj cijeni na svaki zahtjev. U jakoj verziji isti blok se piše jednom i čita na svim narednim zahtjevima za desetinu cijene.
Tri mini futrole
Slučaj 1 — Keširanje pravilnika. Računovodstvena automatizacija je dodavala pravilnik o 12.000 tokena svakoj fakturi; 5.000 zahtjeva dnevno. Unos bez predmemorije košta ~180$ po danu. Zadržali su pravilnik konstantnim i keširali ga: prvi zahtjevi su platili premiju za pisanje, naknadno čitanje 0,1×. Troškovi ulaza su pali ~90% na ~18$ po danu.
Slučaj 2 — Trošak skrivene datumske linije. Jedan tim je postavio keš memoriju, ali nije dobio nijedan pogodak; cache_read_input_tokens je uvijek bio nula. Razlog: Bilo je datetime.now() u prvom redu sistemskog prompta, prefiks se mijenjao sa svakim zahtjevom. Kada smo premjestili datum u korisničku poruku, stopa pogodaka je odjednom porasla sa 0% na 94%.
Slučaj 3 — Zagubljen keš. Aplikacija za pretraživanje je slala potpuno različite kratke upite sa svakim zahtjevom; Nestrpljivo su dodali znak za predmemoriju. Bez zajedničkog prefiksa, svaki zahtjev je plaćao samo premiju za pisanje, bez čitanja – povećavajući cijenu. Uklonili su znak. Lekcija: keš se isplati samo ako postoji veliki i konstantni prefiks koji se ponovo koristi.
Uobičajene greške
- Miješanje konstante i varijable: Kada je sadržaj varijable u prefiksu, pogodak se resetuje.
- Ugrađivanje datuma/ID-a u sistemski prompt: Najčešći tihi disruptor.
- Ne mjerenje pogotka: Ako cache_read_input_tokens nije označen, gubitak neće biti primjećen.
- Dodavanje predmemorije kada ne postoji javni prefiks: Plaćate samo premiju za pisanje, trošak se povećava.
- Promjena liste vozila ili modela: Prefiks je pokvaren od početka; sve je prepisano.
- Zaboravljanje minimalne veličine keša: Vrlo kratke keš memorije (ispod ~1–4k tokena u zavisnosti od modela) neće tiho ući u keš memoriju.
Dublje: Dizajniranje predmemorije prema tipu radnog opterećenja
Stvarna isplata keširanja varira u zavisnosti od prirode vašeg posla; pa se prvo upoznajte sa svojim prometom. Tri tipična uzorka i ispravna instalacija:
Zajednički sistemski prompt, različita pitanja. Najčešći obrazac preduzeća: veliki sistemski prompt (uloga, pravila, možda referentni dokument) sa stotinama različitih korisničkih pitanja. Ovdje se fiksni dio (sistem) inicijalno kešira; svako novo pitanje plaća punu cijenu samo za svoj mali dio. Dobitak je vrlo visok jer se veliki dio recituje više puta po desetini cijene.
Višekružni monolog. Kako se razgovor odugovlači, svaki novi krug se nadograđuje na sve prethodne istorije. Ako stavite keš zastavicu na kraj posljednje runde, svaki zahtjev ponovo koristi prethodni prefiks razgovora; pogoci se akumuliraju kako razgovor raste. Ovo dramatično obuzdava troškove dugih asistenata.
Zajednički prefiks je posljednji bit za promjenu. Više zahtjeva dijeli veliki skup fiksnih prioriteta (skup uzoraka, instrukcije), ali su razdvojeni jednim pitanjem na kraju. Stavljate keš pokazivač na kraj zajedničkog dijela; U suprotnom, svaki zahtjev bi napisao svoju posebnu keš memoriju i ništa od toga ne bi bilo pročitano.
Jedno upozorenje: keš memorija ovisi o modelu i određenoj minimalnoj veličini. Vrlo mali prefiksi (ispod nekoliko hiljada tokena, ovisno o modelu) neće tiho ući u keš memoriju čak i ako ih označite – cache_creation_input_tokens ostaje nula. Također, promjena modela usred razgovora poništava cijeli keš; Ako drugi zadatak zahtijeva jeftin model, zadržite glavni tok u jednom modelu i stavite sporedni posao u poseban poziv.
Ukratko
Prompt caching je podudaranje prefiksa: fiksni sadržaj bi trebao biti na početku, promjenljivi sadržaj bi trebao biti na kraju. Za veliki kontekst koji se ponovo koristi, trošak čitanja je desetina pune cijene, što je otprilike čak i za dva zahtjeva. Najčešća greška je oštećenje prefiksa ugrađivanjem varijabilnih podataka u sistemski prompt; Pogodak potvrđujete mjerenjem u polju upotrebe.
Zadatak aplikacije
Odaberite radno opterećenje. (1) Podijelite sadržaj u dvije kolone: "nikad se ne mijenja" i "mijenja se sa svakim zahtjevom". (2) Ponovo nacrtajte prompt strukturu, stavljajući konstantni dio na početak i promjenljivi dio na kraj. (3) Procijenite veličinu tokena fiksnog dijela i uporedite mjesečni trošak sa/bez keša. (4) Zabilježite iz kojeg polja (cache_read_input_tokens) ćete provjeriti pogodak.
kontrolna lista
- [ ] Mogu objasniti da je predmemorija podudaranje prefiksa i jedino nepromjenjivo pravilo.
- [ ] Mogu povećati tačnost tako što ću fiksni sadržaj staviti na početak i promjenljivu na kraj.
- [ ] Znam ekonomiju pisanja/čitanja i tačku rentabilnosti sa dva zahtjeva.
- [ ] Mogu prepoznati tihe disruptore (datum, neuređeni JSON, mijenjanje liste vozila).
- [ ] Mogu provjeriti pogodak sa usage.cache_read_input_tokens.