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.
Notes de mise à jour SageMaker HyperPod d'Amazon Inference
Cette rubrique couvre les notes de publication qui suivent les mises à jour, les correctifs et les nouvelles fonctionnalités d'Amazon SageMaker HyperPod Inference. SageMaker HyperPod L'inférence vous permet de déployer et de faire évoluer des modèles d'apprentissage automatique sur vos HyperPod clusters avec une fiabilité digne de l'entreprise. Pour les versions générales, les mises à jour et les améliorations de la SageMaker HyperPod plateforme Amazon, consultezNotes de SageMaker HyperPod publication d'Amazon.
Pour plus d'informations sur les fonctionnalités SageMaker HyperPod d'inférence et les options de déploiement, consultezDéploiement de modèles sur Amazon SageMaker HyperPod.
SageMaker HyperPod Notes de mise à jour d'Inference : v3.1.2
Date de sortie : 6 mai 2026
Récapitulatif
Inference Operator v3.1.2 introduit la capture de données d'inférence pour l'enregistrement du trafic des terminaux, l'intégration du HuggingFace hub pour le déploiement direct du modèle, la gestion DNS Route 53 pour les domaines personnalisés, le déploiement du modèle NVMe local pour réduire la latence de démarrage à froid et les comptes de service personnalisés avec support IRSA.
Nouvelles fonctionnalités
-
Capture des données d'inférence — Enregistrez les entrées et les sorties à trois points de capture : point de terminaison SageMaker AI, équilibreur de charge (journaux d'accès ALB) et module de modélisation. Activez n'importe quelle combinaison
dataCapturedans votre CRD. Consultez Capture de données pour inférence sur HyperPod. -
HuggingFace Source du modèle — Déployez des modèles directement depuis le HuggingFace Hub sans pré-migration vers S3 ou FSx. Supporte les modèles fermés via
tokenSecretRef, l'épinglage des révisions etcommitSHAl'isolation des jetons. Compatible avec les environnements d'exécution VLLM, TGI et SGLang. Consultez Déployez des modèles depuis Amazon S3, Amazon FSx ou Hugging Face Hub à l'aide de kubectl. -
Route 53 DNS Management — Créez et gérez automatiquement des enregistrements DNS pour des domaines personnalisés via
dnsConfig. Consultez Certificats personnalisés et gestion du DNS Route 53 pour HyperPod Inference. -
Déploiement du modèle NVMe local : chargez les pondérations des modèles à partir du stockage NVMe local au nœud via
modelSourceType: kubernetesVolumeafin de réduire la latence lors du démarrage à froid. Supporte le retour à S3. Consultez Déployez des modèles à partir d'un stockage NVMe local à l'aide de kubectl. -
Comptes de service personnalisés — Attribuez des comptes personnalisés ServiceAccounts avec le support IRSA aux pods d'inférence via.
spec.kubernetes.serviceAccountName
Correctifs de bogue
-
Propagation des User-defined balises : les balises
InferenceEndpointConfigactivées se propagent désormais correctement vers leSageMakerEndpointRegistrationCRD et les ressources SageMaker AI en aval. Auparavant, les balises n'étaient pas transmises lors de la création ou des mises à jour de l'enregistrement des terminaux. -
Préservation des répliques à l'échelle automatique : correction d'un problème en raison duquel la mise à jour d'un
InferenceEndpointConfigou d'unJumpStartModelCR rétablissait le nombre de répliques à la valeur de la spécification, annulant ainsi le nombre de répliques actuel HPA/KEDA-managed . L'opérateur conserve désormais le nombre de répliques actives lors des mises à jour du CR. -
Validation CRD à échelle automatique : correction d'une expression régulière de
prometheusTrigger.serverAddressvalidation qui exigeait à tort un segment de chemin final, provoquant 404 erreurs lorsque KEDA était ajouté à l'URL de l'espace de travail AMP./api/v1/query -
Rotation des certificats : rotation des certificats personnalisés fixe qui ne se propage pas vers ALB après le redémarrage du pod opérateur.
Mise à niveau vers la version 3.1.2
Mise à niveau du casque :
Si l'opérateur d'inférence est déjà installé via Helm, utilisez les commandes suivantes pour effectuer la mise à niveau :
helm get values -n kube-system hyperpod-inference-operator \ > current-values.yaml cd sagemaker-hyperpod-cli/helm_chart/HyperPodHelmChart/\ charts/inference-operator helm upgrade hyperpod-inference-operator . -n kube-system \ -f current-values.yaml --set image.tag=v3.1 # Verification kubectl get deployment hyperpod-inference-operator-controller-manager \ -n hyperpod-inference-system \ -o jsonpath='{.spec.template.spec.containers[0].image}'
Add-on Mise à niveau d'EKS :
Si vous avez installé l'opérateur d'inférence en tant qu'EKS Add-on, passez à la dernière version.
Tout d'abord, vérifiez si cela hyperpodClusterArn figure déjà dans la configuration de votre module complémentaire :
CLUSTER=EKS_CLUSTER_NAME REGION=REGION aws eks describe-addon \ --cluster-name $CLUSTER \ --addon-name amazon-sagemaker-hyperpod-inference \ --region $REGION \ --query 'addon.configurationValues' --output text | jq .
S'il hyperpodClusterArn est présent dans la sortie, exécutez la commande suivante pour effectuer la mise à niveau :
aws eks update-addon \ --cluster-name $CLUSTER \ --addon-name amazon-sagemaker-hyperpod-inference \ --addon-version v1.2.0-eksbuild.1 \ --resolve-conflicts OVERWRITE \ --region $REGION
Si hyperpodClusterArn ce n'est pas le cas, récupérez la configuration actuelle, ajoutez-la et mettez-la à niveau :
HP_ARN=HYPERPOD_CLUSTER_ARN CURRENT_CONFIG=$(aws eks describe-addon \ --cluster-name $CLUSTER \ --addon-name amazon-sagemaker-hyperpod-inference \ --region $REGION \ --query 'addon.configurationValues' --output text) # Add hyperpodClusterArn to the configuration NEW_CONFIG=$(echo "$CURRENT_CONFIG" | jq --arg arn "$HP_ARN" \ '. + {hyperpodClusterArn: $arn}') aws eks update-addon \ --cluster-name $CLUSTER \ --addon-name amazon-sagemaker-hyperpod-inference \ --addon-version v1.2.0-eksbuild.1 \ --configuration-values "$NEW_CONFIG" \ --resolve-conflicts OVERWRITE \ --region $REGION
Attendez que le module complémentaire soit actif avant de déployer des modèles.
SageMaker HyperPod Notes de mise à jour d'Inference : v3.1
Date de sortie : 3 avril 2026
Récapitulatif
Inference Operator v3.1 introduit une configuration personnalisée des pods Kubernetes, la prise en charge des certificats personnalisés et des limites de demandes par pod.
Caractéristiques principales
-
Configuration personnalisée du module Kubernetes : ajout d'un nouveau
kuberneteschamp auInferenceEndpointConfigCRD qui permet aux utilisateurs de personnaliser les configurations du module d'inférence :-
Conteneurs d'initialisation personnalisés : exécutez des conteneurs d'initialisation définis par l'utilisateur avant le démarrage du serveur d'inférence (par exemple, réchauffement du cache, configuration du GDS). Les conteneurs d'initialisation sont injectés après le conteneur de prélecture de l'opérateur.
-
Volumes personnalisés — Ajoutez des volumes supplémentaires (
emptyDir,hostPath,configMap, etc.) à la spécification du pod, qui peuvent être référencés par les conteneurs d'initialisation via.volumeMounts -
Nom du planificateur personnalisé : spécifiez un planificateur Kubernetes personnalisé pour le placement des pods.
-
-
Certificats personnalisés — Utilisez vos propres certificats ACM pour les points de terminaison d'inférence au lieu de certificats auto-signés générés par l'opérateur, configurés via.
customCertificateConfigPrend en charge les certificats ACM approuvés par le public, les certificats CA AWS privés et les certificats importés depuis des autorités de certification externes. L'opérateur surveille l'état des certificats et prend en charge la détection automatique des renouvellements. -
Limites de demandes — Contrôlez le traitement des demandes par pod via la nouvelle
RequestLimitsconfiguration ci-dessousWorker, avec les champs configurables suivants :-
maxConcurrentRequests— Nombre maximal de demandes simultanées en vol par module. -
maxQueueSize— Demandes à mettre en file d'attente lorsque la limite de simultanéité est atteinte avant d'être rejetées. -
overflowStatusCode— Code d'état HTTP renvoyé lorsque les limites sont dépassées (par défaut : 429).
-
Pour obtenir des informations détaillées, notamment les prérequis et les instructions de mise à niveau, consultez les sections ci-dessous.
Conditions préalables
Pour utiliser la fonctionnalité de certificats personnalisés, ajoutez les autorisations suivantes à votre rôle d'exécution d'opérateur d'inférence :
{ "Sid": "ACMCertificateAccess", "Effect": "Allow", "Action": [ "acm:DescribeCertificate", "acm:GetCertificate" ], "Resource": "arn:aws:acm:*:*:certificate/*" }
Mise à niveau vers la version 3.1
Si l'opérateur d'inférence est déjà installé via Helm, utilisez les commandes suivantes pour effectuer la mise à niveau :
helm get values -n kube-system hyperpod-inference-operator \ > current-values.yaml cd sagemaker-hyperpod-cli/helm_chart/HyperPodHelmChart/\ charts/inference-operator helm upgrade hyperpod-inference-operator . -n kube-system \ -f current-values.yaml --set image.tag=v3.1 # Verification kubectl get deployment hyperpod-inference-operator-controller-manager \ -n hyperpod-inference-system \ -o jsonpath='{.spec.template.spec.containers[0].image}'
SageMaker HyperPod Notes de mise à jour d'Inference : v3.0
Date de sortie : 23 février 2026
Récapitulatif
Inference Operator 3.0 introduit l' Add-on intégration EKS pour une gestion simplifiée du cycle de vie, la prise en charge de l'affinité des nœuds pour un contrôle granulaire de la planification et un meilleur balisage des ressources. Les Helm-based installations existantes peuvent être migrées vers l'EKS à Add-on l'aide du script de migration fourni. Mettez à jour votre rôle d'exécution d'opérateur d'inférence avec de nouvelles autorisations de balisage avant la mise à niveau.
Caractéristiques principales
-
EKS Add-on Integration : gestion Enterprise-grade du cycle de vie avec expérience d'installation simplifiée
-
Affinité des nœuds : contrôle de planification granulaire pour exclure les instances ponctuelles, privilégier les zones de disponibilité ou cibler les nœuds avec des étiquettes personnalisées
Pour obtenir des informations détaillées, notamment les conditions requises, les instructions de mise à niveau et les conseils de migration, consultez les sections ci-dessous.
Conditions préalables
Avant de passer à la version 3.0 de Helm, les clients doivent ajouter des autorisations de balisage supplémentaires à leur rôle d'opérateur d'inférence. Dans le cadre de l'amélioration du balisage et de la sécurité des ressources, l'opérateur d'inférence étiquette désormais les ressources ALB, S3 et ACM. Cette amélioration nécessite des autorisations supplémentaires dans le rôle d'exécution de l'opérateur d'inférence. Ajoutez les autorisations suivantes à votre rôle d'exécution d'opérateur d'inférence :
{ "Sid": "CertificateTagginPermission", "Effect": "Allow", "Action": [ "acm:AddTagsToCertificate" ], "Resource": "arn:aws:acm:*:*:certificate/*", }, { "Sid": "S3PutObjectTaggingAccess", "Effect": "Allow", "Action": [ "s3:PutObjectTagging" ], "Resource": [ "arn:aws:s3:::<TLS_BUCKET>/*" # Replace * with your TLS bucket ] }
Mise à niveau vers la version 3.0
Si l'opérateur d'inférence est déjà installé via Helm, utilisez les commandes suivantes pour effectuer la mise à niveau :
helm get values -n kube-system hyperpod-inference-operator \ > current-values.yaml cd sagemaker-hyperpod-cli/helm_chart/HyperPodHelmChart/\ charts/inference-operator helm upgrade hyperpod-inference-operator . -n kube-system \ -f current-values.yaml --set image.tag=v3.0 # Verification kubectl get deployment hyperpod-inference-operator-controller-manager \ -n hyperpod-inference-system \ -o jsonpath='{.spec.template.spec.containers[0].image}'
Add-on Migration de Helm vers EKS
Si l'opérateur d'inférence est installé via Helm avant la version 3.0, nous vous recommandons de migrer Add-on vers EKS pour obtenir des mises à jour rapides sur les nouvelles fonctionnalités qui seront publiées pour Inference Operator. Ce script fait migrer l'opérateur SageMaker HyperPod d'inférence d'une Helm-based installation à une installation EKS Add-on .
Vue d'ensemble : le script prend un nom de cluster et une région comme paramètres, récupère la configuration d'installation Helm existante et migre vers le déploiement EKS Add-on . Il crée de nouveaux rôles IAM pour l'opérateur d'inférence, le contrôleur ALB et l'opérateur KEDA.
Avant de migrer l'opérateur d'inférence, le script s'assure que les dépendances requises (pilote CSI S3, pilote FsX CSI, gestionnaire de certificats et serveur de mesures) existent. S'ils n'existent pas, il les déploie en tant que Add-on.
Une fois la Add-on migration de l'opérateur d'inférence terminée, le script migre également S3, FSx et d'autres dépendances (ALB, KEDA, cert-manager, metrics-server) si elles ont été initialement installées via le graphique Inference Operator Helm. --skip-dependencies-migrationÀ utiliser pour ignorer cette étape pour le pilote CSI S3, le pilote FsX CSI, le gestionnaire de certificats et le serveur de mesures. Notez que ALB et KEDA sont installés Add-on dans le même espace de noms que l'opérateur d'inférence et seront migrés dans le cadre de l'opérateur d'inférence. Add-on
Important
Pendant la migration, ne déployez pas de nouveaux modèles car ils ne seront pas déployés tant que la migration ne sera pas terminée. Une fois que l'opérateur d'inférence Add-on est en état ACTIF, de nouveaux modèles peuvent être déployés. La migration prend généralement de 15 à 20 minutes, et elle peut être terminée en 30 minutes si seuls quelques modèles sont actuellement déployés.
Conditions préalables à la migration :
AWS CLI configuré avec les informations d'identification appropriées
kubectl configuré avec accès à votre cluster EKS
Casque installé
Installation Helm existante de l'opérateur d'inférence hyperpode
Note
Les endpoints déjà en cours d'exécution ne seront pas interrompus pendant le processus de migration. Les terminaux existants continueront à gérer le trafic sans interruption tout au long de la migration.
Obtenir le script de migration :
git clone https://github.com/aws/sagemaker-hyperpod-cli.git cd sagemaker-hyperpod-cli/helm_chart/HyperPodHelmChart/\ charts/inference-operator/migration
Utilisation :
./helm_to_addon.sh [OPTIONS] \ --cluster-name <cluster-name> (Required) \ --region <region> (Required) \ --helm-namespace kube-system (Optional) \ --auto-approve (Optional) \ --skip-dependencies-migration (Optional) \ --s3-mountpoint-role-arn <s3-mountpoint-role-arn> (Optional) \ --fsx-role-arn <fsx-role-arn> (Optional)
Options :
--cluster-name NAME— Nom du cluster EKS (obligatoire)--region REGION— AWS région (obligatoire)--helm-namespace NAMESPACE— Espace de noms dans lequel le graphique Helm est installé (par défaut : kube-system) (facultatif)--s3-mountpoint-role-arn ARN— ARN du rôle IAM du pilote S3 Mountpoint CSI (facultatif)--fsx-role-arn ARN— ARN du rôle IAM du pilote FSx CSI (facultatif)--auto-approve— Ignorez les demandes de confirmation si cet indicateur est activé.step-by-stepet s'auto-approveexcluent mutuellement, si cela--auto-approveest indiqué, ne le spécifiez pas--step-by-step(facultatif)--step-by-step— Faites une pause après chaque étape majeure pour passer en revue. Cela ne doit pas être mentionné s'--auto-approveil est déjà ajouté (facultatif)--skip-dependencies-migration— Ignorer la migration des Helm-installed dépendances vers Add-on. Car les dépendances n'ont PAS été installées via le graphique Inference Operator Helm, ou si vous souhaitez les gérer séparément. (facultatif)
Exemples :
Migration de base (migre les dépendances) :
./helm_to_addon.sh \ --cluster-name my-cluster \ --region us-east-1
Auto-approve sans instructions :
./helm_to_addon.sh \ --cluster-name my-cluster \ --region us-east-1 \ --auto-approve
Ignorez la migration des dépendances pour FSx, S3 Mountpoint, le gestionnaire de certificats et le serveur Metrics :
./helm_to_addon.sh \ --cluster-name my-cluster \ --region us-east-1 \ --skip-dependencies-migration
Fournissez les rôles IAM S3 et FSx existants :
./helm_to_addon.sh \ --cluster-name my-cluster \ --region us-east-1 \ --s3-mountpoint-role-arn arn:aws:iam::123456789012:role/s3-csi-role \ --fsx-role-arn arn:aws:iam::123456789012:role/fsx-csi-role
Emplacement de sauvegarde :
Les sauvegardes sont stockées dans /tmp/hyperpod-migration-backup-<timestamp>/
Les sauvegardes permettent une migration et une restauration en toute sécurité :
Annulation en cas d'échec : si la migration échoue, le script peut automatiquement restaurer votre cluster à son état antérieur à la migration à l'aide des configurations sauvegardées
Piste d'audit : fournit un enregistrement complet de ce qui existait avant la migration à des fins de résolution des problèmes et de conformité
Référence de configuration : vous permet de comparer les configurations avant et après la migration
Restauration manuelle : si nécessaire, vous pouvez inspecter et restaurer manuellement des ressources spécifiques à partir du répertoire de sauvegarde
Annulation :
Si la migration échoue, le script demande une confirmation à l'utilisateur avant de lancer le rollback afin de rétablir l'état précédent.
SageMaker HyperPod Notes de mise à jour d'Inference : v2.3
Quoi de neuf
Cette version introduit de nouveaux champs facultatifs dans les définitions de ressources personnalisées (CRD) afin d'améliorer la flexibilité de configuration du déploiement.
Fonctions
-
Types d'instances multiples
-
Fiabilité de déploiement améliorée : prend en charge les configurations de type multi-instance avec basculement automatique vers d'autres types d'instances lorsque les options préférées manquent de capacité
-
Planification intelligente des ressources : utilise l'affinité des nœuds Kubernetes pour hiérarchiser les types d'instances tout en garantissant le déploiement même lorsque les ressources préférées ne sont pas disponibles
-
Coûts et performances optimisés — Conserve vos préférences en matière de type d'instance et prévient les défaillances liées à la capacité lors des fluctuations du cluster
-
Correctifs de bogue
Les modifications apportées invocationEndpoint au champ dans la spécification du InferenceEndpointConfig prendront désormais effet :
-
Si le
invocationEndpointchamp est corrigé ou mis à jour, les ressources dépendantes, telles que leIngressLoad Balancer SageMaker et le EndpointSageMakerEndpointRegistration, seront mises à jour avec normalisation. -
La valeur de
invocationEndpointprovided sera stockée telle quelle dans laInferenceEndpointConfigspécification elle-même. Lorsque cette valeur est utilisée pour créer un Load Balancer et, si elle est activée, un point de SageMaker terminaison, elle sera normalisée pour comporter une barre oblique.-
v1/chat/completionssera normalisé/v1/chat/completionspour leIngress, AWS Load Balancer et Endpoint. SageMaker Pour leSageMakerEndpointRegistration, il sera affiché dans ses spécifications sousv1/chat/completionsla forme. -
///invokesera normalisé/invokepour leIngress, AWS Load Balancer et Endpoint. SageMaker Pour leSageMakerEndpointRegistration, il sera affiché dans ses spécifications sousinvokela forme.
-
Installation de Helm :
Suivez : https://github.com/aws/sagemaker-hyperpod-cli/tree/main/helm_chart
Si vous vous concentrez uniquement sur l'installation de l'opérateur d'inférence, après l'étape 1Set Up Your Helm Environment, c'est-à-dire faites-lecd HyperPodHelmChart/charts/inference-operator. Puisque vous vous trouvez dans le répertoire des diagrammes des opérateurs d'inférence lui-même, dans les commandes, où que vous soyezhelm_chart/HyperPodHelmChart, remplacez par..
Passez à la version 2.3 de l'opérateur si celui-ci est déjà installé :
cd sagemaker-hyperpod-cli/helm_chart/HyperPodHelmChart/\ charts/inference-operator helm get values -n kube-system hyperpod-inference-operator \ > current-values.yaml helm upgrade hyperpod-inference-operator . \ -n kube-system \ -f current-values.yaml \ --set image.tag=v2.3