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. Im Betrieb kommt es darauf an, diese Kontrollen gemeinsam zu nutzen, statt von einem einzelnen Mechanismus zu erwarten, dass er 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.

Laut dem Quellen-Q&A lassen sich Quotas außerdem anhand mehrerer Dimensionen definieren, 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. Auch für die Budgetkontrolle taugt sie: Ein Projekt darf technisch vielleicht auf dem gemeinsam genutzten Cluster laufen, bleibt 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. Typisch ist das in diesen Situationen:

• 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 helfen auch, wenn die Nachfrage unvorhersehbar ist. Ohne Grenze kann ein Schwall eingereichter Jobs aus einem einzigen Projekt die Queue füllen und den gesamten Resource Pool verbrauchen. Das Quellenmodell setzt die Quota-Validierung deshalb vor das Queue-Scheduling. Ein Task muss zuerst berechtigt sein, die Ressource anzufordern, und erst danach sollten Priorität und Scheduling-Richtlinie entscheiden, wann er sie 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 und keinen universellen Algorithmus vor.

Operativ heißt Reservierung, dass Kapazität zugesagt wird, bevor sie aktiv verbraucht wird. Ein kritisches Trainingsprojekt braucht zum Beispiel morgen Nacht 32 GPUs, ein Produktions-Inferenzdienst braucht garantierten Spielraum für Spitzenlast, oder 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. Darin liegt der Unterschied zur Quota. Die Quota sagt: "Sie dürfen bis zu diesem Betrag verbrauchen." Die Reservierung sagt: "Dieser Betrag wird für diesen genehmigten Zweck zurückgehalten."

Wann sollten Reservierungen eingesetzt werden?

Nutzen Sie Reservierungen, wenn es teuer wird, zum benötigten Zeitpunkt keine Kapazität zu haben. Sinnvoll sind sie 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 aber nicht unnötig, denn reservierte und ungenutzte GPUs werden schnell zu teurer Leerlaufkapazität. Das Operations-Dashboard sollte reservierte Kapazität deshalb getrennt von installierter, allokierter, freier und deploybarer Kapazität anzeigen. So bleibt bewusster Schutz sichtbar, und nicht jede reservierte Karte wird fälschlich als Verschwendung eingestuft.

Was ist GPU-Priorität?

Priorität bestimmt die Reihenfolge, in der konkurrierende Workloads bei der Ressourcenzuweisung berücksichtigt werden. Das Quellen-Scheduling-Modell unterstützt Task-Queues mit Priorität und macht Queue-Gründe sichtbar. Warten zwei Jobs auf dieselbe begrenzte Ressource, kann der mit höherer Priorität vorgezogen werden.

Das ist nützlich, weil nicht jeder Workload dieselbe geschäftliche Bedeutung hat. Produktions-Inferenz kann höhere Priorität haben als experimentelles Fine-Tuning, ein kundenseitiger Recovery-Task höhere als ein Entwicklungs-Benchmark, und ein terminkritischer Trainings-Job höhere als ein Hintergrund-Batch-Job.

Bereits laufende Arbeit unterbricht Priorität allerdings nicht zwangsläufig. Genau hier trennt sich Priorität von 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. Bei lang laufenden Trainings-Tasks ist das üblich.

Angenommen, zwei Jobs brauchen dieselbe Beschleuniger-Klasse. Job A läuft bereits, und Job B trifft mit höherer geschäftlicher Priorität ein. Wenn Job A nicht sicher checkpointen kann, gehen bei einer Unterbrechung womöglich viele Stunden Compute verloren. Eine reine Prioritätsrichtlinie lässt Job A fertig laufen und setzt Job B vor die übrige wartende Arbeit. Die Organisation bekommt damit eine geschäftsbewusste Queue, ohne unnötig Trainingsfortschritt zu verlieren.

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.

Sinnvoll ist Preemption, wenn Kapazität knapp ist und manche Workloads ausdrücklich unterbrochen werden dürfen. Ein Beispiel: Ein Batch-Trainings-Task mit niedriger Priorität läuft, als ein Incident-Recovery-Workload mit hoher Priorität eintrifft. Der Task mit niedrigerer Priorität unterstützt Checkpointing. Die Plattform speichert oder nutzt den neuesten Checkpoint, stoppt den Task, 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 also stark davon ab, ob sich der Workload wiederherstellen lässt.

Wann sollte GPU-Preemption eingesetzt werden?

Nutzen Sie Preemption, wenn drei Bedingungen zutreffen. Der Workload mit höherer Priorität hat einen triftigen Grund, früher zu starten. Der Workload mit niedrigerer Priorität ist für eine Unterbrechung genehmigt. Und die unterbrochene Arbeit lässt sich so gut schützen, dass die Kosten akzeptabel bleiben.

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 gehört in die Richtlinie für die Workload-Einreichung und sollte nicht erst mitten in einem Incident zum ersten Mal entschieden werden.

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 Checkpoints und Mechanismen zur geordneten Beendigung. Hohe Priorität bedeutet also nicht automatisch, dass Preemption sicher ist. Priorität drückt aus, wie wichtig ein Workload ist, Preemptierbarkeit dagegen, ob er sich wiederherstellen lässt und was die Richtlinie erlaubt. Man braucht beide Angaben.

