GPU-Quoten und Kostenverrechnung: eine GPU-Plattform mit Kueue, Run:ai und MIG zwischen Abteilungen teilen

Wie Abteilungen eine GPU-Plattform teilen

Auf einer geteilten GPU-Plattform mit Quoten teilen Abteilungen einen Pool von 8 bis 32 GPUs über drei Steuerungen. Jede Abteilung erhält eine Quote an Karten, die sie jederzeit beanspruchen kann; freie Karten über dieser Quote können andere ausleihen, wobei Verdrängung (Preemption) sie zurückgibt; und eine Messung erfasst die GPU-Stunden je Abteilung, mit denen sich die GPU-Kosten als Showback oder Chargeback auf die Abteilungen verrechnen lassen. Unter Kubernetes setzen Kueue oder NVIDIA Run:ai die Quote und das Ausleihen durch, während eine einfache ResourceQuota nur jeden Namespace begrenzt. Die Messung beruht auf den Metriken je Pod aus NVIDIAs DCGM Exporter, und MIG legt fest, wie klein die Einheit der Zuteilung sein kann.

Wie eine Karte mit MIG, Time-Slicing oder MPS zwischen Pods aufgeteilt wird, erklärt unser Leitfaden zum GPU-Sharing in Kubernetes, und Slurm mit Fair-Share für Forschungsteams unser Leitfaden zu GPU-Servern für Universitätslabore.

Kubernetes-Seite Resource Quotas (geändert am 28. September 2026); Kueue-Seiten zu ClusterQueue, LocalQueue und Preemption (19. August und 30. September 2026); Dokumentation von NVIDIA Run:ai self-hosted; MIG-Benutzerhandbuch von NVIDIA (11. September 2026); alle abgerufen am 10. Oktober 2026.

Kubernetes ResourceQuota: eine harte Obergrenze je Namespace

Laut Kubernetes-Dokumentation bietet eine ResourceQuota „Beschränkungen, die den gesamten Ressourcenverbrauch je Namespace begrenzen“, und das Szenario der Seite selbst lautet „Verschiedene Teams arbeiten in verschiedenen Namespaces.“ GPUs sind eine erweiterte Ressource (Extended Resource), und da Overcommit für erweiterte Ressourcen nicht erlaubt ist, sind nur Quoteneinträge mit dem Präfix requests. zulässig. Das Beispiel der Dokumentation ist requests.nvidia.com/gpu: 4. Mit der MIG-Strategie mixed des GPU Operators ist jedes Profil ein eigener Ressourcenname, sodass eine Zeile wie requests.nvidia.com/mig-1g.24gb: 8 Instanzen getrennt von ganzen Karten begrenzt.

Würde das Anlegen eines Pods die Quote überschreiten, „lehnt die Steuerungsebene diese Anfrage mit dem HTTP-Statuscode 403 Forbidden ab“. Eine ResourceQuota reiht keine Arbeit ein und verleiht nichts: Eine Abteilung an ihrer Obergrenze wartet, auch wenn der halbe Cluster frei ist, und eine Abteilung unter ihrer Obergrenze hat keinen Anspruch auf Karten, die andere bereits belegen. Eine Quote mit einem PriorityClass-Scope gilt nur für Pods dieser Prioritätsklasse und kann so begrenzen, wie viele GPUs ein Namespace mit hoher Priorität betreibt. Behalten Sie die ResourceQuota als Obergrenze und ergänzen Sie für das Teilen eine Ebene mit Warteschlangen.

Kueue: eine ClusterQueue je Abteilung, Cohorts und Fair Sharing

Kueue, dessen aktuelles Release auf seiner GitHub-Seite am 10. Oktober 2026 v0.19.6 war, lässt Jobs gegen Quoten zu, bevor der Kubernetes-Scheduler sie platziert. Nutzer reichen Jobs in eine LocalQueue ein, „eine Ressource im Namespace, die eng zusammengehörende Workloads eines einzelnen Mandanten bündelt“, und jede LocalQueue „verweist auf eine ClusterQueue, aus der Ressourcen zugeteilt werden, um ihre Workloads auszuführen“. Für ein Unternehmen heißt das: eine ClusterQueue je Abteilung, deren Namespaces das Feld .spec.namespaceSelector auswählt, und eine Cohort für die ganze Plattform.

