Skalierung und Leistung von Anwendungen

Verwaltung von ML-Artefakten, Bereitstellung von Frameworks und Startoptimierung

Die Bereitstellung von Modellen für maschinelles Lernen (ML) auf Amazon EKS erfordert eine sorgfältige Überlegung, wie Modelle in Container-Images und Laufzeitumgebungen integriert werden. Dies gewährleistet Skalierbarkeit, Reproduzierbarkeit und effiziente Ressourcennutzung. In diesem Thema werden die verschiedenen Ansätze für den Umgang mit ML-Modellartefakten, die Auswahl von Serving-Frameworks und die Optimierung der Startzeiten von Containern mithilfe von Techniken wie Pre-Caching beschrieben, die allesamt darauf zugeschnitten sind, die Startzeiten von Containern zu verkürzen.

Reduzierung der Größe von Container-Bildern

Das Reduzieren der Größe von Container-Images beim Start ist eine weitere Möglichkeit, Bilder zu verkleinern. Sie können bei jedem Schritt des Container-Image-Erstellungsprozesses Kürzungen vornehmen. Wählen Sie zunächst Basis-Images aus, die die geringste Anzahl an erforderlichen Abhängigkeiten enthalten. Schließen Sie bei der Image-Erstellung nur die wesentlichen Bibliotheken und Artefakte ein, die erforderlich sind. Versuchen Sie beim Erstellen von Bildern, mehrere RUN COPY OD-Befehle zu kombinieren, um eine geringere Anzahl größerer Ebenen zu erstellen. Verwenden Sie für AI/ML Frameworks mehrstufige Builds, um Build und Runtime zu trennen, indem Sie nur benötigte Artefakte kopieren (z. B. via COPY —from= für Registries oder lokale Kontexte) und wählen Sie Varianten wie reine Runtime-Images aus (z. B. mit 3,03 GB gegenüber Devel mit 6,66 GB). pytorch/pytorch:2.7.1-cuda11.8-cudnn9-runtime Weitere Informationen finden Sie unter Reduzieren der Container-Image-Größe im AI on EKS Workshop.

Umgang mit ML-Modellartefakten in Bereitstellungen

Eine wichtige Entscheidung ist, wie mit den ML-Modellartefakten (wie Gewichten und Konfigurationen) selbst umgegangen werden soll. Die Wahl wirkt sich auf die Image-Größe, die Bereitstellungsgeschwindigkeit, die Häufigkeit der Modellaktualisierungen und den betrieblichen Aufwand aus. Beachten Sie, dass wir uns beim Speichern des „Modells“ auf die Modellartefakte (wie trainierte Parameter und Modellgewichte) beziehen. Es gibt verschiedene Ansätze für den Umgang mit ML-Modellartefakten in Amazon EKS. Jeder hat seine Kompromisse, und der beste hängt von der Größe Ihres Modells, der Aktualisierungsfrequenz und den Infrastrukturanforderungen ab. Ziehen Sie die folgenden Ansätze in Betracht, von den am wenigsten empfohlenen bis hin zu den am meisten empfohlenen:

• Integrieren des Modells in das Container-Image: Kopieren Sie die Modelldateien (z. B. .safetensors, .pth, .h5) während der Image-Erstellung in das Container-Image (z. B. Dockerfile). Das Modell ist Teil des unveränderlichen Images. Wir empfehlen, diesen Ansatz für kleinere Modelle mit seltenen Updates zu verwenden. Dies gewährleistet Konsistenz und Reproduzierbarkeit, sorgt für keine Ladeverzögerung und vereinfacht das Abhängigkeitsmanagement, führt jedoch zu größeren Bildgrößen, verlangsamten Builds und Pushs, erfordert Neuaufbau und erneutes Deployment für Modellaktualisierungen und ist aufgrund des Registry-Pull-Durchsatzes nicht ideal für große Modelle.

