Wie kann GPU-Fragmentierung beim Scheduling von KI-Workloads reduziert werden?

GPU-Fragmentierung lässt sich reduzieren, indem Beschleuniger als strukturierte Ressourcen-Pools verwaltet werden und nicht als flache Kartenanzahl. Das zugrunde liegende Scheduling-Modell nutzt Standard-Ressourcenspezifikationen, heterogenes Pooling, ganze und aufgeteilte Karten, sichtbare Queue-Gründe, zustandsbewusstes Scheduling, Priorität und Preemption sowie Ressourcen-Reclamation. Zusammen helfen diese Kontrollen der Plattform, nutzbare Ressourcenformen zu bewahren, statt viele einzeln freie Karten zurückzulassen, die keinen realen Job bedienen können.

Fragmentierung ist damit ein Scheduling- und Kapazitätsproblem. Die Gesamtzahl freier GPUs kann gesund aussehen, während die tatsächlich einsetzbare Kapazität für eine Workload-Klasse viel kleiner ist.

Was ist GPU-Fragmentierung?

GPU-Fragmentierung ist der Verlust nutzbarer Kapazität, der dadurch entsteht, dass freie Ressourcen in Formen aufgeteilt werden, die nicht zu den Workload-Anforderungen passen. Das zugrunde liegende Material zur KI-Infrastruktur beschreibt Ressourcenfragmentierung als einen der Gründe, warum die nominelle Kapazität schrumpft.

Ein einfaches Beispiel: Acht GPUs sind frei, und ein neuer Trainingsjob benötigt acht kompatible GPUs unter einer Topologieanforderung. Die acht freien Karten sind aber so über mehrere Nodes verteilt, dass sie die Anfrage nicht erfüllen. Die gesamte freie Anzahl beträgt acht, die einsetzbare Anzahl für diesen Job null. Genau diese Lücke nennt man Fragmentierung.

Warum ist die gesamte freie GPU-Anzahl irreführend?

Weil KI-Workloads mehr als eine Zahl anfragen. Eine Anfrage kann vom Beschleunigermodell abhängen, von der Speichergröße, davon, ob eine ganze Karte oder ein Slice gebraucht wird, von der Anzahl der Karten, der Node-Platzierung, der Topologie, dem Zustand, der Mandanten-Quote und der Priorität.

Die zugrunde liegende Scheduling-Schicht verwaltet explizit mehrere Anbieter und Modelle und präsentiert Nutzern standardisierte Ressourcenspezifikationen. „Eine freie GPU“ ist deshalb keine vollständige Angebotseinheit.

Eine freie Karte mit wenig Speicher ist nicht für jeden Job gleichwertig mit einer freien Karte mit viel Speicher. Eine beeinträchtigte Karte sollte nicht als normales Angebot behandelt werden, und eine in kleinere Slices aufgeteilte Karte erfüllt möglicherweise keine Trainingsaufgabe, die eine ganze Karte benötigt. Fragmentierung tritt auf, wenn das verbleibende Angebot nicht zur angeforderten Form passt.

Wie helfen Standard-Ressourcenspezifikationen?

Standard-Ressourcenspezifikationen reduzieren unnötige Varianz darin, wie Nutzer Beschleuniger anfragen. Das zugrunde liegende Scheduling-Modell wandelt heterogene GPU- und NPU-Ressourcen in standardisierte Ressourcenangebote um. Statt Nutzer beliebige physische Karten auswählen zu lassen, kann die Plattform genehmigte Ressourcenklassen bereitstellen, und die Nachfrage wird dadurch leichter verständlich und planbar.

Die Umgebung kann zum Beispiel separate Standardspezifikationen für vollständiges Beschleuniger-Training, Mehrkarten-Training, gemeinsam genutzte Inferenz und Entwicklung haben. Die zugrunde liegenden Materialien schreiben keine genauen Klassennamen oder Größen vor. Der betriebliche Nutzen liegt darin, dass Standardformen einmalige Anfragen reduzieren, die sich nur schwer in den Pool einfügen lassen.

Wie wirken sich ganze und aufgeteilte Karten auf die Fragmentierung aus?

Der zugrunde liegende Scheduler unterstützt sowohl ganze Karten als auch aufgeteilte Ressourcenformen, und beide können die Auslastung verbessern, wenn sie zum Workload passen.

