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 JetStream-Inferenzarbeitslasten mit einem einzelnen Host und TPUs in GKE. HPA ist eine effiziente Methode, um dafür zu sorgen, dass Ihre Modell-Server 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 TPUs mit GKE konfigurieren.
Eine konsolidierte Übersicht aller Best Practices für GKE 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 daran interessiert sind, ihre JetStream-Arbeitslasten mit einem einzelnen Host mithilfe von TPUs mit Kubernetes zu optimieren.
Nachdem Sie diesen Leitfaden gelesen haben, sollten Sie Folgendes können:
- Wichtige Autoscaling-Messwerte für die JetStream-Inferenz mit einem einzelnen Host verstehen
- Die allgemeinen Vor- und Nachteile bei der Auswahl der Messwerte für das Autoscaling verstehen
Übersicht über Autoscaling-Messwerte für die JetStream-Inferenz
Wir empfehlen die Verwendung der folgenden Messwerte:
Servermesswerte
JetStream bietet wie viele andere LLM-Inferenzserver Leistungsmesswerte. GKE vereinfacht das Monitoring und Autoscaling von JetStream anhand dieser Messwerte auf Serverebene. Wenn Sie Autoscaling konfigurieren möchten, müssen Sie zuerst verstehen, wie sich die JetStreams-Anfragepipeline auf wichtige Leistungskennzahlen auswirkt. Alle eingehenden Anfragen durchlaufen eine Prefill-Warteschlange, eine Transfer-Warteschlange und eine Generierungs-Warteschlange, bevor sie zu einer Decodierungsanfrage werden. JetStream akzeptiert Decodierungsanfragen fortlaufend und verarbeitet sie gleichzeitig mit einer festen Anzahl von Decodierungsthreads. Der Prozentsatz der Decodierungs-Engines, die zu einem bestimmten Zeitpunkt mit der Verarbeitung einer Decodierungsanfrage beschäftigt sind, wird als Messwert jetstream_slots_used_percentage gemessen.
Für die Skalierung von JetStream mit einem einzelnen Host hat dies zwei Auswirkungen auf Latenz und Durchsatz:
- Anfragen werden nicht in den Warteschlangen zurückgestellt, wenn die Rate der eingehenden Anfragen geringer ist als die Rate, mit der die Decodierungs-Slots die Anfragen verarbeiten können. Wenn JetStream keinen Backlog hat, ist der Durchsatz proportional zur Rate der eingehenden Anfragen. Die Latenz bleibt größtenteils konstant, steigt aber leicht und proportional zur Anzahl der gleichzeitigen Decodierungsanfragen, da neu akzeptierte Decodierungsanfragen die Decodierung unterbrechen.
- Anfragen werden in den Warteschlangen zurückgestellt, sobald die Anzahl der eingehenden Anfragen die Anzahl der Decodierungs-Slots übersteigt, die die Anfragen verarbeiten können. Wenn JetStream einen Rückstand hat, erhöht sich die Latenz der Anfragen stärker und proportional zur Anzahl der Anfragen im Rückstand, während der Durchsatz konstant bleibt.
Die folgenden Servermesswerte weisen die stärkste Korrelation mit diesen relevanten Leistungsindikatoren auf. Wir empfehlen, sie für das Autoscaling zu verwenden:
jetstream_prefill_backlog_size: Die Anzahl der Anfragen, die in der Serverwarteschlange auf die Verarbeitung warten (Backlog). Dieser Messwert korreliert stark mit der Latenz. Weitere Informationen finden Sie im zugehörigen Abschnitt Best Practices.jetstream_slots_used_percentage:Die Anzahl der Anfragen, bei denen Inferenz auftritt, als Prozentsatz der Gesamtzahl der Anfragen, die JetStream verarbeiten kann. Dieser Messwert ist stark mit dem Durchsatz korreliert. Weitere Informationen finden Sie im zugehörigen Abschnitt Best Practices.
Diese Messwerte sind oft unempfindlich gegenüber Leistungs- und Traffic-Schwankungen und daher ein zuverlässiger Ausgangspunkt für das Autoscaling in verschiedenen TPU-Hardwarekonfigurationen.
TPU-Messwerte
Da die Bereitstellung von LLMs durch den Arbeitsspeicher und nicht durch die Rechenleistung begrenzt wird, empfehlen wir, JetStream anhand der Arbeitsspeichernutzung und nicht anhand anderer TPU-Messwerte zu skalieren, da dies die Ressourcennutzung der Hardware am besten widerspiegelt. Weitere Informationen finden Sie im zugehörigen Abschnitt Best Practices.
Ü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 Größe des Prefill-Backlogs (Warteschlange), um den Durchsatz zu maximieren und die Kosten innerhalb eines bestimmten Ziellatenz-Schwellenwerts zu minimieren
Wir empfehlen das automatische Skalieren der Vorauffüllungswarteschlange, wenn Sie Durchsatz und Kosten optimieren möchten und Ihre Latenzziele mit dem maximalen Durchsatz der Batchgröße Ihres Modellservers pro Gerät erreicht werden können.
Die Größe der Vorauffüllungswarteschlange steht in direktem Zusammenhang mit der Anfrage-Latenz. Eingehende Anfragen werden in der Vorauffüllungswarteschlange des Modellservers angeordnet, 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 Vorauffüllungswarteschlange 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, da die Warteschlangengröße unabhängig von der Anforderungsgröße, dem Modell oder der Hardware ist.
Wenn Sie den Durchsatz jedes Modell-Server-Repliks maximieren möchten, sollten Sie sich auf die Größe der Vorauffüllungswarteschlange konzentrieren. Die Größe der Vorauffüllungswarteschlange gibt die Anzahl der ausstehenden Anfragen an, nicht der verarbeiteten. JetStream verwendet kontinuierliche Batchverarbeitung, wodurch die Anzahl gleichzeitiger Anfragen maximiert und die Warteschlange klein gehalten wird, wenn Batch-Speicherplatz verfügbar ist. Die Warteschlange wächst deutlich, wenn der Batch-Speicherplatz begrenzt ist. Verwenden Sie den Wachstumspunkt daher als Signal, um die Skalierung zu starten. Durch die Kombination von Autoscaling für die Warteschlangengröße und optimiertem Batchdurchsatz können Sie den Anfragedurchsatz maximieren.
Optimalen Schwellenwert für die Warteschlangengröße für HPA bestimmen
Wählen Sie zuerst einen Wert zwischen 3 und 5 aus und erhöhen Sie ihn dann 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
Achten Sie auf die HPA-Toleranz, die standardmäßig bei einem Nicht-Aktionsbereich von 0,1 um den Zielwert liegt, um Schwankungen zu dämpfene.
Die Größe der Vorauffüllungswarteschlange steuert nicht direkt die Anzahl gleichzeitiger Anfragen. Daher kann der Grenzwert keine geringere Latenz als die pro Gerät zulässige Batchgröße garantieren. Als Behelfslösung können Sie die Batchgröße pro Gerät manuell reduzieren oder automatisch anhand der Batchgröße skalieren.
Best Practice: Verwenden Sie den Prozentsatz „slots_used“, um niedrigere Ziellatenzschwellenwerte als die Warteschlangengröße zu erreichen
Wir empfehlen, das Autoscaling basierend auf „slots_used“ zu verwenden, wenn Sie latenzempfindliche Arbeitslasten haben, bei denen die warteschlangenbasierte Skalierung nicht schnell genug ist, um Ihre Anforderungen zu erfüllen.
Durch das Autoscaling anhand von „slots_used“ wird sichergestellt, dass der Durchsatz Ihrer Arbeitslasten hochskaliert wird, um die Anzahl der parallel verarbeiteten Anfragen zu maximieren, und herunterskaliert, wenn weniger Anfragen parallel verarbeitet werden. Das hat zwei Auswirkungen auf die Latenz. Erstens: Da die Autoscaling-Funktion auf Grundlage von „slots_used“ skaliert wird, um für jede eingehende Anfrage einen Slot zu gewährleisten, entspricht die Nähe des Schwellenwerts zu 1 der Wahrscheinlichkeit, dass eine Anfrage in die Warteschlange gestellt wird und daher eine höhere Latenz aufweist. Zweitens: Größere Batchgrößen erhöhen den Durchsatz, erhöhen aber auch die Latenz, da die Vorauffüllungsphase einiger Anfragen die Decodierungsphase anderer in kontinuierlichen Batch-Modell-Servern unterbricht. Sie können die Muster der Batchgröße beobachten und Autoscaling verwenden, um die Anzahl gleichzeitiger Anfragen bei Lastspitzen zu minimieren.
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. „slots_used“ ist jedoch für latenzempfindliche Arbeitslasten nützlich.
Wir empfehlen außerdem, die Batchgröße pro Gerät auf einen geeigneten Wert einzustellen, bevor Sie das Autoscaling basierend auf „slots_used“ verwenden. Optional können Sie dies auch mit warteschlangenbasiertem Autoscaling kombinieren.
Optimalen Schwellenwert für den Prozentsatz von „slots_used“ für HPA bestimmen
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 zum Testen zu verwenden. Sobald Sie eine optimale Batchgröße pro Gerät ermittelt haben, bei der die Speichernutzung maximiert wird, können Sie das Ziel für den Prozentsatz der verwendeten Slots konfigurieren. Legen Sie den anfänglichen Zielwert etwas unter 1 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
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.
Autoscaling anhand des Prozentsatzes von „slots_used“ ist zwar hilfreich für die Latenzsteuerung, hat aber Einschränkungen. Aufgrund der unterschiedlichen Anfragedimensionen und Hardwarebeschränkungen ist es schwierig, den richtigen Schwellenwert für den Prozentsatz von „slots_used“ zu finden. Wenn eine Skalierungsregel versucht, den durchschnittlichen Prozentsatz von „slots_used“ unter 100% zu halten, bedeutet das, dass sie versucht, eine Anzahl von verfügbaren Slots beizubehalten, die nicht null ist. Diese verfügbaren Slots entsprechen dem nicht genutzten verfügbaren Durchsatz. Das ist nicht ideal, wenn Sie Ihre verfügbaren TPUs optimal nutzen möchten.
Best Practice: HBM-Nutzung (High Bandwidth Memory) der TPU maximieren, um die Hardwareauslastung zu maximieren
Die Nutzung von TPU-Arbeitsspeicher mit hoher Bandbreite (HBM) entspricht am direktesten der Hardwareauslastung, auch im Vergleich zu Systemmesswerten, da diese die Anforderungsgrößen nicht berücksichtigen. Durch die Skalierung mit der Warteschlangengröße wird die Hardwareauslastung zwar besser maximiert, aber auf Kosten der Latenz. Wenn Sie lieber Systemmesswerte als Servermesswerte verwenden möchten, empfehlen wir die HBM-Nutzung als beste Alternative für das Autoscaling mit „slots_used“, da beide mit dem Durchsatz korrespondieren. Weitere Informationen zum TPU-Arbeitsspeicher finden Sie unter So funktioniert eine TPU.
Wenn Sie die Batchgröße über den optimalen Punkt hinaus erhöhen, wird der Durchsatz verbessert, aber auch das Risiko von OOM-Fehlern (Out-of-Memory) steigt. Wir empfehlen dringend, die Skalierung anhand des HBM-Messwerts vorzunehmen, um ein Gleichgewicht zwischen Durchsatz und Stabilität zu erreichen. Wir empfehlen, nicht gleichzeitig nach Größe der Vorauffüllungswarteschlange und HBM-Nutzung zu skalieren, da sich die HBM-Nutzung mit zunehmender Auslastung erhöht und zuerst die Skalierung auslöst.
Optimalen Schwellenwert für die TPU-HBM-Nutzung für HPA bestimmen
Bevor Sie den Grenzwert für die Arbeitsspeichernutzung festlegen, empfehlen wir, die Batchgröße pro Gerät auf einen Wert festzulegen, der die Arbeitsspeichernutzung bei maximal erwarteter Last maximiert. Dieser Wert muss experimentell ermittelt werden und hängt stark von der gesamten HBM sowie der erwarteten Länge von Prompts und Antworten ab. Wir empfehlen, für Tests und Experimente das Tool locust-load-inference zu verwenden.
Legen Sie den Schwellenwert ähnlich wie bei der Batchgröße pro Gerät so fest, dass die TPU-Arbeitsspeichernutzung maximiert und das Risiko von OOM-Verhalten minimiert wird.
Sie können auch ein benutzerdefiniertes Cloud Monitoring-Dashboard erstellen, um das Verhalten der Messwerte zu visualisieren.
Beschränkungen
Es gibt zwei Einschränkungen, die die Stärke der Korrelation zwischen Latenz und Durchsatz und der HBM-Nutzung verringern: die Volatilität der HBM-Nutzung und die niedrigere Abtastrate von TPU-Messwerten im Allgemeinen. Außerdem besteht zwar weiterhin ein Zusammenhang zwischen HBM-Nutzung und Latenz, aber eine Erhöhung der HBM-Nutzung wirkt sich weitaus weniger auf die Latenz aus als eine Erhöhung der Anzahl der Anfragen in der Warteschlange.
Best Practice: HPA-Konfiguration optimieren
Wir empfehlen, die folgenden HPA-Konfigurationsoptionen festzulegen:
- Stabilisierungszeitraum: Mit dieser HPA-Konfigurationsoption können Sie schnelle Änderungen der Replikatanzahl 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 Arbeitslasten 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 Replikate 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.