Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Inference Gateway für Amazon Inference SageMaker HyperPod

Das Amazon SageMaker HyperPod Inference Gateway ist eine Kubernetes-native auf Large Language Model (LLM) basierende Routing- und Orchestrierungsschicht für Cluster auf Amazon EKS. HyperPod Es prüft Inferenzanforderungen, liest den Modellnamen aus jeder Anfrage und wählt auf der Grundlage der GPU-Last einen Pod für die Modellbereitstellung aus, sodass der Datenverkehr mehrerer Modelle effizient über einen einzigen Gateway-Endpunkt geleitet wird.

Das Gateway leitet jede Anfrage durch drei Ebenen weiter. Der Body-Based Router (BBR), eine gemeinsam genutzte Komponente, liest das model Feld aus dem Anforderungstext, löst den Namen eines LoRa-Adapters in sein Basismodell auf und legt die X-Gateway-Model-Name UND-Header fest. X-Gateway-Base-Model-Name Das Gateway ordnet diese Header dann einer HttpRoute zu und leitet die Anfrage an das für das angeforderte Modell weiter. InferencePool Innerhalb dieses Pools wählt der Endpoint Picker (EPP/scheduler) einen Pod aus, der das Modell bereitstellt, indem er Kandidaten anhand von Modell-Server-Metriken wie Warteschlangentiefe und KV-Cache-Auslastung sowie Präfix-Cache- und LoRa-Adapter-Affinität bewertet. Jeder Eintrag, den Sie unter definieren, spec.schedulers führt seinen eigenen Endpoint Picker aus, daher werden in diesem Thema die Begriffe Endpoint Picker, EPP und Scheduler synonym verwendet.

Das Inference Gateway baut auf dem Inference Operator auf, anstatt ihn zu ersetzen HyperPod . Während der Operator die Modellbereitstellung weiter orchestriert, führt das Gateway eine LLM-aware Routing-Ebene vor den Pods ein, die das Modell bereitstellen. Das Gateway ist nicht von einem bestimmten Modellserver oder einer bestimmten Orchestrierungsebene abhängig und wird über das HyperPod Inference Amazon EKS-Add-on bereitgestellt.

Sie definieren ein Gateway mit der InferenceGatewayConfig benutzerdefinierten Ressource. Eine Single InferenceGatewayConfig beschreibt ein Gateway: den gemeinsam genutzten Body-Based Router, die TLS-Terminierung, die Anforderungsauthentifizierung und einen Scheduler für jedes Modell, das das Gateway bedient. Das vollständige Schema finden Sie unterInferenceGatewayConfig CRD-Referenz.

Voraussetzungen und Bereitstellung

Das Inference Gateway wird als Teil des HyperPod Inference Amazon EKS-Add-ons geliefert. Durch die Installation des Add-ons ist das Gateway verfügbar, sodass keine separate Installation erforderlich ist. Anschließend aktivieren Sie das Gateway-Routing für ein Modell über das spec.inferenceGateway.enabled Feld in der InferenceEndpointConfig Ressource des Modells. Die Version, in der eine Funktion eingeführt wurde, finden Sie unterVersionshinweise SageMaker HyperPod zu Amazon Inference.

Bevor Sie den Verkehr durch das Gateway leiten, überprüfen Sie Folgendes:

Richten Sie die IAM-Rolle des Zertifikatsausstellers ein

Wenn das Gateway automatisch ein TLS-Zertifikat ausstellt, generiert cert-manager das Zertifikat im Cluster und der Gateway-Controller importiert es in ACM. Da der Import ein AWS API-Aufruf ist, benötigt der Controller Anmeldeinformationen. AWS Stellen Sie sie bereit, indem Sie eine IAM-Rolle erstellen, die das inference-gateway-controller Dienstkonto im hyperpod-inference-system Namespace über IAM-Rollen für Dienstkonten (IRSA) übernimmt.

