Spør hurtigbufferkontroll i en multi-modell API-gateway: stabile prefikser, leietakerisolasjon og cache-hit-analyse

Promptbufring er lett å kaste bort. Et team kan ha en 40 000-token systemforespørsel, verktøyskjema, policyblokk, depotkart eller agentminne som skal kunne gjenbrukes, og deretter sette et tidsstempel, forespørsels-ID, brukernavn, hentekodebit eller randomisert verktøybestilling nær toppen av ledeteksten ved et uhell. Leverandøren ser et annet prefiks, hurtigbufferen er savnet, ventetiden øker og regningen ser forvirrende ut.

I en enkeltleverandørapplikasjon kan du fikse dette i applikasjonsmalen. I en multi-modell gateway er problemet større: hver leverandør avslører forskjellige hurtigbufferkontroller, token-terskler, time-to-live-atferd, bruksfelt og faktureringssemantikk. Gatewayen trenger et bærbart kontrollplanmønster for å sette sammen hurtigbuffersikre meldinger, måle bufferatferd, isolere leietakere og tilskrive kostnader.

Denne artikkelen beskriver en referansearkitektur. Det er ikke en kundecasestudie og krever ikke benchmark-resultater. Fakta nedenfor kommer fra leverandørdokumentasjon og offentlig forskning; designanbefalingene er driftsveiledning på gateway-nivå.

Feilmodus: hurtigbufferbrytende promptsamling

Buffring av ledetekster belønner vanligvis gjentatte ledetekstprefikser. Den eksakte mekanikken varierer fra leverandør til leverandør, men den praktiske implikasjonen er konsistent: hvis fronten av forespørselen endres, lider gjenbruk.

Vanlige bufferbrytere inkluderer:

• Metadata per forespørsel øverst: tidsstempler, sporings-ID-er, økt-ID-er, distribusjons-ID-er eller genererte forespørselsetiketter.
• Brukerspesifikke data i prefikset: navn, kontoattributter, tillatelser eller private preferanser plassert før gjenbrukbare retningslinjer eller verktøyblokker.
• Ustabil verktøyserialisering: verktøyskjemaer som sendes ut i ikke-deterministisk rekkefølge, med skiftende mellomrom eller genererte ID-er.
• Henting av kodebiter for tidlig: RAG-kontekst satt inn før stabile systeminstruksjoner eller delt depotkontekst.
• Maldrift: Små ordendringer utgis ofte uten versjonskontroll eller bufferdiagnostikk.

En gateway kan ikke på magisk vis gjøre et ustabilt prefiks bufret, men det kan håndheve en umiddelbar monteringskontrakt og gjøre cache-misser synlige.

Leverandørfakta å designe rundt

Detaljene er viktige fordi en gateway må normalisere atferd uten å late som om leverandørene er identiske.

• OpenAI: OpenAI har dokumentert promptbufring for det lengste tidligere beregnede ledetekstprefikset. Den begynner på 1 024 tokens, øker i trinn på 128 tokener, og viser bufrede tokentellinger i bruksfelt. OpenAI opplyser også at hurtigbuffere vanligvis tømmes etter 5–10 minutter med inaktivitet og alltid fjernes innen én time etter siste bruk av hurtigbufferen.
• Antropisk: Antropisk hurtigbufring kan bes med cache_control. Dokumentasjonen beskriver cache-matching over ledetekstkomponenter som verktøy, systeminnhold og meldinger opp til blokken merket med cache-kontroll. Anthropic dokumenterer en flyktig cache, inkludert en varighet på 5 minutter og et alternativ på 1 time mot ekstra kostnad.
• Gemini: Google Gemini kontekstbufring avslører antall cache-hit tokens gjennom bruksmetadata som total_cached_tokens, og dokumentasjonen viser minimum antall input tokens etter modell.
• Datakontrollimplikasjon: OpenAIs API-datakontrolldokumentasjon bemerker at utvidet hurtigbufring krever lagring av nøkkel-/verditensorer som applikasjonstilstand i GPU-lokal lagring. Selv når leverandører opprettholder isolasjonsgarantier, bør gatewayer behandle hurtigbufferatferd som sensitiv infrastruktur, ikke som en delt applikasjonsdatalager.
• Forskningssignal: Offentlig forskning har undersøkt om arkitekturer i gateway-stil kan introdusere prompt-caching-sårbarheter som omgår antakelser om cache-isolering på leverandørnivå. Det beviser ikke at en spesifikk gateway er sårbar, men den støtter konservativ design for leietakerisolering.

Anbefaling: implementer bufferkontroll som en gateway-funksjon med eksplisitte retningslinjer, ikke som en utilsiktet bivirkning av gjentatte forespørsler.

En monteringskontrakt med tre regioner

