La descarga de trabajo a la CPU permite mantener en funcionamiento un modelo demasiado grande almacenando parte de sus pesos en la RAM del sistema, en lugar de exigir que todo el modelo permanezca en la memoria del acelerador.
En un servidor de IA doméstico, esto puede convertir un modelo que no se carga en una GPU en un servicio local utilizable. La contrapartida es directa: disminuye la presión sobre la VRAM, pero la memoria de la CPU, el tráfico PCIe o de interconexión y, en ocasiones, la ejecución en la CPU pasan a formar parte de la ruta de inferencia. La descarga de trabajo es, ante todo, una técnica de capacidad y solo se convierte en una técnica de rendimiento cuando la jerarquía de memoria es lo bastante rápida.
Un modelo demasiado grande falla cuando el dispositivo rápido no puede contener el estado que necesita
Un modelo local necesita espacio para los pesos, además de la caché KV, las activaciones, los búferes temporales y las reservas del entorno de ejecución. Si el acelerador no puede contener el estado residente necesario, la carga puede fallar antes de que comience una inferencia útil.
Hugging Face Accelerate considera la inferencia de modelos grandes un problema de distribución de los pesos del modelo entre los niveles de memoria disponibles. La descarga de trabajo a la CPU añade la RAM del sistema como un nivel de almacenamiento más lento para el estado del modelo.
El modelo se puede ejecutar porque una parte menor debe permanecer en la VRAM al mismo tiempo, no porque el acelerador haya obtenido memoria física adicional.
Los pesos descargados permanecen en la RAM del sistema hasta que se necesita su capa
Un entorno de ejecución puede mantener determinados tensores de parámetros en la CPU mientras la capa o el grupo de capas actual está activo en la GPU. A medida que avanza la ejecución, los pesos necesarios se transfieren al acelerador y los antiguos pueden devolverse o eliminarse de la memoria del dispositivo.
DeepSpeed ZeRO-Inference puede mantener los pesos del modelo en la memoria de la CPU o NVMe y transmitirlos capa por capa a la GPU. Esto reduce la ocupación máxima del acelerador, pero hace que la transferencia de pesos forme parte de la ejecución.
La colocación de las capas también puede ser estática: algunas permanecen en la CPU y se ejecutan allí, mientras que otras se mantienen en la GPU. Ambas estrategias intercambian presión sobre la memoria del dispositivo por rutas de memoria y transferencia más lentas.
La ruta PCIe o de memoria unificada pasa a formar parte de cada token
Si los pesos deben atravesar PCIe durante la ejecución directa, la latencia y el ancho de banda de la transferencia se sitúan directamente en la ruta crítica de la inferencia. Un modelo que cabe por completo en la VRAM puede reutilizar sus pesos residentes a la velocidad de la memoria del dispositivo; un modelo descargado puede tener que recuperar grandes tensores repetidamente.
PyTorch documenta la memoria de host fijada y el comportamiento de las transferencias de CPU a GPU, mostrando por qué el movimiento entre host y dispositivo es un ámbito de rendimiento independiente de las operaciones aritméticas de la GPU.
Por eso la descarga de trabajo a la CPU puede convertir un error de falta de memoria en un modelo funcional, pero más lento. Primero se resuelve la capacidad; el rendimiento puede disminuir considerablemente.
Más RAM del sistema amplía la capacidad, pero no garantiza velocidad
Se necesita suficiente RAM para contener la parte descargada, además del sistema operativo, la caché de páginas, los contenedores, las bases de datos y otros servicios del servidor doméstico. Cuando el modelo empieza a utilizar la memoria de intercambio, una configuración lenta puede volverse poco práctica.
Linux documenta la recuperación de memoria y la memoria de intercambio como parte de la jerarquía de memoria del sistema. Un modelo descargado compite con todos los demás procesos por ese mismo presupuesto de RAM.
Un servidor doméstico que también ejecuta un NAS, un indexador de fotos y una base de datos multimedia debería dejar un margen real, en lugar de dimensionar la RAM basándose únicamente en el archivo del modelo.
La cuantización y la descarga de trabajo resuelven partes distintas del problema de ajuste
La cuantización reduce la cantidad de bytes utilizados por los pesos, lo que puede disminuir tanto la ocupación en la GPU como en la CPU y reducir el volumen de transferencia. La descarga cambia el lugar donde viven esos bytes durante la ejecución.
NVIDIA NeMo documenta la cuantización FP8, INT8 e INT4 posterior al entrenamiento para reducir la memoria del modelo. Un modelo cuantizado puede caber por completo en la GPU y evitar la descarga; uno más grande puede seguir necesitando ambas técnicas.
La secuencia correcta consiste en decidir primero la precisión y la calidad del modelo aceptables y, después, elegir su colocación. Descargar una representación innecesariamente grande puede desperdiciar ancho de banda.
Usa la descarga de trabajo a la CPU cuando sea más importante ejecutar el modelo que obtener el máximo rendimiento
El caso de uso más sólido es un modelo local ocasional que supera la VRAM, pero que todavía ofrece una latencia aceptable cuando parte de su estado vive en la RAM. Es menos atractiva para un servicio interactivo multiusuario en el que cada token debe atravesar repetidamente un enlace lento.
La guía de ZimaSpace sobre la memoria y la capacidad del acelerador para un NAS de IA es la base para la planificación: la descarga debe considerarse una alternativa de capacidad dentro de la carga de trabajo completa del servidor doméstico.
Mide el uso de VRAM, el uso de RAM, los bytes transferidos entre el host y el dispositivo, el tiempo hasta el primer token, los tokens de salida por segundo y el efecto sobre otros servicios autoalojados. Una configuración que técnicamente se carga, pero provoca el uso de memoria de intercambio o ralentiza el NAS, no es una solución adecuada.
La explicación de ZimaSpace sobre la residencia y expulsión de modelos aborda la cuestión relacionada: liberar memoria del acelerador aumenta la capacidad para otras tareas, pero puede hacer que la siguiente solicitud vuelva a pagar el coste de carga o transferencia.
Preguntas frecuentes
¿La descarga de trabajo a la CPU combina la RAM y la VRAM en un único grupo de memoria rápida?
No. Permite que el entorno de ejecución coloque el estado del modelo entre ambos niveles, pero la RAM de la CPU y la VRAM de la GPU tienen diferentes anchos de banda y latencias. Las transferencias entre ellas pueden convertirse en el principal cuello de botella de la inferencia.
¿Añadir más RAM hará que un modelo descargado sea más rápido?
Solo cuando el sistema actual tiene poca RAM, utiliza paginación o no puede mantener residente el estado descargado previsto. La RAM adicional que no se utiliza no elimina los costes de PCIe ni de ejecución en la CPU.
¿La descarga en SSD es lo mismo que la descarga en la CPU?
No. La descarga en disco añade un nivel de almacenamiento aún más lento cuando la RAM es insuficiente. Puede ampliar aún más la capacidad, pero las páginas del modelo deben atravesar el almacenamiento y, normalmente, la memoria del sistema antes de ejecutarse en el acelerador.
Centro de Tecnología e IA
Más para leer

¿Puede una puerta de enlace de IA local imponer un límite estricto de contexto antes de asignar la GPU?
Una explicación basada primero en el mecanismo del bloqueo de contexto estricto, sus compensaciones en recursos compartidos, tres preguntas frecuentes sobre la distribución de...

¿Puede un servidor de IA doméstico asignar en memoria los pesos de un modelo desde un NAS remoto a través de 2.5GbE?
Una explicación basada primero en el mecanismo de la asignación de memoria del modelo NAS remoto, sus compensaciones en recursos compartidos, tres preguntas frecuentes...

¿Pueden varios contenedores compartir una GPU integrada sin filtrar cargas de trabajo?
Una explicación centrada en los mecanismos del aislamiento de contenedores con iGPU compartida, sus compensaciones en recursos compartidos, tres preguntas frecuentes sobre la distribución...

