Kérdező gyorsítótár-vezérlés többmodell API-átjáróban: stabil előtagok, bérlői elkülönítés és gyorsítótár-leütés elemzés

Az azonnali gyorsítótárazás könnyen elpazarolható. Egy csapatnak lehet 40 000 tokenből álló rendszerpromptja, eszközsémája, házirendblokkja, lerakattérképe vagy ügynökmemóriája, amelynek újrafelhasználhatónak kell lennie, majd véletlenül időbélyeget, kérésazonosítót, felhasználónevet, lekérési kódrészletet vagy véletlenszerű eszközsorrendet helyez el a prompt tetejéhez. A szolgáltató más előtagot lát, a gyorsítótár hiányzik, a várakozási idő nő, és a számla zavarónak tűnik.

Egy szolgáltató alkalmazásában ezt az alkalmazássablonon belül javíthatja. A többmodelles átjáróban a probléma nagyobb: minden szolgáltató különböző gyorsítótár-vezérlőket, jogkivonat-küszöbértékeket, élettartam-beli viselkedést, használati mezőket és számlázási szemantikát tesz közzé. Az átjárónak hordozható vezérlősík mintára van szüksége a gyorsítótárat biztonságos promptok összeállításához, a gyorsítótár viselkedésének méréséhez, a bérlők elkülönítéséhez és a költségek hozzárendeléséhez.

Ez a cikk egy referenciaarchitektúrát ír le. Ez nem egy ügyfél esettanulmánya, és nem igényel benchmark eredményeket. Az alábbi tények a szolgáltató dokumentációjából és nyilvános kutatásokból származnak; a tervezési ajánlások átjáró szintű üzemeltetési útmutatók.

A hibamód: gyorsítótárat feltörő prompt összeállítás

A gyorsítótárazás általában jutalmazza az ismételt prompt előtagokat. A pontos mechanika szolgáltatónként eltérő, de a gyakorlati következtetés következetes: ha a prompt eleje megváltozik, az újrahasználatot szenved.

A gyakori gyorsítótár-megszakítók a következők:

• Kérésenkénti metaadatok felül: időbélyegek, nyomkövetési azonosítók, munkamenet-azonosítók, telepítési azonosítók vagy generált kéréscímkék.
• Felhasználóspecifikus adatok az előtagban: nevek, fiókattribútumok, engedélyek vagy privát beállítások, amelyek az újrafelhasználható házirend- vagy eszközblokkok elé kerülnek.
• Instabil eszközsorosítás: az eszközsémák nemdeterminisztikus sorrendben, változó szóközökkel vagy generált azonosítókkal.
• A kódrészletek lekérése túl korán: RAG-kontextus beszúrva a stabil rendszerutasítások vagy a megosztott tárolókontextus elé.
• Sablonok eltolódása: gyakran közzétett kis szövegmódosítások verziószámítás vagy gyorsítótár-diagnosztika nélkül.

Az átjáró nem képes varázslatosan gyorsítótárazhatóvá tenni az instabil előtagot, de kikényszerítheti az azonnali összeszerelési szerződést, és láthatóvá teheti a gyorsítótár hiányosságait.

Szolgáltatói tények a tervezéshez

A részletek azért fontosak, mert az átjárónak normalizálnia kell a viselkedését anélkül, hogy azt tenné, hogy a szolgáltatók azonosak lennének.

