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 mit kubectl Modelle 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 Lesen von Gewichten entfällt der Netzwerk-Hop beim Pod-Start, wodurch die Kaltstartzeit des Inferenz-Pods reduziert wird. Dies ist nützlich für automatische Skalierung von Ereignissen, für Workloads, bei denen die Skalierung von Null aus erfolgt, und für latenzempfindliche Failover. Verwenden Sie oder und überspringen Sie dieses Thema für Workloads, bei denen die Kaltstartlatenz kein Problem darstellt. modelSourceType: s3 fsx

Lokales NVMe ist knotenlokal und kurzlebig: Daten auf NVMe gehen verloren, wenn ein Knoten ausgetauscht wird, z. B. bei einer punktuellen Unterbrechung, einem Hardwarefehler oder einer AMI-Aktualisierung. Die Ansätze in diesem Thema behandeln dies unterschiedlich — bei einigen müssen Sie jeden Knoten vorab auffüllen, bei anderen wird automatisch auf Amazon S3 zurückgegriffen, wenn das Modell nicht lokal zwischengespeichert wird. Lokaler NVMe-Instance-Speicher befindet sich in der Regel in den Instance-Familien P, G und Trn. Sehen Sie sich die Spezifikationen des Amazon EC2 EC2-Instance-Speichers an, um die Verfügbarkeit für Ihren Instance-Typ zu überprüfen.

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

Voraussetzungen

Bevor Sie beginnen, stellen Sie sicher, dass Sie:

Wählen Sie Ihren Bereitstellungsansatz

Verwenden Sie den folgenden Entscheidungsablauf, um zu ermitteln, 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.   │  └──────────────────────┘
                  └──────────────────┘

Verwenden Sie ein Kubernetes-Volume (kein Fallback)

Verwenden Sie diesen Ansatz, wenn Sie auf jedem Knoten Modellgewichte auf NVMe haben und die einfachste Einrichtung wünschen — keine Amazon S3- oder Amazon FSx-Konfiguration PV/PVC, nein und keine InitContainer.

Bei der Einstellung überspringt modelSourceType: kubernetesVolume der Operator die Erstellung vollständig. PV/PVC Es wird kein CSI-Treiber, kein Amazon S3 S3-Sicherungshalter oder kein 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

Verwenden Sie ein Kubernetes-Volume mit Fallback

Verwenden Sie diesen Ansatz, wenn sich das Modell auf einem bestimmten Knoten möglicherweise auf NVMe 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 einen benutzerdefinierten Wert fest modelSourceType: kubernetesVolume und stellen ihn bereitinitContainer, der zuerst NVMe überprüft und dann 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

Bereitstellung mithilfe von Amazon S3 mit Prefetch und NVMe-Fallback

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

Wenn Sie die Einstellung auf einstellenprefetchEnabled: true, modelSourceType: s3 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 Modellgewichten und Modellgewichten mit Prefetch

Bei der 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 angebenmodel-weights, wannprefetchEnabled: true, ist es tatsächlich model-weights-copy das, was /opt/ml/model im Worker-Container montiert 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.

Wenn prefetchEnabled: false es nur ein Volume gibt (das nach Ihrem benannt istmodelVolumeMount.name) und es ist direkt darauf 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 AWS Anmeldeinformationen über IRSA (IAM Roles for Service Accounts) für Ihre Worker- oder Init-Container bereitzustellen — zum Beispiel, um Modellgewichte von Amazon S3 in einem Fallback-Szenario herunterzuladen.

Wenn Sie keine angeben ServiceAccount, wird die Standardeinstellung des ServiceAccount Namespaces verwendet.

Aktivieren Sie benutzerdefinierte Dienstkonten

Die Unterstützung für benutzerdefinierte Dienstkonten ist standardmäßig deaktiviert. Ein Clusteradministrator muss es 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 dieser Bezeichnung können Inferenzendpunkte auf sie 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 unten spec.kubernetes zu 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

Validierungsregeln

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 einen benutzerdefinierten Wert ServiceAccount mit Inferenzendpunkten verwenden, erstellt der HyperPod Inferenzoperator Deployments in Ihrem Namen. Alle Container im Inferenz-Pod — einschließlich Worker, Init-Container und Sidecars — erben die Berechtigungen der angegebenen. ServiceAccount Folgen Sie diesen bewährten Methoden, um Ihren Cluster zu schützen.

Sperren Sie RBAC-Berechtigungen

Geltungsbereich: IRSA IAM-Rollen

Schützen Sie das vom Benutzer zuweisbare Label

Laden Sie Modellgewichte vorab auf NVMe

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

Reservierte Datenträgernamen

Der Betreiber verwaltet mehrere interne Volumes, über die keine Änderungen vorgenommen werden können. kubernetes.volumes Die Verwendung eines dieser Namen führt zu einer KubernetesVolumeValidationFailed Bedingung.

Dinge, die Sie sich merken sollten

Fehlerbehebung

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