KV cache: cómo funciona y qué ahorra en un LLM

La KV cache permite que un modelo reutilice trabajo que ya hizo; por eso la entrada almacenada en caché cuesta menos. Conserva 2 conjuntos de datos de atención, las claves y los valores, para que un modelo de lenguaje de gran tamaño pueda continuar una conversación sin reconstruir el estado de cada token anterior. Así se abarata el procesamiento del contexto repetido, aunque las conversaciones largas siguen ocupando memoria y dejan más contexto al que cada nuevo token debe prestar atención.

Conserva los prefijos útiles y controla cuánto historial retienes. Son tareas distintas. Un prefijo es la parte inicial de una solicitud que permanece igual; guardarlo en caché puede reducir el procesamiento de la entrada, pero no elimina el resto del trabajo del agente.

Los precios y las reglas de caché que aparecen a continuación se verificaron en las páginas de precios y la documentación de los proveedores el 15 de octubre de 2026. Los cálculos de memoria se derivan de las dimensiones documentadas de los tensores, no de mediciones en una GPU concreta.

¿Qué es KV cache y qué trabajo evita repetir?

La KV cache almacena el estado de atención. La atención es el mecanismo con el que un transformer incorpora información anterior relevante a su predicción actual. Un token, una unidad de texto o de otro tipo de entrada del modelo, genera representaciones numéricas dentro de cada capa de atención. La caché conserva las claves y los valores de esa capa para utilizarlos después. La explicación de la caché de Hugging Face describe este almacenamiento por capas.

Las tres funciones de la atención se entienden mejor con la imagen de una biblioteca de investigación:

• Una consulta expresa qué busca la posición actual.
• Una clave permite comparar una posición anterior con esa consulta.
• Un valor aporta la información que puede contribuir cuando hay una coincidencia.

Imagina que preparas un conjunto de notas de investigación con un índice antes de redactar un informe. Para escribir cada nueva frase, puedes consultar las notas que ya preparaste. Reconstruir el índice y las notas en cada frase repetiría trabajo; conservarlos ocupa espacio. La analogía termina al llegar a la implementación: el modelo almacena arreglos numéricos, no fichas legibles ni un resumen de tus documentos.

La consulta actual se compara con las claves anteriores y los pesos de atención resultantes combinan sus valores. En un transformer causal, las posiciones anteriores no pueden mirar hacia el futuro. Por eso, añadir un token posterior no exige modificar los estados ya calculados de las posiciones anteriores. Esa es la base que permite reutilizarlos. El artículo original de PagedAttention describe estos cálculos de atención y el proceso de generación.

Esto también explica por qué la caché habitual guarda K y V, en lugar de todas las consultas anteriores. La siguiente predicción necesita la consulta actual y las claves y los valores acumulados; las consultas anteriores ya cumplieron su función.

En un agente de soporte, los estados conservados pueden representar sus instrucciones, definiciones de herramientas, documentos de políticas y la conversación hasta ese momento. Son específicos del modelo y del contexto que los precede. No son los pesos aprendidos por el modelo ni una base de datos de memoria permanente sobre el cliente.

Un prefijo en caché tampoco es una respuesta en caché. El modelo sigue generando una continuación nueva. Una pregunta distinta sobre el mismo documento puede reutilizar el estado ya preparado de ese documento sin devolver la respuesta anterior.

Prefill y decode: las dos fases que explica la KV cache

Prefill prepara la entrada; decode genera la continuación a partir de ella. Estas fases explican por qué una solicitud puede empezar a responder antes cuando encuentra datos en caché y, aun así, tardar en terminar.

El recorrido de un transformer autorregresivo convencional puede expresarse así:

Prefill: tokens del prompt → procesar el prompt → conservar las claves y los valores de cada capa → predecir el primer token de salida.

Decode: último token generado + claves y valores conservados → procesar ese token y atender al contexto → predecir el siguiente token; añadir las claves y los valores recién calculados.

Repetir decode: reutilizar la caché, que sigue creciendo, hasta que termine la generación.

