Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Déployez des modèles à partir d'un stockage NVMe local à l'aide de kubectl

Cette rubrique explique comment déployer des points de terminaison d'inférence sur Amazon SageMaker HyperPod qui chargent les poids des modèles à partir du stockage NVMe local d'un nœud au lieu de les transférer via le réseau depuis Amazon S3 ou Amazon FSx. La lecture locale des poids élimine le saut réseau lors du démarrage du pod, ce qui réduit le temps de démarrage à froid du pod d'inférence et est utile pour les événements de dimensionnement automatique, les charges de travail à partir de zéro et les basculements sensibles à la latence. Pour les charges de travail pour lesquelles la latence de démarrage à froid n'est pas un problème, utilisez modelSourceType: s3 ou fsx et ignorez cette rubrique.

Le NVMe local est local et éphémère : les données du NVMe sont perdues lorsqu'un nœud est remplacé, par exemple lors d'une interruption ponctuelle, d'une panne matérielle ou d'une actualisation de l'AMI. Les approches décrites dans cette rubrique traitent ce problème différemment : certaines nécessitent de pré-remplir chaque nœud, d'autres font automatiquement appel à Amazon S3 lorsque le modèle n'est pas mis en cache localement. Le stockage d'instance NVMe local se trouve généralement dans les familles d'instances P, G et Trn. Consultez les spécifications du magasin d'instances Amazon EC2 pour valider la disponibilité de votre type d'instance.

Vous pouvez choisir l'une des approches suivantes en fonction de vos besoins de stockage :

Conditions préalables

Avant de commencer, vérifiez les points suivants :

Choisissez votre approche de déploiement

Utilisez le flux de décision suivant pour déterminer l'approche la mieux adaptée à votre cas d'utilisation.

                  ┌────────────────────────────┐
                  │ 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.   │  └──────────────────────┘
                  └──────────────────┘

Déploiement à l'aide d'un volume Kubernetes (pas de solution de secours)

Utilisez cette approche lorsque vous avez des pondérations de modèle sur NVMe sur chaque nœud et que vous souhaitez la configuration la plus simple : pas de configuration Amazon S3 ou Amazon FSx PV/PVC, non et pas d'InitContainers.

Lorsque vous définissezmodelSourceType: kubernetesVolume, l'opérateur ignore complètement PV/PVC la création. Aucun pilote CSI, aucun support de fusible Amazon S3 ou aucun support Amazon FSx n'est utilisé. Le model-weights volume fourni par le client est utilisé directement dans la spécification du pod, et le travailleur lit les données du modèle depuis NVMe à l'adresse. /opt/ml/model

Déploiement à l'aide d'un volume Kubernetes avec solution de secours

Utilisez cette approche lorsque le modèle peut être sur NVMe ou non sur un nœud donné. Un hostPath volume ne fonctionne que sur les nœuds où les données existent : les pods planifiés sur d'autres nœuds créeraient un chemin vide ou inexistant, provoquant la défaillance du serveur modèle.

Dans cette approche, vous définissez modelSourceType: kubernetesVolume et fournissez une personnalisation initContainer qui vérifie d'abord NVMe et télécharge depuis Amazon S3 à l'aide des informations d'identification IRSA si le modèle est absent.

Configurer IRSA

Avant le déploiement, configurez les rôles IAM pour les comptes de service (IRSA) pour fournir les informations d'identification de vos pods à télécharger depuis Amazon S3.

Déploiement du modèle

Déployez à l'aide d'Amazon S3 avec Prefetch et NVMe Fallback

Utilisez cette approche lorsque vous souhaitez inférer les performances en répartissant les poids du modèle dans la RAM, avec un retour automatique vers Amazon S3 si le modèle n'est pas mis en cache localement sur NVMe.

Lorsque vous définissez modelSourceType: s3 avecprefetchEnabled: true, l'opérateur crée automatiquement deux volumes :

