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

En resumen — La caché de prompts en LLM no es una optimización añadida; surge de cómo la arquitectura Transformer calcula realmente la atención. Una vez que entiendes por qué los vectores Clave/Valor de un prefijo estable son matemáticamente reutilizables, la verdadera sorpresa pasa a ser el doble beneficio: una reducción de coste drástica (50–90 %) y una reducción drástica del tiempo hasta el primer token (5–20×). Este artículo —la primera parte de una serie de cuatro entregas— cubre la razón arquitectónica de la existencia de la caché, el equilibrio memoria-frente-a-cómputo que determina si una caché compensa y el comportamiento del TTL que todo desarrollador debe entender. La Parte 2 profundiza en las implementaciones propias de cada proveedor.

Serie: Parte 1 de 4 — Principios de la caché · Siguiente: Parte 2 — Comparativa y evaluación de proveedores · Parte 3 — Tutorial con código funcional · Parte 4 — El mejor LLM según el caso de uso

Por qué la factura de tokens de tu app de IA crece más rápido que tus usuarios

Si estás lanzando un chatbot, una app RAG o un agente de IA, probablemente hayas chocado contra el mismo muro: tu factura se duplica mientras tu uso no. Abre el registro de peticiones y encontrarás el mismo prompt de sistema de varios miles de tokens, las mismas descripciones de herramientas, los mismos fragmentos de la base de conocimiento: reenviados en cada llamada.

Ese es el problema económico central de la inferencia en LLM: el modelo no tiene estado. Cada petición vuelve a procesar todo el contexto desde cero. Un prompt de sistema de 8K tokens llamado 1000 veces equivale a 8 millones de tokens de trabajo repetido. Pagas por cada uno de ellos, y tus usuarios esperan por cada uno de ellos.

La caché de prompts soluciona esto. Pero, a diferencia de la mayoría de los trucos de rendimiento, no se añade a la arquitectura: es una consecuencia natural de cómo se define la atención del Transformer. Una vez que lo ves, el resto del artículo (precios, TTL, diferencias entre proveedores) encaja con limpieza.

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

Esta sección es la parte que casi todos los tutoriales de «caché de prompts» se saltan. Es la parte que explica por qué existe la caché en primer lugar, y por qué los descuentos que ofrecen los proveedores no son cifras de marketing arbitrarias, sino que reflejan una economía de GPU real.

1.1 La autoatención en una sola ecuación

Un Transformer solo decodificador (la familia a la que pertenecen GPT-4, Claude, Gemini, DeepSeek y Qwen) procesa los tokens aplicando repetidamente la autoatención. Para una secuencia de N tokens, la salida de atención para cada token i es:

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

donde Q, K, V son matrices de forma [N × d] derivadas de los embeddings de entrada mediante tres proyecciones lineales aprendidas (una por capa por cabeza). La definición original proviene de Attention Is All You Need (Vaswani et al., 2017).

Dos propiedades de esta ecuación importan enormemente para la caché:

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

Propiedad 2 — K y V dependen solo 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 en la posición i son una función determinista de los tokens en las posiciones 1…i —y solo de esos tokens—. Nada acerca de la posición i+1 puede cambiar K_i ni V_i.

La implicación es inmediata: si dos peticiones 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. Todo lo demás es ingeniería.

1.2 Las dos fases de la inferencia

La inferencia moderna en LLM se ejecuta en dos fases distintas que consumen el tiempo de GPU de maneras muy diferentes. Esta división está documentada exhaustivamente en Efficiently Scaling Transformer Inference (Pope et al., 2022).

Fase de prellenado (prefill). El modelo ingiere el prompt completo de una vez. Para cada capa, calcula Q, K, V para cada token de entrada y ejecuta la autoatención. El prefill está limitado por el cómputo: satura las unidades de multiplicación de matrices de la GPU. El coste escala como O(N²) con la longitud del prompt debido a la matriz de atención.

Fase de decodificación (decode). El modelo produce un token de salida cada vez, de forma autorregresiva. En el paso t, solo se calcula la Q del nuevo token; este atiende a las K/V de todos los tokens previos. El decode está limitado por el ancho de banda de memoria: la mayor parte del tiempo se dedica a leer las K/V de la memoria de la GPU, no a multiplicar. El coste escala como O(N) por token (lineal con la longitud de contexto actual).