ResourceFlavors beschreiben die Kartentypen. Kueues Dokumentation sagt: „Flavors stehen für verschiedene Varianten einer Ressource (zum Beispiel verschiedene GPU-Modelle)“, und eine ClusterQueue legt „die Quote für jede der Ressourcen, die ein Flavor anbietet“ fest. Eine Abteilung kann dann eine nominalQuota von sechs H200 NVL und vier RTX PRO 6000 als zwei getrennte Werte halten. ClusterQueues in derselben Cohort „können sich gegenseitig ungenutzte Quoten leihen“. Das borrowingLimit begrenzt, was eine Queue von den anderen nehmen darf, und das lendingLimit, wie viel ihrer eigenen freien Quote sie verleiht; ein lendingLimit von null hält die Karten eines Produktivdienstes also aus dem Pool heraus.

Preemption muss eingeschaltet werden. Das Feld reclaimWithinCohort nimmt Never (den Standard), LowerPriority oder Any an und erlaubt einer Abteilung, die ihre Quote zurückbraucht, Workloads anderer Queues zu verdrängen, die gerade ausleihen. Das Feld withinClusterQueue, ebenfalls standardmäßig Never, erlaubt Arbeit mit höherer Priorität in einer Abteilung, deren eigene Arbeit mit niedrigerer Priorität zu verdrängen. Ist Fair Sharing in der Kueue-Konfiguration aktiviert, wird der Anteil einer Queue laut Dokumentation „mit dem in einer ClusterQueue definierten .spec.fairSharing.weight gewichtet“, und die Preemption-Strategien LessThanOrEqualToFinalShare und LessThanInitialShare entscheiden, wann eine Abteilung eine andere verdrängen darf.

NVIDIA Run:ai: Departments, Projekte und Over Quota

NVIDIA Run:ai bildet dieselben Steuerungen in einer Hierarchie mit zwei Ebenen ab. Die Dokumentation sagt: „Departments fassen mehrere Projekte unter einem gemeinsamen organisatorischen Rahmen zusammen“, und in seinem Scheduler „sind Projekt-Queues an Department-Queues gebunden, je Node-Pool“. Jedes Projekt hat eine Deserved Quota je Node-Pool, und „Deserved Quota bedeutet, dass ein Projekt berechtigt ist, Ressourcen bis zu einer durch seine Quote festgelegten Höchstzahl zu nutzen“. Die Quote eines Departments lässt sich nicht unter die Quote setzen, die seinen Projekten bereits zugewiesen ist. Sein Limit, standardmäßig Unlimited, begrenzt die GPUs, die das Department aus einem Node-Pool nehmen kann.

Die Art des Workloads bestimmt die Regeln. „Nicht verdrängbare Workloads können nur eingeplant werden, wenn ihre angeforderten Ressourcen innerhalb der Deserved Quotas liegen“, und „Over-Quota-Ressourcen können nur von verdrängbaren Workloads genutzt werden.“ Zuerst entscheidet der Rank, wer freie GPUs erhält, und innerhalb eines Ranks gilt: „Der Anteil, den jedes Projekt erhält, hängt von seinem Over-Quota-Gewicht und der Summe der Over-Quota-Gewichte aller anderen Projekte ab.“ Ist das Over Quota Weight aktiviert, starten Departments desselben Ranks mit einem Standardgewicht von 2; ist es deaktiviert, folgt das Gewicht der zugewiesenen Quote. Reclaim „gibt die Ressourcen an ein Projekt (oder Department) zurück, dem diese Ressourcen als Teil seiner Deserved Quota zustehen“. Innerhalb eines Projekts können Workloads mit höherer Priorität verdrängbare Workloads mit niedrigerer Priorität verdrängen, und ein zeitbasierter Fairshare-Modus berechnet den Fairshare aus der bisherigen Nutzung.

NVIDIAs Dokumentation zu AI Enterprise vom 10. August 2026 hält fest, dass „sowohl NVIDIA Run:ai self-hosted als auch NVIDIA Run:ai SaaS in Ihrer NVIDIA-AI-Enterprise-Lizenz enthalten sind“. AI Enterprise ist ein Nutzungsrecht pro GPU, wie unser Leitfaden zur Lizenzierung von NVIDIA AI Enterprise erklärt, und NVIDIAs Testlizenz über 90 Tage schließt Run:ai nicht ein.

