Control de la memòria cau sol·licitada en una passarel·la d'API multimodel: prefixos estables, aïllament de llogaters i analítiques d'impactes de memòria cau

La memòria cau ràpida és fàcil de perdre. Un equip pot tenir una indicació del sistema de 40.000 fitxes, un esquema d'eina, un bloc de polítiques, un mapa de dipòsits o una memòria d'agent que s'haurien de reutilitzar i, a continuació, posar accidentalment una marca de temps, un identificador de sol·licitud, un nom d'usuari, un fragment de recuperació o una comanda d'eines aleatòries a prop de la part superior de la sol·licitud. El proveïdor veu un prefix diferent, la memòria cau s'ha perdut, la latència augmenta i la factura sembla confusa.

En una aplicació d'un sol proveïdor, podeu solucionar-ho dins de la plantilla de l'aplicació. En una passarel·la multimodel, el problema és més gran: cada proveïdor exposa diferents controls de memòria cau, llindars de testimoni, comportament de temps de vida, camps d'ús i semàntica de facturació. La passarel·la necessita un patró de pla de control portàtil per reunir avisos segurs per a la memòria cau, mesurar el comportament de la memòria cau, aïllar els inquilins i atribuir el cost.

Aquest article descriu una arquitectura de referència. No és un estudi de cas de client i no reclama resultats de referència. Els fets següents provenen de la documentació del proveïdor i la investigació pública; les recomanacions de disseny són una guia operativa a nivell de passarel·la.

El mode d'error: conjunt d'indicadors de trencament de memòria cau

L'emmagatzematge de sol·licituds a la memòria cau generalment recompensa els prefixos de sol·licituds repetits. La mecànica exacta varia segons el proveïdor, però la implicació pràctica és coherent: si la part frontal de l'indicador canvia, la reutilització es veu afectada.

Els trencadors de memòria cau habituals inclouen:

• Metadades per sol·licitud a la part superior: segells de temps, identificadors de traça, identificadors de sessió, identificadors de desplegament o etiquetes de sol·licitud generades.
• Dades específiques de l'usuari al prefix: noms, atributs del compte, permisos o preferències privades situats abans dels blocs d'eines o polítiques reutilitzables.
• Serialització d'eines inestable: esquemes d'eines emesos en ordre no determinista, amb espais en blanc canviants o identificadors generats.
• Fragments de recuperació massa aviat: el context RAG s'ha inserit abans de les instruccions estables del sistema o el context del dipòsit compartit.
• Deriva de la plantilla: petits canvis de text publicats amb freqüència sense versions ni diagnòstic de memòria cau.

Una passarel·la no pot fer que un prefix inestable es pugui posar en memòria cau de manera màgica, però pot fer complir un contracte de muntatge ràpid i fer visibles les faltes de memòria cau.

Proporcioneu dades per dissenyar

Els detalls són importants perquè una passarel·la ha de normalitzar el comportament sense pretendre que els proveïdors siguin idèntics.

• OpenAI: l'OpenAI ha documentat l'emmagatzematge a la memòria cau d'indicadors per al prefix d'indicadors més llarg que s'ha calculat prèviament. Comença amb 1.024 fitxes, augmenta en increments de 128 fitxes i exposa els recomptes de testimonis en memòria cau als camps d'ús. L'OpenAI també indica que les memòries cau d'indicadors s'esborren normalment després de 5-10 minuts d'inactivitat i sempre s'eliminen dins d'una hora després de l'últim ús de la memòria cau.
• Antròpic: la memòria cau d'indicadors antròpics es pot sol·licitar amb cache_control. La seva documentació descriu la concordança de memòria cau sobre components d'indicadors com ara eines, contingut del sistema i missatges fins al bloc marcat amb control de memòria cau. Anthropic documenta una memòria cau efímera, que inclou una durada de 5 minuts i una opció d'1 hora amb un cost addicional.
• Gemini: la memòria cau del context de Google Gemini exposa els recomptes de testimonis d'accés a la memòria cau mitjançant metadades d'ús com ara total_cached_tokens, i la seva documentació enumera els recomptes mínims de testimonis d'entrada per model.
• Implicació del control de dades: la documentació de control de dades de l'API d'OpenAI assenyala que l'emmagatzematge en memòria cau d'indicadors ampliat requereix emmagatzemar tensors de clau/valor com a estat de l'aplicació a l'emmagatzematge local de la GPU. Fins i tot quan els proveïdors mantenen garanties d'aïllament, les passarel·les haurien de tractar el comportament de la memòria cau com una infraestructura sensible, no com un magatzem de dades d'aplicacions compartit.
• Señal d'investigació: la investigació pública ha examinat si les arquitectures d'estil de passarel·la poden introduir vulnerabilitats d'emmagatzematge en memòria cau d'avís que eviten els supòsits d'aïllament de la memòria cau a nivell de proveïdor. Això no demostra que una passarel·la específica sigui vulnerable, però admet un disseny conservador d'aïllament dels inquilins.

