Optimizarea costurilor: Prompt Cache

Câștiguri:

• Explicați logica de potrivire a prefixelor pentru memorarea în cache a promptului
• Mărește accesul în cache punând contextul fix mai întâi și contextul variabil după
• Poate calcula scrierea/citirea cache-ului economic și pragul de rentabilitate

Un produs LLM pare ieftin în prototip; Când treci la scară, nota surprinde. În majoritatea sarcinilor de lucru, cea mai mare parte a facturii provine din același context fix care este trimis mereu și din nou cu fiecare solicitare: un prompt sistem lung, un cadru de reguli, documentație de referință. Memorarea promptă în cache elimină exact această risipă. În această unitate, veți învăța cum funcționează memoria cache, cum să aranjați promptul de a lovi și cum să calculați pragul de rentabilitate al economiei cache-ului. Când este instalat corect, acesta singur vă poate reduce factura la jumătate sau chiar mai mică.

Cum funcționează memoria cache? Singura regulă imuabilă

Memorarea promptă în cache este o potrivire a prefixului. Furnizorul stochează temporar jetoanele pe care le-a procesat de la începutul solicitării dvs. Dacă promptul începe cu același prefix la următoarea cerere, această parte comună nu este recalculată; Este mult mai ieftin de citit decât memoria cache.

Din aceasta rezultă o regulă imuabilă: dacă un singur octet se schimbă oriunde în prefix, întregul cache devine invalid din acel punct încolo. Adică, conținutul fix ar trebui să fie la început și conținutul variabil ar trebui să fie la sfârșit. Dacă puneți o linie la începutul promptului de sistem care se modifică cu fiecare solicitare, cum ar fi „Data de azi: 18.07.2026”, totul din spatele acesteia nu va putea intra în cache.

Ordinea de procesare este de obicei: instrumente → prompt de sistem → mesaje. Puneți punctul de cache (punctul de întrerupere) la sfârșitul secțiunii fixe.

Cache Economic

Cache-ul are trei niveluri de preț:

• Scriere în cache: se stochează pentru prima dată. ~1,25x prețul normal de intrare (pentru stocare de 5 minute).
• Citirea memoriei cache: Citirea solicitărilor ulterioare. ~0,1 ori prețul normal de intrare - adică o zecime.
• Intrare normală: partea care nu intră în cache și este procesată la costul total de fiecare dată.

Punct de rentabilitate: prima solicitare plătește o primă de scriere (1,25×). Din a doua solicitare intră în joc citirea (0,1×). Aproximativ, veți fi pe gât la două cereri; După aceea, este economii nete. Cu cât contextul fix este mai mare și cu cât este reutilizat mai multe solicitări, cu atât câștigul devine mai mare.

Scenariu

Funcționează cache-ul?

Prompt mare de sistem fix, mii de solicitări

Da, cel mai mare câștig

Multe întrebări pe aceleași documente de referință

Da

Text scurt complet diferit pentru fiecare cerere

Nu — bonusul de scriere este irosit

Cerere o singură dată

Nu, nicio citire

Data/ID-ul se schimbă cu fiecare solicitare la promptul de sistem

Nu — prefixul este rupt, hit-ul este zero

Pas cu pas: Cum să configurați un prompt de accesare?

1. Separați constanta și variabila. Ce conținut nu se schimbă niciodată (prompt de sistem, regulament, documentație)? Care se schimbă cu fiecare solicitare (întrebare utilizator, dată, ID)?
2. Pune constanta la început. În timpul prelucrării, piesa care vine prima (unelte, sistem) trebuie să fie stabilă.
3. Pune variabila la sfârșit. Întrebarea curentă a utilizatorului, ultima.
4. Așezați semnul la capătul graniței. Puneți punctul cache în ultimul bloc al părții fixe.
5. Verificați lovitura. Verificați dacă cache_read_input_tokens este mai mare decât zero în câmpul de utilizare din răspuns. Dacă este zero, există un perturbator ascuns în prefix.

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

