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.

Passerelle d'inférence pour Amazon SageMaker HyperPod Inference

Amazon SageMaker HyperPod Inference Gateway est une Kubernetes-native couche de routage et d'orchestration compatible avec les grands modèles de langage (LLM) pour HyperPod les clusters sur Amazon EKS. Il inspecte les demandes d'inférence, lit le nom du modèle de chaque demande et sélectionne un pod servant le modèle en fonction de la charge du processeur graphique, afin que le trafic de plusieurs modèles soit acheminé efficacement via un point de terminaison de passerelle unique.

La passerelle achemine chaque demande via trois couches. Le Body-Based routeur (BBR), un composant partagé, lit le model champ du corps de la requête, résout le nom d'un adaptateur LoRa en son modèle de base et définit les en-têtes X-Gateway-Model-Name etX-Gateway-Base-Model-Name. La passerelle associe ensuite ces en-têtes à un HttpRoute et transmet la demande au modèle InferencePool demandé. Au sein de ce pool, Endpoint Picker (EPP/scheduler) choisit un pod servant de modèle en évaluant les candidats sur la base de paramètres du serveur de modèles tels que la profondeur de la file d'attente et l'utilisation du cache KV, ainsi que le cache de préfixe et l'affinité avec l'adaptateur LoRa. Chaque entrée que vous définissez sous spec.schedulers exécute son propre Endpoint Picker. Cette rubrique utilise donc les termes Endpoint Picker, EPP et planificateur de manière interchangeable.

La passerelle d'inférence s'appuie sur l'opérateur HyperPod d'inférence au lieu de le remplacer. Pendant que l'opérateur continue d'orchestrer le déploiement du modèle, la passerelle introduit une couche de LLM-aware routage devant les modules servant les modèles. La passerelle ne dépend pas d'un serveur modèle ou d'une couche d'orchestration spécifique et est fournie via le module complémentaire HyperPod Inference Amazon EKS.

Vous définissez une passerelle avec la ressource InferenceGatewayConfig personnalisée. Une seule InferenceGatewayConfig décrit une passerelle : le Body-Based routeur partagé, la terminaison TLS, l'authentification des demandes et un planificateur pour chaque modèle desservi par la passerelle. Pour le schéma complet, voirInferenceGatewayConfig Référence CRD.

Prérequis et déploiement

La passerelle d'inférence est fournie dans le cadre du module complémentaire HyperPod Inference Amazon EKS. L'installation du module complémentaire rend la passerelle disponible, aucune installation séparée n'est donc requise. Vous activez ensuite le routage de passerelle pour un modèle via le spec.inferenceGateway.enabled champ de la InferenceEndpointConfig ressource du modèle. Pour la version dans laquelle une fonctionnalité a été introduite, voirNotes de mise SageMaker HyperPod à jour d'Amazon Inference.

Avant d'acheminer le trafic via la passerelle, vérifiez les points suivants :

Configurer le rôle IAM de l'émetteur du certificat

Lorsque la passerelle émet automatiquement un certificat TLS, cert-manager génère le certificat dans le cluster et le contrôleur de passerelle l'importe dans ACM. L'importation étant un appel d' AWS API, le contrôleur a besoin AWS d'informations d'identification. Fournissez-les en créant un rôle IAM que le compte de inference-gateway-controller service dans l'hyperpod-inference-systemespace de noms assume via les rôles IAM pour les comptes de service (IRSA).

Définissez les variables d'environnement suivantes et récupérez l'émetteur OIDC de votre cluster.

export CLUSTER=EKS_CLUSTER_NAME
export REGION=REGION
export ACCOUNT=AWS_ACCOUNT_ID
export ROLE_NAME=CERT_ISSUER_ROLE_NAME

export OIDC_ID=$(aws eks describe-cluster --name $CLUSTER --region $REGION \
  --query 'cluster.identity.oidc.issuer' --output text | sed 's|https://||')

Créez une politique de confiance qui permet au compte de service du contrôleur de passerelle d'assumer ce rôle.

cat > trust-policy.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "Federated": "arn:aws:iam::${ACCOUNT}:oidc-provider/${OIDC_ID}"
    },
    "Action": "sts:AssumeRoleWithWebIdentity",
    "Condition": {
      "StringEquals": {
        "${OIDC_ID}:sub": "system:serviceaccount:hyperpod-inference-system:inference-gateway-controller",
        "${OIDC_ID}:aud": "sts.amazonaws.com"
      }
    }
  }]
}
EOF

