Ātra kešatmiņas vadība vairāku modeļu API vārtejā: stabili prefiksi, nomnieka izolācija un kešatmiņas trāpījumu analīze

Tūlītēju kešatmiņu saglabāšanu ir viegli izšķērdēt. Komandai var būt 40 000 marķieru sistēmas uzvedne, rīka shēma, politikas bloks, repozitorija karte vai aģenta atmiņa, kurai jābūt atkārtoti lietojamai, pēc tam nejauši uzvednes augšdaļā ievietojot laikspiedolu, pieprasījuma ID, lietotājvārdu, izguves fragmentu vai nejaušu rīku secību. Pakalpojumu sniedzējs redz atšķirīgu prefiksu, kešatmiņa ir palaista, latentums palielinās, un rēķins izskatās mulsinošs.

Viena nodrošinātāja lietojumprogrammā varat to labot lietojumprogrammas veidnē. Vairāku modeļu vārtejā problēma ir lielāka: katrs pakalpojumu sniedzējs atklāj dažādas kešatmiņas vadīklas, pilnvaru sliekšņus, darbības laiku, lietojuma laukus un norēķinu semantiku. Vārtejai ir nepieciešams pārnēsājams vadības plaknes modelis, lai apkopotu kešatmiņai drošas uzvednes, izmērītu kešatmiņas darbību, izolētu nomniekus un attiecinātu izmaksas.

Šajā rakstā ir aprakstīta atsauces arhitektūra. Tas nav klientu gadījuma pētījums un nepretendē uz etalonu rezultātiem. Tālāk minētie fakti izriet no pakalpojumu sniedzēja dokumentācijas un publiskas izpētes; projektēšanas ieteikumi ir vārtejas līmeņa darbības norādījumi.

Kļūmes režīms: kešatmiņas laušanas uzvednes montāža

Uzvednes kešatmiņa parasti atalgo atkārtotus uzvednes prefiksus. Precīza mehānika atšķiras atkarībā no pakalpojumu sniedzēja, taču praktiskā nozīme ir konsekventa: ja mainās uzvednes priekšpuse, tiek traucēta atkārtota izmantošana.

Izplatītākie kešatmiņas pārtraucēji ietver:

• Augšdaļā katra pieprasījuma metadati: laikspiedoli, izsekošanas ID, sesijas ID, izvietošanas ID vai ģenerētās pieprasījuma iezīmes.
• Lietotājam raksturīgi dati prefiksā: vārdi, konta atribūti, atļaujas vai privātas preferences, kas ievietotas pirms atkārtoti lietojamām politikas vai rīku blokiem.
• Nestabila rīku serializācija: rīku shēmas tiek izvadītas nedeterministiskā secībā, mainot atstarpes vai ģenerētus ID.
• Pārāk agri tiek izgūti fragmenti: RAG konteksts ievietots pirms stabilām sistēmas instrukcijām vai koplietotā repozitorija konteksta.
• Veidņu novirze: nelielas formulējuma izmaiņas, kas bieži tiek izlaistas bez versiju noteikšanas vai kešatmiņas diagnostikas.

Vārteja nevar maģiski padarīt nestabilu prefiksu ievietojamu kešatmiņā, taču tā var nodrošināt tūlītēju montāžas līgumu un padarīt redzamus kešatmiņas trūkumus.

Nodrošinātāja fakti, ko var izstrādāt

Detaļai ir nozīme, jo vārtejai ir jānormalizē darbība, neizliekoties, ka pakalpojumu sniedzēji ir identiski.

