Guía de almacenamiento en caché de indicaciones de GPT-6 Astra: Cómo reducir los costos de contexto repetido

Los prompts de agentes grandes a menudo repiten la misma política del sistema, definiciones de herramientas, documentación del producto, ejemplos e historial de conversación. Reenviar ese material a veces es inevitable; pagar el costo total de entrada y latencia por un prefijo idéntico no lo es. GPT-6 Astra admite el almacenamiento en caché de prompts en la API de Respuestas para que los prefijos repetidos puedan reutilizarse.

El almacenamiento en caché es una optimización, no memoria. No hace que un modelo recuerde a un cliente entre solicitudes, ni cambia lo que el modelo ve. La solicitud aún necesita la entrada relevante. La diferencia es que un prefijo idéntico y elegible puede servirse desde la caché a una tarifa de entrada en caché más baja.

Lo que GPT-6 Astra almacena en caché

La caché se basa en prefijos. OpenAI puede reutilizar tokens desde el inicio de un prompt cuando la siguiente solicitud comienza con contenido coincidente. Un modelo mental útil es un documento cuyos capítulos estables van primero y cuyo apéndice específico de la solicitud va al final.

Pon estos cerca del frente:

• instrucciones estables para desarrolladores;
• esquemas de herramientas en un orden estable;
• documentos de referencia extensos utilizados en múltiples solicitudes;
• ejemplos canónicos y reglas de salida.

Pon estos cerca del final:

• el mensaje actual del usuario;
• marcas de tiempo, IDs de solicitud y estado temporal;
• pasajes recuperados que cambian en cada llamada;
• preferencias por usuario que no se comparten.

Una marca de tiempo insertada cerca del principio puede invalidar todo lo que le sigue. Del mismo modo, generar arreglos de herramientas a partir de un mapa desordenado puede producir prefijos semánticamente idénticos pero con bytes diferentes. Construye los prompts de manera determinista.

Almacenamiento en caché implícito y explícito

GPT-5.6 y modelos posteriores exponen prompt_cache_options. En modo implícito, el servicio identifica automáticamente un punto de interrupción reutilizable. Este es el punto de partida más sencillo y es adecuado cuando tu prompt tiene un prefijo grande y estable.

SALIDA SOLO TRADUCCIÓN:
import OpenAI from "openai";

const client = new OpenAI();

= await client.responses.create({
  model: "gpt-6-astra",
  prompt_cache_key: "support-agent:v4",
  prompt_cache_options: { mode: "implicit", ttl: "30m" },
  input: [
    { role: "developer", content: "Política estable e instrucciones operativas..." },
    { role: "user", content: "¿Por qué se duplicó mi factura?" }
  ]
});

El valor TTL actualmente documentado es 30m, y 30 minutos es el valor predeterminado. No diseñes en torno a duraciones no documentadas. OpenAI también marca el campo anterior prompt_cache_retention como obsoleto.

El modo explícito le da a la aplicación más control. Agregas elementos de contenido prompt_cache_breakpoint en los límites que vale la pena preservar. Esto es útil cuando un prompt se ensambla a partir de varios bloques estables seguidos de material volátil. Una solicitud puede escribir como máximo cuatro puntos de interrupción, y el servicio considera hasta los últimos 80 puntos de interrupción. Más puntos de interrupción no son automáticamente mejores: cada escritura tiene un costo, y los prefijos fragmentados pueden ser más difíciles de razonar.

Una arquitectura de prefijo práctica

Para un agente de producción, usa cuatro capas:

1. Identidad y seguridad

Coloque el rol duradero, las restricciones de seguridad y el contrato de respuesta primero. Versiona este bloque deliberadamente. Una edición de política debería crear una nueva clave de caché en lugar de mezclar silenciosamente mediciones de dos versiones.

2. Definiciones de herramientas

Los esquemas de herramientas suelen ser grandes y repetidos. Mantén estables los nombres, descripciones, propiedades y el orden. Elimina las herramientas no utilizadas cuando sea posible; esto reduce tanto el contexto no almacenado en caché como el almacenado en caché, y disminuye la ambigüedad en la selección de herramientas.

3. Conocimiento compartido

Añade manuales duraderos, taxonomías, guías de estilo o documentación de productos. Si el conocimiento cambia con frecuencia, la búsqueda de archivos puede ser mejor que incrustarlo todo en cada indicación. Almacena en caché el conocimiento operativo estable; recupera los hechos cambiantes.

4. Estado dinámico de la solicitud

Añadir entrada del usuario, registros actuales, resultados de búsqueda en vivo y estado temporal. Esta ubicación protege el prefijo reutilizable de cambios rutinarios.

Para un flujo de trabajo creativo, la capa estable podría contener reglas de producción de animación y un estilo de la casa, mientras que la cola dinámica contiene la escena actual. Una plataforma como Elser AI podría aplicar el mismo principio a un contexto repetido de la biblia de la historia o de consistencia de personajes sin implicar que el almacenamiento en caché en sí mismo crea consistencia.