Legen Sie die folgenden Umgebungsvariablen fest und rufen Sie den OIDC-Aussteller für Ihren Cluster ab.

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://||')

Erstellen Sie eine Vertrauensrichtlinie, die es dem Gateway Controller-Dienstkonto ermöglicht, die Rolle zu übernehmen.

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

Erstellen Sie die Rolle und fügen Sie die AmazonSageMakerHyperPodInferenceGatewayAccess verwaltete Richtlinie hinzu. Die Richtlinie gewährt die ACM-Berechtigungen, die der Controller benötigt, um die von ihm erstellten Zertifikate zu importieren, zu kennzeichnen, zu beschreiben und zu löschen.

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

Geben Sie diesen Rollen-ARN wie inferenceGateway.serviceAccount.roleArn bei der Installation des Add-ons an.

Installieren Sie das Add-on

Das HyperPod Inferenz-Add-on installiert sowohl den Inference Operator als auch das Inference Gateway. Installieren Sie es mit dem folgenden Befehl. Verwenden Sie inferenceGateway.serviceAccount.roleArn z. B. die Rolle des Zertifikatsausstellers, die Sie im vorherigen Abschnitt erstellt haben. Ersetzen Sie die verbleibenden Platzhalterwerte durch die Rollen und den Bucket für Ihr Konto.

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

Wenn das Add-on bereits auf dem Cluster installiert ist, create-addon ersetzen Sie es durch update-addon und fügen Sie --resolve-conflicts OVERWRITE es hinzu. Der Rest des Befehls ist unverändert. OVERWRITEwendet die Konfigurationswerte im Befehl auf die bestehende Zusatzkonfiguration an.

Vergewissern Sie sich, dass der Gateway-Controller läuft und dass die Gateway-Ressourcen registriert sind.

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

Vergewissern Sie sich, dass das Add-on selbst aktiv ist und keine Systemprobleme meldet.

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

Integration mit dem HyperPod Inferenzoperator

Der HyperPod Inferenzoperator und das Inferenz-Gateway haben unterschiedliche Verantwortlichkeiten. Der Betreiber ist für die Modellbereitstellung, die Orchestrierung und die Verkabelung verantwortlich, die ein Modell mit dem Gateway verbindet. Das Gateway ist für das Anforderungsrouting zuständig und generiert die Routing-Ressourcen für jeden Scheduler. Weitere Hinweise zur Bereitstellung von Modellen mit dem Operator finden Sie unterModelle auf Amazon bereitstellen SageMaker HyperPod.

Sie fügen dem Gateway über den Operator ein Modell auf der Ressource InferenceEndpointConfig (oderJumpStartModel) des Modells hinzu und verwenden dazu das spec.inferenceGateway Feld:

Der folgende Ausschnitt zeigt das inferenceGateway Opt-In für eine 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>.

Der Operator spiegelt den Status des Anhangs auf der Modellressource widerstatus.inferenceGateway, unter der die Werte „Von“ PendingReady, „oder“ und „Statedes Failed angehängten Objekts“ gemeldet Name werden. InferenceGatewayConfig Sie können nicht inferenceGateway.enabled zusammen mit intelligentRoutingSpec.enabled auf demselben Modell setzen; diese Felder schließen sich gegenseitig aus.

Wenn das Gateway für ein Modell aktiviert ist, erstellt oder aktualisiert der Operator eine einzelne InferenceGatewayConfig Ressource und fügt einen Eintrag für das Modell mit seiner spec.schedulers Liste zusammen. Der Operator legt den Schedulername, modelNametargetPort, und und als Standardeinstellung festmodelSelector, llm-d wenn der scheduler Eintrag zum ersten Mal erstellt wird. Bei späteren Abstimmungen behält der Operator vom Kunden eingegebene Werte wie, und bei. scheduler weights loraAdapters Der Body-Based Router wird automatisch aktiviert, wenn mehr als ein Scheduler vorhanden ist.