• OpenAI: OpenAI ir dokumentējis uzvednes kešatmiņu ilgākajam iepriekš aprēķinātajam uzvednes prefiksam. Tas sākas ar 1024 marķieriem, palielinās ar 128 marķieru soli un atklāj kešatmiņā saglabāto marķieru skaitu lietošanas laukos. OpenAI arī norāda, ka uzvednes kešatmiņas parasti tiek notīrītas pēc 5–10 minūtēm bezdarbības un vienmēr tiek noņemtas stundas laikā pēc kešatmiņas pēdējās lietošanas.
• Antropisks: antropisku tūlītēju saglabāšanu kešatmiņā var pieprasīt, izmantojot cache_control. Tās dokumentācijā ir aprakstīta kešatmiņas saskaņošana, izmantojot uzvednes komponentus, piemēram, rīkus, sistēmas saturu un ziņojumus, līdz blokam, kas atzīmēts ar kešatmiņas kontroli. Anthropic dokumentē īslaicīgu kešatmiņu, tostarp 5 minūšu ilgumu un 1 stundu iespēju par papildu samaksu.
• Gemini: Google Gemini konteksta kešatmiņa atklāj kešatmiņā trāpītu marķieru skaitu, izmantojot lietojuma metadatus, piemēram, total_cached_tokens, un tā dokumentācijā ir norādīts minimālais ievades pilnvaru skaits pēc modeļa.
• Ietekme uz datu vadību: OpenAI API datu kontroles dokumentācijā ir norādīts, ka paplašinātai uzvedņu saglabāšanai kešatmiņā ir jāsaglabā atslēgas/vērtības tenzori kā lietojumprogrammas statuss GPU lokālajā krātuvē. Pat tad, ja pakalpojumu sniedzēji saglabā izolācijas garantijas, vārtejas kešatmiņas darbība jāuzskata par sensitīvu infrastruktūru, nevis kā koplietotu lietojumprogrammu datu krātuvi.
• Pētīšanas signāls: publiskajos pētījumos ir pārbaudīts, vai vārtejas stila arhitektūras var ieviest tūlītējas kešatmiņas ievainojamības, kas apiet pakalpojumu sniedzēja līmeņa kešatmiņas izolācijas pieņēmumus. Tas neapliecina, ka konkrēta vārteja ir neaizsargāta, taču tā atbalsta konservatīvu nomnieku izolācijas dizainu.

Ieteikums: ieviesiet kešatmiņas kontroli kā vārtejas līdzekli ar precīzām politikām, nevis kā nejaušu blakusparādību atkārtotu uzvedņu gadījumā.

Trīs reģionu tūlītējas montāžas līgums

Svarīgākais dizaina lēmums ir nodalīt stabilu un nepastāvīgu saturu, pirms pieprasījums sasniedz nodrošinātāja adapteri.

1. reģions: stabils prefikss

Stabilais prefikss ir saturs, kam ir jāpaliek identiskam daudzos pieprasījumos vienai un tai pašai lietojumprogrammai, modeļa maršrutam un uzvednes veidnes versijai. Piemēri:

• pamatsistēmas instrukcijas;
• drošības un politikas bloki;
• rīku shēmas;
• statiskā produkta dokumentācija;
• kodēšanas aģentu repozitoriju kartes;
• norādījumi par fiksētu izvades formātu.

Šim reģionam ir jābūt deterministiskam. Vārtejai tā ir jāizveido, izmantojot versiju veidnes, kanonizētu JSON un stabilas pasūtīšanas kārtulas. Ja ir iekļauts rīku reģistrs, kārtojiet rīkus pēc stabila rīka ID. Ja ir iekļautas JSON shēmas, serializējiet tās ar deterministisku atslēgu secību un bez ģenerētiem laikspiedoliem.

2. reģions: daļēji stabils nomnieka vai darbvietas konteksts

Daļēji stabilais reģions mainās retāk nekā atsevišķi pieprasījumi, taču tas netiek koplietots globāli. Piemēri:

• īrnieka politikas ignorēšana;
• darbvietas līmeņa rīku atļaušanas saraksti;
• klientam specifiska terminoloģija;
• komandas kodēšanas konvencijas;
• ilgstoša projekta konteksts.

Šim reģionam ir jāattiecas uz nomnieku, darbvietu vai lietojumprogrammas robežu. To joprojām var saglabāt kešatmiņā, taču vārtejai nekad nevajadzētu pieņemt, ka cits nomnieks to var droši izmantot atkārtoti.

3. reģions: nepastāvīgs sufikss

Negaistošais sufikss ir pieprasījuma daļa:

• lietotāja ziņojums;
• izgūti fragmenti šim vaicājumam;
• pašreizējais laikspiedols, ja tas patiešām nepieciešams;
• pieprasīt ID un izsekošanas metadatus, ja tie vispār ir iekļauti uzvednē;
• īstermiņa sarunu pagriezieni;
• izpildlaika rīka rezultāti.

