Monitoring-Tools für CPU und Arbeitsspeicher lassen sich nicht ebenso einfach auf Grafikprozessoren (GPU) unter Kubernetes übertragen. Während die Plattform in der Regel Nutzungsmetriken auf Container- oder Pod-Ebene bereitstellt, müssen Plattformteams bei der gemeinsamen Nutzung einer GPU die meisten Ebenen für Transparenz, Zuordnung und Abrechnung selbst aufbauen – von der Datenerfassung bis zur Bestimmung des Kostenanteils jedes Teams.
Die Bedeutung des Problems ergibt sich daraus, dass die GPU üblicherweise den teuersten Posten auf der Infrastrukturrechnung darstellt. Die Analyse weist darauf hin, dass sich die Betriebskosten nicht auf den Preis des Knotens beschränken, sondern auch die erforderliche Engineering-Zeit umfassen, um Messlücken auszugleichen, die Genauigkeit der Zahlen zu überprüfen und zu verhindern, dass Workloads die ihnen von Kubernetes zugewiesenen Ressourcen überschreiten.
Warum reichen die üblichen Metriken nicht aus?
Der NVIDIA DCGM exporter, mit dem viele Betreiber beginnen, liefert standardmäßig Daten auf Ebene des physischen Geräts. Wenn ein Pod eine vollständige GPU besitzt, kann das ausreichen. Bei der Nutzung von time-slicing oder MPS zur gemeinsamen Nutzung des Geräts ändert sich die Situation jedoch. In diesem Fall kann für jeden Pod, der eine GPU nutzt, derselbe Wert angezeigt werden, sodass es so wirkt, als hätten drei Workloads 300 % einer GPU verbraucht, die physisch gar nicht vorhanden ist.
Das Problem besteht darin, dass die Diagramme korrekt aussehen können, obwohl die zugrunde liegenden Daten für eine Zuordnung ungeeignet sind. Daher können Teams vollständige Berichte und Dashboards auf Zahlen aufbauen, die tatsächlich nicht zwischen den Verbrauchern unterscheiden.
Was ändert sich in der Praxis für Plattformteams?
Die GPU unterscheidet sich auch beim Modell der Ressourcenzuweisung von der CPU. In Kubernetes erscheint die GPU üblicherweise als ganzzahlige Ressource wie nvidia.com/gpu: 1, und der Scheduler kann nicht wie bei Prozessoren mit Bruchteilen umgehen. Die tatsächliche gemeinsame Nutzung erfolgt unterhalb der Scheduler-Ebene über time-slicing, MPS oder MIG, wodurch der Vergleich zwischen der Anforderung des Workloads und seiner Nutzung komplexer wird.
Die Teams benötigen außerdem unabhängige Kontrollmechanismen, um sicherzustellen, dass das, was Kubernetes als zugewiesen erfasst, mit dem übereinstimmt, worauf die Anwendung tatsächlich zugreifen kann. Die Umgebungsvariable NVIDIA_VISIBLE_DEVICES kann dazu führen, dass der Container alle GPUs im Knoten sieht, selbst wenn der Scheduler ihm nur eine GPU zugewiesen hat, sofern eine geeignete Konfiguration dies nicht verhindert.
Auch die Aussage „GPU-Nutzung von 80 %“ hat nicht zwangsläufig eine einheitliche Bedeutung. Sie kann lediglich messen, dass während eines Teils des Messfensters ein Kernel ausgeführt wurde, ohne den Verbrauch von Rechenleistung oder die Speicherbandbreite zu erläutern. In einigen Frameworks, etwa vLLM, kann beim Start der Großteil des GPU-Speichers reserviert werden, wodurch der Speicher oder die Bandbreite ein wichtigerer Indikator sein kann als die allgemeine Nutzungszahl.
Abrechnung: Speicher lässt sich besser zuordnen als Rechenleistung
Die NVIDIA-NVML-Bibliothek kann anzeigen, wie viel Speicher jeder Prozess belegt, und anschließend den Prozess dem Pod und dem dafür verantwortlichen Team zuordnen. Dabei ist zu beachten, dass die Summe der Werte nicht dem gesamten Speicher der Karte entspricht, da ein Teil vom Treiber selbst reserviert wird.
Die Zuordnung der Rechenzeit zwischen parallel ausgeführten Workloads ist dagegen nur begrenzt genau. Zwei Workloads können so erscheinen, als seien beide zu 90 % aktiv, ohne dass die Metriken erkennen lassen, welcher 70 % der Leistung und welcher 30 % verbraucht hat. Die Analyse schlägt daher vor, die GPU-Speichernutzung als praktische Grundlage für die interne Abrechnung zu verwenden und die Messung der Rechenleistung als Betriebsindikator, nicht jedoch als genaue Referenz für die Verrechnung zu behandeln.
Das gewählte Modell der gemeinsamen Nutzung verändert die Berechnungen
Die gemeinsame Nutzung einer GPU stellt kein einheitliches Modell dar. time-slicing wechselt sich auf dem Gerät ab, ohne eine Isolierung bereitzustellen, MPS ermöglicht die gleichzeitige Ausführung von Kernels verschiedener Prozesse, während MIG die Hardware in feste Teile aufteilt. Dennoch können Cloud-Dienste den vollständigen physischen GPU-Tarif berechnen, selbst wenn nur ein Teil davon genutzt wird. Außerdem können Karten der Klassen A100 und H100 laut dem Artikel in maximal sieben Instanzen aufgeteilt werden.
Dynamic Resource Allocation (DRA) entwickelt sich zum künftigen Weg für die Ressourcenverwaltung, befindet sich jedoch noch in der Reifephase. Auch die begleitenden Tools, darunter Skalierungswerkzeuge wie Karpenter, holen diese Entwicklung noch ein.
Warum ist diese Nachricht wichtig?
Auf AWS liegt der Preis für die günstigste mit MIG kompatible GPU der A100-Klasse laut dem Artikel bei etwa 22 US-Dollar pro Stunde beziehungsweise bei rund 14 US-Dollar bei Nutzung der Spot-Preise. Zum Vergleich kostet eine entsprechende, ausschließlich auf CPU basierende Instanz etwa 5 US-Dollar pro Stunde. Daher stellt eine fehlerhafte Zuordnung der Nutzung kein kleines Abrechnungsproblem dar, sondern kann sich unmittelbar auf Kapazitäts- und Kostenentscheidungen sowie auf die faire Belastung der Teams auswirken.
Die redaktionelle Schlussfolgerung lautet, dass der Betrieb von GPUs auf Kubernetes weiterhin ein anderes Betriebsmodell als bei CPU und Arbeitsspeicher erfordert. Plattformteams müssen festlegen, was sich genau messen lässt, klare Regeln für die Kostenverteilung aufstellen und vermeiden, Abrechnungsentscheidungen auf einer allgemeinen GPU-Kennzahl aufzubauen, die den tatsächlichen Verbrauch nicht beschreibt. Zugleich weist die Quelle darauf hin, dass die zunehmende Reife von DRA und die Aufteilung der Hardware die Lücke schrittweise verkleinern könnten. Der Zeitpunkt dafür und die Grenzen der derzeitigen Tools bleiben jedoch offene Fragen.