Sfat: nu ghiciți accesările din cache, măsurați-le. Dacă usage.cache_read_input_tokens este încă zero la solicitările consecutive, rulează un întrerupător silențios (datetime.now() la promptul de sistem, JSON neordonat, lista de instrumente care se schimbă cu fiecare solicitare). Comparați promptul brut al celor două solicitări octet cu octet și găsiți diferența.

Perturbatori tăcuți

Tipare tipice care corupă în neștire cache-ul:

# BREAKER: încorporarea informațiilor în promptul de sistem care se modifică la fiecare solicitare „Data de azi: {{acum}}. Sunteți un asistent...” ← prefixul se modifică la fiecare solicitare, hit-ul este zero# TRUE: mutați variabila în sistemul de mesaje: „Sunteți un asistent...” ← constanta intră în cachemessages: [{rol: utilizatorul de astăzi}], Întrebare: {:”w}}] ← variabilă la sfârșit

Alte întreruperi: JSON sortat diferit la fiecare cerere (păstrați cheile în ordine fixă), lista de instrumente care variază în funcție de utilizator (instrumentele sunt procesate mai întâi; nimic nu intră în cache dacă se schimbă), schimbarea modelului la mijlocul conversației (cache-urile sunt specifice modelului).

Prompt slab/Prompt puternic (structură prietenoasă pentru cache)

# Sistem SLAB (construcție de blocare a memoriei cache): „Data: 18.07.2026 14:32. Utilizator: Ahmet (id 8842). Sunteți un bot de asistență. Reguli: ...(2000 de jetoane)...”

# Sistem STRONG (structură prietenoasă cu cache-ul): „Sunteți un bot de asistență. Reguli: ...(2000 de jetoane, nu se schimbă niciodată)...” [semn cache]mesaje: [ { rol: utilizator, conținut: „Data: 18.07.2026 14:32. ID utilizator: 8842. Întrebare: cum îmi inițiez rambursarea?” }]

În versiunea slabă, blocul de reguli de 2000 de jetoane este procesat la costul integral pentru fiecare solicitare. În versiunea puternică, același bloc este scris o dată și citit la toate cererile ulterioare pentru o zecime din preț.

Trei mini carcase

Cazul 1 — Memorarea în cache a caietului de reguli. O automatizare a contabilității a adăugat regulamentul de 12.000 de jetoane la fiecare factură; 5.000 de cereri pe zi. Intrarea fără cache costă ~180 USD pe zi. Ei au păstrat constant regulamentul și l-au stocat în cache: primele solicitări plăteau o primă de scriere, citirile ulterioare 0,1×. Costul de intrare a scăzut cu ~90% la ~18 USD pe zi.

Cazul 2 — Costul liniei de dată ascunse. O echipă a creat un cache, dar nu primea lovituri; cache_read_input_tokens a fost întotdeauna zero. Motiv: exista datetime.now() în prima linie a promptului de sistem, prefixul se schimba cu fiecare solicitare. Când am mutat data în mesajul utilizatorului, rata de accesare a crescut brusc de la 0% la 94%.

Cazul 3 — Cache greșit. O aplicație de căutare trimitea interogări scurte complet diferite cu fiecare cerere; Au adăugat cu nerăbdare un semn cache. Fără un prefix comun, fiecare solicitare plătea doar o primă de scriere, fără citiri - mărind costul. Au scos semnul. Lecție: cache-ul plătește numai dacă există un prefix mare și constant care este reutilizat.

Greșeli comune