Lielākā daļa kešatmiņas izlaidumu, ko izraisa lietojumprogrammas dizains, notiek tāpēc, ka prefiksā nejauši tiek ievietoti nepastāvīgi sufiksa dati. Vārtejas puses veidotājam vajadzētu to padarīt sarežģītu.

Ieviešanas modelis: stabilu prefiksu veidotāji

Praktiska vārtejas ieviešana var parādīt tūlītēju montāžas saskarni, nevis pieņemt vienu necaurspīdīgu uzvednes virkni no katras lietojumprogrammas.

{
  "template_id": "code-agent-v3",
  "īrnieka_id": "īrnieks_123",
  "maršruts": "kodēšana-ilgs konteksts",
  "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"
  },
  "gaistošais_sufikss": {
    "user_message": "Paskaidrojiet, kāpēc šī pārbaude neizdodas...",
    "retrieval_context_ids": ["chunk_7", "chunk_19"],
    "trace_id": "not_inserted_into_prompt"
  }
}

Pēc tam vārteja atveido pakalpojumu sniedzējam raksturīgu pieprasījumu. Tādējādi vārtejai ir vieta, kur ieviest noteikumus:

• noraidīt laikspiedolus stabilos prefiksu laukos;
• kanonizēt rīku shēmas;
• jaukt katru reģionu atsevišķi;
• pievienojiet kešatmiņas vadīklas tur, kur pakalpojumu sniedzējs tos atbalsta;
• saglabājiet tūlītēju semantiku, vēlāk pārvietojot gaistošus materiālus;
• diagnostikai ierakstiet veidni un prefiksu pirkstu nospiedumus.

Mantotajām lietojumprogrammām, kas sūta tikai neapstrādātus ziņojumus, vārteja joprojām var nodrošināt savārstīšanas režīmu: pārbaudīt ziņojumu secību, aprēķināt prefiksu pirkstu nospiedumus un ziņot par iespējamiem kešatmiņas pārkāpumiem, sākotnēji nepārrakstot uzvedni.

Pakalpojumu sniedzēja adaptera slānis: normalizējiet kešatmiņas lietojumu, neslēpjot atšķirības

Vairāku modeļu vārteja izstrādātājiem nedrīkst atklāt trīs nesaistītus kešatmiņas pārskatus. Tas arī nedrīkst tik agresīvi izlīdzināt pakalpojumu sniedzēja ekonomiku, ka rēķinus nav iespējams izskaidrot.

Izveidojiet normalizētu kešatmiņas virsgrāmatu ar tādiem laukiem kā:

{
  "request_id": "req_abc",
  "īrnieka_id": "īrnieks_123",
  "app_id": "koda aģents",
  "maršruts": "kodēšana-ilgs konteksts",
  "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"
  }
}

Adapteris sniedz pakalpojumu sniedzēja lietojumu normalizētās kategorijās:

• Nekešatmiņā saglabāti ievades pilnvari: marķieri, kas apstrādāti bez kešatmiņas lasīšanas atlaides vai kešatmiņas lasīšanas uzskaites.
• Kešatmiņas rakstīšanas pilnvaras: marķieri, kas izveidoja vai atsvaidzina pakalpojumu sniedzēja puses kešatmiņas ierakstu, kad nodrošinātājs ziņo par šo atšķirību.
• Kešatmiņas lasīšanas pilnvaras: marķieri, kas tiek rādīti no kešatmiņas vai tiek uzskaitīti kā kešatmiņā saglabāti, izmantojot pakalpojumu sniedzēja lietošanas metadatus.
• Izvades marķieri: ģenerēti marķieri, kuriem jāpaliek atsevišķi no uzvednes kešatmiņas ekonomikas.
• TTL opcija: atlasītā kešatmiņas ilguma klase, kurā pakalpojumu sniedzējs piedāvā izvēli.