Recomanació: implementeu el control de la memòria cau com una funció de passarel·la amb polítiques explícites, no com un efecte secundari accidental de les sol·licituds repetides.

Un contracte de muntatge ràpid de tres regions

La decisió de disseny més important és separar el contingut estable i volàtil abans que la sol·licitud arribi a un adaptador del proveïdor.

Regió 1: prefix estable

El prefix estable és el contingut que s'espera que es mantingui idèntic en moltes sol·licituds per a la mateixa aplicació, la mateixa ruta de model i la mateixa versió de plantilla de sol·licitud. Alguns exemples inclouen:

• instruccions del sistema bàsic;
• blocs de seguretat i polítiques;
• esquemes d'eines;
• documentació estàtica del producte;
• mapes de dipòsit per a agents de codificació;
• instruccions de format de sortida fixes.

Aquesta regió hauria de ser determinista. La passarel·la l'hauria de crear a partir de plantilles versionades, JSON canonitzat i regles d'ordenació estables. Si s'inclou un registre d'eines, ordena les eines per ID d'eina estable. Si s'inclouen esquemes JSON, serialitzeu-los amb un ordre de claus determinista i sense marca de temps generada.

Regió 2: llogater semiestable o context d'espai de treball

La regió semiestable canvia menys sovint que les sol·licituds individuals, però no es comparteix globalment. Alguns exemples inclouen:

• anul·lació de polítiques específiques de l'arrendatari;
• llistes permeses d'eines a nivell d'espai de treball;
• terminologia específica del client;
• Convencions de codificació d'equip;
• Context de projecte de llarga durada.

Aquesta regió s'ha de limitar a un inquilí, un espai de treball o un límit d'aplicació. És possible que encara es pugui guardar a la memòria cau, però la passarel·la mai hauria de suposar que un altre inquilí el pot reutilitzar de manera segura.

Regió 3: sufix volàtil

El sufix volàtil és la part per sol·licitud:

• missatge de l'usuari;
• s'han recuperat fragments d'aquesta consulta;
• marca de temps actual, si és realment necessari;
• identificador de sol·licitud i metadades de traça, si s'inclouen a la sol·licitud;
• torns de conversa a curt termini;
• resultats de l'eina en temps d'execució.

La majoria dels errors de memòria cau causats pel disseny de l'aplicació es produeixen perquè les dades de sufix volàtils es col·loquen accidentalment al prefix. Un constructor de passarel·la hauria de dificultar-ho.

Patró d'implementació: creadors de prefix estable

Una implementació pràctica de passarel·la pot exposar una interfície de conjunt d'indicadors en lloc d'acceptar una cadena d'indicadors opaca de cada aplicació.

{
  "template_id": "code-agent-v3",
  "tenant_id": "arrendatari_123",
  "route": "codificació-long-context",
  "prefix_estable": {
    "system_policy_version": "2026-08-01",
    "toolset_version": "eines-v12",
    "repo_context_version": "repo-map-8491"
  },
  "semi_stable_context": {
    "workspace_policy_version": "workspace-44-v6"
  },
  "sufix_volatil": {
    "user_message": "Expliqui per què falla aquesta prova...",
    "retrieval_context_ids": ["part_7", "part_19"],
    "trace_id": "not_inserted_into_prompt"
  }
}

