Wie man Multi-Vendor-GPUs und -NPUs verwaltet

Der saubere Weg, GPUs und NPUs mehrerer Hersteller zu verwalten, besteht darin, das Problem in Schichten zu trennen: physische Erkennung, Normalisierung des Gesundheitszustands, Ressourcenabstraktion, Scheduling und Workload-Telemetrie. Tun Sie nicht so, als wäre jeder Beschleuniger identisch. Geben Sie Nutzern einen standardisierten Weg, Fähigkeiten anzufordern, während Hersteller- und Modellunterschiede für die Plattform sichtbar bleiben.

Kubernetes kann bei der Bereitstellung und dem Scheduling von Geräten helfen, macht aber Vendor-Treiber, Device-Plugins oder DRA-Treiber, Firmware-Management, Health-Erfassung und Betriebsrichtlinien nicht überflüssig. Die Management-Ebene muss weiterhin wissen, um welche Karte es sich jeweils handelt, ob sie gesund ist und welche Workloads tatsächlich darauf laufen können.

Warum ist die Verwaltung von Multi-Vendor-Beschleunigern schwierig?

Multi-Vendor-Beschleunigerverwaltung ist schwierig, weil sich die Geräte in mehr als nur dem Hardware-Namen unterscheiden.

Sie können unterschiedliche Treiber, Runtimes, Firmware, Monitoring-Schnittstellen, Speichergrößen, Precision-Support, Partitionierungsmodelle, Topologie-Anforderungen und Framework-Kompatibilität haben.

Selbst Health-Metriken sind uneinheitlich.

Ein Hersteller stellt die Speichertemperatur vielleicht direkt bereit. Ein anderer stellt nur eine Board-Temperatur bereit. ECC-Terminologie kann sich unterscheiden. Power-Metriken können aus unterschiedlichen Schnittstellen stammen. Firmware-Felder können sich zwischen Versionen ändern.

Das bedeutet: Der erste Fehler ist der Versuch, Heterogenität nur auf Dashboard-Ebene zu lösen.

Eine einzelne Seite, die jede Karte auflistet, ist nützlich, macht die Geräte aber nicht operativ austauschbar.

Sie brauchen darunter ein gemeinsames Datenmodell.

Was sollte das gemeinsame Beschleuniger-Inventar enthalten?

Ein nützliches Beschleuniger-Inventar sollte jede physische Karte, ihren Host, ihre Fähigkeiten, ihre Software-Abhängigkeiten und ihren Gesundheitszustand identifizieren.

Erfassen Sie mindestens Hersteller, Modell, Seriennummer oder eindeutige Geräte-ID, Host-Node, Slot- oder Bus-Position, Speicherkapazität, Firmware, Treiberzuordnung, Health-Status, Temperatur, Power und Zuweisungsstatus, sofern diese Werte verfügbar sind.

Für das Scheduling ergänzen Sie operative Attribute wie: Ist die Karte vollständig oder partitioniert, gehört sie zu einer bestimmten Topologie-Domäne, ist sie reserviert, und gilt sie als degradiert.

Für Governance verknüpfen Sie die Karte mit dem physischen Server, dem Rack, dem Rechenzentrum, dem Owner, dem Wartungsstatus und der Workload-Historie.

Genau hier arbeiten In-Band- und Out-of-Band-Monitoring zusammen.

Das BMC ist nützlich für den Hardware-Status auf Serverebene. Vendor-Runtime-Bibliotheken oder Agents können für Auslastungs- und Speichermetriken auf Kartenebene erforderlich sein. Kubernetes stellt die Workload-Bindung bereit. Das Ressourcen-Inventar muss diese Sichten zusammenführen.

Wie stellt Kubernetes GPUs und andere Beschleuniger bereit?

Kubernetes stellt spezialisierte Hardware über Vendor-Integrationen wie Device-Plugins bereit, und neuere Cluster können zusätzlich Dynamic Resource Allocation nutzen.

Das Device-Plugin-Framework erlaubt es einem Hersteller, Geräte dem Kubelet als Node-Ressourcen bekanntzugeben. Kubernetes kann dann einen Pod, der diese Ressource anfordert, auf einem Node mit verfügbarer Kapazität einplanen.

Dieses Modell ist für GPUs weit verbreitet.

Dynamic Resource Allocation, meist abgekürzt als DRA, bietet einen ausdrucksstärkeren Weg, Geräte und Geräteeigenschaften anzufordern. Seit Kubernetes 1.35 ist die zentrale DRA-Funktionalität laut Kubernetes-Dokumentation stabil und standardmäßig aktiviert.

Das ist für heterogene Infrastruktur relevant, weil ein Workload mehr ausdrücken kann als nur eine einfache Anzahl generischer Geräte.

Kubernetes braucht trotzdem einen funktionierenden Treiber und eine Vendor-Integration.

