La caché de prompts puede reducir el costo y la latencia de solicitudes LLM repetidas, 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 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: encontrar tráfico elegible, dar forma a los prompts para su reutilización, instrumentar métricas de caché, calcular el ahorro neto y desplegar sin ocultar regresiones de calidad o fiabilidad. También incluye una auditoría de siete días que convierte los campos de uso del proveedor en una decisión de seguir, corregir o detener.
ROI de la caché de prompts: la respuesta rápida
Por lo general, vale la pena probar la caché de prompts cuando un flujo de trabajo envía repetidamente un prefijo grande e idéntico en bytes dentro de la ventana de retención del proveedor. No es automáticamente rentable solo porque un modelo anuncie tokens en caché con descuento.
Use este filtro de tres partes antes de cambiar los prompts de producción:
| Filtro | Condición de aprobación | Condición de detener |
|---|---|---|
| Reutilización | El mismo prefijo se usa varias veces antes de expirar | La mayoría de los prefijos son de un solo uso o exclusivos de cada usuario |
| Economía | El ahorro observado en lecturas supera el costo de escrituras, almacenamiento y operación | La caché se crea más veces de las que se reutiliza |
| Resultado | El costo por tarea aceptada mejora sin una regresión de calidad o fiabilidad | Un menor costo por token provoca más reintentos, salidas rechazadas o un fallback inseguro |
El cálculo principal es:
net_savings = uncached_baseline_cost
- observed_cached_workflow_cost
- incremental_engineering_and_operations_cost
roi_percent = net_savings
/ incremental_engineering_and_operations_cost
× 100
Si el costo de implementación se comparte entre muchas identidades de caché, amortícelo durante el período de evaluación esperado en lugar de asignar el costo total del proyecto a una sola entrada.
¿Qué cambió para la caché de prompts en 2026?
La caché de prompts ya no es un único mecanismo uniforme de descuento. Los diseños de los proveedores ahora difieren lo suficiente como para que una hoja de cálculo genérica de "los tokens en caché son más baratos" pueda dar una respuesta incorrecta.
Por ejemplo, la documentación actual de GPT-5.6 de OpenAI describe coincidencia automática de prefijos, controles explícitos de prompt_cache_key y cache_control, y uso separado de lectura y escritura de caché. Las escrituras de caché para ese modelo pueden conllevar un recargo, por lo que el cálculo del punto de equilibrio debe incluir el costo de crear o extender una caché, no solo las lecturas con descuento. OpenAI también expone detalles de tokens en caché, sin caché y de escritura de caché en los campos de uso para las solicitudes compatibles.
Anthropic utiliza puntos de corte explícitos de caché y opciones de tiempo de vida (TTL). La caché de contexto explícita de Gemini puede añadir cargos de almacenamiento. DeepSeek documenta la caché automática de contexto con tasas separadas de aciertos y fallos. Todos estos diseños pueden generar ahorros, pero necesitan una telemetría y fórmulas diferentes.
¿Qué es la caché de prompts?
La caché de prompts permite que un proveedor de LLM reutilice el cálculo del contenido del prompt que ha procesado recientemente. En lugar de cobrar y procesar cada token de entrada repetido a la tarifa normal, el proveedor puede aplicar una tarifa de entrada en caché más baja o un precio de lectura de caché separado a la parte reutilizable.
El contenido reutilizable suele ser un prefijo de prompt estable. Los ejemplos comunes incluyen:
- Un prompt de sistema largo y un bloque de políticas.
- Definiciones de herramientas compartidas por cada turno del agente.
- Un gran documento, mapa del repositorio o catálogo de productos consultado repetidamente.
- Ejemplos few-shot reutilizados en una tarea 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 el almacenamiento en caché automático para prefijos de prompt que cumplan los requisitos y expone detalles de tokens en caché en el uso de la API; los modelos más nuevos compatibles también pueden exponer detalles de escritura en caché. 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 el almacenamiento en caché de contexto automático basado 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 comprometer ahorros en una previsión.
El error del ROI: medir el descuento en lugar del flujo de trabajo
Un descuento por token en caché no es lo mismo que el 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 con demasiada agresividad.
Mida la unidad que importa:
ROI neto de caché de prompts = costo de entrada sin caché evitado - costo de escritura/almacenamiento de caché - costo de implementación y operación
Para decisiones de producción, conecte ese resultado con un desenlace aceptado:
Costo por tarea aceptada = costo 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 costos de la API de IA en lugar de tratar la caché como un truco aislado de facturación.
Un flujo de trabajo de caché de prompts en seis pasos
1. Encuentre cargas de trabajo con reutilización real de prefijos
Empiece con trazas de solicitudes, no con intuición. Agrupe el tráfico por flujo de trabajo y estime cuántos tokens de entrada permanecen idénticos desde el comienzo de una solicitud hasta la siguiente.
Los buenos candidatos suelen tener cuatro propiedades:
- Entrada repetida grande: el prefijo reutilizable es material en relación con el sufijo dinámico.
- Reutilización frecuente: varias solicitudes hacen referencia al mismo prefijo dentro de la vida útil efectiva de la caché del proveedor.
- Orden estable: las instrucciones del sistema, las herramientas, los ejemplos y el material de referencia aparecen en el mismo orden.
- 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 de alto potencial incluyen agentes de código con esquemas de herramientas estables, asistentes de soporte fundamentados 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 multiturno.
Los malos candidatos incluyen prompts cortos de uso único, prefijos altamente personalizados, solicitudes que cambian las definiciones de herramientas en cada llamada y tareas de bajo volumen que rara vez reutilizan una entrada de caché.
Construya una tabla base para cada flujo de trabajo:
| Métrica | Por qué importa |
|---|---|
| Solicitudes por día | Determina el volumen de reutilización |
| Tokens de entrada promedio | Establece el costo total de entrada |
| Tokens de prefijo reutilizables | Define la superficie cacheable |
| Variantes de prefijo | Revela fragmentación |
| Intervalo de reutilización | Prueba si las entradas siguen siendo útiles |
| Tasa de tareas aceptadas | Protege la calidad y el valor empresarial |
| Latencia P50/P95 | Mide el impacto en el rendimiento |
2. Coloque el contenido estático antes del contenido dinámico
La caché de prompts normalmente depende 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.
Use este orden cuando el proveedor y el SDK lo permitan:
1. Instrucciones del sistema estables
2. Normas de política y seguridad estables
3. Definiciones de herramientas estables
4. Material de referencia o ejemplos estables
5. Contexto conversacional semiestable
6. Entrada dinámica del usuario y valores en tiempo de ejecución
No coloque marcas de tiempo, IDs de solicitud, etiquetas específicas del usuario, JSON con orden aleatorio o banderas de funciones que cambian con frecuencia cerca del inicio del prompt. Normalice los esquemas de herramientas y serialice el contenido estructurado de forma determinista.
Esto no le da permiso para combinar datos no relacionados en un prefijo sobredimensionado. Mantenga 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 una falla de privacidad o aislamiento.
3. Defina una identidad de caché y una política de invalidación
Su aplicación necesita una forma explícita de razonar sobre las versiones del prompt, incluso cuando el proveedor gestione la caché automáticamente.
Una identidad de caché práctica puede incluir:
flujo_de_trabajo + versión_del_prompt + versión_del_esquema_de_herramientas + versión_del_conocimiento + familia_del_modelo
Haga seguimiento de esta identidad en la telemetría. Cuando cambien las instrucciones, los contratos de herramientas o los datos de referencia, incremente la versión correspondiente. Eso hace que los cambios de costo sean explicables y evita que los equipos confundan una invalidación esperada con una interrupción del proveedor.
Establezca una ventana de reutilización según el comportamiento de la carga de trabajo y el soporte 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 costo de almacenamiento sigue siendo menor que el procesamiento repetido de entradas.
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 caché.
- Tokens totales de entrada, en caché/leídos, de escritura en caché y de salida cuando se expongan.
- Estado de acierto de caché o acierto inferido.
- Costo estimado de entrada, caché, salida y total.
- Latencia, estado, número de reintento y ruta de respaldo.
- Resultado de éxito validado o tarea aceptada.
Use los campos de uso informados por el proveedor como fuente de verdad de la facturación cuando estén disponibles. Si un proveedor no devuelve un indicador claro de acierto de caché, infiéralo con cuidado 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 debe ir en el mismo trace que los reintentos y el fallback del modelo. De lo contrario, una tormenta de reintentos puede parecer una optimización exitosa de la caché. La lista de verificación de implementación de observabilidad de IA muestra cómo conectar el costo por intento con los resultados de la aplicación.
5. Calcule los ahorros y el volumen de punto de equilibrio
Use un modelo que se ajuste a la estructura de cobro del proveedor.
Para la caché automática con una tarifa de lectura descontada:
gross_savings = cache_read_tokens × (uncached_input_rate - cached_input_rate)
net_savings = gross_savings - incremental_operating_cost
Para la caché explícita con cargos de escritura y almacenamiento:
net_savings = avoided_uncached_cost
- cache_write_cost
- cache_storage_cost
- incremental_operating_cost
Para un proveedor o modelo que cobra tarifas de token diferentes para escrituras y lecturas de caché, calcule el ciclo de vida de un prefijo reutilizable:
uncached_scenario = prefix_tokens × total_uses × uncached_rate
cached_scenario = prefix_tokens × cache_writes × write_rate
+ prefix_tokens × cache_reads × read_rate
+ storage_cost
prefix_net_savings = uncached_scenario - cached_scenario
No asuma cache_writes = 1. Un prefijo modificado, una entrada caducada, un cambio de enrutamiento o una actualización explícita pueden crear otra escritura.
Puede estimar el número de reutilizaciones para el punto de equilibrio de 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 completa. Luego añada un margen para errores de caché, invalidaciones y variabilidad del tráfico.
Ejemplo de ROI trabajado
Suponga que un flujo de trabajo tiene:
- 40,000 solicitudes por mes.
- 18,000 tokens de entrada por solicitud.
- Un prefijo estable de 12,000 tokens.
- Una tasa efectiva de aciertos de caché del 70%.
- Una tasa de entrada sin caché de $3 por millón de tokens.
- Una tasa de entrada con caché de $0.30 por millón de tokens.
- $350 por mes en costo amortizado de ingeniería y monitoreo.
Tokens en caché mensuales:
40,000 × 12,000 × 70% = 336,000,000 tokens de entrada en caché
Ahorros brutos:
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 aproximadamente $0.017 en ahorros 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 entradas con caché.
Las tarifas anteriores son ilustrativas, no una cotización actual del proveedor. Reemplácelas con sus tarifas contratadas o publicadas e incluya escrituras de caché, almacenamiento, precios regionales, niveles de servicio y cargos de gateway cuando corresponda.
Hoja de cálculo de ROI de caché de prompts copiable
Construya la hoja de cálculo a nivel de flujo de trabajo y versión del prompt. Una tasa de aciertos agregada a nivel de cuenta puede ocultar una caché rentable y muchas ineficientes.
| Entrada | Símbolo | Pregunta de ejemplo |
|---|---|---|
| Solicitudes elegibles | R |
¿Cuántas solicitudes podrían reutilizar este prefijo? |
| Tokens del prefijo | P |
¿Cuántos tokens iniciales son estables? |
| Lecturas de caché | H |
¿Cuántas solicitudes elegibles realmente leen tokens almacenados en caché? |
| Escrituras en caché | W |
¿Cuántas veces se creó o amplió el prefijo? |
| Tasa de entrada sin caché | U |
¿Cuánto costarían estos tokens sin caché? |
| Tasa de lectura de caché | C |
¿Cuánto cobra el proveedor por un acierto? |
| Tasa de escritura en caché | CW |
¿La creación se tarifica como entrada estándar o con una prima? |
| Coste de almacenamiento | S |
¿La retención se factura por token-hora o por otra unidad? |
| Coste operativo | O |
¿Qué coste de supervisión y mantenimiento es atribuible al flujo de trabajo? |
| Tareas aceptadas | A |
¿Cuántos resultados superaron la comprobación de aceptación en producción? |
Usa estas fórmulas:
eligible_prefix_tokens = R × P
observed_cached_tokens = H × P
baseline_prefix_cost = eligible_prefix_tokens × U
observed_prefix_cost = (H × P × C)
+ (W × P × CW)
+ S
net_savings = baseline_prefix_cost - observed_prefix_cost - O
net_savings_per_accepted_task = net_savings / A
Usa unidades de tarifa coherentes, como dólares por token o dólares por millón de tokens. Si solo se informa de una parte de un prefijo como almacenada en caché, sustituye H × P por el total de tokens almacenados en caché informado por el proveedor.
Atajo de punto de equilibrio para una escritura en caché
Cuando hay una escritura inicial, no hay tarifa de almacenamiento separada y cada uso posterior es un acierto:
break_even_reads = (write_rate - uncached_rate)
/ (uncached_rate - read_rate)
Redondea hacia arriba al siguiente número entero de lecturas. Si la tasa de escritura es igual a la tasa normal sin caché, la primera reutilización exitosa genera ahorros brutos. Si las escrituras tienen una prima, se requieren lecturas adicionales. El punto de equilibrio real en producción será mayor tras los fallos, las invalidaciones, el almacenamiento y el coste de ingeniería.
6. Despliega con un experimento controlado
Ejecuta la caché como un cambio de ingeniería con un grupo de control medible.
- Selecciona un flujo de trabajo con alta reutilización.
- Congela el conjunto de evaluación y los criterios de aceptación.
- Establece líneas base de coste, latencia y calidad sin caché.
- Reestructura solo el prefijo estable.
- Envía una pequeña parte del tráfico de producción por la ruta en caché.
- Compara la tasa de acierto, el coste por tarea aceptada, la latencia P95, los errores y los mecanismos de reserva.
- Amplía solo cuando los ahorros sigan siendo positivos tras el coste operativo.
Ejecuta el control y el tratamiento con tráfico equivalente. Mantén fijos, siempre que sea posible, el modelo, el nivel de servicio, la salida máxima, los parámetros de muestreo, el conjunto de herramientas y la política de reserva. De lo contrario, un cambio de modelo o de enrutamiento puede confundirse con un beneficio de la caché.
Antes de una implantación amplia, realiza tres pruebas deliberadas de invalidación:
- Cambie la versión del prompt y confirme que la caché antigua no se atribuya incorrectamente al nuevo flujo de trabajo.
- Cambie o reordene un esquema de herramienta y verifique que el fallo resultante sea visible en la telemetría.
- Active la ruta de reversión aprobada y confirme que la pérdida de caché y el costo incremental se atribuyan al intento de reversión.
Mantenga las políticas de reintento y reversión separadas de la lógica de caché. Una solicitud fallida puede ser segura de reintentar, insegura de reproducir después de una transmisión parcial o estar mejor atendida por un modelo equivalente. Use una estrategia de reversión de modelo definida en lugar de tratar cada fallo de caché o tiempo de espera como el mismo error.
Una auditoría de ROI de caché de prompts de siete días
Una auditoría breve en producción es más fiable que una previsión basada en un descuento de caché anunciado. El objetivo no es demostrar que la caché funciona en general. Es determinar si un flujo de trabajo específico, una versión de prompt, una ruta de modelo y una política de retención producen un valor repetible.
Genere una fila de auditoría por día y mantenga el control sin caché en funcionamiento durante toda la prueba. Si el tráfico entre semana y el de fin de semana difiere, amplíe la prueba hasta que aparezcan ambos patrones. No compare un día de tratamiento con mucha actividad con una línea base histórica tranquila.
| Day | Action | Evidence to capture | Decision question |
|---|---|---|---|
| 0 | Bloquee el experimento | ID del flujo de trabajo, versión del prompt, modelo, ruta del proveedor, política de reversión, prueba de aceptación | ¿Puede otro ingeniero reproducir la configuración? |
| 1 | Mida el control | Solicitudes, tokens de entrada, tokens de salida, costo, latencia P50/P95, tareas aceptadas | ¿Cuánto cuesta el flujo de trabajo sin caché? |
| 2 | Habilite un tratamiento limitado | Escrituras en caché, lecturas, fallos, modo de retención, tasa de error | ¿Están completos y correctamente analizados los campos de uso? |
| 3 | Diagnostique la localidad | Cardinalidad del prefijo, identidades de caché, motivos de fallo, versiones del esquema de herramientas | ¿Los fallos están causados por baja reutilización o por fragmentación de la implementación? |
| 4 | Pruebe la invalidación | Cambio de versión del prompt, cambio de herramienta, expiración de la retención | ¿La telemetría distingue la invalidación intencional de los fallos sin explicación? |
| 5 | Pruebe la fiabilidad | Escenarios de reintento y de reversión aprobada | ¿Cuánta localidad de caché se pierde durante los fallos? |
| 6 | Conciliar la economía | Coste de referencia, coste observado, coste de escritura/almacenamiento, coste operativo | ¿El ahorro neto es positivo después de cada cargo relevante? |
| 7 | Tome la decisión | Ahorro ajustado por calidad, rango de confianza, responsable, fecha de próxima revisión | ¿El equipo debe ampliar, corregir o detenerse? |
Use cohortes emparejadas, no promedios de toda la cuenta
Asigne solicitudes comparables al control y al tratamiento mediante una regla estable, como un hash del ID del flujo de trabajo más el ID del inquilino. Esto reduce la posibilidad de que la combinación de clientes, la longitud del prompt o la dificultad de la tarea expliquen el resultado. No excluya ni los fallos ni los reintentos de los totales de costo; forman parte de la economía de producción.
Como mínimo, segmente la auditoría por:
- Flujo de trabajo y versión del prompt.
- Modelo y ruta del proveedor.
- Modo de retención de caché o TTL.
- Clase de tenant cuando los prompts difieren materialmente.
- Resultado de éxito, reintento, fallback y salida rechazada.
Una tasa de aciertos de caché a nivel de cuenta es útil para el monitoreo, pero débil para las decisiones de inversión. Un flujo de trabajo de alto volumen puede ocultar decenas de identidades de caché que se escriben continuamente y rara vez se leen.
Añadir comprobaciones de confianza y varianza
No trate un día de ahorro positivo como una señal de despliegue. Calcule los ahorros netos diarios e inspeccione el rango, no solo el total.
daily_net_savings = daily_uncached_baseline_cost
- daily_observed_cached_cost
- daily_operating_cost
quality_adjusted_savings = daily_net_savings
/ daily_accepted_tasks
Use la mediana de los ahorros diarios ajustados por calidad como el resumen principal y luego informe el peor día y la proporción de días que siguieron siendo positivos. Un flujo de trabajo con ahorros medios sólidos pero días negativos repetidos puede ser sensible a la forma del tráfico, el tiempo de expiración o el comportamiento del fallback.
Si el tráfico es bajo, defina un conteo mínimo de observación antes de que comience la auditoría. Una regla práctica es esperar hasta que cada cohorte tenga suficientes tareas aceptadas para incluir reintentos normales, misses y al menos un ciclo de expiración de retención. El conteo exacto depende de la varianza del flujo de trabajo; evite presentar un tamaño de muestra universal como estadísticamente válido para todas las aplicaciones.
Marco de decisión: seguir, corregir o detener
| Decisión | Evidencia requerida | Acción siguiente |
|---|---|---|
| Seguir | El ahorro neto es positivo en la mayoría de los días medidos; el costo por tarea aceptada mejora; la calidad, los errores y la latencia P95 se mantienen dentro de los límites aprobados | Amplíe el tráfico gradualmente y programe una revisión a 30 días |
| Corregir | Existe ahorro bruto, pero las escrituras, la fragmentación de prefijos, la expiración o la pérdida de caché por fallback hacen que los resultados sean inestables | Corrija la causa identificada y ejecute nuevamente la misma auditoría |
| Detener | El ahorro neto sigue siendo negativo, el costo de la tarea aceptada empeora o el flujo de trabajo no puede cumplir con los límites de calidad, seguridad o fiabilidad | Elimine la caché para este flujo de trabajo y conserve la evidencia |
Defina reglas de stop-loss antes del lanzamiento. Los ejemplos incluyen un aumento inaceptable en las salidas rechazadas, una regresión en la tasa de errores, un aumento material de la latencia P95, una identidad de caché entre tenants inesperada o un aumento del gasto diario por encima de la tolerancia presupuestaria del equipo. Los umbrales de stop-loss deben provenir de los objetivos de servicio existentes del producto y de la política de riesgo, no de una referencia genérica de blog.
El registro de auditoría que debe conservar
Guarde la decisión final junto con la configuración del prompt y del enrutamiento, no en una hoja de cálculo desconectada. Un registro de auditoría útil incluye el propietario, las fechas del experimento, el hash del prompt, el hash del esquema de herramientas, la ruta del modelo, las tarifas utilizadas, el mapeo bruto de campos de uso, la definición de tarea aceptada, las exclusiones, los ahorros netos, los resultados de los límites de guardarraíl, la decisión y la fecha de la próxima revisión.
Este registro se vuelve especialmente importante cuando cambian los precios, las versiones del modelo, el comportamiento de retención o las rutas de fallback. Reabra la decisión cuando cambie cualquier supuesto que afecte materialmente a las escrituras, lecturas, almacenamiento o resultados aceptados.
Panel de KPI de caché de prompts
Realice un seguimiento de las siguientes métricas por flujo de trabajo y versión del prompt:
| KPI | Fórmula o definición | Señal de decisión |
|---|---|---|
| Proporción de tokens almacenables en caché | Tokens de prefijo reutilizables / tokens de entrada totales | ¿Es lo suficientemente grande la superficie de optimización? |
| Tasa de aciertos de caché | Solicitudes de lectura de caché / solicitudes elegibles | ¿Realmente está ocurriendo la reutilización? |
| Proporción de tokens en caché | Tokens de entrada en caché / tokens de entrada totales | ¿Qué cantidad de entrada recibe la tarifa más baja? |
| Ahorro por solicitud | Costo base sin caché - costo observado | ¿Cada solicitud es más barata? |
| Ahorro neto | Ahorro bruto - costos de escritura, almacenamiento y operación | ¿El proyecto es financieramente positivo? |
| Costo por tarea aceptada | Costo total / tareas aceptadas | ¿Mejoró la economía ajustada por calidad? |
| Diferencia de latencia P95 | P95 en caché - P95 base | ¿Mejoró el rendimiento visible para el usuario? |
| Tasa de motivo de fallo | Fallos por versión, orden, TTL o proveedor | ¿Qué debería corregir ingeniería a continuación? |
| Relación escritura-lectura de caché | Escrituras de caché / lecturas de caché | ¿Se están creando entradas con demasiada frecuencia? |
| Cardinalidad de prefijos | Identidades de caché distintas / solicitudes elegibles | ¿La personalización está fragmentando la reutilización? |
| Tasa de pérdida de caché por fallback | Intentos de fallback que pierden la reutilización esperada de caché / fallbacks | Qué cuesta en localidad de caché la política de confiabilidad |
Una tasa de aciertos alta con ahorros débiles puede ocurrir cuando el prefijo repetido es pequeño. Una tasa de aciertos baja con un prefijo grande aún puede identificar una oportunidad valiosa si se puede corregir la fragmentación del prompt. Lea 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évalos después del prefijo estable cuando sea posible.
Los esquemas de herramientas cambian entre solicitudes
Los agentes suelen reconstruir o reordenar las definiciones de herramientas de forma dinámica. Normalice el orden, elimine las herramientas irrelevantes y version el esquema deliberadamente.
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. Mida 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 costo total. Siga midiendo la solicitud completa y el resultado aceptado.
Se asume que el comportamiento del proveedor es portable
El almacenamiento automático en caché 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. Construya un adaptador de proveedor y mantenga la métrica de negocio independiente del proveedor.
El fallback destruye la localidad de caché
Cambiar de proveedor o de familias 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 confiabilidad y el costo necesitan una política compartida: haga failover cuando sea necesario y luego atribuya correctamente el fallo y el costo incremental.
Lista de verificación de implementación del proveedor
Use un adaptador de proveedor en lugar de forzar cada implementación a un único campo booleano cache_hit:
| Patrón del proveedor | Campos de ROI que capturar | Riesgo principal de modelado |
|---|---|---|
| Caché automática de prefijos | Tokens en caché, tokens sin caché, modo de retención, clave de caché cuando sea compatible | La discrepancia de prefijo es invisible sin trazas versionadas |
| Puntos de interrupción explícitos | Tokens de creación de caché, tokens de lectura de caché, TTL | Demasiados puntos de interrupción o escrituras pueden borrar los ahorros |
| Contexto almacenado explícitamente | Coste de creación, recuento de tokens en caché, duración del almacenamiento y cargo | La retención inactiva puede costar más que una entrada repetida |
| Precios automáticos de acierto/fallo | Tokens de acierto en caché y de fallo en caché | El enrutamiento o los cambios de modelo restablecen la localidad |
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é tienen precios separados?
- ¿Qué campos de respuesta exponen los 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?
Usa la guía oficial 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 detalles actuales de implementación. Los precios y la elegibilidad de los modelos pueden cambiar, así que vuelve a comprobar estas fuentes durante cada revisión material de costes.
Comprobación de migración 2026 para paneles de caché de OpenAI existentes
Si tu panel es anterior al soporte de GPT-5.6, verifica que no agrupa todos los tokens de prefijo sin caché en el coste de entrada ordinario. Para las solicitudes compatibles con GPT-5.6, inspecciona por separado el uso de escritura en caché, registra el modo de retención y distingue las escrituras explícitas en caché de las lecturas automáticas de caché. Un panel que solo rastrea cached_tokens puede sobrestimar los ahorros cuando la creación de caché tiene una tarifa más alta.
Dónde encaja una pasarela de IA
Una pasarela de IA unificada no hace que las cachés del proveedor sean portables. Cada proveedor sigue controlando su propia semántica de caché y su facturación. Sin embargo, una pasarela puede dar a los equipos un único lugar para normalizar identificadores de modelo, 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 único 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 con la caché del modelo seleccionado y el comportamiento del proveedor antes de tratar una ruta como habilitada para caché.
Si primero está consolidando clientes existentes, use la lista de verificación de migración a una puerta de enlace API compatible con OpenAI y revise el acceso actual a modelos y la tarificación de Flatkey.
Preguntas frecuentes
¿Cuánto puede ahorrar la caché de prompts?
Los ahorros dependen del prefijo reutilizable, la tasa de aciertos, la tarificación del proveedor, los cargos por escritura o almacenamiento y el costo de implementación. Calcule el ahorro neto a partir de los tokens cacheados observados en lugar de aplicar el descuento destacado a todos los tokens de entrada.
¿Cuántos aciertos de caché se necesitan para llegar al punto de equilibrio?
Depende de la prima de escritura, el descuento de lectura, la tarifa de almacenamiento y el costo operativo. Con una escritura cobrada a la tarifa normal sin caché y sin tarifa de almacenamiento, la primera lectura exitosa crea ahorro bruto de tokens. Las escrituras con prima o la retención de pago requieren más reutilización. Calcule el punto de equilibrio a partir de las tarifas exactas y del recuento observado de escrituras en caché para el modelo seleccionado.
¿Qué tasa de aciertos de caché es buena?
No existe un objetivo universal. Una tasa de aciertos útil es la que produce ahorros netos positivos y mejora o mantiene el costo por tarea aceptada. Los prefijos grandes pueden justificar tasas de acierto más bajas; 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 para 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. Haga seguimiento de la latencia P50 y P95 en lugar de asumir una mejora fija.
¿Debería almacenar en caché toda la conversación?
Por lo general, debería maximizar un prefijo estable, no almacenar ciegamente todo en caché. Los turnos de la conversación crecen y cambian. Mantenga al principio las instrucciones estables, las herramientas y el contenido de referencia, y luego añada el historial cambiante y la entrada del usuario.
¿Se pueden compartir los prompts almacenados 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, trate la solicitud como un posible fallo de caché, a menos que el proveedor documente explícitamente una reutilización compatible.
¿La caché de prompts es segura para datos sensibles?
Revise el manejo de datos, el aislamiento de caché, la retención, la residencia y las condiciones de cero retención del proveedor para su cuenta y modelo. No use la optimización de costos para eludir requisitos de seguridad, privacidad o aislamiento entre inquilinos.
Empiece con un prefijo repetido
El mejor flujo de trabajo de caché de prompts es deliberadamente estrecho: elija una carga de trabajo costosa y de alta reutilización; lleve el contenido estable al principio; versionelo; mida aciertos, fallos, latencia, calidad y costo; y luego calcule el ROI neto.
Cuando el resultado mejore el costo por tarea aceptada, amplíe el patrón al siguiente flujo de trabajo. Cuando no lo haga, la telemetría le dirá si el problema es la fragmentación del prompt, un volumen insuficiente, una retención corta, la tarificación del proveedor o una carga de trabajo que nunca fue un buen candidato para la caché.
