Cómo funciona el almacenamiento en caché de prompts en LLM: KV cache y TTL

TL;DR — La caché de prompts en LLM no es una optimización añadida a posteriori, sino una consecuencia directa de cómo la arquitectura Transformer calcula la atención. Cuando entiendes por qué los vectores Key/Value de un prefijo estable se pueden reutilizar matemáticamente, aparece la verdadera ventaja: una reducción drástica tanto del coste (50–90%) como del tiempo hasta el primer token (5–20×). Este artículo, la primera parte de una serie de cinco, explica por qué existe esta caché desde el punto de vista arquitectónico, el equilibrio entre memoria y cómputo que determina si compensa usarla y el comportamiento del TTL que todo desarrollador debe conocer. La Parte 2 analiza las implementaciones específicas de cada proveedor.

Serie: Parte 1 de 5 — Principios de la caché · Siguiente: Parte 2 — Comparativa y evaluación de proveedores · Parte 3 — Tutorial con código funcional · Parte 4 — Mejor LLM según el caso de uso · Parte 5 — Integración con LangChain · Versión en una sola página: guía completa sobre la caché de prompts

Por qué la factura de tokens de tu aplicación de IA crece más rápido que el número de usuarios

Si estás desarrollando un chatbot, una aplicación RAG o un agente de IA, probablemente ya te hayas encontrado con el mismo problema: la factura se duplica, pero el uso no. Al revisar el registro de solicitudes aparecen una y otra vez el mismo system prompt de miles de tokens, las mismas descripciones de herramientas y los mismos fragmentos de la base de conocimiento. Todo se vuelve a enviar en cada llamada.

Ese es el principal problema económico de la inferencia con LLM: el modelo no mantiene estado. Cada solicitud vuelve a procesar desde cero todo el contexto. Un system prompt de 8K tokens invocado 1,000 veces supone repetir el trabajo sobre 8 millones de tokens. Pagas por todos ellos y tus usuarios esperan a que se procesen.

La caché de prompts resuelve este problema. A diferencia de la mayoría de las optimizaciones de rendimiento, no se añade a la arquitectura: surge de forma natural de la propia definición de la atención en los Transformer. Una vez entendido este punto, el resto del artículo —precios, TTL y diferencias entre proveedores— encaja con facilidad.

1. Por qué los LLM tienen caché: recorrido por la inferencia de un Transformer

Casi todos los tutoriales sobre caché de prompts se saltan esta parte. Sin embargo, es la que explica por qué existe la caché y por qué los descuentos de los proveedores no son cifras arbitrarias de marketing, sino un reflejo de la economía real de las GPU.

1.1 Self-attention en una ecuación

Un Transformer solo decodificador —la familia a la que pertenecen GPT-4, Claude, Gemini, DeepSeek y Qwen— procesa los tokens aplicando self-attention repetidamente. Para una secuencia de N tokens, el resultado de la atención de cada token i es:

Attention(Q, K, V) = softmax( Q · Kᵀ / √d ) · V

Q, K y V son matrices de dimensiones [N × d] que se obtienen de los embeddings de entrada mediante tres proyecciones lineales aprendidas, una por capa y por head. La definición original procede de Attention Is All You Need (Vaswani et al., 2017).

Hay dos propiedades de esta ecuación que resultan fundamentales para la caché:

Propiedad 1 — Enmascaramiento causal. Durante la generación, el token i solo puede atender a los tokens situados en posiciones ≤ i. La matriz de atención es triangular inferior: todos los tokens posteriores usan los vectores K y V de los primeros tokens, pero nunca los modifican.

Propiedad 2 — K y V solo dependen del prefijo. Como se calculan a partir de los embeddings de entrada de las posiciones 1…i mediante matrices de pesos fijas, los vectores K y V de la posición i son una función determinista de los tokens situados en las posiciones 1…i, y de ningún otro. Nada de lo que ocurra en la posición i+1 puede cambiar K_i ni V_i.

La consecuencia es inmediata: si dos solicitudes comparten un prefijo idéntico de longitud P, las primeras P filas de K y V son idénticas bit a bit.

Esa es toda la base teórica de la caché de prompts. Lo demás es ingeniería.

1.2 Las dos fases de la inferencia

La inferencia de los LLM modernos se divide en dos fases que consumen tiempo de GPU de formas muy distintas. Esta separación se documenta en detalle en Efficiently Scaling Transformer Inference (Pope et al., 2022).