Prefill puede procesar juntas las posiciones conocidas del prompt. Decode avanza por una continuación cuyos tokens posteriores todavía no se han elegido. El flujo de generación y ejecución del artículo de PagedAttention describe esta diferencia.

La KV cache abarata el siguiente token en comparación con recalcular todo el prefijo. Eso no significa que el costo del siguiente token deje de depender de la longitud del contexto. Con atención completa convencional, su consulta sigue interactuando con las claves y los valores conservados. Cuanto más contexto se retiene, más datos de atención hay que utilizar. Hugging Face documenta este trabajo de atención que sigue siendo necesario en cada paso.

Conviene distinguir dos tipos de reutilización. Dentro de una respuesta, la caché KV evita repetir cálculos durante la generación. Entre solicitudes, la caché de prefijos, también llamada prompt caching en las API alojadas, conserva los estados que cumplen los requisitos para que una llamada posterior pueda omitir parte del trabajo de prefill. Un identificador de conversación, por sí solo, no demuestra que esos estados estén disponibles.

Supongamos que un agente lee un documento de políticas, llama a una herramienta y después pide al modelo que decida qué hacer con el resultado. La siguiente solicitud puede conservar las instrucciones y el documento anteriores como prefijo común, y añadir al final el resultado de la herramienta. Si la caché cumple los requisitos y está disponible, el proveedor no necesita preparar de nuevo ese comienzo compartido.

Para quien desarrolla con una API, esto justifica revisar tanto la espera hasta el primer token como el tiempo dedicado a generar la respuesta. Reducir la primera no demuestra que decode sea más rápido. La documentación de Automatic Prefix Caching de vLLM distingue expresamente el ahorro en prefill del tiempo de decode.

Caché de prompts: cómo se factura el trabajo reutilizado

El descuento corresponde al trabajo de entrada reutilizado, según las condiciones de facturación de cada proveedor. No hay un porcentaje universal ni se aplica el descuento a todos los tokens de una solicitud por el hecho de que una parte coincida con la caché.

En las API que distinguen entre entrada normal, escrituras y lecturas de caché, el costo de la entrada puede expresarse así:

Costo de entrada = (U × p_input + W × p_write + R × p_read) / 1,000,000

Aquí, U representa los tokens de entrada normal; W, los tokens facturados como escrituras de caché; y R, los facturados como lecturas de caché. Cada p es el precio por millón de tokens de esa categoría. Las categorías deben ser mutuamente excluyentes: un token de escritura no debe cobrarse de nuevo a la tarifa de entrada normal. Es un cálculo dimensional basado en las categorías de precios de OpenAI y Anthropic.

Después se suman la salida, los cargos por herramientas que correspondan y cualquier almacenamiento de caché facturado por separado. La caché explícita de Google incorpora el tiempo de retención, por lo que un cálculo limitado a escrituras y lecturas resulta insuficiente. Los siguientes ejemplos ilustran las condiciones de cada servicio; no son una clasificación de los modelos.

Anthropic: señala el final del prefijo reutilizable

Anthropic ofrece caché de prompts mediante cache_control, ya sea en el nivel superior de la solicitud para gestionar automáticamente los puntos de corte, o en bloques de contenido individuales. Un punto de corte marca el final del prefijo que se quiere conservar. Su documentación de precios describe ambas opciones.

Ejemplo de precios, API estándar de Claude: en Claude Sonnet 5.5, la entrada cuesta $2; las lecturas de caché, $0.10; las escrituras con retención de 5 minutos, $2.50; y las escrituras con retención de 1 hora, $4. Todos los importes son por millón de tokens. Precios de Anthropic.

En este modelo, el prefijo mínimo que puede almacenarse en caché es de 512 tokens. El contenido debe coincidir exactamente hasta el límite de la caché. Las lecturas renuevan su vigencia sin otro cargo de escritura, pero el plazo empieza cuando se inicia la solicitud, de modo que la generación de la respuesta consume parte de ese intervalo. Otros modelos Claude tienen mínimos y descuentos de lectura distintos. Reglas de caché de prompts de Anthropic.

