Wirksame Scheduling für GPU-Clustere

Erstellen eines Cluster-Scheduler, um Forschung mit hohem Impact zu priorisieren, während die volle Kapazität gewahrt bleibt

Im Team für die KI-Infrastruktur bei Ai2 sind wir dafür verantwortlich, die GPU-Rechenkapazität des Instituts bereitzustellen, insbesondere für große, verteilte Trainingsaufgaben. Wir betrachten diese Aufgabe als eine Pyramide aus vier miteinander verbundenen Metriken.

Die Grundlage ist Verfügbarkeit: wie oft das Hardware-System gesund und bereit für die Arbeit ist. Darüber liegt Occupancy: der Anteil der verfügbaren Zeit, der einer bestimmten Arbeitslast zugewiesen wird. Danach kommt Impact: wie oft die wertvollsten Arbeitslasten Ressourcen erhalten. Das Zentrum der Pyramide ist Utilization: der Anteil der GPU-Leistung, der im Laufe einer Arbeitslast verwendet wird.

Dieser Beitrag befasst sich mit der Verbesserung des Einflusses unserer Planungsentscheidungen. Wir haben kürzlich einen auf Prioritäten basierenden Planer durch ein System ersetzt, das GPU-Zeitbudgets, hierarchische faire Verteilung und ein Zeitabschnittsmodell umfasst. Dadurch hat sich die Diskussion darüber, wie viel GPU-Zeit jedes Forschungsprojekt verdient, von einer Fall-für-Fall operativen Aufgabe zu einem transparenten administrativen Haushaltsbudget-Prozess verlagert.

Überverkauf

Bei Ai2 verwalten wir tausende NVIDIA H100, B200 und B300-GPUs, die in Clustern mit einer Größe von 88 bis 1024 GPUs angeordnet sind. Diese Clustere sind für das großflächige verteilte Trainieren von AI-Modellen konzipiert und dienen einer Gruppe von etwa 150 interner Forschern, deren Arbeit ein vielfältiges Spektrum an AI-Themen umfasst – einschließlich des vollständigen Modellflusses beim Trainieren von LLM und VLM, der Simulation von Robotik-Reinforcement-Learning (RL), sowie dem Post-Training für wissenschaftliche agentische Anwendungsfälle.

Wie viele Labore haben wir eine Nachfrage nach GPU-Zeit, die den Angeboten weit übertrifft. Basierend auf eingereichten Arbeitslasten gibt es zu jeder Zeit unzählige Anfragen für 2-3x mehr GPUs als verfügbar sind. Eine Möglichkeit, dies zu verstehen, ist, dass jede verfügbare GPU-Stunde im Cluster von 2-3 verschiedenen Forschungsarbeiten benötigt wird.

Historisch gesehen verwendeten wir einen prioritärbasierten Planer und erlaubten es den Arbeitslasten, sich von der Präemptivität zu lösen. Jede Gruppe hatte eine Grenze an parallelen GPUs, die von den Arbeitslasten genutzt werden konnten, die vor der Präemption geschützt waren. Präemptierbare Arbeitslasten konnten diese Grenze bei leeren GPUs überschreiten. Diese Strategie führte zu vorhersehbaren Problemen. Zum Beispiel beobachteten wir Fälle von „GPU-Squatting“, bei denen Benutzer keine-Aufgaben platzieren, die sie bei Bedarf ansprechen könnten. Dies geschah, weil die Forscher herausfanden, dass sie keine Latenzzeiten erreichen konnten, die ausreichend niedrig sind, um Probleme in Echtzeit zu lösen. Wir beobachteten auch eine Prioritätsinflation: Schließlich hatte 100 % der geplanten Workloads eine HÖHE Priorität. Das bedeutete, dass die niedrigeren Prioritätsstufen völlig kein GPU-Zeit erhielten. Da die Vorrangmöglichkeit optional war, stellten wir auch fest, dass unsere auf Abruf dahenen Ingenieure den größten Teil ihrer Zeit für die Antworten auf Ticketanfragen damit verbrachten, den organisierten Schließen von nicht-vorrangmöglichen Arbeitslasten zu verhandeln, die auf Hosts mit bekannten Wartungsproblemen läuften.

Die Tragödie des Gemeinschaftseigentums

