Déploiement de modèles sur Amazon SageMaker HyperPod - Amazon SageMaker AI

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éploiement de modèles sur Amazon SageMaker HyperPod

Amazon va SageMaker HyperPod désormais au-delà de la formation pour proposer une plateforme d'inférence complète qui associe la flexibilité de Kubernetes à l'excellence opérationnelle des services gérés. AWS Déployez, dimensionnez et optimisez vos modèles d'apprentissage automatique avec une fiabilité de niveau professionnel en utilisant le même HyperPod calcul tout au long du cycle de vie du modèle.

Amazon SageMaker HyperPod propose des interfaces de déploiement flexibles qui vous permettent de déployer des modèles par le biais de plusieurs méthodes, notamment kubectl, le SDK Python, l'interface utilisateur Amazon SageMaker Studio ou la CLI. HyperPod Le service fournit des fonctionnalités avancées de mise à l’échelle automatique avec une allocation dynamique des ressources qui s’ajuste automatiquement en fonction de la demande. En outre, il inclut des fonctionnalités complètes d'observabilité et de surveillance qui suivent les indicateurs critiques tels que time-to-first-token la latence et l'utilisation du GPU pour vous aider à optimiser les performances.

Note

Lors d'un déploiement sur des instances dotées d'un processeur graphique, vous pouvez utiliser le partitionnement du GPU avec la technologie GPU multi-instance (MIG) pour exécuter plusieurs charges de travail d'inférence sur un seul GPU. Cela permet une meilleure utilisation du GPU et une optimisation des coûts. Pour plus d'informations sur la configuration du partitionnement du GPU, consultezUtilisation de partitions GPU dans Amazon SageMaker HyperPod.

Infrastructure unifiée pour l’entraînement et l’inférence

Optimisez votre utilisation des GPU en effectuant une transition transparente des ressources de calcul entre les charges de travail d’entraînement et d’inférence. Cela réduit le coût total de possession tout en maintenant la continuité opérationnelle.

Options de déploiement adaptées aux entreprises

Déployez des modèles provenant de sources multiples, notamment des modèles à pondération ouverte et fermée d'Amazon SageMaker JumpStart et des modèles personnalisés d'Amazon S3 et Amazon, FSx avec prise en charge des architectures d'inférence à nœud unique et à nœuds multiples.

Mise en cache de valeurs-clés (KV) hiérarchisée gérée et routage intelligent

La mise en cache KV enregistre les vecteurs clé-valeur précalculés après le traitement des jetons précédents. Lorsque le jeton suivant est traité, les vecteurs n'ont pas besoin d'être recalculés. Grâce à une architecture de mise en cache à deux niveaux, vous pouvez configurer un cache L1 qui utilise la mémoire du processeur pour une réutilisation locale à faible latence, et un cache L2 qui utilise Redis pour permettre un partage de cache évolutif au niveau des nœuds.

Le routage intelligent analyse les demandes entrantes et les dirige vers l'instance d'inférence la plus susceptible de contenir les paires clé-valeur mises en cache pertinentes. Le système examine la demande puis l'achemine selon l'une des stratégies de routage suivantes :

  1. prefixaware— Les demandes suivantes avec le même préfixe d'invite sont acheminées vers la même instance

  2. kvaware— Les demandes entrantes sont acheminées vers l'instance ayant le taux de réussite du cache KV le plus élevé.

  3. session— Les demandes provenant de la même session utilisateur sont acheminées vers la même instance.

  4. roundrobin— Répartition uniforme des requêtes sans tenir compte de l'état du cache KV.

Pour plus d'informations sur l'activation de cette fonctionnalité, consultezConfigurez la mise en cache KV et le routage intelligent pour améliorer les performances.

Support de stockage hiérarchisé avec cache L2 intégré pour la mise en cache KV

S'appuyant sur l'infrastructure de cache KV existante, intègre HyperPod désormais le stockage hiérarchisé en tant qu'option de backend L2 supplémentaire aux côtés de Redis. Grâce au stockage hiérarchisé SageMaker géré intégré, cela permet d'améliorer les performances. Cette amélioration fournit aux clients une option plus évolutive et plus efficace pour le déchargement du cache, particulièrement avantageuse pour les charges de travail d'inférence LLM à haut débit. L'intégration permet de maintenir la compatibilité avec les serveurs du modèle vLLM et les capacités de routage existants tout en offrant de meilleures performances.

Note

Chiffrement des données : les données du cache KV (clés et valeurs d'attention) sont stockées non cryptées au repos afin d'optimiser la latence d'inférence et d'améliorer les performances. Pour les charges de travail soumises à des encryption-at-rest exigences strictes, envisagez le chiffrement des invites et des réponses au niveau de la couche application, ou désactivez la mise en cache.

Isolation des données : lorsque vous utilisez un stockage hiérarchisé géré comme backend de cache L2, plusieurs déploiements d'inférence au sein d'un cluster partagent le stockage en cache sans isolation. Les données du cache L2 KV (clés d'attention et valeurs) provenant de différents déploiements ne sont pas séparées. Pour les charges de travail nécessitant une isolation des données (scénarios multi-locataires, différents niveaux de classification des données), déployez-les sur des clusters distincts ou utilisez des instances Redis dédiées.

Déploiement de type multi-instance avec basculement automatique

HyperPod Inference prend en charge le déploiement de type multi-instance afin d'améliorer la fiabilité du déploiement et l'utilisation des ressources. Spécifiez une liste hiérarchisée de types d'instances dans votre configuration de déploiement, et le système sélectionne automatiquement parmi les alternatives disponibles lorsque votre type d'instance préféré manque de capacité. Le planificateur Kubernetes utilise l'affinité des preferredDuringSchedulingIgnoredDuringExecution nœuds pour évaluer les types d'instances par ordre de priorité, en plaçant les charges de travail sur le type d'instance le plus prioritaire disponible tout en garantissant le déploiement même lorsque les ressources préférées ne sont pas disponibles. Cette fonctionnalité permet d'éviter les échecs de déploiement dus à des contraintes de capacité tout en respectant vos préférences en matière de coûts et de performances, garantissant ainsi une disponibilité continue du service même en cas de fluctuations de capacité du cluster.

Affinité de nœud personnalisée pour un contrôle granulaire de la planification

HyperPod L'inférence prend en charge l'affinité personnalisée des nœuds afin de contrôler le placement de la charge de travail au-delà de la sélection du type d'instance. Spécifiez les critères de sélection des nœuds tels que la distribution des zones de disponibilité, le filtrage par type de capacité (à la demande ou sur place) ou des étiquettes de nœuds personnalisées nodeAffinity dans le champ. Le système prend en charge les contraintes de placement obligatoires requiredDuringSchedulingIgnoredDuringExecution et les préférences facultativespreferredDuringSchedulingIgnoredDuringExecution, offrant ainsi un contrôle total sur les décisions de planification des modules tout en préservant la flexibilité du déploiement.

Note

Nous collectons certaines mesures opérationnelles de routine pour garantir la disponibilité des services essentiels. La création de ces métriques est entièrement automatisée et n'implique aucun examen humain de la charge de travail d'inférence du modèle sous-jacent. Ces mesures concernent les opérations de déploiement, la gestion des ressources et l'enregistrement des terminaux.

Rubriques