En un agente documental que reanuda el trabajo después de una larga pausa del usuario, la retención puede determinar si la siguiente llamada lee un prefijo existente o vuelve a escribirlo. Revisa cache_creation_input_tokens y cache_read_input_tokens en los datos de uso: repetir un documento no demuestra, por sí solo, que se haya producido una lectura con descuento. Campos de uso.

OpenAI: revisa las reglas de escritura de cada modelo

OpenAI activa la caché de prompts de forma predeterminada en los modelos compatibles, y los más recientes admiten puntos de corte tanto implícitos como explícitos. El comportamiento depende del modelo. Caché de prompts de OpenAI.

Ejemplo de precios, nivel Standard de contexto corto: en GPT-6.1 Sol, la entrada cuesta $2.00; la entrada en caché, $0.10; y las escrituras de caché, $2.50 por millón de tokens. Las tarifas de entrada y caché de toda la solicitud se duplican al superar los 272K tokens de entrada. Precios de OpenAI, umbral del modelo.

Para GPT-5.6 y posteriores, el mínimo es de 1,024 tokens de entrada visibles, y la vigencia documentada de la caché es de al menos 30 minutos desde la última escritura o reutilización. La tarifa de escritura de caché sustituye a la tarifa de entrada normal para esos tokens; no supone cobrar de nuevo toda la entrada. Los modelos anteriores tienen otras reglas de escritura y retención. Condiciones vigentes de la caché.

En la Responses API, revisa usage.input_tokens_details.cached_tokens y cache_write_tokens. Mantener una sesión no garantiza un acierto de caché. Consulta la guía del sitio para diagnosticar la caché de prompts de GPT-6 cuando necesites investigar la estructura de la solicitud y el uso que informa el proveedor.

Google Gemini: reutilizar de forma implícita y almacenar de forma explícita son cosas distintas

Google Gemini ofrece caché implícita automática, y traslada el ahorro al cliente cuando se produce un acierto. En el ejemplo de Gemini 3.8 Flash, el mínimo documentado es de 4,096 tokens de entrada. Situar el contenido compartido al principio y hacer las solicitudes con poca separación temporal aumenta la probabilidad de reutilización. Guía de caché de contexto de Google.

Ejemplo de precios, nivel Standard de pago de Gemini Developer API: en Gemini 3.8 Flash, la entrada cuesta $0.75 y la entrada en caché, $0.075 por millón de tokens. El almacenamiento de caché explícita cuesta $0.50 por millón de tokens por hora, hasta el 31 de diciembre de 2026. Precios de Google.

La caché explícita utiliza un recurso de contenido en caché con nombre y una configuración de caducidad, al que hacen referencia las solicitudes posteriores de generateContent. Su cargo de almacenamiento implica que conservar un documento sin usarlo también puede costar dinero. Referencia de la API de caché de Google.

La elección de API importa: la Interactions API solo admite caché implícita. La guía actual de Google también excluye la caché explícita para Gemini 4 Argon y posteriores; los modelos compatibles de Gemini 3 y 2.5 utilizan generateContent para las cachés explícitas. En la Interactions API, revisa usage.total_cached_tokens, tal como indica la guía. Reglas de Google para cada API.

Para quien opera con una API, la diferencia práctica está entre observar aciertos automáticos y pagar deliberadamente por conservar un recurso. Al diseñar una abstracción de caché para varios proveedores, no des por hecho que ambos tienen el mismo ciclo de vida.

La memoria de la KV cache crece con el contexto que conservas

En las capas convencionales de atención completa, la memoria KV sin sobrecargas crece de forma lineal con los tokens retenidos. Una conversación larga implica un conjunto de datos de trabajo cada vez mayor, aunque su comienzo cumpla los requisitos para un descuento.

Para secuencias de igual longitud y capas de atención con geometría uniforme:

KV bytes ≈ 2 × B × T × L × H_kv × D × S

• 2: un arreglo de claves y otro de valores.
• B: secuencias concurrentes, suponiendo que no comparten los datos de sus cachés.
• T: tokens procesados y conservados por secuencia, incluidos los del prompt y los generados.
• L: capas de atención que conservan este tipo de caché.
• H_kv: cabezas de claves y valores por capa.
• D: valores escalares por cabeza.
• S: bytes utilizados para almacenar cada valor escalar.