• OpenAI: Az OpenAI dokumentálta a gyorsítótárazást a leghosszabb, korábban kiszámított prompt előtaghoz. 1024 tokentől kezdődik, 128 tokennel növekszik, és felfedi a gyorsítótárazott tokenszámot a használati mezőkben. Az OpenAI azt is kijelenti, hogy a gyorsítótárak általában 5–10 perc inaktivitás után törlődnek, és mindig a gyorsítótár utolsó használatától számított egy órán belül törlődnek.
• Antropikus: Antropikus gyorsítótárazás kérhető a cache_control segítségével. Dokumentációja leírja a gyorsítótár-illesztést olyan prompt összetevőkön keresztül, mint az eszközök, a rendszertartalom és az üzenetek a gyorsítótár-vezérléssel jelölt blokkig. Az Anthropic egy efemer gyorsítótárat dokumentál, amely tartalmaz egy 5 perces időtartamot és egy 1 órás opciót, felár ellenében.
• Gemini: A Google Gemini kontextus gyorsítótárazása használati metaadatokon (például total_cached_tokens) keresztül teszi elérhetővé a gyorsítótárban elért tokenszámot, a dokumentáció pedig modellenként felsorolja a minimális bemeneti tokenszámot.
• Adatvezérlési vonatkozások: Az OpenAI API adatkezelési dokumentációja megjegyzi, hogy a kiterjesztett prompt gyorsítótárazás megköveteli a kulcs/érték tenzorok alkalmazásállapotként való tárolását a GPU-helyi tárolóban. Még akkor is, ha a szolgáltatók fenntartják az elkülönítési garanciákat, az átjáróknak kényes infrastruktúraként kell kezelniük a gyorsítótár viselkedését, nem pedig megosztott alkalmazásadattárként.
• Kutatási jel: Nyilvános kutatások azt vizsgálták, hogy az átjáró típusú architektúrák bevezethetnek-e olyan gyorsítótárazási sebezhetőségeket, amelyek megkerülik a szolgáltatói szintű gyorsítótár-elkülönítési feltételezéseket. Ez nem bizonyítja, hogy egy adott átjáró sebezhető, de támogatja a konzervatív bérlői elkülönítést.

Javaslat: A gyorsítótár-vezérlést explicit házirendekkel rendelkező átjáróként valósítsa meg, ne pedig az ismételt felszólítások véletlen mellékhatásaként.

Három régióra vonatkozó azonnali összeszerelési szerződés

A legfontosabb tervezési döntés az, hogy szétválasszuk a stabil és változékony tartalmat, mielőtt a kérés eljutna a szolgáltatói adapterhez.

1. régió: stabil előtag

A stabil előtag azt jelenti, hogy a tartalom várhatóan azonos marad az ugyanazon alkalmazásra, modellútvonalra és prompt sablonverzióra vonatkozó kérések során. Példák:

• alaprendszer-utasítások;
• biztonsági és szabályzati blokkok;
• eszközsémák;
• statikus termékdokumentáció;
• tárhelytérképek kódoló ügynökökhöz;
• javított kimeneti formátumú utasítások.

Ennek a régiónak determinisztikusnak kell lennie. Az átjárónak verziószámú sablonokból, kanonizált JSON-ból és stabil rendezési szabályokból kell felépítenie. Ha tartalmaz szerszámnyilvántartást, rendezze az eszközöket stabil eszközazonosító szerint. Ha JSON-sémákat is tartalmaz, sorosítsa őket determinisztikus kulcssorrenddel, generált időbélyegek nélkül.

2. régió: félig stabil bérlői vagy munkaterületi kontextus

A félstabil régió ritkábban változik, mint az egyéni kérések, de nincs globálisan megosztva. Példák:

• bérlőspecifikus házirend-felülbírálások;
• munkaterület-szintű eszközök engedélyezési listái;
• ügyfélspecifikus terminológia;
• csapatkódolási konvenciók;
• hosszú életű projektkörnyezet.

Ezt a régiót bérlői, munkaterület- vagy alkalmazáshatárra kell korlátozni. Lehet, hogy továbbra is gyorsítótárazható, de az átjáró soha nem feltételezheti, hogy egy másik bérlő biztonságosan újra felhasználhatja.

3. régió: változékony utótag

Az illékony utótag a kérésenkénti rész:

• felhasználói üzenet;
• részletek lekérve ehhez a lekérdezéshez;
• aktuális időbélyeg, ha valóban szükséges;
• azonosító és nyomkövetési metaadatok kérése, ha egyáltalán szerepel a promptban;
• rövid távú beszélgetési fordulatok;
• futásidejű eszköz eredményei.

Az alkalmazástervezés okozta gyorsítótár-kihagyások többsége azért történik, mert véletlenül illékony utótagadatok kerülnek az előtagba. Egy átjáró-oldali építőnek ezt meg kell nehezítenie.

