ES
El contexto reutilizable de IA puede presionar la memoria de la GPU
Understanding KV Residency in Production-Scale Agentic LLM Workloads · arXiv:2610.22863
En palabras sencillas
Las sesiones de IA suelen hacer varias llamadas al modelo mientras acumulan el contexto de una misma conversación. Guardar los cálculos de ese contexto puede acelerar llamadas posteriores, pero ocupa memoria de la GPU incluso cuando la sesión está inactiva.
Los autores estudiaron cuatro cargas de trabajo de Microsoft M365 y reprodujeron sus registros de llamadas. En una reproducción de Research, eliminar el contexto guardado después de una hora redujo mucho el uso de memoria estimado y solo aumentó ligeramente la proporción de llamadas que debían reconstruir el contexto. El resultado depende de las estimaciones de memoria y las reglas de reproducción del estudio.
La investigación
Cuando una sesión del modelo hace llamadas repetidas, el contexto guardado puede evitar recalcular información, pero mantenerlo en la memoria de la GPU consume capacidad incluso mientras la sesión está inactiva.
¿Cuánta de esa memoria se puede liberar antes de que muchas llamadas al reanudarse tengan que reconstruir su contexto?
Los autores reproducen registros de llamadas de producción para probar cómo afectan al recálculo del contexto la expulsión por inactividad, las copias recuperables de la caché y el estado local a cada despliegue.
Los autores reprodujeron registros de llamadas de producción para probar si se puede liberar el contexto guardado de las sesiones sin obligar a muchas llamadas a reconstruirlo.
Como las configuraciones de los modelos de producción son confidenciales, estimaron la memoria KV a partir de una configuración pública de referencia y compararon reglas de residencia con registros de Research.
En todo el registro de Research que cumple los requisitos, un límite de inactividad de una hora redujo la residencia máxima estimada de toda la flota de 501.8 TB a 140.8 TB, mientras que la proporción de llamadas que requerían reconstrucción subió del 4.07% al 4.53%. Esto respalda la interpretación de que conservar el estado máximo durante largos periodos de inactividad infla la estimación, mientras que el límite probado añade relativamente pocas llamadas con reconstrucción.
Son estimaciones y reproducciones contrafactuales, no mediciones de una política de retención desplegada.
Los registros abarcan cuatro cargas de trabajo de Microsoft M365, y la reproducción no mide cómo afectan las copias de caché de menor precisión a las respuestas, la latencia o los costes de transferencia.
Qué muestran las pruebas
- La memoria de cada sesión, bajo estudio
Este estudio de sistemas en funcionamiento pregunta cómo deberían gestionar los sistemas de servicio el estado guardado en la caché de clave y valor (KV) entre llamadas de una sesión. Las llamadas posteriores pueden reutilizar cálculos de contextos anteriores, pero mantener ese estado en la memoria de la GPU consume capacidad cuando una sesión está inactiva.
Los autores analizan cuatro cargas de trabajo de Microsoft M365 en producción y reproducen sus secuencias de llamadas para examinar la presión sobre la memoria y el estado local a cada despliegue.
- Estimar la escala
Las estimaciones en bytes usan la configuración KV pública de Llama-2-70B porque los modelos de producción son confidenciales. Con ese supuesto, una sesión de Deep Research situada en el percentil 99 tiene un estado KV estimado de 81.6 GiB, más que los 80 GB de memoria de una GPU H100.
En una estimación aparte, conservar el estado máximo de cada sesión de Research que cumple los requisitos durante toda su vida observada produce un límite de 501.8 TB para la flota. Estas cifras describen únicamente una estimación del estado KV, no asignaciones reales de memoria de GPU.
- Probar un límite de inactividad
Después, los autores reproducen todo el registro de Research que cumple los requisitos con un límite de inactividad: al cabo de una hora sin actividad, expulsan el estado KV dimensionado según el máximo de la sesión. La residencia máxima estimada de toda la flota baja de 501.8 TB a 140.8 TB, mientras que la proporción de llamadas que requieren reconstrucción sube del 4.07% al 4.53%.
Los porcentajes de llamadas con reconstrucción cuentan todas las llamadas de ese registro. Esta comparación indica que los largos intervalos de inactividad elevan la estimación que supone conservar todas las sesiones activas, mientras que el aumento de llamadas con reconstrucción es moderado con el límite probado.
- Las copias recuperables reducen las reconstrucciones
Otra reproducción prueba políticas de memoria con 176,007 llamadas de 9,486 sesiones durante la hora de mayor actividad de Research, y un presupuesto compartido de 4.7 TB para todas las sesiones. Las llamadas que requieren reconstrucción representan el 62.9% con la expulsión por menos uso reciente y el 31.1% con la política de siguiente uso más lejano.
Conservar el estado desplazado como una copia int4 más pequeña reduce la tasa al 13.6%. Como MRR sigue el orden de descarte de LRU, su mejora frente a LRU aísla el efecto de conservar una copia recuperable más pequeña en vez de destruir el estado.
Su ventaja frente a FNU con este presupuesto se debe a que caben más datos, no a que use información del futuro; con el presupuesto más ajustado probado, FNU tiene una tasa de reconstrucción menor. El resultado se limita a esta reproducción y este presupuesto; no contempla la calidad de las respuestas ni los costes de restaurar las copias.
- La ubicación impone un mínimo aparte
Por último, una reproducción con memoria ilimitada cambia la forma de identificar los objetos de caché. Cuando el estado es local a un despliegue, identificar los objetos por sesión y despliegue eleva del 5.4% al 20.2% de las llamadas el mínimo de reconstrucciones en el primer acceso, durante la misma hora de Research.
Los autores interpretan esto como un problema de ubicación distinto de la presión sobre la memoria: más memoria no elimina las reconstrucciones causadas porque el estado no está disponible en otro despliegue.
Detalles
- Autores del paper original
- Mayank Arya, Agrim Bari, Anjaly Parayil, Yogesh Simmhan, Renee St. Amant
- Enviado a arXiv
- Licencia
- arXiv non-exclusive