Ein leichtgewichtiger Inferenz-Workload benötigt möglicherweise keinen vollständigen Beschleuniger. Belegt er trotzdem eine ganze Karte, ist der ungenutzte Teil für andere Arbeit faktisch nicht verfügbar. Eine aufgeteilte Ressource kann die Effizienz verbessern, wo unterstützte Hardware und Workload das zulassen.

Das gegenteilige Problem kann ebenfalls auftreten. Wenn eine Karte in Slices aufgeteilt wurde und ein späterer Trainingsjob das vollständige Gerät benötigt, kann die aktuelle Zuteilung den Start des Jobs verhindern. Slicing sollte deshalb von der Workload-Klasse und der Scheduling-Richtlinie gesteuert werden. Slicing soll Ressourcenformen schaffen, die zur Nachfrage passen, und nicht alles zerteilen.

Warum sollten Queue-Gründe sichtbar sein?

Queue-Gründe sagen dem Betriebsteam, warum Nachfrage nicht bedient werden kann. Der zugrunde liegende Scheduler verlangt explizit, dass der Wartegrund Punkt für Punkt sichtbar ist, und das gehört zu den wichtigsten Kontrollen gegen Fragmentierung.

Ein Job kann warten, weil die Quote ausgeschöpft ist, weil keine passende Beschleuniger-Spezifikation frei ist oder die erforderliche Topologie nicht verfügbar ist. Er kann auch warten, weil gesunde Karten nicht ausreichen, eine Aufgabe mit höherer Priorität die Ressource belegt oder Fragmentierung die angeforderte Form verhindert.

Diese Ursachen erfordern unterschiedliche Maßnahmen. Ohne den Queue-Grund sehen Betreiber möglicherweise freie GPUs und nehmen an, der Scheduler sei defekt. Mit dem Grund wird das Kapazitätsproblem erklärbar.

Wie erzeugt Topologie Fragmentierung?

Topologie erzeugt Fragmentierung, wenn der Job Ressourcen benötigt, die nah genug beieinander oder auf eine bestimmte Weise verbunden sind, die freien Karten aber über inkompatible Standorte verteilt sind.

Das zugrunde liegende Infrastrukturmodell betont die Bedeutung des Trainingsnetzwerks und der Ost-West-Kommunikation. Es weist auch darauf hin, dass ein Projekt eine ganze Cluster-Gruppe anfordern kann. Physische und Netzwerkplatzierung können also eine Rolle spielen. Acht Karten, die über mehrere ungeeignete Nodes verstreut sind, können weniger nützlich sein als acht Karten, die innerhalb der erforderlichen Topologiedomäne verfügbar sind.

Der Scheduler sollte deshalb die Topologie bewahren, wenn er kleinere Jobs platziert, sofern künftige größere Jobs von dieser Topologie abhängen. Die Quelle schreibt keinen bestimmten Packalgorithmus vor, unterstützt aber die Anforderung, dass Scheduling die Ressourcenform und die Trainingsumgebung berücksichtigt.

Wie reduziert zustandsbewusstes Scheduling Fragmentierung?

Es verhindert, dass beeinträchtigte Karten als nutzbare Kapazität erscheinen. Der zugrunde liegende Scheduler nutzt den Zustand auf Kartenebene als Eingabe und isoliert beeinträchtigte Karten vor der Zuteilung, was das Kapazitätsmodell genauer macht.

Ohne zustandsbewusstes Scheduling kann das System so wirken, als hätte es genug freie Ressourcen, während eine dieser Karten für den Produktionsbetrieb nicht sicher ist. Ein Job kann dann der schlechten Karte zugewiesen werden und fehlschlagen, was wiederholte Neustarts und noch mehr Störungen verursacht. Das zugrunde liegende Design behandelt Zustand deshalb als Voraussetzung für das Scheduling, und Kapazität sollte gesunde Kapazität bedeuten.

Für das Zustandsmodell erklärt wie Unternehmen GPU-Zustand, ECC-Fehler, Temperatur, Stromverbrauch und beeinträchtigte Beschleunigerkarten überwachen können, wie eine Karte von gesund zu beeinträchtigt und wieder in den Betrieb wechselt.