Créez le rôle et associez la politique AmazonSageMakerHyperPodInferenceGatewayAccess gérée. La politique accorde les autorisations ACM dont le contrôleur a besoin pour importer, baliser, décrire et supprimer les certificats qu'il crée.

aws iam create-role --role-name $ROLE_NAME --assume-role-policy-document file://trust-policy.json
aws iam attach-role-policy --role-name $ROLE_NAME --policy-arn arn:aws:iam::aws:policy/AmazonSageMakerHyperPodInferenceGatewayAccess

Indiquez l'ARN de ce rôle comme inferenceGateway.serviceAccount.roleArn lorsque vous installez le module complémentaire.

Installez le module complémentaire

Le module complémentaire HyperPod Inference installe à la fois l'opérateur d'inférence et la passerelle d'inférence. Installez-le à l'aide de la commande suivante. PourinferenceGateway.serviceAccount.roleArn, utilisez le rôle d'émetteur de certificat que vous avez créé dans la section précédente. Remplacez les valeurs d'espace réservé restantes par les rôles et le compartiment de votre compte.

aws eks create-addon \
  --cluster-name $CLUSTER --region $REGION \
  --addon-name amazon-sagemaker-hyperpod-inference \
  --addon-version v2.0.0-eksbuild.2 \
  --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_NAME>" }
    },
    "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>"
  }'

Si le module complémentaire est déjà installé sur le cluster, remplacez-le create-addon par update-addon et ajoutez-le--resolve-conflicts OVERWRITE. Le reste de la commande est inchangé. OVERWRITEapplique les valeurs de configuration de la commande à la configuration du module complémentaire existant.

Vérifiez que le contrôleur de passerelle est en cours d'exécution et que les ressources de passerelle sont enregistrées.

kubectl rollout status deploy/inference-gateway-controller \
  -n hyperpod-inference-system --timeout=150s

kubectl get crd inferencegatewayconfigs.inference.sagemaker.aws.amazon.com

kubectl get gatewayclass inference-gateway

Vérifiez que le module complémentaire lui-même est actif et ne signale aucun problème de santé.

aws eks describe-addon \
  --cluster-name $CLUSTER --region $REGION \
  --addon-name amazon-sagemaker-hyperpod-inference \
  --query 'addon.{version:addonVersion,status:status,health:health.issues}'

Intégration avec l'opérateur HyperPod d'inférence

L'opérateur HyperPod d'inférence et la passerelle d'inférence ont des responsabilités distinctes. L'opérateur est propriétaire du déploiement, de l'orchestration et du câblage qui relie un modèle à la passerelle. La passerelle possède le routage des demandes et génère les ressources de routage pour chaque planificateur. Pour plus d'informations sur le déploiement de modèles avec l'opérateur, consultezDéploiement de modèles sur Amazon SageMaker HyperPod.

Vous attachez un modèle à la passerelle via l'opérateur, sur la ressource du modèle InferenceEndpointConfig (ouJumpStartModel), à l'aide du spec.inferenceGateway champ :

L'extrait suivant montre l'inferenceGatewayopt-in sur une ressource. InferenceEndpointConfig

apiVersion: inference.sagemaker.aws.amazon.com/v1
kind: InferenceEndpointConfig
metadata:
  name: my-model
spec:
  # ... model deployment fields ...
  inferenceGateway:
    enabled: true
    name: my-gateway        # Optional. When empty, the operator generates inf-igw-<uuid>.

L'opérateur reflète l'état de la pièce jointe sur la ressource modèle ci-dessousstatus.inferenceGateway, qui indique un State de Pending ReadyFailed, ou et le Name de la pièce jointeInferenceGatewayConfig. Vous ne pouvez pas inferenceGateway.enabled les définir ensemble intelligentRoutingSpec.enabled sur le même modèle ; ces champs s'excluent mutuellement.

