Automatische Skalierung der KI-Modellinferenz auf GPUs mit Amazon EKS

Tipp

Melden Sie sich für bevorstehende Amazon AI/ML EKS-Workshops an.

In diesem Abschnitt werden die Konzepte und Verfahren für die automatische Skalierung von KI-Inferenz-Workloads auf GPUs mit Amazon EKS behandelt.

Das einzelne VllM-Modellreplikat, das Sie im vorherigen Abschnitt Load & Serve-Modelle bereitgestellt haben, kann eine begrenzte Anzahl gleichzeitiger Anfragen bearbeiten, bevor neue Anfragen warten, was die Latenz erhöht und zu Zeitüberschreitungen bei Anfragen führen kann. Um mit dem Datenverkehr Schritt zu halten, können Sie die Bereitstellung automatisch horizontal skalieren. Autoscaling fügt Workload-Replikate hinzu, wenn der Bedarf steigt, und entfernt sie, wenn der Bedarf sinkt, sodass Sie eine übermäßige Bereitstellung von GPU-Kapazität vermeiden können.

Die automatische Skalierung von Inferenzen erfolgt in zwei Phasen.

• Knotenskalierung — Wenn der Kubernetes-Scheduler keinen Platz hat, um neue Pods auf den vorhandenen Knoten zu platzieren, bleiben die Pods bestehen. Pending Karpenter reagiert auf Pending Pods, indem es GPU-Knoten bereitstellt, die zu ihnen passen, und entfernt Knoten, wenn die Workload-Replikate wieder herunterskaliert werden.

• Pod-Skalierung — Der Horizontal Pod Autoscaler (HPA) überwacht eine konfigurierte Metrik. Wenn diese Metrik einen konfigurierten Schwellenwert überschreitet, erhöht HPA die Anzahl der Workload-Replikate und es werden neue vLLM-Pods erstellt.

In der Phase der Knotenskalierung wird die GPU-Kapazität für die Workload bereitgestellt, die Replikate für die Ausführung benötigen. In der Phase der Pod-Skalierung wird die Anzahl der Workload-Replikate so angepasst, dass die von Ihnen gewählte Metrik in der Nähe des Ziels bleibt.

Bereitstellung von GPU-Knoten mit Karpenter

Karpenter verwaltet den Knotenlebenszyklus, stellt Knoten bereit, wenn Workloads sie benötigen, und konsolidiert oder entfernt Knoten, wenn sie nicht benötigt werden. Es funktioniert mit dem Kubernetes-Scheduler, anstatt ihn zu ersetzen. Der Scheduler platziert Pods auf Knoten. Karpenter stellt Kapazität für die Pods bereit, in die der Scheduler nicht passt, und lässt sie dann vom Scheduler binden, sobald der Knoten fertig ist. Ready

Karpenter behandelt GPU-Knoten anders als eine Flotte von CPU-Knoten.

GPUs werden als ganze Einheiten angefordert

Sofern Sie keine GPU-Sharing-Technik wie Time-Slicing oder MIG verwenden, erhält ein Pod eine oder mehrere ganze GPUs und nicht nur einen Bruchteil, wie dies bei CPU oder Arbeitsspeicher der Fall wäre. Jede GPU hat ihren eigenen dedizierten Speicher, sodass Replikate auf demselben Knoten den GPU-Speicher nicht gemeinsam nutzen. Wie dies den Knoten zugeordnet wird, hängt vom Instanztyp ab:

• Single-GPU Instanz (wieg6.xlarge) — Der Knoten enthält genau ein Replikat. Replikate, GPUs und Knoten werden eins zu eins skaliert, und jedes Replikat ist auf seiner eigenen Instanz isoliert.

• Multi-GPU Instanz (z. B. g6.12xlarge mit 4 GPUs) — Das Geräte-Plugin gibt die vollständige GPU-Anzahl bekannt, sodass Karpenter mehrere Replikate auf einen Knoten packen kann, eine pro GPU.

• Multi-GPU Pod — Ein Pod kann mehr als eine GPU anfordern. Stellen Sie beispielsweise ein, nvidia.com/gpu: 2 dass ein großes Modell auf zwei GPUs aufgeteilt wird, und Karpenter platziert den Pod auf einem Knoten, auf dem so viele GPUs frei sind.

Karpenter optimiert die Verfügbarkeit und die Kosten der GPU

