BLOG | NGINX

Eine Kurzanleitung zum Skalieren von KI/ML-Workloads auf Kubernetes

NGINX-Teil-von-F5-horiz-schwarz-Typ-RGB
Ilya Krutov Miniaturbild
Ilja Krutow
Veröffentlicht am 11. Januar 2024

Beim Ausführen von Modelltraining und Inferenz für künstliche Intelligenz (KI) und maschinelles Lernen (ML) auf Kubernetes wird die dynamische Skalierung nach oben und unten zu einem kritischen Element. Das Training von KI-Modellen erfordert nicht nur Speicher und Netzwerke mit hoher Bandbreite zur Datenaufnahme, sondern auch umfangreiche (und teure) Rechenleistung, meist durch GPUs oder andere spezialisierte Prozessoren. Selbst beim Einsatz vorab trainierter Modelle sind Aufgaben wie die Bereitstellung und Feinabstimmung von Modellen in der Produktion immer noch rechenintensiver als die meisten Unternehmens-Workloads.

Cloud-native Kubernetes erlaubt Ihnen schnelle Skalierung – nach oben und unten. Es sorgt außerdem für mehr Agilität und eine kosteneffiziente Nutzung von Ressourcen bei dynamischen Workloads in hybriden Multi-Cloud-Umgebungen.

In diesem Blog behandeln wir die drei gängigsten Möglichkeiten zum Skalieren von KI-/ML-Workloads auf Kubernetes, damit Sie optimale Leistung, Kosteneinsparungen und Anpassungsfähigkeit für dynamische Skalierung in unterschiedlichen Umgebungen erreichen.

Drei Skalierungsmodalitäten für KI/ML-Workloads auf Kubernetes

Die drei gängigen Methoden zum Skalieren einer Arbeitslast durch Kubernetes sind Horizontal Pod Autoscaler (HPA), Vertical Pod Autoscaler (VPA) und Cluster Autoscaler.

Hier ist eine Aufschlüsselung dieser drei Methoden:

  • HPA – Das Äquivalent zum Hinzufügen von Instanzen oder Pod-Replikaten zu einer Anwendung, um ihr mehr Skalierbarkeit, Kapazität und Durchsatz zu verleihen.
  • VPA – Das Äquivalent zur Größenanpassung eines Pods, um ihm eine höhere Kapazität mit mehr Rechenleistung und Speicher zu verleihen.
  • Cluster Autoscaler – Passt die Anzahl der Knoten in einem Kubernetes-Cluster automatisch an den aktuellen Bedarf der Pods an.

Jede Modalität hat ihre Vorteile für das Modelltraining und die Inferenz, die Sie in den folgenden Anwendungsfällen erkunden können.

HPA-Anwendungsfälle

Verteilte KI-Modelltrainings- und Inferenz-Workloads lassen sich häufig horizontal skalieren, indem Sie weitere Pods hinzufügen, um den Trainingsprozess oder die Anfragen schneller zu bearbeiten. So profitieren die Workloads von HPA, das die Anzahl der Pods anpasst – basierend auf Metriken wie CPU- und Speicherauslastung oder auch benutzerdefinierten und externen Metriken, die für Ihre Workloads relevant sind. Wenn sich die Workloads im Verlauf der Zeit ändern, passt HPA die Pod-Anzahl dynamisch an und sorgt so für optimale Ressourcenauslastung.

Ein weiterer Aspekt der horizontalen Skalierung von KI-Workloads in Kubernetes ist der Lastausgleich. Um eine optimale Leistung und zeitnahe Anforderungsverarbeitung sicherzustellen, müssen eingehende Anforderungen auf mehrere Instanzen oder Pods verteilt werden. Aus diesem Grund ist ein Ingress-Controller eines der idealen Tools, das in Verbindung mit HPA verwendet werden kann.

Kubernetes mit Ingress Controller-Diagramm

VPA-Anwendungsfälle

