Caché de prompts en LLM: la guía completa de 2026

Si despliegas un chatbot, una aplicación RAG o un agente de IA contra un gran modelo de lenguaje, la caché de prompts es la única optimización que te devuelve del 50 al 90 % del coste de entrada y de 3 a 10× en el tiempo hasta el primer token sin coste de calidad alguno. No es un truco añadido por encima: surge directamente de cómo se define la atención en los Transformers. Una vez que lo entiendes, el resto de la pila (TTL, diferencias entre proveedores, estructura del prompt) encaja con claridad.

Esta página es el índice de una serie de cuatro partes que te lleva desde la teoría hasta una matriz de decisión para producción. Elige por dónde entrar según lo que ya sepas.

Por dónde entrar

Cada parte es autónoma, pero están escritas de forma que leerlas en orden construye el panorama sin redundancia.

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

Caché de prompts en LLM #1: cómo funcionan la caché KV y el TTL →

El artículo arquitectónico. Recorre la autoatención como una única ecuación, explica por qué los vectores K y V de un prefijo estable son matemáticamente reutilizables y muestra cómo el compromiso entre memoria y cómputo produce el comportamiento del TTL alrededor del cual todo desarrollador debe diseñar.

Puntos clave:

• La caché de prompts no es una optimización colocada por encima, sino una consecuencia directa de la atención con máscara causal. El K/V en la posición i es una función determinista de los tokens 1…i, de modo que prefijos idénticos dan K/V idénticos bit a bit.
• El prefill (limitado por cómputo, O(N²)) es lo que ahorra la caché; el decode (limitado por el ancho de banda de memoria, O(N) por token) es lo que todo motor de inferencia ya optimiza.
• Los TTL existen porque la caché KV es enorme (~10 GB para un contexto de 32K en un modelo de 70B). 5 minutos es el horizonte de presión de memoria de la GPU; de horas a días solo es posible con cachés respaldadas por disco (la arquitectura MLA de DeepSeek).
• La caché gana tanto en coste (50 a 90 % de descuento sobre la entrada en los aciertos de caché) como en latencia (el TTFT cae de 3 a 10× para prompts del orden de 5 a 10K tokens, y mucho más para más de 100K).

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

Caché de prompts en LLM #2: comparar Claude, GPT, Gemini, DeepSeek →

La guía de compra. Cinco proveedores exponen la caché de prompts en cinco formas muy distintas: marcadores explícitos (Claude), totalmente automática (GPT-5, DeepSeek-v4), híbrida implícita+explícita (Gemini, Qwen) o respaldo arquitectónico en disco (la MLA de DeepSeek). El artículo ofrece una comparación característica por característica más un marco de evaluación de 5 dimensiones para puntuarlos según tu carga de trabajo específica.

Puntos clave:

• No compares los precios base, compara el coste efectivo ponderado por tu tasa de aciertos (fórmula en §4.1).
• Claude tiene el descuento más profundo en una sola llamada (~90 %), pero requiere marcadores cache_control explícitos.
• DeepSeek-v4 es el único proveedor con cachés respaldadas por disco a escala; las coincidencias parciales de prefijo obtienen descuentos porque la granularidad es de 64 tokens en lugar de 1.024.
• La caché explícita de Gemini cobra tarifas de almacenamiento por hora: el punto de equilibrio depende de la frecuencia de las llamadas.
• La ergonomía de la API, la previsibilidad de la tasa de aciertos, la adecuación del TTL, la latencia en caso de fallo y el coste de migración son las cinco dimensiones que realmente distinguen a los proveedores una vez que se controla la tasa de aciertos.

Parte 3 — Tutorial de Python funcional

Caché de prompts en LLM #3: tutorial de Python funcional →

El artículo práctico. Un SDK de OpenAI + un SDK de Anthropic contra una única pasarela, con cifras medidas el 2026-05-25 en 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: reducción de coste del 88 al 89 % medida 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 del TTFT de 5× (3,6 s → 0,73 s en un prompt de 7K tokens), 93 % de tasa de aciertos de caché en los tokens del sistema.
• Gemini 2.5-flash implícita: reducción de coste del 88 % en los aciertos de caché cuando se captura el uso en streaming.
• DeepSeek-v4-flash: 74 % de descuento, respaldada por disco (la caché sobrevive a inactividades de horas).
• Patrones conscientes del TTL: heartbeat keep-alive para cron, reglas de estabilidad del prefijo, qué registrar en cada llamada.

Parte 4 — El mejor modelo según el caso de uso

Caché de prompts en LLM #4: el mejor modelo para chat, RAG y agentes →

El artículo de decisión. Las distintas cargas accionan las palancas de coste/latencia de forma diferente: el chat es naturalmente favorable a la caché, el RAG lucha contra el problema de la estabilidad del prefijo, los agentes dependen de la disciplina del prefijo acumulativo. El artículo da una recomendación de modelo por forma de carga con estimaciones de coste.

Puntos clave:

• Chatbots: cualquier modelo con caché automática funciona; las sesiones aciertan de forma natural. Elige según coste/calidad. gpt-5.4-nano es el más barato, gpt-5.4-mini tiene el TTFT en caché más rápido, claude-haiku-4-5 ofrece el mejor seguimiento de instrucciones con un sobrecoste modesto.
• RAG: la reordenación de los documentos recuperados destruye los aciertos de caché a mitad del prompt. Tres soluciones: empujar las referencias al final, un orden de fragmentos determinista o los puntos de ruptura múltiples cache_control de Claude.
• Agentes: las llamadas a herramientas y sus resultados deben ser de solo anexado e idénticos bit a bit de un paso a otro. claude-sonnet-4-5 con 4 marcadores cache_control ofrece el descuento de prefijo acumulativo más fuerte; gpt-5.4-mini funciona sin cambios de código con un 50 % de ahorro.
• Ajuste del TTL: 5 min para chat, 1 hora para agentes con pasos con intervención humana, respaldo en disco para lotes esporádicos.

Cómo leer esto

• Ingeniero nuevo en el tema: lee en orden. La arquitectura de la Parte 1 hace que las Partes 2 a 4 encajen al instante.
• PM o arquitecto que selecciona proveedor: salta a la Parte 2 + la Parte 4. Consulta la Parte 1 si un compañero pregunta «pero por qué existe el TTL».
• Ingeniero con una carga específica que entregar hoy: primero la Parte 4 (encuentra tu fila en la matriz), luego la Parte 3 para el código exacto.
• Cualquiera que optimice una app existente: el benchmark entre proveedores de la Parte 3 §6 — reprodúcelo con tu propio prompt; es un trabajo de un día, no una migración de varias semanas.

Las cifras de esta serie

Todas las cifras medidas se capturaron el 2026-05-25 contra la pasarela Synthorai (https://synthorai.io/v1 para compatibilidad con OpenAI, https://synthorai.io/ para Anthropic nativo), de un solo inquilino, en una única ejecución secuencial, sin carga concurrente. Tus cifras variarán según la región, la hora del día y la carga de inquilinos en competencia; trátalas como un punto de partida y reprodúcelas con tu propio tráfico antes de citarlas.

Las tablas de precios y el comportamiento del TTL reflejan la documentación pública de los proveedores a fecha de 2026-05. Los proveedores las actualizan cada pocos meses; el razonamiento arquitectónico (Parte 1) es estable, las cifras comparativas (Partes 2 y 3) se desvían.

← Volver al blog