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 TPUs in GKE mit einem einzelnen Host. 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 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 ihre JetStream-Arbeitslasten mit einem einzelnen Host mithilfe von TPUs mit Kubernetes optimieren möchten.
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
Wie viele andere LLM-Inferenzserver bietet auch JetStream Leistungsmesswerte. GKE vereinfacht das Monitoring und Autoscaling von JetStream anhand dieser Messwerte auf Serverebene. Bevor Sie das Autoscaling konfigurieren können, müssen Sie wissen, wie sich die JetStream-Anfragepipeline auf wichtige Leistungskennzahlen auswirkt. Alle eingehenden Anfragen werden durch eine Vorauffüllungswarteschlange, eine Übertragungswarteschlange und eine Generierungswarteschlange geleitet und werden dann zu einer Dekodierungsanfrage. JetStream nimmt Dekodierungsanfragen fortlaufend an und verarbeitet sie gleichzeitig mit einer festen Anzahl von Dekodierungsthreads. Der Prozentsatz der Dekodierungs-Engines, die zu einem bestimmten Zeitpunkt mit der Verarbeitung einer Dekodierungsanfrage beschäftigt sind, wird als Messwert jetstream_slots_used_percentage gemessen.
Bei der Skalierung von JetStream auf einem einzelnen Host hat dies zwei Auswirkungen auf Latenz und Durchsatz:
- Anfragen werden nicht in den Warteschlangen zurückgehalten, wenn die Rate der eingehenden Anfragen unter der Rate liegt, mit der die Dekodierungsslots 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 Dekodierungsanfragen, da neu angenommene Dekodierungsanfragen die Dekodierung unterbrechen.
- Anfragen werden in den Warteschlangen zurückgehalten, sobald die Anzahl der eingehenden Anfragen die Rate übersteigt, mit der die Dekodierungsslots die Anfragen verarbeiten können. Wenn JetStream einen Backlog hat, erhöht sich die Anfragelatenz deutlicher und proportional zur Anzahl der Backlog-Anfragen, während der Durchsatz konstant bleibt.
Die folgenden Servermesswerte haben die stärkste Korrelation mit diesen relevanten Leistungskennzahlen. Wir empfehlen, sie für das Autoscaling zu verwenden:
jetstream_prefill_backlog_size: Die Anzahl der Anfragen, die in der Serverwarteschlange (Backlog) auf Verarbeitung warten. Dieser Messwert ist stark mit der Latenz korreliert. Weitere Informationen finden Sie im Abschnitt zu 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 korreliert stark mit dem Durchsatz. 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 TPU-Hardwarekonfigurationen.
TPU-Messwerte
Da die Auslieferung von LLM durch den Arbeitsspeicher und nicht durch die Rechenleistung begrenzt ist, 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 Abschnitt zu 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 die Autoscaling-Funktion für die Größe der Vorauffüllungswarteschlange, wenn Sie Durchsatz und Kosten optimieren und Ihre Latenzziele mit dem maximalen Durchsatz der Batchgröße Ihres Modellservers pro Gerät erreichbar sind.
Die Größe der Vorauffüllungswarteschlange steht in direktem Zusammenhang mit der Anfragelatenz. Eingehende Anfragen werden in der Vorauffüllungswarteschlange 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 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 Größe der Warteschlange unabhängig von der Größe der Anfrage, 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. Bei JetStream wird kontinuierliches Batching verwendet, wodurch die Anzahl der gleichzeitigen Anfragen maximiert und die Warteschlange klein 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 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
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 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 des Messwerts 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 der verwendeten Slots, um niedrigere Ziellatenzschwellenwerte als die Warteschlangengröße zu erreichen
Wir empfehlen die autoscaling auf Grundlage von „slots_used“, 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 Arbeitslast 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. Da das Autoscaling auf der Grundlage von „slots_used“ skaliert, um für jede eingehende Anfrage einen Slot zu gewährleisten, entspricht die Wahrscheinlichkeit, dass eine Anfrage in der Warteschlange verbleibt und daher eine höhere Latenz hat, der Nähe des Grenzwerts zu 1. 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 Muster für die Batchgröße überwachen und mithilfe von Autoscaling gleichzeitige Anfragen bei Lastspitzen minimieren.
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. „slots_used“ ist jedoch für latenzempfindliche Arbeitslasten wertvoll.
Wir empfehlen außerdem, die Batchgröße pro Gerät auf einen geeigneten Wert anzupassen, bevor Sie die automatische Skalierung auf Grundlage von „slots_used“ ausprobieren. Optional können Sie dies auch mit der warteschlangenbasierten Autoscaling-Funktion kombinieren.
Optimalen Prozentsatz für den Schwellenwert „slots_used“ für HPA bestimmen
Um den richtigen Grenzwert für die Batchgröße auszuwählen, erhöhen Sie experimentell die Auslastung Ihres Servers und beobachten Sie, wo die Batchgröße Spitzen aufweist. Wir empfehlen außerdem, das Tool locust-load-inference für Tests zu verwenden. Sobald Sie die optimale Batchgröße pro Gerät ermittelt haben, bei der die Speichernutzung maximiert wird, können Sie das prozentuale Ziel für „slots_used“ konfigurieren. Legen Sie den anfänglichen Zielwert etwas unter 1 fest und verringern 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
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.
Das Autoscaling anhand des Prozentsatzes der verwendeten Slots ist zwar hilfreich für die Latenzsteuerung, hat aber Einschränkungen. Aufgrund unterschiedlicher Anfragegrößen und Hardwareeinschränkungen ist es schwierig, den richtigen Prozentsatz für den Grenzwert „slots_used“ zu finden. Wenn eine Skalierungsregel versucht, den Prozentsatz der durchschnittlich verwendeten Slots unter 100 % zu halten, bedeutet das, dass die Skalierungsregel versucht, eine nicht nullwertige Anzahl verfügbarer Slots beizubehalten. 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-Speicher (High Bandwidth Memory) der TPU verwenden, um die Hardwarenutzung zu maximieren
Die Nutzung des TPU-Arbeitsspeichers mit hoher Bandbreite (HBM) steht in direktem Zusammenhang mit der Hardwareauslastung, sogar im Vergleich zu Systemmesswerten, da diese die Anfragegrößen nicht berücksichtigen. Die Skalierung nach Warteschlangengröße maximiert zwar die Hardwareauslastung, geht aber zu Lasten der Latenz. Wenn Sie lieber System- als Servermesswerte verwenden möchten, empfehlen wir die HBM-Nutzung als beste Alternative für das Autoscaling mit „slots_used“, da beide dem Durchsatz entsprechen. Weitere Informationen zum TPU-Speicher finden Sie unter Funktionsweise einer TPU.
Wenn Sie die Batchgröße über den optimalen Wert hinaus erhöhen, wird der Durchsatz zwar verbessert, aber auch das Risiko von OOM-Fehlern (Out-of-Memory). Wir empfehlen dringend, die Skalierung anhand des HBM-Messwerts vorzunehmen, um einen optimalen Durchsatz bei gleichzeitig hoher Stabilität zu erzielen. 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 der maximal erwarteten Auslastung maximiert. Dieser Wert muss experimentell ermittelt werden und hängt stark vom gesamten HBM sowie von der erwarteten Länge von Prompts und Antworten ab. Wir empfehlen, das Tool locust-load-inference für Ihre Tests zu verwenden.
Ähnlich wie bei der Batchgröße pro Gerät sollten Sie den Grenzwert so festlegen, dass die TPU-Speichernutzung maximiert und das Risiko eines OOM-Verhaltens minimiert wird.
Sie können auch ein benutzerdefiniertes Cloud Monitoring-Dashboard erstellen, um das Verhalten des Messwerts zu visualisieren.
Beschränkungen
Es gibt zwei Einschränkungen, die die Korrelation zwischen Latenz und Durchsatz und der HBM-Nutzung beeinträchtigen: die Volatilität der HBM-Nutzung und die geringere Stichprobenrate von TPU-Messwerten im Allgemeinen. Auch wenn es immer noch eine Korrespondenz zwischen HBM-Nutzung und Latenz gibt, wirkt sich eine Erhöhung der HBM-Nutzung auf die Latenz weitaus weniger aus als eine Erhöhung der Anzahl der anstehenden 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 Replikats 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 Horizontal Pod Autoscaling.