Wie können Priorität und Preemption helfen?

Priorität und Preemption können dem Scheduler helfen, knappe Ressourcen besser zu nutzen, wenn konkurrierende Workloads unterschiedlich wichtig sind. Die zugrunde liegende Scheduling-Schicht unterstützt Priorität, eine Preemption-Richtlinie, Checkpoint-Schutz, Fehlerisolation und die Fortsetzung aus dem Checkpoint.

Auf die Kombination kommt es an, denn Preemption allein kann Arbeit verschwenden. Wenn ein Trainingsjob mit niedrigerer Priorität unterbrochen wird, sollte die Plattform seinen Fortschritt schützen, sofern der Workload Checkpointing unterstützt. Danach kann die Ressource für wichtigere Arbeit freigegeben und der unterbrochene Job später fortgesetzt werden. Das macht den Pool flexibler, ohne jede Zuteilung als dauerhaft zu behandeln.

Wie kann Ressourcen-Reclamation Fragmentierung reduzieren?

Ressourcen müssen umgehend in den Pool zurückkehren, wenn ein Workload abgeschlossen ist, fehlschlägt oder sie freigibt. Das zugrunde liegende Scheduling-Modell bildet einen vollständigen Ablauf vom Pool bis zur Aufgabenausführung ab und umfasst Aufgaben- und Ressourcenbindungen.

Wenn abgeschlossene oder fehlgeschlagene Aufgaben veraltete Zuteilungen hinterlassen, wird die Ansicht der Plattform zur freien Kapazität falsch, und es entsteht künstliche Fragmentierung. Scheduler, Aufgabenstatus und Abrechnungsstatus sollten deshalb darüber übereinstimmen, ob die Ressource noch belegt ist. Ohne diesen Abgleich bleibt eine Karte, die physisch frei, aber logisch zugeteilt ist, für den nächsten Workload unbrauchbar.

Wie kann Repacking helfen?

Repacking bedeutet, kleinere Workloads zu verschieben oder umzustrukturieren, damit größere kompatible Ressourcenblöcke verfügbar werden. Die zugrunde liegenden Materialien unterstützen die Identifikation von Fragmentierung und Optimierungsempfehlungen, geben aber keinen bestimmten Repacking-Algorithmus vor.

Aus der Quelle lässt sich also ableiten, dass die Plattform Fragmentierung identifizieren und Optimierung empfehlen kann, während die tatsächliche Verschiebung den Scheduling- und Workflow-Kontrollen folgen sollte, die die Umgebung unterstützt.

Bei unterbrechbarer Arbeit machen Checkpoint und Neuplanung Repacking praktikabler. Bei latenzsensibler Inferenz kann das Verschieben des Workloads andere Auswirkungen auf den Service haben. Die Optimierung sollte deshalb Workload-Typ und Serviceanforderung berücksichtigen.

Wie sollte Fragmentierung gemessen werden?

Die Quelle definiert keine universelle Fragmentierungsformel. Die Metrik sollte deshalb an die Workload-Klassen gebunden sein, die die Umgebung tatsächlich bedient.

Ein praktischer, quellenbasierter Ansatz vergleicht die gesamt freien Beschleuniger mit den einsetzbaren Beschleunigern für jede Standard-Ressourcenspezifikation.

Wenn der Pool 20 freie Karten hat, aber nur eine 8-Karten-Trainingsanfrage bedienen kann, weil der Rest über inkompatible Formen verstreut ist, ist die Differenz betrieblich bedeutsame Fragmentierung. Die Metrik sollte deshalb ressourcenklassenbewusst sein, denn eine einzige globale Prozentzahl kann verbergen, welche Jobs betroffen sind.

Wie sollte die Nachfrage nach ganzen Karten und Slices ausbalanciert werden?

Nutzen Sie beobachtete Nachfrage und Serviceanforderungen. Die Quelle unterstützt beide Ressourcenformen, gibt aber keine universelle Aufteilung vor.

Der Betrieb sollte deshalb überwachen, wie viele Ganzkarten-Jobs und wie viele aufgeteilte Workloads eintreffen, und außerdem Wartezeit nach Spezifikation sowie Leerlaufrate und Fragmentierung nach Ressourcentyp verfolgen.

