Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Das Modell gewichtet das Caching und das Caching von Bildern Wenn Sie eine Inferenzbereitstellung skalieren, muss jeder neue Pod das Inferenzserver-Container-Image aus einer Registrierung abrufen. Es muss außerdem Modellgewichte aus dem Remotespeicher (Amazon S3 oder Amazon FSx) herunterladen, bevor es den Datenverkehr verarbeiten kann. Bei großen Sprachmodellen tragen das Herunterladen von Modellgewichten und das Abrufen von Container-Images am meisten zur Kaltstart-Latenz bei. Um diese Engpässe beim Scale-Out zu vermeiden, konfigurieren Sie einen oder beide der folgenden hostlokalen Caching-Mechanismen in Amazon Inference: SageMaker HyperPod Das `weightsCache` Modell gewichtet Caching () Pre-populates Gewichtung der Dateien im hostlokalen NVMe-Speicher auf jedem geeigneten Knoten. Inferenz-Pods auf demselben Knoten laden Gewichtungen aus dem lokalen Speicher, anstatt sie von der Remote-Modellquelle herunterzuladen, wodurch redundante Downloads zwischen den Pods vermieden werden. Zwischenspeichern von Bildern () `imageCache` Pre-pulls das Container-Image des Inferenzservers auf den Zielknoten, sodass neue Pods gestartet werden, ohne auf einen kalten Image-Pull warten zu müssen. Sie konfigurieren beide Caching-Mechanismen über das `modelCacheConfig` Feld in Ihrem `InferenceEndpointConfig` oder `JumpStartModel` Deployment. Sie können das Gewichtungs-Caching und das Bild-Caching unabhängig voneinander oder zusammen aktivieren. Beide Funktionen funktionieren mit allen Amazon SageMaker HyperPod Inference-Modellquellen, einschließlich SageMaker JumpStart Amazon-Bereitstellungen (sowohl Open-Weights- als auch Gated-Modelle) und benutzerdefinierten Modellen von Amazon S3 oder Amazon FSx. ## Voraussetzungen Bevor Sie das Caching aktivieren, überprüfen Sie Folgendes: Instanztyp mit lokalem NVMe-Speicher Beim Model-Gewichtungs-Caching werden Gewichtungen auf dem lokalen NVMe-Speicher gespeichert (standardmäßig). `/opt/dlami/nvme` Ihr Instance-Typ muss lokalen NVMe-Speicher in der konfigurierten Version bereitstellen. `hostPath` Ausreichende NVMe-Kapazität Stellen Sie sicher, dass der Knoten über ausreichend lokalen Speicher für Ihr Modell verfügt. Jede Bereitstellung verwendet ihr eigenes isoliertes Cache-Verzeichnis, sodass mehrere zwischengespeicherte Bereitstellungen auf demselben Knoten jeweils ihren eigenen Speicher verbrauchen. Inferenz-Operator Ihr Cluster muss über eine Version des HyperPod Inferenzoperators verfügen, die das Modell-Caching unterstützt. Wenn das `modelCacheConfig` Feld nicht erkannt wird, aktualisieren Sie das Inferenzoperator-Add-on auf die neueste Version. **Wichtig** Wenn Ihr Instance-Typ im konfigurierten Zustand nicht über lokalen NVMe-Speicher verfügt`hostPath`, erwärmt das Caching der Modellgewichte den Cache nicht und die Inferenz-Pods greifen darauf zurück, Gewichtungen von der Remote-Modellquelle herunterzuladen. Stellen Sie sicher, dass Ihr Instance-Typ lokalen NVMe-Speicher bereitstellt, bevor Sie diese Funktion aktivieren. ## Konfigurieren Sie das Caching der Modellgewichte und das Caching von Bildern Fügen Sie einen `modelCacheConfig` Block zu `spec` Ihrer `InferenceEndpointConfig` oder `JumpStartModel` Ressource hinzu. Das folgende Beispiel aktiviert sowohl das Zwischenspeichern von Modellgewichten als auch das Zwischenspeichern von Bildern. ``` spec: # ... model source, worker, and TLS configuration ... modelCacheConfig: weightsCache: enabled: true hostPath: /opt/dlami/nvme imageCache: enabled: true ``` Das `modelCacheConfig` Feld unterstützt die folgenden Unterfelder. | Feld | Standard | Description | | --- | --- | --- | | weightsCache.enabled | false | Ob das Zwischenspeichern der gewichteten Modellgewichtung auf dem Host aktiviert ist. In diesem true Fall füllt der Operator die Modellgewichte im lokalen Host-Speicher vorab aus und mountet sie in Inferenz-Pods. | | weightsCache.hostPath | /opt/dlami/nvme | Der Host-Pfad, in dem zwischengespeicherte Modellgewichte gespeichert werden. Muss ein nicht leerer absoluter Pfad mit maximal 255 Zeichen sein. | | imageCache.enabled | false | Ob das Container-Image-Caching aktiviert ist. In diesem true Fall zieht der Operator das Container-Image des Inferenzservers vorab auf die Zielknoten. | ## So funktioniert das Caching mit Modellgewichtungen Wenn dies der `weightsCache.enabled` Fall ist`true`, lädt der Operator Modellgewichte von der Remote-Modellquelle (Amazon S3 oder Amazon FSx) in den hostlokalen NVMe-Speicher auf jedem geeigneten Knoten herunter, bevor die Inferenz-Pods mit der Bereitstellung des Datenverkehrs beginnen. Inferenz-Pods mounten die zwischengespeicherten Gewichtungen schreibgeschützt und laden das Modell aus dem lokalen Speicher, anstatt es wiederholt von der Remote-Quelle herunterzuladen. Der Operator füllt den Cache auf Knoten auf, die den Planungseinschränkungen der Inferenzbereitstellung entsprechen, und kennzeichnet jeden Knoten, wenn sein Cache warm ist. Bei der Inferenzbereitstellung wird bei diesem Label die * bevorzugte * Node-Affinität verwendet, sodass Pods auf Warm-Nodes eingeplant werden, wenn sie verfügbar sind, sie aber trotzdem an anderer Stelle geplant werden können. Isolation Jede Bereitstellung verwendet für jede Bereitstellung ein isoliertes Cache-Verzeichnis unter dem konfigurierten Verzeichnis`hostPath`, sodass sich mehrere Modellbereitstellungen auf demselben Knoten nicht gegenseitig stören. Der Cache hat das Fallback verpasst Wenn ein Pod auf einem Knoten geplant ist, auf dem der Cache noch nicht verfügbar ist, werden bei der Bereitstellung die Modellgewichte direkt von der Remote-Modellquelle geladen, sodass Bereitstellungen auch ohne einen warmen Cache funktionsfähig bleiben. Austausch des Knotens Wenn ein Knoten ausgetauscht wird (z. B. nach einem Ausfall), muss der Operator den Cache auf dem neuen Knoten erneut warmlaufen lassen, bevor Pods bevorzugt für ihn eingeplant werden. Bestehende warme Knoten bedienen in der Zwischenzeit weiterhin den Datenverkehr. Beim Löschen aufräumen Wenn Sie die Bereitstellung löschen, entfernt der Operator die zwischengespeicherten Gewichtungsdateien von den Knoten, mit denen er gefüllt wurde. ## So funktioniert das Zwischenspeichern von Bildern `imageCache.enabled`Ist dies der Fall`true`, zieht der Operator das Container-Image des Inferenzservers vorab auf die Zielknoten. Da das Image bereits auf dem Knoten vorhanden ist, vermeiden neue Inferenz-Pods den Cold Image-Pull, der andernfalls den Pod-Start verzögern würde. Dies ist besonders vorteilhaft für große Inferenzserver-Images und für Bereitstellungen, die häufig skaliert werden. Das Zwischenspeichern von Bildern ist unabhängig vom Zwischenspeichern der Modellgewichte. Sie können es eigenständig aktivieren oder es mit dem Gewichtungs-Caching kombinieren, um sowohl die Zeit für das Abrufen von Bildern als auch für das Herunterladen von Gewichten beim Scale-Out zu reduzieren. ## Stellen Sie sicher, dass das Caching funktioniert Stellen Sie anhand der folgenden Prüfungen sicher, dass das Caching für Ihre Bereitstellung aktiv ist. ### Überprüfen Sie die Knotenbezeichnungen auf einen warmen Cache Wenn der Cache eines Knotens warm ist, wendet der Operator ein Cache-Ready-Label darauf an. Beim Caching für Modellgewichtungen wird ein Label mit dem Präfix verwendet`inference.sagemaker.aws.amazon.com/weights-cache-ready.`, und beim Bild-Caching wird das Präfix verwendet`inference.sagemaker.aws.amazon.com/image-cache-ready.`, wobei jeweils die UID der Cache-Konfiguration als Suffix angehängt wird. ``` kubectl get nodes --show-labels | grep "cache-ready" ``` Keine Ausgabe bedeutet, dass noch keine Knoten den Cache erwärmt haben. ### Überprüfe die Pod-Ereignisse auf den Cache-Mount Untersuchen Sie einen Inferenz-Pod und vergewissern Sie sich, dass er den hostlokalen Cache-Pfad schreibgeschützt mountet. Wenn das HostPath-Volume nicht vorhanden ist, lädt der Pod Gewichte aus dem Remote-Speicher. ``` kubectl describe pod {{inference-pod-name}} -n {{namespace}} ``` ### Überprüfen Sie die Bedienerprotokolle Überprüfen Sie die Inferenzoperatorprotokolle auf Aktivitäten oder Fehler beim Aufwärmen des Caches. ``` kubectl logs -n hyperpod-inference-system deployment/hyperpod-inference-controller-manager | grep -i "cache" ``` ## Fehlerbehebung | Symptom | Mögliche Ursache | Auflösung | | --- | --- | --- | | Pods starten langsam, obwohl das Caching aktiviert ist. | Der NVMe-Pfad ist für den Instanztyp nicht vorhanden. | Stellen Sie sicher, dass Ihr Instance-Typ über lokalen NVMe-Speicher verfügt und dass dieser hostPath mit dem tatsächlichen Mount-Punkt übereinstimmt. | | Der Cache erwärmt sich nie. | Nicht genügend Speicherplatz auf dem Host-Pfad. | Prüfen Sie die verfügbare Kapazität unterhostPath. Große Modelle können erheblichen lokalen Speicherplatz benötigen. | | Keine Knoten sind als Cache-bereit gekennzeichnet. | Der Cache-Download ist fehlgeschlagen, oder die Remote-Quelle ist nicht erreichbar. | Überprüfen Sie die Betreiberprotokolle auf Download-Fehler und überprüfen Sie den Netzwerkzugriff auf Amazon S3 oder Amazon FSx. | | Bei mehreren Bereitstellungen kommt es zu einem Festplattendruck auf einem Knoten. | Gecachte Bereitstellungen nutzen denselben NVMe-Speicher auf demselben Knoten. | Verwenden Sie separate Instanzgruppen oder reduzieren Sie die Anzahl der gleichzeitigen zwischengespeicherten Bereitstellungen pro Knoten. | ## Überlegungen + Für das Caching mit Modellgewichtungen sind Instanztypen mit lokalem NVMe-Speicher erforderlich. EBS-only Instanzen werden nicht unterstützt. + Die maximale zwischenspeicherbare Modellgröße ist durch die verfügbare NVMe-Kapazität des Instanztyps begrenzt. + Die Aufwärmzeit des Caches hängt von der Modellgröße und dem Netzwerkdurchsatz zur Remote-Modellquelle ab.