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.

Stellen Sie Modelle mithilfe von kubectl aus dem lokalen NVMe-Speicher bereit

In diesem Thema erfahren Sie, wie Sie Inferenzendpunkte auf Amazon bereitstellen SageMaker HyperPod, die Modellgewichte aus dem lokalen NVMe-Speicher eines Knotens laden, anstatt sie von Amazon S3 oder Amazon FSx über das Netzwerk abzurufen. Durch das lokale Auslesen der Gewichtungen entfällt der Netzwerk-Hop beim Pod-Start. Dadurch wird die Kaltstartzeit des Inferenz-Pods reduziert. Dies ist nützlich für Autoscaling-Ereignisse, Workloads, die von Null aus skalieren, und latenzempfindliche Failover. Verwenden Sie für Workloads, bei denen die Kaltstart-Latenz kein Problem darstellt, oder und überspringen Sie dieses Thema. modelSourceType: s3 fsx

Lokales NVMe ist knotenlokal und kurzlebig: Daten auf NVMe gehen verloren, wenn ein Knoten ausgetauscht wird, z. B. bei einer Spot-Unterbrechung, einem Hardwarefehler oder einer AMI-Aktualisierung. Bei den Ansätzen in diesem Thema wird dies unterschiedlich gehandhabt — bei einigen müssen Sie jeden Knoten vorab mit Daten füllen, bei anderen wird automatisch auf Amazon S3 zurückgegriffen, wenn das Modell nicht lokal zwischengespeichert wird. Lokaler NVMe-Instance-Speicher befindet sich normalerweise in den Instance-Familien P, G und Trn. Informationen zur Überprüfung der Verfügbarkeit für Ihren Instance-Typ finden Sie in den Amazon EC2-Instance-Store-Spezifikationen.

Je nach Ihren Speicheranforderungen können Sie aus den folgenden Ansätzen wählen:

Voraussetzungen

Bevor Sie beginnen, stellen Sie sicher, dass Sie:

Wählen Sie Ihren Bereitstellungsansatz

Ermitteln Sie anhand des folgenden Entscheidungsablaufs, welcher Ansatz für Ihren Anwendungsfall geeignet ist.

                  ┌────────────────────────────┐
                  │ Want to use a volume of    │
                  │ your choice, e.g. NVMe?    │
                  └─────┬──────────────┬───────┘
                   YES  │              │ NO
                        ▼              ▼
        ┌──────────────────────┐   Use S3/FSx/HF
        │ Are you sure EVERY   │   as-is (no volume
        │ node has the model   │   override needed)
        │ on NVMe?             │
        └─────┬──────────┬─────┘
         YES  │          │ NO
              ▼          ▼
  ┌─────────────────┐  ┌───────────────────────────────┐
  │ Approach 1      │  │ Do you need the operator to   │
  │                 │  │ create S3/FSx PVCs as a       │
  │ Use k8sVolume   │  │ fallback when the model is    │
  │ field in CRD to │  │ missing on a node?            │
  │ read from NVMe  │  └──────┬────────────────┬───────┘
  │ directly.       │    YES  │                │ NO
  └─────────────────┘         ▼                ▼
                  ┌──────────────────┐  ┌──────────────────────┐
                  │ Approach 3       │  │ Approach 2           │
                  │                  │  │                      │
                  │ Use S3 with      │  │ Use k8sVolume with a │
                  │ prefetch enabled.│  │ custom initContainer │
                  │ Custom           │  │ you create that      │
                  │ initContainer    │  │ checks NVMe first    │
                  │ checks NVMe      │  │ and downloads from   │
                  │ first, falls     │  │ S3 via IRSA if the   │
                  │ back to S3, and  │  │ model is missing.    │
                  │ copies to RAM.   │  └──────────────────────┘
                  └──────────────────┘

Stellen Sie die Bereitstellung mithilfe eines Kubernetes-Volumes bereit (kein Fallback)

Verwenden Sie diesen Ansatz, wenn Sie Modellgewichtungen für NVMe auf jedem Knoten haben und das einfachste Setup wünschen — keine Amazon S3- oder Amazon FSx-Konfiguration, nein PV/PVC, und keine InitContainers.

Wenn Sie festlegenmodelSourceType: kubernetesVolume, überspringt der Operator die Erstellung vollständig. PV/PVC Es wird kein CSI-Treiber, Amazon S3 Fuse Mount oder Amazon FSx Mount verwendet. Das vom Kunden bereitgestellte model-weights Volume wird direkt in der Pod-Spezifikation verwendet, und der Worker liest Modelldaten von NVMe unter. /opt/ml/model

Stellen Sie die Bereitstellung mithilfe eines Kubernetes-Volumes mit Fallback bereit

Verwenden Sie diesen Ansatz, wenn sich das Modell möglicherweise auf NVMe auf einem bestimmten Knoten befindet oder nicht. Ein hostPath Volume funktioniert nur auf Knoten, auf denen die Daten vorhanden sind. Pods, die auf anderen Knoten geplant sind, würden einen leeren oder nicht vorhandenen Pfad bereitstellen, was zum Ausfall des Modellservers führen würde.

Bei diesem Ansatz legen Sie ein benutzerdefiniertes System fest modelSourceType: kubernetesVolume und stellen es bereitinitContainer, das zuerst NVMe überprüft und mithilfe von IRSA-Anmeldeinformationen von Amazon S3 herunterlädt, falls das Modell fehlt.

Richten Sie IRSA ein

Konfigurieren Sie vor der Bereitstellung IAM Roles for Service Accounts (IRSA) so, dass Ihre Pods Anmeldeinformationen für das Herunterladen von Amazon S3 erhalten.

