Best Practices für das Autoscaling von LLM-Inferenzarbeitslasten mit GPUs in Google Kubernetes Engine (GKE)


In diesem Best Practices-Leitfaden finden Sie die verfügbaren Messwerte und Informationen zur Auswahl geeigneter Messwerte zum Einrichten des horizontalen Pod-Autoscalers (HPA) für Ihre Inferenzarbeitslasten in GKE. HPA ist eine effiziente Möglichkeit, um dafür zu sorgen, dass Ihre Modellserver mit Last entsprechend skaliert werden. Die Optimierung der HPA-Einstellungen ist die wichtigste Methode, um die Kosten für bereitgestellte Hardware an die Trafficanforderungen anzupassen, um die Leistungsziele Ihres Inferenzservers zu erreichen.

Beispiele zur Implementierung dieser Best Practices finden Sie unter Autoscaling für LLM-Arbeitslasten auf GPUs mit GKE konfigurieren.

Lernziele

Dieser Leitfaden richtet sich an Kunden der generativen KI, neue oder bestehende GKE-Nutzer, ML-Entwickler und LLMOps-Entwickler (DevOps), die ihre LLM-Arbeitslasten mithilfe von GPUs mit Kubernetes optimieren möchten.

Nachdem Sie diese Anleitung gelesen haben, sollten Sie Folgendes können:

  • Autoscaling-Messwerte für LLM-Inferenz verstehen
  • Die allgemeinen Vor- und Nachteile bei der Auswahl der Messwerte für das Autoscaling verstehen

Übersicht über Autoscaling-Messwerte für die LLM-Inferenz

Die folgenden Messwerte sind in GKE verfügbar:

Servermesswerte

Beliebte LLM-Inferenzserver wie TGI, vLLM und NVIDIA Triton geben arbeitslastspezifische Leistungsmesswerte aus. GKE vereinfacht das Scraping und das Autoscaling von Arbeitslasten anhand dieser Messwerte auf Serverebene. Mit diesen Messwerten erhalten Sie Einblick in Leistungsindikatoren wie Batchgröße, Warteschlangengröße und Decodierungslatenzen.

Basierend auf diesen Messwerten können Sie das Autoscaling an den relevantesten Leistungsindikatoren ausrichten. Zu den wichtigsten Messwerten auf Serverebene für das Autoscaling gehören:

  • Warteschlangengröße: Die Anzahl der Anfragen, die in der Serverwarteschlange auf die Verarbeitung warten. Verwenden Sie die Warteschlangengröße, um den Durchsatz zu maximieren und die Kosten innerhalb eines bestimmten Ziellatenz-Schwellenwerts zu minimieren. Weitere Informationen finden Sie im zugehörigen Abschnitt mit Best Practices.
  • Batchgröße: Die Anzahl der Anfragen, bei denen Inferenz auftritt. Verwenden Sie die Batchgröße, um niedrigere Ziellatenzschwellenwerte als die Warteschlangengröße zu erreichen. Weitere Informationen finden Sie im zugehörigen Abschnitt mit Best Practices.

Diese Messwerte sind oft beständig gegenüber Leistungs- und Trafficschwankungen. Daher sind sie ein zuverlässiger Ausgangspunkt für das Autoscaling auf verschiedenen GPU-Hardware-Konfigurationen.

GPU-Messwerte

GPUs geben verschiedene Nutzungs- und Leistungsmesswerte aus und bieten arbeitslastunabhängiges Autoscaling für jede GPU-basierte Aufgabe, einschließlich der Ableitung von Arbeitslasten, die keine benutzerdefinierten Messwerte haben. Informationen zum Einrichten der DCGM-Erfassung finden Sie unter DCGM-Erfassung konfigurieren.

Gängige GPU-Messwerte für GKE:

GPU-Messwert Nutzung Beschränkungen
GPU-Auslastung (DCGM_FI_DEV_GPU_UTIL) Misst den Arbeitszyklus, d. h. die Zeit, während der die GPU aktiv ist. Es wird nicht gemessen, wie viel Arbeit ausgeführt wird, während die GPU aktiv ist. Dies erschwert die Zuordnung von inferenzbasierten Leistungsmesswerten wie Latenz und Durchsatz zu einem GPU-Auslastungsschwellenwert.
GPU-Arbeitsspeichernutzung (DCGM_FI_DEV_FB_USED) Gibt an, wie viel GPU-Arbeitsspeicher zu einem bestimmten Zeitpunkt verwendet wird. Dies ist nützlich für Arbeitslasten, die die dynamische Zuordnung von GPU-Arbeitsspeicher implementieren. Bei Arbeitslasten, die GPU-Arbeitsspeicher vorab zuweisen oder niemals Arbeitsspeicher freigeben (z. B. Arbeitslasten, die auf TGI und vLLM ausgeführt werden), funktioniert dieser Messwert nur zum Hochskalieren und nicht zum Herunterskalieren, wenn der Traffic abnimmt.

