Kontrola brze predmemorije u API pristupniku s više modela: stabilni prefiksi, izolacija stanara i analiza učitavanja predmemorije

Promptno predmemoriranje lako je protratiti. Tim može imati upit sustava od 40 000 tokena, shemu alata, blok pravila, mapu repozitorija ili memoriju agenta koja bi se trebala ponovno koristiti, a zatim slučajno staviti vremensku oznaku, ID zahtjeva, korisničko ime, isječak za dohvaćanje ili nasumični poredak alata pri vrhu upita. Davatelj vidi drugačiji prefiks, predmemorija je propuštena, latencija se povećava, a račun izgleda zbunjujuće.

U aplikaciji s jednim pružateljem to možete popraviti unutar predloška aplikacije. U pristupniku s više modela problem je veći: svaki pružatelj izlaže različite kontrole predmemorije, pragove tokena, ponašanje vremena života, polja upotrebe i semantiku naplate. Pristupniku je potreban prijenosni uzorak kontrolne ravnine za sastavljanje upita sigurnih u predmemoriju, mjerenje ponašanja predmemorije, izolaciju zakupaca i pripisivanje troškova.

Ovaj članak opisuje referentnu arhitekturu. To nije studija slučaja kupca i ne zahtijeva referentne rezultate. Činjenice u nastavku proizlaze iz dokumentacije pružatelja usluga i javnog istraživanja; preporuke za dizajn su operativne smjernice na razini pristupnika.

Način neuspjeha: sklop upita za razbijanje predmemorije

Predmemoriranje upita općenito nagrađuje ponovljene prefikse upita. Točna mehanika razlikuje se ovisno o pružatelju usluga, ali praktična implikacija je dosljedna: ako se prednji dio upita promijeni, ponovna upotreba trpi.

Uobičajeni razbijači predmemorije uključuju:

• Metapodaci po zahtjevu na vrhu: vremenske oznake, ID-ovi praćenja, ID-ovi sesija, ID-ovi implementacije ili generirane oznake zahtjeva.
• Podaci specifični za korisnika u prefiksu: imena, atributi računa, dopuštenja ili privatne postavke postavljene ispred pravila za višekratnu upotrebu ili blokova alata.
• Nestabilna serijalizacija alata: sheme alata emitirane nedeterminističkim redoslijedom, s promjenom razmaka ili generiranih ID-ova.
• Isječci za dohvaćanje prerano: RAG kontekst umetnut prije uputa stabilnog sustava ili konteksta dijeljenog repozitorija.
• Odstupanje predloška: male izmjene teksta koje se često objavljuju bez određivanja verzija ili dijagnostike predmemorije.

Gateway ne može magično učiniti nestabilni prefiks predmemoriranim, ali može nametnuti ugovor o brzom sklapanju i učiniti promašaje predmemorije vidljivima.

Činjenice o pružatelju usluga oko kojih treba dizajnirati

Pojedinosti su bitne jer pristupnik mora normalizirati ponašanje bez pretvaranja da su pružatelji usluga identični.

• OpenAI: OpenAI je dokumentirao predmemoriranje upita za najdulji prethodno izračunati prefiks obavijesti. Započinje s 1024 tokena, povećava se u koracima od 128 tokena i izlaže predmemorirane brojeve tokena u poljima upotrebe. OpenAI također navodi da se brze predmemorije obično brišu nakon 5-10 minuta neaktivnosti i uvijek se uklanjaju unutar jednog sata od zadnje upotrebe predmemorije.
• Anthropic: Anthropic promptno predmemoriranje može se zatražiti s cache_control. Njegova dokumentacija opisuje usklađivanje predmemorije preko brzih komponenti kao što su alati, sadržaj sustava i poruke do bloka označenog kontrolom predmemorije. Anthropic dokumentira efemernu predmemoriju, uključujući trajanje od 5 minuta i opciju od 1 sata uz dodatnu cijenu.
• Gemini: Google Gemini predmemoriranje konteksta izlaže brojeve tokena za predmemoriju putem metapodataka o korištenju kao što je total_cached_tokens, a njegova dokumentacija navodi minimalne brojeve tokena unosa po modelu.
• Implikacija kontrole podataka: OpenAI-ova API dokumentacija kontrole podataka napominje da prošireno brzo predmemoriranje zahtijeva pohranjivanje tenzora ključ/vrijednost kao stanja aplikacije u lokalnoj pohrani GPU-a. Čak i kada pružatelji usluga održavaju jamstva izolacije, pristupnici bi trebali tretirati ponašanje predmemorije kao osjetljivu infrastrukturu, a ne kao dijeljenu pohranu podataka aplikacije.
• Signal istraživanja: Javno istraživanje ispitalo je mogu li arhitekture u stilu pristupnika uvesti ranjivosti brzog predmemoriranja koje zaobilaze pretpostavke izolacije predmemorije na razini pružatelja usluga. To ne dokazuje da je određeni pristupnik ranjiv, ali podržava konzervativni dizajn izolacije stanara.

