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 ](sagemaker-hyperpod-model-deployment.md) 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](#sagemaker-hyperpod-model-deployment-inference-gateway-crd)
**Importante**
Per impostazione predefinita, gli endpoint creati da Inference Gateway non dispongono di autenticazione o autorizzazione a livello di richiesta. A meno che non venga `spec.auth.jwt` configurato su`InferenceGatewayConfig`, il gateway accetta qualsiasi richiesta che lo pervenga; l'accesso è limitato solo dai controlli VPC e di rete. Consigliamo vivamente di abilitare l'autenticazione JWT su ogni gateway. Per configurare l'autenticazione, vedi [Prerequisiti e distribuzione](#sagemaker-hyperpod-model-deployment-inference-gateway-prereqs) e `spec.auth` sotto[campi delle specifiche](#sagemaker-hyperpod-model-deployment-inference-gateway-spec).
## 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à, vedere[Note sulla versione di Amazon SageMaker HyperPod Inference](sagemaker-hyperpod-inference-release-notes.md).
Prima di indirizzare il traffico attraverso il gateway, verifica quanto segue:
Pod per la gestione dei modelli implementati
Ogni scheduler indirizza ai pod destinati al modello selezionati da un selettore di etichette. Distribuite i vostri modelli con l' HyperPod Inference Operator e annotate le etichette applicate ai relativi pod in modo da potervi fare riferimento nella configurazione del gateway. Per elencare le etichette sui pod dei modelli, esegui il seguente comando:
```
kubectl get pods -n NAMESPACE --show-labels
```
Versioni del server modello
Inference Gateway richiede vLLM v0.9.2 o successivo e SGLang v0.3.5.post1 o successivo. Nelle versioni precedenti di vLLM, la metrica della cache KV viene pubblicata con un nome diverso da quello letto dal gateway. Le richieste vengono ancora indirizzate utilizzando i segnali rimanenti, ma l'utilizzo della cache KV viene ignorato e non viene segnalato alcun errore. Le versioni precedenti di SGlang non supportano il `--enable-metrics` flag e il contenitore non si avvia. Avvia SGLang con questo flag in modo che il gateway possa leggere le metriche necessarie per le decisioni di routing.
Add-on versione
Inference Gateway è disponibile a partire dalla versione `v2.0.0-eksbuild.2` del componente aggiuntivo Amazon SageMaker HyperPod Inference. Installa o aggiorna l'ultima versione disponibile del componente aggiuntivo. Se il cluster non riconosce la `InferenceGatewayConfig` risorsa, il componente aggiuntivo esegue una versione precedente che non include il gateway.
Dipendenze del cluster
+ cert-manager deve essere installato sul cluster per il percorso TLS di emissione automatica, che il gateway utilizza quando `spec.tls` è impostato senza un. `acmArn`
+ Il AWS Load Balancer Controller deve essere installato per il tipo di endpoint Application Load Balancer.
+ Il gateway utilizza il namespace. `hyperpod-inference-system`
Certificato TLS
Per terminare HTTPS sul gateway, fornisci un certificato ACM ARN esistente o consenti al gateway di emettere automaticamente un certificato. Auto-issue utilizza cert-manager e importa il certificato in ACM. Questo flusso richiede che il ruolo di esecuzione dell'operatore disponga delle `acm:DeleteCertificate` autorizzazioni`acm:ImportCertificate`, `acm:AddTagsToCertificate``acm:DescribeCertificate`, e tramite IRSA.
Richiedi l'autenticazione (consigliata)
Consigliamo vivamente di abilitare l'autenticazione JWT su ogni gateway impostando `spec.auth.jwt` su. `InferenceGatewayConfig` Quando `spec.auth` viene omesso, il gateway non dispone di autenticazione a livello di richiesta e l'accesso è limitato solo dai controlli del VPC e della rete. Per abilitare l'autenticazione JWT, tieni a portata di mano quanto segue prima di creare`InferenceGatewayConfig`: un URL dell'emittente OIDC, l'endpoint HTTPS JWKS che pubblica le chiavi di firma dell'emittente e i valori di pubblico (o attestazioni obbligatorie) che i token per questo gateway devono contenere. Vedi sotto per `spec.auth` lo schema completo. [campi delle specifiche](#sagemaker-hyperpod-model-deployment-inference-gateway-spec)
### 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).
**Importante**
L'emissione automatica del protocollo TLS è abilitata per impostazione predefinita e il controller del gateway legge questo ruolo all'avvio. Crea il ruolo prima di installare il componente aggiuntivo.
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 <
L'add-on HyperPod Inference installa sia l'Inference Operator che l'Inference Gateway. Installalo con il seguente comando. Per`inferenceGateway.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:::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/"
}'
```
Se il componente aggiuntivo è già installato nel cluster, sostituisci `create-addon` con e aggiungi. `update-addon` `--resolve-conflicts OVERWRITE` Il resto del comando è invariato. `OVERWRITE`applica 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](sagemaker-hyperpod-model-deployment.md)
HyperPod Operatore di inferenza
Riconcilia le risorse personalizzate `InferenceEndpointConfig` e `JumpStartModel` (gruppo`inference.sagemaker.aws.amazon.com`, versione) del modello. `v1` L'operatore crea il modello Deployment and Service, l'Application Load Balancer, l'autoscaling KEDA, il certificato cert-manager e la registrazione degli endpoint AI. SageMaker Quando il gateway è abilitato per un modello, l'operatore collega anche quel modello al gateway.
Inference Gateway
Possiede il routing delle richieste, dal Body-Based Router attraverso il gateway e HttpRoute all'Endpoint Picker, e genera le risorse di routing downstream per ogni scheduler: la configurazione di Endpoint Picker, HttpRoute e. `InferencePool` `EnvoyExtensionPolicy`
**Nota**
Le risorse personalizzate del modello dell'operatore utilizzano la versione, mentre la risorsa del gateway utilizza la versione. `v1` `InferenceGatewayConfig` `v1alpha1` Entrambi appartengono al `inference.sagemaker.aws.amazon.com` gruppo.
Si collega un modello al gateway tramite l'operatore, sulla risorsa del modello `InferenceEndpointConfig` (o`JumpStartModel`), utilizzando il `spec.inferenceGateway` campo:
`spec.inferenceGateway.enabled`(Facoltativo, booleano)
Se questo modello è collegato al gateway. Default: `false`.
`spec.inferenceGateway.name`(Opzionale, String)
Il nome della `InferenceGatewayConfig` risorsa a cui collegarsi. I modelli che condividono un nome e uno spazio dei nomi condividono un gateway. Quando questo campo è vuoto, l'operatore genera un nome del modulo. `inf-igw-`
Lo snippet seguente mostra l'`inferenceGateway`opt-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-.
```
L'operatore rispecchia lo stato dell'allegato sulla risorsa del modello in `status.inferenceGateway` basso, che riporta un `State` elemento di `Pending` `Ready``Failed`, 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 scheduler`name`, `modelName` `targetPort``modelSelector`, 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:
+ Abilita il gateway per modello tramite l'operatore, impostandolo `spec.inferenceGateway.enabled` su quello del `InferenceEndpointConfig` modello. L'operatore crea e gestisce la voce dello scheduler per il modello.
+ Crea direttamente la `InferenceGatewayConfig` risorsa, come mostrato in[Esempi](#sagemaker-hyperpod-model-deployment-inference-gateway-examples).
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](sagemaker-hyperpod-model-deployment-setup.md#sagemaker-hyperpod-model-deployment-setup-install-inference-operator-addon) 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](sagemaker-hyperpod-model-deployment-deploy.md)
**Nota**
Il mantenimento dello stato di salute dell' SageMaker HyperPod Inference Operator è una responsabilità condivisa tra e il cliente. AWS AWS è responsabile della fornitura e della manutenzione dell'operatore di SageMaker HyperPod inferenza. Dopo l'installazione, il cliente è responsabile del monitoraggio dello stato operativo dell'operatore all'interno del proprio cluster.
## 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 sottostante`InferencePool`, Endpoint Picker, HttpRoute e le `EnvoyExtensionPolicy` risorse per ogni scheduler; tu crei solo la risorsa. `InferenceGatewayConfig`
**InferenceGatewayConfig metadati delle risorse**
| Proprietà | Valore |
| --- | --- |
| Tipo | InferenceGatewayConfig |
| Gruppo | inference.sagemaker.aws.amazon.com |
| Versione | v1alpha1 |
| Plurale | inferencegatewayconfigs |
| Nome breve | igwc |
| Scope | Con spaziatura dei nomi |
| Sottorisorsa Status | /status |
### 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.
`bbr` (Obbligatorio)
Configurazione per il router condiviso. Body-Based Contiene i seguenti campi:
`bbr.enabled`(Obbligatorio, booleano)
Se il Body-Based router è abilitato. Il router deve essere abilitato quando è configurato più di uno scheduler.
`bbr.replicas` (Facoltativo, Numero intero)
Numero di repliche Body-Based del router. Minimo:`1`. Default: `2`.
`bbr.defaultBackend` (facoltativo).
Il backend che riceve richieste che il router non può abbinare a uno scheduler. Contiene una `name` stringa e un `port` numero intero (impostazione predefinita:). `8000`
`bbr.maxRequestBodyBytes` (Facoltativo, Numero intero)
Dimensione massima del corpo della richiesta, in byte, che il router memorizza nel buffer per leggere il campo. `model` Valore predefinito e massimo: `268435456` (256 MiB).
`tls`
Configurazione della terminazione HTTPS per il gateway. Contiene un `acmArn` campo che fa riferimento a un certificato ACM esistente. Se `tls` è impostato con un valore vuoto`acmArn`, il gateway emette automaticamente un certificato con cert-manager e lo importa in ACM.
`auth` (Facoltativo, Consigliato)
Richiedere la configurazione dell'autenticazione. Consigliamo vivamente di abilitare l'autenticazione JWT bearer-token su ogni gateway; se omesso, il gateway non ha un'autenticazione a livello di richiesta. I percorsi di controllo dello stato del Load Balancer rimangono non autenticati, in modo che i test di integrità possano avere successo senza un token.
Contiene i seguenti `auth.jwt.provider` campi:
`name`(Obbligatorio, String)
Nome univoco per il provider.
`issuer`(Obbligatorio, stringa)
URL dell'emittente OIDC (). `https://...` Il gateway convalida l'`iss`attestazione del token rispetto a questo valore.
`remoteJWKS.uri`(Obbligatorio, stringa)
Endpoint HTTPS JWKS utilizzato per verificare la firma JWT.
`audiences`(Facoltativo, Elenco)
Valori dei `aud` reclami accettati (fino a 8). Almeno uno dei valori `audiences` indicati `requiredClaims` deve essere impostato.
`requiredClaims`(Facoltativo, Elenco)
Claim-based autorizzazione (fino a 16 voci). Ogni voce contiene`name`, `valueType` (`String`o`StringArray`) e `values` (1—128 voci, ciascuna 1—1024 caratteri). Se impostato, il gateway nega le richieste per impostazione predefinita e ammette solo i token i cui valori di dichiarazione corrispondono.
`observability` (facoltativo).
Configurazione dell'osservabilità. Contiene`metrics.enabled`, che controlla il sidecar delle OpenTelemetry metriche. Le metriche sono abilitate per impostazione predefinita.
`podDefaults` (facoltativo).
Le impostazioni predefinite dei pod si applicano sia ai pod Body-Based Router che a Endpoint Picker. Supporta`resources`,,`nodeSelector`,`tolerations`,`affinity`, `labels``annotations`, `env` e. `envFrom`
`schedulers`(Obbligatorio, Elenco)
Un elenco di configurazioni dello scheduler per modello, digitate da. `name` È richiesto almeno uno scheduler ed è possibile definirne fino a 100. Ogni voce è una`SchedulerSpec`, descritta in[SchedulerSpec campi](#sagemaker-hyperpod-model-deployment-inference-gateway-scheduler).
### SchedulerSpec campi
Ogni voce in `spec.schedulers` configura il routing e la selezione degli endpoint per un modello. Uno scheduler nomina il generato`InferencePool`, Endpoint Picker, HttpRoute e le risorse. `EnvoyExtensionPolicy`
`name`(Obbligatorio, stringa)
Il nome dello scheduler. Utilizzato per denominare il generatore`InferencePool`, Endpoint Picker, HttpRoute e le risorse. `EnvoyExtensionPolicy` Lunghezza massima: 63 caratteri.
`modelSelector` (Obbligatorio)
Un selettore di etichette Kubernetes che seleziona i pod che servono i modelli a cui viene indirizzato questo scheduler.
`modelName`(Obbligatorio, String)
Il nome del modello corrisponde al `model` campo nel corpo della richiesta e viene utilizzato come corrispondenza dell'intestazione HttpRoute. Deve essere univoco tra gli scheduler. Lunghezza massima: 253 caratteri.
`targetPort` (Facoltativo, Numero intero)
La porta sui pod Model-Serving che riceve il traffico inoltrato. Intervallo: 1—65535. Default: `8000`.
`appProtocol`(Opzionale, stringa)
Il protocollo applicativo utilizzato per raggiungere i pod che servono i modelli. Valori validi: `http`, `kubernetes.io/h2c`. Default: `http`.
`scheduler`(Opzionale, String)
Il tipo di scheduler, che seleziona l'immagine Endpoint Picker. Valori validi: `llm-d`, `epp`. Default: `llm-d`.
`engineType`(Facoltativo, String)
Il motore di inferenza in esecuzione nei pod che servono i modelli. Questo valore seleziona l'insieme di nomi delle metriche Prometheus che Endpoint Picker analizza. Valori validi: `vllm`, `sglang`. Default: `vllm`.
`weights` (facoltativo).
Pesi di punteggio utilizzati da Endpoint Picker per classificare i pod candidati. Tutti i pesi sono numeri interi non negativi. Reciprocamente esclusivo con `configMapRef`. Pesi supportati:
`queue`
Peso per la profondità della coda delle richieste in sospeso. Default: `2`.
`kvCache`
Peso per l'utilizzo della cache KV. Default: `2`.
`prefix`
Peso per l'affinità tra prefisso e cache. Default: `3`.
`lru`
Peso per il punteggio utilizzato meno di recente. Valido solo quando `scheduler` è `llm-d`.
`loraAffinity`
Peso per l'affinità dell'adattatore LoRa.
`runningRequests`
Peso per il numero di richieste in esecuzione su un pod.
`predictedLatency`
Peso della latenza prevista delle richieste.
`configMapRef` (facoltativo).
Un riferimento a un ConfigMap che fornisce una configurazione personalizzata di Endpoint Picker, in alternativa a. `weights` Contiene un campo obbligatorio `name` e uno `key` (predefinito:`default-plugins.yaml`). Reciprocamente esclusivo con `weights`.
`replicas` (Facoltativo, Numero intero)
Numero di repliche di Endpoint Picker per questo scheduler. `1`Minimo:. Default: `2`. Quando `replicas` è maggiore di 1, Endpoint Picker viene eseguito in alta disponibilità con l'elezione del leader.
`env`e `envFrom` (opzionale)
Variabili di ambiente aggiunte al contenitore Endpoint Picker di questo scheduler.
`loraAdapters`(Facoltativo, Elenco)
I nomi degli adattatori LoRa sono utilizzati alla base del modello di questo scheduler. Massimo: 50 elementi, ciascuno con un massimo di 253 caratteri.
`routeTimeout`(Opzionale, stringa)
Il timeout della richiesta HttpRoute, come durata dell'API Gateway (ad esempio, `30s` o). `5m` Impostare su `0s` per disattivare il timeout.
`logLevel` (Facoltativo, Numero intero)
La verbosità del registro di Endpoint Picker. Intervallo: 0—5.
### Regole di convalida
La `InferenceGatewayConfig` risorsa applica le seguenti regole di convalida. Una risorsa che viola una di queste regole viene rifiutata.
+ Il Body-Based router deve essere abilitato (`bbr.enabled: true`) quando è configurato più di uno scheduler.
+ `modelName`deve essere univoco in tutti gli scheduler.
+ All'interno di uno scheduler `weights` e si `configMapRef` escludono a vicenda.
+ Il `weights.lru` peso è valido solo se il tipo dello scheduler è. `scheduler` `llm-d`
### campi di stato
Il controller riporta lo stato osservato del gateway nella `status` sottorisorsa.
`conditions`
Condizioni standard di Kubernetes che descrivono lo stato generale della configurazione del gateway.
`schedulers`
Per-scheduler stato. Ogni voce contiene:
`name`
Il nome dello scheduler.
`conditions`
Condizioni che descrivono lo stato di questo scheduler.
`currentScheduler`
Il tipo di scheduler attualmente in vigore per questa voce.
`rolloutState`
Lo stato di implementazione dello scheduler. Uno tra `Pending`, `Progressing`, `Available` o `Degraded`.
`observedGeneration`
La generazione della risorsa riconciliata più di recente dal controller.
`tls`
Stato TLS, riportato solo in modalità di emissione automatica. Contiene`acmArn`,`issuedAt`, e. `dnsNames`
## 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 verbi`create`,,`get`, `list``watch`, `update` e. `patch` `delete`
**Autorizzazioni del controller Inference Gateway**
| Gruppo API | Resources | Verbi | Scopo |
| --- | --- | --- | --- |
| inference.sagemaker.aws.amazon.com | inferencegatewayconfigs, comprese le sue status e le sue risorse secondarie finalizers | get,list, watchupdate, e patch perinferencegatewayconfigs; getupdate, e per patch i suoistatus; update per i suoi finalizers | Riconcilia la InferenceGatewayConfig risorsa, scrivine lo stato e gestisci il suo finalizzatore. |
| gateway.networking.k8s.io | httproutes, gateways, gatewayclasses | Accesso completo per httproutes egateways;get,,list, watch e per create patch gatewayclasses | Instradamento delle richieste di programma tramite l'API Gateway. |
| inference.networking.k8s.io | inferencepools | Accesso completo ad | Crea il backend di routing per ogni scheduler. |
| inference.networking.x-k8s.io | inferencepools, inferenceobjectives, inferencemodelrewrites | get, list, watch | Leggi l'intento di routing per la selezione degli endpoint. |
| gateway.envoyproxy.io | envoyextensionpolicies, envoyproxies, httproutefilters, clienttrafficpolicies, securitypolicies | Accesso completo ad | Configura il piano dati del gateway e la relativa telemetria. |
| Nucleo () "" | configmaps, services, serviceaccounts, events, secrets, pods | Accesso completo perconfigmaps,services, eserviceaccounts; create e patch perevents;get,list, e watch per secrets e pods | Gestisci i carichi di lavoro generati e leggi lo stato di routing e serving. |
| apps | deployments | Accesso completo ad | Gestisci le implementazioni di Body-Based Router ed Endpoint Picker. |
| rbac.authorization.k8s.io | roles, rolebindings | Accesso completo ad | Crea l'Endpoint Picker per scheduler. Role |
| discovery.k8s.io, coordination.k8s.io | endpointslices; leases | get,list, e watch perendpointslices;get,,list, watch e per create update patch leases | Endpoint Discovery ed elezione del leader di Endpoint Picker. |
| networking.k8s.io | ingresses, networkpolicies | Accesso completo ad | Effettua il provisioning del percorso Application Load Balancer tramite il Load Balancer Controller AWS . |
| cert-manager.io | issuers, certificates (con getlist, e watch sul core) secrets | Accesso completo ad | Auto-issue un certificato TLS se spec.tls impostato senza unacmArn. |
| apiextensions.k8s.io | customresourcedefinitions | create; eget, updatepatch, e delete limitato in base al nome della risorsa agli specifici CRD dell'API Gateway gestiti dal gateway | Installa le definizioni personalizzate delle risorse da cui dipende il gateway. |
**Nota**
Il `create` verbo on non `customresourcedefinitions` è limitato a nomi di risorse specifici. Il controller installa le definizioni di risorse personalizzate dell'API Gateway da cui dipende applicandole all'avvio dalla propria immagine del contenitore, poiché la loro dimensione combinata supera il limite di payload del componente aggiuntivo Amazon EKS. Kubernetes non consente di limitare il `create` verbo alle risorse denominate, quindi questa autorizzazione è necessariamente ampia. Tutte le altre operazioni sulle definizioni di risorse personalizzate (, `get` `update``patch`, e`delete`) sono limitate alle specifiche definizioni di risorse personalizzate gestite dal gateway. Questa autorizzazione consente di definire solo quei tipi di CRD; non concede l'accesso ai dati di alcuna risorsa personalizzata.
Il controller crea inoltre i seguenti ruoli con namespace in fase di esecuzione, a seconda della configurazione del gateway:
+ *Body-Based Router*: un namespace `Role` che concede`get`, e attiva`list`, che il router legge per risolvere gli adattatori `watch` `configmaps` LoRa. Quando il router utilizza più namespace, questo è un sostituto. `ClusterRole`
+ *Endpoint Picker*: un `Role` namespace che concede l'accesso in lettura a. `pods` Quando un Endpoint Picker viene eseguito con più di una replica, il controller crea anche un'elezione dei leader per e. `Role` `leases` `events` Quando le metriche Prometheus sono abilitate, il controller crea un optional `ClusterRole` che concede l'accesso in e in lettura all'endpoint`create`. `tokenreviews` `subjectaccessreviews` `/metrics`
**Nota**
Quando si abilita il gateway tramite HyperPod Inference Operator, il controller dell'operatore è autorizzato a creare e aggiornare le risorse. `InferenceGatewayConfig` Per informazioni su come l'operatore collega un modello al gateway, vedere[Integrazione con l'operatore di HyperPod inferenza](#sagemaker-hyperpod-model-deployment-inference-gateway-operator-integration).
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](sagemaker-hyperpod-model-deployment-observability.md) 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](#sagemaker-hyperpod-model-deployment-inference-gateway-spec)
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"}
]
}'
```