A continuació, la passarel·la presenta la sol·licitud específica del proveïdor. Això dóna a la passarel·la un lloc per fer complir les regles:

• rebutja les marques de temps als camps de prefix estables;
• canonitzar esquemes d'eines;
• agrega cada regió per separat;
• adjuntar controls de memòria cau quan un proveïdor els admet;
• preservar la semàntica ràpida mentre es mou material volàtil més tard;
• enregistreu la plantilla i les empremtes digitals de prefix per al diagnòstic.

Per a les aplicacions heretades que només envien missatges en brut, la passarel·la encara pot proporcionar un mode de pelusa: inspeccioneu l'ordre dels missatges, calculeu les empremtes digitals del prefix i informeu de possibles interrupcions de la memòria cau sense reescriure la sol·licitud inicialment.

Capa d'adaptador del proveïdor: normalitzeu l'ús de la memòria cau sense amagar diferències

Una passarel·la multimodel no hauria d'exposar tres informes de memòria cau no relacionats als desenvolupadors. Tampoc hauria d'aplanar l'economia específica del proveïdor de manera tan agressiva que les factures siguin impossibles d'explicar.

Creeu un llibre de memòria cau normalitzat amb camps com ara:

{
  "request_id": "req_abc",
  "tenant_id": "arrendatari_123",
  "app_id": "agent de codi",
  "route": "codificació-long-context",
  "proveïdor": "nom_proveïdor",
  "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": "efímer_5m",
  "provider_cache_fields": {
    "raw_field_names": "ús_emmagatzemat_o_redacted_provider_usage"
  }
}

L'adaptador mapeja l'ús del proveïdor en categories normalitzades:

• Fitxas d'entrada sense memòria cau: testimonis processats sense descompte de lectura de memòria cau ni comptabilitat de lectura de memòria cau.
• Tokens d'escriptura de la memòria cau: testimonis que han creat o actualitzat una entrada de memòria cau del proveïdor quan el proveïdor informa d'aquesta distinció.
• Tokens de lectura de la memòria cau: testimonis que es publiquen des de la memòria cau o que es compten com a memòria cau per les metadades d'ús del proveïdor.
• Fitxas de sortida: testimonis generats, que haurien de romandre separats de l'economia de la memòria cau d'avís.
• Opció TTL: la classe de durada de la memòria cau seleccionada on un proveïdor exposa una opció.

Recomanació: emmagatzemeu l'ús del proveïdor en brut en un formulari redactat i amb versions d'esquema juntament amb camps normalitzats. La normalització és útil per als quadres de comandament; els camps en brut són necessaris per a la conciliació quan la semàntica del proveïdor canvia.

Observabilitat de la memòria cau: taulers que expliquen els errors

Un tauler de control de memòria cau útil fa més que mostrar el total de fitxes de memòria cau. Hauria d'ajudar els equips a respondre: "Quina càrrega de treball trenca el prefix i què ha canviat?"

Feu un seguiment de les mètriques de la memòria cau mitjançant:

• arrendatari;
• espai de treball o aplicació;
• model de ruta;
• proveïdor i model;
• versió de la plantilla sol·licitada;
• hash de prefix estable;
• hash de context semiestable;
• Clau de l'API o compte de servei, si escau;
• finestra de temps, sobretot perquè els TTL de la memòria cau són curts per a moltes càrregues de treball.

Les mètriques derivades útils inclouen:

• Percentatge de lectura de la memòria cau: testimonis d'entrada a la memòria cau dividits pel total de testimonis d'entrada aptes per a la memòria cau.
• Desactivació del prefix: nombre de hashes de prefix estables diferents per versió de plantilla per hora.
• Deriva de la plantilla: canvis a la memòria cau després d'un llançament de la plantilla.
• Cost d'inici en fred: la despesa d'escriptura de la memòria cau o d'entrada sense memòria cau per a la primera sol·licitud d'una ràfega.
• Comparació de rutes: percentatges d'èxits a les rutes del proveïdor per a la mateixa càrrega de treball lògica.

No emmagatzemeu per defecte les indicacions en brut per a la depuració. Preferiu els hash, les longituds de regió, els identificadors de plantilles, els avisos de canonització i les diferències redactades. Si un equip necessita una depuració més profunda, requereix controls d'accés explícits i límits de retenció.

