Pag-optimize ng Gastos: Prompt Caching

Mga nadagdag:

• Ipaliwanag ang prefix matching logic ng prompt caching
• Pinapataas ang cache hit sa pamamagitan ng paglalagay sa nakapirming konteksto muna at variable na konteksto pagkatapos
• Maaaring kalkulahin ang cache write/read economics at break-even point

Ang isang produkto ng LLM ay mukhang mura sa prototype; Kapag humakbang ka sa sukat, ang kuwenta ay sorpresa. Sa karamihan ng mga workload, karamihan sa bill ay nagmumula sa parehong nakapirming konteksto na paulit-ulit na ipinapadala sa bawat kahilingan: isang mahabang prompt ng system, isang rulebook, reference na dokumentasyon. Eksaktong tinatanggal ng maagang pag-cache ang basurang ito. Sa unit na ito, matututunan mo kung paano gumagana ang cache, kung paano ayusin ang prompt na pindutin, at kung paano kalkulahin ang break-even point ng ekonomiya ng cache. Kapag na-install nang tama, maaari nitong bawasan ang iyong bill sa kalahati o mas mababa pa.

Paano Gumagana ang Cache? Ang Isang Hindi Nababagong Panuntunan

Ang maagang pag-cache ay isang tugma ng prefix. Pansamantalang iniimbak ng provider ang mga token na naproseso nito mula sa simula ng iyong prompt. Kung ang prompt ay magsisimula sa parehong prefix sa susunod na kahilingan, ang karaniwang bahaging ito ay hindi muling kinalkula; Ito ay mas murang basahin kaysa sa cache.

Isang hindi nababagong panuntunan ang sumusunod mula rito: Kung nagbabago ang isang byte saanman sa prefix, ang buong cache ay magiging invalid mula sa puntong iyon. Ibig sabihin, ang nakapirming nilalaman ay dapat nasa simula at ang variable na nilalaman ay dapat nasa dulo. Kung maglalagay ka ng linya sa simula ng prompt ng system na nagbabago sa bawat kahilingan, gaya ng "Petsa ngayong araw: 18.07.2026", hindi makakapasok sa cache ang lahat ng nasa likod nito.

Ang pagkakasunud-sunod ng pagproseso ay karaniwang: mga tool → prompt ng system → mga mensahe. Ilalagay mo ang cache point (breakpoint) sa dulo ng nakapirming seksyon.

Cache Economy

Ang cache ay may tatlong antas ng presyo:

• Cache write: Pag-iimbak sa unang pagkakataon. ~1.25x normal na presyo ng pag-input (para sa 5 minutong imbakan).
• Cache read: Pagbabasa sa mga kasunod na kahilingan. ~0.1 beses ang normal na presyo ng input — ibig sabihin, isang ikasampu.
• Normal na input: Ang bahagi na hindi pumapasok sa cache at pinoproseso sa buong halaga sa bawat oras.

Break-even point: Ang unang kahilingan ay nagbabayad ng write premium (1.25×). Mula sa pangalawang kahilingan, ang pagbabasa (0.1×) ay papasok. Sa halos lahat, ikaw ay magiging leeg at leeg sa dalawang kahilingan; Pagkatapos nito, ito ay net savings. Kung mas malaki ang nakapirming konteksto at mas maraming kahilingan ito ay muling ginagamit, mas malaki ang pakinabang.

Sitwasyon

Gumagana ba ang cache?

Malaking fixed system prompt, libu-libong mga kahilingan

Oo — pinakamataas na kita

Maraming tanong sa parehong reference na doc

Oo

Ganap na magkakaibang maikling teksto para sa bawat kahilingan

Hindi — nasayang ang write bonus

Isang beses na kahilingan

Hindi — walang pagbabasa

Pagbabago ng petsa/ID sa bawat kahilingan sa prompt ng system

Hindi — nasira ang prefix, zero ang hit

Hakbang sa Hakbang: Paano Mag-set Up ng Hit Prompt?

1. Paghiwalayin ang pare-pareho at variable. Anong content ang hindi nagbabago (system prompt, rulebook, documentation)? Aling mga pagbabago sa bawat kahilingan (tanong ng user, petsa, ID)?
2. Ilagay ang pare-pareho sa simula. Sa panahon ng pagproseso, ang bahagi na mauna (mga kasangkapan, sistema) ay dapat na matatag.
3. Ilagay ang variable sa dulo. Kasalukuyang tanong ng user, huli.
4. Ilagay ang karatula sa dulo ng hangganan. Ilagay ang cache point sa huling bloke ng nakapirming bahagi.
5. I-verify ang hit. Tingnan kung ang cache_read_input_tokens ay mas malaki kaysa sa zero sa field ng paggamit sa tugon. Kung zero, may nakatagong disruptor sa prefix.