Para una carga típica de chatbot (prompt de sistema de 8K tokens + consulta de usuario de 100 tokens + respuesta de 300 tokens), el prefill domina el tiempo de reloj y el coste en dólares en una proporción de aproximadamente 4:1. Eso es lo que ahorra la caché.

Desglose por llamada (prompt 8K, 300 tokens de salida, modelo de clase Claude):

  ████████████████████████████████░░░░░░░░  Prefill: ~80 % del cómputo
  ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░████████  Decode:  ~20 % del cómputo

1.3 La caché KV: guardar el trabajo de prefill para el decode

La «caché KV» se refería originalmente a una optimización dentro de la propia petición. Durante la decodificación, cada token recién generado necesita atender a las K y V de cada token previo. Recalcularlas en cada paso convertiría un decode O(N) en un decode O(N²). Por eso cada motor de inferencia almacena las K y V del prefill en la memoria de la GPU y las reutiliza durante toda la fase de decode. Esto es universal: lo hace cada LLM comercial. Es lo que hace que la generación sea siquiera viable.

Lo que los proveedores exponen como «caché de prompts» es la siguiente generalización: mantener la caché KV después de que la petición termine y reutilizarla para la siguiente petición que comparta el mismo prefijo.

1.4 El equilibrio memoria–cómputo (por qué existen los TTL)

Entonces, ¿por qué no almacena cada proveedor simplemente todo para siempre? Porque la caché KV es enorme.

Para un modelo con L capas Transformer, H cabezas de atención, D dimensión de cabeza y B bytes por valor (típicamente 2 para fp16), el tamaño de la caché KV para N tokens es:

Tamaño de caché KV  =  2 × L × H × D × B × N
                       ↑   ↑   ↑   ↑   ↑   ↑
                      K&V capas cabezas cabeza bytes tokens

Para un modelo de clase 70B con 80 capas, 8 cabezas KV (tras la atención por consultas agrupadas), 128 de dimensión de cabeza y pesos fp16, eso son aproximadamente 320 KB por token. Un contexto de 32K tokens = ~10 GB de caché KV, solo para una petición. Una GPU H100 moderna tiene 80 GB; como mucho puedes alojar un puñado de estas simultáneamente.

Esta es la restricción central que PagedAttention (Kwon et al., 2023, el artículo detrás de vLLM) se diseñó para resolver a nivel de lote (batch), y la misma restricción es la que acota la caché de prompts a nivel entre peticiones:

Así pues, el TTL de la caché de un proveedor es esencialmente una política de desalojo de memoria: en algún momento la GPU necesita esa memoria para las cargas activas de otros usuarios, y el prefijo en caché se desaloja. 5 minutos para cachés residentes en HBM; hasta 1 hora para cachés paginadas a DRAM; horas para cachés respaldadas en disco.

