En la mayoría de las aplicaciones LLM en producción, el prompt de sistema, la documentación de contexto o el historial de conversación representan la mayor parte del texto de entrada en cada llamada. Si su prompt de sistema tiene mil tokens y atiende diez mil peticiones al día, pagará por diez millones de tokens — la mayoría de ellos el mismo texto una y otra vez. El prompt caching resuelve este problema a nivel de infraestructura: el proveedor almacena la representación KV de los prefijos repetidos y no los recalcula en las siguientes llamadas.
Este artículo explica cómo funciona el prompt caching por dentro, en qué condiciones reduce significativamente el coste y la latencia, qué cachear concretamente y cuándo el caching no ayuda — o incluso añade costes. También está relacionado con cómo diseñar prompts que se cacheen bien, algo que muchos equipos pasan por alto.
Cómo funciona el prompt caching
Cuando envía una petición a la API de un LLM, el modelo calcula para cada token de entrada la denominada KV cache (vectores key-value) — la base del mecanismo de self-attention a través del cual el modelo evalúa las relaciones entre tokens. Este cálculo no es gratuito: es trabajo de GPU que afecta directamente al coste y al tiempo hasta el primer token (TTFT).
El prompt caching (también llamado context caching o prefix caching) dice lo siguiente: si el inicio del prompt — el prefijo — es el mismo en múltiples llamadas, el proveedor calcula su representación KV una vez, la almacena en el servidor y en las peticiones siguientes simplemente la carga en lugar de recalcularla. Desde el punto de vista del que llama esto es transparente — las respuestas son igual de correctas, solo más baratas y rápidas.
Lo que esto significa en números:
- En Anthropic: cache read = 10 % del precio habitual del token de entrada (90 % de ahorro); cache write = 125–200 % del precio habitual del token de entrada (ligero sobrecoste en la primera escritura)
- En OpenAI: automático, cache read = 50 % del precio del token de entrada; sin código explícito por parte del que llama
- Ahorro real en producción: típicamente 50–70 % del total de costes de tokens de entrada en workloads con prefijos largos y repetidos
La economía es pues la siguiente: en la primera llamada se paga algo más por el cache write, pero cada lectura posterior del mismo prefijo es notablemente más barata. El beneficio llega desde la segunda lectura y, con miles de llamadas al día, el ahorro es sustancial.
TTL y consistencia del prefijo
El prefijo cacheado no dura para siempre. Anthropic ofrece TTL (time-to-live) de 5 minutos o 1 hora — al expirar, la caché se invalida y en la siguiente llamada el prefijo se recalcula de nuevo (otro cache write). OpenAI gestiona el TTL de forma automática sin configuración explícita.
De esto se derivan dos consecuencias prácticas. Primera: si tiene un workload donde las peticiones con el mismo prefijo llegan en poco tiempo (por ejemplo, en cuestión de segundos o minutos), el caching funciona bien. Si las peticiones se distribuyen a lo largo del día con pausas de una hora y utiliza un TTL de 5 minutos, la caché se invalidará con regularidad. Segunda: el prefijo debe ser idéntico byte a byte. Incluso un pequeño cambio (un espacio distinto, una fecha formateada de forma diferente en el prompt de sistema) invalida toda la representación cacheada y desencadena un nuevo cache write.
Qué tiene sentido cachear
No todo el texto de un prompt merece ser cacheado. La selección parte de una lógica simple: tiene sentido cachear lo que es largo, estático y de uso repetido.
El prompt de sistema. El candidato más obvio. Si tiene 500–2000 tokens de instrucciones de sistema (rol, contexto, reglas de comportamiento, ejemplos few-shot), estos no cambian en absoluto o solo raramente en la mayoría de las aplicaciones. Colóquelos como prefijo fijo al inicio del prompt — el caching los cubrirá automáticamente.
Documentos y normas compartidos. Si cada petición incluye el mismo manual técnico, norma ISO, reglamento de empresa o documento legal como contexto de referencia, es un candidato ideal. Hemos visto despliegues donde una documentación técnica de 300 páginas se insertaba en cada llamada de un chatbot de atención al cliente — el caching redujo los costes más de un 80 % en ese caso.
Historial de conversación largo. En chats multi-turn, la aplicación envía todo el historial anterior con cada nueva petición. La parte más antigua del historial no cambia — es un prefijo estable y creciente. El caching funciona aquí siempre que la aplicación formatee la conversación de forma consistente y no reordene los mensajes.
Ejemplos few-shot. Si utiliza en el prompt de sistema varios ejemplos largos entrada-salida (el llamado few-shot prompting), estos también son estáticos y reutilizables. Inclúyalos en el prefijo cacheado.
Qué no tiene sentido cachear:
- Prompts cortos o de un solo uso — pagará más por el cache write pero nunca recuperará el beneficio
- Prompts donde cada petición difiere desde el principio (por ejemplo, generación de informes variables sin prefijo común)
- Sistemas con formato inconsistente — un cambio aleatorio en el orden de los parámetros del prompt de sistema basta para invalidar la caché
Cómo diseñar prompts para el caching
Uno de los descuidos más frecuentes que encontramos al revisar aplicaciones existentes: los equipos activan el caching, pero la estructura del prompt no está diseñada para aprovecharlo con eficiencia.
Regla básica: lo estático antes que lo dinámico. El caching cubre el prefijo — el inicio del prompt. Por eso todo lo que cambia por petición (la pregunta concreta del usuario, parámetros variables, la fecha actual) debe ir al final del prompt. Si inserta un elemento dinámico en medio del contexto estático, el prefijo cambiará en cada llamada y el caching no tendrá efecto.
Ejemplo de orden incorrecto:
Prompt de sistema (estático)
↓
Fecha actual y nombre del usuario (dinámico — cambia en cada petición)
↓
Manual técnico (estático, 800 tokens)
↓
Pregunta del usuario (dinámica)En este ejemplo, el elemento dinámico en medio invalida el caching para todo el manual técnico que hay debajo.
Orden correcto:
Prompt de sistema (estático)
↓
Manual técnico (estático, 800 tokens)
↓
Fecha actual y nombre del usuario (dinámico)
↓
Pregunta del usuario (dinámica)El bloque estático es ahora un prefijo coherente — el proveedor lo cachea y los elementos dinámicos no lo afectan.
Formato estable. Si su prompt de sistema genera código, evite insertar valores variables (timestamp, versión) directamente en la parte estática. En lugar de Versión actual del sistema: 2.4.1 (desplegada 2026-03-20) use Versión actual del sistema: {version} e inserte el valor en la parte dinámica o, mejor aún, en el user message.
En on-prem (vLLM, SGLang) rigen los mismos principios. Tanto vLLM como SGLang implementan el prefix caching por su propio camino — SGLang mediante RadixAttention (árbol LRU de KV caches), vLLM mediante PagedAttention con gestión de bloques prefix-aware. Ambos frameworks reconocen automáticamente los prefijos repetidos y no repiten su cálculo. Los detalles difieren, pero el principio de diseño — lo estático antes que lo dinámico — es igualmente válido. Más información sobre la elección del framework de serving en vLLM vs SGLang vs Ollama.
Cuándo el caching ayuda mucho — y cuándo no
Un test sencillo: calcule qué porcentaje de los tokens de entrada constituye el prefijo estático repetido. Si supera el 50 %, el caching es probablemente una inversión con sentido. Si cada petición es única, el caching no ayudará.
Escenarios con ahorro alto:
- RAG con contexto largo. Aplicaciones que en cada llamada insertan la misma documentación compartida como contexto (reglamentos de empresa, manuales, normas). El contexto cacheado se carga al 10 % del precio.
- Atención al cliente con prompts de sistema largos. Un chatbot de atención al cliente típico en producción tiene un prompt de sistema de 500–1500 tokens que describe el producto, las reglas, el tono y los ejemplos. Con miles de llamadas al día el ahorro es sustancial.
- Agentes multi-turn con historial acumulado. Sesiones conversacionales donde el historial se escribe en el contexto. La parte más antigua del historial se convierte en un prefijo estable — el caching crece aquí orgánicamente con la longitud de la conversación. Está directamente relacionado con cómo gestionar los costes de un agente de IA en producción.
- Procesamiento por lotes de documentos con instrucciones comunes. Si procesa miles de facturas, registros de servicio u órdenes de compra con las mismas instrucciones de extracción, las instrucciones se cachean y solo paga por los propios documentos.
Escenarios con ahorro bajo o nulo:
- Tareas generativas one-shot. Escríbame una anotación para este vídeo, traduzca este texto, genere un informe — cada petición es única también en la parte del sistema. Pagará el cache write de más pero nunca lo recuperará.
- Workload de bajo volumen. Si la aplicación realiza cien llamadas al día, los ahorros absolutos son pequeños. El overhead de implementación (refactorización de prompts, monitorización del hit rate) puede no amortizarse.
- Prompts de sistema cortos. Si tiene un prompt de sistema de 50 tokens, ni siquiera se cumple el tamaño mínimo para cachear (Anthropic exige un prefijo de al menos 1024 tokens).
Medición de la eficiencia del caching
Desplegar sin medir es navegar a ciegas. Tres métricas que seguir:
Cache hit rate. Proporción de peticiones en las que el prefijo se cargó desde caché respecto al total de peticiones. En Anthropic, la API devuelve en la respuesta cache_read_input_tokens y cache_creation_input_tokens. OpenAI devuelve cached_tokens en el objeto usage. Objetivo: con prompts bien estructurados, el hit rate debería ser del 80–95 % con un workload estable.
Media de tokens de entrada por petición. Si el caching funciona, el precio efectivo de los tokens de entrada baja — los tokens de cache read se facturan más baratos. Siga la media móvil del coste de entrada por petición en el tiempo.
TTFT (Time to First Token). El prefijo cacheado elimina el recálculo, lo que reduce el TTFT. Si observa una distribución bimodal de la latencia (algunas peticiones más rápidas, otras más lentas), probablemente sea consecuencia de las diferencias entre cache hit y cache miss.
Incorpore estas métricas a su pipeline de observabilidad — por ejemplo mediante logs estructurados o seguimiento en agent observability y tracing.
Comparativa de proveedores cloud
Los enfoques también difieren en los detalles de implementación, lo que influye en cómo diseña el caching.
Anthropic (Claude): Explícito — en la petición debe marcar los bloques que desea cachear mediante el parámetro cache_control. Le da control sobre qué se cachea exactamente. TTL de 5 minutos o 1 hora (según configuración). Mínimo para cachear: 1024 tokens. Cache write es el 125–200 % del precio del token de entrada habitual; cache read es el 10 %.
OpenAI (GPT): Implícito — automático, sin código. El proveedor reconoce por sí solo los prefijos repetidos y los cachea. Cache read = 50 % del precio del token de entrada. Más fácil de activar, menos control sobre qué se cachea.
Google (Gemini): Context caching explícito mediante API, similar a Anthropic. TTL más largo — horas o días. Adecuado para contextos largos muy estables (manuales completos, bases de código).
On-prem (vLLM, SGLang): El prefix caching está integrado y funciona automáticamente con prefijos repetidos. No se paga extra por el write — los costes de cómputo son propios, pero con prefijos repetidos el framework de serving ahorra tiempo de GPU, lo que aumenta el throughput y reduce la latencia. Esta ventaja es clave en despliegues privados con hardware propio.
Preguntas frecuentes
¿Es seguro el prompt caching — mis datos se quedan en los servidores del proveedor?
Sí, la representación KV cacheada permanece en los servidores del proveedor durante la ventana de TTL. Para la mayoría de las empresas esto no supone un problema — las llamadas a la API van allí de todas formas. Para organizaciones con requisitos estrictos de residencia de datos (hospitales, bancos, sectores regulados), el serving on-prem con vLLM o SGLang es mejor opción, ya que la caché queda completamente bajo su control. Más información en LLM on-prem para sectores regulados.
¿Puede el caching afectar negativamente a la calidad de las respuestas?
No — el caching solo afecta a la rapidez con que los vectores KV del prefijo llegan a memoria, no a los valores que tienen. El modelo recibe un contexto idéntico tanto si el prefijo se calculó de nuevo como si se cargó desde caché. Las respuestas son las mismas.
¿Vale la pena el caching para una aplicación pequeña con pocos cientos de llamadas al día?
Depende de la longitud del prompt de sistema y del precio del modelo. Para un prompt de sistema de 1000 tokens y 500 llamadas al día con un modelo frontier, los ahorros mensuales son del orden de unos pocos euros — en el límite de si merece la pena refactorizar el código. Con 50 000 llamadas al día y un prompt de 2000 tokens, los ahorros son del orden de cientos de euros al mes o más — ahí el sentido es claro.
¿Qué pasa si mi prompt de sistema necesita actualizarse cada hora (por ejemplo, si inserto la hora actual o el estado del stock)?
Es una trampa clásica. Si el valor dinámico está dentro del bloque cacheado, cada cambio invalida la caché. La solución: saque el valor dinámico del prefijo cacheado y llévelo al user message o a un bloque no cacheado al final del prompt. El prompt de sistema cacheado no cambia; el valor dinámico va junto a él.
¿Funciona el prompt caching también con salida estructurada (modo JSON)?
Sí. El caching es independiente del formato de salida. El prefijo cacheado puede ser una combinación de instrucciones de sistema y esquema JSON, siempre que sea estático — el modelo genera según él y el cache hit rate no cambia. Más sobre salida estructurada en structured outputs y modo JSON.
Conclusión
El prompt caching no es una revolución — es una optimización de infraestructura que funciona de forma silenciosa y fiable siempre que diseñe la aplicación para aprovecharlo. Tres cosas son clave: identificar el prefijo estático en sus prompts, colocarlo de forma consistente al inicio y medir el hit rate. En workloads con miles de llamadas al día y contextos comunes largos, este cambio puede reducir la factura de la API de LLM en varias decenas de porcentaje sin ninguna modificación en la lógica de la aplicación.
*En MP Industrial Solutions, al revisar aplicaciones LLM de clientes, encontramos regularmente estructuras de prompts donde el caching no está aprovechado — o donde un elemento dinámico en medio del contexto estático echa a perder todo el efecto. Si quiere que analicemos su aplicación e identifiquemos los ahorros concretos, con mucho gusto nos reunimos para una consultoría.*