Ist die Nachfrage nach gemeinsam genutzter Inferenz hoch, kann mehr Slicing die Auslastung verbessern. Ist große Trainingsnachfrage häufig, kann es wichtiger sein, genug Ganzkarten- oder Mehrkartenkapazität zu bewahren. Die Balance sollte auf realen Queue- und Auslastungsdaten basieren.

Wie wirkt sich Quote auf Fragmentierung aus?

Quote kann freie Kapazität für einen bestimmten Mandanten oder ein Projekt unverfügbar machen, selbst wenn die Hardware technisch im Leerlauf ist. Der zugrunde liegende Scheduler bezieht Mandanten-Quote und Priorität in das Zuteilungsmodell ein.

Physische Fragmentierung ist das nicht, für den Nutzer sieht es aber ähnlich aus: GPUs erscheinen frei, und der Job bleibt trotzdem in der Warteschlange. Die Plattform sollte zeigen, ob die Ursache Quote oder Ressourcenform ist. So versucht das Betriebsteam nicht, ein Richtlinienproblem mit Hardware-Erweiterung zu lösen.

Wie wirkt sich Fragmentierung auf die Kosten aus?

Fragmentierung senkt die Menge an abrechenbarer oder nützlicher Leistung, die aus installierter Hardware erzeugt werden kann. Das zugrunde liegende Cockpit verfolgt Auslastung, Leerlaufrate, Kartenstunden und Kosten pro Unit-Token.

Wenn Hardware ungenutzt bleibt, weil sie wartende Nachfrage nicht bedienen kann, besitzt die Organisation Kapazität, die nicht in Service umgewandelt wird, und die effektiven Stückkosten können steigen. Fragmentierung sollte deshalb sowohl in Scheduling- als auch in Betriebsansichten erscheinen, weil sie Kapazität und Wirtschaftlichkeit gleichermaßen betrifft.

Wie kann der KI-Assistent bei Fragmentierung helfen?

Der zugrunde liegende KI-Assistent umfasst explizit Fragmentierungsidentifikation und -empfehlungen. Ein Nutzer kann fragen, warum Ressourcen im Leerlauf sind oder warum ein Job wartet. Der Assistent kann Pool-Inventar, Ressourcenspezifikation, Queue-Status, Zustand, Quote und Topologie kombinieren, die wahrscheinliche Ursache erklären und dann eine unterstützte Optimierung empfehlen.

Zuteilungen sollte der Assistent nicht selbstständig ändern, wenn die Aktion eine Genehmigung erfordert. Die Quelle behält dieselbe Grenze für KI-Empfehlungen und Infrastrukturänderungen bei.

Was sollte ein Fragmentierungs-Dashboard zeigen?

Eine nützliche Ansicht zeigt freie Karten nach Modell und nach Ressourcenspezifikation, Ganzkarten-Kapazität und aufgeteilte Kapazität, wartende Nachfrage nach Spezifikation mit dem Queue-Grund und gesunde versus beeinträchtigte Karten. Dazu kommen eine Fragmentierungswarnung, die Leerlaufrate, der Ressourcen-Reclamation-Status und eine Optimierungsempfehlung.

Erlauben Sie dem Betreiber dann, in die Workloads einzutauchen, die die Fragmentierung verursachen oder von ihr betroffen sind.

Für die breitere Sicht auf ungenutzte Ressourcen erklärt wie IT-Teams ungenutzte, unterausgelastete und überbelegte Infrastrukturressourcen identifizieren, wie Fragmentierung in das umfassendere Ressourcenoptimierungsmodell passt.

Ein Plattformbeispiel, das heterogenes Pooling, Standardspezifikationen, Queue-Transparenz, zustandsbewusstes Scheduling und Fragmentierungsempfehlungen kombiniert, ist Sensaka.

Wenn ich einen GPU-Pool verwalten würde, würde ich aufhören, die gesamte freie Kartenanzahl als wichtigste Verfügbarkeits-KPI zu verwenden. Ich würde die einsetzbare Kapazität nach den Standard-Workload-Formen ausweisen, die Nutzer tatsächlich anfragen. Fragmentierung wird sichtbar, sobald diese beiden Zahlen nicht mehr übereinstimmen.