Flujo de trabajo de caché de prompts: guía de costes y ROI para apps de LLM

La caché de prompts puede reducir el coste y la latencia de las solicitudes repetidas de LLM, pero solo cuando el flujo de trabajo produce prefijos estables, suficiente reutilización y un comportamiento aceptable de aciertos de caché. Activar la función no es lo mismo que demostrar el retorno de la inversión.

Esta guía ofrece a los equipos de ingeniería y FinOps un flujo de trabajo práctico de caché de prompts: identificar el tráfico elegible, adaptar los prompts para su reutilización, instrumentar métricas de caché, calcular el ahorro neto e implementar sin ocultar regresiones de calidad o fiabilidad.

What is prompt caching?

La caché de prompts permite a un proveedor de LLM reutilizar el cómputo del contenido del prompt que ha procesado recientemente. En lugar de cobrar y procesar cada token de entrada repetido al ritmo normal, el proveedor puede aplicar una tarifa más baja para entradas en caché o un precio de lectura de caché separado a la parte reutilizable.

El contenido reutilizable suele ser un prefijo de prompt estable. Algunos ejemplos comunes incluyen:

• Un prompt del sistema largo y un bloque de políticas.
• Definiciones de herramientas compartidas por cada turno del agente.
• Un documento grande, un mapa del repositorio o un catálogo de productos consultado repetidamente.
• Ejemplos few-shot reutilizados en un trabajo de clasificación o extracción.
• Un historial de conversación compartido por varias posibles acciones siguientes.

Las implementaciones de los proveedores difieren. OpenAI documenta la caché automática para prefijos de prompt que cumplen los requisitos y expone detalles de tokens en caché en el uso de la API. Anthropic admite puntos de ruptura de caché explícitos y múltiples opciones de tiempo de vida. Google Gemini admite cachés de contexto explícitos con cargos de almacenamiento, mientras que DeepSeek documenta la caché automática de contexto basada en disco con tarifas de entrada separadas para aciertos y fallos de caché. Confirme siempre la compatibilidad actual del modelo y los precios en la documentación oficial del proveedor antes de incorporar el ahorro a una previsión.

The ROI mistake: measuring the discount instead of the workflow

Un descuento por tokens en caché no es lo mismo que un ahorro neto. El flujo de trabajo también puede generar cargos por escritura en caché, cargos de almacenamiento, solicitudes adicionales, complejidad operativa o regresiones de calidad cuando los equipos optimizan la estructura del prompt de forma demasiado agresiva.

Mida la unidad que importa:

ROI neto de la caché de prompts = coste de entrada sin caché evitado - coste de escritura/almacenamiento de la caché - coste de implementación y operación

Para las decisiones de producción, conecte ese resultado con un resultado aceptado:

Coste por tarea aceptada = coste total de la solicitud / tareas exitosas validadas

Esto evita un resultado engañoso en el que el gasto en tokens baja, pero aumentan los reintentos, las salidas rechazadas o la revisión humana. También alinea la caché de prompts con un programa más amplio de optimización de costes de la API de IA en lugar de tratar la caché como un truco de facturación aislado.

A six-step prompt caching workflow

1. Find workloads with real prefix reuse

Empiece con trazas de solicitudes, no con intuiciones. Agrupe el tráfico por flujo de trabajo y estime cuántos tokens de entrada permanecen idénticos desde el inicio de una solicitud hasta la siguiente.

Los buenos candidatos suelen tener cuatro propiedades:

1. Entrada repetida grande: el prefijo reutilizable es material en relación con el sufijo dinámico.
2. Reutilización frecuente: varias solicitudes hacen referencia al mismo prefijo dentro de la ventana de caché efectiva del proveedor.
3. Orden estable: las instrucciones del sistema, las herramientas, los ejemplos y el material de referencia aparecen en el mismo orden.
4. Baja cardinalidad: la aplicación reutiliza un número manejable de variantes de prompt en lugar de crear un prefijo único para cada usuario.

Los flujos de trabajo típicos con alto potencial incluyen agentes de código con esquemas de herramientas estables, asistentes de soporte basados en un paquete de conocimiento compartido, sesiones de preguntas y respuestas sobre documentos, extracción por lotes con ejemplos repetidos y agentes de investigación de varios turnos.

Los candidatos poco adecuados incluyen prompts cortos de una sola vez, prefijos altamente personalizados, solicitudes que cambian las definiciones de herramientas en cada llamada y trabajos de bajo volumen que rara vez reutilizan una entrada de caché.