Bereitstellen des Modells

Stellen Sie die Bereitstellung mithilfe von Amazon S3 mit Prefetch und NVMe-Fallback bereit

Verwenden Sie diesen Ansatz, wenn Sie eine Inferenzleistung erzielen möchten, indem Sie die Modellgewichte im RAM verteilen und automatisch auf Amazon S3 zurückgreifen, wenn das Modell nicht lokal auf NVMe zwischengespeichert wird.

Wenn Sie auf setzen modelSourceType: s3prefetchEnabled: true, erstellt der Operator automatisch zwei Volumes:

Sie fügen ein benutzerdefiniertes nvme-cache Volume hinzu, das auf den lokalen NVMe-Speicher des Knotens verweist, und ein benutzerdefiniertes, initContainer das:

Grundlegendes zu Model-Weights und Model-Weights-Copy mit Prefetch

Bei Verwendung von Prefetch erstellt der Operator zwei modellbezogene Volumes:

In deinem InferenceEndpointConfig definierst du:

modelVolumeMount:
    name: model-weights
    mountPath: /opt/ml/model

Während Sie darauf verweisenmodel-weights, wannprefetchEnabled: true, ist es tatsächlich model-weights-copy das, was /opt/ml/model im Worker-Container gemountet wird. Wenn Sie einen benutzerdefinierten InitContainer verwenden, stellen Sie sicher, dass Sie die Daten in das aufgerufene Volume kopieren model-weights-copy — dort erwartet der Worker sie zu finden.

WennprefetchEnabled: false, gibt es nur ein Volume (benannt nach IhremmodelVolumeMount.name) und es wird direkt dort gemountet. /opt/ml/model

Konfigurieren Sie ein benutzerdefiniertes Dienstkonto

Sie können Ihren Inferenzendpunkt-Pods mithilfe des spec.kubernetes.serviceAccountName Felds im ein benutzerdefiniertes Kubernetes ServiceAccount zuweisen. InferenceEndpointConfig Dies ist nützlich, um Ihren Worker-Containern oder Init-Containern AWS Anmeldeinformationen über IRSA (IAM Roles for Service Accounts) zur Verfügung zu stellen — zum Beispiel, um in einem Fallback-Szenario Modellgewichte von Amazon S3 herunterzuladen.

Wenn Sie keinen angeben ServiceAccount, wird der Standardnamespace ServiceAccount verwendet.

Aktivieren Sie benutzerdefinierte Dienstkonten

Die Unterstützung für benutzerdefinierte Dienstkonten ist standardmäßig deaktiviert. Ein Cluster-Administrator muss ihn in der Helm-Konfiguration des Operators aktivieren, bevor Benutzer ServiceAccounts in ihrer Konfiguration auf benutzerdefinierte Einstellungen verweisen könnenInferenceEndpointConfig.

Benennen Sie das Dienstkonto

Bevor Sie auf ein benutzerdefiniertes Objekt verweisen können ServiceAccount, muss ein Clusteradministrator es als vom Benutzer zuweisbar kennzeichnen:

kubectl label serviceaccount <your-service-account> \
  sagemaker.amazonaws.com/user-assignable=true \
  -n <namespace>

Nur ServiceAccounts mit diesem Label können Inferenzendpunkte darauf verweisen. Dies ist eine Sicherheitskontrolle, um eine unbefugte Rechteerweiterung zu verhindern.

Geben Sie das Dienstkonto in Ihrer Konfiguration an

Fügen Sie das serviceAccountName Feld spec.kubernetes unter Ihrem hinzuInferenceEndpointConfig:

apiVersion: inference.sagemaker.aws.amazon.com/v1
kind: InferenceEndpointConfig
metadata:
  name: my-inference-endpoint
  namespace: my-namespace
spec:
  kubernetes:
    serviceAccountName: my-inference-sa
  # ... rest of your config

Regeln für die Validierung

Der Operator validiert das serviceAccountName Feld sowohl bei Erstellungs- als auch bei Aktualisierungsvorgängen. Ihre Bereitstellung wird mit einem DeploymentFailed Status abgelehnt, wenn eine der folgenden Bedingungen erfüllt ist:

Bewährte Sicherheitsmethoden für benutzerdefinierte Dienstkonten

Wenn Sie eine benutzerdefinierte Version ServiceAccount mit Inferenzendpunkten verwenden, erstellt der HyperPod Inferenzoperator Bereitstellungen in Ihrem Namen. Alle Container im Inferenz-Pod — einschließlich Worker, Init-Container und Sidecars — erben die Berechtigungen der angegebenen Container. ServiceAccount Folgen Sie diesen bewährten Methoden, um Ihren Cluster zu sichern.

Sperren Sie die RBAC-Berechtigungen

Umfang: IRSA IAM-Rollen

Schützen Sie das vom Benutzer zuweisbare Label

Laden Sie Modellgewichtungen vorab auf NVMe

Wenn Sie NVMe vor der Bereitstellung auf bestimmten Knoten vorab auffüllen müssen, können Sie einen einmaligen Pod für die Synchronisierung von Amazon S3 verwenden.

Namen reservierter Volumes

Der Operator verwaltet mehrere interne Volumes, die nicht über überschrieben werden können. kubernetes.volumes Die Verwendung eines dieser Namen führt zu einer KubernetesVolumeValidationFailed Bedingung.

Dinge, die man sich merken sollte

Fehlerbehebung

Verwenden Sie diese Debugging-Befehle, wenn Ihre Bereitstellung nicht wie erwartet funktioniert.