• Herunterladen des Modells zur Laufzeit: Beim Start des Containers lädt die Anwendung das Modell über Skripts in einem Init-Container oder Einstiegspunkt von einem externen Speicher herunter (z. B. Amazon S3, unterstützt von S3 CRT für optimierte Übertragungen mit hohem Durchsatz mithilfe von Methoden wie Mountpoint for S3 CSI Driver, AWS S3 CLI oder s5cmd OSS CLI). Für große Modelle mit häufigen Updates empfehlen wir, mit diesem Ansatz zu beginnen. Dadurch bleibt der Fokus der Container-Images auf Code/Laufzeit gerichtet, es werden einfache Modellaktualisierungen ohne Neuerstellungen ermöglicht, die Versionierung über Speichermetadaten unterstützt, aber es führt zu potenziellen Netzwerkausfällen (erfordert Wiederholungslogik) und erfordert Authentifizierung und Caching.

Weitere Informationen finden Sie unter Beschleunigter Pull-Prozess im Workshop KI on EKS.

Bereitstellung von ML-Modellen

Die Bereitstellung und Bereitstellung von Modellen für maschinelles Lernen (ML) auf Amazon EKS erfordert die Auswahl eines geeigneten Model-Serving-Ansatzes, um Latenz, Durchsatz, Skalierbarkeit und einfache Bedienung zu optimieren. Die Wahl hängt von Ihrem Modelltyp (z. B. Sprache, Visionsmodell), den Arbeitslastanforderungen (z. B. Echtzeit-Inferenz) und der Expertise Ihres Teams ab. Zu den gängigen Ansätzen gehören Python-basierte Setups für das Prototyping, dedizierte Modellserver für Funktionen in Produktionsqualität und spezialisierte Inferenz-Engines für hohe Leistung und Effizienz. Jede Methode beinhaltet Kompromisse bei der Komplexität der Einrichtung, der Leistung und der Ressourcennutzung. Beachten Sie, dass die Bereitstellung von Frameworks die Größe von Container-Images aufgrund von Abhängigkeiten (um ein Vielfaches GBs) erhöhen kann, was sich möglicherweise auf die Startzeiten auswirkt. Ziehen Sie eine Entkopplung mithilfe von Techniken zur Behandlung von Artefakten in Betracht, um dieses Problem zu minimieren. Die Optionen sind von den am wenigsten empfohlenen bis hin zu den am meisten empfohlenen Optionen aufgeführt:

Verwenden von Python-Frameworks (z. B. FastAPI, HuggingFace Transformers with PyTorch) Entwickeln Sie eine benutzerdefinierte Anwendung mithilfe von Python-Frameworks und betten Sie Modelldateien (Gewichte, Konfiguration, Tokenizer) in ein containerisiertes Knoten-Setup ein.

• Vorteile: Einfaches Prototyping, nur Python ohne zusätzliche Infrastruktur, kompatibel mit allen HuggingFace Modellen, einfache Kubernetes-Bereitstellung.

• Nachteile: Beschränkt auf request/simple Einzelstapelverarbeitung, langsame Token-Generierung (keine optimierten Kernel), ineffizienter Speicher, mangelnde Skalierung/Überwachung und lange Startzeiten.

• Empfehlung: Wird für die erste Prototypenentwicklung oder für Einzelknotenaufgaben verwendet, die eine benutzerdefinierte Logikintegration erfordern.

Verwenden Sie spezielle Model-Serving-Frameworks (z. B. TensorRT-LLM, TGI) Verwenden Sie spezialisierte Server wie TensorRT-LLM oder TGI für ML-Inferenz und verwalten Sie das Laden, Routing und Optimierung von Modellen. Diese unterstützen Formate wie Safetensors mit optionaler Kompilierung oder Plugins.

