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

Brzo 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 je prije uputa stabilnog sustava ili konteksta zajedničkog repozitorija.
• Odstupanje predloška: male izmjene teksta koje se često objavljuju bez dijagnostike verzija ili predmemorije.

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

Činjenice o pružatelju usluga oko kojih treba dizajnirati

Detalji su važni 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: predmemoriranje konteksta Google Gemini izlaže broj tokena za predmemoriju putem metapodataka o korištenju kao što je total_cached_tokens, a njegova dokumentacija navodi minimalne brojeve tokena za unos po modelu.
• Implikacija kontrole podataka: OpenAI-jeva dokumentacija o kontroli podataka API-ja 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, kanonikaliziranog JSON-a i stabilnih pravila naručivanja. Ako je uključen registar alata, sortirajte alate prema stabilnom ID-u alata. Ako su uključene JSON sheme, serijalizirajte ih determinističkim redoslijedom ključeva i bez generiranih vremenskih oznaka.

Regija 2: polustabilni zakupac ili kontekst radnog prostora

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

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

Ova regija treba biti ograničena na granicu stanara, radnog prostora ili aplikacije. Možda se i dalje može 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;
• preuzete isječke 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;
• kratkotrajni razgovor;
• 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 otkriti sučelje brzog sklapanja umjesto prihvaćanja jednog neprozirnog niza upita iz svake aplikacije.

{
  "template_id": "code-agent-v3",
  "stanar_id": "stanar_123",
  "ruta": "kodiranje-dugog-konteksta",
  "stabilni_prefiks": {
    "system_policy_version": "2026-08-01",
    "toolset_version": "tools-v12",
    "repo_context_version": "repo-map-8491"
  },
  "polu_stabilan_kontekst": {
    "workspace_policy_version": "workspace-44-v6"
  },
  "volatile_suffix": {
    "user_message": "Objasnite zašto ovaj test ne uspijeva...",
    "retrieval_context_ids": ["chunk_7", "chunk_19"],
    "trace_id": "nije_umetnuto_u_prompt"
  }
}

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

• odbiti vremenske oznake u stabilnim poljima prefiksa;
• kanonizirati sheme alata;
• raspršiti svaku regiju zasebno;
• priložiti kontrole predmemorije tamo gdje ih pružatelj podržava;
• očuvati brzu semantiku pri kasnijem premještanju nepostojanog materijala;
• zabilježite predložak 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 moguće razbijače predmemorije bez ponovnog pisanja upita.

Sloj adaptera pružatelja: normalizirajte korištenje predmemorije bez skrivanja razlika

Pristupnik s više modela ne bi trebao izlagati tri nepovezana izvješća o predmemoriji 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",
  "stanar_id": "stanar_123",
  "app_id": "agent koda",
  "ruta": "kodiranje-dugog-konteksta",
  "provider": "provider_name",
  "model": "id_modela",
  "template_id": "code-agent-v3",
  "stable_prefix_hash": "sha256:...",
  "polu_stabilni_hash": "sha256:...",
  "input_tokens_total": 58200,
  "input_tokens_uncached": 8200,
  "cache_write_tokens": 50000,
  "cache_read_tokens": 0,
  "output_tokens": 1300,
  "cache_ttl_class": "efemerno_5m",
  "provider_cache_fields": {
    "raw_field_names": "stored_or_redacted_provider_usage"
  }
}

Adapter preslikava upotrebu pružatelja u normalizirane kategorije:

• Ulazni tokeni bez predmemorije: 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 iz predmemorije: tokeni koji se poslužuju iz predmemorije ili se računaju kao predmemorirani pomoću metapodataka o korištenju pružatelja usluga.
• 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 semantika davatelja promijeni.

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?"

Prati metriku predmemorije prema:

• stanar;
• radni prostor ili aplikacija;
• model rute;
• pružatelj i model;
• verzija predloška upita;
• stabilni hash prefiksa;
• polustabilni hash 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 koji ispunjavaju uvjete za predmemoriju.
• Odljev prefiksa: broj različitih stabilnih raspršivanja 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 ruta: stope pogodaka kroz rute pružatelja usluga 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 izolacije zakupca: nemojte dizajnirati za ponovnu upotrebu između zakupaca

Pretpostavka o najsigurnijem pristupniku je jednostavna: ponašanje koje se može predmemorirati treba biti u opsegu stanara. Č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 s obzirom na zakupca: usmjerite promet koji se može predmemorirati koristeći granice zakupca, radnog prostora i aplikacije.
• Bez dijeljenih tajnih prefiksa: nikada ne stavljajte tajne stanara, vjerodajnice, privatne dokumente ili podatke specifične za korisnika u višekratni zajednički prefiks.
• Odvojeni prefiksni otisci prstiju: izračunajte 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 nije značajka proizvoda za preprodaju: tretirajte izolaciju predmemorije pružatelja kao osnovnu zaštitu, a ne kao dopuštenje za izgradnju skupljanja predmemorije za više korisnika.

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 normalni 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. spremiti tokene pisanja;
3. spremiti tokene čitanja;
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 iz predmemorije, drugi naplaćuje drugačije za pisanje 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 efekte predmemorije zakupcu i aplikaciji koja je podnijela zahtjev. Izbjegavajte dodjelu prednosti čitanja predmemorije s jednog stanara na drugog. Ako zajednički interni tim platforme 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 zajedničkim 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 razbacane 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. Promatrajte prije mijenjanja upita

Započnite prikupljanjem polja korištenja pružatelja usluga i normaliziranih mjernih podataka predmemorije za postojeći promet. Izračunajte otiske 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.

Kompromisi

• Veća stopa pogodaka predmemorije u odnosu na brzu fleksibilnost: stabilni prefiksi poboljšavaju ponovnu upotrebu, ali će timovi možda morati kasnije premjestiti dinamičke upute ili redizajnirati predloške.
• Izvorno predmemoriranje pružatelja usluga u odnosu na prenosivost: upotreba kontrola predmemorije svakog pružatelja može poboljšati ekonomiju, 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 u opsegu 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 agentovim sesijama, ali mogu uvesti drugačija razmatranja o cijenama i kontroli podataka.

Zaključak koji se može poduzeti

Promptno predmemoriranje smatrajte problemom kontrolne razine pristupnika, a ne potvrdnim okvirom 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 pogodaka predmemorije po 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.

Povezano čitanje

• ugradite kategorije koje su svjesne predmemorije u knjigu naplate
• pridruži metriku predmemorije sa sigurnom mogućnošću promatranja LLM
• zadrži kontekst dohvaćanja u opsegu stanara u RAG radnim opterećenjima