# Caché de LLM: cómo ahorrar hasta 90% en facturas de IA con prompt caching > Versión Markdown limpia de https://claudecodeguia.com/cache-llm/, optimizada para consumo por agentes de IA. Última actualización: mayo 2026. Llevas todo el día hablando con un modelo de IA. Probablemente haya leído el mismo prompt de sistema, el mismo manual de producto y la misma definición de herramientas decenas de veces. ¿Eso significa que has quemado tokens decenas de veces? Aquí está el mecanismo más importante de los modelos modernos: **la entrada que se repite no necesita volver a calcularse**. Si lo configuras bien, tu factura puede caer hasta un 90%. ## El caché que ya has usado sin saberlo Abres una página web. La primera vez tarda. La segunda carga en un segundo. La razón: el navegador guardó imágenes, scripts y estilos en una caché local, y la próxima vez no los pide al servidor. El caché de los LLM funciona con la misma lógica, pero con una diferencia. Mientras la caché del navegador guarda *archivos*, la del LLM guarda el **«estado de cálculo»** que el modelo dejó después de leer la primera parte del input. Más exactamente: muchos proveedores guardan los resultados intermedios de las matrices `key` y `value` de las capas de atención. Por eso se le llama **KV cache**. Este mecanismo permite que, cuando el modelo ya leyó un bloque grande de contenido fijo, la siguiente vez que vea el mismo inicio pueda saltarse buena parte del trabajo. ## Prefill y decode: dónde se gasta tu dinero Cuando el modelo recibe tu pregunta, pasa por dos fases: **Prefill** = «leer todo lo que le pasaste». El modelo escanea system prompt, historial, documentos, definiciones de herramientas, y calcula relaciones entre tokens. **Cuanto más largo el input, más caro este paso.** **Decode** = «escribir hacia fuera». Apoyándose en el estado del prefill, genera la respuesta token por token. El insight clave: en aplicaciones con **input largo y respuesta corta**, casi todo el coste se va antes de que el modelo abra la boca. Casos típicos: bots de atención al cliente, RAG, análisis de bases de código, agentes con muchas herramientas. El bloque fijo puede ocupar entre miles y cientos de miles de tokens, mientras que la pregunta nueva son dos líneas. El prompt caching ataca esa primera mitad. La primera petición lee el contenido fijo y lo guarda en caché. La segunda, si comparte el mismo inicio, reutiliza ese estado y solo procesa lo que cambió. **Importante**: el caché no hace que el modelo «recuerde la respuesta», ni te ahorra tokens de salida. Solo te ahorra el coste de releer la entrada repetida. ## Por qué un solo espacio puede romper todo el caché Lo más contraintuitivo: > El sistema mira si **el prefijo es exactamente igual byte por byte**, no si el significado es parecido. ``` Eres un asistente de cocina. Dime qué cenar. Eres un asistente de cocina. Dime qué comer. ``` La primera mitad es idéntica → caché OK. ``` ¿Qué cenar? Eres un asistente de cocina. ¿Qué comer? Eres un asistente de cocina. ``` La primera palabra ya es distinta → caché casi nunca acierta. Lo mismo pasa con JSON: cambiar orden de campos, saltos de línea o espacios produce, desde el punto de vista del modelo, una entrada distinta. **Regla de oro**: Lo que no cambia, va al principio. Lo que cambia, va al final. ## Cómo ordenar tu prompt para maximizar el caché 1. **Instrucciones de sistema** — Rol, límites, formato de respuesta. Estables. 2. **Definición de herramientas** — Suelen ser largas y se incluyen en cada petición. Perfectas para cachear. 3. **Base de conocimiento y documentos largos** — Manuales, contratos, fragmentos de código. Solo cachean bien si son idénticos entre peticiones. 4. **Historial de conversación** — Lo que ya pasó no cambia. 5. **Lo que solo cambia ahora** — Pregunta del usuario, hora actual, ID de usuario, parámetros A/B. **Fallo clásico**: poner `Ahora son las 15:30 del 4 de mayo de 2026.` en la primera línea. Un minuto después es 15:31 — todo el prefijo cambia. ## Cómo activar caché en cada proveedor | Proveedor | Cómo se activa | Umbral mínimo | Ahorro al acertar | Retención | |---|---|---|---|---| | **OpenAI** | Automático | 1024 tokens, sube de 128 en 128 | ~10% del precio base en GPT-5 | 5–10 min sin actividad; 24 h opcional | | **Claude** | Manual: `cache_control` en bloques reutilizables | 1024 o 2048 tokens según modelo | Lectura ~10% del precio de input | 5 min default; 1 h opcional | | **Gemini** | Implícito automático; explícito manual | Flash: 1024 · Pro: 4096 | Implícito: ahorro automático | Explícito: 1 h default, TTL configurable | | **DeepSeek** | Automático | Reglas de prefijo internas | Hit notablemente menor que miss | Disco, best-effort, horas a días | **OpenAI** es el más cómodo. No tocas código: prompt sobre el umbral + mismo prefijo → automático. Mira `cached_tokens` en la respuesta. En **Claude Code** no necesitas preocuparte: la herramienta gestiona el caché. Si llamas a la API directamente, añade `cache_control` en bloques de herramientas, system o mensajes. Mira `cache_creation_input_tokens` y `cache_read_input_tokens`. **Gemini** ofrece dos modos. *Implícito* funciona como OpenAI. *Explícito*: creas un objeto de caché con material grande y lo referencias. Ideal para «un material, muchas preguntas», pero el almacenamiento tiene coste. **DeepSeek** usa caché en disco activado por defecto. Respuesta incluye `prompt_cache_hit_tokens` y `prompt_cache_miss_tokens`. Es *best-effort*. ## Cuánto puedes ahorrar realmente Bot de atención al cliente. Cada petición: 5.000 tokens fijos + 200 tokens pregunta + 300 tokens respuesta. 10.000 peticiones/día. **Sin caché**: ``` (5.000 + 200) × 10.000 = 52 millones tokens/día Input: ~$130 Output: ~$45 Total: $175/día ``` **Con caché** (4.500 de los 5.000 tokens fijos aciertan): ``` Hits caché: 4.500 × 10.000 = 45 millones (~$11.25) Input completo: (500 + 200) × 10.000 = 7 millones (~$17.50) Output: 300 × 10.000 = 3 millones (~$45) Total: ~$73.75/día ``` **Ahorro: ~$100/día**. Casi mitad de la factura sin tocar la calidad. Regla: cuanto más largo el input, más alta la repetición y más corta la respuesta, **más vale el caché**. ## Casos de uso ideales - **Atención al cliente y asistentes**: system prompt y manual estables, solo la pregunta cambia. - **RAG con matiz**: si los documentos recuperados cambian completamente cada vez, el caché no acierta. Truco: materiales base estables al principio, retrieval temporal al final. - **Agentes con múltiples herramientas**: definiciones de herramientas son miles de tokens al inicio, repetidos en cada paso. - **Conversaciones multi-turno**: historial se acumula sin cambiar. - **Scripts de baja frecuencia**: olvídate. Si corre cada media hora, el caché default (5–10 min) ya expiró. ## Caché semántico: el primo más arriesgado Prompt caching mira caracteres exactos. **Caché semántico** compara *significados*. Usuario A: «¿Cuál es vuestra política de devoluciones?» Usuario B: «Compré algo por error, ¿cómo lo devuelvo?» Si la similitud es alta, devuelve la respuesta anterior **sin volver a llamar al modelo**. Se implementa en la capa de aplicación. Lo habitual: meter Q&A históricos en una base vectorial; nueva pregunta busca similares; si supera umbral, devuelve cacheado. Combinación con prompt caching: - **Prompt caching** = «esta llamada cuesta menos» - **Caché semántico** = «esta llamada quizá no haga falta» **Riesgo serio**: parecido no es igual. En devoluciones, contratos, salud o finanzas, una falsa coincidencia destruye confianza. Umbral muy conservador, y para preguntas críticas siempre dejar que el modelo responda. ## Los 5 errores más comunes en producción 1. **Timestamps, IDs o aleatorios al principio del prompt.** Cualquier variable que cambia rompe el caché si está al inicio. Fallo silencioso: la factura sube y nadie sabe por qué. 2. **Serialización JSON inestable.** Misma config con otro orden de campos = otro input para el modelo. Serializa siempre con orden fijo y misma indentación. 3. **Personalización del usuario al top del system prompt.** «Estás atendiendo a Juan, le gustan respuestas cortas» al principio = cada usuario genera prefijo único. Mejor: reglas globales arriba, perfil de usuario al final. 4. **Mirar solo total de tokens, no campos de caché.** OpenAI: `cached_tokens`. Claude: `cache_read_input_tokens`. Gemini: dentro de `usage_metadata`. DeepSeek: `prompt_cache_hit_tokens`. Sin esto no sabes si funciona. 5. **Pensar que el caché cambia la calidad.** Solo reutiliza el cálculo del prefijo. La salida sigue generándose en vivo, temperatura y sampling siguen influyendo igual. ## Cómo verificar que tu caché funciona 1. **Lee siempre los campos de caché de la respuesta API** — son la verdad. 2. **Diff entre dos prompts consecutivos** — encuentra el carácter oculto que cambia. 3. **Mide la latencia, no solo el coste** — TTFT (time to first token) baja cuando el caché acierta. 4. **Vigila la tasa hit/miss en producción** — si es <50% en apps con prefijo estable, hay un bug. ## TL;DR > **Lo que no cambia, va al principio. Lo que cambia, va al final.** Si haces bien esta única cosa, el caché de los LLM puede ahorrarte hasta el 90% de la factura de input. No te hace más inteligente, no cambia la calidad, no es magia. Solo evita que el modelo vuelva a hacer trabajo que ya hizo. En aplicaciones reales (agentes, RAG, atención al cliente), ese ahorro suele ser la diferencia entre un producto rentable y uno que no escala. ## Recursos oficiales - [OpenAI Prompt Caching documentation](https://platform.openai.com/docs/guides/prompt-caching) - [Claude (Anthropic) Prompt Caching documentation](https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching) - [Gemini API caching (Google)](https://ai.google.dev/gemini-api/docs/caching) - [DeepSeek KV Cache Guide](https://api-docs.deepseek.com/guides/kv_cache) --- **Versión web (HTML)**: https://claudecodeguia.com/cache-llm/ **Versión inglesa**: https://claudecodeguia.com/en/llm-caching/ **Sitio principal**: https://claudecodeguia.com/