Als diese Probleme auftraten, war es langsam, die eigentlichen Ursachen zu erkennen. Unsere anfänglichen Bemühungen, das wichtigste Arbeiten Zeit auf der GPU zu geben, konzentrierten sich auf eine strengere Kontrolle der Prioritätensetzung und letztendlich darauf, den prioritärbasierten Scheduler zu umgehen, indem wir offensichtlich GPU-Monopole für wichtige Projekte zuweisen. Obwohl wir es anfangs nicht erkannten, hatten wir ein perfektes Labor errichtet, in dem wir die „Tragödie des Gemeinsamen“ beobachten konnten. Die Individuen konkurrierten um ein knappes, gemeinsames Ressourcenobjekt und versuchten, durch maximale individuelle Ergebnisse ein nicht optimales globales Ergebnis zu erzielen, wodurch das ursprüngliche Ressourcenobjekt missbraucht wurde.

Wir waren nicht die ersten, die dieses Art von Interaktion beobachteten. Die Ressourcenzuteilung ist ein faszinierendes Forschungsgebiet, das Algorithmenentwicklung, Wirtschaft und Systemmanagement miteinander verbindet. Ein zentrales Problem ist, dass Nutzer oft besser als die Organisation selbst den Wert ihrer eigenen Aufgaben kennen – doch sie haben möglicherweise Anreize, diesen Wert zu verbergen oder Ressourcen zu behalten, auch wenn dies das Gesamtpaket beeinträchtigt. Beispielsweise berichten Ghodsi und seine Kollegen in ihrem Artikel von 2011 über Dominant Resource Fairness, dass eine Suchgesellschaft nur spezielle Maschinen für bestimmte Aufgaben bereitstellt, wenn die Nutzer eine hohe Nutzung garantieren können. Sie stellten schnell fest, dass „Nutzer ihren Code mit unendlichen Schleifen füllen, um die Nutzungsraten künstlich zu erhöhen“. Die Hardware ändert sich, aber die grundlegenden Probleme, die die Ressourcenzuteilung komplex machen, bleiben bestehen.

> Budgets nicht Szenarien

Die klassische Lösung für eine Tragödie des Gemeinguts ist die Privatisierung des gemeinsam genutzten Ressourcen – die Eigentümer werden dazu angeregt, den Wert ihres Eigentums zu maximieren. Als wir Teams mit Monopolen über Gruppen an GPUs ausgestattet haben, tat wir bereits etwas Ähnliches, aber es war zu grob. Dadurch blieben die GPUs aufgrund der saisonalen Besonderheiten der Forschung ungenutzt. Die Teams sind bereit, Experimente und Trainings in unterschiedlichen Zeiten durchzuführen. Daher würde die Zuweisung eines Monopols dazu führen, dass es Zeiten geben könnte, in denen keine Aufgaben verfügbar sind, während ein anderes Team auf Kapazität wartet.

Wir haben manuell ein Knapsack-Problem gelöst, indem wir versuchten, die dynamisch veränderlichen Forschungsanforderungen in einen statischen Zeitplan zu passen. Wir wollten den Eigentumsanreiz haben, aber auch die volle Nutzung der GPUs aufrechterhalten.

Wir haben beschlossen, das Eigentumsmodell zu überdenken. Anstatt Teams mit GPUs auszusenden, entschieden wir uns dafür, einen Teil der GPU-Zeit zu vergeben. Die Vorhersage der Nachfrage in der Zukunft erfordert die Kenntnis der Ergebnisse neuer wissenschaftlicher Experimente, sodass sie nicht genau vorhergesagt werden kann. Die Priorität der Forschungsaktivitäten hingegen ist eine strategische Frage, und diese kann leichter im Voraus diskutiert und entschieden werden. Anstatt versuchen zu wollen, das Zeitplanungsproblem zu lösen, ermöglichten wir es der Führung, wie Investoren zu denken. Bevor die Arbeitslasten entstehen, muss entschieden werden, wie jeder Forschungsaufwand mit GPU-Zeit finanziert wird – basierend auf der Einschätzung des möglichen Einflusses. Der Scheduler kann anschließend diese Informationen verwenden, um die eintreffenden Arbeitslasten zu priorisieren.

