Warum GPU-Observability auf Kubernetes maßgeschneiderte Engineering-Lösungen erfordert

Der Betrieb von KI-Workloads auf Kubernetes zeigt einen deutlichen Unterschied im Management von CPUs und GPUs. Während CPU- und Speichernutzung über eingebaute Metriken pro Pod und Kostenzuordnung verfügen, bieten geteilte GPUs diese Funktionen nicht out-of-the-box. Stand Oktober 2026 müssen Plattform-Ingenieure die Sichtbarkeit für ihre kostspieligste Infrastrukturkomponente manuell rekonstruieren.

Was passiert ist

Jahrelang verließen sich Kubernetes-Nutzer auf Standard-Dashboards zur Überwachung des Ressourcenverbrauchs. Diese Tools vergleichen die angeforderten Ressourcen eines Containers mit dem tatsächlichen Verbrauch, sodass Teams Verschwendung identifizieren und Kosten nach Namespace zuordnen können. Dieses Modell funktioniert nahtlos für CPU und Speicher, da der Kernel die Nutzung pro Container automatisch erfasst. Dieser etablierte Workflow bricht jedoch vollständig zusammen, wenn er auf Grafikeinheiten (GPUs) angewendet wird.

Wenn Workloads auf GPUs migriert werden, gelten die Annahmen, die für andere Ressourcen zutreffen, nicht mehr. Plattformteams sehen sich gezwungen, jede Ebene der Sichtbarkeit von Grund auf neu aufzubauen. Sie müssen eigene Metriken erstellen, eigene Genauigkeitsstandards definieren und Regeln für die Aufteilung der Rechnungen erfinden. Dieser manuelle Aufwand ist besonders schmerzhaft, da GPU-Kosten den größten Anteil an den Budgets moderner KI-Infrastrukturen ausmachen.

Wie es funktioniert

Das Kernproblem liegt darin, wie GPU-Metriken bereitgestellt werden. Tools wie der DCGM-Exporter von NVIDIA melden Daten standardmäßig auf physischer Geräteebene. Dieser Ansatz funktioniert, wenn ein einzelner Pod eine gesamte GPU besitzt. Wenn jedoch mehrere Pods eine GPU durch Time-Slicing oder Multi-Process Service (MPS) teilen, weist der Exporter jedem Pod denselben Gesamtverbrauchswert zu. Teilen sich drei Pods eine GPU, scheint jeder das Gerät zu 100 % zu nutzen, was zu einer unsinnigen Gesamtauslastung von 300 % führt. Der Treiber stellt nur einen einzigen Satz Zähler für die gesamte GPU bereit, wodurch es unmöglich ist, den individuellen Verbrauch der Workloads zu unterscheiden.

Auch die Right-Sizing-Prozesse werden komplex. Im Gegensatz zu CPUs, die Millikerns und Overcommitting unterstützen, werden GPUs in der Regel als ganze Einheiten angefordert. Fractional Sharing findet unterhalb des Schedulers statt, entweder durch Time-Slicing oder Multi-Instance-GPU-(MIG)-Partitionen, was bedeutet, dass Kubernetes-Anforderungen nicht sauber mit der tatsächlichen Nutzung übereinstimmen. Darüber hinaus sind GPU-Auslastungsmetriken mehrdeutig. Eine GPU kann eine Auslastung von 100 % anzeigen, während sie nur minimale Rechenarbeit verrichtet, da Frameworks oft den Großteil des Speichers beim Start reservieren. Die Speichernutzung bleibt der zuverlässigste Indikator für die Kostenzuordnung, da die Rechenzeit in parallelen Umgebungen schwer genau zu messen ist.

Wichtige Details

• Der DCGM-Exporter von NVIDIA meldet auf Geräteebene, was zu aufgeblasenen Nutzungszahlen führt, wenn GPUs über mehrere Pods hinweg geteilt werden.
• GPU-Anforderungen in Kubernetes sind ganzzahlige Ressourcen, was die bei CPUs üblichen Strategien des Overcommitting und Bursting verhindert.
• Die Umgebungsvariable NVIDIA_VISIBLE_DEVICES kann Pods den Zugriff auf alle GPUs eines Nodes ermöglichen, wenn sie nicht ordnungsgemäß vom Device Plugin überschrieben wird.
• Compute-Auslastungsmetriken sind für geteilte Workloads unzuverlässig, da sie Aktivität anstelle eines proportionalen Ressourcenverbrauchs anzeigen.
• Die Speichernutzung ist das genaueste Signal für die Kostenzuordnung, berücksichtigt jedoch nicht die vom Treiber reservierten Speichersegmente.
• Cloud-Anbieter rechnen GPU-Nodes als einzelne Rechnungspositionen ab, was eine manuelle Aufschlüsselung erfordert, um Kosten bestimmten Modellen oder Teams zuzuordnen.

Warum das wichtig ist

Für Softwareentwickler führt das Fehlen einer nativen GPU-Observability direkt zu technischer Last und finanzieller Intransparenz. Teams können ihre bestehenden Playbooks für die CPU-Überwachung nicht einfach übernehmen. Stattdessen müssen sie erhebliche Zeit in den Aufbau eigener Tools investieren, um die Nutzung zu verfolgen, Guardrails durchzusetzen und Kosten aufzuteilen. Dies lenkt Ressourcen von der Produktentwicklung auf die Infrastrukturwartung ab. Ohne präzise Daten riskieren Organisationen die Überbereitstellung teurer Hardware oder die falsche Zuordnung von Kosten an die richtigen Teams, was zu Budgetineffizienzen führt.

Die Komplexität erstreckt sich auch auf Entscheidungen zur technischen Architektur. Verschiedene Sharing-Paradigmen wie Time-Slicing, MPS und MIG verändern die zugrunde liegende Mathematik für die Ressourcenzuweisung. Dynamic Resource Allocation (DRA) reift in Kubernetes heran, aber das Ökosystem, einschließlich Autoscaler, hinkt noch hinterher. Ingenieure müssen verstehen, welchen Sharing-Modus ihre Nodes verwenden, um Metriken korrekt zu interpretieren. Fehlinterpretationen dieser Signale können zu falschen Skalierungsentscheidungen und Leistungsengpässen führen.

Was Sie tun können

• Prüfen Sie Ihr aktuelles Setup zur GPU-Überwachung.
• Berücksichtigen Sie, dass GPU-Anforderungen in Kubernetes ganzzahlige Ressourcen sind, was Overcommitting und Bursting wie bei CPUs verhindert.
• Stellen Sie sicher, dass die Umgebungsvariable NVIDIA_VISIBLE_DEVICES ordnungsgemäß vom Device Plugin überschrieben wird, damit Pods nicht versehentlich auf alle GPUs eines Nodes zugreifen.
• Verlassen Sie sich bei geteilten Workloads nicht auf Compute-Auslastungsmetriken, da diese Aktivität statt proportionalen Ressourcenverbrauch anzeigen.
• Nutzen Sie die Speichernutzung als primäres Signal für die Kostenzuordnung, obwohl sie vom Treiber reservierte Speichersegmente nicht berücksichtigt.
• Planen Sie eine manuelle Aufschlüsselung der Kosten ein, da Cloud-Anbieter GPU-Nodes als einzelne Rechnungspositionen abrechnen und Kosten spezifischen Modellen oder Teams zugeordnet werden müssen.