PyTorch Monarch vorgestellt

• PyTorch Monarch ist ein neues Framework, das entwickelt wurde, um effizientes verteiltes Training und Inferenz für große Modelle zu unterstützen
• Es erweitert die modulare Struktur von PyTorch und bietet Funktionen, um riesige neuronale Netze automatisch auf mehrere Geräte und Knoten aufzuteilen und zu verwalten
• Über eine API, mit der sich Modellparallelisierung, Pipeline-Parallelisierung und Datenparallelisierung integriert steuern lassen, wird der Aufwand für komplexe Konfigurationen für Entwickler reduziert
• Monarch zeigt insbesondere bei speicherintensiven Workloads wie großen Sprachmodellen (LLMs) und Empfehlungssystemen eine hohe Effizienz
• Als Teil des Versuchs, innerhalb des PyTorch-Ökosystems gleichzeitig Skalierbarkeit und Performance-Optimierung zu erreichen, ist es eine zentrale Komponente der verteilten Trainingsinfrastruktur der nächsten Generation

---

Überblick über PyTorch Monarch

• PyTorch Monarch wird als neue Komponente von PyTorch vorgestellt, um verteiltes Training und Inferenz für große Modelle zu vereinfachen
  • Es wurde so konzipiert, dass es die Flexibilität von PyTorch beibehält und gleichzeitig Modelle mit Milliarden von Parametern effizient auf mehrere GPUs und Knoten verteilen kann
  • Ohne komplexe Parallelisierungsstrategien manuell konfigurieren zu müssen, stellt es automatisierte Partitionierungs- und Kommunikationsoptimierungsfunktionen bereit
• Das zentrale Ziel von Monarch besteht darin, das Abstraktionsniveau der Modellparallelisierung zu erhöhen, damit sich Entwickler auf den Entwurf der Modellarchitektur konzentrieren können
  • Verschiedene Parallelisierungsmethoden wie Datenparallelisierung, Pipeline-Parallelisierung und Tensor-Parallelisierung lassen sich über eine einheitliche Schnittstelle steuern
  • Dadurch werden im Vergleich zu bestehenden Frameworks für verteiltes Training Codekomplexität und Kommunikations-Overhead deutlich reduziert

Hauptfunktionen und technische Merkmale

• Monarch platziert über einen automatischen Partitionierungsalgorithmus jede Ebene des Modells auf dem optimalen Gerät
  • Die Partitionierungsstrategie wird dynamisch unter Berücksichtigung von GPU-Speicherkapazität, Kommunikationsbandbreite und Rechenlast bestimmt
  • Diese Automatisierung ist besonders effizient bei LLMs, Transformer-basierten Modellen und großen Empfehlungssystemen
• Es stellt eine integrierte Parallelisierungs-API bereit, mit der Entwickler mit einer einzigen Codebasis verschiedene Parallelisierungsstrategien ausprobieren können
  • So kann dasselbe Modell beispielsweise mit einer Kombination aus Datenparallelisierung und Pipeline-Parallelisierung ausgeführt oder auf Tensor-Parallelisierung umgestellt werden
  • Diese Flexibilität erleichtert die Suche nach Optimierungen abhängig von Modellgröße und Hardware-Konfiguration
• Monarch ist mit den bestehenden PyTorch-Funktionen DistributedDataParallel(DDP) und Fully Sharded Data Parallel(FSDP) kompatibel
  • Der Umstieg auf Monarch ist möglich, ohne die bestehende Codebasis umfassend ändern zu müssen
  • Zudem ist es in TorchScript und TorchDynamo von PyTorch integriert und unterstützt so Optimierungen bei Kompilierung und Ausführung

Performance und Anwendungsfälle

• Erste Benchmark-Ergebnisse zeigen, dass Monarch gegenüber dem bestehenden verteilten Training in PyTorch eine 20–30 % höhere Kommunikationseffizienz und einen 15 % geringeren Speicherverbrauch erreicht
  • Insbesondere bei Modellen mit mehreren Milliarden Parametern verbessern sich Trainingsgeschwindigkeit und GPU-Auslastung deutlich
  • Dies wurde experimentell bei großen Sprachmodellen (z. B. der GPT-Familie) und Empfehlungssystemen bestätigt
• Monarch läuft sowohl in Cloud- als auch On-Premises-Umgebungen und ist mit wichtigen Cloud-Infrastrukturen wie AWS, Azure und GCP kompatibel
  • Auch die Integration mit übergeordneten Frameworks wie PyTorch Lightning und Hugging Face Transformers wird unterstützt

Bedeutung im PyTorch-Ökosystem

• Monarch wird als zentrale Infrastrukturerweiterung bewertet, mit der PyTorch auf das Zeitalter großer KI-Modelle reagiert
  • Es schafft die Grundlage dafür, das bisherige, auf einzelne GPUs ausgerichtete Trainingsparadigma zu überwinden und das Training extrem großer Modelle mit Tausenden von GPUs zu ermöglichen
  • Für Forschende und Unternehmen dient es als standardisierte Lösung für verteiltes Training, mit der sich Skalierbarkeit und Effizienz zugleich erreichen lassen
