View a markdown version of this page

Notes de mise SageMaker HyperPod à jour d'Amazon Inference - Amazon SageMaker AI
v2.0.0-eksbuild.2/Opérateur v3.6v1.6.0-eksbuild.1/Opérateur v3.5v1.5.0-eksbuild.1/Opérateur v3.4v1.4.0-eksbuild.1/Opérateur v3.3v1.3.0-eksbuild.1/Opérateur v3.2v1.2.0-eksbuild.1/Opérateur v3.1.2Opérateur v3.1Opérateur v3.0Opérateur v2.3

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 sur l'inférence : HyperPod Inference Amazon EKS v2.0.0-eksbuild.2 et Inference Operator v3.6

Date de sortie : 10 septembre 2026

Récapitulatif

La v2.0.0-eksbuild.2 version du module complémentaire HyperPod Inference Amazon EKS introduit l' HyperPod Inference Gateway, une Kubernetes-native couche de LLM-aware routage qui distribue le trafic d'inférence entre les pods servant des modèles en utilisant le contenu du corps de la demande et la sélection des points de terminaison. GPU-aware L'opérateur d'inférence et la passerelle d'inférence sont fournis ensemble dans le cadre de cette version complémentaire.

Il s'agit d'une mise à jour majeure du module complémentaire, du v1.6.0-eksbuild.1 auv2.0.0-eksbuild.2. La mise à jour reflète l'ajout d'Inference Gateway, et la version reste rétrocompatible avec les fonctionnalités complémentaires existantes. Si vous n'avez besoin d'aucun des composants, vous pouvez le désactiver dans la configuration du module complémentaire en réglant inferenceGateway.enabled ou inferenceOperator.enabled surfalse.

Passerelle d'inférence

  • Passerelle d'inférence  : acheminez le trafic d'inférence pour plusieurs modèles via un point de terminaison de passerelle unique à l'aide de trois couches de routage : un Body-Based routeur qui lit le model champ de demande, la passerelle avec HttpRoute pour le routage basé sur les en-têtes et un Endpoint Picker. GPU-aware Configurez la passerelle avec le nouveau InferenceGatewayConfig CRD, y compris les planificateurs par modèle, les pondérations de notation, la prise en charge de l'adaptateur LoRa et la terminaison TLS en option. Consultez Passerelle d'inférence pour Amazon SageMaker HyperPod Inference.

Opérateur d'inférence

  • Intégration de la passerelle activée InferenceEndpointConfig et JumpStartModel — Ajout d'un inferenceGateway champ facultatif aux deux CRD. Réglez true sur inferenceGateway.enabled pour choisir un modèle dans une passerelle partagée. L'opérateur ajoute ensuite une entrée de planificateur pour ce modèle à unInferenceGatewayConfig, créant ainsi la passerelle si elle n'existe pas déjà. Utilisez inferenceGateway.name pour sélectionner la passerelle. Les modèles qui spécifient le même nom dans le même espace de noms partagent une passerelle, et un nom qui n'est pas encore utilisé en crée une nouvelle. Lorsque le champ est vide, l'opérateur génère un nom unique afin que le modèle dispose de sa propre passerelle. L'opérateur reflète l'état de préparation de la passerellestatus.inferenceGateway. Pour de plus amples informations, veuillez consulter Intégration avec l'opérateur HyperPod d'inférence.

  • Annotations de pod personnalisées activées InferenceEndpointConfig — Ajout d'un podTemplateAnnotations champ facultatif sousspec.kubernetes. L'opérateur propage ces annotations aux pods sous-jacents, afin que les intégrations de pod-scraping telles que la découverte automatique des métriques puissent les lire.

Passez à la version 2.0.0-eksbuild.2 ou 3.6

Modifications du schéma de configuration :

Le schéma de configuration du module complémentaire a été modifié dans cette version. inferenceGatewayvient d'être ajouté et configure la passerelle d' HyperPodinférence. Le schéma ajoute égalementinferenceOperator, ce qui vous donne la possibilité d'activer ou de désactiver l'opérateur d'inférence indépendamment. Les deux composants sont activés par défaut, avec inferenceGateway.enabled et inferenceOperator.enabled définis surtrue. Pour désactiver l'un ou l'autre des composants, définissez son enabled champ sur false in--configuration-values.

