Overcoming Orchestration Bottlenecks at Exascale: A Decentralized, Policy-Driven Approach for Sim-AI Ensembles
Dieses Paper stellt EnsembleLauncher vor, einen dezentralen, richtliniengesteuerten Workflow-Orchestrator, der Orchestrierungsengpässe auf Exascale-Systemen wie Aurora überwindet, indem er erfolgreich auf acht Millionen Aufgaben skaliert und den aktuellen Stand der Technik signifikant übertrifft, während er gleichzeitig ein flexibles Scheduling für heterogene Simulations-KI-Ensembles ermöglicht.
Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen
Stellen Sie sich vor, Sie sind der Regisseur eines riesigen, chaotischen Filmsets. Sie haben Millionen von winzigen, blitzschnellen Aufgaben (wie ein Kamerablitz) und ein paar riesige, langsam bewegliche Aufgaben (wie das Verschieben einer gigantischen Schlosskulisse). In der Vergangenheit war der Versuch, all diese Schauspieler und Requisiten auf einem Supercomputer in der Größe einer Stadt (wie dem Aurora-Supercomputer) zu verwalten, ein Albtraum. Der „Manager“, der für die Verteilung der Aufträge zuständig war, wurde von der schieren Anzahl der Anfragen so überfordert, dass die gesamte Produktion zum Stillstand kam.
Dieses Paper stellt eine neue Art vor, die Show zu leiten, genannt EnsembleLauncher. Anstatt einen einzelnen Chef zu haben, der mit jedem einzelnen Arbeiter spricht, baut EnsembleLauncher einen fraktalen Baum aus Managern auf. Stellen Sie sich das wie eine riesige Unternehmenshierarchie vor, in der der CEO nicht die Praktikanten anruft; der CEO ruft die VPs an, die VPs rufen die Manager an und die Manager rufen die Praktikanten an. Diese „rekursive Hierarchie“ bedeutet, dass der oberste Chef niemals von zu vielen Telefonaten überflutet wird.
Die große Entdeckung: Es geht um die Form, nicht die Software
Die Autoren führten ein faszinierendes Experiment durch, um herauszufinden, warum andere Tools versagten. Sie nahmen zwei sehr unterschiedliche Software-Tools (Dask und Parsell) und zwangen sie beide dazu, denselben „flachen“ Managementstil zu nutzen (bei dem alle mit dem Chef sprechen). Beide Tools stürzten gleichzeitig ab.
Dann gaben sie denselben Tools eine „hierarchische“ Form (die Baumstruktur). Plötzlich funktionierten sie viel besser.
- Das Ergebnis: Das Paper beweist, dass die Form des Management-Teams (die Topologie) das Wichtigste ist, nicht die spezifische Software-Code, die verwendet wird. Wenn man eine flache Struktur hat, wird selbst die beste Software ersticken. Wenn man eine Baumstruktur hat, kann selbst unterschiedliche Software hochskalieren.
- Der Beweis: Auf dem Aurora-Supercomputer skalierten sie dieses neue System auf 8.192 Knoten (was das Maximum war, das sie für den Test verwenden durften) und ließen 8 Millionen serielle Aufgaben laufen. Das System war mehr als viermal schneller als die derzeit besten verfügbaren Tools.
Warum der alte Weg scheiterte: Der „Stau“
Um zu verstehen, warum der alte Weg scheiterte, stellen Sie sich einen einzelnen Verkehrspolizisten vor, der in der Mitte einer Autobahn steht und versucht, Millionen von Autos zu dirigieren.
- Das Flach-Problem: In den alten „flachen“ Systemen musste jede einzelne Aufgabe beim zentralen Scheduler um Erlaubnis fragen, um laufen zu dürfen. Bei 128 Knoten maß das Paper, dass die Arbeiter für winzige 0,1-Sekunden-Aufgaben 27,6 Sekunden lang nur darauf warteten, mit dem Chef zu sprechen, während die eigentliche Arbeit nur 0,1 Sekunden dauerte. Die Arbeiter saßen untätig herum und starrten auf ihre Telefone, weil der Chef zu beschäftigt war.
- Die Baum-Lösung: EnsembleLauncher lässt die lokalen Manager den Smalltalk erledigen. Die Arbeiter sprechen nur mit ihrem lokalen Manager, der wiederum nur mit der nächsten Ebene darüber spricht. Dies reduzierte die Wartezeit für diese winzigen Aufgaben von 27,6 Sekunden auf nur 1,9 Sekunden.
Der „schlaue“ Scheduler: Es gibt kein „Einheitsmodell“
Das Paper argumentiert auch, dass man nicht einfach eine einzige Regel verwenden kann, um alle Jobs zu verwalten. Manchmal muss man die größten Jobs zuerst erledigen; manchmal die schnellsten.
- Das Experiment: Sie testeten verschiedene „Regeln“ für eine Mischung von Aufgaben, die sich in ihrer Größe und Zeit massiv unterschieden (einige dauerten 0,1 Sekunden, andere über 1.500 Sekunden).
- Das Ergebnis: Sie fanden heraus, dass es bei Aufgaben mit hoher Variation (einige sehr schnell, andere sehr langsam) sehr wichtig war, die richtige Regel zu wählen. Die Verwendung einer „Largest First“- oder „Longest First“-Regel verkürzte die Gesamtzeit erheblich im Vergleich zu der Methode, Aufgaben einfach in der Reihenfolge ihres Eintreffens abzuarbeiten (FIFO).
- Die Flexibilität: EnsembleLauncher erlaubt es Wissenschaftlern, ihre eigenen benutzerdefinierten Regeln einzubauen. In einem Test, der einen realen wissenschaftlichen Workflow (genannt MOFA) nachahmte, erledigte eine „schlaue“ Regel, die Jobs an das am wenigsten ausgelastete Team routete, die Arbeit doppelt so schnell wie eine starre Regel, die alle kleinen Jobs in eine bestimmte Ecke des Computers zwang.
Was sie (noch) nicht gelöst haben
Das Paper ist sich sehr klar darüber, was sie nicht behoben haben.
- Das „Straggler“-Problem: Wenn ein Zweig des Baumes mit einem langsamen Job feststeckt, kann das System diesen Job nicht einfach „stehlen“ und einem schnelleren Zweig geben. Sie schlagen dies als zukünftige Arbeit vor.
- Der „Ein-Knoten“-Absturz: Wenn ein Manager-Knoten ausfällt, muss das System derzeit den gesamten Zweig des Baumes unter ihm neu starten, nicht nur das einzelne defekte Stück. Sie geben zu, dass dies eine Einschränkung ist.
- Das Skalierungs-Limit: Obwohl sie bis zu 8.192 Knoten getestet haben, merkt das Paper an, dass dies lediglich das Limit der Maschine war, die sie verwendet haben, und nicht unbedingt das Limit ihrer Software. Sie vermuten, dass es noch viel höher gehen könnte, haben es aber noch nicht gemessen.
Das Fazit
Das Paper zeigt, dass wir, um die massiven, gemischten Workflows der Zukunft (in denen KI und Super-Simulationen zusammen tanzen) zu betreiben, aufhören müssen, flache Single-Boss-Systeme zu verwenden. Indem wir einen tiefen, rekursiven Baum aus Managern bauen und Wissenschaftlern erlauben, ihre eigenen Scheduling-Regeln zu wählen, können wir die Arbeiter des Supercomputers beschäftigt halten und die Produktion am Laufen halten. Es ist nicht nur ein neues Tool; es ist eine neue Art zu denken darüber, wie man eine digitale Armee von Millionen organisiert.
Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?
Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.