Presentan PyTorch Monarch

• PyTorch Monarch es un nuevo framework diseñado para habilitar el entrenamiento e inferencia distribuidos eficientes de modelos de gran escala
• Amplía la estructura modular de PyTorch existente y ofrece funciones para particionar y administrar automáticamente redes neuronales enormes entre múltiples dispositivos y nodos
• Reduce la carga de configuraciones complejas para los desarrolladores mediante una API que permite controlar de forma unificada la paralelización de modelos, la paralelización por pipeline y la paralelización de datos
• Monarch muestra una alta eficiencia especialmente en cargas de trabajo intensivas en memoria, como los modelos de lenguaje de gran escala (LLM) y los sistemas de recomendación
• Es parte del esfuerzo dentro del ecosistema de PyTorch por lograr al mismo tiempo escalabilidad y optimización del rendimiento, y se perfila como un componente clave de la infraestructura de entrenamiento distribuido de próxima generación

---

Resumen de PyTorch Monarch

• PyTorch Monarch se presenta como un nuevo componente de PyTorch para simplificar el entrenamiento distribuido y la inferencia de modelos de gran escala
  • Mantiene la flexibilidad de PyTorch existente, mientras está diseñado para ubicar de forma eficiente modelos con miles de millones de parámetros en múltiples GPU y nodos
  • Proporciona funciones automatizadas de particionado y optimización de comunicación sin necesidad de configurar manualmente estrategias de paralelización complejas
• El objetivo central de Monarch es elevar el nivel de abstracción de la paralelización de modelos para que los desarrolladores puedan concentrarse en el diseño de la arquitectura del modelo
  • Permite controlar diversas técnicas de paralelización, como paralelización de datos, paralelización por pipeline y paralelización de tensores, desde una sola interfaz unificada
  • Con ello, reduce de manera significativa la complejidad del código y la sobrecarga de comunicación frente a frameworks de entrenamiento distribuido existentes

Funciones principales y características técnicas

• Monarch ubica cada capa del modelo en el dispositivo óptimo mediante un algoritmo de particionado automático
  • Determina dinámicamente la estrategia de particionado considerando la capacidad de memoria de la GPU, el ancho de banda de comunicación y la carga de cómputo
  • Esta automatización muestra una alta eficiencia especialmente en LLM, modelos basados en Transformer y sistemas de recomendación a gran escala
• Ofrece una API de paralelización unificada que permite a los desarrolladores experimentar con distintas estrategias de paralelización desde una sola base de código
  • Por ejemplo, es posible ejecutar el mismo modelo con una combinación de paralelización de datos y paralelización por pipeline, o cambiarlo a paralelización de tensores
  • Esta flexibilidad facilita la exploración de optimizaciones según el tamaño del modelo y la configuración de hardware
• Monarch es compatible con las funciones existentes de PyTorch DistributedDataParallel(DDP) y Fully Sharded Data Parallel(FSDP)
  • Es posible migrar a Monarch sin modificar en gran medida la base de código existente
  • También se integra con TorchScript y TorchDynamo de PyTorch para brindar optimización de compilación y ejecución

Rendimiento y casos de uso

• Según los benchmarks iniciales, Monarch logró una mejora de 20 a 30% en la eficiencia de comunicación y una reducción de 15% en el uso de memoria frente al entrenamiento distribuido convencional de PyTorch
  • En particular, se mejoraron notablemente la velocidad de entrenamiento y la utilización de GPU en modelos con miles de millones de parámetros
  • Esto se validó experimentalmente en modelos de lenguaje de gran escala (por ejemplo, la familia GPT) y en sistemas de recomendación
• Monarch funciona tanto en entornos cloud como on-premise y es compatible con infraestructuras cloud principales como AWS, Azure y GCP
  • También admite integración con frameworks de nivel superior como PyTorch Lightning y Hugging Face Transformers

Significado dentro del ecosistema de PyTorch

• Monarch es visto como una expansión clave de la infraestructura de PyTorch para responder a la era de los modelos de IA de gran escala
  • Proporciona la base para hacer posible el entrenamiento de modelos gigantes utilizando miles de GPU, dejando atrás el paradigma centrado en una sola GPU
  • Funciona como una solución estandarizada de entrenamiento distribuido que permite a investigadores y empresas asegurar simultáneamente escalabilidad y eficiencia