• Das PyTorch-Team hat angekündigt, Monarch als Open Source zu veröffentlichen und es unter Einbeziehung von Community-Feedback kontinuierlich weiterzuentwickeln
  • Künftig sollen Funktionen für automatische Optimierung, dynamisches Scheduling und hybride Parallelisierung ergänzt werden
  • Als verteiltes Trainings-Framework der nächsten Generation von PyTorch dürfte es zur Demokratisierung von KI-Infrastruktur und besserer Zugänglichkeit beitragen

[GN⁺]

Hacker-News-Kommentare

• Dieses Projekt scheint auf eine andere Ebene als Tinker abzuzielen.
  Wenn man den Vorstellungsartikel zu Tinker liest, ist Tinker ein verwalteter Fine-Tuning-Service, während Monarch Infrastruktur-Primitive bereitstellt.
  Deshalb frage ich mich, ob sich auf Monarch auch ein Dienst wie Tinker aufbauen ließe.

  • Im Moment läuft dort wohl so etwas wie TorchForge.

• Es sieht so aus, als hätte bei PyTorch die Oxidation begonnen.
  Monarch ist in ein Python-basiertes Frontend und ein in Rust implementiertes Backend aufgeteilt.
  Insgesamt wirkt das wie ein ziemlich interessantes Projekt.

  • Laut mehreren Quellen ist Monarch ein experimentelles Framework für PyTorch und kein Ersatz.
    Man wird also vermutlich weiterhin zirkuläre Graphen auf Basis von std::shared_ptr und Memory Leaks genießen können.
    Schade, dass es nicht komplett in einer funktionalen Sprache neu geschrieben wurde.
  • Das scheint keine oxidierte Version eines bestehenden Projekts zu sein, sondern ein völlig neues Projekt.

• Ich habe selbst eine PyTorch-Erweiterung gebaut — mycelya-torch.
  Meine Version unterstützt noch keine Kommunikation zwischen Knoten, aber ich fand interessant, wie Monarch Performance erreicht.
  Monarch verwendet vermutlich cloudpickle, um Code an alle Knoten zu verteilen, was nur anfängliche Setup-Kosten verursacht und effizient ist.
  Auch die Struktur, bei der ein einzelner Controller Nachrichten fan-out verteilt, fand ich eindrucksvoll.
  Ich frage mich allerdings, ob benutzerdefinierte Kernel unterstützt werden und wie fein sich die Kommunikation zwischen Akteuren steuern lässt.
  Insgesamt gefällt mir dieser Ansatz besser als ein Multi-Controller-Modell.

  • Um benutzerdefinierte Kernel zu verwenden, muss man den Initialisierungscode der Remote-Worker eventuell etwas anpassen.
    Dafür kann man die benötigten Kernel oder den Systemcode direkt einbacken (bake-in).

• Das wirkt strukturell ähnlich wie Ray.

  • Das Codebeispiel ist fast identisch mit Ray.
    Monarchs Actor und Rays @ray.remote-Klassen folgen demselben Muster.
  • Ich frage mich, warum man Monarch statt Ray verwenden sollte — vielleicht wegen der engeren Integration mit PyTorch oder der Tensor-Abstraktion?
  • Dask macht eine ähnliche verteilte Verarbeitung, stammt aber ursprünglich aus dem HPC-Bereich, daher ist die GPU-Unterstützung eingeschränkt.
    Siehe die offizielle Dask-Website.
  • Das dachte ich auch. Vor allem mit Blick auf die jüngste Kooperationsankündigung von PyTorch und Ray hatte ich diesen Eindruck.
    Zugehöriger Blog

• Interessant, das erinnert im Kern an das Konzept von Fortran-Coarrays (2008).

  • Oder vielleicht eher an Hadoop (2006).
    Nur dass es viel besser ist, weil man weder MapReduce noch Fortran direkt verwenden muss.

• Es gab die Formulierung: „Engpässe eines einzelnen Hosts vermeiden und für die Nachrichtenübertragung das vollständige Mesh über einen verteilten Cluster nutzen“.
  Falls das jemand bearbeiten kann, hätte ich gern Referenzwerte dazu ergänzt.

• Sieht nach einem guten Projekt aus.
  Ich hätte dazu ein paar Fragen.

  • Ist das ähnlich wie openMPI?
  • Wie wird das Mesh aufgebaut? Geht das nur innerhalb desselben Hosts?

• Das könnte in der Coarray-Welt ein wichtiges Projekt werden, aber es gibt schon Anzeichen für Probleme.
  Die Tensor-Engine ist an CUDA und RDMA (ibverbs) gebunden, und da der Code GPUDirect RDMA verwendet,
  dürfte die CUDA-Abhängigkeit am Ende noch stärker werden.
  OpenUCX wäre vermutlich die bessere Wahl gewesen.

• Im Vergleich zu Jax wirkt es funktional schwächer.
  Jax optimiert mit einem starken Compiler die Kommunikation zwischen Knoten.

  • Monarch konzentriert sich allerdings auf ein Single-Controller-Paradigma, während Jax auf eine Multi-Controller-SPMD-Struktur setzt.
    Ein einzelner Controller ist leichter zu verstehen, Multi-Controller ist für bestimmte Datenflüsse besser optimiert.
    Es gibt auch interessante Versuche, beide Ansätze zu kombinieren.