Fase de prefill. El modelo ingiere el prompt completo de una vez. En cada capa calcula Q, K y V para todos los tokens de entrada y ejecuta el self-attention. El prefill está limitado por cómputo: satura las unidades de multiplicación de matrices de la GPU. Debido a la matriz de atención, el coste crece como O(N²) respecto a la longitud del prompt.

Fase de decode. El modelo genera los tokens de salida de uno en uno y de forma autorregresiva. En el paso t solo se calcula la Q del nuevo token, que atiende a las K/V de todos los tokens anteriores. El decode está limitado por el ancho de banda de memoria: la mayor parte del tiempo se dedica a leer K/V de la memoria de la GPU, no a multiplicar. El coste por token crece como O(N), de forma lineal respecto a la longitud actual del contexto.

En una carga típica de chatbot —system prompt de 8K tokens, consulta de usuario de 100 tokens y respuesta de 300 tokens—, el prefill domina tanto el tiempo total como el coste económico en una proporción aproximada de 4:1. Esa es la parte que evita la caché.

Per call breakdown (8K prompt, 300 output tokens, Claude-class model):

  ████████████████████████████████░░░░░░░░  Prefill: ~80% of compute
  ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░████████  Decode:  ~20% of compute

1.3 La KV cache: conservar el trabajo de prefill para el decode

El término «KV cache» designaba originalmente una optimización dentro de una misma solicitud. Durante el decode, cada nuevo token generado debe atender a las K y V de todos los tokens anteriores. Volver a calcularlas en cada paso convertiría un decode O(N) en uno O(N²). Por eso, todos los motores de inferencia almacenan en la memoria de la GPU las K y V obtenidas durante el prefill y las reutilizan durante toda la fase de decode. Es una práctica universal: todos los LLM comerciales lo hacen. Sin ella, la generación ni siquiera sería viable.

Lo que los proveedores ofrecen como «caché de prompts» es el siguiente paso: conservar la KV cache después de que termine la solicitud y reutilizarla en la siguiente solicitud que comparta el mismo prefijo.

1.4 El equilibrio entre memoria y cómputo: por qué existen los TTL

¿Por qué los proveedores no guardan todo en caché para siempre? Porque la KV cache es enorme.

Para un modelo con L capas Transformer, H heads de atención, D dimensiones por head y B bytes por valor —normalmente 2 para fp16—, el tamaño de la KV cache para N tokens es:

KV cache size  =  2 × L × H × D × B × N
                  ↑   ↑   ↑   ↑   ↑   ↑
                  K&V layers heads head bytes tokens

En un modelo de la clase 70B con 80 capas, 8 KV heads —tras aplicar grouped-query attention—, 128 dimensiones por head y pesos fp16, esto equivale aproximadamente a 320 KB por token. Un contexto de 32K tokens necesita ~10 GB de KV cache para una sola solicitud. Una GPU H100 moderna tiene 80 GB, por lo que solo caben unos pocos contextos de ese tamaño al mismo tiempo.

Esta es la limitación que PagedAttention (Kwon et al., 2023, el paper en el que se basa vLLM) intenta resolver a nivel de batch. La misma restricción limita la caché de prompts entre solicitudes:

Por tanto, el TTL de caché de un proveedor es, en la práctica, una política de expulsión de memoria. En algún momento, la GPU necesita esa memoria para las cargas activas de otros usuarios y expulsa el prefijo almacenado. 5 minutos para cachés residentes en HBM; hasta 1 hora para cachés paginadas a DRAM; horas para cachés respaldadas por disco.

La solución de DeepSeek. DeepSeek-V2 introdujo Multi-head Latent Attention (MLA), que comprime la KV cache aproximadamente 4× frente al grouped-query attention estándar (DeepSeek-AI, 2024). Esa compresión es precisamente lo que permite persistir la KV cache en disco en lugar de HBM. A su vez, esto permite usar una unidad mínima de caché mucho menor —64 tokens frente a 1,024 en cachés residentes en HBM— y TTL efectivos mucho más largos.

Esta es también la razón por la que la caché entre solicitudes exige prefijos idénticos token por token. La caché se indexa mediante un hash de los IDs de token. Cualquier diferencia, incluso un solo carácter que provoque otra tokenización, produce K y V distintas a partir de ese punto. En esta capa no existe ninguna «coincidencia aproximada»; eso corresponde a la caché semántica, un mecanismo distinto del gateway.

1.5 Dos capas de caché

┌──────────────────────────────────────────────────────────────┐
│  Layer 1: Per-request KV cache (always on, every provider)    │
│  → keeps decode O(N) instead of O(N²)                        │
│  → you don't pay attention to it; the provider just does it  │
└──────────────────────────────────────────────────────────────┘
                              ↓
