Was sind GPU-Quotas, -Reservierungen, -Prioritäten und -Preemption, und wann sollte man welche einsetzen?

GPU-Quotas, -Reservierungen, -Prioritäten und -Preemption lösen vier unterschiedliche Scheduling-Probleme. Quotas begrenzen, wie viel ein Tenant oder Projekt verbrauchen kann. Reservierungen schützen Kapazität für geplante Arbeit. Prioritäten entscheiden, welcher Workload zuerst knappe Kapazität erhalten soll. Preemption erlaubt einem Workload mit höherer Priorität, Ressourcen von Arbeit mit niedrigerer Priorität zurückzufordern, wenn die Richtlinie es erlaubt.

Das Quellen-Scheduling-Modell unterstützt Tenant-Quotas, Task-Queues, Priorität, Preemption, Checkpoint-Schutz, Resource Reclamation und sichtbare Queue-Gründe. Das wichtige Betriebsprinzip ist, diese Kontrollen gemeinsam zu nutzen, statt zu erwarten, dass ein einzelner Mechanismus jedes Kapazitätsproblem löst.

Was ist eine GPU-Quota?

Eine GPU-Quota legt die Ressourcengrenze für einen Tenant, ein Projekt oder einen anderen genehmigten Eigentümerbereich fest.

Das Quellen-Scheduling-Design beschreibt Tenant-Quotas als harte Beschränkung, die einen ungeordneten Wettbewerb um teure Beschleuniger-Ressourcen verhindert.

Das Quellen-Q&A besagt außerdem, dass Quotas anhand mehrerer Dimensionen definiert werden können, darunter:

GPU-Anzahl
Beschleuniger-Speicher
CPU und Speicher
Gleichzeitige Tasks
Monatliche Beschleuniger-Kartenstunden

Das genaue Quota-Modell hängt von der Managementrichtlinie der Organisation ab.

Eine Quota ist nützlich, wenn sich mehrere Teams einen Infrastruktur-Pool teilen und die Plattform verhindern muss, dass ein Team die gesamte verfügbare Kapazität verbraucht.

Sie ist auch für die Budgetkontrolle nützlich.

Ein Projekt darf technisch vielleicht auf dem gemeinsam genutzten Cluster laufen, ist aber auf eine definierte Kapazitätsmenge oder einen monatlichen Verbrauch begrenzt.

Wann sollten GPU-Quotas eingesetzt werden?

Nutzen Sie Quotas, wenn Sie eine harte Grenze zwischen Tenants, Projekten oder Teams brauchen.

Typische Situationen umfassen:

Mehrere Abteilungen teilen sich einen GPU-Cluster.

Externe oder interne Tenants brauchen isolierte Ressourcengrenzen.

Projekte haben genehmigte Kapazitätsbudgets.

Ein Entwicklungsteam sollte nicht ohne Genehmigung Produktionskapazität verbrauchen.

Die monatliche Beschleuniger-Nutzung muss innerhalb eines genehmigten Budgets bleiben.

Quotas sind auch hilfreich, wenn die Nachfrage unvorhersehbar ist.

Ohne Grenze kann ein Schwall eingereichter Jobs aus einem Projekt die Queue füllen und den gesamten Resource Pool verbrauchen.

Das Quellenmodell setzt die Quota-Validierung daher vor das Queue-Scheduling.

Ein Task muss zuerst berechtigt sein, die Ressource anzufordern.

Erst dann sollten Priorität und Scheduling-Richtlinie entscheiden, wann er die Ressource erhält.

Was ist eine GPU-Reservierung?

Eine Reservierung schützt Kapazität für einen geplanten Workload, ein Projekt, einen Dienst oder ein Zeitfenster.

Die Quellenmaterialien unterscheiden in der Planung ausdrücklich zwischen reservierter und freier, deploybarer Kapazität, schreiben aber kein universelles Reservierungsprodukt oder keinen universellen Algorithmus vor.

Operativ bedeutet eine Reservierung, dass Kapazität zugesagt wird, bevor sie aktiv verbraucht wird.

Zum Beispiel:

Ein kritisches Trainingsprojekt braucht morgen Nacht 32 GPUs.

Ein Produktions-Inferenzdienst braucht garantierten Spielraum für Spitzenlast.

Ein Hardware-Validierungsprogramm benötigt während eines Wartungsfensters eine bestimmte Beschleuniger-Klasse.

Die reservierte Kapazität sollte für andere Workloads nicht als generell frei erscheinen, wenn ihre Nutzung die Zusage gefährden würde.

Das unterscheidet Reservierung von Quota.

Quota sagt: "Sie dürfen bis zu diesem Betrag verbrauchen."

