Nyereség:
- Magyarázza el a gyorsítótárazás előtagillesztési logikáját
- Növeli a gyorsítótárban elért találatokat azáltal, hogy a rögzített kontextust előtérbe helyezi, majd a változó környezetet
- Ki tudja számítani a gyorsítótár írási/olvasási gazdaságosságát és a fedezeti pontot
Egy LLM termék olcsónak tűnik prototípusban; Amikor fellép a mérlegre, a számla meglepő. A legtöbb munkaterhelésben a számlák nagy része ugyanabból a rögzített kontextusból származik, amelyet minden kéréssel újra és újra elküldenek: hosszú rendszerprompt, szabálykönyv, referenciadokumentáció. Az azonnali gyorsítótárazás pontosan ezt a veszteséget szünteti meg. Ebben az egységben megtudhatja, hogyan működik a gyorsítótár, hogyan rendezheti el a promptot, és hogyan számíthatja ki a gyorsítótár-gazdaságosság fedezeti pontját. Ha helyesen telepíti, önmagában a felére vagy még alacsonyabbra csökkentheti a számlát.
Hogyan működik a gyorsítótár? Az egyetlen megváltoztathatatlan szabály
Az azonnali gyorsítótárazás egy előtagegyezés. A szolgáltató ideiglenesen tárolja az általa a prompt kezdete óta feldolgozott tokeneket. Ha a prompt ugyanazzal az előtaggal kezdődik a következő kérésnél, akkor ez a közös rész nem kerül újraszámításra; Sokkal olcsóbb az olvasása, mint a gyorsítótár.
Ebből egy megváltoztathatatlan szabály következik: Ha egyetlen bájt az előtagban bárhol megváltozik, attól kezdve a teljes gyorsítótár érvénytelenné válik. Vagyis a rögzített tartalom legyen az elején, és a változó tartalom legyen a végén. Ha a rendszerprompt elejére tesz egy sort, amely minden kéréssel változik, például „Mai dátum: 2026.07.18.”, akkor minden mögötte lévő dolog nem tud belépni a gyorsítótárba.
A feldolgozási sorrend általában a következő: eszközök → rendszerprompt → üzenetek. A gyorsítótár-pontot (töréspontot) a rögzített szakasz végére helyezi.
Gyorsítótár gazdaságosság
A gyorsítótár három árszinttel rendelkezik:
- Gyorsítótár írása: Tárolás először. ~1,25x normál bemeneti ár (5 perces tárolásra).
- Gyorsítótár olvasása: A későbbi kérések olvasása. A normál bemeneti ár ~0,1-szerese – azaz egytizede.
- Normál bemenet: Az a rész, amely nem lép be a gyorsítótárba, és minden alkalommal teljes költséggel kerül feldolgozásra.
Megtérülési pont: Az első kérésre írási díj fizetendő (1,25×). A második kéréstől kezdve a leolvasás (0,1×) lép működésbe. Körülbelül két kérésre leszel nyakon. Ezt követően nettó megtakarításról van szó. Minél nagyobb a rögzített kontextus, és minél több kérést használnak fel újra, annál nagyobb lesz a nyereség.
Forgatókönyv
A gyorsítótár működik?
Nagy fix rendszerprompt, több ezer kérés
Igen – a legmagasabb kereset
Sok kérdés ugyanazon a referenciadokumentumban
Igen
Teljesen más rövid szöveg minden kéréshez
Nem – az írási bónusz kárba veszett
Egyszeri kérés
Nem – egyáltalán nem olvasni
A dátum/azonosító minden kéréssel módosul a rendszerpromptnál
Nem – az előtag törött, a találat nulla
Lépésről lépésre: Hogyan állítsunk be egy találati parancsot?
- Külön állandó és változó. Milyen tartalom nem változik soha (rendszerprompt, szabálykönyv, dokumentáció)? Mi változik minden kéréssel (felhasználói kérdés, dátum, azonosító)?
- Tedd az állandót az elejére. A feldolgozás során az előbbi alkatrésznek (szerszámok, rendszer) stabilnak kell lennie.
- Tedd a változó végére. Felhasználó aktuális kérdése, utolsó.
- Helyezze a táblát a határ végére. Helyezze a gyorsítótár pontot a rögzített rész utolsó blokkjába.
- Találat ellenőrzése. Ellenőrizze, hogy a cache_read_input_tokens értéke nagyobb-e nullánál a válasz használati mezőjében. Ha nulla, akkor az előtagban rejtett zavaró elem található.
{ "rendszer": [ { "type": "text", "text": "{{large_constant_system_promptu_and_rules}}", "cache_control": { "type": "efemerális" } } ], "üzenetek": [ { "role": "user", "content": "{{felhasználói_jelenlegi_kérdés}}"_
Tipp: Ne találgassa ki a gyorsítótár találatait, hanem mérje meg őket. Ha a usage.cache_read_input_tokens továbbra is nulla az egymást követő kéréseknél, akkor egy csendes megszakító (datetime.now() rendszerpromptnál, rendezetlen JSON, minden kéréssel változó eszközlista) fut. Hasonlítsa össze a két kérés nyers promptját bájtonként, és keresse meg a különbséget.
Csendes zavarók
Tipikus minták, amelyek tudtukon kívül megsértik a gyorsítótárat:
# BREAKER: információk beágyazása a rendszerpromptba, amely minden kéréssel változik "A mai dátum: {{most}}. Ön asszisztens..." ← Az előtag minden kéréssel változik, a találat nulla# IGAZ: mozgassa a változót az üzenetrendszerbe: "Ön asszisztens..." ← A konstans belép a gyorsítótárba: {{rolen:} user is, {{rolen:}. ..."}] ← változó a végén
Egyéb megszakítók: a JSON minden kérésnél eltérően rendeződik (a kulcsok rögzített sorrendben tartása), az eszközök listája felhasználónként változó (az eszközök feldolgozása először történik meg; semmi sem kerül a gyorsítótárba, ha megváltoznak), a modell módosítása beszélgetés közben (a gyorsítótárak modellspecifikusak).
Gyenge prompt / Erős prompt (gyorsítótárbarát szerkezet)
# WEAK (cache busting build)system: "Dátum: 2026.07.18. 14:32. Felhasználó: Ahmet (id 8842). Ön egy támogató bot. Szabályok: ...(2000 tokenek)..."
# ERŐS (gyorsítótár-barát szerkezet)rendszer: "Ön egy támogató bot. Szabályok: ...(2000 token, soha nem változik)..." [gyorsítótár jel]üzenetek: [ { szerep: felhasználó, tartalom: "Dátum: 2026.07.18. 14:32. Felhasználói azonosító: 8842. Kérdés: hogyan kezdeményezhetem a visszatérítést?" }]
A gyengébb verzióban a 2000 tokenből álló szabályblokk feldolgozása minden kérésnél teljes költséggel történik. Az erős változatban ugyanazt a blokkot egyszer írják le, és az összes további kérésnél az ár tizedéért olvassák el.
Három mini tok
1. eset – A szabálykönyv gyorsítótárazása. Egy könyvelési automatizálás minden számlához hozzáadta a 12 000 token szabálykönyvet; 5000 kérés naponta. A gyorsítótár nélküli bevitel napi 180 dollárba kerül. Állandóan tartották a szabálykönyvet és gyorsítótárazták: az első kérések írási prémiumot fizettek, a későbbi olvasások 0,1×-et. A beviteli költség ~90%-kal csökkent napi 18 dollárra.
2. eset – Rejtett dátumsor költsége. Az egyik csapat gyorsítótárat állított fel, de nem kapott találatot; cache_read_input_tokens mindig nulla volt. Ok: A rendszerprompt első sorában a datetime.now() szerepel, az előtag minden kéréssel változott. Amikor áthelyeztük a dátumot a felhasználói üzenetbe, a találati arány hirtelen 0%-ról 94%-ra nőtt.
3. eset – Rosszul elhelyezett gyorsítótár. Egy keresőalkalmazás teljesen különböző rövid lekérdezéseket küldött minden kéréssel; Mohón hozzáadtak egy gyorsítótár jelet. Közös előtag hiányában minden kérés csak írási prémiumot fizetett, olvasás nélkül – ez növelte a költségeket. Eltüntették a táblát. Tanulság: a gyorsítótár csak akkor fizet, ha van egy nagy és állandó előtag, amelyet újra felhasználnak.
Gyakori hibák
- Állandó és változó keverése: Ha a változó tartalma az előtagban van, a találat visszaáll.
- Dátum/azonosító beágyazása a rendszerpromptba: A leggyakoribb csendes zavaró.
- Nem méri a találatot: Ha a cache_read_input_tokens nincs bejelölve, a pazarlás nem észlelhető.
- Gyorsítótár hozzáadása nyilvános előtag hiányában: Csak az írási prémiumot fizeti, a költség nő.
- Járműlista vagy modell módosítása: Az előtag az elejétől törött; minden át van írva.
- A minimális gyorsítótár méret elfelejtése: A nagyon rövid gyorsítótárak (modelltől függően ~1–4 ezer token alatt) nem lépnek be csendben a gyorsítótárba.
Mélyebb: Gyorsítótár tervezése munkaterhelés típusa szerint
A gyorsítótárazás tényleges megtérülése a munkaterhelés jellegétől függően változik; ezért először ismerje meg a forgalmát. Három tipikus minta és helyes telepítés:
Közös rendszerkérdés, különböző kérdések. A leggyakoribb vállalati minta: egy nagy rendszerprompt (szerep, szabályok, esetleg referenciadokumentum) több száz különböző felhasználói kérdéssel. Itt a rögzített rész (rendszer) kezdetben gyorsítótárazásra kerül; minden új kérdés csak a saját kis részéért fizet teljes árat. A nyereség nagyon magas, mert a nagy részt ismételten az ár tizedéért mondják el.
Többfordulós monológ. Ahogy a beszélgetés elhúzódik, minden új forduló az összes korábbi történelemre épül. Ha a gyorsítótár jelzőt az utolsó kör végén helyezi el, minden kérés újra felhasználja az előző beszélgetési előtagot; a találatok gyűlnek a beszélgetés növekedésével. Ez drámai módon visszafogja a hosszú asszisztensi ülések költségeit.
A megosztott előtag az utolsó módosítandó bit. A több kérés egy nagy számú rögzített prioritáson osztozik (mintakészlet, utasítások), de a végén egyetlen kérdés választja el őket. A gyorsítótár mutatóját a megosztott rész végére helyezi; Ellenkező esetben minden kérés külön gyorsítótárat írna, és egyiket sem olvasná be.
Egy figyelmeztetés: a gyorsítótár a modelltől és egy bizonyos minimális mérettől függ. A nagyon kicsi előtagok (modelltől függően néhány ezer token alatt) nem lépnek be csendben a gyorsítótárba, még akkor sem, ha megjelöli őket – a cache_creation_input_tokens nulla marad. Ezenkívül a modell beszélgetés közbeni megváltoztatása érvényteleníti a teljes gyorsítótárat; Ha egy másik feladat olcsó modellt igényel, tartsa a fő áramlást egy modellben, és tegye a mellékmunkát egy külön felhívásba.
Összefoglalva
A gyorsítótárazás egy előtagegyezés: a rögzített tartalom az elején, a változó tartalom a végén legyen. Nagyméretű, újrafelhasznált kontextus esetén az olvasási költség a teljes ár tizede, ami nagyjából két kérés esetén is meghalad. A leggyakoribb hiba az előtag megsértése azáltal, hogy változó adatokat ágyaz be a rendszerpromptba; A találatot a használati mezőben történő méréssel ellenőrizheti.
Pályázati feladat
Válasszon munkaterhelést. (1) Ossza fel a tartalmat két oszlopra: „soha nem változik” és „minden kéréssel változik”. (2) Rajzolja át a prompt szerkezetet úgy, hogy a konstans részt az elejére, a változó részt pedig a végére téve! (3) Becsülje meg a rögzített rész token méretét, és hasonlítsa össze a havi költséget gyorsítótárral vagy anélkül. (4) Jegyezze fel, hogy melyik mezőből (cache_read_input_tokens) fogja ellenőrizni a találatot.
ellenőrző lista
- [ ] Meg tudom magyarázni, hogy a gyorsítótár az előtagegyeztetés, és az egyetlen megváltoztathatatlan szabály.
- [ ] A pontosságot úgy tudom növelni, hogy a fix tartalmat az elejére, a változót a végére teszem.
- [ ] Ismerem az írás/olvasás közgazdaságtant és a kétkéréses fedezeti pontot.
- [ ] Felismerem a csendes zavarókat (dátum, rendezetlen JSON, változó járműlista).
- [ ] A találatot a usage.cache_read_input_tokens segítségével tudom ellenőrizni.