Mit diesem Ziel entwickelten wir ein hierarchisches System, bei dem Manager das GPU-Zeitverfügbarkeit proportional zu den Projekten und Forschern verteilen können, für die sie verantwortlich sind. Wie das untenstehende Diagramm zeigt, wird diese Strategie direkt in eine garantierte Verteilung der GPU-Zeit umgesetzt. Das Projekt A1 weiß, dass es einen Anteil von 35% an der Gesamtkapazität hat, unabhängig davon, wie viele andere Projekte anderswo im Wartungszustand sind.

Die interne Werte zeigen die Gesamtkapazität des Clusters an, die einem Blattprojekt zugewiesen wird.

In diesem System muss jede Anfrage nach GPU-Zeit durch einen Budgetrahmen finanziert werden, sonst ist sie nicht vor Überlauf geschützt. Im alten System hatte eine hohe Priorität keinen Kostenaufwand, und die Nicht-Überlauf-Fähigkeit ermöglichte es einem Team, den gemeinsamen GPU-Limit unbegrenzt zu erreichen, sodass alle ihn nutzten. Jetzt ist nichts kostenlos, daher stammt jede Methode, um GPU-Zeit zu erhalten, aus der Zuweisung des Nutzers, der davon profitiert. Eine überlaufende Arbeitslast verbraucht den Budgetrahmen des Teams für nichts. Unsere Strategie besteht darin, den Planer für Spiele teurer zu machen als eine ehrlich geführte Debatte mit einem größeren Budget. Wir iterieren ständig an diesem Budgetprüfverfahren, aber die wichtigsten Anforderungen sind, dass es regelmäßige Möglichkeiten für Forscher gibt, sich für die benötigte Zeit zu rechtfertigen, und die Entscheidungen werden von Managern getroffen, die den entsprechenden Konflikten am besten zugänglich sind. Das bedeutet, dass Entscheidungen bezüglich der Allokationen in einem Forschungsprojekt von dem leitenden Forscher getroffen werden, in einem Forschungsprogramm von dem Leiter des Forschungsprogramms und über alle Programme von dem leitenden Programmmanager oder vom CEO.

Fair-share

In Kombination mit diesem GPU-Zeitbudgets-Tool haben wir einen hierarchischen Fair-Share-Scheduler entwickelt, um die tatsächliche Nutzung der Allokationen im gesamten Programmbaum zu verwalten. Der Algorithmus ist nicht neu – eine hierarchische Fair-Share über ein Zeitfenster gehört zu einer Tradition, die bis zur Hadoop Fair Scheduler im Jahr 2009 zurückgeht, und die gleiche Herangehensweise wird heute in SLURM’s Fair Tree und YARN’s Fair Scheduler aktiv verwendet. Was neu für uns ist, sind die Eingaben: der Baum spiegelt die Struktur des Forschungsprogramms wider, und die Gewichte sind Budgets, die von den Verwaltern festgelegt werden, anstatt statischer Quoten.

Der Scheduler überwacht die Nutzung innerhalb einer scrollenden Vergrößerungsfenster-Zeiträume (wir setzen standardmäßig 7 Tage voraus) und ordnet die Arbeitslasten nach der Sortierung von ungenutzt verfügbaren Allokationen über die übernutzten Allokationen. Auf diese Weise können wir im Zeitraum einer Woche erwarten, dass jede Gruppe das ihr zugewiesene GPU-Zeitfenster erhält, solange sie aktiv Arbeitslasten mit ausreichender Nachfrage einreicht.

„Der neue Scheduler gibt uns das Gefühl, dass wir 30 Prozent mehr Rechenleistung haben. Bei dem alten Scheduler wurde diese Leistung im Falle von Zeiten, in denen wir nicht den vollen Slot limit benötigten, praktisch verloren. Mit dem neuen Scheduler können wir solche Situationen abfangen und später über die zugewiesene Limit hinausfahren – und dabei weiterhin schnell und ohne Unterbrechung unsere Aufgaben planen, sodass wir wieder diese Leistung zurückbekommen. Unsere Arbeitslasten sind oft fluktuierend, daher hat uns das eine erhebliche Menge an Rechenleistung zurückgegeben.“ – Chris Clark