Reservierung sagt: "Dieser Betrag wird für diesen genehmigten Zweck zurückgehalten."

Wann sollten Reservierungen eingesetzt werden?

Nutzen Sie Reservierungen, wenn die Kosten dafür, zum benötigten Zeitpunkt keine Kapazität zu haben, hoch sind.

Reservierungen sind sinnvoll für:

Geplante Trainingsläufe
Kritische Produktions-Inferenz
Bekannte Geschäftsereignisse
Migrationsfenster
Große Modellevaluierung
Hardware-Validierung
Für einen Kunden oder Tenant zugesagte Kapazität

Reservieren Sie Kapazität nicht unnötig.

Reservierte, aber ungenutzte GPUs können zu teurer Leerlaufkapazität werden.

Das Operations-Dashboard sollte reservierte Kapazität daher getrennt anzeigen von:

Installierter Kapazität
Allokierter Kapazität
Freier Kapazität
Deploybarer Kapazität

Das macht bewussten Schutz sichtbar, statt jede reservierte Karte fälschlich als Verschwendung einzustufen.

Was ist GPU-Priorität?

Priorität bestimmt die Reihenfolge, in der konkurrierende Workloads für die Ressourcenzuweisung berücksichtigt werden sollen.

Das Quellen-Scheduling-Modell unterstützt Task-Queues mit Priorität und macht Queue-Gründe sichtbar.

Ein Job mit höherer Priorität kann einem Job mit niedrigerer Priorität vorgezogen werden, wenn beide auf dieselbe begrenzte Ressource warten.

Priorität ist nützlich, weil nicht jeder Workload dieselbe geschäftliche Bedeutung hat.

Beispiele:

Produktions-Inferenz kann höhere Priorität haben als experimentelles Fine-Tuning.

Ein kundenseitiger Recovery-Task kann höhere Priorität haben als ein Entwicklungs-Benchmark.

Ein terminkritischer Trainings-Job kann höhere Priorität haben als ein Hintergrund-Batch-Job.

Priorität unterbricht nicht zwangsläufig bereits laufende Arbeit.

Das ist der Unterschied zwischen Priorität und Preemption.

Wann sollte Priorität ohne Preemption eingesetzt werden?

Nutzen Sie Priorität allein, wenn die Warte-Reihenfolge wichtig ist, eine Unterbrechung aber zu riskant oder zu teuer wäre.

Das ist bei lang laufenden Trainings-Tasks üblich.

Angenommen, zwei Jobs brauchen dieselbe Beschleuniger-Klasse.

Job A läuft bereits.

Job B trifft mit höherer geschäftlicher Priorität ein.

Wenn Job A nicht sicher checkpointen kann, kann eine Unterbrechung viele Stunden Compute verlieren.

Eine reine Prioritätsrichtlinie kann Job A fertig laufen lassen, während Job B vor anderer wartender Arbeit platziert wird.

Das gibt der Organisation eine geschäftsbewusste Queue, ohne unnötigen Trainingsverlust zu erzeugen.

Das Quellen-Scheduling-Design merkt ausdrücklich an, dass Preemption mit hoher Priorität gegen den Schutz laufender Tasks abgewogen werden muss.

Deshalb sollten Priorität und Preemption getrennte Kontrollen sein.

Was ist GPU-Preemption?

Preemption erlaubt dem Scheduler, Ressourcen von einem laufenden Workload zurückzufordern, damit ein anderer Workload sie nutzen kann.

Das Quellen-Scheduling-Modell unterstützt Preemption mit hoher Priorität und verknüpft sie mit Checkpoint-Schutz und geordneter Task-Wiederherstellung.

Preemption ist nützlich, wenn Kapazität knapp ist und manche Workloads ausdrücklich unterbrochen werden dürfen.

Zum Beispiel:

Ein Batch-Trainings-Task mit niedriger Priorität läuft.

Ein Incident-Recovery-Workload mit hoher Priorität trifft ein.

Der Task mit niedrigerer Priorität unterstützt Checkpointing.

Die Plattform speichert oder nutzt den neuesten Checkpoint, stoppt den Task mit niedrigerer Priorität, gibt die GPUs frei und weist sie dem Task mit höherer Priorität zu.

Später kann der unterbrochene Task fortgesetzt werden.

Preemption hängt daher stark von der Wiederherstellbarkeit des Workloads ab.

Wann sollte GPU-Preemption eingesetzt werden?

Nutzen Sie Preemption, wenn alle drei Bedingungen zutreffen.

Erstens: Der Workload mit höherer Priorität hat einen triftigen Grund, früher zu starten.