Política d'aïllament d'inquilins: no dissenyeu per a la reutilització entre inquilins

La hipòtesi de la passarel·la més segura és senzilla: el comportament de la memòria cau s'hauria d'abastar l'inquilí. Fins i tot si dos inquilins comparteixen un bloc de política pública idèntic, la passarel·la no hauria d'encaminar ni donar forma intencionada al trànsit per aprofitar la reutilització de la memòria cau entre arrendataris.

Una política conservadora inclou:

• Enrutament conscient de l'inquilí: encamina el trànsit que es pot guardar en memòria cau mitjançant els límits de l'inquilí, l'espai de treball i l'aplicació.
• Sense prefixos compartits que porten secrets: mai col·loqueu secrets d'inquilí, credencials, documents privats o dades específiques d'usuari en un prefix compartit reutilitzable.
• Empremtes dactilars de prefix separades: calculeu les empremtes dactilars amb l'àmbit de l'arrendatari inclòs al llibre de la passarel·la, encara que el text renderitzat sigui idèntic.
• Controls a nivell d'organització: permeten als administradors desactivar les funcions de memòria cau del proveïdor per a càrregues de treball sensibles.
• L'aïllament del proveïdor no és una característica del producte per revendre: tracteu l'aïllament de la memòria cau del proveïdor com una protecció bàsica, no com un permís per crear una agrupació de memòria cau entre clients.

Predicció: a mesura que els agents de context llarg siguin més habituals, el comportament de la memòria cau formarà part de les revisions de seguretat, no només de les revisions de costos. Les passarel·les que puguin demostrar la política de memòria cau a l'abast dels inquilins seran més fàcils de governar.

Atribució de facturació: lectura, escriptura i testimonis normals de la memòria cau separades

La memòria cau ràpida pot dificultar la comprensió de les factures si tots els testimonis d'entrada es mostren com un sol número. El llibre de facturació ha de conservar almenys cinc categories:

1. indicadors d'entrada sense memòria cau;
2. cache fitxes d'escriptura;
3. mesos de lectura de la memòria cau;
4. indicadors de sortida;
5. Càrrecs de control de memòria cau o TTL específics del proveïdor.

Això importa quan un proveïdor descompta les lectures de la memòria cau, un altre cobra de manera diferent per les escriptures de la memòria cau i un altre exposa una opció TTL més llarga. Una factura de client hauria de poder explicar per què dues sol·licituds amb testimonis d'entrada totals similars tenien costos diferents.

Per a la devolució interna, atribuïu efectes de memòria cau a l'inquilí i a l'aplicació que ha fet la sol·licitud. Eviteu assignar un benefici de lectura de memòria cau d'un inquilí a un altre. Si un equip de plataforma interna compartida és propietari de la plantilla de sol·licitud estable, informeu del rendiment de la memòria cau a nivell de plantilla per separat de les factures dels inquilins.

Llista de comprovació de la memòria cau

Abans d'activar l'aplicació de la memòria cau, executeu plantilles de sol·licitud mitjançant una llista de verificació de pelusa:

• Les instruccions estables del sistema apareixen abans de l'entrada volàtil de l'usuari.
• Els esquemes d'eines s'ordenen per identificador o nom estable.
• JSON es serialitza de manera determinística.
• No apareixen marques de temps, identificadors aleatoris, identificadors de sol·licituds ni identificadors de traça al prefix estable.
• No apareix cap secret específic d'usuari als blocs reutilitzables compartits.
• Els fragments RAG es col·loquen després de les seccions d'eines i polítiques reutilitzables, tret que hi hagi una raó deliberada per no fer-ho.
• Les plantilles de sol·licitud tenen versions explícites.
• Les versions de les plantilles es poden correlacionar amb els canvis de la taxa d'accés a la memòria cau.
• Els controls de memòria cau del proveïdor només s'utilitzen mitjançant el codi de l'adaptador, no la lògica d'aplicació dispersa.
• El registre d'indicacions en brut està desactivat de manera predeterminada o està protegit per regles estrictes de retenció i accés.