Wir liefern Lizenzen für NVIDIA AI Enterprise, die Run:ai enthalten, unter einem EU-Vertrag und auf einer Rechnung mit den Servern. Nennen Sie uns, wie viele GPUs und Abteilungen die Plattform haben wird, und wir empfehlen Edition und Laufzeit.

MIG-Profile als Einheit der Zuteilung

Eine Quote zählt ganze Ressourcen; ohne Partitionierung ist die kleinste Einheit, die eine Abteilung halten kann, also eine Karte. NVIDIAs MIG-Benutzerhandbuch vom 11. September 2026 nennt für die RTX PRO 6000 Blackwell Server Edition bis zu vier Instanzen 1g.24gb, zwei 2g.48gb oder eine 4g.96gb. Für die H200 mit 141 GB, den Speicher der H200 NVL, nennt es bis zu sieben Instanzen 1g.18gb, drei 2g.35gb oder zwei 3g.71gb, und Kueue-Quoten benennen jedes Profil wie jede andere Ressource.

MIG-Instanzen haben eigenen Speicher und eigene Fehlerisolierung, sodass ein Notebook einer Abteilung nicht den Speicher füllen kann, den die Instanz einer anderen Abteilung auf derselben Karte hält. Das Layout ist eine Einstellung des Nodes, die der MIG Manager nur ändert, wenn auf den GPUs keine Benutzer-Workloads laufen. Planen Sie die Profile je Node zusammen mit den Quoten und ändern Sie sie in vereinbarten Wartungsfenstern.

GPU-Stunden je Abteilung messen für Showback oder Chargeback

Showback weist die Nutzung jeder Abteilung aus, Chargeback bucht sie auf deren Kostenstelle. Beide brauchen GPU-Stunden je Abteilung und je Kartentyp. NVIDIAs Blog vom 4. November 2020 erklärt, dass sich der DCGM Exporter „mit dem Pod-Resources-Server des kubelet verbindet“, um die GPU-Geräte jedes Pods zu ermitteln, und „die Pod-Informationen der GPU-Geräte an die gesammelten Metriken anhängt“. Das README des Exporters zeigt seine Beispielmetriken mit den Labels container, namespace und pod. NVIDIAs Seite zum DCGM Exporter führt die Option -k für die Pod-Zuordnung mit „Default: false“; prüfen Sie also, ob sie in Ihrem Deployment eingeschaltet ist. Für MIG veröffentlicht der Exporter laut NVIDIA „Metriken sowohl für die gesamte GPU als auch für einzelne MIG-Geräte“, mit den Labels GPU_I_ID und GPU_I_PROFILE.

Aus diesen Zeitreihen kann Prometheus für jedes Abtastintervall zählen, wie viele GPUs oder MIG-Instanzen ein Namespace belegt hat. Über einen Monat summiert und von Namespaces auf Abteilungen abgebildet, ergibt die Zählung zugewiesene GPU-Stunden, also die Zeit, in der eine Karte belegt war, ob sie arbeitete oder nicht. Die andere Grundlage bucht die Quote jeder Abteilung vollständig und weist geliehene Stunden zusätzlich aus; sie folgt der Struktur der Plattform, wenn die Quoten nach den gekauften Karten bemessen sind. Wir gewichten MIG-Instanzen nach der Höchstzahl je Karte in NVIDIAs Handbuch, eine 1g.24gb als ein Viertel einer RTX PRO 6000 und eine 1g.18gb als ein Siebtel einer H200 NVL, und weisen die beiden Kartentypen in getrennten Zeilen aus.

Eine Spalte mit der Auslastung zeigt, welche Abteilungen Karten belegen, die sie nicht nutzen; unser Leitfaden zum Monitoring mit DCGM erklärt, warum die GPU-Auslastung die Last überzeichnet und welche Felder sie messen. Für eine Karte mit Time-Slicing, die sich mehrere Pods teilen, nennt NVIDIAs DCGM-Befehlszeilenreferenz vom 10. September 2026 die Option --kubernetes-virtual-gpus, standardmäßig aus, mit der Beschreibung „Attribute supported time-sharing or MPS assignments in Kubernetes mode“. Ohne sie messen Sie Nodes mit Time-Slicing nach den Replikaten, die jeder Namespace hält.

