As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá. # Gateway de inferência para Amazon SageMaker HyperPod Inference O Amazon SageMaker HyperPod Inference Gateway é uma Kubernetes-native camada de roteamento e orquestração compatível com um modelo de linguagem grande (LLM) para clusters no Amazon EKS. HyperPod Ele inspeciona as solicitações de inferência, lê o nome do modelo de cada solicitação e seleciona um pod que serve o modelo com base na carga da GPU, para que o tráfego de vários modelos seja roteado de forma eficiente por meio de um único terminal de gateway. O gateway encaminha cada solicitação por meio de três camadas. O Body-Based roteador (BBR), um componente compartilhado, lê o `model` campo do corpo da solicitação, resolve o nome de um adaptador LoRa para seu modelo básico e define os `X-Gateway-Model-Name` cabeçalhos e. `X-Gateway-Base-Model-Name` O gateway então combina esses cabeçalhos com um HttpRoute e encaminha a solicitação `InferencePool` para o modelo solicitado. Dentro desse pool, o Endpoint Picker (EPP/scheduler) escolhe um pod que serve o modelo pontuando os candidatos nas métricas do servidor modelo, como profundidade da fila e utilização do cache KV, junto com a afinidade do cache de prefixo e do adaptador LoRa. Cada entrada que você define em `spec.schedulers` executa seu próprio Seletor de Endpoint, portanto, este tópico usa os termos Endpoint Picker, EPP e scheduler de forma intercambiável. O Inference Gateway se baseia no [ HyperPod Inference Operator em ](sagemaker-hyperpod-model-deployment.md) vez de substituí-lo. Enquanto o operador continua a orquestrar a implantação do modelo, o gateway introduz uma camada de LLM-aware roteamento na frente dos pods que servem o modelo. O gateway não depende de um modelo específico de servidor ou camada de orquestração e é fornecido por meio do complemento HyperPod Inference Amazon EKS. Você define um gateway com o recurso `InferenceGatewayConfig` personalizado. Um único `InferenceGatewayConfig` descreve um gateway: o Body-Based roteador compartilhado, a terminação TLS, a autenticação de solicitação e um agendador para cada modelo que o gateway atende. Para ver o esquema completo, consulte[InferenceGatewayConfig Referência CRD](#sagemaker-hyperpod-model-deployment-inference-gateway-crd). **Importante** Por padrão, os endpoints criados pelo Inference Gateway não têm autenticação ou autorização em nível de solicitação. A menos que você configure `spec.auth.jwt` no`InferenceGatewayConfig`, o gateway aceita qualquer solicitação que chegue até ele; o acesso é restrito somente pela sua VPC e pelos controles de rede. É altamente recomendável ativar a autenticação JWT em todos os gateways. Para configurar a autenticação, consulte [Pré-requisitos e implantação](#sagemaker-hyperpod-model-deployment-inference-gateway-prereqs) e `spec.auth` abaixo[campos de especificação](#sagemaker-hyperpod-model-deployment-inference-gateway-spec). ## Pré-requisitos e implantação O Inference Gateway é fornecido como parte do complemento HyperPod Inference Amazon EKS. A instalação do complemento torna o gateway disponível, portanto, nenhuma instalação separada é necessária. Em seguida, você ativa o roteamento de gateway para um modelo por meio do `spec.inferenceGateway.enabled` campo no `InferenceEndpointConfig` recurso do modelo. Para a versão na qual um recurso foi introduzido, consulte[Notas de lançamento do Amazon SageMaker HyperPod Inference](sagemaker-hyperpod-inference-release-notes.md). Antes de rotear o tráfego pelo gateway, verifique o seguinte: Pods de serviço de modelos implantados Cada programador encaminha para pods que servem modelos selecionados por um seletor de rótulos. Implante seus modelos com o operador de HyperPod inferência e anote os rótulos aplicados aos pods para que você possa referenciá-los na configuração do gateway. Para listar os rótulos em seus pods de modelo, execute o seguinte comando: ``` kubectl get pods -n NAMESPACE --show-labels ``` Versões do servidor modelo O Inference Gateway exige o vLLm v0.9.2 ou posterior e o SGlang v0.3.5.post1 ou posterior. Nas versões anteriores do vLLM, a métrica de cache KV é publicada com um nome diferente daquele que o gateway lê. As solicitações ainda são roteadas usando os sinais restantes, mas a utilização do cache KV é ignorada e nenhum erro é relatado. As versões anteriores do SGLang não suportam o `--enable-metrics` sinalizador e o contêiner falha ao iniciar. Inicie o SGLang com esse sinalizador para que o gateway possa ler as métricas necessárias para as decisões de roteamento. Add-on versão O Inference Gateway está disponível a partir `v2.0.0-eksbuild.2` da versão do complemento Amazon SageMaker HyperPod Inference. Instale ou atualize para a versão mais recente disponível do complemento. Se o cluster não reconhecer o `InferenceGatewayConfig` recurso, o complemento está executando uma versão anterior que não inclui o gateway. Dependências de cluster + O cert-manager deve ser instalado no cluster para o caminho TLS de emissão automática, que o gateway usa quando `spec.tls` é definido sem um. `acmArn` + O controlador do balanceador de AWS carga deve ser instalado para o tipo de endpoint do Application Load Balancer. + O gateway usa o `hyperpod-inference-system` namespace. Certificado TLS Para encerrar o HTTPS no gateway, forneça um ARN de certificado ACM existente ou permita que o gateway emita automaticamente um certificado. Auto-issue usa cert-manager e importa o certificado para o ACM. Esse fluxo exige que a função de execução do operador tenha as `acm:DeleteCertificate` permissões`acm:ImportCertificate`, `acm:AddTagsToCertificate``acm:DescribeCertificate`, e por meio do IRSA. Solicitar autenticação (recomendado) É altamente recomendável ativar a autenticação JWT em cada gateway, `spec.auth.jwt` configurando o. `InferenceGatewayConfig` Quando `spec.auth` é omitido, o gateway não tem autenticação em nível de solicitação e o acesso é restrito somente por sua VPC e controles de rede. Para habilitar a autenticação JWT, prepare o seguinte antes de criar o`InferenceGatewayConfig`: um URL do emissor do OIDC, o endpoint HTTPS JWKS que publica as chaves de assinatura do emissor e os valores de público (ou declarações obrigatórias) que os tokens desse gateway devem conter. Veja `spec.auth` abaixo [campos de especificação](#sagemaker-hyperpod-model-deployment-inference-gateway-spec) o esquema completo. ### Configurar a função IAM do emissor do certificado Quando o gateway emite automaticamente um certificado TLS, o cert-manager gera o certificado no cluster e o controlador do gateway o importa para o ACM. Como a importação é uma chamada de AWS API, o controlador precisa de AWS credenciais. Forneça-os criando uma função do IAM que a conta `inference-gateway-controller` de serviço no `hyperpod-inference-system` namespace assume por meio das funções do IAM para contas de serviço (IRSA). **Importante** A emissão automática de TLS é ativada por padrão, e o controlador do gateway lê essa função quando ela é iniciada. Crie a função antes de instalar o complemento. Defina as seguintes variáveis de ambiente e recupere o emissor OIDC para seu 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://||') ``` Crie uma política de confiança que permita que a conta de serviço do controlador de gateway assuma a função. ``` cat > trust-policy.json < O complemento HyperPod Inference instala o Inference Operator e o Inference Gateway. Instale-o com o comando a seguir. Para`inferenceGateway.serviceAccount.roleArn`, use a função de emissor do certificado que você criou na seção anterior. Substitua os valores restantes do espaço reservado pelas funções e pelo bucket da sua conta. ``` 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 o complemento já estiver instalado no cluster, `create-addon` substitua por `update-addon` e adicione`--resolve-conflicts OVERWRITE`. O resto do comando permanece inalterado. `OVERWRITE`aplica os valores de configuração no comando sobre a configuração adicional existente. Confirme se o controlador do gateway está em execução e se os recursos do gateway estão registrados. ``` 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 ``` Confirme se o complemento em si está ativo e não relata problemas de saúde. ``` aws eks describe-addon \ --cluster-name $CLUSTER --region $REGION \ --addon-name amazon-sagemaker-hyperpod-inference \ --query 'addon.{version:addonVersion,status:status,health:health.issues}' ``` ## Integração com o operador de HyperPod inferência O operador de HyperPod inferência e o gateway de inferência têm responsabilidades distintas. O operador possui a implantação do modelo, a orquestração e a fiação que conecta um modelo ao gateway. O gateway possui o roteamento de solicitações e gera os recursos de roteamento para cada agendador. Para obter mais informações sobre a implantação de modelos com o operador, consulte[Implantação de modelos na Amazon SageMaker HyperPod](sagemaker-hyperpod-model-deployment.md). HyperPod Operador de inferência Reconcilia os recursos personalizados do modelo `InferenceEndpointConfig` e `JumpStartModel` (grupo`inference.sagemaker.aws.amazon.com`, versão`v1`). O operador cria o modelo Deployment and Service, o Application Load Balancer, o escalonamento automático KEDA, o certificado cert-manager e o registro do endpoint de IA. SageMaker Quando o gateway está habilitado para um modelo, o operador também conecta esse modelo ao gateway. Gateway de inferência Possui o roteamento de solicitações, do Body-Based roteador através do gateway e do HttpRoute até o Endpoint Picker, e gera os recursos de roteamento downstream para cada agendador: a configuração do Endpoint Picker`InferencePool`, HTTPRoute e. `EnvoyExtensionPolicy` **nota** Os recursos personalizados do modelo do operador usam a versão`v1`, enquanto o `InferenceGatewayConfig` recurso do gateway usa a versão`v1alpha1`. Ambos pertencem ao `inference.sagemaker.aws.amazon.com` grupo. Você anexa um modelo ao gateway por meio do operador, no recurso do modelo `InferenceEndpointConfig` (ou`JumpStartModel`), usando o `spec.inferenceGateway` campo: `spec.inferenceGateway.enabled`(Opcional, booleano) Se esse modelo está conectado ao gateway. Padrão: `false`. `spec.inferenceGateway.name`(Opcional, Cadeia de caracteres) O nome do `InferenceGatewayConfig` recurso a ser anexado. Modelos que compartilham um nome e um namespace compartilham um gateway. Quando esse campo está vazio, o operador gera um nome do formulário`inf-igw-`. O trecho a seguir mostra a `inferenceGateway` aceitação de um recurso. `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-. ``` O operador espelha o estado do anexo no recurso do modelo abaixo`status.inferenceGateway`, que relata um `State` de `Pending``Ready`,`Failed`, ou e o `Name` do anexo`InferenceGatewayConfig`. Você não pode definir `inferenceGateway.enabled` juntos `intelligentRoutingSpec.enabled` no mesmo modelo; esses campos são mutuamente exclusivos. Quando o gateway é habilitado para um modelo, o operador cria ou atualiza um único `InferenceGatewayConfig` recurso e mescla uma entrada para o modelo em sua `spec.schedulers` lista. O operador define o agendador`name`,, e `modelName``targetPort`, e`modelSelector`, como padrão, `llm-d` quando cria `scheduler` a entrada pela primeira vez. Em reconciliações posteriores, o operador preserva valores fornecidos pelo cliente, como, e. `scheduler` `weights` `loraAdapters` O Body-Based roteador é ativado automaticamente quando mais de um agendador está presente. O operador não exclui o `InferenceGatewayConfig` recurso nem os recursos de roteamento downstream. Quando você desativa o gateway de um modelo ou exclui o modelo, o operador remove somente a entrada do agendador desse modelo. O controlador do gateway é responsável pela limpeza dos recursos de roteamento. Você pode criar um `InferenceGatewayConfig` de duas maneiras, e os dois caminhos coexistem no mesmo recurso: + Ative o gateway por modelo por meio do operador, configurando `spec.inferenceGateway.enabled` no modelo`InferenceEndpointConfig`. O operador cria e mantém a entrada do agendador para o modelo. + Crie o `InferenceGatewayConfig` recurso diretamente, conforme mostrado em[Exemplos](#sagemaker-hyperpod-model-deployment-inference-gateway-examples). Os componentes do gateway e o `InferenceGatewayConfig` CRD devem ser instalados por meio do complemento HyperPod Inference Amazon EKS antes que um recurso de modelo com o gateway ativado possa ser reconciliado. Para a instalação do complemento do operador, consulte[Instalando o operador de inferência com o complemento EKS](sagemaker-hyperpod-model-deployment-setup.md#sagemaker-hyperpod-model-deployment-setup-install-inference-operator-addon). Para implantar os pods que servem modelos para os quais um programador encaminha, consulte. [Implantar modelos de base e modelos personalizados e ajustados](sagemaker-hyperpod-model-deployment-deploy.md) **nota** Manter a integridade do operador de SageMaker HyperPod inferência é uma responsabilidade compartilhada entre AWS e o cliente. AWS é responsável por fornecer e manter o Operador de SageMaker HyperPod Inferência. Após a instalação, o cliente é responsável por monitorar a integridade operacional do operador em seu cluster. ## InferenceGatewayConfig Referência CRD Você configura o Inference Gateway com um único recurso `InferenceGatewayConfig` personalizado. O recurso é um singleton para um determinado gateway: ele contém a configuração compartilhada do Body-Based roteador e uma lista de agendadores por modelo. O controlador gera o Endpoint Picker`InferencePool`, o HttpRoute e `EnvoyExtensionPolicy` os recursos subjacentes para cada agendador; você cria somente o recurso. `InferenceGatewayConfig` **InferenceGatewayConfig metadados de recursos** | Propriedade | Valor | | --- | --- | | Tipo | InferenceGatewayConfig | | Group (Grupo) | inference.sagemaker.aws.amazon.com | | Versão | v1alpha1 | | Plural | inferencegatewayconfigs | | Nome curto | igwc | | Escopo | Com namespace | | Sub-recurso de status | /status | ### campos de especificação O `spec` campo do `InferenceGatewayConfig` recurso contém a configuração compartilhada do Body-Based roteador, as configurações de TLS, a lista necessária de agendadores e as configurações opcionais de observabilidade e padrão do pod. `bbr` (Obrigatório) Configuração para o Body-Based roteador compartilhado. Contém os seguintes campos: `bbr.enabled`(Obrigatório, booleano) Se o Body-Based roteador está ativado. O roteador deve ser ativado quando mais de um agendador estiver configurado. `bbr.replicas` (opcional, inteiro) Número de réplicas Body-Based do roteador. Mínimo:`1`. Padrão: `2`. `bbr.defaultBackend` (Opcional) O back-end que recebe solicitações que o roteador não pode corresponder a um agendador. Contém uma `name` string e um `port` inteiro (padrão:`8000`). `bbr.maxRequestBodyBytes` (opcional, inteiro) Tamanho máximo do corpo da solicitação, em bytes, que o roteador armazena em buffer para ler o `model` campo. Padrão e máximo: `268435456` (256 MiB). `tls` Configuração de terminação HTTPS para o gateway. Contém um `acmArn` campo que faz referência a um certificado ACM existente. Se `tls` estiver definido como vazio`acmArn`, o gateway emite automaticamente um certificado com o cert-manager e o importa para o ACM. `auth` (Opcional, Recomendado) Solicite a configuração de autenticação. É altamente recomendável ativar a autenticação do token portador do JWT em cada gateway; quando omitido, o gateway não tem autenticação em nível de solicitação. As rotas de verificação de integridade do balanceador de carga permanecem não autenticadas para que as sondagens de integridade possam ser bem-sucedidas sem um token. Contém `auth.jwt.provider` os seguintes campos: `name`(Obrigatório, Cadeia de caracteres) Nome exclusivo do provedor. `issuer`(Obrigatório, Cadeia de caracteres) URL do emissor do OIDC (). `https://...` O gateway valida a `iss` reivindicação do token em relação a esse valor. `remoteJWKS.uri`(Obrigatório, Cadeia de caracteres) Endpoint HTTPS JWKS usado para verificar a assinatura JWT. `audiences`(Opcional, Lista) Valores de `aud` reivindicação aceitos (até 8). Pelo menos um dos `audiences` ou `requiredClaims` deve ser definido. `requiredClaims`(Opcional, Lista) Claim-based autorização (até 16 entradas). Cada entrada tem`name`, `valueType` (`String`ou`StringArray`) e `values` (1—128 entradas, cada 1—1024 caracteres). Quando definido, o gateway nega solicitações por padrão e admite somente tokens cujos valores de declaração correspondam. `observability` (Opcional) Configuração de observabilidade. Contém`metrics.enabled`, que controla o sidecar das OpenTelemetry métricas. As métricas são ativadas por padrão. `podDefaults` (Opcional) As configurações padrão do pod foram aplicadas aos pods Body-Based Router e Endpoint Picker. Suporta `resources` `nodeSelector``tolerations`,`affinity`,`labels`, `annotations``env`,, `envFrom` e. `schedulers`(Obrigatório, Lista) Uma lista de configurações de agendador por modelo, digitada por. `name` É necessário pelo menos um agendador e você pode definir até 100. Cada entrada é uma`SchedulerSpec`, descrita em[SchedulerSpec campos](#sagemaker-hyperpod-model-deployment-inference-gateway-scheduler). ### SchedulerSpec campos Cada entrada `spec.schedulers` configura o roteamento e a seleção de terminais para um modelo. Um agendador nomeia os recursos gerados`InferencePool`, o Endpoint Picker, o HttpRoute e os recursos. `EnvoyExtensionPolicy` `name`(Obrigatório, Cadeia de caracteres) O nome do agendador. Usado para nomear os recursos gerados`InferencePool`, o Endpoint Picker, o HttpRoute e os recursos. `EnvoyExtensionPolicy` Tamanho máximo: 63 caracteres. `modelSelector` (Obrigatório) Um seletor de rótulos do Kubernetes que seleciona os pods que servem o modelo para os quais esse agendador encaminha. `modelName`(Obrigatório, Cadeia de caracteres) O nome do modelo correspondeu ao `model` campo no corpo da solicitação e foi usado como a correspondência do cabeçalho HttpRoute. Deve ser exclusivo em todos os agendadores. Tamanho máximo: 253 caracteres. `targetPort` (opcional, inteiro) A porta nos pods que servem o modelo que recebe tráfego encaminhado. Intervalo: 1—65535. Padrão: `8000`. `appProtocol`(Opcional, Cadeia de caracteres) O protocolo do aplicativo usado para acessar os pods que servem o modelo. Valores válidos: `http`, `kubernetes.io/h2c`. Padrão: `http`. `scheduler`(Opcional, Cadeia de caracteres) O tipo de agendador, que seleciona a imagem do Endpoint Picker. Valores válidos: `llm-d`, `epp`. Padrão: `llm-d`. `engineType`(Opcional, Cadeia de caracteres) O mecanismo de inferência em execução nos pods que servem o modelo. Esse valor seleciona o conjunto de nomes de métricas do Prometheus que o Endpoint Picker coleta. Valores válidos: `vllm`, `sglang`. Padrão: `vllm`. `weights` (Opcional) Pesos de pontuação que o Endpoint Picker usa para classificar os pods de candidatos. Todos os pesos são números inteiros não negativos. Mutuamente exclusivo com `configMapRef`. Pesos suportados: `queue` Peso da profundidade da fila de solicitações pendentes. Padrão: `2`. `kvCache` Peso para utilização do cache de KV. Padrão: `2`. `prefix` Peso da afinidade entre prefixo e cache. Padrão: `3`. `lru` Peso para a pontuação usada menos recentemente. Válido somente quando `scheduler` é `llm-d`. `loraAffinity` Peso para afinidade com o adaptador LoRa. `runningRequests` Peso para o número de solicitações em execução em um pod. `predictedLatency` Peso da latência prevista da solicitação. `configMapRef` (Opcional) Uma referência a um ConfigMap que fornece uma configuração personalizada do Endpoint Picker, como alternativa a. `weights` Contém um obrigatório `name` e um `key` (padrão:`default-plugins.yaml`). Mutuamente exclusivo com `weights`. `replicas` (opcional, inteiro) Número de réplicas do Endpoint Picker para esse agendador. Mínimo:`1`. Padrão: `2`. Quando `replicas` é maior que 1, o Endpoint Picker é executado em alta disponibilidade com eleição de líder. `env`e `envFrom` (Opcional) Variáveis de ambiente anexadas ao contêiner do Endpoint Picker desse agendador. `loraAdapters`(Opcional, Lista) Os nomes dos adaptadores LoRa serviram por trás do modelo desse agendador. Máximo: 50 itens, cada um com até 253 caracteres. `routeTimeout`(Opcional, Cadeia de caracteres) O tempo limite da solicitação HttpRoute, como duração da API Gateway (por exemplo, `30s` ou). `5m` Defina como `0s` para desativar o tempo limite. `logLevel` (opcional, inteiro) A verbosidade do registro do Endpoint Picker. Intervalo: 0—5. ### Regras de validação O `InferenceGatewayConfig` recurso impõe as seguintes regras de validação. Um recurso que viole qualquer uma dessas regras é rejeitado. + O Body-Based roteador deve estar ativado (`bbr.enabled: true`) quando mais de um agendador estiver configurado. + `modelName`deve ser exclusivo em todos os agendadores. + Dentro de um agendador, `weights` e `configMapRef` são mutuamente exclusivos. + O `weights.lru` peso é válido somente quando o `scheduler` tipo do programador é`llm-d`. ### campos de status O controlador relata o estado observado do gateway no `status` sub-recurso. `conditions` Condições padrão do Kubernetes que descrevem o estado geral da configuração do gateway. `schedulers` Per-scheduler status. Cada entrada contém: `name` O nome do agendador. `conditions` Condições que descrevem o estado desse agendador. `currentScheduler` O tipo de agendador atualmente em vigor para essa entrada. `rolloutState` O estado de implantação do agendador. Um destes: `Pending`, `Progressing`, `Available` ou `Degraded`. `observedGeneration` A geração do recurso reconciliado mais recentemente pelo controlador. `tls` Status do TLS, relatado somente no modo de emissão automática. Contém `acmArn``issuedAt`, `dnsNames` e. ## Permissões RBAC do Kubernetes O Inference Gateway é executado como um único controlador sob a conta `inference-gateway-controller` de serviço Kubernetes no namespace. `hyperpod-inference-system` O Body-Based roteador, os selecionadores de endpoint por agendador, o controlador de gateway e o `InferenceGatewayConfig` reconciliador são executados sob esse único controlador. Suas permissões com escopo de cluster são concedidas por um `ClusterRole` nome `sagemaker-inference-gateway-controller-supplement` e um correspondente. `ClusterRoleBinding` Juntos, eles complementam a conta de serviço e as permissões que o gráfico do Gateway incluído já fornece. Essas permissões têm escopo e privilégios mínimos, e o controlador não é executado como administrador do cluster. A tabela a seguir lista as permissões com escopo de cluster do controlador, agrupadas por finalidade. Nesta tabela, acesso * total * significa os `delete` verbos `create` `get``list`, `watch``update`,`patch`,,, e. **Permissões do controlador do Inference Gateway** | Grupo de APIs | Recursos | Verbos | Finalidade | | --- | --- | --- | --- | | inference.sagemaker.aws.amazon.com | inferencegatewayconfigs, incluindo seus status e seus finalizers sub-recursos | get,list,watch,update, e patch parainferencegatewayconfigs; getupdate, e patch para seustatus; update para seu finalizers | Reconcilie o InferenceGatewayConfig recurso, escreva seu status e gerencie seu finalizador. | | gateway.networking.k8s.io | httproutes, gateways, gatewayclasses | Acesso total para httproutes egateways; getlist,watch,create, e patch para gatewayclasses | Roteamento de solicitações de programas por meio da API Gateway. | | inference.networking.k8s.io | inferencepools | Acesso total. | Crie o back-end de roteamento para cada agendador. | | inference.networking.x-k8s.io | inferencepools, inferenceobjectives, inferencemodelrewrites | get, list, watch | Leia a intenção de roteamento para seleção de terminais. | | gateway.envoyproxy.io | envoyextensionpolicies, envoyproxies, httproutefilters, clienttrafficpolicies, securitypolicies | Acesso total. | Configure o plano de dados do gateway e sua telemetria. | | Núcleo ("") | configmaps, services, serviceaccounts, events, secrets, pods | Acesso total paraconfigmaps,services, eserviceaccounts; create e patch paraevents; getlist, e watch para secrets e pods | Gerencie as cargas de trabalho geradas e leia o roteamento e o estado do serviço. | | apps | deployments | Acesso total. | Gerencie as implantações do Body-Based roteador e do seletor de terminais. | | rbac.authorization.k8s.io | roles, rolebindings | Acesso total. | Crie o Endpoint Picker por agendador. Role | | discovery.k8s.io, coordination.k8s.io | endpointslices; leases | get,list, e watch paraendpointslices; getlist, watchcreate,update, e patch para leases | Descoberta de endpoints e eleição de líder do Endpoint Picker. | | networking.k8s.io | ingresses, networkpolicies | Acesso total. | Provisione o caminho do Application Load Balancer por meio do AWS Load Balancer Controller. | | cert-manager.io | issuers, certificates (com getlist, e watch no núcleosecrets) | Acesso total. | Auto-issue um certificado TLS quando spec.tls definido sem umacmArn. | | apiextensions.k8s.io | customresourcedefinitions | create; eget, updatepatch, e delete restritos pelo nome do recurso aos CRDs específicos da API do Gateway que o gateway gerencia | Instale as definições de recursos personalizados das quais o gateway depende. | **nota** O `create` verbo on não `customresourcedefinitions` está restrito a nomes de recursos específicos. O controlador instala as definições de recursos personalizados da API Gateway das quais depende aplicando-as na inicialização a partir de sua própria imagem de contêiner, pois seu tamanho combinado excede o limite de carga útil do complemento Amazon EKS. O Kubernetes não permite que o `create` verbo seja restrito a recursos nomeados, portanto, essa permissão é necessariamente ampla. Todas as outras operações nas definições de recursos personalizados —`get`, `update``patch`, e `delete` — são restritas às definições específicas de recursos personalizados que o gateway gerencia. Essa permissão permite definir somente esses tipos de CRD; ela não concede acesso aos dados de nenhum recurso personalizado. O controlador também cria as seguintes funções com namespace em tempo de execução, dependendo da configuração do gateway: + *Body-Based Roteador * — Um namespace `Role` que concede e `get` `watch` ativa `list` que o roteador lê para `configmaps` resolver adaptadores LoRa. Quando o roteador é executado em vários namespaces, isso é um `ClusterRole` substituto. + *Seletor de endpoint * — Um namespace que concede acesso de leitura a. `Role` `pods` Quando um Endpoint Picker é executado com mais de uma réplica, o controlador também cria uma eleição de líder `Role` para e. `leases` `events` Quando as métricas do Prometheus estão habilitadas, o controlador cria um opcional `ClusterRole` que `create` concede acesso ativo `tokenreviews` `subjectaccessreviews` e de leitura ao `/metrics` endpoint. **nota** Quando você ativa o gateway por meio do operador de HyperPod inferência, o próprio controlador do operador tem permissão para criar e atualizar `InferenceGatewayConfig` recursos. Para saber como o operador conecta um modelo ao gateway, consulte[Integração com o operador de HyperPod inferência](#sagemaker-hyperpod-model-deployment-inference-gateway-operator-integration). Algumas dessas permissões se aplicam somente quando o recurso correspondente está ativado. ## Observabilidade O Inference Gateway emite métricas do Prometheus de cada componente do gateway. Tanto o Body-Based roteador quanto cada seletor de endpoint expõem um endpoint padrão do Prometheus `/metrics` em seus pods. Body-Based Os pods do roteador são executados no `hyperpod-inference-system` namespace; os pods do Endpoint Picker são executados no mesmo namespace do. `InferenceGatewayConfig` As métricas abrangem contadores e durações de solicitações por modelo, latência de agendamento e tempo de execução por plug-in dentro do Endpoint Picker e métricas agregadas do pool, como utilização média do cache KV e profundidade da fila. Model-server As métricas do pod (por exemplo, do vLLm ou do SGLang) são emitidas pelo próprio servidor do modelo; o Endpoint Picker as coleta para pontuar os pods candidatos. Quando `spec.observability.metrics.enabled` é `true` (o padrão), o controlador do gateway injeta um sidecar OpenTelemetry Collector em cada pod do Body-Based roteador e do Endpoint Picker. O sidecar encaminha essas métricas para a pilha de observabilidade de HyperPod inferência, onde os painéis integrados do Grafana as apresentam junto com as métricas do servidor de modelos e do cluster. Para obter detalhes sobre a configuração e o painel, consulte[Implementando a observabilidade da inferência em clusters HyperPod](sagemaker-hyperpod-model-deployment-observability.md). Defina o campo como `false` para ignorar a injeção lateral. Para obter a referência de campo, veja `observability` abaixo[campos de especificação](#sagemaker-hyperpod-model-deployment-inference-gateway-spec). Para visualizar as métricas do gateway no Amazon Managed Grafana, abra a * pasta * Inference Dashboards e selecione o painel * Inference Gateway. * O painel relata a disponibilidade em todo o gateway, a taxa de solicitação e a latência de ponta a ponta, a taxa de transferência, a latência e os erros por agendador para cada modelo, e a taxa na qual o roteador resolve nomes de modelos dos corpos de solicitação. Body-Based ## Exemplos Os exemplos a seguir mostram `InferenceGatewayConfig` configurações comuns e como invocar o gateway. ### Configuração mínima de vários modelos Este exemplo é roteado para um agendador llm-d com TLS emitido automaticamente. Como `tls` está definido como um objeto vazio, o gateway emite automaticamente um certificado e o importa para o 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 ``` ### Agendador SGLang com pesos explícitos Este exemplo usa o tipo de `epp` agendador com o `sglang` mecanismo e define pesos de pontuação explícitos do 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 ``` ### adaptador LoRa ConfigMap O Body-Based roteador descobre os adaptadores LoRa e seu modelo básico a partir de um ConfigMap rótulo para gerenciamento de BBR. O roteador usa esse mapeamento para resolver um nome de adaptador no corpo da solicitação para seu modelo básico. ``` 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 ``` ### Invoque o gateway O gateway serve como um endpoint de OpenAI-compatible inferência. Esse é o contrato de invocação em tempo de execução para enviar solicitações de inferência pelo gateway; não é uma AWS operação de API. Envie solicitações para o endpoint do gateway com o `model` campo definido como o do agendador `modelName` de destino. O Body-Based roteador lê esse campo para rotear a solicitação. ``` 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"} ] }' ```