┌──────────────────────────────────────────────────────────────┐
│  Layer 2: Cross-request Prompt Cache (the money-and-time      │
│           saver this series is about)                         │
│  → reuses prefill K/V across requests with matching prefixes  │
│  → exposed as: explicit / fully automatic / hybrid           │
│  → bounded by TTL (memory-eviction-driven)                   │
└──────────────────────────────────────────────────────────────┘

El resto de la serie, y casi todo lo que tendrás que ajustar como desarrollador, se centra en la capa 2.

2. Las dos ventajas: coste Y latencia

La mayoría de los artículos presentan la caché como una optimización de costes. Se quedan cortos. En muchos equipos que trabajan con chat de cara al usuario, la reducción de latencia es el principal motivo para adoptarla en producción.

2.1 Las cuentas del coste

Las páginas de precios muestran las cifras principales, pero rara vez las aplican a una carga realista. Tomemos un bot de atención al cliente con un system prompt de 8,000 tokens, 100K consultas diarias y mensajes de usuario de 200 tokens. Calculamos el coste con claude-sonnet-4-5 y las tarifas publicadas por Anthropic para 2026: el input leído desde caché cuesta el 10% y la escritura en caché tiene un recargo del 125%.

Sin caché

• Input por llamada: 8,200 tokens × tarifa base de input
• Coste por llamada (medido en una sola llamada): ~$0.022
• Coste mensual: 100K × 30 × $0.022 = ~$66,000

Con caché de prompts

• Escritura inicial en caché: 8,000 tokens × recargo del 125% (insignificante frente al volumen mensual)
• A partir de ahí, por llamada: 8,000 tokens × 10% de la tarifa base + 200 tokens × tarifa base + output
• Coste efectivo por llamada: ~$0.003
• Coste mensual: ~$9,000

~86% de ahorro. Es el descuento publicado por Anthropic aplicado a un patrón de input realista. El artículo siguiente, la Parte 3 — Tutorial, muestra mediciones reales del resto de proveedores.

2.2 La reducción de latencia: a menudo, la ventaja principal

El prefill no solo es caro. En prompts de más de unos cientos de tokens, es el factor que más contribuye al tiempo hasta el primer token. Un hit de caché permite omitir casi todo ese trabajo.

Mediciones de TTFT con streaming en el gateway público de Synthorai, 2026-05-25, usando un system prompt estable de ~7,300 tokens:

Una sola ejecución y un solo tenant. La mejora del TTFT se aprecia sobre todo con prompts largos (>5K tokens); en prompts cortos, el prefill representa una fracción demasiado pequeña como para dominar la latencia. En Claude, la mayor mejora medida corresponde al coste —un ahorro de ~88–89% en el input leído desde caché—. Según las cifras publicadas por Anthropic, en prompts de 100K tokens o más, la reducción del TTFT aumenta considerablemente.

En interfaces de chat, los usuarios empiezan a percibir conscientemente la espera cuando el TTFT supera aproximadamente 1 s y el primer texto útil tarda ~2 s. Un prompt RAG de 10K tokens sin caché supera claramente ese umbral. Con caché, la misma carga parece instantánea.

En loops de agentes con 15 o más pasos, ahorrar un 50% está bien, pero la reducción de latencia es lo que hace viable el producto: 15 pasos × 5s de prefill = 75 s de espera improductiva por tarea. Con caché, se reduce a 15 × 0.5s = 7.5 s.

2.3 Por qué afecta a la estrategia de producto

Un error frecuente consiste en considerar la caché como «una optimización de costes de operaciones» que se añade después del lanzamiento. Sin embargo, al reducir la latencia, también forma parte de la experiencia de usuario:

• Un chatbot con un TTFT inferior a 1 s parece ágil; el mismo bot con 3 s parece averiado.
• Un producto RAG en el que la recuperación y el prefill tardan 4 s pierde frente al mismo producto si tarda 1 s.
• Un agente que completa una tarea en 20 s supera a otro que necesita 90 s.

La estrategia de caché debe decidirse al mismo tiempo que el modelo y la estructura del prompt, no tres sprints después del lanzamiento.

3. Vigencia de la caché, TTL y modelo operativo

El TTL es uno de los temas que más dudas genera y peor se explica al hablar de caché de prompts. Hay que distinguir dos aspectos:

3.1 «Vigencia» puede referirse a dos cosas distintas

La vigencia de la caché no equivale a la vigencia de la respuesta. Son dos conceptos diferentes que suelen confundirse:

Las respuestas que usan la caché no quedan «obsoletas» desde el punto de vista de la calidad del modelo. Son matemáticamente idénticas a las que se generarían sin caché. Pero si incluyes «la hora actual es 14:32:05» en el system prompt y dependes de los hits de caché, la «hora actual» seguirá siendo 14:32:05 hasta que venza el TTL. El modelo dará a los usuarios una hora falsa con total seguridad.

3.2 Comportamiento del TTL según el proveedor

El valor predeterminado de 5 minutos no es arbitrario. Se aproxima al horizonte de presión sobre la memoria de la GPU para modelos populares en momentos de máxima carga. Como calculamos en §1.4, la KV cache de un contexto grande puede ocupar decenas de GB. Los proveedores no pueden conservarla indefinidamente.

3.3 Cómo diseñar teniendo en cuenta el TTL

Tres patrones que funcionan en producción:

Patrón A — Mantener calientes las sesiones. En un chat, la frecuencia natural de las solicitudes —de segundos a minutos entre turnos— mantiene activa la caché por sí sola. No necesitas preocuparte por el TTL; basta con no incluir datos dinámicos en el prefijo.

Patrón B — Heartbeat para procesos por lotes. En jobs por lotes que duran horas, envía una solicitud mínima cada TTL/2 para mantener caliente la caché. El coste es prácticamente cero —unos pocos tokens de input— y evita oleadas de expulsiones de caché.

Patrón C — Usar proveedores con TTL largos para almacenamiento en frío. Si tienes un documento de 50K tokens que se consulta de forma esporádica —por ejemplo, una vez por hora durante una semana—, las cachés explícitas de Gemini con TTL de 24 horas o las cachés en disco de DeepSeek rendirán mejor que las alternativas con TTL cortos, aunque cobren por el almacenamiento.

4. Principios universales que todo desarrollador debe conocer

Los proveedores ofrecen la caché de cinco formas muy distintas: marcadores explícitos, automatización completa, modelos híbridos, almacenamiento arquitectónico en disco o ninguna opción. El siguiente artículo está dedicado a compararlas: Parte 2 — Comparativa y evaluación de proveedores. Sin embargo, hay cuatro principios que se cumplen independientemente del proveedor y se derivan directamente de la arquitectura que acabamos de explicar:

4.1 La caché se basa en prefijos: el orden importa

Como K/V en la posición i depende de los tokens situados en 1…i, los proveedores solo pueden encontrar coincidencias en un prefijo contiguo que empiece en el token 0. Si cambias un solo carácter en la posición 0, se invalida todo el prefijo. El contenido estable debe ir primero y el contenido variable, al final. No es una heurística, sino una consecuencia directa de la estructura causal del self-attention (§1.1).

4.2 La caché almacena K/V, no respuestas

Un hit de caché no devuelve una respuesta generada anteriormente. Devuelve los vectores K y V calculados previamente, que el modelo utiliza para generar una respuesta nueva a la pregunta actual. Por tanto:

• La calidad del output es idéntica a la de una llamada sin caché (§1.1).
• El output mantiene el comportamiento no determinista habitual: temperature, top-p y demás parámetros siguen aplicándose.
• Las respuestas obtenidas mediante caché nunca quedan «obsoletas» desde el punto de vista de la calidad del modelo. Solo puede quedar desactualizado el contenido del prompt, como timestamps o precios. Consulta de nuevo §3.1.

4.3 Escribir en caché es una inversión, no sale gratis

En los proveedores que aplican un recargo por escritura —125% en Anthropic y 125% en las cachés explícitas de Gemini—, la primera llamada con un prefijo nuevo cuesta más que una llamada sin caché. El punto de equilibrio se alcanza rápido, normalmente con un solo hit. Pero si tu prefijo «estable» cambia en cada solicitud, pagarás la escritura una y otra vez sin obtener ningún beneficio. Presta atención si ordenas los documentos recuperados por relevancia: es el antipatrón clásico.

4.4 Las APIs de caché no son portables entre proveedores

cache_control (Anthropic) ≠ cached_content (Gemini) ≠ cache_id (Qwen). Si tu aplicación debe funcionar con varios proveedores, tendrás que mantener tres integraciones o colocar delante un Token Gateway que las unifique. La Parte 2 lo explica en detalle.

5. ¿La caché de prompts es ahorro garantizado?

Casi. Compensa cuando:

• Tus prompts tienen un prefijo estable: system prompt, base de conocimiento o esquemas de herramientas
• Las llamadas son frecuentes o están relacionadas: misma sesión, cargas por lotes o ejecuciones de agentes en curso
• Puedes estructurar los prompts para que el contenido estable vaya al principio