Megvalósítási minta: stabil előtag-készítők

Egy praktikus átjáró-megvalósítás egy azonnali összeállítási felületet tesz közzé, ahelyett, hogy minden alkalmazásból egyetlen átlátszatlan prompt karakterláncot fogadna el.

{
  "template_id": "code-agent-v3",
  "bérlő_azonosítója": "bérlő_123",
  "útvonal": "coding-long-context",
  "stable_prefix": {
    "system_policy_version": "2026-08-01",
    "toolset_version": "tools-v12",
    "repo_context_version": "repo-map-8491"
  },
  "semi_stable_context": {
    "workspace_policy_version": "workspace-44-v6"
  },
  "volatile_suffix": {
    "user_message": "Indokolja meg, miért nem sikerült ez a teszt...",
    "retrieval_context_ids": ["chunk_7", "chunk_19"],
    "trace_id": "not_inserted_into_prompt"
  }
}

Az átjáró ezután a szolgáltató-specifikus kérést jeleníti meg. Ez lehetőséget ad az átjárónak a szabályok betartatására:

• az időbélyegek elutasítása a stabil előtag mezőkben;
• az eszközsémák kanonizálása;
• az egyes régiókat külön-külön kivonatolja;
• gyorsítótár-vezérlők csatolása ott, ahol a szolgáltató támogatja őket;
• megőrzi az azonnali szemantikát az illékony anyagok későbbi mozgatásakor;
• rögzítse a sablont és az előtag ujjlenyomatait a diagnosztikához.

Azoknál a régi alkalmazásoknál, amelyek csak nyers üzeneteket küldenek, az átjáró továbbra is tud szöszmötölési módot biztosítani: megvizsgálja az üzenetek sorrendjét, kiszámítja az előtag ujjlenyomatait, és jelentheti a valószínű gyorsítótár-megszakítókat anélkül, hogy először át kellene írnia a promptot.

Szolgáltatói adapterréteg: a gyorsítótár használatának normalizálása a különbségek elrejtése nélkül

Egy több modellből álló átjáró nem adhat ki három független gyorsítótár-jelentést a fejlesztők számára. Ezenkívül nem szabad olyan agresszíven ellaposítani a szolgáltató-specifikus gazdaságosságokat, hogy a számlák magyarázata lehetetlenné váljon.

Hozzon létre egy normalizált gyorsítótár-könyvet a következő mezőkkel:

{
  "request_id": "req_abc",
  "bérlő_azonosítója": "bérlő_123",
  "app_id": "kódügynök",
  "útvonal": "coding-long-context",
  "provider": "szolgáltató_neve",
  "model": "model_id",
  "template_id": "code-agent-v3",
  "stable_prefix_hash": "sha256:...",
  "semi_stable_hash": "sha256:...",
  "input_tokens_total": 58200,
  "input_tokens_uncached": 8200,
  "cache_write_tokens": 50000,
  "cache_read_tokens": 0,
  "output_tokens": 1300,
  "cache_ttl_class": "ephemeral_5m",
  "provider_cache_fields": {
    "raw_field_names": "tárolt_vagy_megszerkesztett_szolgáltató_használat"
  }
}

Az adapter normalizált kategóriákba sorolja a szolgáltató használatát:

• Nem gyorsítótárazott beviteli tokenek: gyorsítótár-olvasási engedmény vagy gyorsítótár-olvasási elszámolás nélkül feldolgozott tokenek.
• Gyorsítótár írási tokenek: olyan tokenek, amelyek létrehoztak vagy frissítettek egy szolgáltatói gyorsítótár-bejegyzést, amikor a szolgáltató jelenti ezt a különbséget.
• Gyorsítótár olvasási tokenek: a gyorsítótárból kiszolgált vagy a szolgáltató használati metaadatai által gyorsítótárazottnak számító tokenek.
• Kimeneti tokenek: generált tokenek, amelyeknek külön kell maradniuk az azonnali gyorsítótár-gazdaságosságtól.
• TTL opció: a gyorsítótár kiválasztott időtartama, ahol a szolgáltató választási lehetőséget kínál.