Zweitens: Der Workload mit niedrigerer Priorität ist für eine Unterbrechung genehmigt.

Drittens: Die unterbrochene Arbeit lässt sich gut genug schützen, dass die Kosten akzeptabel sind.

Gute Kandidaten sind unter anderem:

Unterbrechbare Batch-Jobs
Jobs mit häufigen Checkpoints
Entwicklungs-Workloads
Niedrigere Service-Stufen
Flexible Hintergrundverarbeitung

Das Quellen-Design empfiehlt ausdrücklich, zwischen preemptierbaren und nicht preemptierbaren Tasks zu unterscheiden.

Diese Unterscheidung sollte Teil der Richtlinie für die Workload-Einreichung sein.

Entscheiden Sie das nicht zum ersten Mal während eines Incidents.

Wann sollte Preemption vermieden werden?

Vermeiden oder beschränken Sie Preemption stark bei Workloads, bei denen eine Unterbrechung unverhältnismäßigen Verlust erzeugt.

Beispiele sind unter anderem:

Lang laufendes Training ohne gültigen Checkpoint
Kritische Produktions-Inferenz ohne Redundanz
Zustandsbehaftete Workloads, die nicht sicher neu starten können
Jobs, bei denen eine Neuplanung eine genehmigte experimentelle Bedingung verändert
Tasks mit externen Abhängigkeiten, die sich nicht rekonstruieren lassen

Das Quellen-Q&A warnt, dass Preemption mit hoher Priorität Trainingsverlust verursachen kann, und empfiehlt Checkpoint- und Mechanismen zur geordneten Beendigung.

Die zentrale Lektion ist, dass hohe Priorität nicht automatisch bedeutet, dass Preemption sicher ist.

Priorität drückt Bedeutung aus.

Preemptierbarkeit drückt Wiederherstellbarkeit und Richtlinie aus.

Beides wird gebraucht.

Wie arbeiten Quotas und Prioritäten zusammen?

Quota entscheidet, ob der Workload berechtigt ist, die Ressource anzufordern.

Priorität entscheidet über seinen Platz unter den berechtigten Workloads.

Beispiel:

Projekt-A-Quota: 16 GPUs.

Projekt-B-Quota: 16 GPUs.

Projekt A nutzt bereits alle 16.

Ein neuer Projekt-A-Job fordert 8 weitere an.

Der Job kann abgelehnt oder in die Queue gestellt werden, weil die Projekt-Quota ausgeschöpft ist.

Seine Priorität hebelt die Quota nicht aus, sofern die Organisation nicht ausdrücklich eine solche Richtlinie definiert.

Stellen Sie sich nun vor, beide Projekte liegen innerhalb ihrer Quota und warten auf dieselbe GPU-Klasse.

Priorität kann bestimmen, welcher Job zuerst bedient wird.

Diese Kontrollen getrennt zu halten macht Scheduling erklärbar.

Wie arbeiten Reservierungen und Quotas zusammen?

Reservierungen schützen eine bekannte Menge zukünftiger oder garantierter Kapazität, während Quotas den Gesamtverbrauch begrenzen.

Ein Projekt kann beides haben.

Beispiel:

Projekt-A-Quota: 64 GPUs.

Projekt-A-Reservierung für heute Nacht: 32 GPUs.

Das Projekt darf laut Richtlinie bis zu 64 verbrauchen, aber 32 sind speziell für den geplanten Lauf geschützt.

Die Quellenmaterialien definieren keine universelle Regel für das Zusammenspiel zwischen Reservierung und Quota.

Diese Beziehung sollte daher in der unternehmensweiten Scheduling-Richtlinie festgelegt werden.

Die wichtige operative Anforderung ist, dass Reservierungen sichtbar bleiben, damit vermeintlich freie Kapazität nicht doppelt zugesagt wird.

Wie arbeiten Reservierungen und Prioritäten zusammen?

Eine Reservierung sollte die zugesagte Ressource normalerweise unabhängig von der gewöhnlichen Queue-Priorität schützen.

Andernfalls ist die Reservierung keine echte Garantie.

Unternehmen können jedoch Notfall-Override-Richtlinien definieren.

Die Quellenmaterialien schreiben kein solches Override-Modell vor.

Das sicherere, quellenbasierte Design besteht darin, die Richtlinie explizit und auditierbar zu machen.

Wenn ein reservierter Pool überschrieben wird, sollte die Plattform Folgendes protokollieren:

Wer es autorisiert hat
Welcher Workload die Kapazität genutzt hat
Welche Reservierung betroffen war
Welches Servicerisiko akzeptiert wurde

Das ist besonders wichtig, wenn die Reservierung zu einer Zusage an einen anderen Tenant oder Kunden gehört.