La fórmula se obtiene contando elementos a partir de las dimensiones documentadas de la caché por capa y de la disposición de las cabezas de claves y valores de vLLM. Estima el tamaño de los tensores en bruto, no toda la memoria del dispositivo.

El número de cabezas importa. En la atención de consultas agrupadas, varias cabezas de consulta comparten cabezas de claves y valores, por lo que esta fórmula necesita el número de cabezas KV. Sustituirlo por el número de cabezas de consulta, que es mayor, sobreestimaría el tamaño de la caché.

Si mantienes el modelo y la precisión de almacenamiento y duplicas T, la caché densa en bruto duplica su tamaño. Si duplicas tanto T como el número de secuencias concurrentes independientes, pasa a ser cuatro veces mayor. Ese resultado es algebraico; no afirma nada sobre la capacidad de una GPU concreta ni sobre su rendimiento medido.

Para un servicio de soporte alojado en infraestructura propia, esto plantea una pregunta útil al planificar capacidad: ¿cuántos tokens retenidos están activos a la vez entre todos los clientes? Que el modelo quepa en memoria es solo el comienzo. El servidor también debe alojar el estado de inferencia cambiante de esos clientes.

La documentación de estrategias de caché de Hugging Face describe el límite de las capas con ventana, mientras que el diseño de la caché de prefijos de vLLM explica los bloques físicos reutilizables. Utiliza la disposición de estado documentada para la arquitectura cuando difiera de estos arreglos densos convencionales de claves y valores.

Para el cliente de una API alojada, ese mismo crecimiento tiene otra consecuencia visible: en cada turno pueden facturarse más tokens como lecturas, aunque la tasa de aciertos se mantenga estable. Un precio unitario menor multiplicado por una entrada cada vez mayor sigue dando un costo creciente. La generación de salida también continúa atendiendo al contexto, y los umbrales de las tarifas pueden depender de la longitud total de la entrada.

Cómo optimizar la KV cache en vLLM

vLLM, un motor de código abierto para servir LLM, permite controlar la asignación, la reutilización y la representación de los datos en infraestructura propia. Antes de modificar el despliegue, elige el control que resuelva tu cuello de botella.

PagedAttention: asigna bloques a medida que crece la conversación

PagedAttention permite que la atención opere sobre datos KV almacenados en bloques físicos separados. Una secuencia lógica no necesita reservar un gran espacio contiguo para todo lo que pueda llegar a crecer. El diseño original reduce el desperdicio en la asignación y permite compartir datos. Artículo de PagedAttention.

La analogía de la biblioteca sigue siendo útil: a un proyecto de investigación que va creciendo se le asignan secciones disponibles de las estanterías y se mantiene un mapa de su orden. No hace falta reservar un pasillo enorme y vacío antes de saber cuánto material producirá.

La paginación no reduce por sí sola la información almacenada por token. Mejora la forma en que esa información se acomoda en la memoria disponible. Además, vLLM identifica su página del kernel de Paged Attention como histórica: aprovecha el concepto sin tomar esa descripción antigua del kernel como si fuera la implementación actual.

Caché de prefijos: aprovecha el trabajo de una solicitud anterior

Automatic Prefix Caching reutiliza el estado KV de un prefijo coincidente. vLLM documenta la opción enable_prefix_caching=True; esta es la función pertinente cuando las preguntas sucesivas sobre un documento o los turnos de un agente mantienen el mismo comienzo. Caché automática de prefijos.

La identidad de la caché incluye el prefijo anterior, no solo el texto de un bloque aislado. Por eso no se puede asumir que dos párrafos idénticos sean intercambiables si van precedidos de instrucciones distintas. El diseño de caché basado en hashes de vLLM hace explícita esa dependencia.

El límite lo marca la carga de trabajo: los prompts sin relación entre sí comparten poco procesamiento, y en las respuestas largas decode puede seguir dominando el tiempo total. Si estás eligiendo el motor, la comparativa de vLLM y SGLang aborda esa decisión más amplia.