Add-on Mise à niveau EKS :

Si vous avez installé l'opérateur d'inférence en tant qu'EKS Add-on, effectuez la mise à niveau à l'v2.0.0-eksbuild.2aide de la commande suivante :

CLUSTER=EKS_CLUSTER_NAME
REGION=REGION
ACCOUNT=AWS_ACCOUNT_ID

aws eks update-addon \
  --cluster-name $CLUSTER --region $REGION \
  --addon-name amazon-sagemaker-hyperpod-inference \
  --addon-version v2.0.0-eksbuild.2 \
  --resolve-conflicts OVERWRITE \
  --configuration-values '{
    "executionRoleArn": "arn:aws:iam::<ACCOUNT>:role/<EXEC_ROLE>",
    "tlsCertificateS3Bucket": "<TLS_BUCKET>",
    "inferenceOperator": { "enabled": true },
    "inferenceGateway": {
      "enabled": true,
      "serviceAccount": { "roleArn": "arn:aws:iam::<ACCOUNT>:role/<CERT_ISSUER_ROLE>" }
    },
    "keda": { "enabled": true, "auth": { "aws": { "irsa": { "enabled": true, "roleArn": "arn:aws:iam::<ACCOUNT>:role/<KEDA_IRSA_ROLE>" } } } },
    "alb": { "enabled": true, "serviceAccount": { "create": true, "roleArn": "arn:aws:iam::<ACCOUNT>:role/<ALB_IRSA_ROLE>" } },
    "jumpstartGatedModelDownloadRoleArn": "arn:aws:iam::<ACCOUNT>:role/<JUMPSTART_ROLE>"
  }'

Mise à niveau du casque :

L'Inference Gateway est disponible uniquement via le module complémentaire Amazon EKS. Si vous gérez l'opérateur d'inférence avec Helm et que vous souhaitez continuer à utiliser les fonctionnalités réservées aux opérateurs, mettez à niveau votre version de Helm à l'aide des commandes suivantes. Nous vous recommandons de migrer vers le module complémentaire pour bénéficier de toutes les fonctionnalités de l'opérateur d'inférence et de la passerelle d'inférence.

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.6

# Verification
kubectl get deployment hyperpod-inference-operator-controller-manager \
  -n hyperpod-inference-system \
  -o jsonpath='{.spec.template.spec.containers[0].image}'

Pour la migration de Helm vers le module complémentaire Amazon EKS, consultezDe la barre vers EKS Add-on Migration.

SageMaker HyperPod Notes de mise à jour sur l'inférence : HyperPod Inference Amazon EKS v1.6.0-eksbuild.1 et Inference Operator v3.5

Date de sortie : 3 septembre 2026

Récapitulatif

Amazon SageMaker HyperPod Inference Operator v3.5 vous permet de contrôler directement où les pondérations des modèles sont pré-mises en cache. Vous pouvez désormais associer vos propres règles d'affinité de nœud au cache des pondérations au lieu de vous fier uniquement au ciblage par type d'instance dérivé de votre déploiement par l'opérateur. Cette version ajoute également deux métriques Prometheus pour le volume de demandes entrantes et inclut quelques correctifs de sécurité.

Amazon SageMaker HyperPod Inference Operator v3.5 est disponible dans toutes les AWS régions où il SageMaker HyperPod est pris en charge.

Nouvelles fonctionnalités

  • Affinité des nœuds pour la mise en cache des pondérations de modèle  : déterminez quels nœuds sont situés avant la mise en cache des pondérations de modèle en utilisant le nouveau nodeAffinity champ situé sous votre oumodelCacheConfig.weightsCache. InferenceEndpointConfig JumpStartModel Le champ accepte la structure d'affinité standard des nœuds Kubernetes, vous obtenez requiredDuringSchedulingIgnoredDuringExecution donc des termes. preferredDuringSchedulingIgnoredDuringExecution Plusieurs vous nodeSelectorTerms donnent une sémantique OR, qui vous permet de cibler des pools de nœuds, des zones de disponibilité ou des ensembles d'étiquettes personnalisés dans un seul déploiement.

    L'opérateur applique vos règles en plus du ciblage par type d'instance dont il dérive spec.instanceType ouspec.instanceTypes, de sorte que les pondérations ne sont mises en cache que sur les nœuds qui satisfont les deux. Utilisez-le pour épingler le cache des pondérations à une seule zone de disponibilité ou à des groupes d' HyperPod instances spécifiques.

  • Suivi des demandes entrantes  : deux nouvelles mesures Prometheus vous offrent une visibilité sur le volume des demandes d'inférence entrantes, ce qui vous permet de mesurer la demande totale, de suivre la charge supprimée et de planifier la mise à l'échelle automatique et la capacité en conséquence.

    • model_requests_received_total— Compte chaque demande au point d'entrée du proxy, avant toute décision de contrôle d'admission. Cela inclut les demandes qui sont ensuite rejetées.

    • model_requests_shed_total— Compte les demandes rejetées par le contrôle d'admission par le biais de la régulation.

