En las implementaciones de inferencia de producción, la demanda fluctúa con el tiempo, lo que requiere que las réplicas de inferencia escalen de manera elástica. El inicio en frío de cargas de trabajo de inferencia en Kubernetes puede tardar varios minutos. Durante ese tiempo, las GPU están asignadas pero inactivas, no generan tokens ni atienden solicitudes.
'Arranque en frío' significa la secuencia completa que un servidor modelo debe completar antes de atender cualquier solicitud: extraer la imagen del contenedor, cargar los pesos del modelo en la memoria de la GPU, calentar los núcleos CUDA, compilar o capturar gráficos CUDA y registrarse en la capa de descubrimiento de servicios. Este retraso aumenta el riesgo de infracciones del SLA durante los picos de tráfico, ya que el sistema no puede escalar lo suficientemente rápido para absorber aumentos repentinos de la demanda.
La latencia de arranque en frío para una carga de trabajo vLLM (v0.20.0) de una sola GPU se divide en tres segmentos: extracción de contenedor/imagen, inicialización del motor (carga de peso, calentamiento del kernel, compilación de gráficos) e inicio del tiempo de ejecución distribuido.
Para abordar esto, el equipo de investigación de IA de NVIDIA presentó NVIDIA Dynamo Snapshot: un enfoque de punto de control/restauración para cargas de trabajo de inferencia de IA en Kubernetes.
¿Qué es CRIU y cuda-checkpoint?
El estado controlable de un trabajador de inferencia en ejecución tiene dos componentes. El estado del dispositivo (del lado de la GPU) incluye contextos CUDA, transmisiones, memoria del dispositivo y asignaciones de direcciones virtuales; esto no es visible para el host. Para serializarlo, cuda-checkpoint utiliza la capacidad de puntos de control del controlador CUDA para volcar el estado del dispositivo a la memoria de la CPU del proceso que posee cada contexto CUDA. El estado del host (del lado de la CPU) incluye la memoria de la CPU, subprocesos, descriptores de archivos y espacios de nombres. CRIU (Punto de control/Restauración en el espacio de usuario) recorre la contabilidad del kernel de Linux y serializa el estado del árbol de procesos en el disco.
Al realizar puntos de control, las dos herramientas se ejecutan en orden: cuda-checkpoint primero vuelca todo el estado del dispositivo en la memoria de la CPU, luego CRIU vuelca todo el estado del árbol de procesos del lado del host en una carpeta almacenada. Al restaurar en el mismo nodo o en uno diferente: CRIU restaura primero el árbol de procesos desde el almacenamiento distribuido, como NFS o SMB, luego cuda-checkpoint restaura el estado de la GPU desde lo que ahora está en la memoria de la CPU en las nuevas GPU.
CRIU es fundamentalmente un mecanismo de congelación y descongelación. Cuando se restaura un proceso, la ejecución se reanuda en la instrucción exacta donde se marcó el punto de control, sin saber por completo que se produjo el punto de control o la restauración. Debido a esto, cualquier coordinación requerida antes de establecer puntos de control, como inmovilizar la carga de trabajo, o después de la restauración, como restablecer el estado externo, debe manejarse externamente a través de un orquestador o ganchos específicos de la carga de trabajo.
Cómo funciona Dynamo Snapshot en Kubernetes
En Kubernetes, las cargas de trabajo se ejecutan dentro de contenedores dentro de pods. Debido a que los puntos de control CRIU contienen referencias a la capa del sistema de archivos grabable del contenedor, los puntos de control se realizan a nivel del contenedor para que el estado del árbol de procesos y el sistema de archivos viajen juntos.
NVIDIA proporciona un DaemonSet privilegiado, un agente de instantáneas, que se puede instalar a través de un gráfico Helm. Un agente se ejecuta en cada nodo y maneja el punto de control y la restauración de contenedores administrados por runc sin necesidad de modificaciones en el propio runc. En el punto de control, el agente espera la prueba de preparación de la carga de trabajo, invoca cuda-checkpoint y CRIU desde el lado del host y escribe el artefacto en el almacenamiento compartido. Es posible que la carga de trabajo haya creado o eliminado archivos locales en el contenedor (el sistema de archivos superpuesto), que el agente también verifica después de la etapa CRIU.
Durante la restauración, el agente inicia un pod de marcador de posición liviano, restaura el sistema de archivos superpuesto y restaura el punto de control CRIU/CUDA en sus espacios de nombres. Cada agente opera de forma independiente en su nodo local, lo que permite que los puntos de control y las restauraciones se paralelicen de forma natural en todo el clúster.
Se eligió este enfoque de DaemonSet en lugar del soporte nativo de puntos de control/restauración de Kubernetes en runc por tres razones: es completamente portátil sin depender de las puertas de funciones del proveedor de la nube, brinda un control más estricto sobre CRIU para el ajuste del rendimiento y permite que los artefactos de los puntos de control vivan en backends de almacenamiento flexibles en lugar de estar incrustados en imágenes OCI.
Inmovilizar/reanudar ganchos: un trabajador de inferencia de Dynamo se inicializa en dos fases ordenadas. Primero, la inicialización del motor: se inicializan los comunicadores, se cargan los pesos, se calientan los núcleos y se compilan los gráficos CUDA. El trabajador está completamente caliente en este punto, pero aún no se lo puede encontrar fuera de su módulo. En segundo lugar, inicio en tiempo de ejecución distribuido: el trabajador se conecta al plano de control de Dynamo y se registra en el backend de descubrimiento. Las conexiones TCP abiertas al plano de control existen a partir de este punto.
Si se tomara el punto de control después del inicio del tiempo de ejecución distribuido, habría conexiones TCP activas que CRIU no podría capturar. La solución son los ganchos de suspensión/reanudación: el trabajador escribe un archivo de señal "listo para el punto de control" después de la inicialización del motor pero antes del inicio del tiempo de ejecución distribuido. Luego, el trabajador ingresa a un ciclo de sondeo esperando un archivo de señal de "restauración completa" mientras el agente de instantáneas lo controla externamente. Debido a que CRIU restaura la ejecución en la instrucción exacta donde ocurrió el punto de control, el trabajador continúa directamente dentro del ciclo de sondeo, detecta el archivo de señal y continúa con la inicialización del tiempo de ejecución distribuido sin requerir sincronización adicional.
El patrón de inactividad/reanudación también es importante para los puntos de control de múltiples GPU y múltiples nodos (planeados para una versión futura): las conexiones TCP salientes utilizadas para RPC no se pueden controlar en un estado establecido porque la IP del pod cambia entre el punto de control y la restauración, y los registros de RDMA y el estado de la NIC deben recrearse después de la restauración.
Optimización 1: Desasignación y liberación de caché KV
Después de medir el uso máximo de memoria de la GPU mientras se asignan pesos, gráficos CUDA y otros búferes, los motores de inferencia asignan la memoria restante de la GPU como un búfer de caché KV grande. Dado que el punto de control se toma antes de que la réplica haya atendido cualquier solicitud, no es necesario controlar este búfer de caché KV en absoluto. Sin embargo, su dirección virtual debe permanecer estable porque está integrada en el gráfico CUDA.
La solución es asignar la caché KV a través de la API de administración de memoria virtual CUDA (cuMemCreate y cuMemMap), luego liberar la asignación física subyacente con cuMemUnmap y cuMemRelease, pero no con cuMemAddressFree. Esto mantiene intacto el rango de direcciones virtuales mientras libera la memoria física. Esta funcionalidad está disponible de forma nativa en vLLM mediante sleep() y wake_up() y en SGLang mediante torch_memory_saver.
Para Qwen3-0.6B en un B200, esto reduce el tamaño total del artefacto de ~190 GiB a ~6 GiB. Las ventajas son más pronunciadas para tamaños de caché KV grandes, es decir, pesos de modelo más pequeños en relación con el tamaño de GPU.
Optimización 2: acelerar la restauración de la memoria CRIU
Incluso después de que el artefacto sea más pequeño, el tiempo de restauración de CRIU ascendente sigue siendo un cuello de botella. Para los modelos más grandes, el tiempo de restauración en realidad excede el tiempo de arranque en frío, lo que anula el beneficio de los puntos de control.
Nota: Las optimizaciones CRIU que se describen a continuación aún no se incluyen como parte de Dynamo Snapshot. Es posible que estén disponibles una vez que se fusionen con CRIU ascendente.
2.1 — Restauración paralela de memfd: la ruta sleep()/wake_up() de vLLM y torch_memory_saver de SGLang mueven las asignaciones de GPU con etiquetas de peso a búferes de sombra de CPU anclados. CUDA respalda estas asignaciones con memoria anónima compartida, fijada a través del controlador NVIDIA. Dentro del kernel de Linux, aparecen como memfds: archivos anónimos respaldados por RAM asignados con MAP_SHARED. Para gpt-oss-120b, estos buffers consumieron más de 120 GiB, divididos en muchos buffers independientes de 2 GiB o menos. La CRIU ascendente restaura esos buffers en serie. La CRIU modificada enumera todos los objetos únicos respaldados por shmem y luego utiliza un grupo de subprocesos para restaurarlos en paralelo, lo que permite que la restauración utilice el ancho de banda de almacenamiento disponible y el paralelismo de la CPU.
2.2 — AIO nativo de Linux para memoria anónima: en CRIU ascendente, la ruta de restauración de memoria es un bucle preadv sincrónico con exactamente una lectura en curso en cualquier momento, dejando el dispositivo de almacenamiento inactivo entre solicitudes. El reemplazo utiliza AIO nativo de Linux: CRIU envía un lote de iocbs a través de io_submit y mantiene una ventana deslizante de hasta 128 lecturas en funcionamiento simultáneamente. A medida que llegan las finalizaciones a través de io_getevents, los nuevos envíos llenan la ventana.
Cuando el backend de almacenamiento lo admite, las lecturas de memoria tanto anónimas como compartidas utilizan O_DIRECT, lo que evita una presión innecesaria en la caché de páginas durante el flujo de restauración de una sola pasada. AIO nativo de Linux solo es verdaderamente asíncrono en archivos abiertos con O_DIRECT. En los sistemas de archivos donde O_DIRECT no está disponible, como algunas implementaciones de NFS, la restauración recurre a E/S almacenadas en búfer con lectura anticipada secuencial, y las ganancias de AIO se reducen significativamente.
Resultados combinados en tres modelos (tamaños de puntos de control después de desasignar la caché KV):
*SOL (velocidad de la luz) es la velocidad de restauración máxima teórica dado el ancho de banda de almacenamiento disponible: el piso por debajo del cual no puede llegar el tiempo de restauración.
En este punto, el tiempo de restauración de CRIU está cerca de SOL, pero la restauración de un extremo a otro todavía está dominada por mover secuencialmente pesos de modelos grandes desde el almacenamiento a través de la memoria del host a la GPU. Este es un cuello de botella en serie: cuda-checkpoint no puede restaurar la memoria de la GPU hasta que CRIU materialice los pesos en la memoria del host.
Optimización 3: Servicio de memoria GPU (GMS)
Para eliminar el cuello de botella de la transferencia de peso en serie, el equipo de investigación de NVIDIA desarrolló el Servicio de memoria GPU (GMS). GMS utiliza la API CUDA Virtual Memory Management (VMM) para desacoplar pesos de modelo grandes de la vida útil del proceso del trabajador de inferencia, descargando la mayor parte de la memoria del proceso en un artefacto GMS separado. Al eliminar los pesos del punto de control CRIU central, GMS permite que la restauración del estado del proceso y la restauración del peso se ejecuten simultáneamente utilizando diferentes canales de ancho de banda de memoria. La restauración de peso puede utilizar las rutas más rápidas disponibles, como GPUDirect Storage (GDS) o GPU RDMA/NVLink.
Tamaños de artefactos de puntos de control con GMS:
En un backend de restauración de peso de prueba de concepto que divide los pesos en 8 SSD NVMe locales, la restauración del peso se completa en paralelo con la restauración del proceso CRIU, lo que lleva el tiempo total de inicio de extremo a extremo para gpt-oss-120b a menos de 5 segundos, una reducción de 21 veces. Los tiempos de restauración se miden a partir de una marca de tiempo de activación de restauración común, excluyendo el tiempo de inicio del contenedor.
Implementación: recursos de Kubernetes
El flujo de trabajo de implementación utiliza tres recursos de Kubernetes. El agente de instantáneas DaemonSet se instala mediante el gráfico Helm. El recurso personalizado de DynamoCheckpoint (nombre corto: dckpt) define qué configuración del modelo verificar. El CR de DynamoGraphDeployment hace referencia al punto de control para la restauración.
Requisitos previos de la documentación: nodos GPU x86_64 (amd64); Controlador NVIDIA 580.xx o posterior en nodos GPU (590.xx o posterior para instantáneas de múltiples GPU); Almacenamiento ReadWriteMany para restauración entre nodos; El soporte de backend actual es solo vLLM, en versión preliminar limitada.
La identidad de DynamoCheckpoint es un hash SHA256 de 16 caracteres de campos que afectan el estado del tiempo de ejecución: model, backendFramework, dynamoVersion, tensorParallelSize, pipelineParallelSize, dtype, maxModelLen y extraParameters. Los campos que no afectan el hash incluyen el recuento de réplicas, la ubicación de los nodos, los límites de recursos y la configuración de observabilidad.
Existen dos modos de implementación. El modo checkpointRef explícito hace referencia a un DynamoCheckpoint listo por su nombre. El modo automático hace que el operador calcule el hash de identidad, busque un DynamoCheckpoint coincidente y cree uno solo cuando no existe ninguna coincidencia: el primer trabajador arranca en frío y el punto de control se crea en segundo plano para eventos de escala posteriores.
Limitaciones actuales: checkpoint/restore admite trabajadores vLLM solo en vista previa limitada; no se apoya a los trabajadores especializados (multimodales, de integración, de difusión); las configuraciones de tensor paralelo de múltiples GPU tienen una validación limitada; La restauración de GMS aún no está disponible; el agente de instantáneas debe ejecutarse con privilegios; y la restauración es sensible al estado activo del socket TCP.
Conclusiones clave
Dynamo Snapshot utiliza CRIU y cuda-checkpoint para congelar y restaurar trabajadores de inferencia de GPU única en Kubernetes, evitando la latencia total del arranque en frío. La desasignación de caché de KV a través de cuMemUnmap y cuMemRelease reduce el tamaño de los artefactos del punto de control de ~190 GiB a ~6 GiB para Qwen3-0.6B en un B200. La AIO nativa de Linux y la restauración memfd paralela reducen el tiempo de restauración de CRIU hasta 7,9 veces con respecto a CRIU ascendente; Estas optimizaciones están pendientes de la fusión de CRIU ascendente. El servicio de memoria GPU (GMS) desacopla los pesos del modelo del artefacto CRIU, lo que permite procesos simultáneos y restauración de peso a través de canales como GPUDirect Storage. En una prueba de concepto que utiliza 8 SSD NVMe locales seccionados, el tiempo de inicio de gpt-oss-120b se reduce 21 veces a menos de 5 segundos.
Explicador visual de Marktechpost
Consulta los detalles técnicos. Además, no dude en seguirnos en Twitter y no olvide unirse a nuestro SubReddit de más de 150.000 ML y suscribirse a nuestro boletín. ¡Esperar! estas en telegrama? Ahora también puedes unirte a nosotros en Telegram.
¿Necesita asociarse con nosotros para promocionar su repositorio de GitHub O su página principal de Hugging O su lanzamiento de producto O seminario web, etc.? Conéctate con nosotros