• Amestecare constantă și variabilă: când conținutul variabil este în prefix, hit-ul este resetat.
• Încorporarea datei/ID-ului în promptul de sistem: Cel mai comun perturbator silențios.
• Nu se măsoară hit-ul: dacă cache_read_input_tokens nu este bifat, risipa nu va fi observată.
• Adăugarea cache-ului atunci când nu există prefix public: plătiți doar prima de scriere, costul crește.
• Modificarea listei de vehicule sau a modelului: prefixul este rupt de la început; totul este rescris.
• Uitând dimensiunea minimă a memoriei cache: cache-urile foarte scurte (sub ~1–4k tokens, în funcție de model) nu vor intra în cache în tăcere.

Mai profund: proiectarea memoriei cache în funcție de tipul de sarcină de lucru

Beneficiul real al stocării în cache variază în funcție de natura încărcăturii dvs. de lucru; deci cunoaște-ți mai întâi traficul. Trei modele tipice și instalare corectă:

Prompt comun de sistem, întrebări diferite. Cel mai comun model de întreprindere: un prompt de sistem mare (rol, reguli, poate document de referință) cu sute de întrebări diferite ale utilizatorului. Aici partea fixă ​​(sistemul) este stocată inițial în cache; fiecare întrebare nouă plătește prețul întreg doar pentru propria sa mică parte. Câștigul este foarte mare deoarece porția mare este recitată în mod repetat la o zecime din preț.

Monolog cu mai multe runde. Pe măsură ce o conversație se prelungește, fiecare nouă rundă se bazează pe toată istoria anterioară. Dacă puneți indicatorul cache la sfârșitul ultimei runde, fiecare cerere reutiliza prefixul conversației precedente; hit-urile se acumulează pe măsură ce conversația crește. Acest lucru reduce în mod dramatic costul sesiunilor lungi de asistenți.

Prefixul partajat este ultimul bit care trebuie schimbat. Solicitările multiple au în comun un set mare de priorități fixe (set de mostre, instrucțiuni), dar sunt separate printr-o singură întrebare la sfârșit. Puneți indicatorul de cache la sfârșitul părții partajate; În caz contrar, fiecare solicitare ar scrie propriul cache separat și nu ar fi citit nimic.

Un avertisment: memoria cache depinde de model și de o anumită dimensiune minimă. Prefixele foarte mici (sub câteva mii de jetoane, în funcție de model) nu vor intra în tăcere în cache, chiar dacă le semnalați — cache_creation_input_tokens rămâne zero. De asemenea, schimbarea modelului la mijlocul conversației invalidează întregul cache; Dacă o altă sarcină necesită un model ieftin, păstrați fluxul principal într-un singur model și puneți jobul secundar într-un apel separat.

Pe scurt

Memorarea promptă în cache este o potrivire a prefixului: conținutul fix ar trebui să fie la început, conținutul variabil ar trebui să fie la sfârșit. Pentru un context mare, reutilizat, costul de citire este o zecime din prețul integral, practic egal cu două cereri. Cea mai frecventă greșeală este de a corupe prefixul prin încorporarea datelor variabile în promptul de sistem; Verificați hit-ul măsurându-l în câmpul de utilizare.

Sarcina de aplicare

Alegeți un volum de muncă. (1) Împărțiți conținutul în două coloane: „nu se modifică niciodată” și „se modifică la fiecare solicitare”. (2) Redesenați structura promptă, punând partea constantă la început și partea variabilă la sfârșit. (3) Estimați dimensiunea simbolului părții fixe și comparați costul lunar cu/fără cache. (4) Rețineți din ce câmp (cache_read_input_tokens) veți verifica accesul.

lista de verificare

• [ ] Pot să explic că memoria cache este potrivirea prefixelor și singura regulă imuabilă.
• [ ] Pot crește acuratețea punând conținutul fix la început și variabila la sfârșit.
• [ ] Știu scrierea/citirea economiei și pragul de rentabilitate pentru două cereri.
• [ ] Pot recunoaște disruptoarele silențioase (data, JSON neordonat, schimbarea listei de vehicule).
• [ ] Pot verifica hit-ul cu usage.cache_read_input_tokens.