Lorsque la passerelle est activée pour un modèle, l'opérateur crée ou met à jour une InferenceGatewayConfig ressource unique et fusionne une entrée pour le modèle dans sa spec.schedulers liste. L'opérateur définit le planificateurname,, et modelName targetPortmodelSelector, et la valeur par défaut est la llm-d date scheduler à laquelle il crée l'entrée pour la première fois. Lors de rapprochements ultérieurs, l'opérateur conserve les valeurs fournies par le client, telles scheduler que, et. weights loraAdapters Le Body-Based routeur est activé automatiquement lorsque plusieurs planificateurs sont présents.

L'opérateur ne supprime pas la InferenceGatewayConfig ressource ni les ressources de routage en aval. Lorsque vous désactivez la passerelle pour un modèle ou que vous supprimez le modèle, l'opérateur supprime uniquement l'entrée du planificateur de ce modèle. Le contrôleur de passerelle est responsable du nettoyage des ressources de routage.

Vous pouvez InferenceGatewayConfig en créer un de deux manières, et les deux chemins coexistent sur la même ressource :

Les composants de la passerelle et le InferenceGatewayConfig CRD doivent être installés via le module complémentaire HyperPod Inference Amazon EKS pour qu'une ressource de modèle avec la passerelle activée puisse être réconciliée. Pour l'installation du module complémentaire pour opérateurs, consultezInstallation de l'opérateur d'inférence avec le module complémentaire EKS. Pour déployer les pods servant des modèles vers lesquels un planificateur est acheminé, consultez. Déploiement de modèles de fondation et de modèles personnalisés et peaufinés

InferenceGatewayConfig Référence CRD

Vous configurez la passerelle d'inférence avec une seule ressource InferenceGatewayConfig personnalisée. La ressource est un singleton pour une passerelle donnée : elle contient la configuration du Body-Based routeur partagé et une liste de planificateurs par modèle. Le contrôleur génère le sous-jacentInferencePool, Endpoint Picker, HttpRoute et les EnvoyExtensionPolicy ressources pour chaque planificateur ; vous créez uniquement la ressource. InferenceGatewayConfig

champs de spécifications

Le spec champ de la InferenceGatewayConfig ressource contient la configuration du Body-Based routeur partagé, les paramètres TLS, la liste requise de planificateurs, ainsi que les paramètres facultatifs d'observabilité et les paramètres par défaut du pod.

SchedulerSpec champs

Chaque entrée spec.schedulers configure le routage et la sélection des points de terminaison pour un modèle. Un planificateur nomme les ressources généréesInferencePool, Endpoint Picker, HttpRoute et. EnvoyExtensionPolicy

Règles de validation

La InferenceGatewayConfig ressource applique les règles de validation suivantes. Une ressource qui enfreint l'une de ces règles est rejetée.

champs de statut

Le contrôleur rapporte l'état observé de la passerelle dans la status sous-ressource.

Autorisations RBAC de Kubernetes

L'Inference Gateway s'exécute en tant que contrôleur unique sous le compte inference-gateway-controller de service Kubernetes dans l'espace de noms. hyperpod-inference-system Le Body-Based routeur, les Endpoint Pickers par planificateur, le contrôleur Gateway et le InferenceGatewayConfig réconciliateur s'exécutent tous sous ce contrôleur unique. Ses autorisations à l'échelle du cluster sont accordées par un ClusterRole nom sagemaker-inference-gateway-controller-supplement et un correspondant. ClusterRoleBinding Ensemble, ils complètent le compte de service et les autorisations déjà fournis par le graphique Gateway groupé. Ces autorisations sont limitées et dotées du moindre privilège, et le contrôleur ne s'exécute pas en tant qu'administrateur de cluster.

Le tableau suivant répertorie les autorisations du contrôleur par cluster, regroupées par objectif. Dans ce tableau, l'accès complet signifie les delete verbes create get listwatch,update,patch,, et.

Le contrôleur crée également les rôles d'espace de noms suivants lors de l'exécution, en fonction de la configuration de votre passerelle :

Certaines de ces autorisations ne s'appliquent que lorsque la fonctionnalité correspondante est activée.

Observabilité

La passerelle d'inférence émet des métriques Prometheus depuis chaque composant de la passerelle. Le Body-Based routeur et chaque Endpoint Picker exposent un point de /metrics terminaison Prometheus standard sur leurs pods. Body-Based Les pods du routeur s'exécutent dans l'hyperpod-inference-systemespace de noms ; les pods Endpoint Picker s'exécutent dans le même espace de noms que le. InferenceGatewayConfig Les métriques couvrent les compteurs et les durées de requêtes par modèle, la planification de la latence et le temps d'exécution par plug-in dans Endpoint Picker, ainsi que les mesures de pool agrégées telles que l'utilisation moyenne du cache KV et la profondeur de la file d'attente. Model-server les métriques de pod (provenant par exemple de vLLM ou SGlang) sont émises par le serveur de modèles lui-même ; le Endpoint Picker les extrait pour évaluer les pods candidats.

