Caché de prompts en LLM: guía completa de 2026 (reduce el coste de entrada entre un 50 y un 90%)

Si tienes en producción un chatbot, una aplicación RAG o un agente de IA conectado a un modelo de lenguaje grande, la caché de prompts es la única optimización que permite reducir entre un 50 y un 90% el coste de entrada y entre 3 y 10 veces el tiempo hasta el primer token, sin afectar a la calidad. No es un truco añadido a posteriori: se deriva directamente de la definición de la atención en los Transformers. Cuando entiendes esto, el resto de las piezas —TTL, diferencias entre proveedores y estructura de los prompts— encajan con claridad.

TL;DR

• La caché de prompts reduce entre un 50 y un 90% el coste de entrada y acelera entre 3 y 10 veces el tiempo hasta el primer token, sin afectar a la calidad.
• Mediciones del 2026-05-25: los marcadores cache_control de Claude redujeron el coste de entrada entre un 88 y un 89%; la caché automática de GPT-5.4-mini bajó el TTFT de 3.6s a 0.73s; DeepSeek-v4-flash ofreció un descuento del 74% con una caché respaldada en disco.
• Los TTL son cortos porque el estado KV ocupa muchísimo espacio: unos 10 GB para un contexto de 32K tokens en un modelo de la clase de 70B.
• DeepSeek almacena en caché con una granularidad de 64 tokens, frente al mínimo habitual de 1,024 tokens, por lo que las coincidencias parciales de prefijo también obtienen descuentos.

Esta página sirve como índice de una serie de cinco partes que cubre desde la teoría hasta una matriz de decisión para producción, además de la capa de frameworks donde realmente se construyen los prompts. Empieza por la parte que mejor encaje con lo que ya sabes.

Por dónde empezar

Cada parte se puede leer por separado, pero el orden propuesto permite construir una visión completa sin repetir contenido.

Parte 1 — Cómo funciona la caché de prompts en los LLM

Cómo funciona la caché de prompts en los LLM: caché KV y TTL →

El artículo sobre arquitectura. Resume la autoatención en una sola ecuación, explica por qué los vectores K y V de un prefijo estable son reutilizables matemáticamente y muestra cómo el compromiso entre memoria y cómputo da lugar al comportamiento de los TTL que todo desarrollador debe tener en cuenta al diseñar el sistema.

Puntos clave:

• La caché de prompts no es una optimización añadida por encima: es una consecuencia directa de la atención con máscara causal. K/V en la posición i es una función determinista de los tokens 1…i, por lo que dos prefijos idénticos producen valores K/V idénticos bit a bit.
• La caché evita el prefill —limitado por cómputo, O(N²)—. El decode —limitado por el ancho de banda de memoria, O(N) por token— ya lo optimizan todos los motores de inferencia.
• Los TTL existen porque la caché KV es enorme: ~10 GB para un contexto de 32K en un modelo de 70B. Los 5 minutos responden a la presión sobre la memoria de la GPU; para mantener la caché durante horas o días hace falta almacenamiento en disco, como en la arquitectura MLA de DeepSeek.
• La caché mejora tanto el coste —entre un 50 y un 90% menos en la entrada cuando hay un acierto— como la latencia —el TTFT baja entre 3 y 10 veces con prompts de 5–10K tokens, y mucho más por encima de 100K—.

Parte 2 — Comparativa de la caché de prompts en LLM entre proveedores

Comparativa de la caché de prompts: Claude, GPT-5, Gemini, DeepSeek y Qwen (2026) →

La guía para elegir proveedor. Cinco proveedores exponen la caché de prompts de formas muy distintas: marcadores explícitos en Claude, funcionamiento totalmente automático en GPT-5 y DeepSeek-v4, un enfoque híbrido implícito y explícito en Gemini y Qwen, y respaldo arquitectónico en disco mediante MLA en DeepSeek. El artículo incluye una comparativa función por función y un marco de evaluación con 5 dimensiones para puntuarlos según tu carga de trabajo.

Puntos clave:

• No compares precios base. Compara el coste efectivo ponderado por tu tasa de aciertos —la fórmula está en §4.1—. La comparativa actualizada de precios de LLM y la calculadora de costes permiten aplicarlo a tu carga de trabajo.
• Claude ofrece el mayor descuento por llamada —~90%—, pero exige marcadores cache_control explícitos.
• DeepSeek-v4 es el único proveedor con cachés respaldadas en disco a gran escala. Las coincidencias parciales de prefijo también reciben descuentos porque la granularidad es de 64 tokens en lugar de 1,024.
• La caché explícita de Gemini cobra almacenamiento por hora. El umbral de rentabilidad depende de la frecuencia de las llamadas.
• Una vez normalizada la tasa de aciertos, las cinco dimensiones que realmente diferencian a los proveedores son la ergonomía de la API, la previsibilidad de la tasa de aciertos, la adecuación del TTL, la latencia en caso de fallo de caché y el coste de migración.

Parte 3 — Tutorial práctico en Python

Caché de prompts en LLM con Python: tutorial con código funcional →

El artículo práctico. Usa un SDK de OpenAI y otro de Anthropic contra un único gateway, con mediciones del 2026-05-25 para toda la familia Claude —de haiku-4-5 a opus-4-7—, GPT-5.x, Gemini 2.5, DeepSeek-v4 y Qwen3.

Puntos clave:

• Claude con marcadores cache_control: las mediciones muestran una reducción de costes del 88–89% de forma uniforme en haiku/sonnet/opus 4-x. Usa el SDK de Anthropic con base_url="https://synthorai.io/".
• Caché automática de GPT-5.4-mini: mejora de 5× en el TTFT —3.6 s → 0.73 s con un prompt de 7K tokens— y una tasa de aciertos del 93% en los tokens del sistema.
• Caché implícita de Gemini 2.5-flash: reducción de costes del 88% en los aciertos de caché cuando se captura el uso en streaming.
• DeepSeek-v4-flash: descuento del 74%, con respaldo en disco —la caché sobrevive a periodos de inactividad de varias horas—.
• Patrones adaptados al TTL: heartbeat de keep-alive para cron, reglas para mantener estable el prefijo y datos que conviene registrar en cada llamada.

Parte 4 — Mejor modelo según el caso de uso

Mejor LLM para chat, RAG y agentes: matriz de decisión de modelos y costes para 2026 →

El artículo para tomar decisiones. Cada carga de trabajo aprovecha de forma distinta las palancas de coste y latencia: el chat encaja de manera natural con la caché, RAG tiene problemas para mantener estable el prefijo y los agentes dependen de conservar correctamente los prefijos acumulados. El artículo recomienda modelos según el tipo de carga e incluye estimaciones de costes.

Puntos clave:

• Chatbots: sirve cualquier modelo con caché automática, porque las sesiones generan aciertos de forma natural. Elige por coste y calidad. gpt-5.4-nano es el más barato, gpt-5.4-mini ofrece el TTFT más rápido con caché y claude-haiku-4-5 es el que mejor sigue las instrucciones por un sobrecoste moderado.
• RAG: cambiar el orden de los documentos recuperados elimina los aciertos de caché en mitad del prompt. Hay tres soluciones: colocar las referencias al final, ordenar los fragmentos de forma determinista o usar varios puntos de corte cache_control de Claude.
• Agentes: las llamadas a herramientas y sus resultados deben añadirse únicamente al final y mantenerse idénticos bit a bit entre pasos. claude-sonnet-4-5 con 4 marcadores cache_control ofrece el mayor descuento para prefijos acumulados; gpt-5.4-mini consigue un ahorro del 50% sin cambios de código.
• TTL adecuado: 5 min para chat, 1 hora para agentes con pasos de intervención humana y respaldo en disco para procesos por lotes esporádicos.

Parte 5 — Integración con LangChain

Caché de prompts en LangChain: configuraciones que sí aciertan en caché →

El artículo sobre el framework. Las partes 1–4 parten de que controlas los bytes del prompt. LangChain los construye por ti, y su sintaxis más cómoda desactiva silenciosamente la caché de Claude. Las mediciones se hicieron con langchain-core 1.4.8 y un prefijo de sistema marcado.

Puntos clave:

• La plantilla con tuplas de strings ("system", "...") no puede incluir cache_control: las pruebas con llamadas idénticas no registraron ninguna actividad de caché. La solución es usar un SystemMessage con bloques de contenido.
• El orden del prompt determina la tasa de aciertos. Colocar el contexto RAG recuperado antes de las reglas estáticas hizo que cada llamada escribiera en frío, lo que en Claude cuesta más que no usar caché debido al recargo por escritura.
• Un marcador en el bloque de sistema también cubre las herramientas vinculadas. bind_tools genera una serialización estable a nivel de bytes, y los marcadores incluidos en un diccionario de herramientas con formato de Anthropic se transmiten sin cambios.
• Agentes con varios turnos: mueve el marcador hasta el mensaje más reciente. Así, cada turno vuelve a leer todo el prefijo anterior y solo escribe el delta —medición: lectura de 1,864, escritura de 15—.
• En modelos con caché automática —GPT, GLM y DeepSeek—, un orden incorrecto falla de forma silenciosa: no hay recargo ni error, pero el descuento nunca llega. Supervisa los campos de uso.

Cómo leer esta serie

• Ingeniero sin experiencia previa en el tema: léela en orden. La arquitectura de la parte 1 permite entender de inmediato las partes 2–4.
• PM o arquitecto que está seleccionando un proveedor: ve directamente a las partes 2 y 4. Consulta la parte 1 si alguien del equipo pregunta por qué existe el TTL.
• Ingeniero que debe poner hoy en producción una carga concreta: empieza por la parte 4 —busca tu fila en la matriz— y pasa después a la parte 3 para obtener el código exacto.
• Si ya usas LangChain: ve directamente a la parte 5. Los patrones con SDK sin framework de la parte 3 siguen siendo aplicables, pero los problemas —plantillas de strings, ubicación de variables y nombres de los campos de uso— son específicos del framework.
• Si estás optimizando una aplicación existente: consulta el benchmark entre proveedores de la parte 3, §6. Reprodúcelo con tu propio prompt; es una tarea de un día, no una migración de varias semanas.

Mediciones de esta serie

Las cifras de las partes 1–4 se midieron el 2026-05-25, y las mediciones de LangChain de la parte 5, el 2026-07-04. Se utilizó el gateway de Synthorai —https://synthorai.io/v1 para compatibilidad con OpenAI y https://synthorai.io/ para la API nativa de Anthropic—, en un entorno single-tenant, con una única ejecución secuencial y sin carga concurrente. Tus resultados variarán según la región, la hora del día y la carga de otros tenants. Úsalos como punto de partida y repite las mediciones con tu propio tráfico antes de citarlos.

Las tablas de precios y el comportamiento de los TTL reflejan la documentación pública de los proveedores a fecha de 2026-05. Los proveedores actualizan estos datos cada pocos meses. Los fundamentos arquitectónicos de la parte 1 se mantienen estables; las cifras comparativas de las partes 2 y 3 cambian con el tiempo.

← Volver al blog