Der Scheduler unterscheidet zwei Arten von Besetzung. Allokierte Besetzung ist die Zeit, in der eine Arbeitslast in den Budget eingestellt wird. Dies basiert auf den Allokationen des Arbeitslastbesitzers und beeinflusst die Berechnung des fairen Anteils im Budget. Diese Arbeitslasten sind während ihrer minimalen Betriebszeitfenster vor Übernahme geschützt. Unallokierte Besetzung wird nicht in den Budget eingestellt, ist von Anfang an nicht geschützt und kann durch jede Allokationseinholung übernommen werden. Dadurch können die GPUs auch dann vollständig besetzt bleiben, wenn die Allokationen nicht genau dem Bedarf entsprechen, und Teams können keine freien GPU-Zyklen verlieren.

Der Scheduling-Contract

Eine weitere Eigenschaft des verteilten Trainings, die eine gerechte Ressourcenzuteilung erschwert, ist, dass Arbeitslasten sehr lange laufen können. Trainingsaufgaben laufen regelmäßig Stunden, Tage – und manchmal sogar Wochen lang. Einmal eingeschaltet, bleibt eine Arbeitslast für eine Woche oder länger auf den zugewiesenen GPUs, sodass andere keine Möglichkeit haben, ihr budgetierter Zeitbedarf zu erhalten. Das ist die Systemeigenschaft, die das Anlegen von GPU-Zeiten ermöglicht. Es war auch das, was die auf Call stehenden Ingenieure dazu zwang, mit den Betreibern langer Projekte zu verhandeln, um die anhaltenden Wartungsprobleme zu lösen.

Um diese Probleme zu lösen, haben wir einen „Planungsvertrag“ eingeführt. Im Austausch für den Zugang zum Cluster muss eine Arbeitslast ihre minimale Laufzeit angeben – also die kürzeste Dauer, die erforderlich ist, um bedeutenden Fortschritt zu erzielen. Während dieser Zeit wird die Arbeitslast vor Übernahme geschützt. Dadurch erhält der Forscher eine Garantie für Fortschritt, während dem Planer das Recht zukommt, nachdem der Fortschritt gespeichert wurde, neu zu balancieren und die wiederverwendbaren Arbeitslasten automatisch erneut zu priorisieren. Alternativ kann ein Benutzer den Mindestlaufzeitwert auf null setzen, was bedeutet, dass die GPU-Zeit nicht verwendet werden muss. Diese Arbeitslasten sind immer einem Unterbrechung ausgesetzt, aber sie sind auch frei, da sie nicht mit einem Budget verrechnet werden.

Das Arbeitsumfeld-Lebenszyklus folgt diesem Muster:

1. Die Arbeitslast wird mit einem Mindestlaufzeitverfahren eingereicht und zeigt an, ob sie wiederholt werden kann oder nicht.
2. Die Arbeitsbelastung wird nach dem fairen Teilverfahren geplant, wobei sie durch das Verhältnis zwischen tatsächlicher Auslastung und zugewiesenem Zeitraum im Rückblendenfenster gewichtet wird.
3. Die Arbeitslast läuft für ihre minimale Laufzeit ab, und diese wird auf die Zuweisungen angerechnet.
4. Die Arbeitslast kann weiterhin laufen, solange die damit verbundenen Allokationen sie gegenüber anderen Prioritäten haben. Diese Zeit wird ebenfalls von den Allokationen abgezogen.
5. Es kann vorzeitig abgebrochen und wieder eingeleitet werden, wodurch es zum Schritt 2 zurückkehrt.
6. Die Arbeitslast ist abgeschlossen und lässt seine Ansprüche auf die Ressourcen frei.

Gemeinsam fügen diese Vereinbarungen der Zeit-Slicing-Technik unserem Scheduler hinzu. Laufende Arbeitslasten können entfernt und automatisch wieder eingeleitet werden, wodurch eine gerechte Verteilung erreicht wird und das Anlegen von Speicherplätzen verhindert wird. Sie ermöglichen es auch ungesunden Hosts, ihre Arbeitslasten zu reduzieren, sobald sie ihr minimaler Laufzeitlimit erreichen – sodass Reparaturaktivitäten vollständig automatisiert werden können. Dieser letzte Punkt war wichtiger, als wir beim Planen dieser Arbeit erkannten. Dadurch wurden die Reparaturen, die einen menschlichen Eingreifakt erfordern, um 74% reduziert – was eine enorme Einsparung an Arbeitszeit bedeutet.

Simulations

