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 javaslatok á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: Nem determinisztikus sorrendben kibocsátott eszközsémák, változó szóközzel vagy generált azonosítókkal.
• A töredékek lekérése túl korán: RAG-kontextus beszúrva a stabil rendszerutasítások vagy a megosztott tárolókontextus elé.
• Sablonsodródás: Kis szövegmódosítások, amelyeket gyakran tesznek közzé verzió- és gyorsítótár-diagnosztika nélkül.

Egy átjáró nem képes varázslatosan gyorsítótárazhatóvá tenni egy 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.

Tények a szolgáltatóról a tervezéshez

A részletek azért számítanak, mert egy átjárónak normalizálnia kell a viselkedést anélkül, hogy azt tenné, hogy a szolgáltatók azonosak lennének.

• OpenAI: OpenAI dokumentálta a prompt gyorsítótárazást a leghosszabb ideig 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. A OpenAI azt is kimondja, 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.
• Anthropic: Anthropic A gyorsítótárazást a cache_control segítségével lehet kérni. Dokumentációja leírja a gyorsítótár-illesztést az olyan prompt összetevők között, mint az eszközök, a rendszertartalom és az üzenetek a gyorsítótár-vezérléssel megjelölt blokkig. Anthropic egy átmeneti 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: Google Gemini A kontextus-gyorsítótárazás felfedi a gyorsítótár találati tokenszámát a használati metaadatokon, például a total_cached_tokens-on keresztül, a dokumentáció pedig modellenként felsorolja a minimális bemeneti tokenszámot.
• Data-control impplication: OpenAI API adatvezérlé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ési tervezést.

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

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

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

1. régió: stabil előtag

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

• alapvető rendszerre vonatkozó 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;
• fix 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 é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át tartalmaz, sorosítsa őket determinisztikus kulcssorrenddel, és ne generáljon időbélyeget.

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

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 gyakorlati átjáró-megvalósítás egy azonnali összeállítási felületet jelenthet, ahelyett, hogy minden alkalmazásból egyetlen átlátszatlan prompt karakterláncot fogadna el.

{
  "template_id": "code-agent-v3",
  "tenant_id": "tenant_123",
  "route": "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": "Explain why this test fails...",
    "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:

• időbélyegek elutasítása a stabil előtag mezőkben;
• az eszközsémák kanonizálása;
• minden régió külön-külön kivonatolt;
• 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;
• sablon rögzítése és ujjlenyomatok előtagja 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: ellenőrizni az üzenetek sorrendjét, kiszámítani az előtag ujjlenyomatait, és jelenteni 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

A többmodelles á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 leegyenlítenie a szolgáltató-specifikus közgazdaságtanokat, hogy a számlák magyarázata lehetetlenné váljon.

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

{
  "request_id": "req_abc",
  "tenant_id": "tenant_123",
  "app_id": "code-agent",
  "route": "coding-long-context",
  "provider": "provider_name",
  "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": "stored_or_redacted_provider_usage"
  }
}

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

• Gyorsítótárazott beviteli tokenek: gyorsítótár-olvasási kedvezmé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óoldali gyorsítótár-bejegyzést, amikor a szolgáltató jelzi 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 a gyorsítótár-gazdaságosságtól.
• TTL-opció: a kiválasztott gyorsítótár-időtartam-osztály, ahol a szolgáltató választási lehetőséget kínál.

Javaslat: Tárolja a nyers szolgáltatóhasználatot redukált, 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őkre szükség van 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 hiányosságokat

Egy hasznos gyorsítótár-irányítópult többre képes, mint az összes gyorsítótárazott token megjelenítése. 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 template version;
• 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-jei 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 osztva a gyorsítótárazásra alkalmas beviteli tokenek számával.
• Prefix churn: különböző 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: gyorsítótár írási vagy gyorsítótárazott beviteli ráfordítása a sorozat első kérésére.
• Útvonal-összehasonlítás: találati arány a szolgáltatói útvonalakon azonos logikai terhelés mellett.

Ne alapértelmezés szerint tárolja a 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 redukált eltéréseket. Ha egy csapatnak mélyebb hibakeresésre van szüksége, akkor egyértelmű hozzáférés-szabályozást és megőrzési korlátokat írjon elő.

Bérlői elkülönítési szabályzat: ne tervezzen több bérlői ú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 nyilvános szabályzati blokkon, az átjárónak nem szabad szándékosan irányítania vagy alakítania a forgalmat a bérlői gyorsítótár újrahasználatának kihasználása érdekében.

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

• Tenant-aware routing: a gyorsítótárazott forgalmat bérlői, munkaterületi és alkalmazási határok segítségével irányítja.
• Nincsenek megosztott titkot hordozó 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 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 a rendszergazdák számára, hogy letiltsák a szolgáltató gyorsítótár funkcióit érzékeny munkaterhelések esetén.
• A szolgáltatói elkülönítés nem a termék viszonteladása: kezelje a szolgáltatói gyorsítótár-elkülönítést 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. Azok az átjárók, amelyek bizonyítani tudják a bérlői hatókörű gyorsítótár-szabályzatot, könnyebben kezelhetők lesznek.

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ó engedményt ad a gyorsítótárazott olvasásért, a másik eltérő díjat számít 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érelemnek miért volt eltérő költsége.

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ést, futtassa a prompt 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.
• Nem jelennek meg időbélyegek, véletlenszerű azonosítók, kérésazonosítók vagy nyomkövetési azonosítók a stabil előtagban.
• 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 ok van rá.
• A prompt 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 nem.
• 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 az utasítások módosítása előtt

Kezdje azzal, hogy összegyűjti a szolgáltatói használati mezőket é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 bemutatása

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 módosítást a modell áttelepítésével, az eszköz újratervezésével vagy a felszólítások jelentős átírásával, különben nem fogja tudni, mi okozta a mérőszám változásait.

4. Canary one route

A gyorsítótár-vezérlők engedélyezése 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. Fokozatos végrehajtás

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

Trade-offs

• Nagyobb gyorsítótár találati aránya, mint rugalmasság: 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ési szemantika eltérő.
• Megfigyelhetőség vs. érzékeny naplózás: a prompt diff-ek segítenek a hibakeresésben, de a hash-ek és a redukált diagnosztika biztonságosabb alapértelmezések.
• A bérlői elszigeteltség kontra maximális újrahasználat: 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, illetve költség és irányelvek összetettsége: A hosszabb TTL-beállítások segíthetik az ügynöki munkameneteket, de eltérő árképzési és adatkezelési szempontokat is bevezethetnek.

Igazítható 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ói jelölőnégyzetké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őtagok 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
• Csatlakozzon a gyorsítótár-mutatókhoz biztonságos LLM-mel observability
• tartsa a lekérési kontextus bérlői hatókörét a RAG-munkaterhelésekben