Den viktigste designbeslutningen er å skille stabilt og flyktig innhold før forespørselen når en leverandøradapter.

Region 1: stabilt prefiks

Det stabile prefikset er innhold som forventes å forbli identisk på tvers av mange forespørsler for samme applikasjon, modellrute og forespørselsmalversjon. Eksempler inkluderer:

• instruksjoner for kjernesystemet;
• sikkerhets- og policyblokkeringer;
• verktøyskjemaer;
• statisk produktdokumentasjon;
• depotkart for kodingsagenter;
• faste utdataformatinstruksjoner.

Denne regionen bør være deterministisk. Gatewayen bør bygge den fra versjonerte maler, kanonisert JSON og stabile bestillingsregler. Hvis et verktøyregister er inkludert, sorter verktøy etter stabil verktøy-ID. Hvis JSON-skjemaer er inkludert, serialiser dem med deterministisk nøkkelrekkefølge og ingen genererte tidsstempler.

Region 2: semi-stabil leietaker eller arbeidsområdekontekst

Den semi-stabile regionen endres sjeldnere enn individuelle forespørsler, men deles ikke globalt. Eksempler inkluderer:

• leietakerspesifikke retningslinjer overstyrer;
• Tillatelseslister for verktøy på arbeidsområdenivå;
• kundespesifikk terminologi;
• lagkodingskonvensjoner;
• langvarig prosjektsammenheng.

Denne regionen bør omfatte en leietaker, arbeidsområde eller applikasjonsgrense. Det kan fortsatt være bufret, men gatewayen bør aldri anta at en annen leietaker trygt kan gjenbruke den.

Region 3: flyktig suffiks

Det flyktige suffikset er delen per forespørsel:

• brukermelding;
• hentet utdrag for dette søket;
• gjeldende tidsstempel, hvis det virkelig er nødvendig;
• be om ID og sporingsmetadata, hvis det i det hele tatt er inkludert i ledeteksten;
• kortsiktige samtaler snur;
• resultater fra kjøretidsverktøy.

De fleste cache-misser forårsaket av applikasjonsdesign skjer fordi flyktige suffiksdata ved et uhell plasseres i prefikset. En gateway-sidebygger bør gjøre det vanskelig.

Implementeringsmønster: stabile prefiksbyggere

En praktisk gateway-implementering kan avsløre et hurtigmonteringsgrensesnitt i stedet for å godta én ugjennomsiktig ledetekststreng fra hver applikasjon.

{
  "template_id": "kode-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-kart-8491"
  },
  "semi_stable_context": {
    "workspace_policy_version": "workspace-44-v6"
  },
  "volatile_suffix": {
    "user_message": "Forklar hvorfor denne testen mislykkes...",
    "retrieval_context_ids": ["chunk_7", "chunk_19"],
    "trace_id": "not_inserted_into_prompt"
  }
}

Gatewayen gjengir deretter den leverandørspesifikke forespørselen. Dette gir gatewayen et sted å håndheve regler:

• avvis tidsstempler i stabile prefiksfelt;
• kanonisere verktøyskjemaer;
• hash hver region separat;
• legg ved bufferkontroller der en leverandør støtter dem;
• bevar rask semantikk mens du flytter flyktig materiale senere;
• registreringsmal og prefiksfingeravtrykk for diagnostikk.

For eldre applikasjoner som bare sender råmeldinger, kan gatewayen fortsatt tilby en lint-modus: inspiser meldingsrekkefølgen, beregne prefiksfingeravtrykk og rapporter sannsynlige hurtigbufferbrytere uten å skrive om forespørselen først.

Leverandøradapterlag: normaliser hurtigbufferbruken uten å skjule forskjeller

En multi-modell gateway bør ikke eksponere tre urelaterte cache-rapporter for utviklere. Det bør heller ikke flate ut leverandørspesifikk økonomi så aggressivt at fakturaer blir umulige å forklare.

Opprett en normalisert hurtigbufferbok med felt som:

{
  "request_id": "req_abc",
  "tenant_id": "tenant_123",
  "app_id": "kode-agent",
  "route": "coding-long-context",
  "provider": "leverandørnavn",
  "model": "model_id",
  "template_id": "kode-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": "lagret_eller_redacted_provider_usage"
  }
}

Adapteren kartlegger leverandørbruken i normaliserte kategorier:

• Ubufrede inndatatokens: tokens behandlet uten en bufferlese-rabatt eller cache-lest regnskap.
• Cache-skrive-tokens:-tokens som opprettet eller oppdatert en bufferoppføring på leverandørsiden når leverandøren rapporterer denne forskjellen.
• Cache-lese-tokens:-tokener servert fra buffer eller regnet som bufret av leverandørbruksmetadata.
• Utdatatokens: genererte tokens, som skal forbli atskilt fra hurtigbufferøkonomi.
• TTL-alternativ: den valgte buffervarighetsklassen der en leverandør viser et valg.

