La caché KV crece con la longitud del contexto porque el entorno de ejecución almacena las claves y los valores de atención de cada token retenido en varias capas del modelo.
Un prompt breve de IA para el hogar puede dejar suficiente memoria para varios usuarios, mientras que un documento extenso, un historial de chat prolongado o el registro de un agente pueden consumir mucha más memoria de trabajo sin cambiar el archivo del modelo. La caché comienza durante el procesamiento del prompt y sigue creciendo a medida que el modelo genera nuevos tokens. Su tamaño también depende del número de capas, la arquitectura de atención, la precisión numérica y las solicitudes simultáneas. Las secciones siguientes siguen ese crecimiento desde un token hasta el límite de memoria de todo el servidor.
Cada token retenido añade estado de atención
Durante la inferencia de un transformer, cada capa produce tensores de claves y valores a partir de los tokens procesados hasta ese momento. El entorno de ejecución conserva esos tensores para que el token siguiente pueda atender al contexto anterior sin volver a calcular toda la secuencia.
El trabajo de vLLM identifica el estado KV por token como un requisito importante de memoria para ofrecer modelos. Los tokens nuevos añaden entradas a la caché, mientras que las entradas retenidas anteriormente siguen disponibles para los pasos de atención posteriores.
Por tanto, la caché es un estado mutable de la solicitud, no una parte de los pesos estáticos del modelo. Cargar el mismo modelo con una conversación activa más larga crea una huella de memoria mayor.
El crecimiento de la caché es aproximadamente lineal con la longitud de la secuencia retenida
En una arquitectura de modelo y una precisión de caché fijas, duplicar el número de tokens retenidos duplica aproximadamente las entradas KV almacenadas para esa solicitud. Tanto el prompt como la respuesta generada cuentan para la secuencia activa.
H2O describe cómo la caché KV escala con la longitud de la secuencia y el tamaño del lote. La relación sigue siendo aproximadamente lineal porque cada token adicional aporta claves y valores en todas las capas que generan la caché.
Por eso, aumentar la configuración del entorno de ejecución de un contexto pequeño a un máximo mucho mayor puede cambiar el límite práctico de memoria, incluso cuando el modelo utiliza los mismos pesos.
La configuración máxima y el uso real son conceptos distintos. Algunos entornos asignan bloques de caché bajo demanda, mientras que otros reservan una región mayor al principio para garantizar el crecimiento futuro.
La arquitectura del modelo cambia el número de bytes por token
Dos modelos con el mismo número de parámetros pueden requerir distinta cantidad de memoria KV porque pueden utilizar diferentes números de capas, dimensiones de cabeza, cabezas de atención, atención de consultas agrupadas o atención de consultas múltiples.
KIVI estudia la precisión de la caché KV y muestra que almacenar las claves y los valores con menos bits puede reducir considerablemente la memoria máxima. El beneficio se aplica al estado de la solicitud, no a la reducción de los pesos subyacentes del modelo.
Los diseños de consultas agrupadas y consultas múltiples comparten las cabezas de claves y valores entre más cabezas de consulta, lo que puede reducir los bytes de caché por token frente a la atención multi-cabeza completa. El número de capas y el ancho de las cabezas siguen multiplicando el estado retenido.
Por tanto, una estimación útil debe utilizar la arquitectura exacta del modelo y el formato de caché del entorno de ejecución, no solo una regla genérica de bytes por token copiada de otro modelo.
Los tokens generados siguen ampliando la caché después del prellenado
El procesamiento del prompt crea la caché inicial para el contexto de entrada. A continuación, la decodificación autorregresiva añade el estado de cada token de salida aceptado para que los tokens posteriores puedan atender a la conversación completa.
vAttention considera el crecimiento dinámico de la caché un problema de asignación, porque la longitud final de salida se desconoce cuando comienza una solicitud. Reservar demasiado desperdicia memoria, mientras que reservar muy poco puede obligar a realizar una expulsión o tareas de ampliación.
Un prompt que cabe cómodamente puede superar el límite de memoria durante una respuesta larga. Por tanto, los límites de salida protegen la memoria, además de la longitud de la respuesta y el tiempo de generación.
Los usuarios simultáneos multiplican el estado de contexto independiente
Los pesos del modelo pueden compartirse entre solicitudes, pero cada conversación activa normalmente conserva su propio historial de tokens y su propia caché KV. Cinco usuarios con contextos largos no comparten una única caché universal simplemente porque utilicen el mismo modelo.
Las investigaciones recientes sobre la gestión de KV plantean las reservas por solicitud como un equilibrio central entre eficiencia de memoria y riesgo de expulsión. Las longitudes de salida desconocidas hacen que el pico combinado sea más difícil de predecir que con un simple recuento de usuarios.
En ocasiones, los prefijos de prompt compartidos pueden reutilizar el estado de la caché cuando el entorno de ejecución admite coincidencias exactas de prefijos, pero el historial privado del chat y las salidas divergentes siguen creando ramas independientes.
La guía de hardware de ZimaSpace considera el contexto y la concurrencia requisitos de memoria adicionales al archivo del modelo. Por tanto, una prueba con un solo usuario puede subestimar la RAM o VRAM que necesita un asistente doméstico.
La paginación, la cuantización y la expulsión cambian el límite, no la causa
La asignación paginada reduce la fragmentación al dividir el estado de la caché en bloques más pequeños, de modo que el entorno de ejecución no necesita una única reserva contigua sobredimensionada para cada secuencia posible.
PagedAttention proporciona una asignación basada en bloques, mientras que la cuantización de la caché reduce los bytes por valor almacenado y las políticas de expulsión descartan determinadas entradas antiguas. Cada método cambia cuánto contexto cabe, pero el estado de atención retenido sigue creciendo a medida que se acumulan tokens.
La expulsión o las ventanas deslizantes pueden limitar la memoria al eliminar tokens anteriores, pero el modelo ya no puede atender al estado descartado mediante la ruta normal de contexto completo. La compresión y la retención selectiva también pueden introducir compromisos relacionados con la calidad o con la carga de trabajo.
Mide el uso de la caché con el modelo real, el contexto, la precisión de la caché, el tamaño del lote y el número de usuarios. El límite práctico se alcanza cuando no se puede admitir otro token o solicitud sin expulsión, descarga, recálculo o fallo.
Preguntas frecuentes
¿El archivo del modelo aumenta de tamaño cuando aumenta la longitud del contexto?
No. Los pesos del modelo permanecen iguales. La memoria adicional es estado del entorno de ejecución creado para el prompt activo y los tokens generados.
¿Configurar un contexto máximo grande siempre asigna toda la memoria KV de inmediato?
No. El comportamiento de asignación depende del entorno de ejecución. Algunos reservan capacidad desde el principio, mientras que los sistemas paginados asignan bloques a medida que se admiten tokens.
¿La RAM del sistema puede almacenar la caché KV cuando la VRAM está llena?
Algunos entornos de ejecución pueden descargar o mover el estado de la caché, pero las transferencias añaden latencia y dependen de la compatibilidad del software, el ancho de banda y la ruta de atención activa.
Centro de Tecnología e IA
Más para leer

Estado de ejecución frente a estado persistente en Home Assistant: ¿qué debe sobrevivir al reinicio?
Home Assistant no conserva todos los valores en tiempo real; la configuración, los registros, los estados restaurados seleccionados, el historial y los datos de...

¿Cómo autentica Home Assistant las sesiones locales y remotas?
Las sesiones locales y remotas de Home Assistant utilizan el mismo modelo de identidad del servidor; el acceso remoto cambia la ruta y el...

¿Por qué pueden volverse lentas las consultas del historial de Home Assistant a medida que crecen los datos del grabador?
El crecimiento del grabador puede aumentar el costo de las consultas del historial cuando el rango solicitado abarca más filas, aumentan los fallos de...

