Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Inference Gateway per Amazon Inference SageMaker HyperPod

Amazon SageMaker HyperPod Inference Gateway è un livello di routing e orchestrazione compatibile con un Kubernetes-native modello di linguaggio ampio (LLM) per i cluster su Amazon EKS. HyperPod Ispeziona le richieste di inferenza, legge il nome del modello da ogni richiesta e seleziona un pod che serve i modelli in base al carico della GPU, in modo che il traffico per più modelli venga indirizzato in modo efficiente attraverso un singolo endpoint gateway.

Il gateway indirizza ogni richiesta attraverso tre livelli. Il Body-Based Router (BBR), un componente condiviso, legge il model campo dal corpo della richiesta, risolve il nome di un adattatore LoRa nel relativo modello base e imposta le intestazioni and. X-Gateway-Model-Name X-Gateway-Base-Model-Name Il gateway abbina quindi tali intestazioni a un HttpRoute e inoltra la richiesta al modello richiesto. InferencePool All'interno di quel pool, Endpoint Picker (EPP/scheduler) sceglie un pod per il model-serving assegnando un punteggio ai candidati in base a metriche del model-server come la profondità della coda e l'utilizzo della cache KV, insieme all'affinità tra prefisso e adattatore LoRa. Ogni voce definita in spec.schedulers esegue il proprio Endpoint Picker, quindi questo argomento utilizza i termini Endpoint Picker, EPP e scheduler in modo intercambiabile.

L'Inference Gateway si basa sull'Inference Operator invece di sostituirlo. HyperPod Mentre l'operatore continua a orchestrare l'implementazione del modello, il gateway introduce un livello di LLM-aware routing davanti ai pod che servono i modelli. Il gateway non dipende da un server modello o da un livello di orchestrazione specifico e viene fornito tramite il componente aggiuntivo Inference Amazon EKS. HyperPod

Definisci un gateway con la risorsa personalizzata. InferenceGatewayConfig Un singolo InferenceGatewayConfig descrive un gateway: il Body-Based router condiviso, la terminazione TLS, l'autenticazione delle richieste e uno scheduler per ogni modello utilizzato dal gateway. Per lo schema completo, vedere. InferenceGatewayConfig Riferimento CRD

Prerequisiti e distribuzione

L'Inference Gateway viene fornito come parte del componente aggiuntivo HyperPod Inference Amazon EKS. L'installazione del componente aggiuntivo rende il gateway disponibile, quindi non è richiesta alcuna installazione separata. Quindi si attiva il routing del gateway per un modello tramite il spec.inferenceGateway.enabled campo sulla risorsa del InferenceEndpointConfig modello. Per la versione in cui è stata introdotta una funzionalità, vedereNote sulla versione di Amazon SageMaker HyperPod Inference.

Prima di indirizzare il traffico attraverso il gateway, verifica quanto segue:

Imposta il ruolo IAM dell'emittente del certificato

Quando il gateway emette automaticamente un certificato TLS, cert-manager genera il certificato nel cluster e il controller del gateway lo importa in ACM. Poiché l'importazione è una chiamata AWS API, il controller necessita di credenziali. AWS Forniscile creando un ruolo IAM che l'account di inference-gateway-controller servizio nel hyperpod-inference-system namespace assume tramite i ruoli IAM per gli account di servizio (IRSA).

Imposta le seguenti variabili di ambiente e recupera l'emittente OIDC per il tuo 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://||')

Crea una policy di fiducia che consenta all'account di servizio del controller del gateway di assumere il ruolo.

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

Crea il ruolo e AmazonSageMakerHyperPodInferenceGatewayAccess allega la policy gestita. La policy concede all'ACM le autorizzazioni necessarie al controller per importare, etichettare, descrivere ed eliminare i certificati che crea.

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

Fornisci questo ruolo ARN come inferenceGateway.serviceAccount.roleArn quando installi il componente aggiuntivo.

Installa il componente aggiuntivo

L'add-on HyperPod Inference installa sia l'Inference Operator che l'Inference Gateway. Installalo con il seguente comando. PerinferenceGateway.serviceAccount.roleArn, usa il ruolo di emittente del certificato che hai creato nella sezione precedente. Sostituisci i valori segnaposto rimanenti con i ruoli e il bucket per il tuo account.

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>"
  }'

