¿Por qué la fragmentación de la memoria de la GPU puede bloquear un modelo de IA local?

Eva Wong es la Redactora técnica y manitas residente en ZimaSpace. Una geek de toda la vida con pasión por los homelabs y el software de código abierto, se especializa en traducir conceptos técnicos complejos en guías accesibles y prácticas. Eva cree que el autoalojamiento debe ser divertido, no intimidante. A través de sus tutoriales, empodera a la comunidad para desmitificar las configuraciones de hardware, desde construir su primer NAS hasta dominar los contenedores Docker.

La fragmentación de la memoria de la GPU puede impedir que un modelo de IA local se ejecute cuando la capacidad libre está dividida en regiones que no pueden satisfacer el siguiente patrón de asignación del entorno de ejecución.

El fallo suele aparecer después de cambiar de modelo, modificar las longitudes de contexto, ejecutar cargas de trabajo de imágenes y lenguaje al mismo tiempo o atender solicitudes cuyos tensores temporales crecen y se reducen. La monitorización puede mostrar VRAM sin usar, pero el asignador sigue sin poder colocar un espacio de trabajo grande, un fragmento del modelo o una ampliación de la caché KV sin liberar o reorganizar los bloques existentes. Las secciones siguientes separan la escasez real de capacidad de la fragmentación del asignador y explican por qué reiniciar el entorno de ejecución puede hacer temporalmente que el mismo modelo vuelva a caber.

La VRAM total libre no es lo mismo que el espacio de asignación utilizable

Un monitor de memoria informa de la capacidad agregada, pero un asignador debe satisfacer las solicitudes mediante los bloques y las asignaciones virtuales que administra. Varias regiones libres pequeñas pueden sumar más que el tamaño solicitado y, aun así, resultar inutilizables bajo una regla de asignación contigua.

Un análisis de operaciones de LLM describe esta discrepancia de memoria libre cuando las cachés KV y los tensores variables dejan huecos más pequeños que la siguiente solicitud. Por tanto, el OOM visible está relacionado tanto con la disposición como con el número total de bytes.

Los controladores y los frameworks también pueden informar de forma diferente sobre la memoria libre del dispositivo, reservada, asignada e inactiva. Compara la vista del asignador del entorno de ejecución con el uso a nivel del dispositivo en lugar de confiar en una sola cifra principal.

Los cambios en el tamaño de los tensores crean huecos con el tiempo

Las cargas de trabajo de IA asignan y liberan repetidamente tensores de distintos tamaños para prompts, lotes, dimensiones de imagen, espacios de trabajo de atención y conversiones temporales. Un asignador con caché conserva los bloques para reutilizarlos porque devolverlos repetidamente al controlador resulta costoso.

La investigación de GMLake muestra que las asignaciones irregulares pueden degradar los pools de memoria basados en división y crear una fragmentación considerable en modelos grandes. Reutilizar tamaños exactos es eficiente; dividir y combinar repetidamente tamaños que no coinciden es más difícil.

Un servidor doméstico que cambia de modelo es especialmente vulnerable porque los entornos de ejecución de lenguaje, difusión, visión y voz solicitan formas de bloque muy diferentes a la misma GPU.

La fragmentación puede acumularse sin que exista una fuga de memoria. Todas las asignaciones pueden terminar liberándose al pool, pero la forma del pool puede seguir sin ajustarse bien a la siguiente carga de trabajo.

El crecimiento de la caché KV hace dinámica la fragmentación durante la inferencia

Los pesos de los LLM son relativamente estables después de la carga, mientras que la caché KV crece con los usuarios activos, la longitud de los prompts y los tokens generados. Además, las solicitudes finalizan en momentos distintos y liberan regiones desiguales.

PagedAttention se diseñó para reducir la fragmentación de la caché KV mediante el almacenamiento del estado de cada solicitud en bloques más pequeños, en lugar de reservar una única región contigua grande para una longitud final de secuencia desconocida.

Este problema es distinto de la fragmentación del asignador general de tensores del framework, pero ambos pueden coexistir. Un administrador de KV paginada no puede compactar automáticamente los espacios de trabajo del modelo ni las asignaciones pertenecientes a otro proceso.

El análisis de ZimaSpace sobre los contextos simultáneos muestra por qué un modelo que cabe para un usuario puede superar un límite de memoria cuando varias conversaciones se amplían al mismo tiempo.

-15% OFF

La memoria reservada puede hacer que el fallo parezca una fuga

Los asignadores de los frameworks suelen conservar los bloques liberados para acelerar las solicitudes posteriores. Las herramientas del dispositivo cuentan esos bloques como utilizados por el proceso, aunque el modelo actual no contenga tensores activos en todos ellos.

Una guía práctica sobre OOM distingue la memoria reservada de los requisitos del modelo activo y de la caché. Una diferencia grande puede indicar bloques reutilizables del asignador, fragmentación o una carga de trabajo cuyo pico fue superior a su estado actual.

Limpiar una caché puede devolver algunos bloques al controlador, pero no puede liberar los pesos activos, el estado KV en uso, el contexto de otro proceso ni un espacio de trabajo necesario para la siguiente operación.

Las formas de asignación estables y la paginación reducen los fallos repetidos

Reproduce el fallo con un solo modelo, un límite de contexto fijo, un tamaño de lote fijo y ningún servicio de IA competidor. Registra la memoria asignada y reservada a nivel de proceso, la memoria libre a nivel del dispositivo, la solicitud más grande y la secuencia de carga de trabajo que precedió al OOM.

vAttention utiliza la asignación mediante memoria virtual para separar el espacio KV virtual contiguo de la asignación física. Los enfoques similares de paginación y asignación segmentada reducen la dependencia de una única región físicamente continua.

En un servidor doméstico, los controles prácticos incluyen dejar margen de VRAM, limitar los cambios de modelo, usar límites estables de contexto y lote, coordinar los servicios mediante un único entorno de ejecución y reiniciar un proceso fragmentado durante el mantenimiento, en lugar de esperar a que falle una solicitud de usuario.

Si un reinicio limpio no hace que el modelo quepa, es probable que el problema principal sea la capacidad real y no la fragmentación acumulada. Reduce el tamaño del modelo, la memoria ocupada por la cuantización, el contexto, el lote o las asignaciones en conflicto.

Centro de Tecnología e IA

Más para leer

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.