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 SageMaker HyperPod à jour d'Amazon Inference
Cette rubrique couvre les notes de version 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é de niveau professionnel. Pour les versions générales, les mises à jour et les améliorations de la SageMaker HyperPod plateforme Amazon, consultezNotes de SageMaker HyperPod mise à jour 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.2
Date de sortie : 12 juin 2026
Récapitulatif
Inference Operator v3.2 permet aux clients de déployer des LLM à contexte long (tels que Llama 3.3 70B) avec une latence prévisible par jeton en cas de charge simultanée. Cette version introduit le préremplissage et le décodage désagrégés (DDP), qui sépare la phase de préremplissage liée au calcul et la phase de décodage liée à la bande passante de la mémoire sur des pools de GPU distincts et transfère le cache KV entre eux via EFA avec RDMA. GPU-Direct DDP réduit la latence de queue par jeton, augmente le débit et vous permet de faire évoluer la capacité de préremplissage et de décodage de manière indépendante. Outre DPR, nous incluons d'autres corrections de bogues dans cette version.
Principales caractéristiques
Préremplissage et décodage désagrégés (DDP)
-
Ajout d'un nouveau
pdSpecchamp auInferenceEndpointConfigCRD qui permet une inférence désagrégée. Lorsque cettepdSpecoption est définie, l'opérateur fournit des modules de préremplissage et de décodage séparés, les connecte ensemble via le routeur DPR et transfère le cache KV entre eux à l'aide de LMCache sur NIXL et EFA avec RDMA. GPU-Direct Voici des exemples de champs configurables (pour plus de configuration, consultez le guide de l'utilisateur) :-
routingThreshold— Token-length seuil au-dessus duquel les demandes utilisent le chemin désagrégé. En dessous du seuil, les requêtes contournent le préremplisseur et vont directement au décodeur. -
prefillSpec.argsetdecodingSpec.args— Les indicateurs Per-role vLLM ont été fusionnésworker.argsau démarrage. -
prefillSpec.replicasetdecodingSpec.replicas— Adaptez la capacité de préremplissage et de décodage indépendamment pour correspondre à la distribution des longueurs d'entrée et de sortie de votre charge de travail.
-
-
Prérequis
-
Pour déployer des points de terminaison DDP, les nœuds de votre cluster doivent prendre en charge l'EFA avec lecture et écriture RDMA, et être situés dans la même zone de disponibilité pour les communications nœud à nœud à bande passante élevée.
-
Familles d'instances recommandées :
ml.p5.48xlargeml.p5e.48xlarge,ml.p5en.48xlarge,ml.p6-b200.48xlarge,ml.p6-b300.48xlarge.
-
Correctifs de bogue
-
Planification des opérateurs sur les nœuds x86 : le déploiement des opérateurs permet désormais de
nodeAffinityplanifier uniquement sur les nœuds Linux amd64. -
Nous incluons d'autres correctifs mineurs et de sécurité.
Mise à niveau vers la v3.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.2 # 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 EKS :
Si vous avez installé l'opérateur d'inférence en tant qu'EKS Add-on, passez à la dernière version :
CLUSTER=EKS_CLUSTER_NAME REGION=REGION aws eks update-addon \ --cluster-name $CLUSTER \ --addon-name amazon-sagemaker-hyperpod-inference \ --addon-version v1.3.0-eksbuild.1 \ --resolve-conflicts OVERWRITE \ --region $REGION
SageMaker HyperPod Notes de mise à jour d'inférence : 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 la journalisation du trafic des terminaux, l'intégration du HuggingFace hub pour le déploiement direct de modèles, la gestion DNS Route 53 pour les domaines personnalisés, le déploiement de modèles NVMe locaux pour réduire la latence de démarrage à froid et des comptes de service personnalisés avec support IRSA.
Nouvelles fonctionnalités
-
Capture de 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èle. Activez n'importe quelle combinaison via
dataCapturevotre CRD. Consultez Capture de données à des fins d'inférence sur HyperPod. -
HuggingFace Source du modèle : déployez des modèles directement depuis HuggingFace Hub sans passer par S3 ou FSx au préalable. Supporte les modèles sécurisés via
tokenSecretRef, l'épinglage des révisions viacommitSHAet l'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. -
Gestion DNS Route 53 — Créez et gérez automatiquement les enregistrements DNS pour les domaines personnalisés via
dnsConfig. Consultez Certificats personnalisés et gestion du DNS Route 53 pour HyperPod Inference. -
Déploiement de modèles NVMe locaux : chargez les poids des modèles à partir du stockage NVMe local des nœuds afin de réduire la latence au démarrage
modelSourceType: kubernetesVolumeà 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 fonctionnalités personnalisées ServiceAccounts avec le support IRSA aux modules 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 d' SageMaker IA en aval. Auparavant, les balises n'étaient pas transmises lors de la création ou des mises à jour de l'enregistrement des terminaux. -
Mise à l'échelle automatique de la préservation des répliques : correction d'un problème en raison duquel la mise à jour d'un
InferenceEndpointConfigou d'unJumpStartModelCR réinitialisait le nombre de répliques à la valeur spécifiée, remplaçant ainsi le nombre de HPA/KEDA-managed répliques actuel. L'opérateur conserve désormais le nombre de répliques actives lors des mises à jour CR. -
Validation CRD automatique : correction d'une expression régulière de
prometheusTrigger.serverAddressvalidation qui exigeait à tort un segment de chemin final, ce qui provoquait 404 erreurs lors de l'ajout par KEDA à l'URL de l'espace de travail AMP./api/v1/query -
Rotation des certificats : correction de la rotation des certificats personnalisés qui ne se propageait pas vers ALB après le redémarrage du module opérateur.
Passez à 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 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 se trouve 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 effectuez la mise à 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 sur l'inférence : v3.1
Date de sortie : 3 avril 2026
Récapitulatif
Inference Operator v3.1 introduit la configuration personnalisée des pods Kubernetes, la prise en charge des certificats personnalisés et des limites de demandes par pod.
Principales caractéristiques
-
Configuration personnalisée du pod Kubernetes : ajout d'un nouveau
kuberneteschamp auInferenceEndpointConfigCRD qui permet aux utilisateurs de personnaliser les configurations du pod 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 Init sont injectés après le conteneur de prélecture de l'opérateur.
-
Volumes personnalisés : ajoutez des volumes supplémentaires (
emptyDir,hostPathconfigMap, etc.) à la spécification du pod, qui peuvent être référencés par les conteneurs d'initialisation viavolumeMounts. -
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 du certificat et prend en charge la détection automatique des renouvellements. -
Limites de demandes — Contrôlez la gestion des demandes par pod via la nouvelle
RequestLimitsconfiguration ci-dessousWorker, avec les champs configurables suivants :-
maxConcurrentRequests— Nombre maximum 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é 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 Node Affinity 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.
Principales caractéristiques
-
EKS Add-on Integration : gestion Enterprise-grade du cycle de vie avec une expérience d'installation simplifiée
-
Affinité des nœuds : contrôle de planification granulaire pour exclure les instances ponctuelles, préférer les zones de disponibilité ou cibler les nœuds avec des étiquettes personnalisées
Pour obtenir des informations détaillées, notamment les prérequis, 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'exécution 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 ] }
Passez à 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}'
De la barre vers EKS Add-on Migration
Si l'opérateur d'inférence est installé via Helm avant la version 3.0, nous vous recommandons de migrer vers EKS pour obtenir des mises Add-on à jour en temps opportun sur les nouvelles fonctionnalités qui seront publiées pour Inference Operator. Ce script fait migrer l'opérateur SageMaker HyperPod d'inférence de l' Helm-based installation vers l'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 S3 CSI, pilote FSx CSI, cert-manager et metrics-server) 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 Helm de l'opérateur d'inférence. Permet d'--skip-dependencies-migrationignorer cette étape pour le pilote S3 CSI, le pilote FSx CSI, le cert-manager et le serveur de métriques. Notez qu'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 déployés qu'une fois la migration terminée. Une fois que l'opérateur d'inférence Add-on est à l'état ACTIF, de nouveaux modèles peuvent être déployés. Le temps de migration prend généralement de 15 à 20 minutes et peut être effectué 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 hyperpod
Note
Les terminaux déjà en cours d'exécution ne seront pas interrompus pendant le processus de migration. Les terminaux existants continueront de 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 où le graphique Helm est installé (par défaut : kube-system) (facultatif)--s3-mountpoint-role-arn ARN— Rôle IAM ARN du pilote CSI S3 Mountpoint (facultatif)--fsx-role-arn ARN— Rôle IAM ARN du pilote FSx CSI (facultatif)--auto-approve— Ignorez les invites de confirmation si cet indicateur est activé.step-by-stepet s'auto-approveexcluent mutuellement,--auto-approves'ils sont donnés, ne le spécifiez pas--step-by-step(facultatif)--step-by-step— Faites une pause après chaque étape importante pour passer en revue. Cela ne doit pas être mentionné s'--auto-approveil est déjà ajouté (facultatif)--skip-dependencies-migration— Ignorez la migration des Helm-installed dépendances vers Add-on. Car les dépendances n'ont PAS été installées via le graphique Helm de l'opérateur d'inférence, 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, le point de montage S3, 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 sécurisées :
Restauration en cas d'échec : en cas d'échec de la migration, le script peut restaurer automatiquement l'état de votre cluster avant 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 dépannage et de conformité
Référence de configuration : 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 à l'utilisateur de confirmer avant de lancer la restauration pour 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 la 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'instance 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 et SageMaker EndpointSageMakerEndpointRegistration, seront mises à jour lors de la normalisation. -
La valeur
invocationEndpointfournie sera stockée telle quelle dans laInferenceEndpointConfigspécification elle-même. Lorsque cette valeur est utilisée pour créer un équilibreur de charge et, si elle est activée, un SageMaker point de terminaison, elle sera normalisée pour comporter une seule barre oblique.-
v1/chat/completionssera normalisé/v1/chat/completionspour AWS Load Balancer et SageMaker Endpoint.IngressPour leSageMakerEndpointRegistration, il sera affiché dans ses spécifications sous la formev1/chat/completions. -
///invokesera normalisé/invokepour AWS Load Balancer et SageMaker Endpoint.IngressPour leSageMakerEndpointRegistration, il sera affiché dans ses spécifications sous la formeinvoke.
-
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 du graphique des opérateurs d'inférence lui-même, dans les commandes, partout où vous le voyezhelm_chart/HyperPodHelmChart, remplacez par..
Mettez à niveau l'opérateur vers la v2.3 au cas où il serait 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