Anbefaling: lagre rå leverandørbruk i en redigert, skjemaversjonsform sammen med normaliserte felt. Normalisering er nyttig for dashbord; råfelt er nødvendig for avstemming når leverandørsemantikk endres.

Cache observerbarhet: dashbord som forklarer glipp

Et nyttig hurtigbufferdashbord gjør mer enn å vise totalt bufrede tokens. Det bør hjelpe teamene med å svare: "Hvilken arbeidsmengde bryter prefikset, og hva endret seg?"

Spor bufferberegninger ved å:

• leietaker;
• arbeidsområde eller app;
• modellrute;
• leverandør og modell;
• forespørselsmalversjon;
• stabil prefiks-hash;
• halvstabil konteksthash;
• API-nøkkel eller tjenestekonto, der det er aktuelt;
• tidsvindu, spesielt fordi cache TTL-er er korte for mange arbeidsbelastninger.

Nyttige utledede beregninger inkluderer:

• Cache-lesefrekvens: bufrede inndatatokener delt på totalt antall inputtokener som er kvalifisert for bufring.
• Prefiks-churn: antall distinkte stabile prefiks-hasher per malversjon per time.
• Maldrift: cache-hit endres etter en malutgivelse.
• Kallstartkostnad: cache-skriving eller ubufrede inndataforbruk for den første forespørselen i en serie.
• Rutesammenligning: trefffrekvens på tvers av leverandørruter for samme logiske arbeidsbelastning.

Ikke som standard å lagre rå meldinger for feilsøking. Foretrekk hasher, regionlengder, mal-ID-er, kanoniseringsadvarsler og redigerte diff. Hvis et team trenger dypere feilsøking, må du kreve eksplisitte tilgangskontroller og oppbevaringsgrenser.

Retningslinjer for isolering av leietakere: ikke design for gjenbruk på tvers av leietakere

Den sikreste gateway-antagelsen er enkel: bufret atferd bør være leietaker-omfanget. Selv om to leietakere deler en identisk offentlig policy-blokk, bør ikke gatewayen med vilje rute eller forme trafikk for å utnytte gjenbruk av buffer på tvers av leietakere.

En konservativ politikk inkluderer:

• Leietakerbevisst ruting: rute bufret trafikk ved hjelp av leietaker-, arbeidsområde- og applikasjonsgrenser.
• Ingen delte hemmelige prefikser: plasser aldri leietakerhemmeligheter, legitimasjon, private dokumenter eller brukerspesifikke data i et gjenbrukbart delt prefiks.
• Separate prefiksfingeravtrykk: beregne fingeravtrykk med leietakeromfang inkludert i gatewayens hovedbok, selv om den gjengitte teksten er identisk.
• Kontroller på organisasjonsnivå: lar administratorer deaktivere leverandørens hurtigbufferfunksjoner for sensitive arbeidsbelastninger.
• Isolering av leverandør er ikke en produktfunksjon som skal videreselges: behandle leverandørens bufferisolering som en grunnleggende beskyttelse, ikke som tillatelse til å bygge buffersamling på tvers av kunder.

Forutsigelse: etter hvert som agenter med lang kontekst blir mer vanlig, vil bufferoppførsel bli en del av sikkerhetsvurderinger, ikke bare kostnadsvurderinger. Gatewayer som kan bevise leietaker-omfanget bufferpolitikk vil være enklere å styre.

Faktureringsattribusjon: separat buffer for lesing, skriving og vanlige tokens

Promptbufring kan gjøre fakturaer vanskeligere å forstå hvis alle inndatasymboler vises som ett tall. Faktureringsreskontroen bør beholde minst fem kategorier:

1. ubufrede inndatatokener;
2. cache skrive-tokens;
3. bufferlese-tokens;
4. utdata-tokens;
5. leverandørspesifikke TTL- eller bufferkontrollkostnader.

Dette har betydning når en leverandør gir rabatt på hurtigbufrede lesinger, en annen tar forskjellig betalt for cacheskriving, og en annen viser et lengre TTL-alternativ. En kundefaktura skal kunne forklare hvorfor to forespørsler med lignende totale input tokens hadde forskjellige kostnader.

For intern tilbakeføring, tilskriv hurtigbuffereffekter til leieren og applikasjonen som sendte forespørselen. Unngå å tildele en cache-lest fordel fra en leietaker til en annen. Hvis et delt internt plattformteam eier den stabile forespørselsmalen, rapporter bufferytelse på malnivå separat fra leietakerfakturaer.

Sjekkliste for cache-linting