Cuantización de la KV cache: menos bytes por valor almacenado

La cuantización de la KV cache reduce la precisión de los valores numéricos guardados. vLLM admite almacenamiento de caché en FP8 mediante kv_cache_dtype="fp8" y recomienda calibrar las escalas con un conjunto de datos para cuidar la calidad. Las opciones disponibles dependen del backend de atención. Documentación de caché cuantizada de vLLM.

Pasar de valores de 16 bits a valores de 8 bits reduce a la mitad el tamaño de los datos escalares en la fórmula, antes de sumar los metadatos de escala y la sobrecarga de asignación. No reduce a la mitad toda la memoria del servidor ni demuestra una mejora de velocidad medida. Cuantizar los pesos del modelo y cuantizar el estado de atención son decisiones distintas.

En un agente en producción, evalúa las tareas largas que importan: mantener las restricciones, elegir herramientas y recuperar detalles de mensajes anteriores. Reducir el estado solo sirve si la tarea sigue resolviéndose bien. Que el servidor arranque no demuestra que la calidad se mantenga.

Compresión de la KV cache: distingue entre precisión y contenido

Conservar valores menos precisos y retener menos posiciones tienen consecuencias distintas. La cuantización cambia cómo se representan los valores. Una ventana de atención limitada cambia qué posiciones siguen disponibles para esa capa. Sus posibles fallos no deben agruparse bajo una afirmación genérica sobre compresión. Estrategias de caché de Hugging Face.

Un primer paso práctico es dejar de enviar resultados de herramientas que no aportan nada a la tarea. Eso reduce el contexto futuro desde su origen, pero es una decisión de la aplicación: conserva la evidencia que necesita el agente antes de optimizar el estado retenido.

Offloading de la KV cache: más estado retenido a cambio de transferencias

El offloading traslada el estado reutilizable a otro nivel de memoria. El OffloadingConnector de vLLM puede conservar bloques completos en la memoria del sistema anfitrión asociada a la CPU y en niveles secundarios compatibles, y devolver a la GPU los bloques que se reutilicen cuando hagan falta. Guía de offloading de vLLM.

Esto puede ayudar cuando los prefijos siguen siendo útiles después de dejar de residir en la GPU. También exige mover datos. Compara el beneficio de evitar nuevos cálculos con el trabajo de transferencia en tu carga concreta; no hay una mejora universal de latencia que pueda prometerse.

Cuando las solicitudes activas presionan la capacidad KV, vLLM puede interrumpirlas y repetir sus cálculos más adelante. Su guía de optimización recomienda revisar la concurrencia y la asignación de memoria si estas interrupciones, o preemptions, se vuelven frecuentes. Para quien opera el servicio, que aumente ese contador orienta mejor las acciones que el simple hecho de que la memoria de la GPU parezca llena.

Lo que una tasa alta de aciertos de caché no te dice

Una tasa alta de aciertos no equivale a un agente eficiente. Mide la reutilización, mientras que tu negocio necesita que la tarea se complete correctamente dentro de un tiempo y un presupuesto aceptables.

Una conversación puede reutilizar casi toda su entrada anterior y seguir creciendo en cada turno. Puede releer una y otra vez material irrelevante con descuento. También puede dedicar la mayor parte del tiempo a generar la salida, donde reutilizar prefijos no ofrece un atajo directo.

No conserves un historial excesivo solo para proteger una métrica de caché. Compáctalo o reinícialo cuando el material anterior deje de ser útil, aceptando que cambiar el prefijo puede exigir procesarlo de nuevo. La decisión debe responder a la calidad de la tarea y al trabajo total. La guía de ingeniería de contexto del sitio explica cómo decidir qué debe formar parte del contexto de trabajo.

Si desarrollas con API de pago y tus solicitudes comparten a menudo una cantidad considerable de contenido, optimiza ya la estructura del prompt. Si tu carga de trabajo apenas repite prefijos, puedes posponer una gestión de caché compleja. Si operas infraestructura propia, investiga la presión sobre la asignación y las interrupciones antes de asumir que el modelo necesita más cómputo. Las solicitudes breves, aisladas y sin relación entre sí ofrecen poco trabajo reutilizable entre llamadas.