Ieteikums: saglabājiet neapstrādātu pakalpojumu sniedzēja lietojumu rediģētā, shēmas versijā līdzās normalizētiem laukiem. Normalizācija ir noderīga informācijas paneļiem; neapstrādāti lauki ir nepieciešami saskaņošanai, kad mainās nodrošinātāja semantika.

Kešatmiņas novērojamība: informācijas paneļi, kas izskaidro kļūdas

Noderīgs kešatmiņas informācijas panelis dara vairāk, nekā parāda kopējo kešatmiņā saglabāto pilnvaru skaitu. Tam vajadzētu palīdzēt komandām atbildēt: “Kura darba slodze pārkāpj prefiksu, un kas mainījās?”

Kešatmiņas metrikas izsekošana pēc:

• īrnieks;
• darbvieta vai lietotne;
• maršruta modelis;
• nodrošinātājs un modelis;
• uzvednes veidnes versija;
• stabila prefiksa jaukšana;
• daļēji stabila konteksta hash;
• API atslēga vai pakalpojuma konts, ja nepieciešams;
• laika logs, jo īpaši tāpēc, ka kešatmiņas TTL ir īss daudzām darba slodzēm.

Noderīga atvasināta metrika ir:

• Kešatmiņas lasīšanas ātrums: kešatmiņā saglabātās ievades pilnvaras dalītas ar kopējo ievades pilnvaru skaitu, kas ir piemērotas saglabāšanai kešatmiņā.
• Prefiksu maiņa: atšķirīgu stabilu prefiksu jaucēju skaits vienā veidnes versijā stundā.
• Veidnes novirze: kešatmiņas trāpījumu izmaiņas pēc veidnes izlaišanas.
• Aukstās palaišanas izmaksas: kešatmiņas ierakstīšanas vai nekešatmiņas ievades tēriņi pirmajam sērijas pieprasījumam.
• Maršrutu salīdzinājums: trāpījumu rādītāji starp pakalpojumu sniedzēju maršrutiem ar tādu pašu loģisko darba slodzi.

Neizmantojiet noklusējuma glabāšanas neapstrādātas uzvednes atkļūdošanai. Dodiet priekšroku jaucējkodiem, reģionu garumiem, veidņu ID, kanonizācijas brīdinājumiem un rediģētajām atšķirībām. Ja komandai nepieciešama padziļināta atkļūdošana, pieprasiet precīzas piekļuves vadīklas un saglabāšanas ierobežojumus.

Īrnieku izolācijas politika: neveidojiet atkārtotai izmantošanai starp nomniekiem

Drošākās vārtejas pieņēmums ir vienkāršs: kešatmiņas darbībai ir jāattiecas uz nomnieku. Pat ja diviem nomniekiem ir identisks sabiedriskās politikas bloks, vārtejai nevajadzētu apzināti maršrutēt vai veidot trafiku, lai izmantotu starpnomnieku kešatmiņas atkārtotu izmantošanu.

Konservatīvā politika ietver:

• Nomnieku atpazīstama maršrutēšana: maršrutējiet kešatmiņu, izmantojot nomnieka, darbvietas un lietojumprogrammu robežas.
• Nav koplietotu noslēpumu saturošu prefiksu: nekad neievietojiet nomnieka noslēpumus, akreditācijas datus, privātus dokumentus vai lietotājam raksturīgus datus atkārtoti lietojamā koplietotā prefiksā.
• Atsevišķi prefiksu pirkstu nospiedumi: aprēķiniet pirkstu nospiedumus ar nomnieka tvērumu, kas iekļauts vārtejas virsgrāmatā, pat ja renderētais teksts ir identisks.
• Organizācijas līmeņa vadīklas: ļauj administratoriem atspējot pakalpojumu sniedzēja kešatmiņas funkcijas jutīgām darba slodzēm.
• Pakalpojumu sniedzēja izolācija nav produkta funkcija, ko pārdot tālāk. Uztveriet pakalpojumu sniedzēja kešatmiņas izolāciju kā pamata aizsardzību, nevis kā atļauju veidot starpklientu kešatmiņas apvienošanu.

Paredzēšana: tā kā ilgstoša konteksta aģenti kļūst arvien izplatītāki, kešatmiņas darbība kļūs par drošības pārskatiem, nevis tikai izmaksu pārskatiem. Vārtejas, kas var pierādīt nomnieka darbības jomas kešatmiņas politiku, būs vieglāk pārvaldāmas.