El truco de DeepSeek. DeepSeek-V2 introdujo la Multi-head Latent Attention (MLA), que comprime la caché KV en aproximadamente 4× respecto a la atención por consultas agrupadas estándar (DeepSeek-AI, 2024). Esa compresión es exactamente lo que les permite persistir la caché KV en disco en lugar de en HBM, lo que a su vez habilita una unidad mínima de caché mucho menor (64 tokens frente a 1024 para 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 peticiones requiere prefijos idénticos token a token. La caché se indexa mediante un hash de los identificadores de token, y cualquier divergencia —aunque sea un solo carácter que se tokenice de forma distinta— produce una K y una V diferentes a partir de ese punto. No hay «coincidencia difusa» en esta capa (eso es lo que hace la caché semántica, pero es un mecanismo distinto dentro de la pasarela).

1.5 Dos capas de caché

┌──────────────────────────────────────────────────────────────┐
│  Capa 1: caché KV por petición (siempre activa, todo proveedor)│
│  → mantiene el decode en O(N) en lugar de O(N²)             │
│  → no te ocupas de ella; el proveedor simplemente lo hace    │
└──────────────────────────────────────────────────────────────┘
                              ↓
┌──────────────────────────────────────────────────────────────┐
│  Capa 2: caché de prompts entre peticiones (el ahorro de     │
│           dinero y tiempo del que trata esta serie)           │
│  → reutiliza las K/V del prefill entre peticiones con prefijos coincidentes │
│  → expuesta como: explícita / totalmente automática / híbrida │
│  → acotada por el TTL (impulsado por el desalojo de memoria) │
└──────────────────────────────────────────────────────────────┘

El resto de la serie —y la mayor parte de lo que ajustarás como desarrollador— vive en la Capa 2.

2. Las dos victorias: coste Y latencia

La mayoría de los artículos plantean la caché como una optimización de coste. Eso la infravalora. La victoria en latencia suele ser la razón más grande por la que los equipos de producción adoptan la caché, especialmente para el chat de cara al usuario.

2.1 Las matemáticas del coste

Las páginas de precios dan las cifras de titular, pero rara vez las muestran aplicadas a una carga realista. Toma un bot de soporte al cliente con un prompt de sistema de 8000 tokens, 100K consultas/día y mensajes de usuario de 200 tokens. Valorándolo en claude-sonnet-4-5 con las tarifas publicadas de Anthropic para 2026 (10 % para la entrada en caché, recargo del 125 % por escritura de caché):

Sin caché

• Entrada por llamada: 8200 tokens × tarifa de entrada base
• Coste por llamada (medido en llamada única): ~0,022 $
• Coste mensual: 100K × 30 × 0,022 $ = ~66 000 $

Con caché de prompts

• Escritura única de caché: 8000 tokens × recargo del 125 % (despreciable frente al volumen mensual)
• Por llamada a partir de entonces: 8000 tokens × 10 % base + 200 tokens × base + salida
• Coste efectivo por llamada: ~0,003 $
• Coste mensual: ~9000 $

~86 % ahorrado. Esa cifra es el descuento publicado de Anthropic aplicado a una forma de entrada realista. El artículo que sigue (Parte 3 — Tutorial) muestra cifras reales medidas en el resto de los proveedores.

2.2 La victoria en latencia (a menudo la historia más grande)

El prefill no solo es caro: es el mayor contribuyente individual al tiempo hasta el primer token para cualquier prompt de más de unos pocos cientos de tokens. Los aciertos de caché te permiten saltarte casi todo él.

TTFT de streaming medido contra la pasarela pública de Synthorai, 2026-05-25, prompt de sistema estable de ~7300 tokens:

Ejecución única, monoinquilino. La victoria en TTFT es más visible en prompts largos (>5K tokens); para prompts cortos, la porción de prefill es demasiado pequeña para dominar la latencia. La mayor victoria medida de Claude es el coste (~88–89 % de reducción en la entrada por lectura de caché); para tamaños de prompt en el rango de 100K+, la victoria en TTFT se acumula sustancialmente según las cifras publicadas por Anthropic.

Para interfaces de chat, el umbral por encima del cual los usuarios perciben conscientemente un retraso ronda 1 s para el TTFT y ~2 s para el primer texto útil. Un prompt RAG de 10K tokens sin caché está claramente por encima de esa línea. Con caché, la misma carga se siente instantánea.

Para bucles de agente con más de 15 pasos, la historia del coste es buena (50 % ahorrado), pero la historia de la latencia es lo que hace que el producto sea realmente entregable: 15 pasos × 5 s de prefill = 75 s de tiempo muerto por tarea → con caché, 15 × 0,5 s = 7,5 s.

2.3 Por qué esto importa para la estrategia de producto

Un error común es tratar la caché como «ops haciendo optimización de coste», algo que añades tras el lanzamiento. Pero la victoria en latencia significa que la caché también forma parte de la superficie de UX:

• Un chatbot con un TTFT inferior a 1 s se siente vivo; el mismo bot a 3 s se siente roto.
• Un producto RAG donde la recuperación+prefill tarda 4 s pierde frente al mismo producto donde tarda 1 s.
• Un agente que completa una tarea en 20 s gana frente a uno que tarda 90 s.

Deberías estar decidiendo la estrategia de caché al mismo tiempo que decides tu modelo y la estructura de tu prompt, no tres sprints después del lanzamiento.

3. Frescura de la caché, TTL y el modelo operativo

La cuestión del TTL es una de las partes más preguntadas y menos explicadas de la caché de prompts. Dos cosas que entender:

3.1 La frescura tiene dos significados: no los confundas

Frescura de la caché ≠ frescura de la respuesta. Dos conceptos distintos suelen mezclarse:

En otras palabras: las respuestas en caché no están «obsoletas» en ningún sentido de calidad del modelo. Son matemáticamente idénticas a las no almacenadas en caché. Pero si pones «la hora actual es las 14:32:05» en tu prompt de sistema y dependes de los aciertos de caché, tu «hora actual» permanece en las 14:32:05 hasta que expire el TTL y tu modelo mentirá con seguridad a los usuarios al respecto.

3.2 Comportamiento del TTL entre proveedores

El valor por defecto de 5 minutos no es arbitrario: corresponde aproximadamente al horizonte de presión de memoria de GPU de los modelos populares en carga máxima. Como calculamos en §1.4, la caché KV de un contexto grande puede ser de decenas de GB; los proveedores no pueden permitirse retenerlas indefinidamente.

3.3 Diseñar pensando en el TTL

Tres patrones que funcionan en producción:

Patrón A — Mantener las sesiones calientes. Para el chat, la cadencia natural de peticiones (de segundos a minutos entre turnos) mantiene la caché viva por sí sola. No te preocupes por el TTL; simplemente no pongas datos dinámicos en el prefijo.

Patrón B — Latido para el batch. Para trabajos por lotes que abarcan horas, envía una petición mínima cada TTL/2 para mantener la caché caliente. El coste es esencialmente nulo (unos pocos tokens de entrada) y previene tormentas de desalojo de caché.

Patrón C — Usar proveedores de TTL largo para almacenamiento en frío. Si tienes un documento de 50K tokens que se consulta de forma esporádica (p. ej., una vez por hora durante una semana), las cachés explícitas de Gemini (TTL de 24 horas) o las cachés en disco de DeepSeek superarán a las alternativas de TTL corto pese a la tarifa de almacenamiento.

4. Principios universales que todo desarrollador debería conocer

Los proveedores exponen la caché en cinco formas muy distintas: marcadores explícitos, totalmente automática, híbrida, respaldo arquitectónico en disco o ninguna en absoluto. Dedicamos el próximo artículo a esa comparativa (Parte 2 — Comparativa y evaluación de proveedores). Pero cuatro principios se aplican independientemente del proveedor y se derivan directamente de la arquitectura que acabamos de recorrer:

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

Como las K/V en la posición i dependen de los tokens en las posiciones 1…i, los proveedores solo pueden hacer coincidir un prefijo contiguo que empiece en el token 0. Cambia un solo carácter en la posición 0 y todo el prefijo se invalida. El contenido estable primero, el contenido volátil al final. Esto no es una heurística: es una consecuencia directa de la estructura causal de la autoatención (§1.1).

4.2 La caché almacena K/V, no respuestas

Un acierto de caché no devuelve una respuesta generada previamente: devuelve vectores K y V calculados previamente, que el modelo usa luego para generar una respuesta nueva a la pregunta actual. Esto significa:

• La calidad de la salida es idéntica a la de una llamada sin caché (§1.1).
• La salida es no determinista de las formas habituales: la temperatura, el top-p, etc., siguen aplicándose.
• Las respuestas en caché nunca están «obsoletas» en el sentido de calidad del modelo: solo el contenido de tu prompt (marcas de tiempo, precios) puede estar obsoleto. Vuelve a ver §3.1.

4.3 Las escrituras de caché son inversiones, no gratis

Para los proveedores que cobran un recargo por escritura (Anthropic 125 %, Gemini explícita 125 %), la primera llamada con un prefijo nuevo cuesta más que no usar caché. El punto de equilibrio se alcanza rápido (normalmente un solo acierto), pero si tu prefijo «estable» cambia en cada petición, pagarás costes de escritura una y otra vez sin retorno. Vigila esto si ordenas los documentos recuperados por relevancia: ese es el antipatrón clásico.

4.4 Las API 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, o bien mantienes tres integraciones, o pones un Token Gateway delante para unificarlas. La Parte 2 cubre esto en detalle.

5. ¿Es la caché de prompts dinero gratis?

Casi. Compensa cuando:

• Tus prompts tienen un prefijo estable: prompt de sistema, base de conocimiento, esquemas de herramientas
• Tus llamadas son frecuentes o conectadas: misma sesión, cargas por lotes, ejecuciones de agente en curso
• Puedes estructurar los prompts para que el contenido estable se sitúe al frente

Cumple esos tres y normalmente verás un 50–90 % menos de gasto y un TTFT 3–20× más rápido sin cambiar de modelo.

A continuación: la Parte 2 — Comparativa de caché entre proveedores y marco de evaluación toma el panorama arquitectónico anterior y lo convierte en una comparativa función por función de Claude, OpenAI, Gemini, DeepSeek y Qwen, con una rúbrica de evaluación para elegir el proveedor adecuado para tu carga.

Inicio rápido: usa el SDK de OpenAI contra todos los proveedores

Synthorai expone un endpoint compatible con OpenAI: apunta el SDK oficial openai hacia él y cada modelo (Claude, GPT, Gemini, DeepSeek, Qwen) se convierte en un cambio de modelo de una sola línea. La pasarela traduce 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 para gpt-5.4-mini, gemini-2.5-pro, deepseek-v4-flash, qwen3-max: solo cambia el campo model. La pasarela devuelve los metadatos de acierto de la caché de prompts en el campo estándar de OpenAI prompt_tokens_details.cached_tokens, además de un campo cost en USD, de modo que no necesitas mantener localmente una matriz de precios por proveedor.

Preguntas frecuentes

¿Es la caché de prompts en LLM lo mismo que la caché semántica? No. La caché de prompts es basada en el prefijo: reutiliza los valores K/V para una coincidencia exacta a nivel de token al inicio del prompt. La caché semántica coincide a nivel de significado (mediante embeddings) y devuelve una respuesta previa. Ambas son útiles, y un buen Token Gateway las combina en capas.

¿Cambia la caché de prompts la salida del modelo? No. K y V son funciones deterministas de los tokens de entrada (§1.1). Los logits que el modelo produce a partir de una K/V en caché son matemáticamente idénticos a los de una K/V recalculada de nuevo. La caché es una optimización de eficiencia pura, sin impacto en la calidad.

¿Por qué es tan corto el TTL de la caché? ¿No pueden simplemente conservarla para siempre? La caché KV es enorme (§1.4: ~10 GB por contexto de 32K para un modelo de 70B). La memoria de la GPU es el cuello de botella; las cachés se desalojan cada vez que el servidor necesita esa memoria para cargas activas. Las cachés respaldadas en disco (DeepSeek) pueden vivir horas, pero las cachés en memoria normalmente no pueden.

¿Cuál es la diferencia entre caché KV y caché de prompt? La caché KV es la estructura de datos en memoria usada durante la inferencia. La «caché de prompt» es la reutilización entre peticiones de esa caché KV. Capa 1 frente a Capa 2 en §1.5 más arriba.

¿Las prompts en caché alguna vez quedan obsoletas de un modo que degrade la calidad? No, desde la perspectiva del modelo. Sí, desde la perspectiva de tu contenido si tu prompt codifica información sensible al tiempo. La caché almacena vectores K/V, no hechos sobre el mundo. Ver §3.1.

¿Cómo mido la tasa de aciertos de caché? Cada proveedor la devuelve en el objeto usage de la respuesta: cache_read_input_tokens (Anthropic), cached_tokens (OpenAI), cached_content_token_count (Gemini), prompt_cache_hit_tokens (DeepSeek). Haz seguimiento de estos valores en tu canalización de registro.

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) — MLA architecture · Anthropic Prompt Caching docs · OpenAI Prompt Caching docs · Google Gemini Context Caching docs · DeepSeek KV Cache guide · Alibaba Bailian Context Cache

← Volver al blog