• Vorteile: Bietet Batching (Parallelität). static/in-flight or continuous), quantization (INT8, FP8, GPTQ), hardware optimizations (NVIDIA, AMD, Intel, Inferentia), and multi-GPU support (Tensor/Pipeline TensorRT-LLM unterstützt verschiedene Modelle (LLMs, Encoder-Decoder), während TGI die Integration nutzt. HuggingFace

• Nachteile: TensorRT-LLM muss kompiliert werden und ist nur für NVIDIA verfügbar; TGI ist möglicherweise weniger effizient beim Batching; beide erhöhen den Konfigurationsaufwand und sind möglicherweise nicht für alle Modelltypen geeignet (z. B. Nicht-Transformatoren).

• Empfehlung: Geeignet für PyTorch/TensorFlow Modelle, die Produktionskapazitäten wie Tests oder hohen Durchsatz mit kompatibler Hardware benötigen. A/B

Verwendung spezialisierter Inferenz-Engines mit hohem Durchsatz (z. B. vLLM) Nutzen Sie fortschrittliche Inferenz-Engines wie vLLM und optimieren Sie die LLM-Bereitstellung mit, die Batching während des Fluges und die Quantisierung ( PagedAttention, -KV, AWQ), die in die automatische Skalierung von EKS integriert werden können. INT8 FP8

• Vorteile: Hoher Durchsatz und Speichereffizienz (40-60% VRAM-Einsparungen), dynamische Bearbeitung von Anfragen, Token-Streaming, Tensor Parallel Multi-GPU-Unterstützung mit einem Knoten und umfassende Hardwarekompatibilität.

• Nachteile: Optimiert für reine Decoder-Transformatoren (z. B. LLa MA), weniger effektiv für Modelle ohne Transformator, erfordert kompatible Hardware (z. B. NVIDIA) und Einrichtungsaufwand. GPUs

• Empfehlung: Erste Wahl für LLM-Inferenz mit hohem Volumen und geringer Latenz auf EKS, wodurch Skalierbarkeit und Leistung maximiert werden.

Container-Images vor dem Zwischenspeichern

Große Container-Images (z. B. solche, die Modelle enthalten PyTorch) können zu Kaltstartverzögerungen führen, die sich auf die Latenz auswirken. Für latenzempfindliche Workloads, wie z. B. horizontal skalierte Echtzeit-Inferenz-Workloads, bei denen ein schneller Pod-Start entscheidend ist, empfehlen wir, Container-Images vorab zu laden, um Verzögerungen bei der Initialisierung zu minimieren. Ziehen Sie die folgenden Ansätze in Betracht, von den am wenigsten empfohlenen bis hin zu den am meisten empfohlenen:

Verwenden von SOCI-Snapshotter zum Pre-Pull von Images

Für sehr große Bilder, die Sie nicht einfach minimieren können, können Sie den Open-Source-Snapshotter Seekable OCI (SOCI) verwenden, der im parallelen Pull & Unpack-Modus konfiguriert ist. Mit dieser Lösung können Sie vorhandene Images verwenden, ohne Ihre Build-Pipelines neu erstellen oder ändern zu müssen. Diese Option ist besonders effektiv, wenn Workloads mit sehr großen Images auf EC2 Hochleistungscomputer-Instances bereitgestellt werden. Sie eignet sich gut für Netzwerke mit hohem Durchsatz und Hochleistungsspeicherkonfigurationen, wie es bei AI/ML skalierten Workloads üblich ist.

Der pull/unpack SOCI-Parallelmodus verbessert die Leistung end-to-end beim Abrufen von Bildern durch konfigurierbare Parallelisierungsstrategien. Schnelleres Abrufen und Vorbereiten von Images wirken sich direkt darauf aus, wie schnell Sie neue Workloads bereitstellen und Ihren Cluster effizient skalieren können. Das Abrufen von Images erfolgt in zwei Hauptphasen:

1. Ebenen werden aus der Registrierung auf den Knoten abgerufen

Für die Optimierung des Layer-Abrufs erstellt SOCI mehrere gleichzeitige HTTP-Verbindungen pro Ebene, wodurch der Download-Durchsatz über die Beschränkung für eine einzelne Verbindung hinaus vervielfacht wird. Es teilt große Ebenen in Blöcke auf und lädt sie gleichzeitig über mehrere Verbindungen herunter. Dieser Ansatz trägt dazu bei, Ihre verfügbare Netzwerkbandbreite zu sättigen und die Download-Zeiten erheblich zu reduzieren. Dies ist besonders nützlich für AI/ML Workloads, bei denen eine einzelne Ebene mehrere Gigabyte umfassen kann.

2. Diese Schichten auspacken und vorbereiten, um Container zu erstellen

Zur Optimierung des Layer-Entpackens verarbeitet SOCI mehrere Ebenen gleichzeitig. Anstatt zu warten, bis jede Ebene vollständig entpackt ist, bevor mit der nächsten begonnen wird, werden Ihre verfügbaren CPU-Kerne verwendet, um mehrere Schichten gleichzeitig zu dekomprimieren und zu extrahieren. Diese Parallelverarbeitung verwandelt die herkömmliche I/O-gebundene Auspackphase in einen CPU-optimierten Vorgang, der mit Ihren verfügbaren Kernen skaliert. Das System orchestriert diese Parallelisierung sorgfältig, um die Konsistenz des Dateisystems aufrechtzuerhalten und gleichzeitig den Durchsatz zu maximieren.

Der parallel SOCI-Pull-Modus verwendet ein Steuerungssystem mit zwei Schwellenwerten und konfigurierbaren Parametern sowohl für die Parallelität beim Herunterladen als auch für die Entpackungsparallelität. Mit dieser detaillierten Steuerung können Sie das Verhalten von SOCI an Ihre spezifischen Leistungsanforderungen und Umgebungsbedingungen anpassen. Wenn Sie diese Parameter verstehen, können Sie Ihre Laufzeit optimieren, um die beste Pull-Leistung zu erzielen.

Referenzen

• Weitere Informationen zur Lösung und zu Kompromissen bei der Optimierung finden Sie in der Feature-Dokumentation im SOCI-Projekt-Repository unter. GitHub

• Ein praktisches Beispiel mit Karpenter auf Amazon EKS finden Sie im Karpenter Blueprint mit SOCI-Snapshotter-Parallelmodus. pull/unpack

• Informationen zur Konfiguration von Bottlerocket für parallelen Pull finden Sie in der Bottlerocket-Dokumentation unter soci-snapshotter Parallel Pull Unpack Mode.

Verwenden von EBS-Snapshots zum Pre-Pull von Bildern

Sie können einen Amazon Elastic Block Store (EBS) -Snapshot von zwischengespeicherten Container-Images erstellen und diesen Snapshot für EKS-Worker-Knoten wiederverwenden. Dadurch wird sichergestellt, dass die Bilder beim Start des Knotens lokal vorab abgerufen werden, wodurch die Pod-Initialisierungszeit reduziert wird. Weitere Informationen zur Verwendung von Karpenter und EKS Terraform Blueprints für verwaltete Knotengruppen finden Sie unter Verkürzen der Container-Startzeit auf Amazon EKS mit Bottlerocket-Datenvolumen.

Weitere Informationen finden Sie unter Verwenden von containerd snapshotter und Preload von Container-Images in Bottlerocket-Datenvolumes mit EBS-Snapshots im AI on EKS Workshop.

Verwenden des Container-Runtime-Cache zum Pre-Pull von Images

Sie können Container-Images mithilfe von Kubernetes-Ressourcen (z. B. DaemonSet oder Deployment) vorab auf Knoten abrufen, um den Container-Laufzeit-Cache des Knotens zu füllen. Der Container-Runtime-Cache ist der lokale Speicher, der von der Container-Laufzeit verwaltet wird (z. B. containerd), in dem Bilder gespeichert werden, nachdem sie aus einer Registrierung abgerufen wurden. Durch das Pre-Pull wird sichergestellt, dass Bilder lokal verfügbar sind, wodurch Verzögerungen beim Herunterladen beim Pod-Start vermieden werden. Dieser Ansatz ist besonders nützlich, wenn sich Images häufig ändern (z. B. bei häufigen Updates), wenn EBS-Snapshots nicht vorkonfiguriert sind, wenn das Erstellen eines EBS-Volumes zeitaufwändiger wäre als das direkte Abrufen aus einer Container-Registry, oder wenn sich Knoten bereits im Cluster befinden und Pods bei Bedarf mit einem von mehreren möglichen Images hochgefahren werden müssen.

Das Vorabziehen aller Varianten gewährleistet eine schnelle Startzeit, unabhängig davon, welches Image benötigt wird. Bei einem massiv parallel ML-Workload, der 100.000 kleine Modelle erfordert, die mit 10 verschiedenen Techniken erstellt wurden, minimiert das Vorabziehen von 10 Bildern DaemonSet über einen großen Cluster (z. B. Tausende von Knoten) die Pod-Startzeit und ermöglicht die Fertigstellung in weniger als 10 Sekunden, da On-Demand-Pulls vermieden werden. Die Verwendung des Container-Runtime-Cache-Ansatzes macht die Verwaltung von EBS-Snapshots überflüssig und stellt sicher, dass Sie immer die neueste Container-Image-Version erhalten. Bei DaemonSets Inferenz-Workloads in Echtzeit, bei denen Knoten in/out, new nodes added by tools like Cluster Autoscaler may schedule workload pods before the pre-pull DaemonSet completes image pulling. This can cause the initial pod on the new node to trigger the pull anyway, potentially delaying startup and impacting low-latency requirements. Additionally, kubelet image garbage collection can affect pre-pulled images by removing unused ones when disk usage exceeds certain thresholds or if they exceed a configured maximum unused age. In scale-in/out Muster skalieren, kann dies jedoch dazu führen, dass Bilder auf inaktiven Knoten entfernt werden, was bei nachfolgenden Scale-ups Re-Pulls erforderlich macht und die Zuverlässigkeit des Caches für Burst-Workloads verringert.

Beispiele für das Pre-Pullen von Images in den Container-Runtime-Cache finden Sie im GitHub AWS-Repository.

Wird NVMe für Kubelet- und containerd verwendet

Erwägen Sie containerd die Konfiguration kubelet und Verwendung von temporären NVMe Instance-Speicherlaufwerken für eine höhere Festplattenleistung. Der Container-Pull-Prozess beinhaltet das Herunterladen eines Container-Images aus einer Registrierung und das Dekomprimieren seiner Schichten in ein verwendbares Format. Um die I/O Abläufe während der Dekomprimierung zu optimieren, sollten Sie abwägen, was für den Instance-Typ Ihres Container-Hosts ein höheres Maß an I/O Leistung und Durchsatz bietet: NVMe Backed-Instances mit lokalem Speicher im Vergleich zu EBS-Volume-IOPS/Durchsatz. Für EC2 Instances mit NVMe lokalem Speicher sollten Sie erwägen, das dem Knoten zugrunde liegende Dateisystem für kubelet (/var/lib/kubelet), containerd () und Pod logs (/var/lib/containerd/var/log/pods) zu konfigurieren, um kurzlebige NVMe Instanz-Speicherplatten für höhere Leistung und höheren Durchsatz zu verwenden. I/O

Der kurzlebige Speicher des Knotens kann von Pods gemeinsam genutzt werden, die kurzlebigen Speicher anfordern, und von Container-Images, die auf den Knoten heruntergeladen werden. Wenn Sie Karpenter mit Bottlerocket oder AL2 023 EKS Optimized verwenden, kann AMIs dies EC2NodeClassdurch Einstellung auf RAID0 oder, bei Verwendung von Managed Node instanceStorePolicy Groups, durch Einstellen von In als Teil der Benutzerdaten konfiguriert werden. localStoragePolicy NodeConfig