Best Practices für das Autoscaling von Inferenzen für LLM-Arbeitslasten (Large Language Model) 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 sicherzustellen, dass Ihre Modellserver entsprechend der Last 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 für die Implementierung dieser Best Practices finden Sie unter Autoscaling für LLM-Arbeitslasten auf GPUs mit GKE konfigurieren.

Eine konsolidierte Übersicht über alle GKE-Best Practices finden Sie unter Best Practices für GKE.

Ziele

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

Nachdem Sie diesen Leitfaden 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 Erfassen und Autoscaling von Arbeitslasten basierend auf diesen Messwerten auf Serverebene. Mit diesen Messwerten können Sie Einblicke in Leistungsindikatoren wie Batchgröße, Warteschlangengröße und Decodierungslatenzen erhalten.

Basierend auf diesen Messwerten können Sie das Autoscaling an den relevantesten Leistungsindikatoren ausrichten. Wichtige Messwerte auf Serverebene für das Autoscaling sind:

  • 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 entsprechenden Abschnitt zu 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 entsprechenden Abschnitt zu Best Practices.

Diese Messwerte sind oft widerstandsfähig gegenüber Leistungs- und Trafficschwankungen und daher ein zuverlässiger Ausgangspunkt für das Autoscaling in verschiedenen GPU-Hardwarekonfigurationen.

GPU-Messwerte

GPUs geben verschiedene Nutzungs- und Leistungsmesswerte aus, die ein arbeitslastunabhängiges Autoscaling für jede GPU-basierte Aufgabe ermöglichen, einschließlich Inferenzarbeitslasten ohne benutzerdefinierte Messwerte. Informationen zum Einrichten der DCGM-Erfassung finden Sie unter DCGM-Erfassung konfigurieren.

Häufige GPU-Messwerte für GKE sind:

GPU-Messwert Nutzung Beschränkungen
GPU-Auslastung (DCGM_FI_DEV_GPU_UTIL) Misst den Arbeitszyklus, also die Zeit, in der die GPU aktiv ist. Misst nicht, wie viel Arbeit erledigt wird, während die GPU aktiv ist. Dies erschwert die Zuordnung von inferenzbasierten Leistungsmesswerten wie Latenz und Durchsatz zu einem GPU-Auslastungsschwellenwert.
GPU-Speicherauslastung (DCGM_FI_DEV_FB_USED) Misst, 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. Bei Arbeitslasten, die auf CPUs ausgeführt werden, sind die Messwerte für die CPU- und Speicherauslastung 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 Speicherauslastung nicht als einzige Indikatoren für die Menge der von einem Job verbrauchten Ressourcen, da Inferenzarbeitslasten hauptsächlich auf GPU-Ressourcen angewiesen sind. 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

Berücksichtigen Sie die folgenden Überlegungen und Best Practices, um den besten Messwert für das Autoscaling in GKE auszuwählen und die Leistungsziele Ihrer Inferenzarbeitslast 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, wenn Sie den Durchsatz und die Kosten optimieren möchten und Ihre Latenzziele mit dem maximalen Durchsatz der maximalen Batchgröße Ihres Modellservers erreichbar sind.

Die Warteschlangengröße korreliert direkt mit der Anfragelatenz. Eingehende Anfragen werden in der Warteschlange des Modellservers angeordnet, bevor sie verarbeitet werden. Diese Wartezeit erhöht die Gesamtlatenz. Die Warteschlangengröße ist ein sensibler Indikator für Lastspitzen, da die Warteschlange bei erhöhter Last schnell gefüllt wird.

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 ist relativ einfach zu implementieren und weitgehend arbeitslastunabhängig, da die Warteschlangengröße unabhängig von Anfragengröße, Modell oder Hardware ist.

Konzentrieren Sie sich auf die Warteschlangengröße, wenn Sie den Durchsatz maximieren und gleichzeitig die Konfiguration Ihres Modellservers berücksichtigen möchten. Die Warteschlangengröße gibt die Anzahl der ausstehenden Anfragen an, nicht der verarbeiteten. vLLM und TGI verwenden kontinuierliches Batching, wodurch die Anzahl gleichzeitiger Anfragen maximiert und die Warteschlange klein gehalten wird, wenn Batchspeicher verfügbar ist. Die Warteschlange wächst spürbar, wenn der Batchspeicher begrenzt ist. Verwenden Sie daher den Wachstumspunkt als Signal, um das Hochskalieren zu initiieren. Durch die Kombination von Autoscaling der Warteschlangengröße mit optimiertem Batchdurchsatz können Sie den Anfragendurchsatz 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.

Wählen Sie zum Festlegen des richtigen Schwellenwerts für die Warteschlangengröße einen Wert zwischen 3 und 5 und erhöhen Sie ihn schrittweise, bis die Anfragen die bevorzugte Latenz erreichen. Verwenden Sie das locust-load-inference Tool für Tests. 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 Dashboard in Cloud Monitoring erstellen, um das Verhalten des Messwerts zu visualisieren.

Beschränkungen

Die Warteschlangengröße steuert nicht direkt die Anzahl gleichzeitiger Anfragen. Daher kann der Grenzwert keine geringere Latenz als die maximal zulässige Batchgröße garantieren. 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, das Autoscaling basierend auf der Batchgröße auszuwählen, wenn Sie latenzempfindliche Arbeitslasten haben, bei denen die warteschlangenbasierte Skalierung nicht schnell genug ist, um Ihre Anforderungen zu erfüllen.

Die Batchgröße korreliert direkt mit dem Durchsatz und der Latenz einer eingehenden Anfrage. Die Batchgröße ist ein guter Indikator für Lastspitzen, da eine Erhöhung der Last dazu führt, dass der vorhandenen Batch weitere Anfragen hinzugefügt werden, was zu einer größeren Batchgröße führt. 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 erfüllt, priorisieren Sie sie für das 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 beobachten und das Autoscaling verwenden, um die Anzahl gleichzeitiger Anfragen bei Lastspitzen zu minimieren.

Wenn Ihr Modellserver dies zulässt, empfehlen wir, die maximale Batchgröße als zusätzlichen Optimierungsmechanismus anzupassen. Sie können dies auch mit dem warteschlangenbasierten 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 die Last auf Ihrem Server experimentell und beobachten Sie, wo die Batchgröße ihren Höchstwert erreicht. Wir empfehlen auch, das locust-load-inference Tool für Tests zu verwenden. Nachdem Sie die maximale Batchgröße ermittelt haben, legen Sie den anfänglichen Zielwert etwas unter diesem Maximum fest und verringern Sie ihn, bis die bevorzugte Latenz erreicht ist.

Sie können auch ein benutzerdefiniertes Dashboard in Cloud Monitoring erstellen, um das Verhalten des Messwerts zu visualisieren.

Beschränkungen

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

Best Practice: HPA-Konfiguration optimieren

Wir empfehlen, die folgenden HPA-Konfigurationsoptionen festzulegen:

  • Stabilisierungszeitraum: Mit dieser HPA-Konfigurationsoption können Sie schnelle Änderungen der Anzahl der Replikate 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 Volatilität Ihrer Arbeitslast und die 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 werden, und das Richtlinienlimit „Prozent“, um die prozentuale Änderung anzugeben.

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

Nächste Schritte