Der Operator löscht weder die InferenceGatewayConfig Ressource noch die Downstream-Routing-Ressourcen. Wenn Sie das Gateway für ein Modell deaktivieren oder das Modell löschen, entfernt der Operator nur den Scheduler-Eintrag dieses Modells. Der Gateway-Controller ist für die Bereinigung der Routing-Ressourcen zuständig.

Sie können eine InferenceGatewayConfig auf zwei Arten erstellen, und die beiden Pfade existieren gleichzeitig auf derselben Ressource:

Die Gateway-Komponenten und das InferenceGatewayConfig CRD müssen über das HyperPod Inference Amazon EKS-Add-on installiert werden, bevor eine Modellressource mit aktiviertem Gateway abgeglichen werden kann. Informationen zur Installation des Operator-Add-ons finden Sie unter. Installation des Inferenzoperators mit dem EKS-Add-on Informationen zur Bereitstellung der Model-Serving-Pods, zu denen ein Scheduler eine Route weiterleitet, finden Sie unter. Bereitstellen von Grundlagenmodellen und maßgeschneiderten, optimierten Modellen

InferenceGatewayConfig CRD-Referenz

Sie konfigurieren das Inference Gateway mit einer einzigen InferenceGatewayConfig benutzerdefinierten Ressource. Die Ressource ist ein Singleton für ein bestimmtes Gateway: Sie enthält die gemeinsam genutzte Body-Based Router-Konfiguration und eine Liste von Schedulern pro Modell. Der Controller generiert die zugrundeliegenden InferencePool Endpoint Picker-, HttpRoute- und EnvoyExtensionPolicy Ressourcen für jeden Scheduler. Sie erstellen nur die Ressource. InferenceGatewayConfig

Spezifikationsfelder

Das spec Feld der InferenceGatewayConfig Ressource enthält die gemeinsame Body-Based Router-Konfiguration, TLS-Einstellungen, die erforderliche Liste von Schedulern sowie optionale Observability- und Pod-Default-Einstellungen.

SchedulerSpec Felder

Jeder Eintrag in spec.schedulers konfiguriert das Routing und die Endpunktauswahl für ein Modell. Ein Scheduler benennt die generierten RessourcenInferencePool, Endpoint Picker, HttpRoute und Ressourcen. EnvoyExtensionPolicy

Regeln für die Validierung

Die InferenceGatewayConfig Ressource erzwingt die folgenden Validierungsregeln. Eine Ressource, die gegen eine dieser Regeln verstößt, wird abgelehnt.

Status-Felder

Der Controller meldet den beobachteten Zustand des Gateways in der status Unterressource.

Kubernetes RBAC-Berechtigungen

Das Inference Gateway wird als einzelner Controller unter dem Kubernetes-Dienstkonto im Namespace ausgeführt. inference-gateway-controller hyperpod-inference-system Der Body-Based Router, die Endpoint Pickers pro Scheduler, der Gateway-Controller und der InferenceGatewayConfig Reconiler werden alle unter diesem einen Controller ausgeführt. Seine clusterbezogenen Berechtigungen werden von einem benannten und einem passenden Benutzer erteilt. ClusterRole sagemaker-inference-gateway-controller-supplement ClusterRoleBinding Zusammen ergänzen sie das Dienstkonto und die Berechtigungen, die das gebündelte Gateway-Diagramm bereits bietet. Bei diesen Berechtigungen handelt es sich um bereichsbezogene und geringste Rechte, und der Controller wird nicht als Clusteradministrator ausgeführt.

In der folgenden Tabelle sind die Clusterberechtigungen des Controllers, gruppiert nach Zweck, aufgeführt. In dieser Tabelle bedeutet Vollzugriff die Verbencreate,get,, list watchupdate, patch und. delete

Je nach Gateway-Konfiguration erstellt der Controller zur Laufzeit auch die folgenden Rollen mit Namespaces:

Einige dieser Berechtigungen gelten nur, wenn die entsprechende Funktion aktiviert ist.