CPU-Messwerte

In GKE ist HPA mit CPU- und arbeitsspeicherbasiertem Autoscaling sofort einsatzbereit. Für Arbeitslasten, die auf CPUs ausgeführt werden, sind die Messwerte zur CPU- und Arbeitsspeicherauslastung in der Regel der primäre Messwert für das Autoscaling.

Für Inferenzarbeitslasten, die auf GPUs ausgeführt werden, empfehlen wir die CPU- und Arbeitsspeicherauslastung nicht als einzigen Indikator für die Menge der Ressourcen, die ein Job verbraucht, da abgeleitete Arbeitslasten hauptsächlich auf GPU-Ressourcen basieren. Die Verwendung von CPU-Messwerten allein für das Autoscaling kann daher zu suboptimaler Leistung und suboptimalen Kosten führen.

Überlegungen zur Auswahl der Autoscaling-Messwerte

Beachten Sie die folgenden Überlegungen und Best Practices, um den besten Messwert für das Autoscaling in GKE auszuwählen, um Ihre Leistungsziele für Inferenzarbeitslasten zu erreichen.

Best Practice: Verwenden Sie die Warteschlangengröße, um den Durchsatz zu maximieren und die Kosten innerhalb eines bestimmten Ziellatenz-Schwellenwerts zu minimieren

Wir empfehlen das Autoscaling der Warteschlangengröße bei der Optimierung von Durchsatz und Kosten und wenn Ihre Latenzziele mit dem maximalen Durchsatz der maximalen Batchgröße Ihres Modellservers erreichbar sind.

Die Warteschlangengröße hängt direkt mit der Anfragelatenz zusammen. Eingehende Anfragen werden vor der Verarbeitung auf dem Modellserver in die Warteschlange gestellt. Diese Warteschlangenzeit erhöht die Gesamtlatenz. Die Warteschlangengröße ist ein sensibler Indikator für Lastspitzen, da eine erhöhte Last die Warteschlange schnell ausfüllt.

Durch das auf der Warteschlangengröße basierende Autoscaling wird die Warteschlangenzeit minimiert. Dazu wird die Warteschlange unter Last hochskaliert und wird herunterskaliert, wenn die Warteschlange leer ist. Dieser Ansatz lässt sich relativ einfach implementieren und ist weitgehend arbeitslastunabhängig, da die Größe der Warteschlange von der Anfragegröße, dem Modell oder der Hardware unabhängig ist.

Wenn Sie den Durchsatz unter Berücksichtigung der Konfiguration Ihres Modellservers maximieren möchten, sollten Sie sich auf die Warteschlangengröße konzentrieren. Die Warteschlangengröße erfasst ausstehende, nicht verarbeitete Anfragen. vLLM und TGI verwenden kontinuierliches Batching, das gleichzeitige Anfragen maximiert und die Warteschlange niedrig hält, wenn Batchspeicherplatz verfügbar ist. Die Warteschlange wächst merklich, wenn der Batchspeicherplatz begrenzt ist. Verwenden Sie daher den Wachstumspunkt als Signal zum Initiieren des Hochskalierens. Durch die Kombination der automatischen Skalierung der Warteschlangengröße mit dem optimierten Batchdurchsatz können Sie den Anfragedurchsatz maximieren.

Optimalen Schwellenwert für die Warteschlangengröße für HPA bestimmen

Achten Sie auf die HPA-Toleranz, die standardmäßig bei einem Nicht-Aktionsbereich von 0,1 um den Zielwert liegt, um Schwankungen zu dämpfen.

Zur Auswahl des richtigen Schwellenwerts für die Warteschlangengröße beginnen Sie mit einem Wert zwischen 3 und 5 und erhöhen ihn schrittweise, bis die Anfragen die bevorzugte Latenz erreichen. Verwenden Sie das locust-load-inference-Tool zum Testen. Für Schwellenwerte unter 10 passen Sie die HPA-Einstellungen für das Hochskalieren an, um Trafficspitzen zu verarbeiten.

Sie können auch ein benutzerdefiniertes Cloud Monitoring-Dashboard erstellen, um das Messwertverhalten zu visualisieren.

Beschränkungen

Die Warteschlangengröße steuert gleichzeitige Anfragen nicht direkt. Daher kann ihr Schwellenwert keine geringere Latenz garantieren, als die maximale Batchgröße zulässt. Als Behelfslösung können Sie die maximale Batchgröße manuell reduzieren oder automatisch anhand der Batchgröße skalieren.

