Cómo diseñar indicaciones de LLM con reconocimiento de caché en OpenAI, Anthropic y Gemini

El almacenamiento en caché rápido solo ayuda cuando los mismos tokens se reutilizan en el lugar correcto, durante el tiempo suficiente y según la semántica del proveedor al que realmente estás llamando. Los equipos a menudo pierden el beneficio porque tratan el almacenamiento en caché como una característica del modelo en lugar de un problema de arquitectura de solicitud. Colocan marcas de tiempo cerca de la parte superior de cada mensaje, intercalan resultados de recuperación de solicitudes específicas con esquemas de herramientas reutilizables u optimizan para un proveedor mientras aumentan silenciosamente el costo de otro.

La solución práctica es hacer que el almacenamiento en caché de mensajes forme parte del compilador de solicitudes de puerta de enlace. La puerta de enlace debe separar el material de solicitud estable del material de solicitud volátil, compilar instrucciones de caché específicas del proveedor y medir el costo y la latencia por prefijo almacenable en caché. Eso es más importante en un entorno multimodelo, donde OpenAI, Anthropic y Gemini exponen diferentes comportamientos de almacenamiento en caché, campos de contabilidad, TTL y costos de configuración.

Comience con la unidad almacenable en caché, no con el proveedor

La unidad reutilizable generalmente no es todo el mensaje. Es un prefijo u objeto de contexto elaborado a partir de material de aviso que comparten muchas solicitudes. En un LLM empresarial API de producción, ese material a menudo incluye política de plataforma, política de organización, instrucciones de aplicación, definiciones de herramientas, reglas de formato de respuesta, instrucciones de agente de codificación u orientación de corpus estático.

La parte volátil es el material que cambia según la solicitud: la tarea actual del usuario, los ID de la solicitud, las marcas de tiempo, el final de la conversación, los pasajes RAG recién recuperados, los datos específicos de la cuenta y resultados únicos de la herramienta. Si el contenido volátil aparece antes que el contenido estable, puede interrumpir la reutilización del prefijo o forzar al proveedor a tratar un mensaje grande como nuevo.

Hecho: las implementaciones del proveedor difieren. OpenAI documentos solicitan el almacenamiento en caché como reutilización de un prefijo compartido, con contabilidad de tokens en caché. Su artículo público sobre almacenamiento en caché indica que el almacenamiento en caché automático comienza con un prefijo de 1024 tokens y crece en incrementos de 128 tokens, y que las entradas de caché generalmente se borran después de 5 a 10 minutos de inactividad y dentro de una hora del último uso. Anthropic documenta puntos de interrupción de caché explícitos y recomienda colocar cache_control en el último bloque compartido, como mensajes del sistema o definiciones de herramientas. Gemini documenta el almacenamiento en caché de contexto como una función paga con recuentos de tokens almacenados en caché devueltos en metadatos de uso para operaciones de caché y llamadas de generación que usan un caché.

Recomendación: diseñe su representación de mensajes internos en torno a bloques estables y bloques volátiles antes de asignar cualquier cosa a las API del proveedor.

Compilar solicitudes de más estable a más Volátil

Un compilador de solicitudes con reconocimiento de caché debe ordenar el material para que la sección reutilizable más grande aparezca antes de la sección específica de la solicitud. Un orden predeterminado práctico es:

1. Política de cumplimiento y seguridad de la plataforma.
2. Política de organización o inquilino.
3. Función de la aplicación e instrucciones de tareas.
4. Esquemas de herramientas y reglas de uso de herramientas.
5. Conocimiento estático o material de referencia de larga duración.
6. Historial de conversaciones que se reutiliza en cada turno.
7. Pasajes recuperados u otro contexto específico de la solicitud.
8. La tarea del usuario actual.
9. Metadatos efímeros necesarios solo para esta llamada.

Este orden no es una verdad universal. Algunos proveedores o modelos pueden responder de manera diferente cuando cambian las instrucciones. La prioridad de las políticas y la calidad del comportamiento siguen siendo importantes.Trate el orden basado en caché como un cambio controlado: ejecute pruebas de regresión de mensajes antes y después de cambiar el diseño.

Ejemplo de bloques de mensajes internos

