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 Methode, um dafür zu sorgen, 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.
Lernziele
Dieser Leitfaden richtet sich an Kunden von generativer KI, neue oder bestehende GKE-Nutzer, ML-Entwickler und LLMOps-Entwickler (DevOps), die daran interessiert sind, ihre LLM-Arbeitslasten mit GPUs und Kubernetes zu optimieren.
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 automatische Skalieren von Arbeitslasten anhand dieser Messwerte auf Serverebene. Mit diesen Messwerten können Sie Leistungsindikatoren wie Batchgröße, Warteschlangengröße und Decodierungslatenzen im Blick behalten.
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 Best Practices-Abschnitt.
- 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 Best Practices.
Diese Messwerte sind oft unempfindlich gegenüber Leistungs- und Traffic-Schwankungen und eignen sich daher als zuverlässiger Ausgangspunkt für das Autoscaling bei verschiedenen GPU-Hardwarekonfigurationen.
GPU-Messwerte
GPUs geben verschiedene Nutzungs- und Leistungsmesswerte aus, die ein arbeitslastunabhängiges Autoscaling für alle GPU-basierten Aufgaben 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, d. h. die Zeit, in der die GPU aktiv ist. | Es wird nicht gemessen, 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 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 Messwerte zur CPU- und Speichernutzung in der Regel der primäre Autoscaling-Messwert.
Für Inferenzarbeitslasten, die auf GPUs ausgeführt werden, empfehlen wir nicht, die CPU- und Arbeitsspeichernutzung als einzige Indikatoren für die Menge der von einem Job verbrauchten Ressourcen zu verwenden, 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 die automatische Skalierung der Warteschlangengröße, wenn Sie Durchsatz und Kosten optimieren möchten und Ihre Latenzziele mit dem maximalen Durchsatz der maximalen Batchgröße Ihres Modellservers erreicht werden können.
Die Warteschlangengröße steht in direktem Zusammenhang mit der Anfrage-Latenz. Eingehende Anfragen werden auf dem Modellserver in die Warteschlange gestellt, bevor sie verarbeitet werden. Diese Wartezeit erhöht die Gesamtlatenz. Die Warteschlangengröße ist ein sensibler Indikator für Lastspitzen, da eine erhöhte Last die Warteschlange schnell fü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 ist relativ einfach zu implementieren und weitgehend arbeitslastunabhängig, da die Warteschlangengröße unabhängig von der Anforderungsgröße, dem Modell oder der Hardware ist.
Wenn Sie den Durchsatz maximieren und gleichzeitig die Konfiguration Ihres Modellservers berücksichtigen möchten, sollten Sie sich auf die Warteschlangengröße konzentrieren. Die Warteschlangengröße gibt die Anzahl der ausstehenden Anfragen an, nicht der verarbeiteten. vLLM und TGI verwenden Continuous Batching, wodurch die Anzahl gleichzeitiger Anfragen maximiert und die Warteschlange niedrig gehalten wird, wenn Batchspeicherplatz verfügbar ist. Die Warteschlange wächst merklich, wenn der Batch-Speicherplatz begrenzt ist. Verwenden Sie den Wachstumspunkt daher als Signal, um die Skalierung zu starten. Durch die Kombination von Autoscaling der Warteschlangengröße mit optimiertem 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.
Wählen Sie zum Festlegen des richtigen Schwellenwerts für die Warteschlangengröße einen Wert zwischen 3 und 5 aus 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 Cloud Monitoring-Dashboard erstellen, um das Verhalten der Messwerte 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 maximale 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 auf der Batchgröße basierende Autoscaling zu verwenden, wenn Sie latenzempfindliche Arbeitslasten haben und das auf der Warteschlange basierende Autoscaling 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 eine Erhöhung der Last dazu führt, dass 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 Ihren Latenzzielen entspricht, 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 wichtig. 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 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 diese Funktion 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 zu ermitteln, erhöhen Sie die Last auf Ihrem Server experimentell und beobachten Sie, wo die Batchgröße ihren Höchstwert erreicht. Wir empfehlen außerdem, das Tool locust-load-inference für Tests zu verwenden. Sobald 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 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. Aufgrund der unterschiedlichen Anfrageszenarien und Hardwarebeschränkungen ist es schwierig, den richtigen Schwellenwert für die Batchgröße zu finden.
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 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 Repliken angeben, die pro Zeiteinheit geändert werden, und mit dem Richtlinienlimit „Prozent“ die prozentuale Änderung.
Weitere Informationen zu diesen Optionen finden Sie in der Open-Source-Dokumentation zu Kubernetes unter Horizontales Pod-Autoscaling.