Javaslat: tárolja a nyers szolgáltatóhasználatot szerkesztett, sémaverzióval ellátott formában a normalizált mezők mellett. A normalizálás hasznos az irányítópultok esetében; A nyers mezők szükségesek az egyeztetéshez, amikor a szolgáltató szemantikája megváltozik.

Gyorsítótár megfigyelhetősége: irányítópultok, amelyek elmagyarázzák a kihagyásokat

Egy hasznos gyorsítótár-irányítópult többet tesz, mint az összes gyorsítótárban tárolt token megjelenítését. Segítenie kell a csapatoknak a következő kérdések megválaszolásában: „Melyik munkaterhelés töri meg az előtagot, és mi változott?”

A gyorsítótár mutatóinak nyomon követése:

• bérlő;
• munkaterület vagy alkalmazás;
• útvonalmodell;
• szolgáltató és modell;
• prompt sablon verziója;
• stabil előtag hash;
• félstabil kontextus hash;
• API-kulcs vagy szolgáltatásfiók, ha szükséges;
• időablak, különösen azért, mert a gyorsítótár TTL-ei sok munkaterheléshez rövidek.

A hasznos származtatott mutatók a következők:

• Gyorsítótár olvasási aránya: a gyorsítótárazott beviteli tokenek elosztva a gyorsítótárazásra alkalmas beviteli tokenek számával.
• Előtag lemorzsolódás: az eltérő stabil előtag-kivonatok száma sablonverziónként óránként.
• Sablonsodródás: a gyorsítótár-lekérés megváltozik a sablon kiadása után.
• Hidegindítási költség: a gyorsítótárba írás vagy a gyorsítótárazott beviteli ráfordítás a sorozat első kérésére.
• Útvonal-összehasonlítás: a szolgáltatói útvonalak találati aránya ugyanazon logikai terhelés mellett.

Ne alapértelmezés szerint tároljon nyers promptokat a hibakereséshez. Előnyben részesítse a hash-eket, a régióhosszakat, a sablonazonosítókat, a kanonizálási figyelmeztetéseket és a szerkesztett eltéréseket. Ha egy csapatnak mélyebb hibakeresésre van szüksége, akkor kifejezett hozzáférés-szabályozást és megőrzési korlátokat igényel.

Bérlői elkülönítési szabályzat: ne tervezze a bérlők közötti újrafelhasználásra

A legbiztonságosabb átjáró feltételezése egyszerű: a gyorsítótárazott viselkedésnek bérlői hatókörűnek kell lennie. Még ha két bérlő osztozik is egy azonos közrendű blokkon, az átjárónak nem szabad szándékosan irányítania vagy alakítania a forgalmat a bérlők közötti gyorsítótár-újrahasználat kihasználása érdekében.

A konzervatív irányelvek a következőket tartalmazzák:

• Bérlő-tudatos útválasztás: a gyorsítótárban tárolható forgalom iránya bérlői, munkaterületi és alkalmazási határok használatával.
• Nincsenek megosztott titkokat tartalmazó előtagok: soha ne helyezzen el bérlői titkokat, hitelesítő adatokat, személyes dokumentumokat vagy felhasználóspecifikus adatokat egy újrafelhasználható megosztott előtagban.
• Különálló előtag ujjlenyomatok: Ujjlenyomatok kiszámítása az átjáró főkönyvében szereplő bérlői hatókörrel, még akkor is, ha a megjelenített szöveg azonos.
• Szervezeti szintű vezérlők: lehetővé teszik az adminisztrátorok számára, hogy letiltsák a szolgáltató gyorsítótár funkcióit érzékeny munkaterhelések esetén.
• A szolgáltatók elkülönítése nem a termék viszonteladása: kezelje a szolgáltató gyorsítótár-elkülönítését alapvédelemként, nem pedig az ügyfelek közötti gyorsítótár-készlet létrehozásának engedélyeként.