Mide los ahorros en lugar de asumirlos

Inspecciona usage.input_tokens_details.cached_tokens y cache_write_tokens. Un recuento alto de tokens en caché indica que parte del prefijo fue reutilizada. Los tokens de escritura en caché revelan el costo de crear o actualizar entradas.

Para GPT-6 Astra, los precios del modelo publicados en la fecha de verificación indican que la entrada en caché es más barata que la entrada normal, y las escrituras en caché son más caras que la entrada normal. Esto plantea una pregunta de punto de equilibrio: un prefijo reutilizado repetidamente puede ahorrar dinero; un prefijo escrito una vez y nunca reutilizado puede costar más. Los precios cambian, por lo que es mejor calcular con la página actual del modelo en lugar de codificar números fijos en hojas de cálculo de planificación.

Rastrea al menos:

• tasa de aciertos de caché por versión de prompt;
• tokens de entrada en caché, escritos y totales;
• tiempo p50 y p95 hasta el primer token;
• costo por tarea completada, no solo por solicitud;
• fallos de caché causados por lanzamientos.

Un panel agrupado solo por modelo oculta la causa de los fallos. Incluye una clave de caché o una dimensión de versión de prompt en tu propia telemetría, pero nunca pongas datos personales o secretos en las claves de caché.

Siete causas comunes de fallos de caché

El contenido dinámico aparece demasiado pronto

Mover fechas, IDs de usuario y material recuperado después del contenido reutilizable.

Los esquemas de herramientas cambian de orden

Ordenar herramientas y propiedades de esquema de manera determinista en el paso de compilación de la aplicación.

Los prompts son "equivalentes" pero no idénticos

Los espacios en blanco, los ejemplos o la serialización pueden diferir. Genere bloques compartidos a partir de artefactos versionados en lugar de cadenas ad hoc.

El prefijo es demasiado corto

La longitud mínima de caché varía según el modelo. Las indicaciones muy cortas pueden no beneficiarse. Confírmalo mediante los datos de uso.

La compactación cambió el prefijo

La compactación ayuda a ajustar conversaciones largas, pero produce una representación de contexto diferente. Espere que los patrones de reutilización cambien después de la compactación y mida alrededor de los límites de los hitos.

Demasiados puntos de interrupción de bajo valor

Los puntos de interrupción deben corresponder a capas reutilizables significativas. Cuatro escrituras permitidas son un límite, no un objetivo.

Una clave de caché es demasiado amplia o demasiado estrecha

Una clave para cada flujo de trabajo no relacionado produce una agrupación débil; una clave única por solicitud impide la reutilización. Prefiere una clave semántica como legal-review:v3:us.

Un plan de implementación seguro

Comience con el modo implícito activado en un flujo de trabajo de alto volumen. Estabilice la construcción del prompt, registre los detalles de los tokens y compare dos semanas de costo y latencia. Luego considere puntos de interrupción explícitos si el prompt tiene múltiples capas reutilizables o colas dinámicas frecuentes. Evalúe la calidad junto con los ahorros: la eliminación agresiva de contexto no es almacenamiento en caché y puede reducir la calidad de las respuestas.

Almacene en caché solo el contenido que ya tenga permitido enviar a la API. El almacenamiento en caché no reemplaza la clasificación de datos, el aislamiento de inquilinos, los controles de acceso ni las decisiones de retención. Mantenga los secretos fuera de las indicaciones siempre que una herramienta pueda obtenerlos justo a tiempo.

Preguntas Frecuentes

¿El almacenamiento en caché de prompts reduce el coste de los tokens de salida?

No. Se aplica a la entrada repetida elegible. La salida se genera normalmente y se factura a la tarifa de salida.

¿Hace previous_response_id que los turnos anteriores sean gratuitos?

No. OpenAI establece que los tokens de entrada anteriores en una cadena de respuesta aún se facturan como entrada. El almacenamiento en caché de indicaciones puede reducir el costo de prefijos repetidos elegibles, pero el encadenamiento de conversaciones y el almacenamiento en caché son mecanismos separados.

¿Debo almacenar en caché los resultados de búsqueda recuperados?

Solo cuando son estables y se reutilizan genuinamente. Los resultados en vivo normalmente pertenecen a la cola dinámica. Para corpus controlados, la búsqueda de archivos puede evitar incrustar una colección completa en cada indicación.

¿Puedo confiar en un acierto de caché?

Trata el almacenamiento en caché como una optimización oportunista. Tu aplicación debe seguir siendo correcta en caso de fallo.

Conclusión

La estrategia de almacenamiento en caché de GPT-6 Astra de mayor valor es arquitectónica: instrucciones y herramientas estables primero, estado volátil al final, serialización determinista, versionado deliberado y medición a través de detalles de tokens. Comience con almacenamiento en caché implícito, agregue puntos de interrupción explícitos solo cuando los datos los respalden y optimice el costo por tarea exitosa en lugar de perseguir una he