Wir wissen, dass Änderungen in der Zeitplanungspolitik unbeabsichtigte Folgen haben können. Die Nullsummensubstanz des Problems bedeutet, dass die Zeit, die einem Forscher gegeben wird, dazu führt, dass jener anderen Forscher weniger Zeit bekommt. Benutzer, die diesen Austausch verlieren, neigen dazu, nach neuen Lösungen zu suchen. Bevor das budgetbasierte System eingeführt wird, wollten wir eine schnelle Methode haben, um vorherzusagen, wo die längeren Wartezeiten entstehen könnten, und die Konfigurationsparameter wie die Länge der Rückblende-Winche oder den maximalen Wert für den minimalen Betriebszeitraum (wir wählten 8 Stunden) zu testen.

Wir haben eine kleine Simulationumgebung entwickelt, die eine Sammlung von Arbeitslasten und deren Einreichungsplan als Eingabe verwendet und es dem Planer ermöglicht, Entscheidungen bezüglich der Übernahme und der GPU-Zuweisung zu treffen. Mit Kenntnis der erforderlichen Anzahl an GPUs und des Gesamtbetriebszeitraums jeder Arbeitslast kann der Simulator auf die skalierbaren Momente zugreifen und in wenigen Sekunden eine Analyse der Wartezeiten in der Warteschlange, der Übernahmeereignisse sowie der Verteilung der GPU-Betriebszeit über die Projekte über mehrere simulierte Tage liefern. Wir führten den Simulator gegen beide historische Einsendedaten durch und erstellten Szenarien, um sie besser verstehen zu können.

Eine Hypothese, die wir testen wollten, betraf „Debug-Workloads“. Diese Aufgaben erfordern eine kleine Anzahl an GPUs und eine Mindestlaufzeit von 15 Minuten oder weniger – das reicht aus, damit der Benutzer sehen kann, ob eine Aufgabe erfolgreich startet oder wegen eines Bugs oder einer falschen Konfiguration frühzeitig kollabiert. Wir wollten wissen, ob diese Aufgaben eine kürzere Wartezeit in der Warteschlange haben als größere Trainingsaufgaben, die oft viele GPUs und Stunden Laufzeit benötigen, um bedeutenden Fortschritt zu erzielen. Intuitiv sollten diese kleineren Aufgaben an die Spitze der Warteschlange kommen, da eine kleine Aufgabe mehr Platz bietet als eine große. Doch die genaue Wartelast der Warteschlange war wichtig. Eine kurze Wartezeit von einer oder zwei Minuten würde eine neue Entwicklungspraxis ermöglichen, aber eine zehnminütige Wartezeit wird unpraktisch sein.

Unsere Simulationsen erforderten handgefertigte Testfalldaten, da unser historisches Datensatz nicht eine ausreichende Menge dieser debugartigen Arbeitslasten enthielt. Unsere Ergebnisse unterstützten die Hypothese, indem sie zeigten, dass die Wartezeiten für die p90-Debug-Arbeitslast von etwa 6 Stunden auf nur 5 Minuten abnahmen.

Visualisierung eines Simulators in kleinerer Skala der Grundausstattung (links) und des neuen „Allokations“-Scheduler (rechts). Jede Spalte entspricht einer GPU; jede Strecke stellt eine Aufgabe dar, die durch das Elternarbeitsvolumen farbig markiert ist – jeweils ein Farbton pro Team. Die Ausstriche zeigen die Zeiten, in denen eine Aufgabe unterbrochen werden kann, und der rote Rand markiert eine Überlagerung. Bei der Grundausstattung werden lange dringende Aufgaben nie unterbrochen, und es kommen weniger Überlagerungen bei Arbeiten niedrigeren Prioritätsniveaus. Der neue Scheduler zeigt eine größere Vielfalt an Farben auf jeder GPU, was die Rotation der Besetzung zwischen den Teams verdeutlicht.

Ergebnisse

Mit den Simulationsergebnissen in der Hand begannen wir Ende Juli die Ausrollung pro Cluster. Die Ergebnisse, die uns wichtig sind, sind: ob die ausgewählten Arbeitslasten ihre Zeit erhielten, ob das neue System eine volle Auslastung aufwies und ob die Forscher in der Lage waren, über den Schalter zu denken, um fundierte Entscheidungen zu treffen.