Előrejelzés: amint a hosszú kontextusú ügynökök egyre gyakoribbá válnak, a gyorsítótár viselkedése a biztonsági felülvizsgálatok részévé válik, nem csak a költségvizsgálatok során. Azokat az átjárókat, amelyek bizonyítani tudják a bérlői hatókörű gyorsítótár-házirendet, könnyebb lesz irányítani.

Számlázási hozzárendelés: különálló gyorsítótár-olvasások, -írások és normál tokenek

Az azonnali gyorsítótárazás megnehezítheti a számlák megértését, ha az összes beviteli token egyetlen számként jelenik meg. A számlázási főkönyvnek legalább öt kategóriát meg kell őriznie:

1. gyorsítótárazott beviteli tokenek;
2. gyorsítótár írási tokenek;
3. gyorsítótár olvasási tokenek;
4. kimeneti tokenek;
5. szolgáltató-specifikus TTL vagy gyorsítótár-vezérlési díjak.

Ennek akkor van jelentősége, ha az egyik szolgáltató csökkenti a gyorsítótárazott olvasást, a másik eltérően számol fel a gyorsítótárba történő írásért, a másik pedig hosszabb TTL-lehetőséget tesz elérhetővé. A vevői számlának képesnek kell lennie arra, hogy magyarázatot adjon arra, hogy két, hasonló beviteli tokennel rendelkező kérésnek miért voltak eltérő költségei.

Belső visszaterheléshez rendeljen gyorsítótár-effektusokat a kérelmet benyújtó bérlőhöz és alkalmazáshoz. Kerülje a gyorsítótár-olvasási előnyök egyik bérlőtől a másikhoz való kiosztását. Ha egy megosztott belső platform csapata birtokolja a stabil prompt sablont, jelentse a sablon szintű gyorsítótár teljesítményét a bérlői számláktól elkülönítve.

Gyorsítótár-feltöltés ellenőrzőlista

Mielőtt engedélyezné a gyorsítótár kényszerítését, futtassa a felszólító sablonokat egy szálellenőrző listán keresztül:

• A stabil rendszerre vonatkozó utasítások az illékony felhasználói bevitel előtt jelennek meg.
• Az eszközsémák stabil azonosító vagy név szerint vannak rendezve.
• A JSON determinisztikusan szerializált.
• A stabil előtagban nem jelennek meg időbélyegek, véletlenszerű azonosítók, kérésazonosítók vagy nyomkövetési azonosítók.
• Nem jelennek meg felhasználóspecifikus titkok a megosztott újrafelhasználható blokkokban.
• A RAG-töredékek az újrafelhasználható irányelv- és eszközszakaszok után kerülnek elhelyezésre, kivéve, ha szándékos indok van rá.
• A felszólító sablonoknak van explicit verziója.
• A sablonkiadások korrelálhatók a gyorsítótár találati arányának változásaival.
• A szolgáltatói gyorsítótár-vezérlők csak adapterkódon keresztül használhatók, elszórt alkalmazáslogikán keresztül.
• A nyers prompt naplózás alapértelmezés szerint le van tiltva, vagy szigorú megőrzési és hozzáférési szabályok védik.

Közzétételi terv

1. Figyelje meg, mielőtt módosítja az utasításokat

Kezdje azzal, hogy összegyűjti a szolgáltató használati mezőit és a normalizált gyorsítótár-mutatókat a meglévő forgalomhoz. Számítsa ki az előtag ujjlenyomatait az első N tokenhez vagy az átjáró által meghatározott prompt régiókhoz. A cél az, hogy nagy mennyiségű, hosszú kontextusú útvonalakat találjunk magas előtag-lemorzsolódással.

2. Munkaterhelések osztályozása

Csoportosítsa a forgalmat kategóriákba: ügynöki munkamenetek, kódolási asszisztensek, RAG, támogatási automatizálás, dokumentumelemzés, kötegelt feladatok és rövid csevegés. Az azonnali gyorsítótár-munka általában a hosszú kontextusú és ismétlődő előtagú munkaterhelésekre fordítja a legnagyobb figyelmet. Előfordulhat, hogy a szolgáltatói küszöbérték alatti rövid felszólítások nem előnyösek.