• El equipo de PyTorch planea publicar Monarch como open source y seguir desarrollándolo de forma continua incorporando feedback de la comunidad
  • En el futuro se prevé agregar funciones de optimización automática, scheduling dinámico y paralelización híbrida
  • Como framework distribuido de próxima generación de PyTorch, se espera que contribuya a la democratización de la infraestructura de IA y a mejorar su accesibilidad

[GN⁺]

Comentarios de Hacker News

• Parece que este proyecto apunta a una capa distinta de Tinker
  Si ves el artículo de presentación de Tinker, Tinker es un servicio administrado de fine-tuning, mientras que Monarch está estructurado para ofrecer primitivas de infraestructura
  Así que me pregunto si se podría construir un servicio como Tinker sobre Monarch

  • Por ahora algo como TorchForge ya está funcionando encima de eso

• Parece que empezó la oxidación de PyTorch
  Monarch está dividido entre un frontend basado en Python y un backend implementado en Rust
  En general, parece un proyecto bastante interesante

  • Según varias fuentes, Monarch es un framework experimental de PyTorch, no un reemplazo
    Supongo que aún se podrá seguir disfrutando de grafos cíclicos basados en std::shared_ptr y fugas de memoria
    Es una lástima que no lo hayan reescrito por completo en un lenguaje funcional
  • Esto no parece una versión oxidada de un proyecto existente, sino un proyecto completamente nuevo

• Yo mismo he creado una extensión de PyTorch — mycelya-torch
  Mi versión todavía no soporta comunicación entre nodos, pero me pareció interesante la forma en que Monarch logra el rendimiento
  Monarch probablemente usa cloudpickle para compartir el código con todos los nodos, lo que solo implica un costo de configuración inicial y resulta eficiente
  También me impresionó la estructura de hacer fan-out de mensajes desde un solo controlador
  Aun así, me da curiosidad si soporta kernels personalizados o qué tan fino es el control de la comunicación entre actores
  En general, me gusta más este enfoque que uno con múltiples controladores

  • Para usar kernels personalizados, quizá haya que modificar un poco el código de inicialización del worker remoto
    Pero sí se pueden integrar (bake-in) directamente los kernels o el código de sistema necesarios

• Esto se ve estructuralmente parecido a Ray

  • El ejemplo de código es casi idéntico al de Ray
    El Actor de Monarch y la clase @ray.remote de Ray siguen el mismo patrón
  • Me pregunto por qué alguien usaría Monarch en lugar de Ray — quizá por una integración más estrecha con PyTorch o con la abstracción de tensores
  • Dask también hace procesamiento distribuido similar, pero originalmente era para HPC, así que su soporte para GPU es limitado
    Consulta el sitio oficial de Dask
  • Yo pensé lo mismo. Sobre todo al ver el reciente anuncio de colaboración entre PyTorch y Ray, me dio más esa impresión
    Blog relacionado

• Interesante, esencialmente me recuerda al concepto de coarray de Fortran (2008)

  • O quizá a Hadoop (2006)
    Solo que me parece mucho mejor porque no hace falta usar directamente MapReduce ni Fortran

• Había una frase que decía “evita el cuello de botella de un solo host y aprovecha toda la malla con un clúster distribuido para el paso de mensajes”,
  si alguien que pueda modificarlo lo ve, ojalá agregue cifras de referencia

• Parece un buen proyecto
  Tengo algunas dudas

  • ¿Esto es similar a openMPI?
  • ¿Cómo se construye la malla? ¿Solo funciona dentro del mismo host?

• Esto podría ser un proyecto importante en el mundo de coarray, pero ya se ven señales de problemas
  El motor de tensores está atado a CUDA y RDMA (ibverbs), y como es código que usa GPUDirect RDMA
  al final parece que la dependencia de CUDA se va a volver aún más fuerte
  Habría sido mejor usar OpenUCX

• Parece menos capaz en funcionalidad que Jax
  Jax optimiza la comunicación entre nodos con un compilador potente

  • Pero Monarch está enfocado en el paradigma de controlador único, mientras que Jax usa una estructura SPMD con múltiples controladores
    Un solo controlador es más fácil de entender, y múltiples controladores son más óptimos para ciertos flujos de datos
    También hay intentos interesantes de mezclar ambos enfoques)