Vous ajoutez un nvme-cache volume personnalisé pointant vers le stockage NVMe local du nœud et un volume personnalisé initContainer qui :

Comprendre les pondérations des modèles et les pondérations des modèles avec Prefetch

Lors de l'utilisation de la fonction prefetch, l'opérateur crée deux volumes liés au modèle :

Dans votreInferenceEndpointConfig, vous définissez :

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

Pendant que vous faites référencemodel-weights, quandprefetchEnabled: true, c'est en fait model-weights-copy ce qui est monté /opt/ml/model dans le conteneur de travail. Lorsque vous utilisez un InitContainer personnalisé, assurez-vous de copier les données dans le volume appelémodel-weights-copy, c'est là que le travailleur s'attend à les trouver.

Quand prefetchEnabled: false il n'y a qu'un seul volume (nommé d'après le vôtremodelVolumeMount.name) et qu'il est monté directement sur/opt/ml/model.

Configurer un compte de service personnalisé

Vous pouvez attribuer un Kubernetes personnalisé ServiceAccount à vos pods de points de terminaison d'inférence à l'aide du champ duspec.kubernetes.serviceAccountName. InferenceEndpointConfig Cela est utile pour fournir des AWS informations d'identification via IRSA (IAM Roles for Service Accounts) à vos conteneurs de travail ou à vos conteneurs d'initialisation, par exemple pour télécharger les pondérations des modèles depuis Amazon S3 dans un scénario de repli.

Si vous ne spécifiez pas de ServiceAccount, la valeur par défaut de l'espace de noms ServiceAccount est utilisée.

Activer les comptes de service personnalisés

La prise en charge des comptes de service personnalisés est désactivée par défaut. Un administrateur de cluster doit l'activer dans la configuration Helm de l'opérateur pour que les utilisateurs puissent faire référence à la personnalisation ServiceAccounts dans leurInferenceEndpointConfig.

Étiquetez le compte de service

Avant de pouvoir référencer une personnalisation ServiceAccount, un administrateur de cluster doit l'étiqueter comme étant assignable par l'utilisateur :

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

Ce n'est qu' ServiceAccounts avec cette étiquette que les points de terminaison d'inférence peuvent être référencés. Il s'agit d'un contrôle de sécurité destiné à empêcher toute escalade de privilèges non autorisée.

Spécifiez le compte de service dans votre configuration

Ajoutez le serviceAccountName champ ci-dessous spec.kubernetes dans votre InferenceEndpointConfig :

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

Règles de validation

L'opérateur valide le serviceAccountName champ lors des opérations de création et de mise à jour. Votre déploiement sera rejeté avec un DeploymentFailed statut si l'une des conditions suivantes est remplie :

Meilleures pratiques de sécurité pour les comptes de service personnalisés

Lorsque vous utilisez une configuration personnalisée ServiceAccount avec des points de terminaison d'inférence, l'opérateur d' HyperPod inférence crée des déploiements en votre nom. Tous les conteneurs du module d'inférence, y compris le worker, les conteneurs d'initialisation et les sidecars, héritent des autorisations des éléments spécifiés. ServiceAccount Suivez ces bonnes pratiques pour sécuriser votre cluster.

Verrouiller les autorisations RBAC

Champ d'application des rôles IAM de l'IRSA

Protégez l'étiquette assignable par l'utilisateur

Préchargez les poids du modèle dans NVMe

Si vous devez préremplir NVMe sur des nœuds spécifiques avant le déploiement, vous pouvez utiliser un module unique pour effectuer la synchronisation depuis Amazon S3.

Noms de volumes réservés

L'opérateur gère plusieurs volumes internes qui ne peuvent pas être remplacés via. kubernetes.volumes L'utilisation de l'un de ces noms entraîne la création d'une KubernetesVolumeValidationFailed condition.

Choses à retenir

Résolution des problèmes

Utilisez ces commandes de débogage si votre déploiement ne fonctionne pas comme prévu.