Fitimet:
- Shpjegoni logjikën e përputhjes së prefiksit të memories së shpejtë
- Rrit goditjen e cache-it duke vendosur në fillim kontekstin fiks dhe më pas kontekstin e ndryshueshëm
- Mund të llogarisë ekonominë e shkrimit/leximit në cache dhe pikën e kthimit
Një produkt LLM duket i lirë në prototip; Kur ngjiteni në shkallë, fatura befason. Në shumicën e ngarkesave të punës, pjesa më e madhe e faturës vjen nga i njëjti kontekst fiks që dërgohet pa pushim me çdo kërkesë: një mesazh i gjatë sistemi, një libër rregullash, dokumentacion referimi. Memoria e shpejtë eliminon pikërisht këtë humbje. Në këtë njësi, ju do të mësoni se si funksionon cache, si të rregulloni kërkesën për të goditur dhe si të llogaritni pikën e ndarjes së ekonomisë së cache. Kur instalohet siç duhet, vetëm ai mund të zvogëlojë faturën tuaj në gjysmë ose edhe më të ulët.
Si funksionon cache? Rregulli i vetëm i pandryshueshëm
Memoria e menjëhershme e memories është një përputhje parashtese. Ofruesi ruan përkohësisht argumentet që ka përpunuar që nga fillimi i kërkesës suaj. Nëse prompti fillon me të njëjtin prefiks në kërkesën tjetër, kjo pjesë e përbashkët nuk rillogaritet; Është shumë më lirë për t'u lexuar se cache.
Një rregull i pandryshueshëm rrjedh nga kjo: Nëse një bajt i vetëm ndryshon diku në prefiks, i gjithë cache bëhet i pavlefshëm nga ajo pikë e tutje. Kjo do të thotë, përmbajtja fikse duhet të jetë në fillim dhe përmbajtja e ndryshueshme duhet të jetë në fund. Nëse vendosni një rresht në fillim të promptit të sistemit që ndryshon me çdo kërkesë, si p.sh. "Data e sotme: 18.07.2026", gjithçka që qëndron pas tij nuk do të mund të hyjë në cache.
Rendi i përpunimit është zakonisht: vegla → prompt sistemi → mesazhe. Ju vendosni pikën e memories (pikën e ndërprerjes) në fund të seksionit fiks.
Ekonomia e cache
Cache ka tre nivele çmimesh:
- Shkrimi në cache: Ruajtja për herë të parë. ~ 1,25x çmimi normal i hyrjes (për 5 minuta ruajtje).
- Lexuar në cache: Leximi i kërkesave të mëvonshme. ~ 0.1 herë çmimi normal i hyrjes - domethënë një e dhjeta.
- Hyrja normale: Pjesa që nuk hyn në cache dhe përpunohet me kosto të plotë çdo herë.
Pika e barazimit: Kërkesa e parë paguan premium shkrimi (1,25×). Nga kërkesa e dytë hyn në lojë leximi (0.1×). Përafërsisht, ju do të jeni në qafë dhe në qafë për dy kërkesa; Pas kësaj, është kursim neto. Sa më i madh të jetë konteksti fiks dhe sa më shumë kërkesa të ripërdoret, aq më i madh bëhet fitimi.
Skenari
A funksionon cache?
Prompt i madh i sistemit fiks, mijëra kërkesa
Po - fitimet më të larta
Shumë pyetje për të njëjtat dokumente referimi
po
Tekst i shkurtër krejtësisht i ndryshëm për çdo kërkesë
Jo - bonusi i shkrimit është i humbur
Kërkesë një herë
Jo - pa lexim fare
Data/ID ndryshon me çdo kërkesë në kërkesën e sistemit
Jo - prefiksi është i prishur, goditja është zero
Hap pas hapi: Si të vendosni një kërkesë për goditje?
- Ndani konstante dhe variabël. Çfarë përmbajtje nuk ndryshon kurrë (kërkesa e sistemit, rregullorja, dokumentacioni)? Çfarë ndryshon me secilën kërkesë (pyetja e përdoruesit, data, ID)?
- Vendos konstanten në fillim. Gjatë përpunimit, pjesa që vjen e para (veglat, sistemi) duhet të jetë e qëndrueshme.
- Vendos variablin në fund. Pyetja aktuale e përdoruesit, e fundit.
- Vendoseni shenjën në fund të kufirit. Vendosni pikën e cache në bllokun e fundit të pjesës fikse.
- Verifiko goditjen. Kontrolloni nëse cache_read_input_tokens është më i madh se zero në fushën e përdorimit në përgjigje. Nëse zero, ka një ndërprerës të fshehur në prefiks.
{ "system": [ { "lloj": "tekst", "tekst": "{{large_constant_system_promptu_and_rules}}", "cache_control": { "type": "efemeral" } } ], "mesazhe": [{"role": "user", "content}_currency"{user}_
Këshillë: Mos i merrni me mend goditjet e cache-it, matini ato. Nëse usage.cache_read_input_tokens është ende zero në kërkesat e njëpasnjëshme, funksionon një ndërprerës i heshtur (datetime.now() në kërkesën e sistemit, JSON i parregulluar, lista e mjeteve që ndryshojnë me çdo kërkesë). Krahasoni kërkesën e papërpunuar të dy kërkesave bajt për bajt dhe gjeni ndryshimin.
Përçarës të heshtur
Modele tipike që korruptojnë pa vetëdije cache:
# BREAKER: futja e informacionit në sistemin e kërkesës që ndryshon me çdo kërkesë "Data e sotme: {{tani}}. Ju jeni një asistent..." ← prefiksi ndryshon me secilën kërkesë, goditja është zero# E VËRTETË: zhvendoseni variablin në sistemin e mesazheve: "Ju jeni një asistent..." ← konstanta hyn në mesazhet e memories: {roow user: {roow është përmbajtja: Pyetje: ..."}] ← ndryshore në fund
Ndërprerës të tjerë: JSON i renditur ndryshe për secilën kërkesë (mbani çelësat në rend fiks), lista e mjeteve që ndryshon sipas përdoruesit (veglat përpunohen fillimisht; asgjë nuk hyn në memorien specifike nëse ndryshojnë), duke ndryshuar modelin në mes të bisedës (memoria e fshehtë janë specifike për modelin).
Prompt i dobët / Prompt i fortë (strukturë miqësore me cache)
Sistemi # DOBËT (ndërtimi i cache busting): "Data: 18.07.2026 14:32. Përdoruesi: Ahmet (id 8842). Ju jeni një bot mbështetës. Rregullat: ...(2000 argumente)..."
Sistemi # STRONG (strukturë miqësore me cache): "Ju jeni një bot mbështetës. Rregullat: ...(2000 shenja, nuk ndryshon kurrë)..." [shenjë e memories] mesazhe: [ { roli: përdoruesi, përmbajtja: "Data: 18.07.2026 14:32. ID-ja e përdoruesit: 8842. Pyetje: si mund t'i rimbursoj?" }]
Në versionin e dobët, blloku i rregullave prej 2000 tokenësh përpunohet me kosto të plotë për çdo kërkesë. Në versionin e fortë, i njëjti bllok shkruhet një herë dhe lexohet në të gjitha kërkesat e mëvonshme për një të dhjetën e çmimit.
Tre Mini Rastet
Rasti 1 — Ruajtja në memorie e rregullores. Një automatizim i kontabilitetit po shtonte rregulloren 12,000 token në çdo faturë; 5000 kërkesa në ditë. Hyrja pa memorie kushton ~ 180 dollarë në ditë. Ata e mbajtën rregulloren konstante dhe e ruajtën në memorie të fshehtë: kërkesat e para paguanin një premium shkrimi, leximet pasuese 0.1×. Kostoja e hyrjes ra me ~ 90% në ~ 18 dollarë në ditë.
Rasti 2 - Kostoja e linjës së fshehur të datës. Një ekip krijoi një memorie të fshehtë, por nuk po merrte asnjë goditje; cache_read_input_tokens ishte gjithmonë zero. Arsyeja: Kishte datetime.now() në rreshtin e parë të kërkesës së sistemit, prefiksi po ndryshonte me çdo kërkesë. Kur e zhvendosëm datën te mesazhi i përdoruesit, shkalla e goditjes u rrit papritur nga 0% në 94%.
Rasti 3 - Cache e gabuar. Një aplikacion kërkimi po dërgonte pyetje të shkurtra krejtësisht të ndryshme me secilën kërkesë; Ata shtuan me padurim një shenjë cache. Pa prefiks të përbashkët, çdo kërkesë paguante vetëm një premium shkrimi, pa lexime - duke rritur koston. E hoqën shenjën. Mësimi: cache paguan vetëm nëse ka një parashtesë të madhe dhe konstante që ripërdoret.
Gabimet e zakonshme
- Përzierja e konstantës dhe variablit: Kur përmbajtja e ndryshores është në prefiks, goditja rivendoset.
- Përfshirja e datës/ID në kërkesën e sistemit: Ndërprerësi më i zakonshëm i heshtur.
- Mos matja e goditjes: Nëse cache_read_input_tokens nuk kontrollohet, mbetjet nuk do të vihen re.
- Shtimi i cache kur nuk ka prefiks publik: Ju paguani vetëm premiumin e shkrimit, kostoja rritet.
- Ndryshimi i listës ose modelit të automjeteve: Prefiksi është i prishur që në fillim; gjithçka është rishkruar.
- Harrimi i madhësisë minimale të memories: Memoria e memories shumë e shkurtër (nën ~ 1–4 mijë shenja në varësi të modelit) nuk do të hyjë në heshtje në memorie të fshehtë.
Më e thellë: Dizajnimi i cache sipas llojit të ngarkesës së punës
Shpërblimi aktual i memorizimit ndryshon në varësi të natyrës së ngarkesës suaj të punës; kështu që së pari njihuni me trafikun tuaj. Tre modele tipike dhe instalim i saktë:
Prompt i përbashkët i sistemit, pyetje të ndryshme. Modeli më i zakonshëm i ndërmarrjes: një mesazh i madh i sistemit (roli, rregulla, ndoshta dokument referimi) me qindra pyetje të ndryshme përdoruesi. Këtu pjesa fikse (sistemi) ruhet fillimisht në memorie; çdo pyetje e re paguan çmimin e plotë vetëm për pjesën e saj të vogël. Fitimi është shumë i lartë sepse pjesa e madhe recitohet në mënyrë të përsëritur me një të dhjetën e çmimit.
Monolog me shumë raunde. Ndërsa një bisedë zvarritet, çdo raund i ri ndërtohet mbi të gjithë historinë e mëparshme. Nëse vendosni flamurin e cache-it në fund të raundit të fundit, çdo kërkesë ripërdor prefiksin e bisedës së mëparshme; goditjet grumbullohen ndërsa biseda rritet. Kjo frenon në mënyrë dramatike koston e seancave të gjata të asistentit.
Parashtesa e përbashkët është pjesa e fundit për të ndryshuar. Kërkesat e shumëfishta ndajnë një grup të madh prioritetesh fikse (bashkësi mostër, udhëzime) por ndahen nga një pyetje e vetme në fund. Ju vendosni treguesin e cache në fund të pjesës së përbashkët; Përndryshe, çdo kërkesë do të shkruante cache-in e vet të veçantë dhe asnjë prej tyre nuk do të lexohej.
Një paralajmërim: cache varet nga modeli dhe një madhësi minimale e caktuar. Prefikset shumë të vogla (nën disa mijëra shenja, në varësi të modelit) nuk do të hyjnë në heshtje në cache edhe nëse i shënoni - cache_creation_input_tokens mbetet zero. Gjithashtu, ndryshimi i modelit në mes të bisedës zhvlerëson të gjithë cache-in; Nëse një detyrë tjetër kërkon një model të lirë, mbajeni rrjedhën kryesore në një model dhe vendosni punën anësore në një telefonatë të veçantë.
Në përmbledhje
Prompt caching është një përputhje me prefiksin: përmbajtja fikse duhet të jetë në fillim, përmbajtja e ndryshueshme duhet të jetë në fund. Për një kontekst të madh dhe të ripërdorur, kostoja e leximit është një e dhjeta e çmimit të plotë, afërsisht duke u thyer edhe në dy kërkesa. Gabimi më i zakonshëm është korruptimi i prefiksit duke futur të dhëna të ndryshueshme në promptin e sistemit; Ju verifikoni goditjen duke e matur atë në fushën e përdorimit.
Detyra e aplikimit
Zgjidhni një ngarkesë pune. (1) Ndani përmbajtjen në dy kolona: "nuk ndryshon kurrë" dhe "ndryshon me çdo kërkesë". (2) Rivizatoni strukturën e shpejtë, duke vendosur pjesën konstante në fillim dhe pjesën e ndryshueshme në fund. (3) Vlerësoni madhësinë e shenjës së pjesës fikse dhe krahasoni koston mujore me/pa cache. (4) Vini re se nga cila fushë (cache_read_input_tokens) do të verifikoni goditjen.
listë kontrolli
- [ ] Mund të shpjegoj se cache është përputhja e parashtesave dhe i vetmi rregull i pandryshueshëm.
- [ ] Mund ta rris saktësinë duke vendosur përmbajtjen fikse në fillim dhe variablin në fund.
- [ ] Unë e di ekonominë e shkrimit/leximit dhe pikën kufitare të dy kërkesave.
- [ ] Mund të njoh ndërprerës të heshtur (data, JSON i parregulluar, ndryshimi i listës së automjeteve).
- [ ] Mund ta verifikoj goditjen me usage.cache_read_input_tokens.