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 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 TPUs mit GKE konfigurieren.
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 die Überwachung und das Autoscaling von JetStream basierend auf diesen Messwerten auf Serverebene. Wenn Sie Autoscaling konfigurieren möchten, müssen Sie zuerst verstehen, wie sich die JetStreams-Anfragepipeline auf wichtige Leistungsmesswerte auswirkt. Alle eingehenden Anfragen durchlaufen eine Prefill-Warteschlange, eine Transfer-Warteschlange und eine Generate-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 belegt 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 Anfragen überschreitet, die von den Decodierungs-Slots verarbeitet werden können. Wenn JetStream einen Rückstand hat, steigt die Anfragelatenz 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, diese für das Autoscaling zu verwenden:
jetstream_prefill_backlog_size:Die Anzahl der Anfragen, die in der Serverwarteschlange (Backlog) auf die Verarbeitung warten. Dieser Messwert ist stark mit der Latenz korreliert. Weitere Informationen finden Sie im entsprechenden Best Practices-Abschnitt.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 entsprechenden Best Practices-Abschnitt.
Diese Messwerte sind oft unempfindlich gegenüber Leistungs- und Traffic-Schwankungen und eignen sich daher als 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 entsprechenden Best Practices-Abschnitt.
Ü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 Vorabfüllungs-Backlogs (Warteschlange), um den Durchsatz zu maximieren und die Kosten innerhalb eines bestimmten Ziellatenz-Schwellenwerts zu minimieren
Wir empfehlen die automatische Skalierung 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 korreliert direkt 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 Anfragengröße, dem Modell oder der Hardware ist.
Wenn Sie den Durchsatz jedes Modellserver-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 Continuous Batching, wodurch die Anzahl gleichzeitiger Anfragen maximiert und die Warteschlange niedrig gehalten wird, wenn Batch-Speicherplatz 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 aus Autoscaling der 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 für den Schwellenwert für die Warteschlangengröße 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 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
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 von „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 das Warteschlangen-basierte Skalieren 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. Dies 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 reservieren, entspricht die Nähe des Schwellenwerts zu 1 der Wahrscheinlichkeit, dass eine Anfrage in die Warteschlange eingereiht wird und somit eine höhere Latenz aufweist. Zweitens: Größere Batches erhöhen den Durchsatz, erhöhen aber auch die Latenz, da die Vorauffüllungsphase einiger Anfragen die Decodierungsphase anderer in kontinuierlichen Batchmodellservern 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 Autoscaling basierend auf „slots_used“ verwenden. Optional können Sie dies auch mit dem warteschlangenbasierten 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 für Tests 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 von „slots_used“ 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 Verhalten der Messwerte 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 Anfrageseiten und Hardwarebeschränkungen ist es schwierig, den richtigen Prozentsatz für den Schwellenwert „slots_used“ zu finden. Wenn eine Skalierungsregel versucht, den durchschnittlichen Prozentsatz von „slots_used“ unter 100% zu halten, bedeutet das, dass die Skalierungsregel 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 (High Bandwidth Memory) der TPU verwenden, um die Hardwareauslastung zu maximieren
Die Nutzung des HBM (High Bandwidth Memory) der TPU 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, allerdings 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 auf dem HBM-Messwert zu basieren, um Durchsatz und Stabilität in Einklang zu bringen. 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 den verwendeten Arbeitsspeicher 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 Ihre Tests und Experimente das Tool locust-load-inference zu verwenden.
Ähnlich wie bei der Batchgröße pro Gerät legen Sie den Schwellenwert so fest, dass die TPU-Speichernutzung 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 Samplingrate von TPU-Messwerten im Allgemeinen. Außerdem besteht zwar weiterhin eine Korrelation zwischen HBM-Nutzung und Latenz, aber eine Erhöhung der HBM-Nutzung wirkt sich viel weniger auf die Latenz aus als eine Erhöhung der Anzahl der in der Warteschlange befindlichen Anfragen.
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 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 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.