Lorsque cette valeur spec.observability.metrics.enabled est true définie (par défaut), le contrôleur de passerelle injecte un side-car OpenTelemetry Collector dans chaque module Body-Based Router et Endpoint Picker. Le side-car transmet ces métriques à la pile d'observabilité par HyperPod inférence, où les tableaux de bord Grafana intégrés les présentent aux côtés des métriques modèle-serveur et cluster. Pour plus de détails sur la configuration et le tableau de bord, consultezMise en œuvre de l'observabilité par inférence sur les clusters HyperPod. Réglez le champ sur false pour ignorer l'injection de side-car. Pour la référence du champ, voir observability ci-dessouschamps de spécifications.

Pour afficher les mesures de passerelle dans Amazon Managed Grafana, ouvrez le dossier Inference Dashboards et sélectionnez le tableau de bord Inference Gateway. Le tableau de bord indique la disponibilité à l'échelle de la passerelle, le taux de demandes et la latence de bout en bout, le débit par planificateur, la latence et les erreurs pour chaque modèle, ainsi que la vitesse à laquelle le Body-Based routeur résout les noms de modèles à partir des corps de requête.

Exemples

Les exemples suivants montrent les InferenceGatewayConfig configurations courantes et la manière d'invoquer la passerelle.

Configuration multimodèle minimale

Cet exemple achemine vers un planificateur llm-d avec un protocole TLS émis automatiquement. Comme elle tls est définie sur un objet vide, la passerelle émet automatiquement un certificat et l'importe dans ACM.

apiVersion: inference.sagemaker.aws.amazon.com/v1alpha1
kind: InferenceGatewayConfig
metadata:
  name: inference-gateway-demo
  namespace: inference-gateway
spec:
  bbr:
    enabled: true
  tls: {}                       # Auto-issue a certificate via cert-manager and import to ACM.
  schedulers:
    - name: llama
      modelName: "meta-llama/Llama-3.2-1B-Instruct"
      modelSelector:
        matchLabels:
          app: vllm-llama
      targetPort: 8000
      scheduler: llm-d

Planificateur SGlang avec pondérations explicites

Cet exemple utilise le type de epp planificateur avec le sglang moteur et définit des pondérations de notation explicites pour Endpoint Picker.

spec:
  bbr:
    enabled: true
  schedulers:
    - name: qwen7b
      modelName: "Qwen/Qwen2.5-7B-Instruct"
      modelSelector:
        matchLabels:
          app: sglang-qwen7b
      targetPort: 8000
      scheduler: epp
      engineType: sglang
      logLevel: 4
      weights:
        kvCache: 2
        prefix: 3
        runningRequests: 2

adaptateur LoRa ConfigMap

Le Body-Based routeur découvre les adaptateurs LoRa et leur modèle de base à partir d'un système ConfigMap étiqueté pour la gestion BBR. Le routeur utilise ce mappage pour résoudre le nom d'un adaptateur dans le corps de la requête en son modèle de base.

apiVersion: v1
kind: ConfigMap
metadata:
  name: deepseek-adapters
  labels:
    inference.networking.k8s.io/bbr-managed: "true"
data:
  baseModel: deepseek/vllm-deepseek-r1
  adapters: |
    - ski-resorts
    - movie-critique

Invoquer la passerelle

La passerelle sert de point de terminaison d' OpenAI-compatible inférence. Il s'agit du contrat d'invocation d'exécution pour l'envoi de demandes d'inférence via la passerelle ; il ne s'agit pas d'une opération d' AWS API. Envoyez des demandes au point de terminaison de la passerelle avec le model champ défini sur modelName celui du planificateur cible. Le Body-Based routeur lit ce champ pour acheminer la demande.

curl https://your-gateway-endpoint/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "meta-llama/Llama-3.1-8B-Instruct",
    "messages": [
      {"role": "user", "content": "Hello"}
    ]
  }'