Norēķinu attiecinājums: atsevišķas kešatmiņas lasīšanas, rakstīšanas un parastās pilnvaras

Ja visas ievades pilnvaras tiek rādītas kā viens skaitlis, rēķini var būt grūtāk saprotami. Norēķinu virsgrāmatā ir jāsaglabā vismaz piecas kategorijas:

1. neatslēgtas ievades pilnvaras;
2. kešatmiņas rakstīšanas pilnvaras;
3. kešatmiņas lasīšanas pilnvaras;
4. izvades marķieri;
5. pakalpojumu sniedzējam noteiktas TTL vai kešatmiņas kontroles izmaksas.

Tam ir nozīme, ja viens pakalpojumu sniedzējs atlaiž kešatmiņā saglabāto lasīšanu, cits iekasē atšķirīgu maksu par rakstīšanu kešatmiņā un cits piedāvā garāku TTL opciju. Klienta rēķinā ir jāspēj izskaidrot, kāpēc diviem pieprasījumiem ar līdzīgām kopējām ievades pilnvarām bija atšķirīgas izmaksas.

Lai veiktu iekšējo atmaksu, attieciniet kešatmiņas efektus uz nomnieku un lietojumprogrammu, kas veica pieprasījumu. Izvairieties no kešatmiņas lasīšanas priekšrocību piešķiršanas no viena nomnieka citam. Ja koplietotai iekšējās platformas komandai pieder stabila uzvednes veidne, ziņojiet par veidnes līmeņa kešatmiņas veiktspēju atsevišķi no nomnieka rēķiniem.

Kešatmiņas papildināšanas kontrolsaraksts

Pirms iespējot kešatmiņas izpildi, palaidiet uzvedņu veidnes, izmantojot savārstījumu kontrolsarakstu:

• Stabilas sistēmas norādījumi parādās pirms nepastāvīgas lietotāja ievades.
• Rīku shēmas tiek kārtotas pēc stabila ID vai nosaukuma.
• JSON ir serializēts deterministiski.
• Stabilajā prefiksā netiek rādīti laikspiedoli, nejauši ID, pieprasījumu ID vai izsekošanas ID.
• Koplietotajos atkārtoti izmantojamajos blokos netiek rādīti lietotājam specifiski noslēpumi.
• RAG fragmenti tiek ievietoti aiz atkārtoti lietojamām politikas un rīku sadaļām, ja vien nav apzināta iemesla to nedarīt.
• Uzvedņu veidnēm ir precīzas versijas.
• Veidņu laidienus var saistīt ar kešatmiņas trāpījumu skaita izmaiņām.
• Pakalpojumu sniedzēja kešatmiņas vadīklas tiek izmantotas tikai ar adaptera kodu, nevis izkliedētu lietojumprogrammu loģiku.
• Neapstrādāta uzvednes reģistrēšana ir atspējota pēc noklusējuma vai aizsargāta ar stingriem saglabāšanas un piekļuves noteikumiem.

Izplatīšanas plāns

1. Ievērojiet, pirms maināt uzvednes

Sāciet, apkopojot nodrošinātāja lietojuma laukus un normalizētas kešatmiņas metriku esošajai datplūsmai. Aprēķiniet prefiksu pirkstu nospiedumus pirmajiem N marķieriem vai vārtejas definētajiem uzvednes apgabaliem. Mērķis ir atrast liela apjoma, gara konteksta maršrutus ar lielu prefiksu novirzi.

2. Klasificēt darba slodzi

Grupējiet trafiku kategorijās: aģentu sesijas, kodēšanas palīgi, RAG, atbalsta automatizācija, dokumentu analīze, pakešu darbi un īsa tērzēšana. Veicot tūlītēju kešatmiņas darbu, lielākā uzmanība parasti tiek pievērsta gara konteksta un atkārtotu prefiksu darba slodzēm. Īsas uzvednes zem pakalpojumu sniedzēja sliekšņa var nesniegt labumu.

3. Ieviest stabilu prefiksu veidotājus