Wie verändert Checkpointing die Preemption-Richtlinie?

Checkpointing reduziert die Kosten einer Unterbrechung.

Der Quellen-Scheduler umfasst Checkpoint-Schutz, Fehlerisolation und Fortsetzung ab Checkpoint.

Ein Workload mit einem aktuellen Checkpoint kann seine Ressourcen mit weniger verlorener Arbeit freigeben.

Das macht ihn zu einem besseren Preemption-Kandidaten.

Ein Workload, dessen letzter Checkpoint sechs Stunden alt ist, ist deutlich teurer zu unterbrechen.

Die Scheduling-Richtlinie kann daher zusätzlich zur statischen Priorität den Checkpoint-Status berücksichtigen.

Die Quelle definiert keinen spezifischen Scoring-Algorithmus.

Das unterstützte Prinzip ist, dass der Schutz laufender Tasks und die Checkpoint-Fähigkeit Preemption-Entscheidungen beeinflussen sollten.

Für Failure Recovery erklärt wie KI-Infrastruktur Trainings-Jobs nach einem GPU- oder Server-Ausfall automatisch wiederherstellen kann denselben Checkpoint-Mechanismus von der Resilienz-Seite aus.

Wie sollten Queue-Gründe angezeigt werden?

Das Quellen-Design besagt, dass Queue-Gründe einzeln sichtbar sein sollten.

Das ist essenziell, wenn Quotas, Reservierungen, Prioritäten und Fragmentierung gleichzeitig bestehen.

Ein Job kann warten, weil:

Quota ausgeschöpft
Passender GPU-Typ nicht verfügbar
Reservierte Kapazität für dieses Projekt nicht verfügbar
Arbeit mit höherer Priorität vorgereiht ist
Erforderliche Topologie nicht verfügbar
Gesunde Kapazität nicht ausreicht
Ressourcenfragmentierung die Platzierung verhindert

Der Nutzer sollte den tatsächlichen Grund sehen.

Andernfalls kann dieselbe Queue wie ein Kapazitätsproblem aussehen, obwohl es eigentlich ein Richtlinienproblem ist.

Wie beeinflussen Health-Checks diese Richtlinien?

Die Quellen-Scheduling-Architektur bezieht Health auf Kartenebene als Eingabe für die Ressourcenzuweisung mit ein.

Das bedeutet, dass sich Quota- und Reservierungszahlen auf nutzbare, gesunde Ressourcen beziehen sollten, nicht nur auf installierte Karten.

Wenn ein Tenant eine Reservierung für acht GPUs hat, aber eine reservierte Karte degradiert, muss die Plattform das Defizit erkennen und, wo die Richtlinie es erlaubt, geeignete Ersatzkapazität finden.

Eine degradierte Karte sollte nicht schedulebar bleiben, nur weil eine Reservierung sie erwartet.

Health-Aware-Scheduling macht die Zusagen realistischer.

Für das Modell auf Kartenebene erklärt wie Unternehmen GPU-Health, ECC-Fehler, Temperatur, Stromverbrauch und degradierte Beschleuniger-Karten überwachen können, wie der Health-Status das Scheduling beeinflussen sollte.

Wie sollten Unternehmen zwischen den vier Kontrollen wählen?

Nutzen Sie die Kontrolle, die zum Problem passt.

Nutzen Sie Quota für Berechtigungs- und Verbrauchsgrenzen.

Nutzen Sie Reservierung für garantierte oder geplante Kapazität.

Nutzen Sie Priorität für die Warte-Reihenfolge.

Nutzen Sie Preemption für kontrollierte Unterbrechung, wenn dringende Arbeit Kapazität zurückfordern muss.

Nutzen Sie Priorität nicht als Ersatz für Quota.

Nutzen Sie Reservierungen nicht für jeden Workload.

Aktivieren Sie Preemption nicht ohne einen Recovery-Plan.

Gehen Sie nicht davon aus, dass eine große Quota sofortige Kapazität garantiert.

Ein Plattformbeispiel, das Tenant-Quotas, Priorität, Preemption, Health-Aware-Scheduling und Resource Recovery kombiniert, ist Sensaka.

Wenn ich die Scheduling-Richtlinie definieren würde, würde ich jeden eingereichten Workload vier Dinge deklarieren lassen: wem er gehört, welche Quota gilt, welche Priorität er hat und ob er sicher preemptiert werden kann. Reservierungen können dann für Workloads hinzugefügt werden, die zu einem bestimmten Zeitpunkt garantierte Kapazität brauchen. Das ergibt ein Scheduling-Modell, das Nutzer verstehen und das Operations-Teams auditieren können.