Si cumples estas tres condiciones, lo habitual es lograr un 50–90% menos de gasto y un TTFT entre 3–20× más rápido sin cambiar de modelo.

Próximamente: la Parte 2 — Comparativa de caché entre proveedores y marco de evaluación parte de la arquitectura descrita aquí para comparar, función por función, Claude, OpenAI, Gemini, DeepSeek y Qwen. También incluye criterios para elegir el proveedor adecuado según tu carga.

Inicio rápido: usa el SDK de OpenAI con cualquier proveedor

Synthorai expone un endpoint compatible con OpenAI. Basta con apuntar a él el SDK oficial openai para cambiar entre modelos —Claude, GPT, Gemini, DeepSeek y Qwen— modificando una sola línea. El gateway convierte cache_control a la sintaxis de caché nativa de cada proveedor.

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["SYNTHORAI_KEY"],
    base_url="https://synthorai.io/v1",
)

resp = client.chat.completions.create(
    model="claude-sonnet-4-5",                       # swap freely
    max_tokens=256,
    messages=[
        {"role": "system", "content": "You are a helpful assistant."},
        {"role": "user",   "content": "Hello"},
    ],
)

print(resp.choices[0].message.content)
print(resp.usage.prompt_tokens_details)  # cached_tokens when upstream reports it
print(resp.usage.cost)                   # USD per call (gateway-computed)

La misma llamada funciona con gpt-5.4-mini, gemini-2.5-pro, deepseek-v4-flash y qwen3-max; solo cambia el campo model. El gateway devuelve los metadatos del hit de caché en el campo estándar de OpenAI prompt_tokens_details.cached_tokens. También añade un campo cost en USD, para que no tengas que mantener localmente una matriz de precios por proveedor.

Preguntas frecuentes

¿La caché de prompts en LLM es lo mismo que la caché semántica? No. La caché de prompts se basa en prefijos: reutiliza valores K/V cuando hay una coincidencia exacta a nivel de token al principio del prompt. La caché semántica busca coincidencias a nivel de significado mediante embeddings y devuelve una respuesta anterior. Ambas son útiles, y un buen Token Gateway las combina por capas.

¿La caché de prompts cambia el output del modelo? No. K y V son funciones deterministas de los tokens de entrada (§1.1). Los logits que genera el modelo a partir de K/V almacenadas en caché son matemáticamente idénticos a los producidos con K/V recién calculadas. La caché es una optimización pura de eficiencia y no afecta a la calidad.

¿Por qué el TTL de la caché es tan corto? ¿No podrían conservarla para siempre? La KV cache es enorme: como se explica en §1.4, ocupa ~10 GB por contexto de 32K en un modelo 70B. La memoria de la GPU es el cuello de botella. Las cachés se expulsan cuando el servidor necesita esa memoria para las cargas activas. Las cachés respaldadas por disco, como las de DeepSeek, pueden durar horas; las que residen en memoria normalmente no.

¿Qué diferencia hay entre KV cache y caché de prompts? La KV cache es la estructura de datos en memoria que se utiliza durante la inferencia. La «caché de prompts» consiste en reutilizar esa KV cache entre solicitudes. Son las capas 1 y 2 de §1.5.

¿Los prompts almacenados en caché pueden quedar obsoletos y reducir la calidad? No desde el punto de vista del modelo. Sí desde el punto de vista del contenido si el prompt incluye información sensible al tiempo. La caché almacena vectores K/V, no hechos sobre el mundo. Consulta §3.1.

¿Cómo puedo medir la tasa de hits de caché? Todos los proveedores la incluyen en el objeto de uso de la respuesta: cache_read_input_tokens (Anthropic), cached_tokens (OpenAI), cached_content_token_count (Gemini) y prompt_cache_hit_tokens (DeepSeek). Registra estos campos en tu pipeline de logging.

Referencias y fuentes: Vaswani et al., “Attention Is All You Need” (NeurIPS 2017) · Pope et al., “Efficiently Scaling Transformer Inference” (2022) · Kwon et al., “Efficient Memory Management for LLM Serving with PagedAttention” (SOSP 2023, vLLM) · DeepSeek-AI, “DeepSeek-V2: A Strong, Economical, and Efficient MoE Language Model” (2024) — arquitectura MLA · Documentación de Anthropic sobre caché de prompts · Documentación de OpenAI sobre caché de prompts · Documentación de Google Gemini sobre caché de contexto · Guía de DeepSeek sobre KV cache · Caché de contexto de Alibaba Bailian

← Volver al blog