Preporuka: implementirajte kontrolu predmemorije kao značajku pristupnika s izričitim pravilima, a ne kao slučajnu nuspojavu ponovljenih upita.

Ugovor o brzoj montaži u tri regije

Najvažnija odluka o dizajnu je odvajanje stabilnog i nepostojanog sadržaja prije nego što zahtjev stigne do adaptera pružatelja usluga.

Regija 1: stabilni prefiks

Stabilni prefiks je sadržaj za koji se očekuje da će ostati identičan u mnogim zahtjevima za istu aplikaciju, rutu modela i verziju predloška upita. Primjeri uključuju:

• upute temeljnog sustava;
• sigurnosni i politički blokovi;
• sheme alata;
• statička dokumentacija proizvoda;
• mape repozitorija za agente kodiranja;
• popravljene upute za izlazni format.

Ova bi regija trebala biti deterministička. Gateway bi ga trebao izgraditi od verzioniranih predložaka, kanonikaliziranih JSON i stabilnih pravila sređivanja. Ako je uključen registar alata, sortirajte alate prema stabilnom ID-u alata. Ako su JSON sheme uključene, serijalizirajte ih determinističkim redoslijedom ključeva i bez generiranih vremenskih oznaka.

Regija 2: polustabilni stanar ili kontekst radnog prostora

Polustabilna regija mijenja se rjeđe od pojedinačnih zahtjeva, ali se ne dijeli globalno. Primjeri uključuju:

• nadjačava pravila specifična za stanara;
• popisi dopuštenih alata na razini radnog prostora;
• terminologija specifična za kupca;
• konvencije timskog kodiranja;
• dugotrajni kontekst projekta.

Ova regija treba biti ograničena na granicu stanara, radnog prostora ili aplikacije. Može se i dalje predmemorirati, ali gateway nikada ne bi trebao pretpostaviti da ga drugi zakupac može sigurno ponovno koristiti.

Regija 3: nepostojani sufiks

Hlapljivi sufiks je dio po zahtjevu:

• korisnička poruka;
• dohvaćeni isječci za ovaj upit;
• trenutačna vremenska oznaka, ako je uistinu potrebna;
• ID zahtjeva i metapodaci praćenja, ako su uopće uključeni u upit;
• kratkotrajne promjene u razgovoru;
• rezultati alata za vrijeme izvođenja.

Većina promašaja predmemorije uzrokovanih dizajnom aplikacije događa se jer su nestabilni podaci sufiksa slučajno smješteni u prefiks. Graditelj na strani pristupnika trebao bi to otežati.

Uzorak implementacije: graditelji stabilnih prefiksa

Praktična implementacija pristupnika može izložiti sučelje brzog sklapanja umjesto prihvaćanja jednog neprozirnog niza upita iz svake aplikacije.

{
  "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"
  }
}

Gateway zatim prikazuje zahtjev specifičan za pružatelja usluge. To daje pristupniku mjesto za provođenje pravila:

• odbaci vremenske oznake u stabilnim poljima prefiksa;
• kanonikaliziraj sheme alata;
• raspršiti svaku regiju zasebno;
• priložite kontrole predmemorije tamo gdje ih pružatelj podržava;
• sačuvajte brzu semantiku dok kasnije premještate nepostojan materijal;
• predložak snimanja i prefiks otisaka prstiju za dijagnostiku.

Za naslijeđene aplikacije koje šalju samo neobrađene poruke, pristupnik još uvijek može pružiti način rada s vlaknima: pregledajte redoslijed poruka, izračunajte otiske prstiju prefiksa i prijavite vjerojatne razbijače predmemorije bez početnog ponovnog pisanja upita.

Adapterski sloj pružatelja: normalizirajte korištenje predmemorije bez skrivanja razlika

Pristupnik s više modela ne bi trebao izlagati tri nepovezana izvješća predmemorije programerima. Također ne bi trebalo tako agresivno izravnati ekonomiju specifičnu za pružatelja usluge da fakture postane nemoguće objasniti.

Stvorite normaliziranu knjigu predmemorije s poljima kao što su:

{
  "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"
  }
}

Adapter preslikava upotrebu pružatelja u normalizirane kategorije:

• Nekeširani ulazni tokeni: tokeni obrađeni bez popusta za čitanje predmemorije ili obračunavanja čitanja predmemorije.
• Tokeni pisanja u predmemoriju: tokeni koji su stvorili ili osvježili unos predmemorije na strani pružatelja usluga kada pružatelj prijavi ovu razliku.
• Tokeni čitanja predmemorije: tokeni posluženi iz predmemorije ili metapodaci o korištenju davatelja računaju kao predmemorirani.
• Izlazni tokeni: generirani tokeni, koji bi trebali ostati odvojeni od ekonomije brze predmemorije.
• TTL opcija: odabrana klasa trajanja predmemorije gdje pružatelj izlaže izbor.

Preporuka: pohranite neobrađenu upotrebu pružatelja usluga u redigiranom obliku s verzijom sheme uz normalizirana polja. Normalizacija je korisna za nadzorne ploče; neobrađena polja neophodna su za usklađivanje kada se promijeni semantika pružatelja usluga.

Možljivost predmemorije: nadzorne ploče koje objašnjavaju promašaje

Korisna nadzorna ploča predmemorije ne samo da prikazuje ukupne predmemorirane tokene. To bi trebalo pomoći timovima da odgovore: "Koje radno opterećenje kvari prefiks i što se promijenilo?"

Praćenje metrike predmemorije prema:

• stanar;
• radni prostor ili aplikacija;
• model rute;
• davatelj i model;
• verzija predloška upita;
• stabilni raspršivač prefiksa;
• polustabilni raspršivač konteksta;
• API ključ ili račun usluge, gdje je prikladno;
• vremenski prozor, posebno zato što su TTL predmemorije kratki za mnoga radna opterećenja.

Korisne izvedene metrike uključuju:

• Stopa čitanja predmemorije: predmemorirani ulazni tokeni podijeljeni s ukupnim ulaznim tokenima podobnim za predmemoriju.
• Odljev prefiksa: broj različitih stabilnih hashova prefiksa po verziji predloška po satu.
• Odstupanje predloška: promjene pogodaka predmemorije nakon izdavanja predloška.
• Troškovi hladnog pokretanja: potrošnja pisanja u predmemoriju ili unosa bez predmemoriranja za prvi zahtjev u nizu.
• Usporedba rute: stope pogodaka preko ruta davatelja za isto logičko radno opterećenje.

Nemojte zadano pohranjivati neobrađene upite za otklanjanje pogrešaka. Preferiraj hashove, duljine regija, ID-ove predložaka, upozorenja o kanonikalizaciji i redigirane razlike. Ako tim treba dublje otklanjanje pogrešaka, zahtijevajte eksplicitne kontrole pristupa i ograničenja zadržavanja.

Pravila o izolaciji stanara: nemojte dizajnirati za ponovnu upotrebu između stanara

Pretpostavka o najsigurnijem pristupniku je jednostavna: ponašanje koje se može predmemorirati treba biti ograničeno na zakupca. Čak i ako dva zakupca dijele identičan blok javne politike, pristupnik ne bi trebao namjerno usmjeravati ili oblikovati promet kako bi iskoristio ponovnu upotrebu predmemorije između zakupaca.