Preguntas frecuentes sobre la KV cache en los LLM

¿ChatGPT utiliza KV cache?

OpenAI documenta la caché de prompts basada en KV para sus API. Eso explica cómo funciona esta característica de su API pública, no todos los detalles de la infraestructura interna que sirve ChatGPT. Al desarrollar, toma como referencia las condiciones de caché publicadas para el modelo de API elegido y sus campos de uso. Documentación de OpenAI.

¿Conviene hacer offloading de la KV cache a la memoria de la GPU?

En la inferencia con GPU, el estado de atención activo se utiliza en la GPU. Con la función de offloading de vLLM, los bloques reutilizables se trasladan a la memoria del sistema anfitrión o a otros niveles compatibles y regresan cuando se necesitan. Considera esta opción cuando conservar más prefijos compense el trabajo de transferencia. Offloading de vLLM.

¿Qué pasa cuando se llena la KV cache?

vLLM puede desalojar bloques en caché que no se estén utilizando; ante la presión de solicitudes activas, puede interrumpir el trabajo y repetir los cálculos después. Esto afecta a la latencia. Es un problema distinto de superar el límite de la ventana de contexto de un modelo. Gestión de caché, interrupción de solicitudes.

¿Cómo se puede reducir la KV cache?

Reduce el contexto retenido o las secuencias concurrentes, reutiliza prefijos compartidos que cumplan los requisitos o evalúa un almacenamiento de caché de menor precisión. El offloading cambia dónde reside el estado, sin reducir necesariamente su tamaño total. Juzga el resultado por la calidad de la tarea y la latencia observada, además de la memoria. Estrategias de caché.

Tres hábitos para mantener los aciertos de caché de un agente

Mantén estable el comienzo y, mientras la tarea siga activa, añade los cambios al final. La reutilización de prefijos exactos favorece las solicitudes predecibles, siempre dentro de las reglas de longitud mínima, retención y disponibilidad del proveedor.

1. 1

   Coloca primero el prompt de sistema estable

   Sitúa las instrucciones duraderas, las definiciones de herramientas y el material de referencia reutilizable antes de los datos variables de la tarea, respetando la estructura de mensajes que exige la API. Mantén estables la redacción, el orden de las herramientas y la serialización. La jerarquía de Anthropic es herramientas, sistema y, después, mensajes; cambiar el conjunto de herramientas puede invalidar la reutilización del contenido posterior. Estructura de caché de Anthropic.

2. 2

   Amplía el historial sin reescribirlo

   Conserva los mensajes anteriores y añade al final el nuevo turno del usuario, la llamada del asistente a una herramienta o el resultado de esa herramienta. Evita reconstruir los turnos previos con resúmenes o formatos que cambien en cada llamada. Cuando sea necesario compactar, hazlo en un punto elegido deliberadamente y establece después un nuevo prefijo estable. Esto responde a la dependencia entre cada bloque y los tokens que lo preceden. Identidad de los prefijos en vLLM.

3. 3

   Deja las marcas de tiempo fuera del comienzo

   Coloca la hora actual, el identificador de la solicitud y otros metadatos variables después del material reutilizable. Una marca de tiempo al principio puede invalidar la reutilización del contexto que viene detrás. Si utilizas puntos de corte explícitos, marca el final del prefijo estable antes del sufijo variable. Indicaciones de Anthropic sobre los puntos de corte.

En tu próxima jornada de trabajo, revisa una conversación representativa de un agente tal como se envía en las solicitudes. Compara el prefijo exacto entre llamadas sucesivas y después examina las escrituras y lecturas de caché que informa el proveedor junto con la entrada total, la salida y la latencia. Corrige un prefijo inestable antes de cambiar de proveedor. Si los aciertos ya son buenos y el agente sigue lento, investiga a continuación el contexto retenido, la longitud de la salida y la competencia por los recursos del servidor.

Suscríbete al boletín para recibir explicaciones prácticas sobre los sistemas que hay detrás de los agentes de IA.