Voitot:
- Selitä välimuistin etuliitesovituslogiikka
- Lisää välimuistin osumia asettamalla kiinteä konteksti ensin ja muuttuva konteksti sen jälkeen
- Osaa laskea välimuistin kirjoitus/lukutalouden ja kannattavuusrajan
LLM-tuote näyttää edulliselta prototyypiltään; Kun astut vaa'alle, lasku yllättää. Useimmissa työkuormissa suurin osa laskusta tulee samasta kiinteästä kontekstista, joka lähetetään yhä uudelleen jokaisen pyynnön yhteydessä: pitkä järjestelmäkehote, sääntökirja, viitedokumentaatio. Nopea välimuisti eliminoi juuri tämän tuhlauksen. Tässä osiossa opit kuinka välimuisti toimii, kuinka kehote järjestetään osumaan ja miten välimuistitalouden kannattavuuspiste lasketaan. Oikein asennettuna se voi yksin leikata laskusi puoleen tai jopa pienempään.
Kuinka välimuisti toimii? Yksi muuttumaton sääntö
Pikavälimuisti on etuliiteosuma. Palveluntarjoaja tallentaa tilapäisesti tunnukset, jotka se on käsitellyt kehotteen alusta lähtien. Jos kehote alkaa samalla etuliitteellä seuraavassa pyynnössä, tätä yhteistä osaa ei lasketa uudelleen; Se on paljon halvempaa lukea kuin välimuisti.
Tästä seuraa yksi muuttumaton sääntö: Jos yksi tavu muuttuu missä tahansa etuliitteessä, koko välimuisti ei kelpaa tästä kohdasta eteenpäin. Toisin sanoen kiinteän sisällön tulee olla alussa ja muuttuvan sisällön lopussa. Jos laitat järjestelmäkehotteen alkuun rivin, joka muuttuu jokaisen pyynnön yhteydessä, kuten "Tänään päivämäärä: 18.07.2026", kaikki sen takana oleva ei pääse välimuistiin.
Käsittelyjärjestys on yleensä: työkalut → järjestelmäkehote → viestit. Asetat välimuistipisteen (katkoskohdan) kiinteän osan loppuun.
Välimuistitalous
Välimuistissa on kolme hintatasoa:
- Välimuistikirjoitus: Tallennetaan ensimmäistä kertaa. ~1,25x normaali syöttöhinta (5 minuutin säilytys).
- Välimuistin luku: Lukee myöhempiä pyyntöjä. ~0,1 kertaa normaali syöttöhinta eli yksi kymmenesosa.
- Normaali syöttö: Osa, joka ei pääse välimuistiin ja joka käsitellään täydellä hinnalla joka kerta.
Kannattavuuspiste: Ensimmäisestä pyynnöstä maksetaan kirjauspalkkio (1,25×). Toisesta pyynnöstä lukema (0,1×) tulee käyttöön. Karkeasti ottaen olet kaulassa kahdessa pyynnössä; Sen jälkeen se on nettosäästöä. Mitä suurempi kiinteä konteksti ja mitä enemmän pyyntöjä sitä käytetään, sitä suurempi vahvistus tulee.
Skenaario
Toimiiko välimuisti?
Suuri kiinteä järjestelmäkehote, tuhansia pyyntöjä
Kyllä – korkeimmat tulot
Useita kysymyksiä samoista viiteasiakirjoista
Kyllä
Täysin erilainen lyhyt teksti jokaiselle pyynnölle
Ei – kirjoitusbonus menee hukkaan
Kerran pyyntö
Ei - ei lukemista ollenkaan
Päivämäärä/tunnus muuttuu jokaisen pyynnön yhteydessä järjestelmäkehotteessa
Ei – etuliite on rikki, osuma on nolla
Vaihe vaiheelta: Kuinka määrittää osumakehote?
- Erottele vakio ja muuttuja. Mikä sisältö ei muutu (järjestelmän kehote, sääntökirja, dokumentaatio)? Mikä muuttuu jokaisen pyynnön yhteydessä (käyttäjän kysymys, päivämäärä, tunnus)?
- Laita vakio alkuun. Käsittelyn aikana ensin tulevan osan (työkalut, järjestelmä) on oltava vakaa.
- Laita muuttuja loppuun. Käyttäjän nykyinen kysymys, viimeinen.
- Aseta kyltti rajan päähän. Aseta välimuistipiste kiinteän osan viimeiseen lohkoon.
- Vahvista osuma. Tarkista, onko cache_read_input_tokens suurempi kuin nolla vastauksen käyttökentässä. Jos nolla, etuliitteessä on piilotettu häiriötekijä.
{ "järjestelmä": [ { "type": "text", "text": "{{large_constant_system_promptu_and_rules}}", "cache_control": { "type": "ephemeral" } } ], "messages": [ { "role": "user", "content": "{{user_curles]}}"_quest
Vinkki: Älä arvaa välimuistin osumia, vaan mittaa ne. Jos usage.cache_read_input_tokens on edelleen nolla peräkkäisissä pyynnöissä, hiljainen katkaisija (datetime.now() järjestelmäkehotteessa, järjestämätön JSON, luettelo työkaluista, jotka muuttuvat jokaisen pyynnön yhteydessä). Vertaa kahden pyynnön raakakehotetta tavulta ja löydä ero.
Hiljaiset häiriötekijät
Tyypillisiä malleja, jotka tietämättään turmelevat välimuistin:
# BREAKER: tietojen upottaminen järjestelmäkehotteeseen, joka muuttuu jokaisen pyynnön yhteydessä "Tämänpäiväinen päivämäärä: {{nyt}}. Olet avustaja..." ← etuliite muuttuu jokaisen pyynnön yhteydessä, osuma on nolla# TOSI: siirrä muuttuja viestijärjestelmään: "Olet avustaja..." ← vakio tulee välimuistiin: {{role ":}day: {{role":}. ..."}] ← muuttuja lopussa
Muut katkaisijat: JSON lajiteltu eri tavalla jokaisessa pyynnössä (pidä avaimet kiinteässä järjestyksessä), luettelo työkaluista vaihtelee käyttäjien mukaan (työkalut käsitellään ensin; mitään ei mene välimuistiin, jos ne muuttuvat), mallin muuttaminen kesken keskustelun (välimuistit ovat mallikohtaisia).
Heikko kehote / Vahva kehote (välimuistiystävällinen rakenne)
# WEAK (cache busting build) -järjestelmä: "Päivämäärä: 18.07.2026 14:32. Käyttäjä: Ahmet (id 8842). Olet tukibotti. Säännöt: ...(2000 tokens)..."
# VAHVA (välimuistiystävällinen rakenne)järjestelmä: "Olet tukibotti. Säännöt: ...(2000 tokenia, ei koskaan muutu)..." [välimuistimerkki]viestit: [ { rooli: käyttäjä, sisältö: "Päivämäärä: 18.07.2026 14:32. Käyttäjätunnus: 8842. Kysymys: miten aloitan palautukseni?" }]
Heikossa versiossa 2000 tunnuksen sääntölohko käsitellään täydellä hinnalla jokaisella pyynnöstä. Vahvassa versiossa sama lohko kirjoitetaan kerran ja luetaan kaikissa myöhemmissä pyynnöissä kymmenesosalla hinnasta.
Kolme minikoteloa
Tapaus 1 – Sääntökirjan tallentaminen välimuistiin. Kirjanpitoautomaatio lisäsi 12 000 tokenin sääntökirjan jokaiseen laskuun; 5000 pyyntöä päivässä. Välimuistiton syöttö maksaa ~ 180 dollaria päivässä. He pitivät sääntökirjan vakiona ja tallensivat sen välimuistiin: ensimmäisistä pyynnöistä maksettiin kirjoituspalkkio, myöhemmistä lukemista 0,1×. Panoskustannukset laskivat ~90 % ~18 dollariin päivässä.
Tapaus 2 — Piilotetun päivämäärärivin hinta. Yksi joukkue perusti kätkön, mutta ei saanut osumia; cache_read_input_tokens oli aina nolla. Syy: Järjestelmäkehotteen ensimmäisellä rivillä oli datetime.now(), etuliite vaihtui jokaisen pyynnön yhteydessä. Kun siirsimme päivämäärän käyttäjäviestiin, osumaprosentti nousi yhtäkkiä 0 %:sta 94 %:iin.
Tapaus 3 – Väärin sijoitettu välimuisti. Hakusovellus lähetti täysin erilaisia lyhyitä kyselyitä jokaisen pyynnön yhteydessä; He lisäsivät innokkaasti kätkömerkin. Ilman yhteistä etuliitettä jokainen pyyntö maksoi vain kirjoituspalkkion, ei lukuja - lisäsi kustannuksia. He poistivat merkin. Oppitunti: välimuisti maksaa vain, jos siinä on suuri ja jatkuva etuliite, jota käytetään uudelleen.
Yleisiä virheitä
- Vakion ja muuttujan sekoitus: Kun muuttujan sisältö on etuliitteessä, osuma nollataan.
- Päivämäärän/tunnuksen upottaminen järjestelmäkehotteeseen: Yleisin hiljainen häiriötekijä.
- Ei mittaa osumaa: Jos cache_read_input_tokens ei ole valittuna, hukkaa ei havaita.
- Välimuistin lisääminen, kun julkista etuliitettä ei ole: Maksat vain kirjoituspalkkion, kustannukset kasvavat.
- Ajoneuvoluettelon tai mallin muuttaminen: Etuliite katkeaa alusta alkaen; kaikki kirjoitetaan uudelleen.
- Vähimmäisvälimuistikoon unohtaminen: Hyvin lyhyet välimuistit (alle ~1–4k tokeneja mallista riippuen) eivät pääse välimuistiin äänettömästi.
Deeper: Välimuistin suunnittelu työkuormatyypin mukaan
Välimuistin todellinen hyöty vaihtelee työkuormasi luonteen mukaan; joten tutustu liikenteeseen ensin. Kolme tyypillistä mallia ja oikea asennus:
Yhteinen järjestelmäkehote, erilaisia kysymyksiä. Yleisin yritysmalli: suuri järjestelmäkehote (rooli, säännöt, ehkä viiteasiakirja), jossa on satoja erilaisia käyttäjäkysymyksiä. Tässä kiinteä osa (järjestelmä) tallennetaan aluksi välimuistiin; jokainen uusi kysymys maksaa täyden hinnan vain omasta pienestä osastaan. Hyöty on erittäin suuri, koska suuri osa lausutaan toistuvasti kymmenesosalla hinnasta.
Monikierros monologi. Keskustelun edetessä jokainen uusi kierros rakentuu kaiken aikaisemman historian päälle. Jos laitat välimuistilipun viimeisen kierroksen loppuun, jokainen pyyntö käyttää uudelleen edellisen keskustelun etuliitettä. osumia kertyy keskustelun kasvaessa. Tämä hillitsee dramaattisesti pitkien avustajaistuntojen kustannuksia.
Jaettu etuliite on viimeinen muutettava bitti. Useat pyynnöt jakavat suuren joukon kiinteitä prioreja (esimerkkijoukko, ohjeet), mutta ne erotetaan yhdellä kysymyksellä lopussa. Asetat välimuistiosoittimen jaetun osan loppuun; Muuten jokainen pyyntö kirjoittaisi oman erillisen välimuistinsa, eikä mitään niistä luettaisi.
Yksi varoitus: välimuisti riippuu mallista ja tietystä vähimmäiskoosta. Hyvin pienet etuliitteet (alle muutama tuhat merkkiä mallista riippuen) eivät pääse äänettömästi välimuistiin, vaikka merkitset ne - cache_creation_input_tokens pysyy nollana. Myös mallin muuttaminen kesken keskustelun mitätöi koko välimuistin; Jos eri tehtävä vaatii halvan mallin, pidä päävirta yhdessä mallissa ja laita sivutyö erilliseen kutsuun.
Yhteenvetona
Pikavälimuisti on etuliiteosuma: kiinteän sisällön tulee olla alussa, muuttuvan sisällön tulee olla lopussa. Suuressa, uudelleen käytetyssä kontekstissa lukuhinta on kymmenesosa täydestä hinnasta, karkeasti jopa kahdessa pyynnössä. Yleisin virhe on etuliitteen korruptoituminen upottamalla muuttujatietoja järjestelmäkehotteeseen. Vahvistat osuman mittaamalla sen käyttökentässä.
Sovellustehtävä
Valitse työmäärä. (1) Jaa sisältö kahteen sarakkeeseen: "ei koskaan muutu" ja "muuttuu jokaisen pyynnöstä". (2) Piirrä kehoterakenne uudelleen niin, että vakio-osa tulee alkuun ja muuttuva osa loppuun. (3) Arvioi kiinteän osan merkkikoko ja vertaa kuukausikustannuksia välimuistin kanssa/ilman sitä. (4) Huomaa, mistä kentästä (cache_read_input_tokens) vahvistat osuman.
tarkistuslista
- [ ] Voin selittää, että välimuisti on etuliitesovitus ja ainoa muuttumaton sääntö.
- [ ] Voin lisätä tarkkuutta laittamalla kiinteän sisällön alkuun ja muuttujan loppuun.
- [ ] Tiedän taloustieteen kirjoittamisen/lukemisen ja kahden pyynnön kannattavuusrajan.
- [ ] Tunnistan hiljaiset häiriötekijät (päivämäärä, järjestämätön JSON, vaihtuva ajoneuvoluettelo).
- [ ] Voin vahvistaa osuman käyttämällä usage.cache_read_input_tokens.