Wie arbeiten Quotas und Prioritäten zusammen?

Die Quota entscheidet, ob der Workload die Ressource überhaupt anfordern darf. Die Priorität entscheidet über seinen Platz unter den berechtigten Workloads.

Ein Beispiel: Projekt A und Projekt B haben jeweils eine Quota von 16 GPUs. Projekt A nutzt bereits alle 16, und ein neuer Job aus Projekt A 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.

Liegen dagegen beide Projekte innerhalb ihrer Quota und warten auf dieselbe GPU-Klasse, kann die Priorität bestimmen, welcher Job zuerst bedient wird. Weil beide Kontrollen getrennt bleiben, lässt sich das Scheduling erklären.

Wie arbeiten Reservierungen und Quotas zusammen?

Reservierungen schützen eine bekannte Menge zukünftiger oder garantierter Kapazität, Quotas begrenzen den Gesamtverbrauch. Ein Projekt kann beides haben.

Nehmen wir an, Projekt A hat eine Quota von 64 GPUs und für heute Nacht eine Reservierung über 32 GPUs. Das Projekt darf laut Richtlinie bis zu 64 verbrauchen, aber 32 davon sind speziell für den geplanten Lauf geschützt.

Die Quellenmaterialien definieren keine universelle Regel für das Zusammenspiel von Reservierung und Quota, also sollte die unternehmensweite Scheduling-Richtlinie diese Beziehung festlegen. Operativ wichtig ist vor allem, 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, sonst ist sie keine echte Garantie.

Unternehmen können jedoch Notfall-Override-Richtlinien definieren. Die Quellenmaterialien schreiben kein solches Override-Modell vor, und das sicherere, quellenbasierte Design macht die Richtlinie explizit und auditierbar. Wird ein reservierter Pool überschrieben, sollte die Plattform protokollieren, wer es autorisiert hat, welcher Workload die Kapazität genutzt hat, welche Reservierung betroffen war und welches Servicerisiko akzeptiert wurde.

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

Wie verändert Checkpointing die Preemption-Richtlinie?

Checkpointing senkt die Kosten einer Unterbrechung. Der Quellen-Scheduler umfasst Checkpoint-Schutz, Fehlerisolation und Fortsetzung ab Checkpoint.

Ein Workload mit aktuellem Checkpoint kann seine Ressourcen mit weniger verlorener Arbeit freigeben und ist damit ein besserer Preemption-Kandidat. Einen Workload, dessen letzter Checkpoint sechs Stunden alt ist, zu unterbrechen, kostet deutlich mehr. Die Scheduling-Richtlinie kann deshalb neben der statischen Priorität auch den Checkpoint-Status berücksichtigen.

Einen spezifischen Scoring-Algorithmus definiert die Quelle nicht. Sie stützt nur das Prinzip, dass der Schutz laufender Tasks und die Checkpoint-Fähigkeit in Preemption-Entscheidungen einfließen 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?

Laut Quellen-Design sollten Queue-Gründe einzeln sichtbar sein. Das wird unverzichtbar, sobald Quotas, Reservierungen, Prioritäten und Fragmentierung gleichzeitig im Spiel sind. Ein Job kann aus diesen Gründen warten:

• 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 ist vorgereiht
• Erforderliche Topologie nicht verfügbar
• Gesunde Kapazität reicht nicht aus
• Ressourcenfragmentierung verhindert die Platzierung

Der Nutzer sollte den tatsächlichen Grund sehen. Andernfalls sieht dieselbe Queue wie ein Kapazitätsproblem aus, obwohl eigentlich eine Richtlinie dahintersteckt.

Wie beeinflussen Health-Checks diese Richtlinien?

Die Quellen-Scheduling-Architektur nutzt den Health-Status auf Kartenebene als Eingabe für die Ressourcenzuweisung. Quota- und Reservierungszahlen sollten sich daher auf nutzbare, gesunde Ressourcen beziehen und nicht bloß auf installierte Karten.

Hat ein Tenant eine Reservierung für acht GPUs und eine der reservierten Karten 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 mit ihr rechnet. 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: Quota für Berechtigungs- und Verbrauchsgrenzen, Reservierung für garantierte oder geplante Kapazität, Priorität für die Warte-Reihenfolge und Preemption für kontrollierte Unterbrechung, wenn dringende Arbeit Kapazität zurückfordern muss.

Priorität ersetzt keine Quota, und Reservierungen brauchen Sie nicht für jeden Workload. Aktivieren Sie Preemption nicht ohne Recovery-Plan, und gehen Sie nicht davon aus, dass eine große Quota sofort 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, müsste jeder eingereichte Workload vier Dinge deklarieren: wem er gehört, welche Quota gilt, welche Priorität er hat und ob er sicher preemptiert werden kann. Reservierungen kämen dann für Workloads hinzu, die zu einem bestimmten Zeitpunkt garantierte Kapazität brauchen. Das ergibt ein Scheduling-Modell, das Nutzer verstehen und Operations-Teams auditieren können.