Das Ziel ist nicht maximale GPU-Zuteilung
Kubernetes kann eine gemeinsame Plattform für KI-Inferenz, Training, Datenaufbereitung und Batch-Scoring bieten. Es macht Beschleuniger-Workloads nicht automatisch effizient, portabel, fair eingeplant, kosteneffizient oder wiederherstellbar.
Das Ziel ist zuverlässiger geschäftlicher Output aus einer kontrollierten Menge an Beschleunigerkapazität — die geschäftliche Kennzahl sollte Kosten pro validem Ergebnis sein, nicht Kosten pro Gerätestunde.
Übliche KI-Workload-Muster
CPU oder GPU? Device Plugins und Dynamic Resource Allocation
Nutzen Sie CPUs, wenn die Latenz akzeptabel ist, der Durchsatz moderat ist oder das Modell klein ist — nutzen Sie Beschleuniger nur, wenn Messungen eine wesentliche Verbesserung bei Latenz, Durchsatz oder Kosten pro Anfrage zeigen. Eine GPU kann die verstrichene Zeit verringern und gleichzeitig die Stundenkosten erhöhen.
Device Plugins machen dem kubelet spezialisierte Ressourcen wie GPUs bekannt, damit der Scheduler Pods platzieren kann, die sie anfordern. Kubernetes bietet stabile Unterstützung für das Scheduling von AMD- und NVIDIA-GPUs über kompatible Device Plugins.
DRA ist ein neueres Framework zum Anfordern und Zuteilen von Beschleuniger-Geräten anhand von Attributen statt allein anhand des Ressourcennamens. Die Kernfunktionalität von DRA wurde mit Kubernetes 1.34 allgemein verfügbar, spätere Releases ergänzten weitere stabile Funktionen — das genaue Verhalten hängt von der installierten Version und dem Treiber ab.
GPU-Sharing-Modelle
Wählen Sie dedizierte Geräte, wenn Performance und Isolation wichtiger sind als Auslastung. Beschreiben Sie eine Time-Shared-GPU nicht als gleichwertig zu einer exklusiven.
Model Serving
Modelle können aus einem Container-Image geladen werden (reproduzierbar, aber langsame Pulls bei großen Modellen), aus Objektspeicher (unabhängiger Lebenszyklus, aber Download-Zeit und Zugangsdaten zu verwalten) oder aus einem PersistentVolume (schneller lokaler Zugriff, aber Storage-Anbindung und Backup-Abhängigkeiten).
Große Modelle können erhebliche Zeit für Download, Deserialisierung, GPU-Speicherzuteilung und das Kompilieren von Kernels benötigen. Nutzen Sie eine Startup-Probe, damit kein Traffic den Pod erreicht, bevor die Initialisierung abgeschlossen ist, und messen Sie die Warm-up-Zeit für kalten Node, kaltes Image und kalten Modell-Cache jeweils separat.
Readiness sollte bestätigen, dass das Modell geladen ist und eine Beispiel-Inferenz erfolgreich läuft — nicht nur, dass der HTTP-Prozess gestartet ist. Liveness sollte niemals von einer temporär nicht verfügbaren Model Registry oder optionaler Telemetrie abhängen, sonst kann ein gemeinsamer Ausfall eine flottenweite Neustartschleife auslösen.
KServe bietet Kubernetes Custom Resources und Controller zum Servieren prädiktiver und generativer KI-Modelle, mit Deployment-Modi, die sich in Serverless- oder Hochdichte-Serving-Komponenten integrieren. Es kann das Serving vereinfachen, führt aber auch Controller und CRDs ein, die wie jede andere Plattform-Abhängigkeit gesichert und wiederhergestellt werden müssen.
Autoscaling für Inferenz
Der HorizontalPodAutoscaler kann unterstützte Workloads anhand von Ressourcen-, Custom- oder externen Metriken skalieren — nützliche Inferenz-Signale sind Queue-Tiefe, gleichzeitige Anfragen, Tokens pro Sekunde und Beschleuniger-Sättigung.
Scale-to-Zero kann Kosten für selten genutzte Modelle senken, führt aber Cold-Start-Latenz ein — bewerten Sie Modellgröße, Download-Zeit und Kunden-Timeout, bevor Sie es für etwas mit strikter Frist für die erste Antwort einsetzen.
Verteiltes Training und Checkpoints
Kubeflow Trainer ist eine Kubernetes-native Plattform für verteiltes Training und Fine-Tuning über Frameworks wie PyTorch, JAX und XGBoost hinweg. Sie macht es nicht überflüssig, Checkpoint-Häufigkeit, Datensatzzugriff, Retry-Verhalten oder Beschleuniger-Topologie zu definieren.
Speichern Sie Checkpoints (Modellgewichte, Optimizer-Zustand, Trainingsschritt, Zufallszustand) außerhalb des Pod-Dateisystems — Objektspeicher, Shared Filesystem oder ein verwaltetes Trainings-Repository — und testen Sie den Neustart aus einem Checkpoint nach dem Verlust von Pod, Node und Cluster, nicht nur nach einem sauberen Shutdown.
Sicherheit, Datenschutz und Modelldiebstahl
KI-Workloads können Geschäftsdaten, Kunden-Prompts, Trainingsdatensätze, Modellgewichte und API-Zugangsdaten offenlegen. Ein Nutzer, der einen beliebigen Pod mit Zugriff auf die Modell-PVC oder die Object-Store-Identität erstellen kann, kann möglicherweise das Modell kopieren — prüfen Sie die effektive Berechtigung, nicht nur Ressourcennamen.
Observability und Kosten
Überwachen Sie vier Ebenen: Cluster (Pods im Zustand Pending, Scheduler-Latenz), Beschleuniger (GPU-Auslastung, Speicher, Temperatur, Fehler), Model Server (Queue-Tiefe, Latenz, Token-Rate) und Business (Rate valider Vorhersagen, Conversion, Kosten pro Anfrage).
Ein Modell kann schnell, aber ungenau sein, verfügbar, aber verzerrt, oder korrekt deployed, aber mit der falschen Version. Überwachen Sie je nach Anwendung Genauigkeit, Drift, Ablehnungsrate und die Rate unsicherer Ausgaben — nicht nur Pod- und GPU-Status.
Nützliche Stückkosten sind Kosten pro 1.000 Inferenzen, Kosten pro Million Tokens und Kosten pro Trainingslauf. Ungenutzte GPU-Kapazität kann durch Latenzziele oder eine Ausfallreserve gerechtfertigt sein — kennzeichnen Sie gerechtfertigte Reserve getrennt von zufälliger Verschwendung, da ein reines Nutzungs-Chargeback für Verfügbarkeit reservierte Kapazität unterbewerten kann.
Backup und Notfallwiederherstellung
Schützen Sie Kubernetes-Ressourcen, Serving-/Trainings-CRDs, Model-Registry-Metadaten, Modellgewichte, Trainings-Checkpoints, Evaluationsergebnisse, Container-Images und Secrets. Modell-Artefakte sollten normalerweise außerhalb des Quell-Clusters existieren — ein PersistentVolume mit der einzigen Modellkopie schafft unnötiges Wiederherstellungsrisiko.
Manche Modelle können bei einem Beschleunigerausfall eine degradierte CPU-Inferenz bereitstellen — bewerten und lasttesten Sie diesen Fallback, statt einfach anzunehmen, dass er funktioniert. Das umfassendere Wiederherstellungs-Framework beschreibt der Leitfaden zum Notfallwiederherstellungsplan.
Häufige Fehler
Der Workload braucht möglicherweise gar keinen Beschleuniger. Vergleichen Sie die Kosten pro validem Ergebnis.
Speicher-, Architektur-, Treiber- und Interconnect-Anforderungen können sich unterscheiden. Definieren Sie kompatible Device Classes.
Die Auslastung spiegelt Queue-Verzögerung, Speicher oder Kunden-Latenz möglicherweise nicht wider. Nutzen Sie Nachfrage- und Service-Metriken.
Der Ersatz des Pods entfernt die einzige Modellkopie. Nutzen Sie einen externen Model Store.
Traffic erreicht einen Prozess, der noch keine Inferenz durchführen kann. Validieren Sie ein geladenes Modell, nicht nur einen laufenden Prozess.
Logs können vertrauliche oder personenbezogene Daten offenlegen. Schwärzen Sie sie und kontrollieren Sie die Aufbewahrung.
Training kann die von Kunden benötigte Kapazität verbrauchen. Trennen Sie Prioritäten oder Node Pools.
Eine Unterbrechung verliert den gesamten Lauf. Speichern Sie dauerhafte Checkpoints.
Beschleuniger-Quota und -Verfügbarkeit können sich je nach Region unterscheiden. Verifizieren Sie die Kapazität und testen Sie die Wiederherstellung.
Checkliste für KI- und GPU-Workloads
0 / 25Häufig gestellte Fragen
Ja. Kubernetes unterstützt GPU-Scheduling über kompatible Hersteller-Device-Plugins.
Es ist ein Plugin-Framework, das spezialisierte Hardware-Ressourcen wie GPUs dem kubelet für die Workload-Zuteilung bekannt macht.
DRA ist ein Kubernetes-Framework zum Anfordern und Zuteilen von Geräten und anderen spezialisierten Ressourcen über treiberdefinierte Device Classes und Claims. Das Kern-Framework wurde mit Kubernetes 1.34 allgemein verfügbar, spätere Releases ergänzten weitere stabile Funktionen.
Möglicherweise, durch Hardware-Partitionierung, herstellerseitiges Time-Sharing, DRA-gestütztes Sharing oder Model-Server-Multiplexing. Die genaue Isolation und das Verhalten hängen von Hardware und Integration ab.
Sie können das, aber getrennte Pools bieten oft bessere Priorisierung, Performance, Kosten und Ausfallisolation.
Ja. Der HPA kann unterstützte Workloads anhand von Ressourcen-, Custom- oder externen Metriken skalieren — das Metriksystem und die Beschleunigerkapazität müssen verfügbar sein.
KServe ist eine Kubernetes-native Model-Serving-Plattform, die Custom Resources und Controller nutzt, um prädiktive und generative Inferenz-Workloads zu verwalten.
Kleine, stabile Modelle können mit dem Image verpackt werden. Große oder häufig aktualisierte Modelle passen oft besser in eine versionierte Model Registry oder einen Object Store.
Erstellen Sie dauerhafte Checkpoints mit ausreichend Trainingszustand, um nach dem Verlust von Pod, Node oder Cluster fortzusetzen.
Ja, wenn der Workload Checkpoints nutzt, unterbrechungstolerant ist und keiner strikten unmittelbaren Frist unterliegt.
Nein. Validieren Sie Modellversion, Modell-Laden, Inferenz-Output, Latenz, Queueing und Geschäftsergebnis.
Er muss auf kompatibler Hardware eingeplant werden, Latenz- und Qualitätsziele erreichen, Kosten und Mandantenzugriff kontrollieren, erwartete Ausfälle überstehen und sein Modell sowie seine Geschäftsfunktion in der freigegebenen Umgebung wiederherstellen.
Betreiben Sie den KI-Dienst, nicht nur die GPU
Kubernetes kann eine starke Control Plane für KI-Inferenz und -Training bieten — wiederholbares Deployment, Hardware-Scheduling, Workload-Isolation und gemeinsamen Betrieb. Die Risiken zeigen sich, wenn teure Beschleuniger wie gewöhnliches, austauschbares Compute behandelt werden.
Messen Sie die CPU-Baseline, wählen Sie bewusst zwischen vollständiger Geräte-Zuteilung, Partitionierung oder Sharing, speichern Sie Modelle und Checkpoints außerhalb des Quell-Clusters, skalieren Sie anhand von Queueing und Service-Nachfrage statt nur der GPU-Auslastung, und überwachen Sie die Modellqualität neben der Infrastruktur-Gesundheit. Testen Sie den Verlust von Pod, GPU-Node, das Laden eines kalten Modells und die Wiederherstellung im Ersatz-Cluster — und berechnen Sie dann die Kosten pro nützlichem Geschäftsergebnis, nicht den GPU-Auslastungsprozentsatz.