Pārvietojiet vienu darba slodzi no neapstrādātas tūlītējas izveides uz reģionālo montāžu. Saglabājiet atveidoto nodrošinātāja pieprasījumu semantiski līdzvērtīgu. Neapvienojiet šīs izmaiņas ar modeļa migrēšanu, rīka pārprojektēšanu vai būtiskām uzvedņu pārrakstīšanām, pretējā gadījumā jūs nezināsiet, kas izraisīja metrikas izmaiņas.

4. Kanāriju viens maršruts

Iespējojiet kešatmiņas vadīklas nelielai viena nomnieka vai iekšējās lietotnes daļai. Salīdziniet kešatmiņas nolasīšanas ātrumu, prefiksu nobīdi, laiku līdz pirmajam marķieri, kļūdu līmeni un izmaksu kategorijas. Nepieprasiet ietaupījumus, kamēr pakalpojumu sniedzēja rēķini nav saskaņoti ar vārtejas virsgrāmatām.

5. Ieviest pakāpeniski

Pēc kanārijputniem pārvērtiet brīdinājumus par pūkām par politikas pārbaudēm. Piemēram, vispirms brīdiniet par nestabilu rīku secību, pēc tam noraidiet jaunas veidņu versijas, kuru stabilajā prefiksā ir iekļauti nepastāvīgi metadati.

Kompromisi

• Lielāks kešatmiņas trāpījumu līmenis salīdzinājumā ar tūlītēju elastību: stabili prefiksi uzlabo atkārtotu izmantošanu, taču komandām, iespējams, vēlāk būs jāpārvieto dinamiskie norādījumi vai jāpārveido veidnes.
• Pakalpojumu sniedzēja vietējā kešatmiņa un pārnesamība: katra pakalpojumu sniedzēja kešatmiņas vadīklu izmantošana var uzlabot ekonomiku, taču atšķiras sliekšņi, TTL, lauki un cenu noteikšanas semantika.
• Novērojamība salīdzinājumā ar sensitīvu reģistrēšanu: tūlītējas atšķirības palīdz atkļūdot kļūdas, taču jaucējvērtības un rediģētā diagnostika ir drošāki noklusējuma iestatījumi.
• Īrnieka izolācija salīdzinājumā ar maksimālo atkārtoto izmantošanu: plaša atkārtota izmantošana var izskatīties pievilcīga, taču īrnieka rīcība ir drošāka un vieglāk izskaidrojama.
• Ilgāka saglabāšana salīdzinājumā ar izmaksām un politikas sarežģītību: garākas TTL opcijas var palīdzēt aģenta sesijām, taču var ieviest atšķirīgus cenu noteikšanas un datu kontroles apsvērumus.

Lietojams secinājums

Uzskatiet tūlītēju kešatmiņu kā vārtejas vadības plaknes problēmu, nevis pakalpojumu sniedzēja izvēles rūtiņu. Praktiskais modelis ir šāds: definējiet stabilus, daļēji stabilus un nepastāvīgus tūlītējus reģionus; atveidot tos deterministiski; pielāgot pakalpojumu sniedzējam raksturīgās kešatmiņas vadīklas aiz viena interfeisa; normalizēt kešatmiņas izmantošanu virsgrāmatā; atklāt kešatmiņas trāpījumu diagnostiku pēc nomnieka, lietotnes, maršruta un veidnes versijas; un īstenot īrnieka tvēruma pieņēmumus.

Pirmais noderīgais solis nav pārrakstīšana. Pievienojiet savām garākajām uzvednēm kešatmiņas novērojamību, identificējiet prefiksu izmaiņu un saplok veidnes, kas izraisa visvairāk kļūdu. Kad varat izskaidrot kešatmiņas darbību, varat to droši optimizēt.

Saistīta informācija

• veidojiet kešatmiņu apzinošas kategorijas norēķinu virsgrāmatā href="https://model-gate.com/en/blog/llm-observability-multi-model-api-gateway-traces-token-ledgers-safe-prompt-logging-9/">pievienojieties kešatmiņas rādītājiem ar drošu LLM novērojamību
• saglabāt izguves konteksta nomnieka tvērumu RAG darba slodzēs