3. Stabil előtag-készítők

Tegyen át egyetlen munkaterhelést a nyers azonnali építésről a régióalapú összeállításra. Tartsa szemantikailag egyenértékűnek a megjelenített szolgáltatói kérést. Ne kombinálja ezt a változtatást a modell áttelepítésével, az eszközök újratervezésével vagy jelentős átírásokkal, különben nem fogja tudni, mi okozta a mérőszám változásait.

4. Canary one route

Engedélyezze a gyorsítótár-vezérlőket egy bérlő vagy belső alkalmazás egy kis szeleténél. Hasonlítsa össze a gyorsítótár olvasási arányát, az előtag lemorzsolódását, az első tokenig eltelt időt, a hibaarányt és a költségkategóriákat. Kerülje a megtakarítások igénylését mindaddig, amíg a szolgáltató számlái nem egyeztethetők össze az átjáró főkönyveivel.

5. Fokozatosan érvényesít

A kanári után a szöszre vonatkozó figyelmeztetéseket változtassa irányelvek ellenőrzésévé. Például először figyelmeztessen az instabil szerszámsorrendre, majd utasítsa el azokat az új sablonváltozatokat, amelyek ingadozó metaadatokat tartalmaznak a stabil előtagban.

Kisváltások

• Nagyobb gyorsítótár találati aránya a gyorsítótárban való rugalmassághoz képest: a stabil előtagok javítják az újrafelhasználást, de előfordulhat, hogy a csapatoknak később át kell helyezniük a dinamikus utasításokat vagy újra kell tervezniük a sablonokat.
• A szolgáltató natív gyorsítótárazása és a hordozhatóság: az egyes szolgáltatók gyorsítótár-vezérlőinek használata javíthatja a gazdaságosságot, de a küszöbértékek, a TTL-ek, a mezők és az árképzés szemantikája eltérő.
• Megfigyelhetőség vs. érzékeny naplózás: a prompt diff-ek segítik a hibakeresést, de a kivonatok és a redukált diagnosztika biztonságosabb alapértelmezések.
• A bérlői elszigeteltség a maximális újrahasználattal szemben: a széles körű újrahasználat vonzónak tűnhet, de a bérlői hatókörű viselkedés biztonságosabb és könnyebben megmagyarázható.
• Hosszabb megőrzés a költségekhez és az irányelvek bonyolultságához képest: a hosszabb TTL-beállítások segíthetik az ügynöki munkameneteket, de eltérő árazási és adatkezelési szempontokat is bevezethetnek.

Intézhető következtetés

Az azonnali gyorsítótárazást az átjáró vezérlősík-problémájaként kezelje, ne a szolgáltató jelölőnégyzeteként. A gyakorlati minta a következő: stabil, félstabil és illékony prompt régiók meghatározása; determinisztikusan adja le őket; a szolgáltató-specifikus gyorsítótár-vezérlők adaptálása egy interfész mögé; a gyorsítótár használatának normalizálása főkönyvbe; felfedheti a gyorsítótár találati diagnosztikáját bérlő, alkalmazás, útvonal és sablonverzió szerint; és érvényesítse a bérlői hatókörű feltételezéseket.

Az első hasznos lépés nem az újraírás. Adja hozzá a gyorsítótár megfigyelhetőségét a leghosszabb promptokhoz, azonosítsa az előtag lemorzsolódását, és szöszölje be a legtöbb kihagyást okozó sablonokat. Miután elmagyarázta a gyorsítótár viselkedését, biztonságosan optimalizálhatja azt.

Kapcsolódó olvasmány

• gyorsítótár-tudatos kategóriák beépítése a számlázási főkönyvbe href="https://model-gate.com/en/blog/llm-observability-multi-model-api-gateway-traces-token-ledgers-safe-prompt-logging-9/">csatlakozás a gyorsítótár mérőszámaihoz biztonságos LLM-megfigyelhetőséggel
• tartsa a lekérési kontextus bérlői hatókörét a RAG-munkaterhelésekben