Før du aktiverer bufferhåndhevelse, kjører du ledetekstmaler gjennom en sjekkliste for lo:

• Stabile systeminstruksjoner vises før flyktige brukerinndata.
• Verktøyskjemaer er sortert etter stabil ID eller navn.
• JSON er serialisert deterministisk.
• Ingen tidsstempler, tilfeldige ID-er, forespørsel-ID-er eller sporings-ID-er vises i det stabile prefikset.
• Ingen brukerspesifikke hemmeligheter vises i delte gjenbrukbare blokker.
• RAG-kodebiter plasseres etter gjenbrukbare policy- og verktøyseksjoner med mindre det er en bevisst grunn til å ikke gjøre det.
• Spørsmålsmaler har eksplisitte versjoner.
• Malutgivelser kan korreleres med endringer i cache-hit-rate.
• Leverandørbufferkontroller brukes bare gjennom adapterkode, ikke spredt applikasjonslogikk.
• Raw prompt-logging er deaktivert som standard eller beskyttet av strenge oppbevaring- og tilgangsregler.

Utrullingsplan

1. Vær oppmerksom før du endrer meldinger

Start med å samle leverandørbruksfelt og normaliserte bufferberegninger for eksisterende trafikk. Beregn prefiksfingeravtrykk for de første N tokens eller for gateway-definerte ledetekstområder. Målet er å finne ruter med høyt volum og lang kontekst med høy prefiks-churn.

2. Klassifiser arbeidsbelastninger

Grupper trafikk i kategorier: agentøkter, kodeassistenter, RAG, støtteautomatisering, dokumentanalyse, batchjobber og kort chat. Hurtigbufferarbeid gir vanligvis mest oppmerksomhet til arbeidsbelastninger med lang kontekst og gjentatte prefikser. Korte meldinger under leverandørterskelverdiene er kanskje ikke til nytte.

3. Introduser stabile prefiksbyggere

Flytt én arbeidsbelastning fra rå promptkonstruksjon til regionbasert montering. Hold den gjengitte leverandørforespørselen semantisk likeverdig. Ikke kombiner denne endringen med modellmigrering, redesign av verktøy eller store omskrivinger av spørsmål, ellers vil du ikke vite hva som forårsaket metriske endringer.

4. Kanariøyene én rute

Aktiver bufferkontroller for en liten del av én leietaker eller intern app. Sammenlign cache-lesefrekvens, prefiks-churn, tid til første token, feilrate og kostnadskategorier. Unngå å kreve besparelser før leverandørens regninger forenes med gateway-reskontro.

5. Håndheve gradvis

Etter kanarifuglen, gjør loadvarsler om til policysjekker. Advar for eksempel om ustabil verktøyrekkefølge først, og avvis deretter nye malversjoner som inkluderer flyktige metadata i det stabile prefikset.

Avveininger

• Høyere trefffrekvens i hurtigbufferen kontra forespørselsfleksibilitet: Stabile prefikser forbedrer gjenbruk, men team kan trenge å flytte dynamiske instruksjoner senere eller redesigne maler.
• Provider-native caching vs. portabilitet: Bruk av hver leverandørs cache-kontroller kan forbedre økonomien, men terskler, TTL-er, felt og prissemantikk varierer.
• Observbarhet vs. sensitiv logging: ledetekstforskjeller hjelper til med å feilsøke feil, men hasher og redigert diagnostikk er sikrere standardinnstillinger.
• Isolering av leietakere kontra maksimal gjenbruk: bred gjenbruk kan se attraktivt ut, men atferd med leietaker er tryggere og enklere å forklare.
• Lengere oppbevaring kontra kostnad og policykompleksitet: Lengre TTL-alternativer kan hjelpe agentøkter, men kan introdusere ulike pris- og datakontrollhensyn.

Aktiv konklusjon

Behandle promptbufring som et gateway-kontrollplanproblem, ikke en leverandøravmerkingsboks. Det praktiske mønsteret er: definer stabile, semi-stabile og flyktige promptregioner; gjengi dem deterministisk; tilpasse leverandørspesifikke hurtigbufferkontroller bak ett grensesnitt; normalisere cache-bruk til en hovedbok; eksponer cache-hit diagnostikk etter leietaker, app, rute og malversjon; og håndheve forutsetninger med leietakeromfang.

Det første nyttige trinnet er ikke en omskrivning. Legg til cache-observabilitet til de lengste ledetekstene dine, identifiser prefiksavbrudd, og lo malene som forårsaker flest feil. Når du kan forklare cache-atferd, kan du trygt optimalisere den.

Relatert lesing

• bygg cache-bevisste kategorier inn i faktureringsreskontrobli med i cache-beregninger med sikker LLM-observerbarhet
• behold hentingskonteksten med leietakeromfang i RAG-arbeidsbelastninger