Am 1. Oktober 2026 hat Modal im offiziellen Engineering-Blog bekannt gegeben, dass Modal Clusters, sein Multi-Node-GPU-Cluster-Produkt, allgemein verfügbar (GA) ist. Entwickler müssen nur einen einzigen Decorator, modal.clustered, an eine Python-Funktion hängen, um einen Multi-Node-Cluster zu erhalten: Die Knoten sind über InfiniBand Verbs mit bis zu 6,4 Tbps Bandbreite verbunden, PyTorch und NCCL werden automatisch konfiguriert. Ein Cluster ist innerhalb von Sekunden bereit und wird sekundengenau abgerechnet.
Was jenseits des einen Decorators steckt
modal.clustered ist kein isolierter syntaktischer Zucker. Modal Clusters ist mit allen bestehenden Modal-Primitiven verzahnt: Trainings-Checkpoints landen in Volumes, Daten werden über Cloud Bucket Mounts eingebunden, Jobs werden mit Queues orchestriert. Der heikelste Teil der Netzwerkschicht steckt in einem einzigen Schalter, rdma=True — Treiber, Umgebungsvariablen und Userspace-Bibliotheken, die bei jedem Cloud-Anbieter anders aussehen, übernimmt die Plattform automatisch, sodass PyTorch + NCCL out of the box läuft.
Bei der Preisgestaltung gilt: Klassische Multi-Node-Setups werden entweder stundenweise gemietet oder verlangen Kapazitätsreservierungen — und man zahlt auch bei Leerlauf. Modal bleibt hier seiner Serverless-Linie treu: laufen lassen, wann man will, und nur für die tatsächliche Nutzung zahlen.
Hintergrund: Wohin 1,5 Jahre Engineering geflossen sind
Laut Modal wurden die vergangenen 1,5 Jahre damit verbracht, die Fähigkeit im Praxiseinsatz zu härten; der Kern war ein kompletter Neubau von Scheduler und Netzwerkstack.
Klassische Scheduler sind gierig: Jede Maschine fragt die Aufgabenwarteschlange für sich ab, und der Scheduler sucht einzeln nach passender Arbeit. Doch Multi-Node-Scheduling ändert die atomare Einheit von „einer Maschine" zu „N Maschinen auf einmal" — also schrieb Modal einen neuen Gang Scheduler: Er verschafft sich zuerst einen Überblick über die gesamte Flotte und alle wartenden Cluster, erstellt einen globalen Platzierungsplan und handelt dann gebündelt, indem er Knoten derselben Verfügbarkeitszone auf dasselbe RDMA-Fabric legt.
RDMA selbst ist berüchtigt schwer zu unterstützen. Modal setzte auf gVisor, die sicherere Multi-Tenant-Container-Runtime — die aber kein RDMA konnte. Also baute Modal die RDMA-Unterstützung selbst in gVisor ein und gab die Änderungen an die Open-Source-Community zurück.
Wer es bereits nutzt
Der Blog nennt drei Workloads, die in der Testphase darauf liefen: Der Kundenservice-Agent-Anbieter Decagon hat Open-Modelle im Billionen-Parameter-Bereich feinabgestimmt; das Humanoid-Robotik-Unternehmen 1x trainiert das Weltmodell von NEO auf Multi-Node-B300-Clustern vor und fährt bei großen Experimentreihen hunderte GPUs auf einmal hoch; und Runway betreibt darauf die Multi-Node-Inferenz seiner neuesten Video-Generierungs- und -Editing-Modelle Gen-4.5 und Aleph 2.0, wobei der Autoscaler die Cluster als Einheit skaliert.
Für wen es passt — und wer abwarten kann
Unternehmen mit Multi-Node-Trainings- oder Inferenzbedarf, die kein eigenes Cluster-Betriebsteam aufbauen wollen, sind die direkteste Zielgruppe: Post-Training großer Modelle, Billionen-Parameter-Fine-tuning und knotenübergreifende Inferenz-Splitting hießen bisher entweder ein Infra-Team einstellen oder sich mit Warteschlangen und Reservierungen der Cloud-Anbieter arrangieren.
Wer dauerhaft auf einer einzigen GPU läuft, für den ist Modal Clusters irrelevant; wer bereits langfristig reservierte eigene Rechenzentren hat, für den lohnt sich eine Migration womöglich nicht. Modal Clusters öffnet eine Option, die es so kaum gab — Multi-Node-Kapazität sekundengenau mieten — und ihr Wert gehört zuerst den Teams, deren Rechenbedarf stark schwankt.