Construye una tabla de referencia para cada flujo de trabajo:

2. Coloca el contenido estático antes que el contenido dinámico

La caché de prompts suele depender de hacer coincidir el prompt desde su inicio. Una pequeña diferencia cerca del principio puede impedir la reutilización de todo lo que sigue.

Usa este orden cuando el proveedor y el SDK lo permitan:

1. Instrucciones estables del sistema
2. Reglas estables de políticas y seguridad
3. Definiciones de herramientas estables
4. Material de referencia estable o ejemplos
5. Contexto conversacional semiestable
6. Entrada dinámica del usuario y valores en tiempo de ejecución

No coloques marcas de tiempo, IDs de solicitud, etiquetas específicas del usuario, JSON con orden aleatorio ni flags de funciones que cambian con frecuencia cerca del inicio del prompt. Normaliza los esquemas de herramientas y serializa el contenido estructurado de forma determinista.

Esto no da permiso para combinar datos no relacionados en un prefijo sobredimensionado. Mantén intactos los límites entre inquilinos, las reglas de autorización y los requisitos de retención de datos. Un prompt más barato no compensa un fallo de privacidad o de aislamiento.

3. Define una identidad de caché y una política de invalidación

Tu aplicación necesita una forma explícita de razonar sobre las versiones del prompt, incluso cuando el proveedor gestiona la caché automáticamente.

Una identidad de caché práctica puede incluir:

workflow + prompt_version + tool_schema_version + knowledge_version + model_family

Haz un seguimiento de esta identidad en la telemetría. Cuando cambien las instrucciones, los contratos de herramientas o los datos de referencia, incrementa la versión correspondiente. Eso hace que los cambios de coste sean explicables y evita que los equipos confundan una invalidación esperada con una interrupción del proveedor.

Establezca una ventana de reutilización en función del comportamiento de la carga de trabajo y de la compatibilidad del proveedor. Un agente interactivo de corta duración puede beneficiarse de minutos de reutilización. Un flujo de trabajo de investigación recurrente puede justificar una caché explícita más larga si el coste de almacenamiento sigue siendo inferior al procesamiento repetido de la entrada.

4. Instrumente aciertos, fallos, escrituras y resultados aceptados

Como mínimo, registre estos campos para cada intento:

• Proveedor, modelo y flujo de trabajo.
• Versión del prompt e identidad de la caché.
• Tokens totales de entrada, en caché/leídos, de escritura en caché y de salida cuando estén expuestos.
• Estado de acierto de caché o acierto inferido.
• Coste estimado de entrada, caché, salida y total.
• Latencia, estado, número de reintento y ruta de fallback.
• Éxito validado o resultado de tarea aceptado.

Use los campos de uso informados por el proveedor como fuente de verdad de facturación cuando estén disponibles. Si un proveedor no devuelve un indicador claro de acierto de caché, infiéralo cuidadosamente a partir de los recuentos de tokens en caché o de los registros de facturación y etiquete la métrica como inferida.

La telemetría de caché de prompts pertenece al mismo trace que los reintentos y el fallback del modelo. De lo contrario, una tormenta de reintentos puede parecer una optimización de caché exitosa. La lista de verificación de implementación de observabilidad de IA muestra cómo conectar el coste por intento con los resultados de la aplicación.

5. Calcule el ahorro y el volumen de equilibrio

Use un modelo que coincida con la estructura de cobro del proveedor.

Para la caché automática con una tarifa de lectura descontada:

ahorro_bruto = cache_read_tokens × (uncached_input_rate - cached_input_rate)
ahorro_neto = ahorro_bruto - incremental_operating_cost

Para la caché explícita con cargos de escritura y almacenamiento:

ahorro_neto = avoided_uncached_cost
            - cache_write_cost
            - cache_storage_cost
            - incremental_operating_cost

Puede estimar el número de reutilizaciones de equilibrio para un prefijo en caché:

break_even_reuses =
  (cache_write_cost + storage_cost + implementation_cost_per_entry)
  / savings_per_cache_read

Redondee hacia arriba a la siguiente reutilización entera. Después añada un margen para fallos, invalidaciones y variabilidad del tráfico.

Ejemplo práctico de ROI

Suponga que un flujo de trabajo tiene:

• 40.000 solicitudes al mes.
• 18.000 tokens de entrada por solicitud.
• Un prefijo estable de 12.000 tokens.
• Una tasa efectiva de acierto de caché del 70%.
• Una tarifa de entrada sin caché de 3 $ por millón de tokens.
• Una tarifa de entrada en caché de 0,30 $ por millón de tokens.
• 350 $ al mes en coste amortizado de ingeniería y monitorización.

Tokens en caché mensuales:

40.000 × 12.000 × 70% = 336.000.000 tokens de entrada en caché

Ahorro bruto:

336 millones × (3,00 $ - 0,30 $) / 1 millón = 907,20 $

Ahorro neto mensual:

907,20 $ - 350 $ = 557,20 $

Si el flujo de trabajo produce 32.000 tareas aceptadas, la caché contribuye con unos 0,017 $ de ahorro por tarea aceptada. Eso puede ser significativo a escala, pero el resultado es mucho más modesto que simplemente citar un descuento del 90% en la entrada en caché.

Las tarifas anteriores son ilustrativas, no una cotización actual del proveedor. Sustitúyelas por tus tarifas contratadas o publicadas e incluye escrituras en caché, almacenamiento, precios regionales, niveles de servicio y cargos de pasarela cuando corresponda.

6. Despliega con un experimento controlado

Ejecuta la caché como un cambio de ingeniería con un grupo de control medible.

1. Selecciona un flujo de trabajo con alto grado de reutilización.
2. Congela el conjunto de evaluación y los criterios de aceptación.
3. Establece líneas base de coste, latencia y calidad sin caché.
4. Reestructura solo el prefijo estable.
5. Envía una pequeña parte del tráfico de producción por la ruta con caché.
6. Compara la tasa de aciertos, el coste por tarea aceptada, la latencia P95, los errores y los fallback.
7. Amplía solo cuando el ahorro siga siendo positivo después del coste operativo.

Mantén las políticas de reintento y fallback separadas de la lógica de caché. Una solicitud fallida puede ser segura para reintentar, insegura para reproducir después de una transmisión parcial, o estar mejor atendida por un modelo equivalente. Usa una estrategia de fallback de modelo definida en lugar de tratar cada fallo de caché o timeout como si fuera el mismo error.

Panel de KPI de caché de prompts

Haz seguimiento de las siguientes métricas por flujo de trabajo y versión del prompt:

Puede producirse una tasa alta de aciertos con un ahorro débil cuando el prefijo repetido es pequeño. Una tasa baja de aciertos con un prefijo grande aún puede identificar una oportunidad valiosa si se puede corregir la fragmentación del prompt. Lee las métricas en conjunto.

Modos de fallo comunes de la caché de prompts

Valores dinámicos al principio

Las marcas de tiempo, los IDs y los metadatos por usuario cerca del inicio fragmentan la caché. Muévelos después del prefijo estable siempre que sea posible.

Los esquemas de herramientas cambian entre solicitudes

Los agentes a menudo reconstruyen o reordenan las definiciones de herramientas de forma dinámica. Estandariza el orden, elimina las herramientas irrelevantes y versiona el esquema de forma deliberada.

Las entradas de caché se escriben pero rara vez se reutilizan

La creación explícita de caché puede costar más de lo que ahorra cuando el tráfico es escaso o el TTL es demasiado largo. Mide la reutilización por identidad de caché antes de ampliar la retención.

Los equipos optimizan tokens pero ignoran las salidas

Los tokens de salida, los reintentos y la revisión humana pueden dominar el coste total. Sigue midiendo la solicitud completa y el resultado aceptado.

Se asume que el comportamiento del proveedor es portable

La caché automática de prefijos, los puntos de interrupción explícitos, la facturación de almacenamiento, las longitudes mínimas de prompt, los modelos elegibles y los campos de uso varían según el proveedor. Crea un adaptador de proveedor y mantén la métrica de negocio independiente del proveedor.

La respuesta de fallback destruye la localidad de la caché

Cambiar de proveedor o de familia de modelos puede eliminar la reutilización porque las cachés no son portables. Esto no significa que deba desactivarse el fallback. Significa que la fiabilidad y el coste necesitan una política compartida: conmutar por error cuando sea necesario y, después, atribuir correctamente la pérdida de acierto y el coste incremental.

Lista de verificación de implementación del proveedor

Antes de habilitar la caché de prompts para un modelo, confirma:

• ¿La caché es automática, explícita o ambas?
• ¿Qué modelos y endpoints de API la admiten?
• ¿Qué longitud mínima de prompt se aplica?
• ¿Cómo se define un prefijo coincidente?
• ¿Qué opciones de TTL o retención existen?
• ¿Las escrituras, lecturas y el almacenamiento de caché se cobran por separado?
• ¿Qué campos de respuesta exponen tokens en caché o la creación de la caché?
• ¿El nivel de servicio, la región, la residencia de datos o los ajustes de retención cero cambian el comportamiento?
• ¿Las cachés están aisladas por proyecto, cuenta, organización u otro límite?
• ¿Qué ocurre cuando la solicitud hace fallback a otro modelo o proveedor?

Utiliza la guía de caché de prompts de OpenAI, la documentación de caché de prompts de Anthropic, la guía de caché de contexto de Google Gemini y la guía de caché de contexto de DeepSeek para obtener los detalles actuales de implementación. Los precios y la elegibilidad de los modelos pueden cambiar, así que vuelve a comprobar estas fuentes en cada revisión material de costes.

Dónde encaja una pasarela de IA

Una pasarela de IA unificada no hace que las cachés de los proveedores sean portables. Cada proveedor sigue controlando su propia semántica de caché y facturación. Sin embargo, una pasarela puede ofrecer a los equipos un único lugar para normalizar identificadores de modelos, enrutar cargas de trabajo elegibles, registrar el uso específico del proveedor, comparar el coste por tarea aceptada y aplicar políticas de fallback o de presupuesto.

Flatkey proporciona un endpoint compatible con OpenAI y un saldo unificado para acceder a varias familias de modelos. Eso facilita comparar flujos de trabajo con y sin caché sin reconstruir cada integración. Confirma la compatibilidad actual del modelo seleccionado con la caché y el comportamiento del proveedor antes de tratar una ruta como habilitada para caché.

Si primero estás consolidando clientes existentes, usa la lista de verificación de migración a una pasarela de API compatible con OpenAI y revisa el acceso actual a modelos y los precios de Flatkey.

Preguntas frecuentes

¿Cuánto puede ahorrar la caché de prompts?

El ahorro depende del prefijo reutilizable, la tasa de aciertos, los precios del proveedor, los cargos por escritura o almacenamiento y el coste de implementación. Calcula el ahorro neto a partir de los tokens en caché observados, en lugar de aplicar el descuento destacado a todos los tokens de entrada.

¿Qué tasa de acierto de caché es buena?

No existe un objetivo universal. Un porcentaje de aciertos útil es aquel que produce ahorros netos positivos y mejora o preserva el coste por tarea aceptada. Los prefijos grandes pueden justificar porcentajes de acierto más bajos; los prefijos pequeños pueden necesitar una reutilización muy alta.

¿La caché de prompts mejora la latencia?

Puede reducir la latencia de procesamiento de entrada en los aciertos de caché, pero el efecto depende del proveedor, el modelo, el tamaño del prompt, la ruta de red y la carga de trabajo. Haz un seguimiento de la latencia P50 y P95 en lugar de asumir una mejora fija.

¿Debería cachear toda la conversación?

Normalmente deberías maximizar un prefijo estable, no cachearlo todo a ciegas. Los turnos de la conversación crecen y cambian. Mantén al principio las instrucciones estables, las herramientas y el contenido de referencia, y luego añade el historial cambiante y la entrada del usuario.

¿Se pueden compartir los prompts en caché entre proveedores?

No. Las cachés de prompts del lado del proveedor son específicas de cada proveedor. Si el enrutamiento cambia el proveedor o el modelo, trata la solicitud como un posible fallo de caché, salvo que el proveedor documente explícitamente una reutilización compatible.

¿Es segura la caché de prompts para datos sensibles?

Revisa el tratamiento de datos del proveedor, el aislamiento de la caché, la retención, la residencia y las condiciones de retención cero para tu cuenta y modelo. No uses la optimización de costes para eludir requisitos de seguridad, privacidad o aislamiento entre inquilinos.

Empieza con un prefijo repetido

El mejor flujo de trabajo de caché de prompts es deliberadamente limitado: elige una carga de trabajo costosa y de alta reutilización; mueve el contenido estable al principio; versiona; mide aciertos, fallos, latencia, calidad y coste; y luego calcula el ROI neto.

Cuando el resultado mejore el coste por tarea aceptada, amplía el patrón al siguiente flujo de trabajo. Cuando no lo haga, la telemetría te dirá si el problema es la fragmentación del prompt, un volumen insuficiente, una retención corta, la fijación de precios del proveedor o una carga de trabajo que nunca fue un buen candidato para la caché.