Bei der Ausführung von Training und Inferenz für Modelle der künstlichen Intelligenz (KI) und des maschinellen Lernens (ML) auf Kubernetes ist die dynamische Skalierung nach oben und unten von entscheidender Bedeutung. Neben Speicher- und Netzwerkressourcen mit hoher Bandbreite für die Datenaufnahme erfordert das Training von KI-Modellen auch erhebliche (und kostspielige) Rechenleistung, die größtenteils von GPUs oder anderen spezialisierten Prozessoren bereitgestellt wird. Selbst beim Einsatz vortrainierter Modelle sind Aufgaben wie die Modellbereitstellung und Feinabstimmung in der Produktion noch immer rechenintensiver als die meisten Unternehmens-Workloads.
Cloud-natives Kubernetes ist für eine schnelle Skalierung nach oben und unten ausgelegt. Zudem ermöglicht es mehr Agilität und eine kosteneffiziente Ressourcennutzung für dynamische Workloads in hybriden Multi-Cloud-Umgebungen.
In diesem Blogbeitrag stellen wir die drei gängigsten Methoden zur Skalierung von KI-/ML-Workloads auf Kubernetes vor, mit denen Sie optimale Leistung, Kosteneinsparungen und Anpassungsfähigkeit bei der dynamischen Skalierung in unterschiedlichen Umgebungen erreichen können.
Drei Skalierungsarten für KI/ML-Workloads auf Kubernetes
Die drei gängigen Methoden, mit denen Kubernetes eine Arbeitslast skaliert, sind der Horizontal Pod Autoscaler (HPA), der Vertical Pod Autoscaler (VPA) und der Cluster Autoscaler.
Hier ist eine Übersicht über diese drei Methoden:
- HPA – Dies entspricht dem Hinzufügen von Instanzen oder Pod-Replikaten zu einer Anwendung, wodurch sie besser skaliert sowie mehr Kapazität und Durchsatz erhält.
- VPA – Dies entspricht der Größenanpassung eines Pods, um ihm durch mehr Rechenleistung und Arbeitsspeicher eine höhere Kapazität zu verleihen.
- Cluster Autoscaler – Erhöht oder verringert automatisch die Anzahl der Knoten in einem Kubernetes-Cluster, abhängig vom aktuellen Ressourcenbedarf der Pods.
Jede Modalität bietet Vorteile für das Training und die Inferenz von Modellen, die Sie anhand der folgenden Anwendungsfälle näher kennenlernen können.
HPA-Anwendungsfälle
In vielen Fällen lassen sich verteilte Workloads für das Training und die Inferenz von KI-Modellen horizontal skalieren (d. h. durch das Hinzufügen weiterer Pods, um den Trainingsprozess oder die Verarbeitung von Anfragen zu beschleunigen). Dadurch können die Workloads von HPA profitieren, das die Anzahl der Pods anhand von Metriken wie CPU- und Arbeitsspeicherauslastung oder sogar anhand benutzerdefinierter und externer, für den jeweiligen Workload relevanter Metriken erhöhen kann. In Szenarien, in denen der Workload im Laufe der Zeit schwankt, kann HPA die Anzahl der Pods dynamisch anpassen, um eine optimale Ressourcenauslastung sicherzustellen.
Ein weiterer Aspekt der horizontalen Skalierung von KI-Workloads in Kubernetes ist der Lastenausgleich. Um eine optimale Leistung und die zeitnahe Verarbeitung von Anfragen zu gewährleisten, müssen eingehende Anfragen auf mehrere Instanzen oder Pods verteilt werden. Daher eignet sich in Verbindung mit HPA insbesondere ein Ingress-Controller.
VPA-Anwendungsfälle
Trainingsaufgaben für KI-Modelle sind häufig ressourcenintensiv und erfordern erhebliche CPU-, GPU- und Arbeitsspeicherressourcen. VPA kann diese Ressourcenzuweisungen dynamisch anpassen. Dadurch wird sichergestellt, dass jeder Pod über genügend Ressourcen verfügt, um die Trainingslast effizient zu bewältigen, und dass alle zugewiesenen Pods ausreichend Rechenkapazität für die Berechnungen haben. Darüber hinaus kann der Speicherbedarf beim Training großer Modelle erheblich schwanken. VPA kann dazu beitragen, Fehler aufgrund unzureichenden Arbeitsspeichers zu vermeiden, indem die Speicherzuweisung bei Bedarf erhöht wird.
Obwohl es technisch möglich ist, HPA und VPA gemeinsam zu verwenden, ist eine sorgfältige Konfiguration erforderlich, um Konflikte zu vermeiden, da sie versuchen könnten, dieselbe Workload auf unterschiedliche Weise zu skalieren (d. h. horizontal bzw. vertikal). Die Zuständigkeitsbereiche der beiden Autoscaler müssen klar definiert werden, damit sie sich ergänzen, anstatt miteinander in Konflikt zu geraten. Ein neuer Ansatz besteht darin, beide mit unterschiedlichen Geltungsbereichen einzusetzen – beispielsweise HPA zur Workload-basierten Skalierung über mehrere Pods hinweg und VPA zur Feinabstimmung der Ressourcenzuweisung jedes einzelnen Pods innerhalb der von HPA festgelegten Grenzen.
Anwendungsfälle für den Cluster Autoscaler
Cluster Autoscaler kann dabei helfen, den gesamten Pool der clusterweit verfügbaren Rechen-, Speicher- und Netzwerkinfrastrukturressourcen dynamisch an die Anforderungen von KI-/ML-Workloads anzupassen. Indem eine Organisation die Anzahl der Knoten in einem Cluster entsprechend dem aktuellen Bedarf anpasst, kann sie die Last auf Makroebene verteilen. Dies ist notwendig, um eine optimale Leistung sicherzustellen, da KI-/ML-Workloads unvorhersehbar erhebliche Rechenressourcen beanspruchen können.
HPA, VPA und Cluster Autoscaler haben jeweils eine eigene Rolle
Zusammenfassend lässt sich sagen, dass Kubernetes-Autoscaling auf drei Arten funktioniert und KI-Workloads zugutekommt:
- HPA skaliert Endpunkte für die Bereitstellung von KI-Modellen, die unterschiedliche Anfrageraten bewältigen müssen.
- VPA optimiert die Ressourcenzuweisung für KI-/ML-Workloads und stellt sicher, dass jeder Pod über genügend Ressourcen für eine effiziente Verarbeitung verfügt, ohne dass zu viele Ressourcen bereitgestellt werden.
- Cluster Autoscaler fügt einem Cluster Knoten hinzu, damit dieser ressourcenintensive KI-Aufgaben bewältigen kann, oder entfernt Knoten, wenn der Rechenbedarf gering ist.
HPA, VPA und Cluster Autoscaler ergänzen sich bei der Verwaltung von KI-/ML-Workloads in Kubernetes. Cluster Autoscaler stellt sicher, dass genügend Knoten vorhanden sind, um die Workload-Anforderungen zu erfüllen, HPA verteilt Workloads effizient auf mehrere Pods und VPA optimiert die Ressourcenzuweisung dieser Pods. Zusammen bieten sie eine umfassende Lösung für die Skalierung und Ressourcenverwaltung von KI-/ML-Anwendungen in Kubernetes-Umgebungen.
Besuchen Sie unsere Seite „Ihre KI-Reise leistungsstark und sicher gestalten“, um mehr darüber zu erfahren, wie F5 und NGINX Sie bei der Bereitstellung, Absicherung und Optimierung Ihrer KI-/ML-Workloads unterstützen können.
Über den Autor
Ähnliche Blogbeiträge
Die Zukunft von NGINX: Zurück zu unseren Open-Source-Wurzeln
Beim NGINX Sprint 2022 besinnen wir uns auf unsere Open-Source-Wurzeln. Erfahren Sie mehr über die Initiativen, die wir im kommenden Jahr verfolgen, und teilen Sie uns mit, was Sie sich wünschen.
Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen
Ein Ingress-Controller kann eines der leistungsstärksten Tools in Ihrem Kubernetes-Stack sein. Erfahren Sie, wie Sie Ihre Ingress-Anforderungen ermitteln, um die beste Option auszuwählen.
Bereitstellung des NGINX Ingress Controllers auf Amazon EKS: So haben wir getestet
Wir haben kürzlich den Lösungsleitfaden zum NGINX Ingress Controller um Empfehlungen zur Dimensionierung für Amazon Elastic Kubernetes Service (EKS) ergänzt. In diesem Blogbeitrag erläutern wir, wie wir diese Empfehlungen erarbeitet haben, und stellen Ihnen alle Informationen zur Verfügung, die Sie benötigen, um selbst ähnliche Tests durchzuführen.
Protokollierung des Datenverkehrs zwischen NGINX und Upstream-Servern bei CDN77
Bei der Fehlersuche bei Datenverkehrsproblemen zwischen NGINX und Upstream-Servern konnte CDN77 die benötigten Daten nur aus dem Fehlerprotokoll mit aktivierter Debug-Ausgabe beziehen, was die Leistung beeinträchtigt und riesige Dateien erzeugt. Daher entwickelte das Team ein neues benutzerdefiniertes Modul, das ausschließlich die benötigten Daten protokolliert.
Ankündigung von NGINX Plus R16
NGINX Plus R16 ist eine einheitliche, elastische Ingress- und Egress-Schicht für Anwendungen, die die Funktionen eines Load Balancers, API-Gateways und einer WAF vereint und neue Features wie clusterfähige Ratenbegrenzung, Schlüssel-Wert-Speicher, „Random with Two Choices“, verbessertes UDP-Load-Balancing und vieles mehr bietet.
5 Gründe für den Umstieg auf softwarebasiertes Load Balancing
Entdecken Sie fünf Gründe für den Wechsel zu einem softwarebasierten Load Balancer wie NGINX Plus, darunter Kosteneinsparungen, die Einführung von DevOps und eine einheitliche Lösung für alle Umgebungen.