{
  "blocks": [
    {"id": "platform_policy:v7", "stability": "global", "kind": "system"},
    {"id": "org_policy:acme:v3", "stability": "tenant", "kind": "system"},
    {"id": "support_agent:v12", "stability": "app", "kind": "instructions"},
    {"id": "crm_tools:v5", "stability": "app", "kind": "tool_schema"},
    {"id": "kb_static:returns:v2", "stability": "workflow", "kind": "context"},
    {"id": "conversation_tail", "stability": "session", "kind": "history"},
    {"id": "retrieved_docs", "stability": "request", "kind": "rag"},
    {"id": "user_task", "stability": "request", "kind": "user"}
  ]
}

El compilador puede aplicar hash al prefijo estable después de renderizarlo. Ese hash se convierte en la clave de unión para el análisis de caché: modelo, inquilino, aplicación, hash de prefijo almacenable en caché, versión de solicitud, elección de TTL, tokens de entrada no almacenados en caché, tokens de entrada en caché, tokens de escritura en caché cuando estén disponibles, tokens de salida, latencia y costo final.

Utilice adaptadores de proveedor en lugar de un supuesto de caché

Un único indicador de "habilitar caché" es demasiado vago para operaciones de múltiples proveedores. La puerta de enlace debe exponer una política de caché interna y compilarla en un comportamiento específico del proveedor.

OpenAI Adaptador

Para OpenAI, optimice para prefijos compartidos repetidos y contabilidad de uso. El compilador de solicitudes debe mantener material estable al frente y evitar pequeñas diferencias dentro del primer intervalo almacenable en caché. Realice un seguimiento de los tokens de entrada almacenados en caché desde los campos de uso del proveedor. Cuando esté disponible, también realice un seguimiento de los tokens de escritura de caché para que el libro de costos pueda comparar la creación y reutilización de la caché.

Dado que el almacenamiento en caché está orientado a prefijos, la tarea operativa importante es evitar la deriva de prefijos. Dos mensajes que parecen iguales para los humanos pueden diferir porque una marca de tiempo, un ID de compilación, un orden aleatorio de herramientas o una personalización del inquilino se representaron cerca de la parte superior.

Anthropic Adaptador

Para Anthropic, compile puntos de interrupción de caché explícitos. Coloque cache_control en el último bloque que debe compartirse con solicitudes de seguimiento. Buenos candidatos son instrucciones de sistemas grandes, definiciones de herramientas o contextos de referencia estables. Los malos candidatos son mensajes de usuario únicos, cargas útiles de tareas actuales o fragmentos de RAG de solicitudes específicas.

Hecho: Anthropic documenta una duración de caché predeterminada de 5 minutos y una duración de caché de 1 hora disponible por un costo adicional. Eso hace que la selección de TTL sea una decisión económica. Un caché largo puede tener sentido para agentes de codificación interactivos, revisión de documentos de varios pasos o copilotos de soporte con pausas entre turnos. Puede ser un desperdicio para una tarea única y con pocas repeticiones.

Gemini Adaptador

Para Gemini, trate el almacenamiento en caché de contexto como una decisión de recursos. Cree contenido almacenado en caché cuando la reutilización esperada justifique el costo de configuración y almacenamiento, luego haga referencia a ese caché desde las llamadas de generación. Esto es diferente a depender únicamente de una caché de prefijos automática. El adaptador debe poseer el ciclo de vida de la caché, el TTL, los metadatos y la política de limpieza.

Gemini Las cachés de contexto de estilo suelen ser mejores para contextos grandes y estables que muchas solicitudes reutilizarán: un manual de políticas extenso, un extracto estático de un catálogo de productos, un entorno de herramientas de agente de codificación fijo o un flujo de trabajo de revisión que formula preguntas repetidamente sobre el mismo conjunto de documentos.

Mida la economía de la caché, no solo las visitas Tasa

La tasa de aciertos de la caché es útil, pero no es suficiente. Una alta tasa de aciertos en un prefijo pequeño puede ahorrar poco. Una tasa de acierto más baja en un prefijo de políticas y herramientas muy grande puede ser más importante.Algunos proveedores exponen los costos de configuración o escritura en caché, y esos costos pueden anular los ahorros si la reutilización es baja.

Capture estos campos para cada solicitud donde el proveedor los expone o la puerta de enlace puede estimarlos:

• Proveedor y modelo.
• Inquilino, aplicación, entorno e identidad de clave API.
• Versión de plantilla de solicitud y prefijo almacenable en caché hash.
• Política TTL o duración de la caché.
• Tokens de entrada sin caché.
• Tokens de entrada en caché.
• Tokens de escritura o creación de caché cuando estén disponibles.
• Tokens de salida.
• Tiempo hasta el primer token y total latencia.
• Versión de precio de lista de proveedores utilizada para el cálculo de costos.
• Si la solicitud fue parte de una sesión interactiva, un trabajo por lotes, un bucle de agente o una llamada única.

