Caché de prompts de 12 horas: calcula las reutilizaciones, no el ahorro anunciado

OpenAI anunció el 20/10 la opción de caché de prompts de 12 horas en la API. (OpenAI)

La guía fija para 12h una escritura total de 2,5 veces la entrada ordinaria, no un recargo añadido. El soporte y las lecturas dependen del modelo; 12h no es un plazo de borrado. (OpenAI)

Define la unidad que quieres comparar

Aísla un prefijo estable: por ejemplo, instrucciones y material de referencia. Separa la parte que cambia en cada petición. Para comparar opciones, utiliza la misma tarea, modelo, tamaño de prefijo y distribución temporal; de otro modo no podrás atribuir la diferencia al diseño de caché.

La elegibilidad y coincidencia del prefijo deben comprobarse según el modelo. No basta con que dos peticiones traten del mismo tema. Si una modificación invalida lo que esperabas reutilizar, necesitas contabilizar su coste como tal, no como una lectura favorable.

Un modelo de coste que deje ver los supuestos

Llamemos P al coste ordinario del prefijo completo, w al multiplicador total de una escritura y r al de una lectura. Si escribes una vez y logras n reutilizaciones completas, el coste del prefijo será P por (w + n·r). Sin esa reutilización, las mismas peticiones cuestan P por (1 + n).

modelo simplificado para el prefijo, no cálculo de factura:
  coste_sin_cache = P * (1 + n)
  coste_con_cache = P * (w + n * r)
  compensa frente a no cachear si: n * (1 - r) > w - 1

supuestos: una escritura, lecturas completas y misma tarea
excluye: entrada variable, salida, herramientas y otros costes

La desigualdad muestra por qué una escritura más cara necesita reutilizaciones suficientes. No afirma que vayas a obtenerlas. Si hay varias escrituras, fallos de caché o reutilización parcial, el modelo debe registrar esos casos en lugar de multiplicar todas las peticiones por un precio de lectura.

Para elegir duración, compara las dos políticas

El ejemplo anterior compara con no cachear, no demuestra que 12 horas sea mejor que una política más corta. Para esa decisión, utiliza el número de escrituras y lecturas que produciría cada opción con los mismos intervalos. Una carga concentrada puede reutilizar suficiente contexto sin necesitar la duración más larga.

Puedes modelar cada política con tres contadores: W escrituras, H lecturas y U peticiones del prefijo sin caché. El coste es P por (W·w + H·r + U), bajo la simplificación de prefijos completos. Registra por separado las reutilizaciones parciales si existen y evita contar un mismo tramo de tokens dos veces.

Qué observar en un ensayo comparable

• Tamaño y versión del prefijo que esperabas reutilizar.
• Distribución real de intervalos entre peticiones y frecuencia de cambios.
• Tokens que el servicio declara escritos o leídos, cuando la respuesta o los informes los expongan.
• Fallos, reintentos, límites y tiempos relevantes para la tarea.
• Coste total de entrada, salida y herramientas con el precio vigente de cada componente.

No deduzcas un hit de que la petición fue rápida. Usa las señales de uso disponibles y conserva sus límites. Si una variable no puede observarse, presenta el resultado como estimación con ese supuesto, no como ahorro medido.

Retención y datos requieren otra comprobación

Antes de enviar información sensible, revisa las condiciones de datos del endpoint, la cuenta y el modelo. Un tiempo elegido para reutilizar contexto no debe interpretarse como una instrucción de eliminación a esa hora. Evita prometer borrado o cumplimiento por seleccionar una opción de rendimiento.

No hemos medido una carga de KIURO ni un coste de cliente. El método permite formular una decisión comprobable: mantener la política actual, ensayar una más larga o rediseñar el prefijo. La elección depende de la reutilización que puedas demostrar y del coste total que realmente importe.