Pla de llançament

1. Observeu abans de canviar les indicacions

Comenceu recopilant camps d'ús del proveïdor i mètriques de memòria cau normalitzades per al trànsit existent. Calculeu les empremtes dactilars de prefix per als primers N fitxes o per a les regions d'indicadors definides per la passarel·la. L'objectiu és trobar rutes de gran volum i de context llarg amb un alt prefix.

2. Classifica les càrregues de treball

Agrupa el trànsit en categories: sessions d'agent, assistents de codificació, RAG, automatització de suport, anàlisi de documents, treballs per lots i xat breu. El treball de memòria cau ràpida normalment presta més atenció a les càrregues de treball de context llarg i de prefixos repetits. Les sol·licituds breus per sota dels llindars del proveïdor poden no beneficiar-se.

3. Introdueix els creadors de prefix estable

Mou una càrrega de treball de la construcció d'indicadors en brut al muntatge basat en la regió. Mantingueu la sol·licitud del proveïdor representada semànticament equivalent. No combini aquest canvi amb la migració del model, el redisseny de l'eina o les reescriptures importants d'indicadors, o no sabràs què ha causat els canvis de mètriques.

4. Canary one route

Activeu els controls de memòria cau per a una petita part d'un inquilí o d'una aplicació interna. Compareu la taxa de lectura de la memòria cau, l'abandonament del prefix, el temps fins al primer testimoni, la taxa d'error i les categories de cost. Eviteu reclamar estalvis fins que les factures del proveïdor no es conciliin amb els llibres de la passarel·la.

5. Aplicar gradualment

Després del canari, converteix les advertències de pelusa en comprovacions de polítiques. Per exemple, primer aviseu sobre l'ordre d'eina inestable i, a continuació, rebutgeu les noves versions de plantilles que incloguin metadades volàtils al prefix estable.

Compartiments

• Percentatge d'èxits de la memòria cau més alt en comparació amb la flexibilitat de la sol·licitud: els prefixos estables milloren la reutilització, però és possible que els equips hagin de moure instruccions dinàmiques més tard o redissenyar les plantilles.
• Memòria cau nativa del proveïdor vs. portabilitat: l'ús dels controls de memòria cau de cada proveïdor pot millorar l'economia, però els llindars, els TTL, els camps i la semàntica de preus són diferents.
• Observabilitat versus registre sensible: les diferències de sol·licitud ajuden a depurar errors, però els hash i els diagnòstics redactats són els valors predeterminats més segurs.
• Aïllament dels inquilins versus reutilització màxima: la reutilització àmplia pot semblar atractiva, però el comportament de l'abast dels inquilins és més segur i més fàcil d'explicar.
• Retenció més llarga en comparació amb el cost i la complexitat de la política: les opcions TTL més llargues poden ajudar a les sessions dels agents, però poden introduir diferents consideracions de preus i control de dades.

Conclusió accionable

Traiteu la memòria cau d'indicadors com un problema del pla de control de la passarel·la, no com una casella de selecció del proveïdor. El patró pràctic és: definir regions ràpides estables, semiestables i volàtils; representar-los de manera determinista; adaptar els controls de memòria cau específics del proveïdor darrere d'una interfície; normalitzar l'ús de la memòria cau en un registre; exposar els diagnòstics de la memòria cau per inquilí, aplicació, ruta i versió de la plantilla; i fer complir els supòsits de l'abast dels inquilins.

El primer pas útil no és una reescriptura. Afegiu l'observabilitat de la memòria cau a les vostres sol·licituds més llargues, identifiqueu l'abandonament del prefix i deixeu anar les plantilles que causen més errors. Un cop pugueu explicar el comportament de la memòria cau, podeu optimitzar-lo de manera segura.

Lectura relacionada

• creeu categories conscients de la memòria cau al llibre de facturació
• href="https://model-gate.com/ca/blog/llm-observability-multi-model-api-gateway-traces-token-ledgers-safe-prompt-logging-9/">uneix les mètriques de memòria cau amb una observabilitat segura de LLM
• mantenir el context de recuperació a l'abast de l'inquilí a les càrregues de treball RAG