Seit der Einführung haben wir beobachtet, dass Benutzer und Teams stets die ihnen zugewiesene GPU-Zeit erhalten. Die Zeit, die einem Team zusteht, wird Stunde für Stunde entsprechend dem tatsächlichen Bedarf begrenzt. Während des 30-tägigen Testzeitraums erhielten die Teams 98% der GPU-Stunden, die ihnen zustanden, und 13 von 15 Team-Zuweisen erreichten 95% oder mehr – im schlimmsten Fall 90%. Die Nutzung des Clusters blieb vor und nach dem Wandel bei 98%, während das Bedürfnis in beiden Phasen um 2-3x die Kapazität überstieg. 18 % der gelieferten GPU-Zeit waren nicht verwendet, wodurch wir während der Zeit, in der die finanzierten Anwendungsfälle noch nicht funktionierten, eine hohe Nutzung erreichen konnten.

Unsere Simulator-Ergebnisse zeigten eine richtungsgenaue Zuordnung, wobei die tatsächlichen Ergebnisse die unseren vorhergesehenen Erwartungen übertrafen. Die Wartezeit in der p90-Kette für die Fehlerbehebungslasten sank unter dem neuen Scheduler von 2 Stunden auf 30 Sekunden, während die simulierte Vorhersage für die handgefertigten Testszenarien 6 Stunden bis 5 Minuten betrug. Es ist erwähnenswert, dass die kleinere Stichprobengröße der Fehlerbehebungslasten im Baseline-Bereich zu einer höheren Variabilität dieser Messungen führte. Die Latenzzeit der Warteschlange verbesserte sich im Allgemeinen als Nebeneffekt des Zeit-Slicing: Auf unserem größten H100-Cluster sank die mittlere Warteschlange-Zeit von 5 Minuten auf 24 Sekunden, und die p90-Warteschlange-Zeit verringerte sich um etwa ein Drittel (von 2,8 Stunden auf 1,8 Stunden).

Im Vergleich zu den drei Problemen, die wir lösen wollten:

1. Quatschen: Kurze Debug-Arbeitslasten beginnen innerhalb einer Minute, was den Wert des Quatschens verringert. Der Preis für dieses Verhalten belastet das Budget des Quatschers, wodurch er keine Zeit bekommt, die er wirklich benötigt.

2. Prioritätsinflation: Wir erlauben weiterhin, dass Arbeitslasten eine Priorität angeben können, aber dies hat nur Auswirkungen auf die Sortierung innerhalb eines Teams. Manager werden ermutigt, die Prioritäten im gesamten Team zu überwachen, um den Einsatz ihrer Budgets optimal zu gestalten.

3. On-call Arbeit: Ungesunde Hosts werden automatisch entlastet, sobald die Arbeitslast den minimalen Betriebszeitraum erreicht. Die Reparaturen, die eine menschliche Einmischung erfordern, sind um 74% zurückgegangen.

Herausforderungen

Die Lernkurve war steiler als wir angenommen hatten. Wir setzten die Änderung schrittweise um, sodass in den Anfangsphasen die Forscher unterschiedliches Verhalten zeigten, je nachdem, welches Cluster sie angriffen. Zudem behielten unsere Interfaces einige alte Begriffe bei (wie „Arbeitslastpriorität“), deren Bedeutung sich geändert hatte. Die Dokumentation allein konnte die Verwirrung nicht lösen. Was wirklich funktionierte, war das Führen von Live-Erklärungssitzungen, eine Plattform für Forscher, um Fragen zu stellen, und für das Engineering-Team, um tiefere Beschreibungen dazu zu geben, wie und warum der Scheduler seine Priorisierungsentscheidungen trifft, mit realen Beispielen.

Dies war ein wichtiger Moment, da er einen Wendepunkt darstellte – von einer frühen Phase der Frustration und folkloristischer Theorien hin zu dem aktuellen Modus, in dem Forschungsteams häufiger und umfassender über die GPU-Anforderungen ihrer Experimente sprechen. Die Forscher nehmen nun an der Budgetplanung teil, mit klareren Kenntnissen über die Kompromisse, die getroffen werden müssen, um neue Anforderungen zu erfüllen.