Passez à la version 3.5 ou à la version 1.6.0-eksbuild.1

Mise à niveau du casque :

Si l'opérateur d'inférence est déjà installé à l'aide de 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.5

# 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.6.0-eksbuild.1 \
  --resolve-conflicts OVERWRITE \
  --region $REGION

SageMaker HyperPod Notes de mise à jour sur l'inférence : HyperPod Inference Amazon EKS v1.5.0-eksbuild.1 et Inference Operator v3.4

Date de sortie : 21 août 2026

Récapitulatif

Amazon SageMaker HyperPod Inference Operator v3.4 permet de configurer les demandes de ressources et les limites des conteneurs sidecar gérés via le CRD. Vous pouvez désormais dimensionner les conteneurs du proxy inverse, du collecteur de métriques et du chargeur de capture de données en fonction de votre charge de travail au lieu de vous fier à des valeurs par défaut fixes.

Amazon SageMaker HyperPod Inference Operator v3.4 est disponible dans toutes les AWS régions où il SageMaker HyperPod est pris en charge.

Nouvelles fonctionnalités

  • Ressources de conteneurs configurables  : définissez les demandes de ressources et les limites pour les conteneurs sidecar gérés par l'opérateur. Utilisez les nouveaux s3UploaderResources champs metricsSidecarResourcesmetricsCollectorResources, et de votre InferenceEndpointConfig ouJumpStartModel. Ces champs vous permettent d'augmenter la mémoire du proxy inverse pour les déploiements à haute simultanéité, de régler le collecteur de métriques et de dimensionner le chargeur de capture de données. Lorsqu'un champ est défini, l'opérateur applique vos valeurs au lieu des valeurs par défaut intégrées et les conserve lors de la réconciliation. Chaque champ remplace entièrement le bloc de ressources de ce conteneur. Spécifiez donc les demandes complètes et les limites.

Passez à la version 3.4 ou à la version 1.5.0-eksbuild.1

Mise à niveau du casque :

Si l'opérateur d'inférence est déjà installé à l'aide de 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.4

# 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.5.0-eksbuild.1 \
  --resolve-conflicts OVERWRITE \
  --region $REGION

SageMaker HyperPod Notes de mise à jour sur l'inférence : HyperPod Inference Amazon EKS v1.4.0-eksbuild.1 et Inference Operator v3.3

Date de sortie : 4 août 2026

Récapitulatif

Amazon SageMaker HyperPod Inference Operator v3.3 introduit la mise en cache des modèles locaux de l'hôte. Cela réduit la latence de démarrage à froid lorsque vous étendez un déploiement d'inférence. Cette version permet également de configurer le délai d'inactivité de l'Application Load Balancer pour chaque déploiement.

Amazon SageMaker HyperPod Inference Operator v3.3 est disponible dans toutes les AWS régions où il SageMaker HyperPod est pris en charge.

