Guía completa de Prompt Caching: principios, modelo de costes y buenas prácticas

Qué problema resuelve prompt caching

En la entrada de la mayoría de llamadas a un LLM, una parte considerable es siempre la misma: el system prompt, los ejemplos few-shot, los documentos fijos recuperados y las definiciones de herramientas (tool schema). Con la facturación normal, ese contenido repetido se paga como tokens de entrada en cada llamada y además se vuelve a calcular la atención cada vez.

La idea de prompt caching es directa: el servidor guarda el resultado del cálculo de ese prefijo y, si en la siguiente petición el prefijo es exactamente igual, lo reutiliza y solo recalcula la parte nueva. Anthropic lo presenta en su [documentación de prompt caching](https://platform.claude.com/docs/en/build-with-claude/prompt-caching) como un mecanismo para reducir latencia y coste; en el lado de OpenAI, el equivalente son el prompt caching automático y los descuentos por batch.

Qué escenarios realmente ahorran dinero

Prompt caching no es un interruptor que 'se activa y ya ahorra'. Tiene un umbral claro de rentabilidad: número de reutilizaciones del mismo prefijo × longitud del prefijo > coste adicional de escritura en caché.

• System prompt largo + conversación multiturno: con un system prompt de miles de tokens y muchos turnos de conversación, casi siempre sale rentable.
• RAG + conjunto fijo de documentos: coloca los documentos de políticas o la base de conocimiento invariables en el prefijo y deja que solo cambie la pregunta del usuario.
• Agentes de código / llamadas a herramientas: el esquema de herramientas y la descripción de la estructura del repositorio suelen repetirse en cada llamada.
• Llamadas puntuales con prefijos cortos: el coste de escribir en caché puede superar el ahorro; no fuerces el uso de caché.

Cinco errores habituales que invalidan la caché

• Incluir marcas de tiempo o IDs aleatorios en el prefijo: basta con poner Date.now() en una posición fija para que todo el prefijo cambie.
• Concatenar el system prompt de forma dinámica: si cada usuario recibe un prefijo distinto, la tasa de aciertos se diluye hasta casi 0.
• Resumir y comprimir los mensajes del historial: si se reescribe en cada turno, el prefijo deja de ser estable.
• Colocar la entrada del usuario al principio: es el error estructural más común; las variables deben ir lo más al final posible.
• Mirar solo la factura y no la tasa de aciertos: sin métricas de aciertos, el beneficio de la caché no se puede atribuir.

Reutilizar la misma estrategia de caché entre varios modelos

Si tu producto usa Claude y GPT a la vez, la semántica de caché no es idéntica entre proveedores (quién declara los puntos de corte de caché, cuánto dura el TTL, cómo se factura). Encapsular esta adaptación detrás de una pasarela unificada tiene la ventaja de que el código de negocio solo mantiene una estructura de prompt y no hay que reescribirla al cambiar de modelo.

La pasarela de Admesh mantiene el protocolo compatible con OpenAI hacia el downstream, de modo que la misma estructura de prompt puede cambiar de proveedor solo modificando el campo model; la facturación de los aciertos de caché se refleja de forma unificada en el detalle de usage de la factura, sin necesidad de integrar por separado el criterio de facturación de cada proveedor.

Ver unidades de facturación y explicación de tokens de caché →

Lista de comprobación para la implementación

1. Divide el prompt en tres tramos: 'prefijo estable / parte semiestable / entrada del usuario', y coloca la parte estable al principio.
2. Asegúrate de que en el prefijo estable no aparezcan marcas de tiempo, números aleatorios ni IDs de usuario.
3. Contabiliza por separado en la factura los tokens de lectura y escritura de caché y conviértelos en la tasa de aciertos real.
4. Usa un conjunto fijo de peticiones de evaluación para hacer regresiones periódicas y confirmar que los cambios en el prompt no han hundido la tasa de aciertos.
5. Fija un umbral mínimo de beneficio de caché (por ejemplo, revertir la estructura del prompt si baja del 5%) para no optimizar por optimizar.