À l’ère du big data et de l’intelligence artificielle, la gestion efficace des workflows de machine learning constitue un enjeu crucial pour les chercheurs et les entreprises. Les systèmes d’apprentissage automatique, capables de traiter des volumes de données colossaux et nécessitant des opérations complexes, se heurtent souvent à des défis inédits. L’un des principaux obstacles réside dans la diversité des environnements de calcul et des architectures distribuées, rendant la mise en œuvre de ces workflows non seulement complexe, mais également sujette à des erreurs et à des défaillances matérielles.
Imaginez un orchestre où chaque musicien joue une partition différente, sans chef d’orchestre pour harmoniser l’ensemble. C’est le défi auquel font face les équipes d’ingénieurs et de chercheurs qui tentent de coordonner des processus d’apprentissage sur des centaines, voire des milliers de GPU. La complexité des workflows, associée à la nature dynamique et asynchrone de ces systèmes, génère une cacophonie qui peut freiner l’innovation et ralentir les progrès. Dans d’autres secteurs, comme la production industrielle ou la gestion de projets, des méthodes d’orchestration centralisée ont prouvé leur efficacité en simplifiant les processus et en améliorant la productivité.
Face à cette réalité, un besoin d’une approche plus intégrée et intuitive s’impose. C’est ici qu’intervient le concept de contrôleur unique, promettant de transformer la manière dont sont conçus et exécutés les projets de machine learning. En unifiant la gestion des ressources et en simplifiant la programmation, cette approche permet aux développeurs de se concentrer sur l’innovation plutôt que sur la complexité technique. Cette évolution est pertinente non seulement pour le domaine du machine learning, mais s’inspire également des avancées dans des secteurs variés, tels que la robotique ou les systèmes embarqués, où la coordination centralisée est devenue la norme.
La nécessité d’une telle transformation est d’autant plus pressante aujourd’hui, alors que les demandes en matière d’intelligence artificielle continuent d’exploser. Les entreprises cherchent à exploiter les capacités de l’IA pour améliorer leurs services, optimiser leurs opérations et offrir des expériences client sans précédent. Pour réussir dans ce paysage compétitif, il est essentiel de disposer d’outils facilitant le développement et l’exécution de modèles d’apprentissage automatique à grande échelle. C’est ici que Monarch entre en jeu, offrant une solution qui démocratise l’accès à des capacités de calcul avancées tout en garantissant une simplicité d’utilisation inégalée.
Contexte des Workflows ML
Défis actuels
Dans un contexte où les workflows de machine learning (ML) deviennent de plus en plus complexes, la gestion efficace de ces processus s’avère essentielle. Avec la diversité des étapes de pré-entraînement et de post-entraînement, les défaillances matérielles et l’asynchronisme, il est crucial d’adopter des solutions robustes et simplifiées. C’est dans cette optique que se positionne Monarch, un framework de programmation distribué transformant la façon dont les applications ML sont développées.
Les workflows ML contemporains se distinguent par leur diversité et leur complexité croissante. Les processus de pré-entraînement intègrent souvent des parallélismes avancés et des opérations asynchrones, tout en devant gérer des pannes partielles. De même, les modèles d’apprentissage par renforcement (RL) utilisés durant la phase de post-entraînement nécessitent une grande adaptabilité et des boucles de rétroaction complexes. Traditionnellement, PyTorch reposait sur un modèle multi-contrôleur de type HPC, où plusieurs instances d’un même script étaient exécutées sur différentes machines. Bien que cette approche soit fonctionnelle, elle présente des limites pour la prise de décisions basées sur une vision locale des workflows.
Modèle de Contrôleur Unique
Pour relever ces défis, Monarch propose un modèle de programmation à contrôleur unique. Dans ce cadre, un seul script orchestre l’ensemble des ressources distribuées, créant ainsi une expérience similaire à celle d’un programme local. Cette approche simplifie la programmation distribuée, permettant aux développeurs d’écrire du code se comportant comme un programme Python sur une unique machine tout en s’étendant sur des milliers de GPU. Grâce à cette architecture, il devient possible d’utiliser des constructions Python classiques — telles que les classes, les fonctions, les boucles et les tâches — pour exprimer des algorithmes distribués complexes.
Caractéristiques Principales de Monarch
API Clés: Processus et Acteur Meshes
Monarch introduit une organisation des ressources en meshes, des tableaux multidimensionnels facilitant la distribution des opérations. Un process mesh est constitué d’un ensemble de processus répartis sur plusieurs hôtes, tandis qu’un actor mesh regroupe des acteurs, chacun s’exécutant dans un processus distinct. Inspirés de la programmation de tableaux dans NumPy ou PyTorch, ces meshes permettent un dispatch efficace des opérations à travers de larges systèmes. Au lancement, Monarch prend en charge les process meshes sur des clusters GPU, typiquement un processus par GPU, et permet également le déploiement d’acteurs sur des actor meshes. Pour le développement local, ces mêmes meshes peuvent être utilisés sur un serveur de développement local.
API Avancées: Moteur de Tenseurs et Tampon RDMA
Le moteur de tenseurs de Monarch révolutionne la gestion des tenseurs distribués au sein des process meshes. Il permet d’écrire des programmes PyTorch comme si l’ensemble du cluster de GPU était directement connecté à la machine exécutant le script. De plus, pour le mouvement de données en vrac, Monarch propose une API de tampon RDMA, qui facilite les transferts directs et à haut débit entre les processus sur des cartes réseau compatibles.
Exemples Simples
Monarch se distingue par sa simplicité d’utilisation. Le code de Monarch permet de décrire de manière impérative la création de processus et d’acteurs à l’aide d’une API Python intuitive. Par exemple, il est possible de définir un acteur déployé sur plusieurs GPU et d’invoquer cet acteur pour obtenir des réponses rapides et efficaces.
Découpage des Meshes
Pour exprimer la communication par diffusion, Monarch organise les acteurs en meshes, qui constituent des conteneurs multidimensionnels avec des dimensions nommées. Par exemple, un cluster pourrait avoir des dimensions telles que “hôtes”: 32 et “GPUs”: 8. Les noms de dimensions sont généralement liés à la structure du cluster, facilitant ainsi l’indexation et la gestion des ressources.
Tolérance aux Pannes
Monarch permet aux utilisateurs d’exprimer des programmes distribués capables de gérer des erreurs grâce à des blocs try et except en Python. Des schémas complexes de détection et de récupération des pannes peuvent être élaborés à partir de ces primitives. Par exemple, un cas pratique illustre comment gérer une exception d’exécution simple dans un acteur distant.
Backend de Monarch
Monarch se compose d’un frontend basé sur Python et d’un backend implémenté en Rust. Python, étant le langage de prédilection pour l’apprentissage automatique, permet une intégration fluide avec les bibliothèques existantes, comme PyTorch, tout en étant compatible avec des outils de calcul interactifs tels que les notebooks Jupyter. Le backend en Rust assure des performances optimales, une évolutivité et une robustesse accrues, exploitant pleinement la concurrence sans crainte offerte par Rust.
Framework Hyperactor
À la base de l’architecture de Monarch se trouve un framework d’acteurs appelé Hyperactor. Ce système d’acteurs distribué à faible niveau est axé sur le passage de messages performant et une supervision robuste. Le hyperactor_mesh est construit sur Hyperactor et combine divers composants pour offrir une implémentation d’acteurs “vectorisée” efficace, optimisée pour des opérations sur de vastes meshes d’acteurs. Les principales API Python de Monarch sont principalement des wrappers autour de hyperactor_mesh.
Messaging Scalable
Monarch repose sur un principe de messagerie scalable, avec des API centrales supportant le casting de messages vers de larges meshes d’acteurs. Hyperactor y parvient grâce à deux mécanismes: les arbres multicast et la messagerie multipart. Pour prendre en charge le multicast, Hyperactor établit des arbres multicast afin de distribuer les messages. Lorsqu’un message est diffusé, il est d’abord envoyé à certains nœuds initiaux, qui transmettent ensuite des copies du message à un ensemble d’enfants, jusqu’à ce que le message soit entièrement distribué dans le mesh. Cela permet d’éviter les goulets d’étranglement liés à un seul hôte et d’utiliser efficacement l’ensemble du mesh pour le transfert de messages.
Études de Cas
Monarch, grâce à son API générale et son intégration native avec PyTorch, ouvre la voie à de nouvelles applications d’IA à grande échelle, capables de répondre aux exigences d’orchestration plus complexes.
Cas d’Utilisation 1: Apprentissage par Renforcement
L’apprentissage par renforcement s’est révélé essentiel pour les modèles de première génération. Il permet aux modèles d’effectuer des recherches approfondies, d’accomplir des tâches dans divers environnements et de résoudre des problèmes complexes, allant de la programmation à la résolution de problèmes mathématiques. Pour une exploration plus approfondie, il est recommandé de consulter des articles spécialisés. Dans le cadre de Monarch, chaque composant d’un modèle de raisonnement pourrait être représenté par un mesh distinct — un mesh pour les générateurs, un autre pour les formateurs, et ainsi de suite. Le script d’entraînement utilise ces meshes pour orchestrer le flux général du travail, en passant les données d’un mesh à l’autre de manière fluide. Grâce à la prise en charge native des transferts de mémoire à distance (RDMA), les données sont transférées directement entre les membres des meshes, garantissant ainsi des workflows efficaces et évolutifs.
Intégration avec Verl
Monarch a été intégré avec verl, un framework d’apprentissage par renforcement largement utilisé dans l’industrie. En tant que preuve de concept, le modèle qwen-2.5-7b a été post-entraîné sur un ensemble de données mathématiques, évalué selon le benchmark AIME 2024. Plus de 500 étapes d’entraînement ont été menées sur 200 GPU, en utilisant megatron-lm, avec une montée progressive de 16 à 2048 GPU. Ces exécutions se sont révélées stables et ont montré une parité numérique satisfaisante avec les options existantes, illustrant ainsi la capacité de Monarch à orchestrer des frameworks RL existants.
Torchforge
Torchforge adopte une approche différente, étant un framework d’apprentissage par renforcement natif de PyTorch, conçu dès le départ avec les primitives de Monarch. L’objectif de Torchforge est de permettre aux chercheurs d’exprimer des algorithmes RL de manière aussi naturelle que du pseudocode, tout en laissant Monarch gérer la complexité distribuée sous-jacente. Le résultat est un code qui ne nécessite ni coordination distribué, ni logique de reprise — simplement du RL écrit en Python.
Cas d’Utilisation 2: Tolérance aux Pannes
Les défaillances matérielles et logicielles sont fréquentes à grande échelle. Par exemple, lors de sessions d’entraînement pour llama3, 419 interruptions ont été enregistrées sur une période de 54 jours pour un job d’entraînement sur 16 000 GPU, soit une défaillance en moyenne toutes les 3 heures. Si l’on projette cela sur des milliers de GPU, cela représente des pannes encore plus fréquentes. Redémarrer l’intégralité du job à chaque échec réduirait considérablement le temps d’entraînement effectif. Pour y remédier, il est essentiel d’exploiter des méthodes qui renforcent l’apprentissage distribué en rendant les modèles plus tolérants aux variations temporelles. Par exemple, torchft propose des solutions pour gérer les défaillances de GPU tout en permettant à l’entraînement de se poursuivre. En cas de panne, une approche hybride de parallélisme de données sharding alliant DDP tolérant aux pannes avec FSDP v2 et PP est mise en œuvre. En cas d’échec, torchcomms facilite la gestion des erreurs, permettant ainsi de reprendre l’entraînement sur le prochain lot sans interruption. Monarch intègre torchft, centralisant le plan de contrôle dans un modèle à contrôleur unique. Grâce à ses primitives de détection des pannes, Monarch peut identifier les défaillances et générer de nouveaux groupes de répliques logiques pour rejoindre l’entraînement. Des tests ont été effectués sur un cluster Coreweave de 30 nœuds (240 H100) en utilisant le planificateur slurm, tout en injectant 100 pannes toutes les 3 minutes. Monarch permet des stratégies de récupération configurables selon le type de défaillance, montrant des gains de temps significatifs en évitant les redémarrages de jobs inutiles.
Cas d’Utilisation 3: Débogage Interactif
Le framework d’acteurs de Monarch ne se limite pas à l’orchestration de jobs à grande échelle, il permet également un débogage interactif en temps réel des calculs complexes sur plusieurs GPU. Cette capacité représente un changement fondamental par rapport aux méthodes de débogage traditionnelles, souvent orientées vers les lots, vers une résolution de problèmes exploratoire qui s’aligne avec l’échelle et la complexité des systèmes ML contemporains. Les méthodes de débogage classiques échouent souvent à traiter les subtilités qui surviennent lorsque les modèles, fonctionnant parfaitement sur un seul GPU, rencontrent des problèmes tels que des conditions de concurrence, des blocages, ou des goulets d’étranglement en communication sur des dizaines d’accélérateurs. Avec Monarch, une expérience de développement interactive est possible. À l’aide d’un notebook Jupyter local, un utilisateur peut piloter un cluster comme un mesh Monarch.
Monarch + Lightning AI Notebook
Avec Monarch, il est désormais possible de lancer une tâche d’entraînement de 256 GPU à partir d’un unique notebook. Cette intégration offre une échelle transparente, des ressources persistantes et un débogage interactif, le tout dans un environnement unique. Cette approche permet de réserver et de maintenir des ressources de calcul directement depuis un notebook local dans Lightning. Même en cas d’interruption de session ou de déconnexion du code, l’allocation du cluster reste active tout au long de l’entraînement distribué. Cette persistance des allocataires de processus facilite l’itération et l’expérimentation, rendant le notebook un centre de contrôle fiable pour les tâches d’entraînement distribuées. Grâce au modèle d’acteurs de Monarch, il est possible de définir et de lancer le formateur Titan en tant qu’acteur sur un mesh de processus, scalant les tâches d’entraînement sur des centaines de GPU, le tout depuis le studio notebook. Monarch gère l’orchestration, le partage de code et de fichiers, ainsi que la collecte des logs, permettant une reconfiguration et un redémarrage rapides des tâches. Les logs et les métriques sont accessibles directement dans le notebook, ainsi que via des outils externes comme litlogger et wandb, simplifiant la surveillance et la gestion d’entraînements à grande échelle. Monarch révolutionne ainsi le débogage interactif dans le cadre de l’entraînement distribué, offrant la possibilité de définir des points d’arrêt Python dans le code d’acteurs, d’inspecter les processus en cours d’exécution, et de se connecter à des acteurs spécifiques pour un dépannage en temps réel, le tout à partir de l’interface du notebook.
Invitation à l’Action
Monarch est dès à présent disponible sur GitHub, prêt à être exploré, construit et enrichi. Les utilisateurs sont invités à plonger dans le repo Monarch pour commencer, à consulter la documentation pour des détails techniques approfondis, et à tester le notebook Jupyter interactif pour voir Monarch en action. Que ce soit pour orchestrer des runs d’entraînement massifs, expérimenter avec l’apprentissage par renforcement, ou déboguer des systèmes distribués, Monarch offre les outils nécessaires pour atteindre les objectifs de manière simple et évolutive.
Remerciements
L’équipe de Monarch tient à exprimer sa gratitude envers toutes les personnes ayant contribué à la réalisation de ce projet, ainsi qu’aux principaux contributeurs pour leur soutien continu.
L’évolution des workflows de machine learning, accompagnée de la montée des architectures distribuées et des systèmes d’apprentissage automatique, présente des défis inédits pour les développeurs et les chercheurs. À mesure que les entreprises cherchent à exploiter les avancées technologiques pour optimiser leurs processus, la nécessité d’une gestion centralisée et intuitive des ressources devient essentielle. Monarch se positionne comme une réponse à cette demande croissante, facilitant la programmation tout en offrant une scalabilité inégalée.
En intégrant des concepts tels que les meshes d’acteurs et la tolérance aux pannes, ce framework ouvre la voie à des applications ambitieuses dans des domaines variés, allant de l’intelligence artificielle à la robotique. Les capacités d’orchestration qu’il propose pourraient transformer la manière dont les équipes abordent leurs projets, permettant des itérations plus rapides et réduisant significativement les erreurs.
À l’échelle sociétale, cette évolution technologique soulève des questions sur l’avenir de l’intelligence artificielle et son rôle dans notre quotidien. Comment ces outils peuvent-ils contribuer à des solutions durables et éthiques ? Quelles innovations émergeront des synergies entre la recherche académique et l’industrie ? Les possibilités sont vastes et méritent d’être explorées. Il est crucial pour les professionnels et les passionnés de s’impliquer dans cette révolution technologique et d’expérimenter avec des outils comme Monarch, tout en considérant les implications plus larges de ces avancées sur notre société.
Aller plus loin
Pour approfondir votre compréhension de Monarch et de l’orchestration distribuée à grande échelle avec PyTorch, commencez par l’annonce officielle « Introducing PyTorch Monarch », qui explique les concepts clés (contrôleur unique, maillages d’acteurs, vectorisation à l’échelle d’un cluster) et les cas d’usage typiques.
Poursuivez avec la documentation sur meta‑pytorch.org/monarch, puis explorez le dépôt GitHub meta‑pytorch/monarch pour parcourir le code, les exemples et les instructions d’installation (incluant les distributions torchmonarch et torchmonarch‑nightly). Ces ressources vous donneront une vision complète pour intégrer Monarch dans vos scripts existants.
La tolérance aux pannes à grande échelle est détaillée dans l’article « Fault Tolerant Llama » sur le blog PyTorch, qui décrit l’usage de TorchFT en conditions extrêmes : Fault‑tolerant training with 2000 failures…. Pour aller plus loin côté implémentation, consultez le dépôt meta‑pytorch/torchft.
Côté post‑training et RL agentique, l’article « A Primer on LLM Post‑Training » propose une mise à niveau claire des techniques d’alignement et d’évaluation : A Primer on LLM Post‑Training. En complément, découvrez Torchforge, la librairie PyTorch‑native pour l’RL post‑training : Introducing torchforge et son dépôt meta‑pytorch/torchforge.
Pour le scaling LLM et les bonnes pratiques PyTorch natives, jetez un œil à TorchTitan, plateforme minimale pour l’entraînement de modèles génératifs à grande échelle, souvent utilisée avec les primitives de distribution modernes. Côté écosystème, cette approche s’imbrique avec les workflows interactifs décrits ici : Large‑scale interactive training with Monarch.
Enfin, consolidez vos bases de distribution PyTorch avec les tutoriels officiels : l’introduction vidéo à DDP (Distributed Data Parallel – Video Series) et le guide « Getting Started with DDP » (ddp_tutorial). Ces ressources vous aideront à passer de l’expérimentation locale à des déploiements multi‑GPU / multi‑nœuds robustes.
En combinant ces lectures — Monarch, TorchFT, Torchforge, TorchTitan et les tutoriels DDP — vous disposerez d’un parcours cohérent pour orchestrer des milliers de GPU avec un seul script, tout en assurant résilience, performance et itération rapide.