Nouvelles fonctionnalités

  • Poids des modèles et mise en cache des images  : mettez en cache les poids des modèles sur le stockage NVMe local des nœuds et extrayez l'image du conteneur du serveur d'inférence sur les nœuds cibles. Les pods ajoutés lors de la mise à l'échelle ne téléchargent pas les pondérations depuis Amazon S3 ou Amazon FSx. Ils n'attendent pas qu'une image soit prise à froid. Activez l'un ou l'autre des mécanismes indépendamment ou les deux ensemble en l'utilisant modelCacheConfig dans votre CRD. Cette fonctionnalité nécessite un type d'instance avec un stockage NVMe local. Consultez Mise en cache des poids des modèles et mise en cache des images.

  • Délai d'inactivité ALB configurable  : contrôlez la durée pendant laquelle l'équilibreur de charge des applications maintient une connexion inactive ouverte en utilisant votre ouloadBalancer.idleTimeoutSeconds. InferenceEndpointConfig JumpStartModel Les valeurs valides sont comprises entre 1 et 4 000 secondes et la valeur par défaut est de 60 secondes. Augmentez cette valeur pour les déploiements dont les demandes mettent plus de temps que la valeur par défaut pour renvoyer une réponse.

Correctifs de bogue

  • Service de routage manquant  : correction d'un problème en raison duquel une réconciliation initiale interrompue pouvait laisser un déploiement sans le service de routage Kubernetes. Ce service prend en charge l'équilibreur d'entrée et de charge du déploiement. Les terminaux ont renvoyé des réponses HTTP 503 alors que tous les signaux de santé étaient sains. L'opérateur recrée désormais le service de routage lorsqu'il est absent.

  • Enregistrement des points de terminaison de routage intelligent — Correction d'un problème en raison duquel les déploiements de routage intelligent utilisaient un nom sans préfixe pour la recherche du chemin d'entrée. La recherche a échoué à chaque rapprochement, ce qui a empêché l'enregistrement des terminaux SageMaker AI de se terminer.

  • Configuration du cache KV — Correction d'un problème qui empêchait l'opérateur d'honorer enableL1Cache ou de enableL2Cache configurer false la connexionkvCacheSpec.

Passez à la v3.3 ou à la v1.4.0-eksbuild.1

Mise à niveau du casque :

Si l'opérateur d'inférence est déjà installé à l'aide de 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.3

# 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.4.0-eksbuild.1 \
  --resolve-conflicts OVERWRITE \
  --region $REGION

SageMaker HyperPod Notes de mise à jour sur l'inférence : HyperPod Inference Amazon EKS v1.3.0-eksbuild.1 et Inference Operator 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 pdSpec champ au InferenceEndpointConfig CRD qui permet une inférence désagrégée. Lorsque cette pdSpec option 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.argset decodingSpec.args — drapeaux Per-role vLLM fusionnés worker.args au démarrage.

    • prefillSpec.replicaset decodingSpec.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 nodeAffinity planifier uniquement sur les nœuds Linux amd64.

  • Nous incluons d'autres correctifs mineurs et de sécurité.

Passez à la v3.2 ou à la v1.3.0-eksbuild.1

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 sur l'inférence : HyperPod Inference Amazon EKS v1.2.0-eksbuild.1 et Inference Operator 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 dataCapture 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 passer par S3 ou FSx au préalable. Supporte les modèles sécurisés viatokenSecretRef, l'épinglage des révisions via commitSHA et 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 viadnsConfig. 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 InferenceEndpointConfig activées se propagent désormais correctement vers le SageMakerEndpointRegistration CRD 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 InferenceEndpointConfig ou d'un JumpStartModel CR 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.serverAddress validation qui exigeait à tort un segment de chemin final, ce qui provoquait 404 erreurs lors de l'ajout de 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 ou à la version v1.2.0-eksbuild.1

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.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.

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 : Inference Operator 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 kubernetes champ au InferenceEndpointConfig CRD 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. customCertificateConfig Prend 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 RequestLimits configuration 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 sur l'inférence : Inference Operator 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 qu'ils 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 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 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-approve s'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 sur l'inférence : Inference Operator 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 invocationEndpoint champ est corrigé ou mis à jour, les ressources dépendantes, telles que le Ingress Load Balancer et SageMaker EndpointSageMakerEndpointRegistration, seront mises à jour lors de la normalisation.

  • La valeur invocationEndpoint fournie sera stockée telle quelle dans la InferenceEndpointConfig spé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/completions pour AWS Load Balancer et SageMaker Endpoint. Ingress Pour leSageMakerEndpointRegistration, il sera affiché dans ses spécifications sous la formev1/chat/completions.

    • ///invokesera normalisé /invoke pour AWS Load Balancer et SageMaker Endpoint. Ingress Pour 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