Karpenter gleicht die Beschaffung knapper GPU-Kapazitäten gegen deren kostengünstigen Betrieb aus:

• Instanzauswahl — Bei einer flexiblen Variante wählt Karpenter den Instance-Typ mit den niedrigsten Kosten aus NodePool, der für Pods geeignet ist. Pending Wenn bei einem Start die Kapazität nicht ausreicht, versucht er es automatisch mit anderen Instance-Typen und Availability Zones, was die Wahrscheinlichkeit erhöht, dass GPU-Kapazität erreicht wird.

• Konsolidierung — Wenn die Nachfrage sinkt und die Anzahl der Replikate zunimmt, holt sich Karpenter die freigewordenen Knoten zurück. WhenEmptyOrUnderutilizedentfernt leere Knoten und packt Replikate auf weniger Knoten neu, während ein Knoten erst dann WhenEmpty zurückgeholt wird, wenn nichts für ihn geplant ist.

• Schutz laufender Pods — Um zu verhindern, dass Pods während der Konsolidierung unterbrochen werden, fügen Sie die karpenter.sh/do-not-disrupt Anmerkung hinzu, legen Sie eine Einstellung fest oder verwenden Sie die Einstellung PodDisruptionBudget, um die consolidateAfter Konsolidierung zu verzögern.

Sobald Karpenter über GPU-Kapazität verfügt, beginnt die Phase der Pod-Skalierung: HPA fügt Replikate auf der Grundlage der von Ihnen konfigurierten Metrik hinzu und entfernt sie. Im Rest dieses Abschnitts wird beschrieben, wie Sie diese Skalierungsmetrik für Inferenz-Workloads auswählen.

Automatische Skalierung von GPU und CPU

In Kubernetes skalieren herkömmliche CPU-based Workloads standardmäßig automatisch, Inferenz jedoch nicht. GPU-based Es gibt drei Hauptunterschiede:

Verfügbarkeit von Metriken für Autoscaling

Kubernetes bietet sofort einsatzbereite CPU- und Speichermetriken für HPA

Das Kubelet auf jedem Knoten meldet die CPU- und Speicherauslastung an die Kubernetes-Metrik-API, sodass HPA diese Werte direkt lesen und Workloads ohne zusätzliche Komponenten skalieren kann.

Beschleunigte Workloads erfordern die Einrichtung zusätzlicher Metriken, Exporter und Adapter

Das Kubelet meldet keine GPU- oder Inferenzmetriken. Um die GPU-based Inferenz zu skalieren, müssen Sie Exporteure hinzufügen, die die relevanten Signale veröffentlichen, z. B. vLLM-Anwendungsmetriken und GPU-Metriken aus dem DCGM-Exporter, sowie Adapter, die diese Metriken HPA zugänglich machen.

Zuweisung und gemeinsame Nutzung von Ressourcen

Herkömmliche Workloads teilen sich CPU und Arbeitsspeicher in Bruchteilen

Linux-Gruppen teilen CPU und Speicher in Teilressourcen auf, sodass sich mehrere Pods denselben Knoten teilen können. Ein Pod kann einen Teil der Kapazität eines Knotens anfordern, z. B. 100 Millikerne CPU oder 512 MiB Speicher.

Beschleunigte Workloads weisen GPUs über ein GPU-Zuweisungsframework zu und teilen sie gemeinsam

GPUs werden nicht über Gruppen wie CPU und Arbeitsspeicher gemeinsam genutzt. Das heute gängigste Kubernetes-Setup verwendet das NVIDIA-Geräte-Plugin, das ganze GPUs Pods zuweist (zum Beispiel). nvidia.com/gpu: 1 Dynamic Resource Allocation (DRA) ist eine neuere Kubernetes-API, die GPUs über Ressourcenansprüche zuweist und so eine flexiblere Planung und Ressourcenverwaltung ermöglicht. Sowohl das Geräte-Plugin als auch DRA können Techniken zur gemeinsamen Nutzung von GPUs unterstützen. Time-slicing ermöglicht es mehreren Pods, eine GPU gemeinsam zu nutzen, indem der Zugriff im Laufe der Zeit verschachtelt wird, während Multi-Instance GPUs (MIG), die GPUs wie NVIDIA A100 und H100 unterstützen, in hardwareisolierte GPUs aufgeteilt werden.

Skalierung von Signalen