{ "system": [ { "type": "text", "text": "{{large_constant_system_promptu_and_rules}}", "cache_control": { "type": "ephemeral" } } ], "message": [ { "role": "user", "content": "{{user_current_}}tanong

Tip: Huwag hulaan ang mga hit sa cache, sukatin ang mga ito. Kung zero pa rin ang usage.cache_read_input_tokens sa magkakasunod na kahilingan, tumatakbo ang isang silent breaker (datetime.now() sa prompt ng system, hindi nakaayos na JSON, listahan ng mga tool na nagbabago sa bawat kahilingan). Ihambing ang raw prompt ng dalawang kahilingan byte byte at hanapin ang pagkakaiba.

Mga Silent Disruptor

Mga karaniwang pattern na hindi sinasadyang sumisira sa cache:

# BREAKER: pag-embed ng impormasyon sa prompt ng system na nagbabago sa bawat kahilingan "Petsa ngayong araw: {{now}}. Isa kang assistant..." ← nagbabago ang prefix sa bawat kahilingan, ang hit ay zero# TRUE: ilipat ang variable sa messagesystem: "Isa kang assistant..." ← constant ang pumapasok sa cachemessages: [{role: user, content: "Ngayon ay {:{now}}. Ngayon ay {:{now}}.

Iba pang mga breaker: Iba-iba ang pagkakasunud-sunod ng JSON sa bawat kahilingan (panatilihin ang mga key sa nakapirming pagkakasunud-sunod), listahan ng mga tool na iba-iba ayon sa user (mga tool ang unang pinoproseso; walang pumapasok sa cache kung magbabago ang mga ito), binabago ang modelo sa kalagitnaan ng pag-uusap (ang mga cache ay partikular sa modelo).

Mahinang prompt / Malakas na prompt (cache friendly na istraktura)

# WEAK (cache busting build)system: "Petsa: 18.07.2026 14:32. User: Ahmet (id 8842). Isa kang support bot. Mga Panuntunan: ...(2000 token)..."

# STRONG (cache-friendly structure)system: "Ikaw ay isang support bot. Mga Panuntunan: ...(2000 token, hindi nagbabago)..." [cache sign]mga mensahe: [ { role: user, content: "Date: 18.07.2026 14:32. User id: 8842. Question: paano ko sisimulan ang aking refund?" }]

Sa mahinang bersyon, ang rule block ng 2000 token ay pinoproseso sa buong halaga sa bawat kahilingan. Sa malakas na bersyon, ang parehong bloke ay nakasulat nang isang beses at basahin sa lahat ng kasunod na mga kahilingan para sa ikasampu ng presyo.

Tatlong Mini Case

Case 1 — Pag-cache sa rulebook. Isang accounting automation ang nagdaragdag ng 12,000 token rulebook sa bawat invoice; 5,000 kahilingan bawat araw. Ang cacheless input ay nagkakahalaga ng ~$180 bawat araw. Pinapanatili nilang pare-pareho ang rulebook at na-cache ito: ang mga unang kahilingan ay nagbayad ng write premium, ang mga kasunod na nabasa ay 0.1×. Bumaba ang halaga ng input ~90% hanggang ~$18 bawat araw.

Case 2 — Gastos ng nakatagong linya ng petsa. Nag-set up ang isang team ng cache ngunit walang natatanggap na hit; Ang cache_read_input_tokens ay palaging zero. Dahilan: Nagkaroon ng datetime.now() sa unang linya ng system prompt, nagbabago ang prefix sa bawat kahilingan. Noong inilipat namin ang petsa sa mensahe ng user, biglang tumaas ang hit rate mula 0% hanggang 94%.

Case 3 — Maling lugar na cache. Ang isang application sa paghahanap ay nagpapadala ng ganap na magkakaibang mga maikling query sa bawat kahilingan; Sabik silang nagdagdag ng cache sign. Nang walang karaniwang prefix, binayaran lang ng bawat kahilingan ang write premium, walang reads — pagtaas ng gastos. Tinanggal nila ang karatula. Aralin: magbabayad lamang ang cache kung mayroong malaki at pare-parehong prefix na muling ginagamit.

Mga karaniwang pagkakamali

• Paghahalo ng pare-pareho at variable: Kapag nasa prefix ang variable na content, ire-reset ang hit.
• Pag-embed ng petsa/ID sa system prompt: Ang pinakakaraniwang silent disruptor.
• Hindi sinusukat ang hit: Kung hindi nasuri ang cache_read_input_tokens, hindi mapapansin ang basura.
• Pagdaragdag ng cache kapag walang pampublikong prefix: Magbabayad ka lang ng write premium, tumataas ang gastos.
• Pagbabago ng listahan o modelo ng sasakyan: Ang prefix ay nasira mula sa simula; lahat ay muling isinulat.
• Nakalimutan ang pinakamababang laki ng cache: Ang mga napakaikling cache (sa ilalim ng ~1–4k token depende sa modelo) ay hindi papasok sa cache nang tahimik.

Mas malalim: Pagdidisenyo ng Cache ayon sa Uri ng Workload

Ang aktwal na kabayaran ng pag-cache ay nag-iiba depende sa uri ng iyong workload; kaya kilalanin mo muna ang iyong trapiko. Tatlong karaniwang pattern at tamang pag-install:

Karaniwang prompt ng system, iba't ibang mga tanong. Ang pinakakaraniwang pattern ng enterprise: isang malaking prompt ng system (role, rules, maybe reference document) na may daan-daang iba't ibang tanong ng user. Dito ang nakapirming bahagi (system) ay naka-cache sa simula; bawat bagong tanong ay nagbabayad ng buong presyo para lamang sa sarili nitong maliit na bahagi. Napakataas ng kita dahil ang malaking bahagi ay binibigkas nang paulit-ulit sa ikasampu ng presyo.

Multi-round monologue. Habang tumatagal ang isang pag-uusap, ang bawat bagong round ay bubuo sa ibabaw ng lahat ng nakaraang kasaysayan. Kung ilalagay mo ang flag ng cache sa dulo ng huling round, muling gagamitin ng bawat kahilingan ang nakaraang prefix ng pag-uusap; naiipon ang mga hit habang lumalaki ang usapan. Ito ay kapansin-pansing nagpipigil sa gastos ng mahabang mga session ng katulong.

Ang nakabahaging prefix ay ang huling bit na magbabago. Ang maramihang mga kahilingan ay nagbabahagi ng malaking hanay ng mga nakapirming prior (sample set, mga tagubilin) ​​ngunit pinaghihiwalay ng isang tanong sa dulo. Inilagay mo ang cache pointer sa dulo ng nakabahaging bahagi; Kung hindi, ang bawat kahilingan ay magsusulat ng sarili nitong hiwalay na cache at wala sa mga ito ang mababasa.

Isang caveat: ang cache ay nakasalalay sa modelo at isang tiyak na minimum na laki. Ang napakaliit na prefix (sa ilalim ng ilang libong token, depende sa modelo) ay hindi tahimik na papasok sa cache kahit na i-flag mo ang mga ito — ang cache_creation_input_tokens ay nananatiling zero. Gayundin, ang pagpapalit ng modelo sa kalagitnaan ng pag-uusap ay magpapawalang-bisa sa buong cache; Kung ang ibang gawain ay nangangailangan ng murang modelo, panatilihin ang pangunahing daloy sa isang modelo at ilagay ang side job sa isang hiwalay na tawag.

Sa buod

Ang maagang pag-cache ay isang prefix na tugma: ang nakapirming nilalaman ay dapat nasa simula, ang variable na nilalaman ay dapat nasa dulo. Para sa isang malaki, muling ginamit na konteksto, ang read cost ay isang ikasampu ng buong presyo, halos break even sa dalawang kahilingan. Ang pinakakaraniwang pagkakamali ay ang sirain ang prefix sa pamamagitan ng pag-embed ng variable na data sa prompt ng system; Ibe-verify mo ang hit sa pamamagitan ng pagsukat nito sa field ng paggamit.

Gawain ng aplikasyon

Pumili ng workload. (1) Hatiin ang content sa dalawang column: "never change" at "changes with every request". (2) I-redraw ang prompt na istraktura, ilagay ang pare-parehong bahagi sa simula at ang variable na bahagi sa dulo. (3) Tantyahin ang laki ng token ng nakapirming bahagi at ihambing ang buwanang gastos na may/walang cache. (4) Tandaan kung saang field (cache_read_input_tokens) mo ibe-verify ang hit.

checklist

• [ ] Maaari kong ipaliwanag na ang cache ay pagtutugma ng prefix at ang tanging hindi nababagong panuntunan.
• [ ] Maaari kong pataasin ang katumpakan sa pamamagitan ng paglalagay ng nakapirming nilalaman sa simula at ang variable sa dulo.
• [ ] Alam kong magsulat/magbasa ng ekonomiya at ang dalawang-hiling na break-even point.
• [ ] Nakikilala ko ang mga silent disruptor (petsa, hindi nakaayos na JSON, pagbabago ng listahan ng sasakyan).
• [ ] Mabe-verify ko ang hit gamit ang usage.cache_read_input_tokens.