Konzervativna politika uključuje:

• Usmjeravanje svjesno stanara: usmjerava promet koji se može predmemorirati koristeći granice stanara, radnog prostora i aplikacije.
• Bez dijeljenih prefiksa koji nose tajnu: nikada ne stavljajte tajne stanara, vjerodajnice, privatne dokumente ili podatke specifične za korisnika u dijeljeni prefiks koji se može ponovno koristiti.
• Odvojeni prefiks otisaka prstiju: izračunava otiske prstiju s opsegom stanara uključenim u knjigu pristupnika, čak i ako je prikazani tekst identičan.
• Kontrole na razini organizacije: dopuštaju administratorima da onemoguće značajke predmemorije pružatelja za osjetljiva radna opterećenja.
• Izolacija pružatelja usluga nije značajka proizvoda za preprodaju: tretirajte izolaciju predmemorije pružatelja kao osnovnu zaštitu, a ne kao dopuštenje za izgradnju skupljanja predmemorije među korisnicima.

Predviđanje: kako agenti dugog konteksta postaju sve češći, ponašanje predmemorije postat će dio sigurnosnih pregleda, a ne samo pregleda troškova. Lakše će se upravljati pristupnicima koji mogu dokazati politiku predmemorije s opsegom stanara.

Dodjela naplate: odvojeno čitanje predmemorije, pisanje i uobičajeni tokeni

Brzo predmemoriranje može otežati razumijevanje faktura ako su svi ulazni tokeni prikazani kao jedan broj. Knjiga naplate treba sadržavati najmanje pet kategorija:

1. nekeširani ulazni tokeni;
2. tokeni pisanja u predmemoriju;
3. predmemorija čitanja tokena;
4. izlazni tokeni;
5. naknade TTL-a ili kontrole predmemorije specifične za pružatelja usluga.

Ovo je važno kada jedan pružatelj popusti na čitanje u predmemoriji, drugi drugačije naplaćuje upisivanje u predmemoriju, a treći izlaže dulju TTL opciju. Faktura korisnika trebala bi moći objasniti zašto su dva zahtjeva sa sličnim ukupnim unosom tokena imala različite troškove.

Za interni stornirani iznos, pripišite učinke predmemorije zakupcu i aplikaciji koja je podnijela zahtjev. Izbjegavajte dodjelu prednosti čitanja predmemorije s jednog stanara na drugog. Ako dijeljeni interni platformski tim posjeduje stabilni predložak upita, izvijestite o izvedbi predmemorije na razini predloška odvojeno od faktura zakupca.

Kontrolni popis za linting predmemorije

Prije nego što omogućite provedbu predmemorije, pokrenite predloške upita kroz popis za provjeru linta:

• Upute stabilnog sustava pojavljuju se prije nepostojanog korisničkog unosa.
• Sheme alata sortirane su prema stabilnom ID-u ili nazivu.
• JSON je serijaliziran deterministički.
• U stabilnom prefiksu ne pojavljuju se vremenske oznake, nasumični ID-ovi, ID-ovi zahtjeva ili ID-ovi praćenja.
• Nikakve tajne specifične za korisnika ne pojavljuju se u dijeljenim blokovima za višekratnu upotrebu.
• RAG isječci se postavljaju nakon odjeljaka pravila i alata za višekratnu upotrebu, osim ako ne postoji namjerni razlog da se to ne učini.
• Predlošci upita imaju eksplicitne verzije.
• Izdanja predložaka mogu se povezati s promjenama stope pogodaka predmemorije.
• Kontrole predmemorije pružatelja usluga koriste se samo putem koda adaptera, a ne logike raspršene aplikacije.
• Zapisivanje neobrađenih upita onemogućeno je prema zadanim postavkama ili je zaštićeno strogim pravilima zadržavanja i pristupa.

Plan uvođenja

1. Pripazite prije mijenjanja upita