Se il componente aggiuntivo è già installato nel cluster, sostituisci create-addon con e aggiungi. update-addon --resolve-conflicts OVERWRITE Il resto del comando è invariato. OVERWRITEapplica i valori di configurazione del comando sulla configurazione aggiuntiva esistente.

Verificare che il controller del gateway sia in esecuzione e che le risorse del gateway siano registrate.

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

Verifica che il componente aggiuntivo stesso sia attivo e non segnali problemi di salute.

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

Integrazione con l'operatore di HyperPod inferenza

L' HyperPod Inference Operator e l'Inference Gateway hanno responsabilità distinte. L'operatore è responsabile della distribuzione del modello, dell'orchestrazione e del cablaggio che collega un modello al gateway. Il gateway possiede il routing delle richieste e genera le risorse di routing per ogni scheduler. Per ulteriori informazioni sulla distribuzione dei modelli con l'operatore, vedere. Distribuzione di modelli su Amazon SageMaker HyperPod

Si collega un modello al gateway tramite l'operatore, sulla risorsa del modello InferenceEndpointConfig (oJumpStartModel), utilizzando il spec.inferenceGateway campo:

Lo snippet seguente mostra l'inferenceGatewayopt-in su una risorsa. 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'operatore rispecchia lo stato dell'allegato sulla risorsa del modello in status.inferenceGateway basso, che riporta un State elemento di Pending ReadyFailed, o e quello Name dell'allegato. InferenceGatewayConfig Non è possibile impostare inferenceGateway.enabled insieme intelligentRoutingSpec.enabled sullo stesso modello; questi campi si escludono a vicenda.

Quando il gateway è abilitato per un modello, l'operatore crea o aggiorna una singola InferenceGatewayConfig risorsa e unisce una voce relativa al modello nel relativo elenco. spec.schedulers L'operatore imposta lo schedulername, modelName targetPortmodelSelector, e per impostazione predefinita è llm-d quando crea la voce scheduler per la prima volta. Nelle riconciliazioni successive, l'operatore conserva i valori forniti dal cliente come, e. scheduler weights loraAdapters Il Body-Based router viene abilitato automaticamente quando è presente più di uno scheduler.

L'operatore non elimina la InferenceGatewayConfig risorsa o le risorse di routing a valle. Quando si disabilita il gateway per un modello o si elimina il modello, l'operatore rimuove solo la voce dello scheduler di quel modello. Il controller del gateway è responsabile della pulizia delle risorse di routing.

È possibile creare un file InferenceGatewayConfig in due modi e i due percorsi coesistono sulla stessa risorsa:

I componenti del gateway e il InferenceGatewayConfig CRD devono essere installati tramite il componente aggiuntivo HyperPod Inference Amazon EKS prima di poter riconciliare una risorsa modello con il gateway abilitato. Per l'installazione del componente aggiuntivo per l'operatore, consulta. Installazione dell'Inference Operator with EKS add-on Per la distribuzione dei pod che servono i modelli a cui viene indirizzato uno scheduler, vedere. Implementazione di modelli di fondazione e di modelli ottimizzati con fine-tuning personalizzati

InferenceGatewayConfig Riferimento CRD

Si configura Inference Gateway con una singola risorsa InferenceGatewayConfig personalizzata. La risorsa è un singleton per un determinato gateway: contiene la configurazione condivisa del Body-Based router e un elenco di scheduler per modello. Il controller genera il sottostanteInferencePool, Endpoint Picker, HttpRoute e le EnvoyExtensionPolicy risorse per ogni scheduler; tu crei solo la risorsa. InferenceGatewayConfig

campi delle specifiche

Il spec campo della InferenceGatewayConfig risorsa contiene la configurazione condivisa del Body-Based router, le impostazioni TLS, l'elenco richiesto degli scheduler e le impostazioni opzionali di osservabilità e predefinite del pod.

SchedulerSpec campi

Ogni voce in spec.schedulers configura il routing e la selezione degli endpoint per un modello. Uno scheduler nomina il generatoInferencePool, Endpoint Picker, HttpRoute e le risorse. EnvoyExtensionPolicy

Regole di convalida

La InferenceGatewayConfig risorsa applica le seguenti regole di convalida. Una risorsa che viola una di queste regole viene rifiutata.

campi di stato

Il controller riporta lo stato osservato del gateway nella status sottorisorsa.

Autorizzazioni Kubernetes RBAC

