)
El caché de LLM es la práctica de almacenar representaciones procesadas de prompts o respuestas completas del modelo para que las solicitudes posteriores puedan reutilizarlas en lugar de volver a ejecutar la inferencia desde cero. Reduce tanto el coste como la latencia sin cambiar la calidad del modelo.
Existen dos tipos relevantes para los despliegues empresariales: el caché de prompts (a nivel de proveedor, que descuenta los tokens del prefijo estable) y el caché semántico (a nivel de aplicación, que devuelve respuestas almacenadas para consultas semánticamente similares sin llegar al modelo).
Cada vez que tu aplicación envía el mismo prompt de sistema de 8.000 tokens al modelo y paga el precio completo de entrada, está pagando por algo que ya pagó ayer. Y el día anterior. El caché es la solución. No es complicado. La mayoría de los equipos simplemente no lo están usando.
TL;DR - Puntos clave
- El caché de prompts reduce el coste de los tokens de entrada estables repetidos hasta un 90% en Anthropic (la entrada de Claude Sonnet 4.6 baja de 3,00 dólares/M a 0,30 dólares/M en los aciertos de caché) y un 50% en OpenAI. Sin cambio de calidad. Sin cambio de modelo. Un solo paso de implementación.
- El caché semántico va más lejos: devuelve una respuesta almacenada para cualquier consulta semánticamente similar a una respondida anteriormente, omitiendo el modelo por completo. Los despliegues en producción alcanzan entre el 20 y el 45% del tráfico sin tocar el modelo, según los benchmarks de Technion (2026).
- El recuento medio de tokens de prompt creció casi 4 veces entre principios de 2024 y finales de 2025, de aproximadamente 1.500 tokens a 6.000 por solicitud. Los prompts más largos hacen que el caché sea más valioso, no menos.
- ProjectDiscovery elevó su tasa de aciertos de caché del 7% al 84%, reduciendo el gasto total en LLM entre un 59-70% con un único cambio arquitectónico. Ese es un resultado de producción documentado, no una proyección de benchmark.
- El 31% de las consultas de LLM en producción muestran una similitud semántica suficiente para devolver una respuesta cacheada, según el análisis de Introl (2025). Eso es un gasto significativo destinado a trabajo idéntico.
- TrustGate de NeuralTrust aplica políticas de caché en la capa de gateway para que se apliquen de forma consistente en todas las aplicaciones conectadas.
¿Qué es el caché de LLM?
La primera vez que una startup que conozco activó el caché de prompts, su factura mensual de Anthropic cayó 14.000 dólares en treinta días. No habían cambiado el modelo. No habían reescrito un solo prompt. No habían tocado la lógica de la aplicación. Añadieron un campo JSON a sus llamadas a la API.
La factura había sido alta por una razón simple: sus agentes ejecutaban un prompt de sistema de 12.000 tokens que contenía definiciones de herramientas, políticas de empresa y un contexto de documentos largo. Cada solicitud reenviaba cada token. Cada token se facturaba al precio completo de entrada. El modelo procesaba algo que ya había procesado diez mil veces antes.
El caché lo solucionó. En un acierto de caché, el modelo no reprocesa el prefijo cacheado. Lee desde el estado almacenado. Por eso el descuento es tan grande. No estás comprando un cómputo más barato. Estás omitiendo un cómputo por el que ya pagaste.
El Caché de LLM consiste en almacenar las representaciones procesadas de los prefijos de prompt (caché de prompts) o las respuestas completas del modelo (caché semántico) para que las solicitudes posteriores puedan reutilizarlas a una fracción del coste de volver a ejecutar la inferencia desde cero.
Dos tipos. Mecánicas diferentes. Casos de uso diferentes. Ambos vale la pena entender antes de elegir uno.
)
Caché de prompts: cómo funciona, qué cuesta y qué ahorra
El caché de prompts opera a nivel del proveedor. Cuando llega tu solicitud, el proveedor comprueba si la parte inicial de tu prompt ha sido vista recientemente y almacenada. Si es así, el modelo omite el reprocesamiento de esa porción y lee los tensores key-value cacheados en su lugar. Pagas la tarifa de lectura de caché, no la tarifa estándar de entrada.
La economía es sencilla:
En Anthropic (Claude Sonnet 4.6, julio 2026):
- Entrada estándar: 3,00 dólares por millón de tokens
- Escritura de caché (TTL de 5 minutos): 3,75 dólares por millón de tokens (1,25 veces la tarifa estándar)
- Escritura de caché (TTL de 1 hora): 6,00 dólares por millón de tokens (2,0 veces la tarifa estándar)
- Lectura de caché: 0,30 dólares por millón de tokens (0,10 veces la tarifa estándar, un descuento del 90%)
En OpenAI (GPT-4.1 y posteriores, julio 2026):
- Lecturas de caché: hasta un 90% de descuento sobre la entrada estándar en los modelos más nuevos
- Sin tarifa de escritura separada: el cacheo es automático, no se requieren cambios de código
El punto de equilibrio con el TTL de 5 minutos de Anthropic se alcanza después de aproximadamente 1,4 lecturas de caché por escritura de caché. Una tasa de aciertos superior al 30% en prompts estables significa que el caché ahorra dinero. Una tasa de aciertos superior al 60% significa que el caché ahorra una cantidad significativa de dinero.
)
La latencia también mejora.
Las lecturas cacheadas omiten el cómputo de prefill para la porción cacheada. OpenAI informa una mejora de hasta el 80% en el tiempo hasta el primer token en las lecturas cacheadas en comparación con los prompts frescos. (Fuente: documentación de Prompt Caching de OpenAI)
¿Qué califica para el caché?
Los prompts deben tener al menos 1.024 tokens tanto en Anthropic como en OpenAI para que el caché se aplique. Los bloques más cortos no se cachean aunque añadas el marcador de caché. El contenido cacheado debe ser un bloque contiguo al inicio de tu prompt, idéntico en todas las solicitudes.
Esto significa que el contenido estable (prompts de sistema, definiciones de herramientas, contexto de documentos largo, bibliotecas de ejemplos) se cachea. El contenido dinámico (la pregunta específica del usuario, el contexto en tiempo real) va al final y no se cachea. La estructura del prompt importa enormemente, y la estructura incorrecta silenciosamente arruina tu tasa de aciertos.
Caché semántico: cómo funciona y cuándo supera al caché de prompts
El caché de prompts maneja las partes estables de tus prompts. El caché semántico maneja las consultas en sí mismas.
La idea: cuando un usuario pregunta "¿cuál es tu política de devoluciones?", calculas un embedding de esa consulta y compruebas tu caché. Si una consulta semánticamente similar ("¿cómo obtengo un reembolso?", "¿puedo devolver mi pedido?") fue respondida recientemente, devuelves la respuesta cacheada sin llamar al modelo en absoluto. El umbral de similitud (típicamente una puntuación de similitud de coseno por encima de 0,8-0,85) determina si una consulta cuenta como un acierto de caché.
Los despliegues en producción típicamente alcanzan entre el 20 y el 45% del tráfico con caché semántico, según los benchmarks publicados por el Departamento de Ciencias de la Computación de Technion (2026). No el 95% que a veces sugieren los materiales de los proveedores, pero que el 20-45% de tus llamadas al LLM no lleguen al modelo sigue siendo una reducción de costes material, especialmente para cargas de trabajo de alto volumen donde el 31% de las consultas muestran una similitud semántica significativa. (Fuente: Introl, 2025)
El toolkit de código abierto es GPTCache (github.com/zilliztech/GPTCache). GPTSemCache, una implementación de investigación, logró tasas de aciertos de caché del 61,6-68,8% en categorías de consultas con una precisión superior al 97%. (Fuente: GPTSemCache, Regmi y Pun, 2024, citado en arxiv.org/html/2603.03301v1)
El compromiso: el caché semántico introduce un nuevo modo de fallo. Un modelo de embedding deficiente mapea consultas semánticamente distintas a vectores cercanos y devuelve una respuesta cacheada incorrecta. Esto es aceptable en la búsqueda, los near-misses son válidos. No es aceptable en el caché de LLM: una respuesta alucinada servida desde el caché es peor que una llamada fresca al modelo. La calidad del modelo de embedding y el umbral de similitud son las dos decisiones de implementación más importantes.
Caché de prompts vs. caché semántico: cuál usar
No son alternativas. Funcionan en capas diferentes y resuelven problemas diferentes. La pregunta no es cuál elegir, es cuál implementar primero.
| Caché de prompts | Caché semántico | |
|---|---|---|
| Qué cachea | Prefijos de prompt estables (prompt de sistema, defs de herramientas, documentos) | Respuestas completas del modelo para consultas semánticamente similares |
| Dónde opera | A nivel de proveedor (Anthropic, OpenAI, Google) | A nivel de aplicación (tu infraestructura) |
| Implementación | Un campo JSON (cache_control) o automático | Modelo de embedding + almacén de vectores + umbral de similitud |
| Requisito mínimo de tokens | Mínimo 1.024 tokens | Sin mínimo; funciona con cualquier consulta |
| Descuento en acierto de caché | 90% de descuento en Anthropic; hasta 90% en los modelos más nuevos de OpenAI | 100%: ninguna llamada al modelo en absoluto |
| Riesgo de calidad | Ninguno: salida del modelo idéntica | Bajo a moderado: depende de la calidad del modelo de embedding y el umbral |
| Mejor para | Prompts de sistema grandes estables, catálogos de herramientas, contexto de documentos RAG | Consultas tipo FAQ, tickets de soporte, búsqueda repetitiva, clasificación |
| Tasas de aciertos en producción | 80-95% en cargas de trabajo con prompts estables | 20-45% en la práctica |
Empieza con el caché de prompts si tienes un prompt de sistema de más de 2.000 tokens y más de unos pocos cientos de llamadas a la API diarias. Es la implementación más sencilla y la recuperación más rápida. El análisis de Agentbrisk (abril de 2026) muestra una aplicación de atención al cliente con un prompt de sistema de 4.000 tokens y 6.000 tokens de contexto RAG logrando una reducción del 76% en el coste total de la API con una tasa de aciertos del 95%, de 10.000 dólares/mes a 2.361 dólares/mes.
Añade caché semántico para los tipos de consultas que son genuinamente repetitivos entre diferentes formulaciones. Chatbots de FAQ, clasificadores de tickets de soporte, búsqueda en catálogos de productos, resumen de documentos sobre los mismos documentos. Estos son los casos de uso donde la misma intención del usuario aparece en diferentes formulaciones en diferentes sesiones. El caché semántico captura esa reutilización. El caché de prompts no.
Cómo estructurar tus prompts para maximizar la tasa de aciertos de caché
La estructura de tu prompt determina si el caché funciona. La regla es simple: coloca el contenido más estable primero, el contenido más dinámico al final. Cualquier cambio en un bloque cacheado invalida ese bloque y todo lo que le sigue.
El orden correcto es:
- Definiciones de herramientas (las más estables: cambian solo cuando actualizas tus herramientas)
- Instrucciones del prompt de sistema (estables: cambian cuando actualizas el comportamiento de la aplicación)
- Documentos de referencia (moderadamente estables: cambian cuando se actualiza tu base de conocimientos)
- Historial de conversación (cambia en cada turno)
- Consulta del usuario (cambia en cada solicitud)
El error común es mezclar contenido estable y dinámico. Si tu prompt de sistema contiene una marca de tiempo, un nombre de usuario o cualquier valor específico de la sesión, el bloque de caché se invalida en cada solicitud. Todo el prefijo debe ser byte-idéntico para un acierto de caché.
Un catálogo de herramientas de 10.000 tokens cacheado al 80% de tasa de aciertos ahorra más por mes que un prompt perfectamente comprimido de 500 tokens al 100% de tasa de aciertos. El recuento absoluto de tokens importa más que el porcentaje de tasa de aciertos. (Fuente: Tokonomics, mayo de 2026)
Errores comunes que arruinan tu tasa de aciertos de caché
Error 1: Contenido dinámico dentro del prefijo cacheado.
Una marca de tiempo, un ID de usuario o cualquier valor específico de la sesión en tu prompt de sistema rompe el caché en cada solicitud individual. Audita tu prompt de sistema para detectar cualquier cosa que cambie por sesión o por usuario antes de habilitar el caché.
Error 2: Orden de prompt incorrecto.
El historial de conversación antes que el prompt de sistema. El contexto RAG antes que las definiciones de herramientas. Cualquier ordenación que ponga contenido inestable al principio del prompt significa que el contenido estable que le sigue nunca obtiene un prefijo estable sobre el que construir.
Error 3: Prompts de menos de 1.024 tokens.
El caché no se activa por debajo del umbral mínimo. Si tu prompt de sistema tiene 800 tokens, el caché no hace nada. Consolidar instrucciones dispersas en un único prompt de sistema coherente mejora tanto el seguimiento de instrucciones del modelo como supera el umbral de caché.
Error 4: No monitorizar la tasa de aciertos.
No puedes optimizar lo que no puedes medir. Registra los aciertos y fallos de caché explícitamente. Una tasa de aciertos inferior al 40% en una carga de trabajo con prompts estables señala un problema estructural, generalmente contenido dinámico dentro del prefijo cacheado o problemas de ordenación del prompt. Consulta nuestra guía de Monitorización del Uso de Tokens para el marco completo de atribución y alertas.
Error 5: Usar el TTL incorrecto.
Anthropic ofrece TTLs de 5 minutos y 1 hora. El TTL de 1 hora cuesta 2 veces la prima de escritura frente a 1,25 veces para 5 minutos, pero el punto de equilibrio se alcanza después de dos lecturas de caché en lugar de una. Si tus solicitudes están espaciadas más de 5 minutos pero llegan dentro de la hora, el TTL de 1 hora es más barato.
)
Preguntas frecuentes sobre estrategias de caché para LLM
1. ¿Qué es el caché de prompts en los LLM?
El caché de prompts es una característica a nivel de proveedor que almacena los tensores key-value procesados de un prefijo de prompt estable en los servidores del proveedor. Cuando una solicitud posterior comienza con el mismo prefijo, el proveedor lee del caché almacenado en lugar de reprocesar esos tokens, y cobra una tarifa con descuento. La tarifa de lectura de caché de Anthropic es un 90% menor que la tarifa estándar de entrada. El caché automático de OpenAI ofrece hasta un 90% de descuento en los modelos más nuevos sin cambios de código. Mínimo 1.024 tokens para el bloque cacheado.
2. ¿Qué es el caché semántico y en qué se diferencia del caché de prompts?
El caché semántico opera a nivel de aplicación y almacena respuestas completas del modelo indexadas por el embedding de la consulta. Cuando llega una nueva consulta con una similitud de coseno por encima de un umbral configurado (típicamente 0,8-0,85) respecto a una consulta anteriormente cacheada, se devuelve la respuesta almacenada sin llamar al modelo en absoluto. Esto es fundamentalmente diferente del caché de prompts, que reduce el coste de las llamadas al modelo que aún ocurren. El caché semántico elimina algunas llamadas al modelo por completo. El compromiso es la complejidad de implementación y el riesgo de devolver respuestas semánticamente similares pero factualmente diferentes.
3. ¿Cuánto puede ahorrar el caché de LLM en producción?
Depende del tipo de carga de trabajo y la tasa de aciertos. El caché de prompts al 80% de tasa de aciertos en un prefijo estable de 10.000 tokens ahorra aproximadamente el 72% del coste de tokens de entrada de ese prefijo. Una aplicación de atención al cliente con un prompt de sistema de 4.000 tokens y 6.000 tokens de contexto RAG logró una reducción del 76% en el coste total de la API al 95% de tasa de aciertos, según el análisis de Agentbrisk (abril de 2026). ProjectDiscovery elevó su tasa de aciertos de caché del 7% al 84% y redujo el gasto total en LLM entre un 59-70%. El caché semántico en producción típicamente alcanza el 20-45% del tráfico, según los benchmarks de Technion (2026).
4. ¿Necesito tanto caché de prompts como caché semántico?
Para la mayoría de las aplicaciones en producción, empieza con el caché de prompts: es un solo paso de implementación y ofrece el ROI inmediato más alto. Añade caché semántico para tipos de consultas que son genuinamente repetitivos en diferentes formulaciones: chatbots de FAQ, clasificadores de tickets de soporte, resumen de documentos en corpus fijos. Las dos técnicas operan en capas diferentes y se combinan. El caché de prompts reduce el coste de cada llamada al modelo. El caché semántico elimina algunas llamadas al modelo por completo.
5. ¿Afecta el caché a la calidad de la salida?
El caché de prompts produce salidas byte-idénticas a las llamadas no cacheadas, el modelo procesa exactamente el mismo contexto, simplemente comenzando desde el estado almacenado en lugar de recomputarlo. No hay diferencia de calidad. El caché semántico puede afectar la calidad si el umbral de similitud se establece demasiado bajo y consultas semánticamente diferentes reciben respuestas cacheadas. Un umbral bien ajustado (similitud de coseno de 0,85+) y un modelo de embedding de alta calidad minimizan este riesgo. GPTSemCache logró una precisión superior al 97% con tasas de aciertos de producción del 61,6-68,8%.
Conclusiones clave
- El caché de prompts es la optimización de mayor ROI disponible para la mayoría de las aplicaciones LLM en producción ahora mismo. Un descuento del 90% en los tokens cacheados sin cambio de calidad y un solo paso de implementación, la mayoría de los equipos no lo están usando.
- El caché semántico elimina las llamadas al modelo por completo para tipos de consultas repetitivos. Las tasas de aciertos en producción del 20-45% son realistas para cargas de trabajo de FAQ, soporte y búsqueda.
- Las dos técnicas no son alternativas. Apílalas: el caché de prompts reduce el coste de cada llamada al modelo, el caché semántico elimina algunas llamadas al modelo por completo.
- La estructura del prompt determina la tasa de aciertos de caché. El contenido más estable primero, el más dinámico al final. El contenido dinámico dentro del prefijo cacheado silenciosamente arruina tu tasa de aciertos.
- Monitoriza la tasa de aciertos explícitamente. Una tasa inferior al 40% en cargas de trabajo con prompts estables señala un problema estructural, no un problema de tráfico.
- TrustGate de NeuralTrust aplica políticas de caché y presupuestos de tokens en la capa de gateway en todas las aplicaciones conectadas.
Artículos relacionados
- AI Token Optimization: The Complete Enterprise Guide to Reducing LLM Costs (2026)
- Prompt Compression: How to Cut Token Costs Without Losing Output Quality
- LLM Cost Reduction: 12 Proven Strategies to Cut Your AI Inference Bill
- Context Window Optimization: How to Manage Long Contexts Without Blowing Your Budget
- LLM Model Routing: How to Automatically Send Queries to the Right Model
- Token Usage Monitoring: How to Track, Attribute, and Optimise AI Spend in Production
- Output Length Control: How to Stop LLMs from Over-Generating and Wasting Tokens
- LLM Batching and Async Inference: How to Cut Costs on High-Volume AI Workloads
- Fine-Tuning vs Prompting: A Cost Comparison for Enterprise AI Teams
Sobre el autor
Roger Howroyd es Head of Global SEO and AI en NeuralTrust, donde lidera la estrategia de búsqueda de la compañía en SEO, AEO, GEO y optimización para LLMs. Está especializado en búsqueda potenciada por IA, estrategia de contenidos, desarrollo de backlinks y SEM. Conecta en LinkedIn
NeuralTrust es una plataforma de seguridad para agentes de IA, reconocida en la Guía de Mercado de Gartner 2025 para AI Gateways y Guardian Agents, y en la KuppingerCole 2025 Leadership Compass for Generative AI Defense. Con sede en Barcelona y certificación ISO 27001.
)