Neben den persönlichen Sitzungen haben wir nach der Veröffentlichung neue Visualisierungen eingeführt, um den Benutzern eine bessere Vorstellung davon zu geben, wie genau die ihnen zugewiesene GPU-Zeit ihren erwarteten Allokationen entspricht und die für die Sortierung der Arbeitslast-Warteschlange verwendete Metrik direkt aufzeigt. Dies bietet eine einfache Möglichkeit, um zu verstehen, warum eine Arbeitslast unterbrochen wird. Diese Visualisierungen haben auch den Budgetverantwortlichen geholfen, indem sie zeigten, wie die GPU-Zeit in verschiedenen Projekten unter ihrer Verwaltung genutzt wird.

Beispielhaftes Visualisieren der Verwendung der Allokationen im Laufe der Zeit.

Nicht jeder Einsatzfall wurde verbessert. Neben der verteilten Trainierung starten unsere Forscher interaktive Sitzungen, in denen sie Datenanalyse durchführen und das Trainingscode während des Schreibens testen. Im alten System konnte ein Forscher eine solche Sitzung bis zu eine Woche lang halten. Durch die Zeit-Slicing-Konfiguration waren sie jedoch an die 8-Stunden-Grenze für den geschützten Laufzeitbereich gebunden, danach wird eine Sitzung preemptiv, wenn sie ihre Zuweisung überschreitet. Wir haben nicht erkannt, in welchem Ausmaß die Forscher von dem instabilen Zustand dieser Sitzungen abhängig waren. Das Überholen bedeutete, zu warten, bis eine neue Sitzung eingerichtet wurde, und auch ihren Zustand manuell neu aufzubauen. Nachdem wir die Forscher befragt hatten, um das Ausmaß dieses Problems zu verstehen, haben wir zwei neue Roadmap-Projekte entwickelt. Wir investieren in einen Cluster mit nur CPU, neben unserem On-Prem-Storage für Entwicklungssitzungen, die sich auf Datenvorbereitungsaufgaben konzentrieren. Dies wird die Kapazität unseres Trainingsclusters für Arbeitslasten erhalten, die sie wirklich benötigen. Darüber hinaus planen wir, wiederherstellbare Sitzungen für diese CPU-basierten Arbeitslasten zu erstellen. Dadurch können wir die Arbeitslasten am Ende ihres minimalen Laufzeitraums für Wartung oder Zeitsegmentierung vorab übernehmen, und gleichzeitig die Sitzung an einem anderen Ort wiederherstellen, ohne dass der Forscher sie neu erstellen muss. Wir können die Betriebs- und Planungsvorteile dieses neuen Systems beibehalten und gleichzeitig die Benutzerfreundlichkeit verbessern.

Wir bleiben auf der Suche nach neuen Problemen. Ein potenzielles Problem, das wir untersuchen, ist die Fragmentierung der Kapazität, was dazu führen kann, dass die Wartezeiten in der Warteschlange für die größten Arbeitslasten zunehmen. Unsere Intuition besagt, dass eine Schutzmaßnahme gegen den minimalen Laufzeitbedarf angewandt wird auf Arten von Aufgaben, die früher auf auslösbare Mechanismen angewiesen waren, um das Konkurrenzlimit der GPU-GPUs zu überwinden. Früher konnten diese Aufgaben jederzeit unterbrochen werden, was Zeit verschwendete und gleichzeitig es ermöglichte, große Aufgaben besser zu planen. Jetzt hat der Planer möglicherweise weniger Möglichkeiten, viele Aufgaben gleichzeitig zu unterbrechen, um eine große ausstehende Arbeitslast zu platzieren. Wir verwenden derzeit unsere Simulatorwerkzeuge, um dieses Problem nachzuahmen, und messen gleichzeitig die Realität in der Produktion.

Die Zukunft

Wenn wir über die hier beschriebene Planung hinaus blicken, zielen wir auf das Zielpunkt der Pyramide: die Nutzung ab. Wir müssen sicherstellen, dass das Bootstrapping, das Checkpointing und die Trainingsanwendungen selbst so effizient wie möglich durchgeführt werden, um den Wert des eingeplanten Zeitraums für jede Arbeitslast maximal auszuschöpfen.

Wenn Sie solche Herausforderungen in enger Zusammenarbeit mit Forschern angehen möchten, empfehlen wir Ihnen, offene Ingenieurrollen bei Ai2 zu erkunden.