DRA macht aus einem nicht unterstützten Beschleuniger keinen unterstützten. Es gibt dem Scheduler und dem Workload lediglich einen besseren Ressourcenvertrag.

Sollten Nutzer einen herstellerspezifischen GPU-Namen anfordern?

Nutzer sollten herstellerspezifische Ressourcen nur dann anfordern, wenn der Workload tatsächlich von diesem Hersteller oder Modell abhängt.

Für viele Plattform-Nutzer ist eine standardisierte Spezifikation die bessere Schnittstelle.

Eine Organisation könnte zum Beispiel Ressourcenklassen wie diese definieren:

Large Training, 8 vollständige Beschleuniger mit viel Speicher
Standard Training, 4 vollständige Beschleuniger
Inference, 1 vollständiger Beschleuniger
Shared Inference, partitionierter Beschleuniger
Development, nur CPU

Diese Klassen sind Beispiele, keine universellen Standards.

Der Punkt ist: Der Business-Nutzer fragt nach der Fähigkeit, die er braucht, während die Plattform die Anfrage auf passende Hardware abbildet.

Wenn ein Workload eine bestimmte CUDA-Version, eine bestimmte Modellarchitektur oder eine bestimmte Speichergröße benötigt, sollte diese Anforderung explizit bleiben.

Abstraktion sollte unnötiges Hardware-Wissen reduzieren. Sie sollte keine Kompatibilitätseinschränkungen verstecken.

Wie entscheidet man, ob zwei Beschleunigermodelle in denselben Pool gehören?

Zwei Beschleunigermodelle gehören nur dann in denselben logischen Pool, wenn die diesem Pool zugewiesenen Workloads auf beiden korrekt und vorhersehbar laufen können.

Prüfen Sie zuerst die Software-Kompatibilität.

Läuft dasselbe Framework und Modell auf beiden? Sind die nötigen Treiber und Bibliotheken verfügbar? Braucht der Workload eine herstellerspezifische Runtime?

Prüfen Sie dann die Hardware-Fähigkeiten.

Speicherkapazität ist oft eine harte Einschränkung. Ein Modell, das mehr Speicher braucht, als eine Karte bietet, kann dort nicht eingeplant werden, nur weil beide Geräte Beschleuniger sind.

Topologie kann für Multi-Card-Training wichtig sein. Interconnect-Eigenschaften können die Trainingsperformance erheblich verändern.

Performance-Unterschiede sind für SLOs und Kosten relevant. Wenn zwei Modelle sehr unterschiedlichen Durchsatz liefern, kann es Warteschlangenzeiten und Fertigstellungsschätzungen irreführend machen, sie als eine undifferenzierte Ressource zu behandeln.

Die beste Abstraktion hält die Nutzeroberfläche meist einfach, bewahrt aber darunter die Resource Flavors.

Kueue unterstützt zum Beispiel ResourceFlavor-Objekte und Quotas, die unterschiedliche GPU-Modelle oder andere Ressourcen-Varianten abbilden können.

Wie sollte der Gesundheitszustand das Scheduling beeinflussen?

Der Gesundheitszustand sollte ein Scheduling-Input sein, nicht nur ein Alarm, nachdem der Job schon gestartet ist.

Eine Karte kann technisch online sein und trotzdem ein schlechtes Scheduling-Ziel sein.

Beispiele sind steigende ECC-Fehler, wiederholte Resets, anhaltend hohe Temperatur, degradiertes Taktverhalten oder wiederkehrende Treiberfehler.

Wenn die Management-Ebene eine solche Karte als degradiert markiert, sollte der Scheduler vermeiden, ihr neue Arbeit zuzuweisen.

Die genaue Maßnahme hängt vom Risiko ab.

Eine Warnung reduziert vielleicht nur die Scheduling-Priorität. Ein ernsterer Zustand markiert den Node womöglich als nicht mehr einplanbar. Ein bestätigter Ausfall kann Task-Migration, Checkpoint-Recovery und einen Reparatur-Arbeitsauftrag auslösen.

Das ist einer der stärksten Gründe, Hardware-Management mit dem Scheduler zu verbinden.

Wenn Hardware-Monitoring in einem Tool lebt und Scheduling in einem anderen, ohne gemeinsamen Health-Status, kann der Scheduler weiterhin Jobs auf eine Karte legen, von der der Betrieb bereits weiß, dass sie unzuverlässig ist.

Wie funktionieren Quotas in einem heterogenen Pool?

Quotas sollten sowohl steuern, wie viel ein Team verbrauchen kann, als auch, welche Ressourcenklassen es verbrauchen darf.

Eine einfache Zahl wie „10 GPUs" kann irreführend sein, wenn die Umgebung sehr unterschiedliche Beschleunigermodelle enthält.