Best Practice: Verwenden Sie die Batchgröße, um niedrigere Ziellatenzschwellenwerte als die Warteschlangengröße zu erreichen

Wir empfehlen, ein Batchgrößen-basiertes Autoscaling zu wählen, wenn Sie latenzempfindliche Arbeitslasten haben, bei denen die warteschlangenbasierte Skalierung nicht schnell genug ist, um Ihren Anforderungen gerecht zu werden.

Die Batchgröße bezieht sich direkt auf den Durchsatz und die Latenz einer eingehenden Anfrage. Die Batchgröße ist ein guter Indikator für Lastspitzen, da eine Erhöhung der Last dazu führt, dass mehr Anfragen zum vorhandenen Batch hinzugefügt werden, was eine größere Batchgröße verursacht. Im Allgemeinen gilt: Je größer die Batchgröße, desto höher die Latenz. Durch das Autoscaling anhand der Batchgröße wird sichergestellt, dass Ihre Arbeitslast hochskaliert wird, um die Anzahl der parallel verarbeiteten Anfragen zu maximieren, und herunterskaliert, wenn weniger Anfragen parallel verarbeitet werden.

Wenn die Warteschlangengröße bereits Ihre Latenzziele erreicht, priorisieren Sie sie beim Autoscaling. Dadurch werden sowohl der Durchsatz als auch die Kosteneffizienz maximiert. Die Batchgröße ist jedoch für latenzempfindliche Arbeitslasten wertvoll. Größere Batches erhöhen den Durchsatz, erhöhen aber auch die Latenz, da die Vorabfüllphase einiger Anfragen die Decodierungsphase anderer in kontinuierlichen Batchmodellservern unterbricht. Sie können Batchgrößenmuster überwachen und Autoscaling verwenden, um gleichzeitige Anfragen während Lastspitzen zu minimieren.

Wenn Ihr Modellserver dies zulässt, empfehlen wir, die maximale Batchgröße als zusätzlichen Abstimmungsmechanismus anzupassen. Sie können dies auch mit warteschlangenbasiertem Autoscaling kombinieren.

Optimalen Schwellenwert für die Batchgröße für HPA bestimmen

Achten Sie auf die HPA-Toleranz, die standardmäßig bei einem Nicht-Aktionsbereich von 0,1 um den Zielwert liegt, um Schwankungen zu dämpfen.

Um den richtigen Schwellenwert für die Batchgröße auszuwählen, erhöhen Sie experimentell die Last auf Ihrem Server und beobachten Sie, wo die Batchgröße am höchsten ist. Zum Testen empfehlen wir außerdem die Verwendung des locust-load-inference-Tools. Nachdem Sie die maximale Batchgröße ermittelt haben, legen Sie den anfänglichen Zielwert etwas unter diesem Höchstwert fest und verringern ihn, bis die bevorzugte Latenz erreicht ist.

Sie können auch ein benutzerdefiniertes Cloud Monitoring-Dashboard erstellen, um das Messwertverhalten zu visualisieren.

Beschränkungen

Autoscaling anhand der Batchgröße ist zwar hilfreich für die Latenzsteuerung, hat aber Einschränkungen. Unterschiedliche Anfragegrößen und Hardwarebeschränkungen erschweren die Ermittlung des richtigen Schwellenwerts für die Batchgröße.

Best Practice: HPA-Konfiguration optimieren

Wir empfehlen, diese HPA-Konfigurationsoptionen festzulegen:

  • Stabilisierungsfenster: Mit dieser HPA-Konfigurationsoption können Sie schnelle Änderungen der Replikatzahl aufgrund schwankender Messwerte verhindern. Standardmäßig betragen die Standardeinstellungen 5 Minuten für das Herunterskalieren (wobei ein vorzeitiges Herunterskalieren vermieden wird) und 0 für das Hochskalieren (dadurch wird die Reaktionsfähigkeit sichergestellt). Passen Sie den Wert an die Schwankungen der Arbeitslast und Ihre bevorzugte Reaktionsfähigkeit an.
  • Skalierungsrichtlinien: Mit dieser HPA-Konfigurationsoption können Sie das Verhalten beim Hoch- und Herunterskalieren optimieren. Sie können das Richtlinienlimit „Pods“ festlegen, um die absolute Anzahl der Replikate anzugeben, die pro Zeiteinheit geändert wurden, und das Richtlinienlimit „Prozent“, um die prozentuale Änderung anzugeben.

Weitere Informationen zu diesen Optionen finden Sie in der Open-Source-Dokumentation zu Kubernetes unter Horizontales Pod-Autoscaling.

Nächste Schritte