Započnite prikupljanjem polja korištenja pružatelja usluga i normaliziranih metričkih podataka predmemorije za postojeći promet. Izračunajte otiske prstiju prefiksa za prvih N tokena ili za područja upita definirana pristupnikom. Cilj je pronaći rute velike količine, dugog konteksta s velikim odljevom prefiksa.

2. Klasificirajte radna opterećenja

Grupirajte promet u kategorije: sesije agenta, pomoćnici kodiranja, RAG, automatizacija podrške, analiza dokumenata, skupni poslovi i kratki razgovor. Brzi rad predmemorije obično obraća najviše pažnje na radna opterećenja dugog konteksta i ponovljenog prefiksa. Kratke upute ispod pragova pružatelja usluga možda neće imati koristi.

3. Predstavite graditelje stabilnih prefiksa

Premjestite jedno radno opterećenje s sirove brze konstrukcije na montažu temeljenu na regiji. Održavajte prikazani zahtjev pružatelja semantički ekvivalentnim. Nemojte kombinirati ovu promjenu s migracijom modela, redizajnom alata ili velikim brzim prepisivanjem ili nećete znati što je uzrokovalo promjene metrike.

4. Canary one route

Omogućite kontrole predmemorije za mali dio jednog stanara ili interne aplikacije. Usporedite stopu čitanja predmemorije, odljev prefiksa, vrijeme do prvog tokena, stopu pogreške i kategorije troškova. Izbjegavajte tražiti ušteđevinu dok se računi pružatelja ne usklade s glavnim knjigama pristupnika.

5. Primjenjujte postupno

Nakon kanarinca, upozorenja o dlačicama pretvorite u provjere pravila. Na primjer, prvo upozorite na nestabilan redoslijed alata, a zatim odbacite nove verzije predložaka koji uključuju nepostojane metapodatke u stabilnom prefiksu.

Ustupci

• Veća stopa pogodaka predmemorije u odnosu na fleksibilnost brze: stabilni prefiksi poboljšavaju ponovnu upotrebu, ali će timovi možda morati kasnije premjestiti dinamičke upute ili redizajnirati predloške.
• Nativno predmemoriranje pružatelja usluga u odnosu na prenosivost: upotreba kontrola predmemorije svakog pružatelja može poboljšati ekonomičnost, ali pragovi, TTL-ovi, polja i semantika cijena razlikuju se.
• Uočljivost u odnosu na osjetljivo bilježenje: brze razlike pomažu u otklanjanju pogrešaka, ali hashovi i redigirana dijagnostika su sigurnije zadane postavke.
• Izolacija stanara u odnosu na maksimalnu ponovnu upotrebu: široka ponovna upotreba može izgledati privlačno, ali ponašanje s opsegom stanara sigurnije je i lakše ga je objasniti.
• Dulje zadržavanje u odnosu na troškove i složenost pravila: dulje TTL opcije mogu pomoći agentskim sesijama, ali mogu uvesti drugačija razmatranja o cijenama i kontroli podataka.

Poduzimajući zaključak

Tretirajte brzo predmemoriranje kao problem kontrolne ravnine pristupnika, a ne potvrdni okvir pružatelja usluga. Praktični obrazac je: definirajte stabilna, polustabilna i nestabilna brza područja; prikazati ih deterministički; prilagodite kontrole predmemorije specifične za pružatelja usluga iza jednog sučelja; normalizirati korištenje predmemorije u glavnu knjigu; izložiti dijagnostiku pogotka predmemorije prema zakupcu, aplikaciji, ruti i verziji predloška; i nametnuti pretpostavke s opsegom stanara.

Prvi koristan korak nije prepisivanje. Dodajte vidljivost predmemorije svojim najdužim upitima, identificirajte odljev prefiksa i označite predloške koji uzrokuju najviše promašaja. Nakon što objasnite ponašanje predmemorije, možete je sigurno optimizirati.

Povezana literatura

• izgradite kategorije koje su svjesne predmemorije u knjigu naplate
• pridružite metrike predmemorije sa sigurnim LLM-om vidljivost
• drži kontekst dohvaćanja u opsegu stanara u RAG radnim opterećenjima