Ieguvumi:
- Izskaidrojiet tūlītējas kešatmiņas prefiksu atbilstības loģiku
- Palielina kešatmiņas trāpījumu, vispirms liekot fiksēto kontekstu un pēc tam mainīgo kontekstu
- Var aprēķināt kešatmiņas rakstīšanas/lasīšanas ekonomiku un līdzsvara punktu
LLM produkts prototipā izskatās lēts; Pakāpjoties uz skalu, rēķins pārsteidz. Lielākajā daļā darba slodžu lielākā daļa rēķinu nāk no tā paša fiksētā konteksta, kas tiek nosūtīts atkal un atkal ar katru pieprasījumu: gara sistēmas uzvedne, noteikumu grāmata, atsauces dokumentācija. Ātra kešatmiņa novērš tieši šos atkritumus. Šajā nodaļā jūs uzzināsit, kā darbojas kešatmiņa, kā sakārtot uzvedni, lai sasniegtu, un kā aprēķināt kešatmiņas ekonomikas līdzsvara punktu. Pareizi uzstādot, tas pats par sevi var samazināt jūsu rēķinu uz pusi vai pat samazināt.
Kā darbojas kešatmiņa? Viens nemainīgs noteikums
Prompt caching ir prefiksa atbilstība. Pakalpojumu sniedzējs īslaicīgi saglabā marķierus, ko tas ir apstrādājis kopš jūsu uzvednes sākuma. Ja uzvedne nākamajā pieprasījumā sākas ar to pašu prefiksu, šī kopējā daļa netiek pārrēķināta; Lasīt ir daudz lētāk nekā kešatmiņā.
No tā izriet viens nemainīgs noteikums: ja viens baits mainās jebkurā prefiksā, visa kešatmiņa kļūst nederīga no šī brīža. Tas ir, fiksētam saturam jābūt sākumā un mainīgam saturam jābūt beigās. Ja sistēmas uzvednes sākumā ievietosiet rindiņu, kas mainās ar katru pieprasījumu, piemēram, "Šodienas datums: 18.07.2026", viss, kas atrodas aiz tā, nevarēs iekļūt kešatmiņā.
Apstrādes secība parasti ir šāda: rīki → sistēmas uzvedne → ziņojumi. Jūs ievietojat kešatmiņas punktu (pārtraukuma punktu) fiksētās sadaļas beigās.
Kešatmiņas ekonomika
Kešatmiņai ir trīs cenu līmeņi:
- Rakstīt kešatmiņā: glabā pirmo reizi. ~1,25x parastā ievades cena (5 minūšu uzglabāšanai).
- Lasīšana kešatmiņā: turpmāko pieprasījumu lasīšana. ~0,1 reize pārsniedz parasto ievades cenu, tas ir, viena desmitā daļa.
- Parasta ievade: daļa, kas neietilpst kešatmiņā un katru reizi tiek apstrādāta par pilnu maksu.
Līdzsvara punkts: pirmais pieprasījums maksā rakstīšanas prēmiju (1,25 ×). No otrā pieprasījuma tiek aktivizēts rādījums (0,1 ×). Aptuveni, jums būs kakla un kakla pēc diviem pieprasījumiem; Pēc tam tie ir neto ietaupījumi. Jo lielāks ir fiksētais konteksts un jo vairāk pieprasījumu tas tiek atkārtoti izmantots, jo lielāks kļūst ieguvums.
Scenārijs
Vai kešatmiņa darbojas?
Liela fiksētas sistēmas uzvedne, tūkstošiem pieprasījumu
Jā - lielākā peļņa
Daudzi jautājumi par tiem pašiem atsauces dokumentiem
Jā
Pilnīgi atšķirīgs īss teksts katram pieprasījumam
Nē — rakstīšanas bonuss ir izšķiests
Vienreizējs pieprasījums
Nē — nelasot vispār
Datums/ID mainās ar katru pieprasījumu pēc sistēmas uzvednes
Nē — prefikss ir bojāts, trāpījums ir nulle
Soli pa solim: kā iestatīt trāpījuma uzvedni?
- Atsevišķi konstante un mainīgie. Kāds saturs nekad nemainās (sistēmas uzvedne, noteikumu grāmata, dokumentācija)? Kas mainās ar katru pieprasījumu (lietotāja jautājums, datums, ID)?
- Ievietojiet konstanti sākumā. Apstrādes laikā pirmajai daļai (rīkiem, sistēmai) jābūt stabilai.
- Novietojiet mainīgo beigās. Lietotāja aktuālais jautājums, pēdējais.
- Novietojiet zīmi robežas galā. Ievietojiet kešatmiņas punktu fiksētās daļas pēdējā blokā.
- Apstipriniet trāpījumu. Pārbaudiet, vai atbildes lietojuma laukā cache_read_input_tokens ir lielāks par nulli. Ja nulle, prefiksā ir slēpts traucētājs.
{ "sistēma": [ { "tips": "teksts", "teksts": "{{large_constant_system_promptu_and_rules}}", "cache_control": { "type": "efemerāls" } } ], "ziņojumi": [ { "role": "user", "content": "{{user_curles]}}"_
Padoms. Neuzminējiet kešatmiņas trāpījumus, bet mēriet tos. Ja usage.cache_read_input_tokens joprojām ir nulle pēc secīgiem pieprasījumiem, darbojas klusais pārtraucējs (datetime.now() sistēmas uzvednē, nesakārtots JSON, rīku saraksts, kas mainās ar katru pieprasījumu). Salīdziniet abu pieprasījumu neapstrādāto uzvedni pa baitam un atrodiet atšķirību.
Klusie traucētāji
Tipiski modeļi, kas neapzināti sabojā kešatmiņu:
# BREAKER: informācijas iegulšana sistēmas uzvednē, kas mainās ar katru pieprasījumu "Šodienas datums: {{tagad}}. Jūs esat asistents..." ← prefikss mainās ar katru pieprasījumu, trāpījums ir nulle# TRUE: pārvietojiet mainīgo uz ziņojumu sistēmu: "Jūs esat palīgs..." ← konstante ievada kešatmiņas ziņojumus: {{role "day:} user: {{role:}}. ..."}] ← mainīgais beigās
Citi pārtraucēji: JSON tiek kārtots atšķirīgi pēc katra pieprasījuma (saglabājiet atslēgas fiksētā secībā), rīku saraksts atšķiras atkarībā no lietotāja (rīki tiek apstrādāti vispirms; nekas nenonāk kešatmiņā, ja tie mainās), modeļa maiņa sarunas laikā (kešatmiņas ir atkarīgas no modeļa).
Vāja uzvedne / spēcīga uzvedne (kešatmiņai draudzīga struktūra)
# WEAK (cache busting build)system: "Datums: 18.07.2026 14:32. Lietotājs: Ahmet (id 8842). Jūs esat atbalsta robots. Noteikumi: ...(2000 marķieri)..."
# STRONG (kešatmiņai draudzīga struktūra)sistēma: "Jūs esat atbalsta robots. Noteikumi: ...(2000 marķieri, nekad nemainās)..." [kešatmiņas zīme]ziņojumi: [ { loma: lietotājs, saturs: "Datums: 18.07.2026 14:32. Lietotāja ID: 8842. Jautājums: kā es varu sākt savu naudas atmaksu?" }]
Vājākajā versijā 2000 marķieru kārtulu bloks tiek apstrādāts par pilnu maksu par katru pieprasījumu. Spēcīgajā versijā tas pats bloks tiek uzrakstīts vienu reizi un tiek lasīts visos turpmākajos pieprasījumos par desmito daļu no cenas.
Trīs mini futrāļi
1. gadījums — noteikumu grāmatas saglabāšana kešatmiņā. Grāmatvedības automatizācija katram rēķinam pievienoja 12 000 marķieru noteikumu grāmatu; 5000 pieprasījumu dienā. Bezkešatmiņas ievade maksā ~180 $ dienā. Viņi saglabāja kārtulu grāmatu nemainīgu un saglabāja to kešatmiņā: par pirmajiem pieprasījumiem tika maksāta rakstīšanas piemaksa, pēc tam par lasīšanu 0,1 ×. Ievades izmaksas samazinājās par ~ 90% līdz ~ 18 USD dienā.
2. gadījums — slēptās datuma rindas izmaksas. Viena komanda izveidoja kešatmiņu, bet nesaņēma nevienu trāpījumu; cache_read_input_tokens vienmēr bija nulle. Iemesls: Sistēmas uzvednes pirmajā rindā bija datetime.now(), prefikss mainījās ar katru pieprasījumu. Kad mēs pārvietojām datumu uz lietotāja ziņojumu, trāpījumu līmenis pēkšņi palielinājās no 0% līdz 94%.
3. gadījums — nepareizi novietota kešatmiņa. Meklēšanas lietojumprogramma ar katru pieprasījumu sūtīja pilnīgi dažādus īsus vaicājumus; Viņi nepacietīgi pievienoja kešatmiņas zīmi. Bez kopīga prefiksa katrs pieprasījums maksāja tikai rakstīšanas piemaksu, bez lasīšanas — palielinot izmaksas. Viņi noņēma zīmi. Nodarbība: kešatmiņa maksā tikai tad, ja ir liels un nemainīgs prefikss, kas tiek izmantots atkārtoti.
Biežas kļūdas
- Konstantes un mainīgā sajaukšana: ja mainīgā saturs ir prefiksā, trāpījums tiek atiestatīts.
- Datuma/ID iegulšana sistēmas uzvednē: visizplatītākais klusais traucētājs.
- Netiek mērīts trāpījums: ja nav atzīmēta cache_read_input_tokens, atkritumi netiks pamanīti.
- Kešatmiņas pievienošana, ja nav publiska prefiksa: jūs maksājat tikai rakstīšanas prēmiju, izmaksas palielinās.
- Transportlīdzekļa saraksta vai modeļa maiņa: prefikss ir bojāts no sākuma; viss ir pārrakstīts.
- Aizmirstot par minimālo kešatmiņas lielumu: ļoti īsas kešatmiņas (mazāk nekā 1–4 000 marķieri atkarībā no modeļa) kešatmiņā neienāks klusi.
Deeper: Cache projektēšana pēc darba slodzes veida
Faktiskā kešatmiņas atdeve atšķiras atkarībā no jūsu darba slodzes veida; tāpēc vispirms uzziniet savu satiksmi. Trīs tipiski modeļi un pareiza uzstādīšana:
Kopīga sistēmas uzvedne, dažādi jautājumi. Visizplatītākais uzņēmuma modelis: liela sistēmas uzvedne (lomas, noteikumi, varbūt atsauces dokuments) ar simtiem dažādu lietotāju jautājumu. Šeit fiksētā daļa (sistēma) sākotnēji tiek saglabāta kešatmiņā; katrs jauns jautājums maksā pilnu cenu tikai par savu mazo porciju. Ieguvums ir ļoti liels, jo lielā daļa tiek atkārtoti deklamēta par desmito daļu no cenas.
Daudzkārtu monologs. Sarunai ieilgstot, katra jauna kārta tiek papildināta ar visu iepriekšējo vēsturi. Ja pēdējās kārtas beigās ievietojat kešatmiņas karogu, katrs pieprasījums atkārtoti izmanto iepriekšējās sarunas prefiksu; trāpījumi uzkrājas, sarunai augot. Tas ievērojami ierobežo ilgo asistenta sesiju izmaksas.
Koplietotais prefikss ir pēdējais bits, kas jāmaina. Vairākiem pieprasījumiem ir liels fiksēto prioritāšu kopums (paraugkopa, norādījumi), bet beigās tos atdala viens jautājums. Jūs ievietojat kešatmiņas rādītāju koplietotās daļas beigās; Pretējā gadījumā katrs pieprasījums ierakstītu savu atsevišķu kešatmiņu un neviens no tiem netiktu nolasīts.
Viens brīdinājums: kešatmiņa ir atkarīga no modeļa un noteikta minimālā izmēra. Ļoti mazi prefiksi (mazāk nekā daži tūkstoši marķieru, atkarībā no modeļa) klusi neiekļūs kešatmiņā pat tad, ja tos atzīmēsit — cache_creation_input_tokens paliek nulle. Arī modeļa maiņa sarunas laikā padara nederīgu visu kešatmiņu; Ja citam uzdevumam ir nepieciešams lēts modelis, saglabājiet galveno plūsmu vienā modelī un ievietojiet blakus darbu atsevišķā izsaukumā.
Rezumējot
Uzvednes kešatmiņa ir prefiksa atbilstība: fiksētajam saturam jābūt sākumā, mainīgam saturam jābūt beigās. Lielam, atkārtoti izmantotam kontekstam lasīšanas maksa ir desmitā daļa no pilnas cenas, kas ir aptuveni pat divos pieprasījumos. Visbiežāk sastopamā kļūda ir prefiksa sabojāšana, sistēmas uzvednē iegulstot mainīgos datus; Jūs pārbaudāt trāpījumu, mērot to lietojuma laukā.
Lietojumprogrammas uzdevums
Izvēlieties darba slodzi. (1) Sadaliet saturu divās kolonnās: "nekad nemainās" un "izmaiņas ar katru pieprasījumu". (2) Pārzīmējiet uzvednes struktūru, ieliekot konstanto daļu sākumā un mainīgo daļu beigās. (3) Novērtējiet fiksētās daļas marķiera lielumu un salīdziniet ikmēneša izmaksas ar kešatmiņu vai bez tās. (4) Ņemiet vērā, no kura lauka (cache_read_input_tokens) verificēsit trāpījumu.
kontrolsaraksts
- [ ] Es varu paskaidrot, ka kešatmiņa ir prefiksu atbilstība un vienīgais nemainīgais noteikums.
- [ ] Precizitāti varu palielināt, sākumā liekot fiksēto saturu un beigās mainīgo.
- [ ] Es zinu rakstīšanas/lasīšanas ekonomiku un divu pieprasījumu rentabilitātes punktu.
- [ ] Es varu atpazīt klusos traucētājus (datums, nesakārtots JSON, mainās transportlīdzekļu saraksts).
- [ ] Es varu pārbaudīt trāpījumu ar usage.cache_read_input_tokens.