Ein gemeinsamer Inferenzdienst ist die Ausnahme. Ein RAG-Assistent für das ganze Unternehmen läuft im Namespace des Plattformteams, und seine GPU-Stunden landen auf einer Kostenstelle. Teilen Sie sie nach den Token auf, die jede Abteilung sendet, entnommen aus dem Protokoll je Schlüssel des Gateways, wie unser Leitfaden zu einem LLM-Gateway mit Schlüsseln und Budgets beschreibt.

Rechenbeispiel: 24 GPUs für fünf Workloads der Abteilungen

Als Beispiel dient ein Unternehmen mit 1.500 Beschäftigten und drei Servern: zwei mit je acht RTX PRO 6000 Server Edition und einer mit acht H200 NVL. Beide Karten stehen auf der Supportliste des GPU Operators und auf NVIDIAs MIG-Liste. Fünf Workloads teilen sich die 24 Karten.

Unsere Beispielzuteilung; MIG-Profile aus NVIDIAs MIG-Benutzerhandbuch (11. September 2026), Felder für Quoten und Preemption aus der Dokumentation von Kueue und Run:ai, abgerufen am 10. Oktober 2026.

Der Assistent läuft auf vier Karten in jedem RTX-Server und behält so die Hälfte seiner Kapazität, wenn ein Server ausfällt. Sein lendingLimit von null hält diese Karten für die Morgenspitze frei. Batch-Jobs leihen nachts freie Karten der Data-Science-Abteilung und werden verdrängt, wenn ein Fine-Tuning startet. In Kueue läuft die Einrichtung in dieser Reihenfolge.

1. Jede Abteilung einem oder mehreren Namespaces zuordnen, diese mit Labels versehen und je Namespace eine LocalQueue anlegen.
2. Je Kartentyp einen ResourceFlavor definieren und einen weiteren für die Nodes mit dem Layout 1g.24gb.
3. Je Abteilung eine ClusterQueue mit einer nominalQuota je Flavor anlegen, alle in einer Cohort, und das lendingLimit der beiden Dienst-Queues auf null setzen.
4. Den Flavor für die H200 NVL in der Batch-Queue mit einer nominalQuota von 0 und einem borrowingLimit aufführen, da „eine ClusterQueue nur Quote für Flavors leihen kann, die die ClusterQueue definiert“, und reclaimWithinCohort auf den Queues setzen, die verleihen.
5. Je Namespace eine ResourceQuota als Obergrenze ergänzen, dann die Pod-Zuordnung im DCGM Exporter einschalten und den Monatsbericht aufbauen.

In Run:ai wird derselbe Plan zu fünf Projekten in drei oder vier Departments: Die beiden Dienste laufen nicht verdrängbar innerhalb ihrer Deserved Quota, und das Batch-Projekt läuft verdrängbar über der Quote mit einem niedrigeren Rank.

Wir bauen GPU-Server auf Bestellung für Plattformen dieser Größe, mit Karten RTX PRO 6000 Server Edition oder H200 NVL. Schicken Sie uns die Abteilungen, ihre Workloads und die Karten, die jede halten soll, über das Formular unten.

Was wir liefern

Wir bauen KI-Server auf Bestellung für eine geteilte GPU-Plattform, mit Karten RTX PRO 6000 Server Edition und H200 NVL, montiert, im Burn-in getestet und mit Herstellergarantie in die ganze EU geliefert. Dieselben Karten sowie die L40S und L4 für Dienste auf ganzen GPUs gibt es auch als Karten aus unserem Sortiment professioneller NVIDIA-GPUs. Lizenzen für NVIDIA AI Enterprise, die Run:ai enthalten, kommen über unser Angebot für Software und Lizenzen, unter einem EU-Vertrag und auf einer Rechnung mit der Hardware. Betriebssystem, Treiber, CUDA und eine Container-Runtime installieren wir auf Wunsch, und der Aufbau der Kubernetes-Plattform darauf ist unsere Leistung Private AI/ML, mit Engineering von unserem Engineering-Partner Vixen.UNO.

FAQ