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 . ](sagemaker-hyperpod-model-deployment.md) 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 unter[InferenceGatewayConfig CRD-Referenz](#sagemaker-hyperpod-model-deployment-inference-gateway-crd). **Wichtig** Vom Inference Gateway erstellte Endpunkte verfügen standardmäßig über keine Authentifizierung oder Autorisierung auf Anforderungsebene. Sofern Sie es nicht `spec.auth.jwt` auf dem konfigurieren`InferenceGatewayConfig`, akzeptiert das Gateway jede Anfrage, die es erreicht. Der Zugriff wird nur durch Ihre VPC und Netzwerksteuerungen eingeschränkt. Wir empfehlen dringend, die JWT-Authentifizierung auf jedem Gateway zu aktivieren. Informationen zur Konfiguration der Authentifizierung finden Sie unter [Voraussetzungen und Bereitstellung](#sagemaker-hyperpod-model-deployment-inference-gateway-prereqs) und `spec.auth` unter[Spezifikationsfelder](#sagemaker-hyperpod-model-deployment-inference-gateway-spec). ## 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 unter[Versionshinweise SageMaker HyperPod zu Amazon Inference](sagemaker-hyperpod-inference-release-notes.md). Bevor Sie den Verkehr durch das Gateway leiten, überprüfen Sie Folgendes: Pods für Model-Serving bereitgestellt Jeder Scheduler leitet an Pods zur Modellbereitstellung weiter, die von einem Label-Selector ausgewählt wurden. Stellen Sie Ihre Modelle mit dem HyperPod Inferenzoperator bereit und notieren Sie sich die Labels, die auf ihre Pods angewendet wurden, damit Sie sie in der Gateway-Konfiguration referenzieren können. Führen Sie den folgenden Befehl aus, um die Labels auf Ihren Modell-Pods aufzulisten: ``` kubectl get pods -n NAMESPACE --show-labels ``` Versionen des Modellservers Das Inference Gateway benötigt vLLM v0.9.2 oder höher und sGLang v0.3.5.post1 oder höher. In früheren vLLM-Versionen wird die KV-Cache-Metrik unter einem anderen Namen veröffentlicht als dem, den das Gateway liest. Anfragen werden weiterhin mit den verbleibenden Signalen weitergeleitet, aber die KV-Cache-Nutzung wird ignoriert und es wird kein Fehler gemeldet. Frühere SGLang-Versionen unterstützen das `--enable-metrics` Flag nicht und der Container kann nicht gestartet werden. Starten Sie sgLang mit diesem Flag, damit das Gateway die Metriken lesen kann, die es für Routing-Entscheidungen benötigt. Add-on Version Das Inference Gateway ist ab `v2.0.0-eksbuild.2` der Version des Amazon SageMaker HyperPod Inference-Add-ons verfügbar. Installieren Sie das Add-on oder aktualisieren Sie es auf die neueste verfügbare Version. Wenn Ihr Cluster die `InferenceGatewayConfig` Ressource nicht erkennt, wird auf dem Add-on eine frühere Version ausgeführt, die das Gateway nicht enthält. Cluster-Abhängigkeiten + cert-manager muss auf dem Cluster für den TLS-Pfad zur automatischen Ausgabe installiert sein, den das Gateway verwendet, wenn er ohne einen festgelegt `spec.tls` ist. `acmArn` + Der Load AWS Balancer Controller muss für den Endpunkttyp Application Load Balancer installiert sein. + Das Gateway verwendet den Namespace. `hyperpod-inference-system` TLS-Zertifikat Um HTTPS am Gateway zu beenden, geben Sie entweder einen vorhandenen ACM-Zertifikat-ARN an oder lassen Sie das Gateway automatisch ein Zertifikat ausstellen. Auto-issue verwendet den Cert-Manager und importiert das Zertifikat in ACM. Für diesen Ablauf muss die Operator-Ausführungsrolle über IRSA über die `acm:DeleteCertificate` Berechtigungen `acm:ImportCertificate``acm:AddTagsToCertificate`,`acm:DescribeCertificate`, und verfügen. Authentifizierung anfordern (empfohlen) Wir empfehlen dringend, die JWT-Authentifizierung auf jedem Gateway zu aktivieren, indem Sie die `InferenceGatewayConfig` Einstellung `spec.auth.jwt` auf. Wenn nicht `spec.auth` angegeben, hat das Gateway keine Authentifizierung auf Anforderungsebene und der Zugriff wird nur durch Ihre VPC und Netzwerksteuerungen eingeschränkt. Um die JWT-Authentifizierung zu aktivieren, müssen Sie Folgendes bereithalten, bevor Sie Folgendes erstellen`InferenceGatewayConfig`: eine OIDC-Aussteller-URL, den HTTPS-JWKS-Endpunkt, der die Signaturschlüssel des Ausstellers veröffentlicht, und die Zielgruppenwerte (oder erforderlichen Ansprüche), die Token für dieses Gateway enthalten müssen. Das vollständige Schema finden Sie unter. `spec.auth` [Spezifikationsfelder](#sagemaker-hyperpod-model-deployment-inference-gateway-spec) ### 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. **Wichtig** Die automatische TLS-Ausgabe ist standardmäßig aktiviert, und der Gateway-Controller liest diese Rolle, wenn er gestartet wird. Erstellen Sie die Rolle, bevor Sie das Add-on installieren. 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 < 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:::role/", "tlsCertificateS3Bucket": "", "inferenceOperator": { "enabled": true }, "inferenceGateway": { "enabled": true, "serviceAccount": { "roleArn": "arn:aws:iam:::role/" } }, "keda": { "enabled": true, "auth": { "aws": { "irsa": { "enabled": true, "roleArn": "arn:aws:iam:::role/" } } } }, "alb": { "enabled": true, "serviceAccount": { "create": true, "roleArn": "arn:aws:iam:::role/" } }, "jumpstartGatedModelDownloadRoleArn": "arn:aws:iam:::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. `OVERWRITE`wendet 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 unter[Modelle auf Amazon bereitstellen SageMaker HyperPod](sagemaker-hyperpod-model-deployment.md). HyperPod Inferenz-Operator Stimmt die benutzerdefinierten Ressourcen `InferenceEndpointConfig` und `JumpStartModel` (Gruppe`inference.sagemaker.aws.amazon.com`, Version`v1`) des Modells ab. Der Operator erstellt das Modell Deployment and Service, den Application Load Balancer, KEDA Autoscaling, das Cert-Manager-Zertifikat und die AI-Endpunktregistrierung. SageMaker Wenn das Gateway für ein Modell aktiviert ist, verbindet der Operator dieses Modell auch mit dem Gateway. Inferenz-Gateway Besitzt das Anforderungsrouting vom Body-Based Router über das Gateway und HttpRoute zum Endpoint Picker und generiert die Downstream-Routing-Ressourcen für jeden Scheduler: die Endpoint Picker-Konfiguration`InferencePool`, HttpRoute und. `EnvoyExtensionPolicy` **Anmerkung** Die benutzerdefinierten Ressourcen des Operatormodells verwenden Version`v1`, während die Ressource des Gateways Version verwendet. `InferenceGatewayConfig` `v1alpha1` Beide gehören zur `inference.sagemaker.aws.amazon.com` Gruppe. Sie fügen dem Gateway über den Operator ein Modell auf der Ressource `InferenceEndpointConfig` (oder`JumpStartModel`) des Modells hinzu und verwenden dazu das `spec.inferenceGateway` Feld: `spec.inferenceGateway.enabled`(Optional, boolesch) Ob dieses Modell an das Gateway angeschlossen ist. Standard: `false`. `spec.inferenceGateway.name`(Optional, Zeichenfolge) Der Name der `InferenceGatewayConfig` Ressource, an die angehängt werden soll. Modelle, die einen Namen und einen Namespace gemeinsam haben, teilen sich ein Gateway. Wenn dieses Feld leer ist, generiert der Operator einen Namen für das Formular`inf-igw-`. 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-. ``` Der Operator spiegelt den Status des Anhangs auf der Modellressource wider`status.inferenceGateway`, unter der die Werte „Von“ `Pending``Ready`, „oder“ und „`State`des `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 Scheduler`name`, `modelName``targetPort`, und und als Standardeinstellung fest`modelSelector`, `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: + Aktivieren Sie das Gateway pro Modell über den Operator, indem Sie die Einstellungen `spec.inferenceGateway.enabled` für das `InferenceEndpointConfig` Modell festlegen. Der Operator erstellt und verwaltet den Scheduler-Eintrag für das Modell. + Verfassen Sie die `InferenceGatewayConfig` Ressource direkt, wie unter gezeigt. [Beispiele](#sagemaker-hyperpod-model-deployment-inference-gateway-examples) 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](sagemaker-hyperpod-model-deployment-setup.md#sagemaker-hyperpod-model-deployment-setup-install-inference-operator-addon) 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](sagemaker-hyperpod-model-deployment-deploy.md) **Anmerkung** Die Aufrechterhaltung der Integrität des SageMaker HyperPod Inferenzoperators liegt in der gemeinsamen Verantwortung von und AWS dem Kunden. AWS ist für die Bereitstellung und Wartung des SageMaker HyperPod Inference Operators verantwortlich. Nach der Installation ist der Kunde für die Überwachung des Betriebszustands des Operators innerhalb seines Clusters verantwortlich. ## 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` **InferenceGatewayConfig Metadaten der Ressource** | Eigenschaft | Wert | | --- | --- | | Art | InferenceGatewayConfig | | Group (Gruppieren) | inference.sagemaker.aws.amazon.com | | Version | v1alpha1 | | Plural | inferencegatewayconfigs | | Kurzname | igwc | | Scope | Mit Namespace | | Status-Unterressource | /status | ### 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. `bbr` (Erforderlich) Konfiguration für den gemeinsam genutzten Router. Body-Based Enthält die folgenden Felder: `bbr.enabled`(Erforderlich, boolesch) Ob der Body-Based Router aktiviert ist. Der Router muss aktiviert sein, wenn mehr als ein Scheduler konfiguriert ist. `bbr.replicas` (Optional, Ganzzahl) Anzahl der Body-Based Router-Replikate. Mindestanzahl:`1`. Standard: `2`. `bbr.defaultBackend` (Optional) Das Backend, das Anfragen empfängt, die der Router keinem Scheduler zuordnen kann. Enthält eine `name` Zeichenfolge und eine `port` Ganzzahl (Standard:`8000`). `bbr.maxRequestBodyBytes` (Optional, Ganzzahl) Maximale Größe des Anforderungstexts in Byte, die der Router zwischenspeichert, um das `model` Feld zu lesen. Standard und Maximum: `268435456` (256 MiB). `tls` HTTPS-Terminierungskonfiguration für das Gateway. Enthält ein `acmArn` Feld, das auf ein vorhandenes ACM-Zertifikat verweist. Wenn `tls` dieses Feld leer ist`acmArn`, stellt das Gateway automatisch ein Zertifikat mit cert-manager aus und importiert es in ACM. `auth` (optional, empfohlen) Fordern Sie die Authentifizierungskonfiguration an. Wir empfehlen dringend, die JWT-Bearer-Token-Authentifizierung auf jedem Gateway zu aktivieren. Wenn sie weggelassen wird, hat das Gateway keine Authentifizierung auf Anforderungsebene. Load Balancer-Health-Check-Routen bleiben nicht authentifiziert, sodass Integritätstests auch ohne Token erfolgreich sein können. Enthält die folgenden `auth.jwt.provider` Felder: `name`(Erforderlich, Zeichenfolge) Eindeutiger Name für den Anbieter. `issuer`(Erforderlich, Zeichenfolge) URL des OIDC-Ausstellers (). `https://...` Das Gateway validiert den `iss` Anspruch des Tokens anhand dieses Werts. `remoteJWKS.uri`(Erforderlich, Zeichenfolge) HTTPS-JWKS-Endpunkt, der zur Überprüfung der JWT-Signatur verwendet wird. `audiences`(Optional, Liste) `aud`Zulässige Anspruchswerte (bis zu 8). Mindestens einer von `audiences` oder `requiredClaims` muss gesetzt werden. `requiredClaims`(Optional, Liste) Claim-based Autorisierung (bis zu 16 Einträge). Jeder Eintrag hat`name`, `valueType` (`String`oder`StringArray`) und `values` (1—128 Einträge, jeweils 1—1024 Zeichen). Wenn diese Option gesetzt ist, lehnt das Gateway Anfragen standardmäßig ab und lässt nur Token zu, deren Anspruchswerte übereinstimmen. `observability` (Optional) Konfiguration der Beobachtbarkeit. Enthält`metrics.enabled`, das den Seitenwagen der OpenTelemetry Metriken steuert. Metriken sind standardmäßig aktiviert. `podDefaults` (Optional) Die Standard-Pod-Einstellungen gelten sowohl für den Body-Based Router- als auch für den Endpoint Picker-Pod. Unterstützt`resources`,`nodeSelector`, `tolerations``affinity`,`labels`, `annotations``env`, und`envFrom`. `schedulers`(Erforderlich, Liste) Eine Liste der Scheduler-Konfigurationen pro Modell, gekennzeichnet durch. `name` Es ist mindestens ein Scheduler erforderlich, und Sie können bis zu 100 definieren. Jeder Eintrag ist ein`SchedulerSpec`, wie unter beschrieben[SchedulerSpec Felder](#sagemaker-hyperpod-model-deployment-inference-gateway-scheduler). ### SchedulerSpec Felder Jeder Eintrag in `spec.schedulers` konfiguriert das Routing und die Endpunktauswahl für ein Modell. Ein Scheduler benennt die generierten Ressourcen`InferencePool`, Endpoint Picker, HttpRoute und Ressourcen. `EnvoyExtensionPolicy` `name`(Erforderlich, Zeichenfolge) Der Name des Schedulers. Wird verwendet, um den generierten Endpoint Picker`InferencePool`, HttpRoute und Ressourcen zu benennen. `EnvoyExtensionPolicy` Maximale Länge: 63 Zeichen. `modelSelector` (Erforderlich) Ein Kubernetes-Labelselektor, der die Model-Serving-Pods auswählt, zu denen dieser Scheduler eine Route weiterleitet. `modelName`(Erforderlich, Zeichenfolge) Der Modellname stimmte mit dem `model` Feld im Anforderungstext überein und wurde als HttpRoute-Header-Match verwendet. Muss für alle Scheduler eindeutig sein. Maximale Länge: 253 Zeichen. `targetPort` (Optional, Ganzzahl) Der Port auf den Model-Serving-Pods, der weitergeleiteten Datenverkehr empfängt. Bereich: 1—65535. Standard: `8000`. `appProtocol`(Optional, Zeichenfolge) Das Anwendungsprotokoll, das verwendet wird, um die Model-Serving-Pods zu erreichen. Zulässige Werte: `http`, `kubernetes.io/h2c`. Standard: `http`. `scheduler`(Optional, Zeichenfolge) Der Scheduler-Typ, der das Endpoint Picker-Image auswählt. Zulässige Werte: `llm-d`, `epp`. Standard: `llm-d`. `engineType`(Optional, Zeichenfolge) Die Inferenz-Engine, die in den Pods für die Modellbereitstellung läuft. Mit diesem Wert wird der Satz von Prometheus-Metriknamen ausgewählt, den der Endpoint Picker scrapt. Zulässige Werte: `vllm`, `sglang`. Standard: `vllm`. `weights` (Optional) Bewertungsgewichte, die der Endpoint Picker zur Rangfolge der Kandidaten-Pods verwendet. Alle Gewichtungen sind nicht negative Ganzzahlen. Schließt sich gegenseitig mit `configMapRef` aus. Unterstützte Gewichte: `queue` Gewicht für die Tiefe der Warteschlange für ausstehende Anfragen. Standard: `2`. `kvCache` Gewicht für die KV-Cache-Nutzung. Standard: `2`. `prefix` Gewicht für die Präfix-Cache-Affinität. Standard: `3`. `lru` Gewichtung für die Bewertung, die am wenigsten kürzlich verwendet wurde. Gilt nur, wenn `scheduler` `llm-d` ist. `loraAffinity` Gewicht für die Affinität zum LoRa-Adapter. `runningRequests` Gewicht für die Anzahl der laufenden Anfragen auf einem Pod. `predictedLatency` Gewicht für die vorhergesagte Latenz bei Anfragen. `configMapRef` (Optional) Ein Verweis auf a ConfigMap , der eine benutzerdefinierte Endpoint Picker-Konfiguration bereitstellt, als Alternative zu`weights`. Enthält ein erforderliches `name` und ein `key` (Standard:`default-plugins.yaml`). Schließt sich gegenseitig mit `weights` aus. `replicas` (Optional, Ganzzahl) Anzahl der Endpoint Picker-Replikate für diesen Scheduler. Mindestwert:. `1` Standard: `2`. Wenn der `replicas` Wert größer als 1 ist, wird der Endpoint Picker mit hoher Verfügbarkeit ausgeführt, wobei der Leader gewählt wird. `env`und `envFrom` (optional) Umgebungsvariablen, die an den Endpoint Picker-Container dieses Schedulers angehängt wurden. `loraAdapters`(Optional, Liste) Die Namen der LoRa-Adapter wurden hinter dem Modell dieses Schedulers verwendet. Maximal: 50 Elemente mit jeweils bis zu 253 Zeichen. `routeTimeout`(Optional, Zeichenfolge) Das Zeitlimit für die HttpRoute-Anfrage als Gateway-API-Dauer (z. B. `30s` oder). `5m` Stellen Sie ihn auf ein, um den `0s` Timeout zu deaktivieren. `logLevel` (Optional, Ganzzahl) Die Ausführlichkeit des Endpoint Picker-Protokolls. Bereich: 0—5. ### Regeln für die Validierung Die `InferenceGatewayConfig` Ressource erzwingt die folgenden Validierungsregeln. Eine Ressource, die gegen eine dieser Regeln verstößt, wird abgelehnt. + Der Body-Based Router muss aktiviert (`bbr.enabled: true`) sein, wenn mehr als ein Scheduler konfiguriert ist. + `modelName`muss für alle Scheduler eindeutig sein. + Innerhalb eines Schedulers `weights` und schließen `configMapRef` sich gegenseitig aus. + Die `weights.lru` Gewichtung ist nur gültig, wenn der `scheduler` Typ des Schedulers lautet. `llm-d` ### Status-Felder Der Controller meldet den beobachteten Zustand des Gateways in der `status` Unterressource. `conditions` Kubernetes-Standardbedingungen, die den Gesamtstatus der Gateway-Konfiguration beschreiben. `schedulers` Per-scheduler Status. Jeder Eintrag enthält: `name` Der Name des Schedulers. `conditions` Bedingungen, die den Status dieses Schedulers beschreiben. `currentScheduler` Der Scheduler-Typ, der derzeit für diesen Eintrag gültig ist. `rolloutState` Der Rollout-Status des Schedulers. Einer der Werte `Pending`, `Progressing`, `Available` oder `Degraded`. `observedGeneration` Die Generierung der Ressource, die zuletzt vom Controller abgeglichen wurde. `tls` TLS-Status, der nur im Modus für die automatische Ausgabe gemeldet wird. Enthält `acmArn``issuedAt`, und`dnsNames`. ## 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 Verben`create`,`get`,, `list` `watch``update`, `patch` und. `delete` **Berechtigungen für den Inference Gateway-Controller** | API-Gruppe | Ressourcen | Verben | Zweck | | --- | --- | --- | --- | | inference.sagemaker.aws.amazon.com | inferencegatewayconfigs, einschließlich seiner status und Unterressourcen finalizers | get,list, watchupdate, und patch fürinferencegatewayconfigs; getupdate, und patch für seinestatus; update für seine finalizers | Stimmen Sie die InferenceGatewayConfig Ressource ab, schreiben Sie ihren Status und verwalten Sie ihren Finalizer. | | gateway.networking.k8s.io | httproutes, gateways, gatewayclasses | Vollzugriff für httproutes undgateways;get, listwatch, create und für patch gatewayclasses | Weiterleitung von Programmanfragen über die Gateway-API. | | inference.networking.k8s.io | inferencepools | Vollzugriff | Erstellen Sie das Routing-Backend für jeden Scheduler. | | inference.networking.x-k8s.io | inferencepools, inferenceobjectives, inferencemodelrewrites | get, list, watch | Lesen Sie die Routing-Absicht für die Endpunktauswahl. | | gateway.envoyproxy.io | envoyextensionpolicies, envoyproxies, httproutefilters, clienttrafficpolicies, securitypolicies | Vollzugriff | Konfigurieren Sie die Gateway-Datenebene und ihre Telemetrie. | | Kern () "" | configmaps, services, serviceaccounts, events, secrets, pods | Voller Zugriff für configmapsservices, undserviceaccounts; create und patch fürevents; getlist, und watch für secrets und pods | Verwalten Sie die generierten Workloads und lesen Sie den Routing- und Serverstatus. | | apps | deployments | Vollzugriff | Verwalten Sie die Body-Based Router- und Endpoint Picker-Bereitstellungen. | | rbac.authorization.k8s.io | roles, rolebindings | Vollzugriff | Erstellen Sie den Endpoint Picker pro Scheduler. Role | | discovery.k8s.io, coordination.k8s.io | endpointslices; leases | getlist, und watch fürendpointslices;get,, list watchcreate, update und für patch leases | Wahl zum Leiter von Endpoint Discovery und Endpoint Picker. | | networking.k8s.io | ingresses, networkpolicies | Vollzugriff | Stellen Sie den Application Load Balancer-Pfad über den Load AWS Balancer Controller bereit. | | cert-manager.io | issuers, certificates (mit getlist, und watch auf dem Kern) secrets | Vollzugriff | Auto-issue ein TLS-Zertifikat, wenn spec.tls es ohne ein gesetzt istacmArn. | | apiextensions.k8s.io | customresourcedefinitions | create; undget, updatepatch, und delete beschränkt durch den Ressourcennamen auf die spezifischen Gateway-API-CDs, die das Gateway verwaltet | Installieren Sie die benutzerdefinierten Ressourcendefinitionen, von denen das Gateway abhängig ist. | **Anmerkung** Das `create` Verb on `customresourcedefinitions` ist nicht auf bestimmte Ressourcennamen beschränkt. Der Controller installiert die benutzerdefinierten Ressourcendefinitionen der Gateway-API, von denen er abhängig ist, indem er sie beim Start von seinem eigenen Container-Image aus anwendet, da ihre kombinierte Größe das Amazon EKS-Zusatznutzlastlimit überschreitet. In Kubernetes ist es nicht möglich, das `create` Verb auf benannte Ressourcen zu beschränken, daher ist diese Erlaubnis zwangsläufig weit gefasst. Alle anderen Operationen mit benutzerdefinierten Ressourcendefinitionen —`get`, `update``patch`, und `delete` — sind auf die spezifischen benutzerdefinierten Ressourcendefinitionen beschränkt, die das Gateway verwaltet. Mit dieser Berechtigung können nur diese CRD-Typen definiert werden. Sie gewährt keinen Zugriff auf die Daten benutzerdefinierter Ressourcen. Je nach Gateway-Konfiguration erstellt der Controller zur Laufzeit auch die folgenden Rollen mit Namespaces: + *Body-Based Router * — Ein Namespaces`Role`, der gewährt und `watch` auf dem der Router liest `get``list`, um `configmaps` LoRa-Adapter aufzulösen. Wenn der Router über mehrere Namespaces läuft, ist dies stattdessen ein. `ClusterRole` + *Endpoint Picker * — Ein `Role` Namespace-Bereich, auf den Lesezugriff gewährt wird. `pods` Wenn ein Endpoint Picker mit mehr als einem Replikat ausgeführt wird, erstellt der Controller auch eine Leader-Auswahl für und. `Role` `leases` `events` Wenn Prometheus-Metriken aktiviert sind, erstellt der Controller eine Option, die den Ein `tokenreviews` - `subjectaccessreviews` und `ClusterRole` Lesezugriff `create` auf den Endpunkt gewährt. `/metrics` **Anmerkung** Wenn Sie das Gateway über den HyperPod Inferenzoperator aktivieren, ist der eigene Controller des Operators berechtigt, Ressourcen zu erstellen und zu aktualisieren. `InferenceGatewayConfig` Informationen dazu, wie der Operator ein Modell mit dem Gateway verbindet, finden Sie unter[Integration mit dem HyperPod Inferenzoperator](#sagemaker-hyperpod-model-deployment-inference-gateway-operator-integration). 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](sagemaker-hyperpod-model-deployment-observability.md) und zum Dashboard finden Sie unter. Stellen Sie das Feld auf ein, `false` um die Beiwageninjektion zu überspringen. Die Feldreferenz finden Sie unter`observability`. [Spezifikationsfelder](#sagemaker-hyperpod-model-deployment-inference-gateway-spec) 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"} ] }' ```