Herkömmliche Workloads werden in der Regel je nach CPU- und Speicherauslastung skaliert

Die Auslastung ist das Standardsignal für automatische Skalierung für CPU- und Speicherarbeitslasten. Es handelt sich um einen Verzögerungsindikator, da er erst ansteigt, wenn die Arbeitslast bereits ausgelastet ist. Für viele herkömmliche Anwendungen reicht er jedoch aus, um Skalierungsentscheidungen zu treffen.

Beschleunigte Workloads sollten anhand von Frühindikatorkennzahlen skaliert werden, nicht anhand der GPU-Auslastung

Die GPU-Auslastung (DCGM_FI_DEV_GPU_UTIL) zeigt, ob die GPU ausgelastet ist, nicht wie ausgelastet sie ist. Da ein Inferenzserver wie vLLM bei einer Vielzahl eingehender Anfragen nahezu 100% bleiben kann, ist die Auslastung ein unzuverlässiges Autoscaling-Signal. Skalieren Sie stattdessen anhand von Frühindikatoren, die steigen, wenn sich die Nachfrage der Kapazität nähert, wie etwa die Tiefe der Anforderungswarteschlange, die Zeit bis zum ersten Token (TTFT) und die Anforderungslatenz.

Von diesen drei oben genannten Unterschieden sollten Sie Ihre Skalierungssignale sorgfältig abwägen. Da die GPU-Auslastung kein verlässliches Signal für die verbleibende Inferenzkapazität ist, müssen Sie Signale identifizieren und sammeln, die den tatsächlichen Bedarf auf dem Modell-Inferenzserver verfolgen.

Im nächsten Abschnitt wird beschrieben, welche Signale Sie als Skalierungsmetriken verwenden sollten und wie sie zusammenarbeiten.

Auswahl von Skalierungsmetriken

Keine einzelne Metrik sagt Ihnen, wann Sie Ihre Modellinferenzreplikate skalieren müssen. Sie skalieren also mit einer Kombination von Signalen vom Inferenzserver. Diese Signale arbeiten zusammen, wobei jedes auf dem vorherigen aufbaut, um catch Nachfrage früher und zuverlässiger zu decken als jede einzelne Metrik:

Signal	Metrik	Rolle bei der Skalierung
Warteschlange	Tiefe der Anforderungswarteschlange (Anzahl der Anfragen, die auf ihre Bearbeitung warten)	Ein Frühindikator und der beste Standardauslöser, da eine Warteschlange entsteht, sobald der Bedarf die Kapazität übersteigt.
Latenz	Latenz bei Anfragen (p95-Latenz oder TTFT)	Löst Skalierung aus, wenn die Antworten langsam sind, auch wenn sich die Warteschlange noch nicht aufgebaut hat, sodass die Latenz für Benutzer innerhalb des Zielbereichs bleibt.
GPU-Speicher	KV-Cache-Auslastung (wie voll ist der Anforderungsspeicher der GPU)	Schützt davor, dass der GPU-Speicher knapp wird. Wenn er sich seinem Limit nähert, beginnt der Server, Anfragen abzulehnen oder in eine Warteschlange zu stellen.

Zusammen bilden sie Schutzschichten: Die Tiefe der Anforderungswarteschlange ist der Hauptauslöser, der ausgelöst wird, sobald der Bedarf die Kapazität übersteigt, die Anforderungslatenz überprüft, ob langsame Antworten vorliegen, bevor sich eine Warteschlange bildet, und die KV-Cache-Nutzung ist der Backstop, der davor schützt, dass der GPU-Speicher knapp wird.

Alles in die Praxis umsetzen

In den folgenden Unterabschnitten wird gezeigt, wie Sie diese Signale mit einem bestimmten Autoscaler zum Laufen bringen können.

• Finden Sie die metrischen Schwellenwerte für die Skalierung. Testen Sie ein einzelnes vLLM-Replikat unter Last, um dessen Kapazitätsobergrenze und die Schwellenwerte für die Warteschlangentiefe und Latenz für die Skalierung zu ermitteln. Fangen Sie hier an.

• Skalieren Sie mit HPA und KEDA. Automatische Skalierung von vLLM-Replikaten mit KEDA und dem Horizontal Pod Autoscaler, wobei die Tiefe der Anforderungswarteschlange und die End-to-End-Latenz als Skalierungssignale verwendet werden.