ModelExpress: Distribución de modelos a velocidad de luz
- NVIDIA ModelExpress (MX) acelera eficazmente el ciclo de vida de los pesos de los modelos seleccionando la ruta más rápida disponible para cargarlos, priorizando transferencias directas GPU a GPU P2P RDMA a través de NIXL y reduciendo la dependencia del almacenamiento de objetos y la memoria del host.
- MX emplea estrategias avanzadas que incluyen transmisión multihilo, caché distribuida atómica, GPUDirect Storage y selección de ruta en tiempo de ejecución para optimizar los arranques en frío, minimizar el movimiento redundante de datos y automatizar métodos de transferencia óptimos en diversos entornos de clústeres.
- La plataforma permite la transferencia rápida de artefactos de pesos y caché de kernels, soporta flujos de trabajo de refit de RL dirigidos por el receptor, se integra con vLLM, SGLang, Dynamo y llm-d, e incorpora optimizaciones como el registro de arena VMM para reducir significativamente los gastos generales de inicio y registro en despliegues de LLM en producción.
El contenido generado por IA puede resumir información de manera incompleta. Verifique la información importante. Más información
Cada byte movido tiene un costo. A medida que los puntos de control de los modelos crecen a cientos de gigabytes o incluso a un terabyte, ese costo aumenta rápidamente. Para empeorar las cosas, mover estos pesos de modelo a través del clúster es extremadamente común. Por ejemplo, un arranque en frío puede extraer pesos del almacenamiento remoto a la memoria de la GPU; el escalado automático y las actualizaciones continuas deben poblar cada nueva réplica; y el post-entrenamiento de RL mueve continuamente pesos actualizados desde los entrenadores a los trabajadores de despliegue. Estos pueden parecer flujos de trabajo diferentes, pero imponen el mismo impuesto recurrente: tiempo dedicado a mover pesos antes de que pueda comenzar el trabajo útil.
ModelExpress: Acelerando el ciclo de vida de los pesos del modelo
NVIDIA ModelExpress (MX) se basa en una idea simple: antes de cargar un modelo, pregunte primero dónde reside ya una copia compatible de sus pesos. En lugar de tratar cada réplica como un arranque en frío independiente, MX elige la fuente y la ruta de transferencia más rápidas disponibles.
Cuando un par de servicio ya posee pesos compatibles en la GPU, MX los transfiere directamente de GPU a GPU a través de P2P RDMA mediante la biblioteca NVIDIA Inference Xfer Library (NIXL), evitando el acceso redundante al almacenamiento de objetos, disco local y memoria del host. Cuando no hay ningún par disponible, MX arranca desde la ruta compatible más rápida transmitiendo desde un almacén de objetos sin aterrizar en el disco o leyendo archivos locales directamente en la memoria de la GPU.
MX transfiere pesos de DeepSeek-V4 Pro y artefactos de caché JIT Kernel desde una réplica de servicio a una réplica nueva en menos de 10 segundos, reduciendo el tiempo total de inicio a 1 minuto y 44 segundos desde los 8 minutos originales. El resto de este artículo muestra cómo MX selecciona la ruta más rápida disponible hacia la memoria de la GPU, priorizando P2P RDMA desde una réplica de servicio y eliminando descargas y copias redundantes en el proceso. Luego, extiende el mismo enfoque para reutilizar cachés de kernels y distribuir actualizaciones de pesos de RL.
La arquitectura de MX que se observa en la Figura 1 ilustra cómo el sistema gestiona los flujos de datos. Cada trabajador nuevo debe obtener sus pesos desde uno de tres lugares: almacenamiento remoto (ej. HF o S3), almacenamiento local u otro trabajador que ya esté sirviendo el modelo. Para el primer trabajador, aún no hay un par, por lo que debe arrancar desde el almacenamiento. MX puede transmitir los puntos de control desde el almacenamiento de objetos o cargarlos desde un almacenamiento local rápido, eliminando copias evitables a lo largo de cualquier ruta.
¿Cómo acelera cada etapa desde el almacenamiento remoto a la GPU?
Una vez que el primer trabajador está en servicio, la fuente preferida cambia. Sus pesos ya están residentes, procesados y dispuestos en la memoria de la GPU, por lo que cada trabajador compatible posterior debe cargar directamente desde ese par a través de P2P RDMA. MX realiza esta transición automáticamente: arranca una vez desde el almacenamiento, luego escala de GPU a GPU, recurriendo al almacenamiento solo cuando no hay un par compatible disponible.
Iniciando el primer trabajador: Arranque desde el almacenamiento
Del almacenamiento de objetos remoto a la GPU: Evitando el disco local
Cuando el punto de control reside en un bucket en la nube y prefiere no aprovisionar ni gestionar una capa de caché de disco, MX utiliza el Model Streamer para extraer safetensors a través de un búfer de preparación de CPU reutilizable y hacia la GPU. El punto de control nunca llega al disco local, eliminando la descarga intermedia, la recarga y el volumen de almacenamiento.
Model Streamer utiliza un lector de tensores multihilo para obtener rangos de tensores simultáneamente a través de los fragmentos del punto de control. A medida que llegan los tensores, canaliza las lecturas remotas con la colocación en la GPU: los tensores completados se pasan al motor de inferencia mientras los tensores posteriores aún se están obteniendo. Esto mantiene ocupadas las rutas de almacenamiento, red y copia de la GPU mientras se reutiliza una cantidad limitada de memoria del host.
En despliegues de paralelismo de tensores, los rangos participantes dividen las lecturas remotas y comparten los resultados, típicamente sobre NCCL, en lugar de que cada rango descargue el punto de control completo de forma independiente. MX conecta este flujo distribuido directamente al cargador de pesos del motor de inferencia, preparando al primer trabajador para convertirse en la fuente P2P para cada réplica compatible que le siga.
Ingreso al clúster: Descargar una vez, no N veces
Cuando un clúster mantiene una capa de caché de disco compartida (ej. volúmenes persistentes en K8s), MX asegura que la flota la pueble solo una vez. Si 10 réplicas desean obtener simultáneamente el modelo DeepSeek-V4 Pro de 806 GiB, necesitarían extraer aproximadamente 8 TiB de datos idénticos a través de la red mientras compiten por el mismo ancho de banda de ingreso. El servicio Model Cache de MX colapsa esas solicitudes en una descarga coordinada: un reclamo atómico en el Metadata Store selecciona un descargador, mientras que las réplicas restantes rastrean su progreso y reutilizan la copia en caché. El clúster paga el costo de descarga externa una vez, luego cada réplica puede comenzar desde el mismo punto de control en caché.
Almacenamiento local a GPU: Evitando la preparación en memoria del host
Cuando el GPUDirect Storage (GDS) es compatible con el sistema, MX lee archivos de puntos de control directamente desde el almacenamiento local hacia la memoria de la GPU a través del backend GDS multihilo de NIXL. NIXL ejecuta lecturas de tensores por lotes en paralelo directamente en la memoria de la GPU, evitando la memoria del host y la copia de preparación requerida por un cargador convencional. Los usuarios no necesitan habilitar GDS explícitamente: MX detecta la capacidad automáticamente y recurre a otra estrategia de carga cuando no está disponible.
Almacenamiento local a GPU: Canalizando lecturas locales con ModelStreamer
MX también puede cargar puntos de control locales a través de ModelStreamer. Múltiples hilos del sistema operativo leen safetensors simultáneamente en un búfer de CPU configurable mientras los tensores completados se mueven a la GPU y las lecturas posteriores continúan en paralelo. A diferencia de GDS, esta ruta aún se prepara a través de la memoria del host, pero superpone la E/S de disco con la colocación en la GPU, se beneficia de la caché de página del sistema operativo y proporciona una ruta rápida y portátil cuando el acceso directo de almacenamiento a GPU no está disponible.
Iniciando cada trabajador después del primero: Obtención desde un par de servicio
Esta es la característica clave de MX. Una vez que otra réplica ya está sirviendo el mismo modelo, los pesos han completado la mayor parte de su viaje: están residentes en la memoria de la GPU, procesados y dispuestos para el motor de inferencia. MX trata a esa réplica como una fuente de pesos en vivo. Después de confirmar la compatibilidad, transfiere los tensores directamente desde la GPU de origen a la GPU de destino. Una vez cargados sus pesos, la nueva réplica se une al grupo de origen, dando a las réplicas posteriores otro par desde el cual cargar. Con cada transferencia exitosa, ese grupo crece junto con el despliegue, convirtiendo el escalado en una distribución de GPU a GPU en lugar de cargas en frío repetidas.
El plano de control de MX descubre pares compatibles, intercambia metadatos de transferencia y rastrea la preparación de la fuente, pero nunca maneja los bytes de peso en sí mismos. En el plano de datos, MX utiliza NIXL como un motor de transferencia predeterminado cuyos backends conectables permiten un rendimiento máximo a través de una variedad de redes.
Vía NVIDIA Developer.
