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 pondérations des modèles à partir du stockage NVMe local d'un nœud au lieu de les transférer sur le réseau depuis Amazon S3 ou Amazon FSx. La lecture locale des pondérations élimine le saut sur le réseau lors du démarrage du pod, ce qui réduit le temps de démarrage à froid du pod par inférence et est utile pour le dimensionnement automatique des événements, la mise à l'échelle des 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 éphémère et local aux nœuds : 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 cela différemment : certaines nécessitent que vous préremplissiez chaque nœud, d'autres recourent automatiquement à 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 (aucune 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 : aucune configuration Amazon S3 ou Amazon FSx, ni PV/PVC aucun InitContainers.

Lorsque vous définissezmodelSourceType: kubernetesVolume, l'opérateur ignore complètement PV/PVC la création. Aucun pilote CSI, aucun fusible Amazon S3 ou aucun support Amazon FSx n'est utilisé. Le model-weights volume fourni par le client est utilisé directement dans les spécifications du module, 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 ou non être sur NVMe 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 installeraient un chemin vide ou inexistant, ce qui provoquerait la défaillance du serveur de modèles.

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

Configurer l'IRSA

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

Déploiement du modèle

Déployez à l'aide d'Amazon S3 avec prefetch et solution de secours NVMe

Utilisez cette approche lorsque vous souhaitez obtenir des performances d'inférence en transférant le poids du modèle à 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 poids des modèles et les poids des modèles et copier avec Prefetch

Lors de l'utilisation de 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.

Lorsqu'prefetchEnabled: falseil n'y a qu'un seul volume (nommé d'après votremodelVolumeMount.name) et qu'il est monté directement sur/opt/ml/model.

Configuration d'un compte de service personnalisé

Vous pouvez attribuer un Kubernetes personnalisé ServiceAccount à vos pods de point 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 le cadre d'un scénario de repli.

Si vous ne spécifiez pas a 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 avant que les utilisateurs puissent faire référence à la personnalisation ServiceAccounts dans leurInferenceEndpointConfig.

Étiqueter 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 l'augmentation non autorisée des privilèges.

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 :

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

Lorsque vous utilisez une option 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 spécifiées. ServiceAccount Suivez ces bonnes pratiques pour sécuriser votre cluster.

Verrouiller les autorisations RBAC

Étendue des rôles IRSA IAM

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

Précharger les poids des modèles dans NVMe

Si vous devez préremplir le 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 par. kubernetes.volumes L'utilisation de l'un de ces noms entraîne 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.