Ein Ansatz ist, Quotas nach Resource Flavor oder Spezifikation zu vergeben. Ein Team erhält vielleicht eine Quota für eine bestimmte Trainingsklasse und eine separate Quota für Inference.

Ein anderer Ansatz ist ein Credit-Modell, bei dem unterschiedliche Ressourcentypen unterschiedlich viel von einem gemeinsamen Budget verbrauchen.

Kueue unterstützt Quotas auf Cluster-Ebene, Resource Flavors, Borrowing, Lending und Fair Sharing. Das gibt Plattform-Teams einen Kubernetes-nativen Weg, Batch- und KI-Workloads teamübergreifend zu steuern.

Für welche Methode Sie sich auch entscheiden: Halten Sie Abrechnung und Quota-Definitionen konsistent.

Wenn der Scheduler eine Ressource anders zählt als das Kostensystem, werden Nutzer die Ergebnisse anzweifeln.

Wie passen vollständige Karten, Partitionen und Sharing zusammen?

Vollständige Kartenzuweisung, Hardware-Partitionierung und Time-Sharing sind unterschiedliche Betriebsmodelle und sollten als unterschiedliche Ressourcentypen bereitgestellt werden.

Vollständige Kartenzuweisung bietet die klarste Isolation. Sie wird oft für große Trainingsjobs oder Workloads mit vorhersehbaren Performance-Anforderungen bevorzugt.

Hardware-Partitionierung, etwa NVIDIA Multi-Instance-GPU auf unterstützter Hardware, teilt eine physische GPU in isolierte Instanzen mit dedizierten Compute- und Speicherressourcen auf.

Time-Sharing lässt mehrere Workloads dieselbe physische GPU zeitversetzt nutzen. Das kann die Auslastung bei leichteren Workloads verbessern, aber die Performance-Isolation unterscheidet sich von Hardware-Partitionierung.

Bezeichnen Sie nicht alle drei einfach als „shared GPU".

Nutzer müssen verstehen, welche Performance und Isolation sie tatsächlich bekommen.

Die tieferliegende Scheduling-Mechanik wird in GPU-Resource-Pooling und Scheduling in Kubernetes behandelt.

Wie sollte Multi-Vendor-Monitoring gestaltet werden?

Multi-Vendor-Monitoring sollte gemeinsame Konzepte normalisieren und dabei herstellerspezifische Details bewahren.

Ein gemeinsames Health-Schema könnte Status, Temperatur, Power, Speichernutzung, Fehleranzahl, Auslastung und Firmware umfassen.

Bewahren Sie unter dieser gemeinsamen Ebene die rohen Hersteller-Felder auf.

Das ist wichtig für die Fehlersuche. Ein normalisiertes „warning" ist für Dashboards nützlich, aber ein Engineer braucht womöglich den originalen Sensornamen, Fehlercode oder das Hersteller-Event.

Auch die Erfassungsfrequenz braucht Überlegung.

Kritische Ausfallindikatoren verdienen womöglich schnelleres Polling oder event-getriebene Erfassung. Sich langsam ändernde Inventarfelder wie Seriennummern nicht.

Das System sollte auch Erfassungsfehler sichtbar machen. Wenn ein Treiber-Upgrade einen Metrik-Exporter kaputt macht, sollte die Plattform anzeigen, dass die Metrikquelle nicht verfügbar ist, statt stillschweigend einen alten Wert zu melden.

Kann eine Plattform sowohl GPU- als auch NPU-Ressourcen verwalten?

Ja, eine Plattform kann beides verwalten, wenn sie beide als Beschleuniger-Ressourcen mit herstellerspezifischen Adaptern unter einem gemeinsamen Ressourcenmodell behandelt.

Die gemeinsame Ebene kann Identität, Gesundheitszustand, Kapazität, Zuweisung, Workload-Bindung, Quota und Kosten abdecken.

Die Adapter-Ebene übernimmt herstellerspezifische Treiber, APIs, Metriken und Deployment-Logik.

Das ist die skalierbare Architektur.

Der Versuch, jeden Hersteller in eine fest codierte Schnittstelle zu zwingen, erzeugt meist ein brüchiges System. Ein Plugin- oder Adapter-Modell macht es einfacher, neue Beschleuniger-Familien hinzuzufügen, ohne die gesamte Plattform neu zu entwerfen.

Ein Plattform-Beispiel, das dieses generelle Modell nutzt, ist Sensaka.

Wenn ich eine heterogene Beschleuniger-Umgebung aufbauen würde, würde ich nicht mit einem „Single Pane of Glass"-Projekt anfangen. Ich würde mit einem vertrauenswürdigen Karten-Inventar und einem Ressourcen-Klassifikationsmodell beginnen. Sobald die Plattform beantworten kann, was jede Karte ist, ob sie gesund ist, was sie ausführen kann und wer sie nutzt, wird die vereinheitlichte Sicht nützlich statt nur kosmetisch.