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. Mit HPA können Sie Ihre Modellserver effizient entsprechend der Auslastung skalieren. 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.
Lernziele
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
Gängige LLM-Inferenzserver wie TGI, vLLM und NVIDIA Triton geben arbeitslastspezifische Leistungsmesswerte aus. GKE vereinfacht das Scraping und die automatische Skalierung von Arbeitslasten anhand dieser Messwerte auf Serverebene. Anhand dieser Messwerte erhalten Sie Informationen zu Leistungskennzahlen wie Batchgröße, Warteschlangengröße und Dekodierungslatenz.
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 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 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 Abschnitt zu Best Practices.
Diese Messwerte sind oft unempfindlich gegenüber Leistungs- und Trafficschwankungen und daher ein zuverlässiger Ausgangspunkt für das Autoscaling bei verschiedenen GPU-Hardwarekonfigurationen.
GPU-Messwerte
GPUs geben verschiedene Nutzungs- und Leistungsmesswerte aus und ermöglichen so workloadunabhängiges Autoscaling für jede GPU-basierte Aufgabe, einschließlich Inferenzarbeitslasten ohne benutzerdefinierte Messwerte. 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) |
Der Arbeitszyklus, also die Zeit, in der die GPU aktiv ist. | Er 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-Arbeitsspeichernutzung (DCGM_FI_DEV_FB_USED) |
Gibt an, wie viel GPU-Arbeitsspeicher zu einem bestimmten Zeitpunkt genutzt 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 CPU- und Arbeitsspeichernutzung in der Regel der primäre Autoscaling-Messwert.
Bei Inferenzarbeitslasten, die auf GPUs ausgeführt werden, empfehlen wir nicht, CPU- und Arbeitsspeichernutzung als einzige Indikatoren für die Menge der Ressourcen zu verwenden, die ein Job verbraucht, da Inferenzarbeitslasten 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
Anhand der folgenden Überlegungen und Best Practices können Sie den besten Messwert für das Autoscaling in GKE auswählen, um 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 die automatische Skalierung der Warteschlangengröße, wenn Sie Durchsatz und Kosten optimieren und Ihre Latenzziele mit dem maximalen Durchsatz der maximalen Batchgröße Ihres Modellservers erreichbar sind.
Die Größe der Warteschlange steht in direktem Zusammenhang mit der Anfragelatenz. Eingehende Anfragen werden in der Warteschlange des Modellservers angeordnet, bevor sie verarbeitet werden. Diese Wartezeit erhöht die Gesamtlatenz. Die Größe der Warteschlange ist ein empfindlicher Indikator für Lastspitzen, da die Warteschlange bei erhöhter Last schnell voll 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 unabhängig von der Arbeitslast, da die Warteschlangengröße unabhängig von der Anfragegröße, dem Modell oder der Hardware ist.
Wenn Sie den Durchsatz maximieren und dabei die Konfiguration Ihres Modellservers einhalten möchten, sollten Sie sich auf die Größe der Warteschlange konzentrieren. Die Größe der Warteschlange 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 Batchplatz verfügbar ist. Die Warteschlange wächst merklich, wenn der Batch-Speicherplatz begrenzt ist. Verwenden Sie den Wachstumspunkt daher als Signal, um eine Skalierung einzuleiten. Durch die Kombination der automatischen Skalierung der Warteschlangengröße mit einem 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.
Um den richtigen Grenzwert für die Warteschlangengröße auszuwählen, beginnen Sie mit einem Wert zwischen 3 und 5 und erhöhen Sie ihn schrittweise, bis die Anfragen die gewünschte Latenz erreichen. Verwenden Sie das Tool locust-load-inference 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 Cloud Monitoring-Dashboard erstellen, um das Verhalten des Messwerts zu visualisieren.
Beschränkungen
Die Größe der Warteschlange 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 die batchgrößenbasierte Autoscaling-Funktion, wenn Sie latenzempfindliche Arbeitslasten haben, bei denen die warteschlangenbasierte Skalierung nicht schnell genug ist, um Ihre Anforderungen zu erfüllen.
Die Batchgröße steht in direktem Zusammenhang mit dem Durchsatz und der Latenz einer eingehenden Anfrage. Die Batchgröße ist ein guter Indikator für Lastspitzen, da bei einer höheren Auslastung dem vorhandenen Batch mehr 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. So 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 Muster bei der Batchgröße beobachten und mithilfe von Autoscaling gleichzeitige Anfragen bei Lastspitzen 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 Grenzwert für die Batchgröße auszuwählen, erhöhen Sie experimentell die Last auf Ihrem Server und beobachten Sie, wo die Batchgröße Spitzen aufweist. Wir empfehlen außerdem, das Tool locust-load-inference 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 senken Sie ihn, bis die gewünschte Latenz erreicht ist.
Sie können auch ein benutzerdefiniertes Cloud Monitoring-Dashboard 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. Unterschiedliche Anfragegrößen und Hardwareeinschränkungen erschweren die Suche nach dem richtigen Grenzwert 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 Replicas 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 gewünschte Reaktionsfähigkeit an.
- Skalierungsrichtlinien: Mit dieser HPA-Konfigurationsoption können Sie das Verhalten beim Hoch- und Herunterskalieren optimieren. Mit dem Richtlinienlimit „Pods“ können Sie die absolute Anzahl der geänderten Repliken pro Zeiteinheit angeben. Mit dem Richtlinienlimit „Prozent“ können Sie die prozentuale Änderung angeben.
Weitere Informationen zu diesen Optionen finden Sie in der Open-Source-Dokumentation zu Kubernetes unter Horizontales Pod-Autoscaling.