Prompt caching en OpenAI, Anthropic y Gemini: arquitectura y elección

Prompt caching reutiliza cálculo para un inicio idéntico de la solicitud: instrucciones de sistema, tool schemas, ejemplos few-shot o un gran contexto compartido. No es un semantic cache de respuestas terminadas. El modelo sigue generando un resultado nuevo para la parte variable, por lo que la caché no debe sustituir controles de calidad, actualidad o permisos.

Un diseño útil tiene tres zonas: un prefijo compartido de larga duración, contexto versionado de equipo o tenant y una cola dinámica con la petición del usuario y datos recientes. Coloca primero lo estable y después lo variable. Un timestamp, ID aleatorio, orden inestable de campos JSON o datos personales al principio pueden romper el match y convertir el ahorro esperado en cache writes constantes.

• Cachea solo un prefijo reutilizable suficientemente grande para las reglas del modelo seleccionado.
• Versiona instrucciones, tools, schemas y revisiones del corpus en lugar de mutarlos de forma oculta.
• Mide reads, writes, misses, uncached input, latencia y calidad por separado.
• No mezcles tenants o niveles de acceso para mejorar el hit rate.
• Comprueba las reglas vigentes de modelo, región, retención y precios antes del rollout.

OpenAI documenta caching automático para prefijos exactos elegibles y expone telemetría de cached tokens; modelos más recientes también ofrecen cache keys, puntos de caché y control de modo. Anthropic admite automatic caching de nivel superior y cache breakpoints explícitos mediante cache_control, con conteo separado de tokens de creación y lectura. Gemini ofrece implicit caching y, en la API Generate Content compatible, cached content explícito con TTL administrado; la disponibilidad depende de la API y del modelo.

No ocultes estas diferencias detrás de un indicador genérico cache=true. Un provider adapter debe describir capabilities: modo implícito o explícito, prefijo mínimo, breakpoints permitidos, TTL, billing de write/read, telemetría, región y restricciones de retención. Si una capability es desconocida, ejecuta una solicitud normal y registra el estado como unsupported o unknown en lugar de inventar un hit.

Monta la solicitud de forma determinista: policy e instrucciones de sistema inmutables, tool definitions ordenadas de forma estable, schemas, ejemplos validados, después documentos compartidos y solo entonces input específico del usuario. La serialización debe ser estable a nivel de bytes dentro del contrato del provider. Incluso un JSON semánticamente idéntico con otro orden de campos puede no coincidir como prefijo exacto.

Deriva la cache identity de provider, model family, prompt version, tool-schema version, policy version, locale, tenant o access scope y corpus revision. No coloques texto secreto en logs ni cache keys; usa un digest opaco de identificadores controlados. Un cambio de modelo, permisos, system policy o de una fuente que requiera revocación inmediata crea una nueva versión; el tráfico deja de usar la caché anterior y el objeto expira o se elimina mediante la API disponible.

Modela un cohort lógico: cache-write tokens y storage, cache-read tokens, uncached input, output, número de reutilizaciones, time to first token y cost per successful task. El break-even depende del precio exacto del modelo, TTL y número observado de reutilizaciones. No traslades el porcentaje de descuento de un provider o modelo a otro contrato ni des por hecho un hit solo porque el texto parezca idéntico.

Un hit rate bajo suele indicar una forma de workload inadecuada, no un servicio débil: prompts cortos, repetición infrecuente, cache keys fragmentadas, cambios frecuentes cerca del prefijo o un burst paralelo antes de que termine el primer write. Compara variantes controladas sobre el mismo traffic slice. Si canonicalization añade más complejidad, write spend o retraso de revocación de lo que ahorra, una solicitud normal sin caché es mejor.

Cache reuse no autoriza a debilitar el control de acceso. Un prefijo compartido solo puede contener datos permitidos para todas las solicitudes de su scope. Documentos de tenant, datos personales y resultados de tools con ACL diferentes requieren identidades separadas o deben quedar después del límite seguro. Un cache key es una pista de routing o un identificador de recurso, no un mecanismo de autorización; el servidor sigue teniendo que autorizar la solicitud y construir el contexto permitido.

El caching explícito puede crear estado persistente durante el TTL. Verifica residencia de datos, compatibilidad con zero-data-retention, cifrado, eliminación e incident response en la documentación y contratos vigentes. Para legal hold o revocación urgente, documenta el camino: detener nuevas reads, cambiar versión o scope, eliminar el cache object donde sea compatible y comprobar que traces posteriores ya no utilizan la revisión retirada.

Un trace debe registrar provider, model, cache mode, fingerprint seguro del prefijo, version, breakpoint, TTL solicitado, conteos de tokens read/write/uncached, latencia, outcome y miss reason sin guardar el prompt privado en bruto. Normaliza los campos del provider en categorías comunes, pero conserva el usage payload original en una capa de audit protegida para verificar la semántica de billing.

El dashboard debe mostrar solicitudes elegibles, hit rate entre ellas, proporción de cached tokens, write amplification, cost per accepted outcome y latencia para hits y misses. Alerta ante una caída brusca tras deploy, un cross-scope fingerprint inesperado, writes sin reads posteriores o uso de una versión retirada. El hit rate por sí solo no es un KPI de calidad: un system prompt invariable pero incorrecto también se cachea perfectamente.

Primero mide la repetición de prefijos sin cambiar el comportamiento. Después activa canonical rendering y compara fingerprints exactos, excluyendo cohorts sensibles. El canary debe cubrir un provider/model y un workload de bajo riesgo; un quality eval tiene que confirmar que reordenar bloques no alteró instruction precedence, comportamiento de tools ni groundedness.

El release gate debe exigir cero defectos cross-tenant, attribution de usage correcta, write amplification aceptable y non-regression en task quality. Rollback desactiva breakpoints explícitos o referencias a cache resources, restaura el renderer anterior y dirige el tráfico a solicitudes normales. Los cache objects antiguos no se consideran eliminados sin provider evidence; su expiry o deletion se sigue por separado del rollback de la aplicación.