Beobachtbarkeit

Das Inference Gateway gibt Prometheus-Metriken von jeder Gateway-Komponente aus. Sowohl der Body-Based Router als auch jeder Endpoint Picker stellen einen /metrics Standard-Prometheus-Endpunkt auf ihren Pods zur Verfügung. Body-Based Router-Pods werden im hyperpod-inference-system Namespace ausgeführt; Endpoint Picker-Pods werden im selben Namespace wie der ausgeführt. InferenceGatewayConfig Die Metriken umfassen Anforderungszähler und -dauern pro Modell, die Planung der Latenz und die Ausführungszeit pro Plugin innerhalb des Endpoint Pickers sowie aggregierte Pool-Metriken wie die durchschnittliche KV-Cache-Auslastung und die Warteschlangentiefe. Model-server Pod-Metriken (z. B. von vLLM oder sGLang) werden vom Modellserver selbst ausgegeben; der Endpoint Picker scrapt sie, um Kandidaten-Pods zu bewerten.

Wenn dies der spec.observability.metrics.enabled Fall ist true (Standardeinstellung), injiziert der Gateway-Controller einen OpenTelemetry Collector-Sidecar in jeden Router- und Endpoint Picker-Pod. Body-Based Der Sidecar leitet diese Metriken an den HyperPod Inferenz-Observability-Stack weiter, wo sie in den integrierten Grafana-Dashboards zusammen mit Modellserver- und Cluster-Metriken angezeigt werden. Einzelheiten zur Einrichtung Implementierung der Beobachtbarkeit von Inferenzen auf Clustern HyperPod und zum Dashboard finden Sie unter. Stellen Sie das Feld auf ein, false um die Beiwageninjektion zu überspringen. Die Feldreferenz finden Sie unterobservability. Spezifikationsfelder

Um die Gateway-Metriken in Amazon Managed Grafana anzuzeigen, öffnen Sie den Ordner Inference Dashboards und wählen Sie das Inference Gateway-Dashboard aus. Das Dashboard meldet die Gateway-weite Verfügbarkeit, die Anforderungsrate und die Ende-zu-Ende-Latenz, den Durchsatz pro Scheduler, die Latenz und die Fehler für jedes Modell sowie die Geschwindigkeit, mit der der Router Modellnamen aus den Anforderungstexten auflöst. Body-Based

Beispiele

Die folgenden Beispiele zeigen gängige InferenceGatewayConfig Konfigurationen und zeigen, wie das Gateway aufgerufen wird.

Minimale Konfiguration mit mehreren Modellen

Dieses Beispiel leitet an einen LLM-D-Scheduler mit automatisch ausgestelltem TLS weiter. Da tls es auf ein leeres Objekt gesetzt ist, stellt das Gateway automatisch ein Zertifikat aus und importiert es 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

sLang-Scheduler mit expliziten Gewichten

In diesem Beispiel wird der epp Scheduler-Typ mit der sglang Engine verwendet und explizite Punktegewichte für Endpoint Picker festgelegt.

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

LoRa-Adapter ConfigMap

Der Body-Based Router erkennt LoRa-Adapter und ihr Basismodell anhand eines für die BBR-Verwaltung ConfigMap gekennzeichneten Geräts. Der Router verwendet diese Zuordnung, um einen Adapternamen im Anforderungstext in sein Basismodell aufzulösen.

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

Rufen Sie das Gateway auf

Das Gateway dient als OpenAI-compatible Inferenzendpunkt. Dies ist der Laufzeitaufrufvertrag für das Senden von Inferenzanforderungen über das Gateway; es handelt sich nicht um einen AWS API-Vorgang. Senden Sie Anfragen an den Gateway-Endpunkt, wobei das model Feld auf das Feld modelName des Ziel-Schedulers gesetzt ist. Der Body-Based Router liest dieses Feld, um die Anfrage weiterzuleiten.

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