Luego calcule el valor de la caché por carga de trabajo, no globalmente. Un copiloto de soporte, un agente codificador, un revisor de documentos y un resumidor único tienen diferentes patrones de reutilización. Los resúmenes deben mostrar los dólares ahorrados, los dólares gastados en escritura de caché, el cambio de latencia y la tasa de aciertos por hash de prefijo.

Un modelo de retorno de la inversión simple es suficiente para comenzar:

expected_savings =
  expected_reuses
  * cacheable_tokens
  * (uncached_input_price - cached_input_price)

net_value =
  expected_savings
  - cache_write_or_setup_cost
  - operational_overhead

Este modelo es intencionalmente simple. Debe usarse como puerta antes de habilitar cachés explícitos o de larga duración, no como sustituto de la medición de producción.

Agregar reglas Lint para rompedores de caché

La mayoría de las fallas de caché provienen de hábitos de construcción rápida, no de errores del proveedor. Agregue reglas de pelusa de puerta de enlace que se ejecuten antes de que las solicitudes lleguen al proveedor.

Marque las marcas de tiempo cerca de la parte superior de las solicitudes. Si el modelo necesita la hora actual, colóquela después del prefijo reutilizable o páselo como un bloque de solicitud tardía.

Marcar ID aleatorios en los mensajes del sistema. Los ID de correlación pertenecen a los metadatos o registros, no al prefijo del mensaje estable.

Marcar esquemas de herramientas ordenados dinámicamente. Ordene las herramientas y las propiedades del esquema de forma determinista antes de renderizar. Una lista de herramientas que cambia de orden en cada solicitud puede destruir la reutilización incluso cuando el conjunto de herramientas es lógicamente idéntico.

Marcar RAG específico de la solicitud antes que herramientas estables. Los pasajes recuperados suelen ser volátiles. Coloque primero las instrucciones estables y los esquemas de herramientas, luego los pasajes recuperados, a menos que las pruebas inmediatas demuestren que se requiere otro orden.

Marque la personalización específica del usuario en la política compartida. La política de inquilinos se puede almacenar en caché en un inquilino, pero las preferencias del usuario y el estado actual de la cuenta generalmente no lo son.

Marcar abandono de versión de plantilla. Si cada implementación cambia los espacios en blanco, los comentarios o el texto de instrucciones no utilizado, el hash del prefijo almacenable en caché cambia. Versione las plantillas de solicitud de forma deliberada y evite ediciones innecesarias en grandes bloques estables.

Maneje las cargas de trabajo de RAG con cuidado

RAG es donde los equipos suelen almacenar en caché en exceso. Las instrucciones de recuperación estables, las reglas de citación, los esquemas de herramientas y las descripciones de corpus pueden ser reutilizables. Los propios pasajes recuperados suelen ser específicos de la solicitud. Si coloca los pasajes recuperados antes de las instrucciones estables, reduce la reutilización. Si almacena en caché todo el contexto cuando es poco probable que se repitan los pasajes, es posible que tenga que pagar costos de escritura o configuración sin suficientes visitas futuras.

Hay excepciones. Un flujo de revisión legal, un flujo de trabajo de soporte o un asistente de documentos de producto pueden consultar repetidamente el mismo paquete de documentos en una sesión. En ese caso, puede resultar útil una caché de mayor duración para el contexto del documento.La decisión debe depender del recuento de reutilización esperado, la duración del caché, el tamaño del contexto del documento y si los usuarios tienden a hacer varias preguntas sobre el mismo material.

Recomendación: clasifique el contexto RAG como uno de tres tipos: guía de corpus estático, contexto de sesión reutilizable o fragmentos recuperados únicos. Almacene en caché solo los dos primeros de forma predeterminada.

Validar el comportamiento antes de optimizar el costo

Mover contenido más tarde en un mensaje puede mejorar la reutilización de la caché, pero también puede cambiar el comportamiento del modelo. Por ejemplo, mover las reglas de las herramientas después del historial de conversaciones podría reducir su influencia. Mover la política por debajo del contenido recuperado puede debilitar la prioridad de la instrucción. La normalización de esquemas puede afectar la selección de herramientas si las descripciones cambian.

Utilice pruebas de regresión antes de implementar diseños compatibles con caché. Como mínimo, pruebe:

• Prioridad de instrucción para la política de seguridad y cumplimiento.
• Selección de herramientas en tareas conocidas.
• Validez de salida estructurada cuando están involucrados esquemas.
• Calidad de respuesta en ejemplos representativos de RAG.
• Latencia y costo en repetición turnos.
• Contabilidad de uso específica del proveedor.

Para flujos de trabajo de alto riesgo, ejecute una comparación paralela: diseño de solicitud original versus diseño con reconocimiento de caché, mismo modelo, mismas entradas, con comprobaciones humanas o automatizadas para detectar cambios de salida inaceptables. Los ahorros de costos no son útiles si el compilador de solicitudes cambia el comportamiento empresarial de maneras que los equipos no aprobaron.

Elija cargas de trabajo de forma selectiva

El almacenamiento en caché de solicitudes es más eficaz cuando las solicitudes son largas y repetidas. Los buenos puntos de partida incluyen agentes de codificación con esquemas de herramientas grandes, copilotos de soporte con instrucciones con muchas políticas, flujos de revisión de documentos con preguntas repetidas sobre el mismo material, agentes con muchas herramientas y asistentes empresariales con grandes bloques de gobernanza.

Los candidatos débiles incluyen indicaciones breves y únicas, indicaciones altamente personalizadas donde la parte superior de la solicitud cambia cada vez, tareas administrativas poco frecuentes y flujos de trabajo donde los tokens de salida dominan el costo total. En esos casos, otras optimizaciones pueden ser más importantes: mensajes más breves, mejor recuperación, enrutamiento de modelos, procesamiento por lotes o límites de salida más estrictos.

Predicción: la semántica del almacenamiento en caché del proveedor seguirá divergiendo. Es probable que el almacenamiento en caché de prefijos automático, los puntos de interrupción explícitos, los recursos de contexto pagos, la contabilidad de escritura en caché y los precios TTL sigan siendo desiguales entre plataformas.Los equipos que centralizan la compilación de solicitudes y la telemetría en la puerta de enlace podrán adaptarse más rápido que los equipos que incorporan lógica de almacenamiento en caché específica del proveedor en el código de la aplicación.

Lista de verificación de implementación

• Crear un modelo de bloque de mensajes interno con etiquetas de estabilidad: global, inquilino, aplicación, flujo de trabajo, sesión y solicitud.
• Representar bloques de forma determinista, incluido el orden de las herramientas y la propiedad del esquema. orden.
• Saque los campos volátiles del prefijo estable.
• Calcule un hash de prefijo almacenable en caché después de la renderización.
• Agregue adaptadores de proveedor para OpenAI reutilización de prefijos, Anthropic puntos de interrupción de caché y Gemini recursos de caché de contexto.
• Registrar tokens de entrada no almacenados en caché, tokens de entrada almacenados en caché, escritura en caché tokens cuando estén disponibles, tokens de salida, latencia, modelo, inquilino, aplicación, hash de prefijo y TTL.
• Cree paneles para ahorrar dinero neto, costo de escritura/configuración, tasa de aciertos y latencia por carga de trabajo.
• Agregue reglas de pelusa para marcas de tiempo, ID aleatorios, ubicación de RAG volátil, orden dinámico de herramientas y personalización en bloques compartidos.
• Ejecutar mensaje pruebas de regresión de comportamiento antes de cambiar el diseño de producción.
• Habilite el almacenamiento en caché primero para cargas de trabajo de alta repetición, luego amplíelo según el retorno de la inversión medido.

Conclusión

El diseño de avisos con reconocimiento de caché no es solo formato de avisos. Es una capacidad de puerta de enlace: representación determinista, diseño de prefijo estable, compilación específica del proveedor, linting y telemetría de costos. Los equipos que más se beneficiarán serán aquellos que puedan responder tres preguntas para cada carga de trabajo: ¿qué parte de la solicitud es realmente reutilizable? ¿Cómo cobra este proveedor por la reutilización? ¿Mejoró la caché el costo o la latencia de un extremo a otro sin cambiar el comportamiento?

Comience con un flujo de trabajo de alta repetición. Separe los bloques estables de los volátiles, agregue manejo de caché específico del proveedor, mida la economía y solo entonces generalice. Esa ruta evita el modo de falla común: activar una función de caché sin saber si está ahorrando dinero, agregando latencia o simplemente trasladando costos a un campo contable diferente.

Lecturas relacionadas

• Observabilidad de LLM neutral para el proveedor