L'Inference Gateway viene eseguito come un singolo controller con l'account del servizio Kubernetes nel namespace. inference-gateway-controller hyperpod-inference-system Il Body-Based router, gli Endpoint Pickers per scheduler, il controller Gateway e il riconciliatore funzionano tutti sotto questo unico controller. InferenceGatewayConfig Le autorizzazioni relative all'ambito del cluster sono concesse da un nome e da una corrispondenza. ClusterRole sagemaker-inference-gateway-controller-supplement ClusterRoleBinding Insieme, integrano l'account di servizio e le autorizzazioni già forniti dal grafico Gateway in bundle. Queste autorizzazioni sono limitate all'ambito e al privilegio minimo e il controller non viene eseguito come amministratore del cluster.

La tabella seguente elenca le autorizzazioni relative all'ambito del cluster del controller, raggruppate per scopo. In questa tabella, per accesso completo si intendono i verbicreate,,get, listwatch, update e. patch delete

Il controller crea inoltre i seguenti ruoli con namespace in fase di esecuzione, a seconda della configurazione del gateway:

Alcune di queste autorizzazioni si applicano solo quando la funzionalità corrispondente è abilitata.

Osservabilità

L'Inference Gateway emette le metriche Prometheus da ogni componente del gateway. Sia il Body-Based router che ciascun Endpoint Picker espongono un endpoint Prometheus standard sui propri pod. /metrics Body-Based I router pod vengono eseguiti nello spazio dei nomi; i pod Endpoint Picker vengono eseguiti hyperpod-inference-system nello stesso namespace del. InferenceGatewayConfig Le metriche riguardano i contatori e le durate delle richieste per modello, la latenza di pianificazione e il tempo di esecuzione per plug-in all'interno di Endpoint Picker e le metriche aggregate del pool, come l'utilizzo medio della cache in KV e la profondità della coda. Model-server le metriche dei pod (ad esempio, da VLLM o SGlang) vengono emesse dal server del modello stesso; l'Endpoint Picker le analizza per assegnare un punteggio ai pod candidati.

Quando spec.observability.metrics.enabled è true (impostazione predefinita), il controller del gateway inietta un sidecar Collector in ogni pod Router ed Endpoint Picker. OpenTelemetry Body-Based Il sidecar inoltra queste metriche allo stack di osservabilità dell' HyperPod inferenza, dove le dashboard integrate di Grafana le presentano insieme alle metriche del model-server e del cluster. Per i dettagli sulla Implementazione dell'osservabilità dell'inferenza sui cluster HyperPod configurazione e sulla dashboard, consulta. Imposta il campo su false per saltare l'iniezione del sidecar. Per il riferimento al campo, vedi observability sotto. campi delle specifiche

Per visualizzare le metriche del gateway in Amazon Managed Grafana, apri la cartella Inference Dashboards e seleziona la dashboard di Inference Gateway. La dashboard riporta la disponibilità a livello di gateway, la frequenza di richiesta e la latenza end-to-end, il throughput per scheduler, la latenza e gli errori per ciascun modello e la velocità con cui il Router risolve i nomi dei modelli dai corpi delle richieste. Body-Based

Esempi

Gli esempi seguenti mostrano le configurazioni comuni e come richiamare il gateway. InferenceGatewayConfig

Configurazione multimodello minima

Questo esempio indirizza a uno scheduler llm-d con TLS emesso automaticamente. Poiché tls è impostato su un oggetto vuoto, il gateway emette automaticamente un certificato e lo importa in 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

Scheduler SGlang con pesi espliciti

Questo esempio utilizza il tipo di epp scheduler con il sglang motore e imposta pesi di punteggio espliciti di 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

adattatore LoRa ConfigMap

Il Body-Based router scopre gli adattatori LoRa e il loro modello base grazie a un' ConfigMapetichetta per la gestione BBR. Il router utilizza questa mappatura per convertire il nome di un adattatore nel corpo della richiesta nel relativo modello 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

Richiama il gateway

Il gateway serve come endpoint di OpenAI-compatible inferenza. Questo è il contratto di invocazione in fase di esecuzione per l'invio di richieste di inferenza tramite il gateway; non è un'operazione API. AWS Invia richieste all'endpoint del gateway con il model campo impostato sullo scheduler modelName di destinazione. Il Body-Based router legge questo campo per indirizzare la richiesta.

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"}
    ]
  }'