KI-Modell-Trainingsaufgaben verbrauchen häufig erhebliche CPU-, GPU- und Speicherressourcen. VPA passen diese Ressourcenzuweisungen flexibel an. So stellen wir sicher, dass jeder Pod ausreichend Ressourcen hat, um die Trainingslast effizient zu bewältigen, und dass alle zugewiesenen Pods genug Rechenleistung für die Berechnungen erhalten. Außerdem schwanken die Speicheranforderungen bei großen Modellen während des Trainings stark. VPA hilft, Speicherüberlauf-Fehler zu vermeiden, indem die Speicherzuweisung bei Bedarf erhöht wird.

Technisch gesehen können Sie HPA und VPA zusammen einsetzen, doch erfordert dies eine präzise Systemkonfiguration, um Konflikte zu verhindern, da beide versuchen könnten, dieselbe Arbeitslast unterschiedlich zu skalieren (also horizontal versus vertikal). Definieren Sie deshalb klare Grenzen für jeden Autoscaler, damit sie sich ergänzen statt widersprechen. Eine aufkommende Strategie nutzt beide mit unterschiedenem Fokus – etwa HPA zur Skalierung über mehrere Pods anhand der Arbeitslast und VPA für die exakte Anpassung der Serverressourcen jedes Pods innerhalb der durch HPA erlaubten Spielräume.

Anwendungsfälle für Cluster Autoscaler

Der Cluster Autoscaler hilft Ihnen, die Gesamtressourcen für Rechenleistung, Speicher und Netzwerkinfrastruktur im Cluster dynamisch an die Anforderungen von KI-/ML-Arbeitslasten anzupassen. Indem Sie die Anzahl der Knoten im Cluster je nach aktuellem Bedarf anpassen, können Sie auf Makroebene effektiv Lasten verteilen. So gewährleisten Sie optimale Leistung, da KI-/ML-Workloads unvorhersehbar erhebliche Rechenressourcen benötigen.

HPA, VPA und Cluster Autoscaler haben jeweils eine Rolle

Zusammenfassend sind dies die drei Möglichkeiten, wie die automatische Skalierung von Kubernetes funktioniert und KI-Workloads zugute kommt:

  • HPA skaliert KI-Modell-Serving-Endpunkte, die unterschiedliche Anforderungsraten verarbeiten müssen.
  • VPA verteilt die Serverressourcen bei KI- und ML-Workloads so, dass jeder Pod effizient arbeitet, ohne dass Sie zu viel bereitstellen müssen.
  • Cluster Autoscaler fügt Knoten zu einem Cluster hinzu, damit Sie leistungsintensive KI-Aufgaben ausführen können, und entfernt sie, wenn der Rechenbedarf sinkt.

HPA, VPA und Cluster Autoscaler ergänzen sich in der Verwaltung von KI/ML-Workloads in Kubernetes optimal. Cluster Autoscaler sorgt dafür, dass genügend Knoten vorhanden sind, um die Anforderungen der Arbeitslast abzudecken, HPA verteilt die Arbeitslast effektiv auf mehrere Pods, und VPA optimiert die Ressourcenzuweisung dieser Pods. Gemeinsam bieten sie eine umfassende Lösung für Skalierung und Ressourcenmanagement von KI/ML-Anwendungen in Kubernetes-Umgebungen.

Besuchen Sie unsere Seite „Power and Protect Your AI Journey“, um mehr darüber zu erfahren, wie F5 und NGINX Ihnen bei der Bereitstellung, Sicherung und Optimierung Ihrer KI-/ML-Workloads helfen können.


„Dieser Blogbeitrag kann auf Produkte verweisen, die nicht mehr verfügbar und/oder nicht mehr unterstützt werden. Die aktuellsten Informationen zu verfügbaren F5 NGINX-Produkten und -Lösungen finden Sie in unserer NGINX-Produktfamilie . NGINX ist jetzt Teil von F5. Alle vorherigen NGINX.com-Links werden auf ähnliche NGINX-Inhalte auf F5.com umgeleitet."