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 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, consulteInferenceGatewayConfig Referência CRD.

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, consulteNotas de lançamento do Amazon SageMaker HyperPod Inference.

Antes de rotear o tráfego pelo gateway, verifique o seguinte:

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).

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 <<EOF
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "Federated": "arn:aws:iam::${ACCOUNT}:oidc-provider/${OIDC_ID}"
    },
    "Action": "sts:AssumeRoleWithWebIdentity",
    "Condition": {
      "StringEquals": {
        "${OIDC_ID}:sub": "system:serviceaccount:hyperpod-inference-system:inference-gateway-controller",
        "${OIDC_ID}:aud": "sts.amazonaws.com"
      }
    }
  }]
}
EOF

Crie a função e anexe a política AmazonSageMakerHyperPodInferenceGatewayAccess gerenciada. A política concede ao ACM as permissões de que o controlador precisa para importar, marcar, descrever e excluir os certificados criados.

aws iam create-role --role-name $ROLE_NAME --assume-role-policy-document file://trust-policy.json
aws iam attach-role-policy --role-name $ROLE_NAME --policy-arn arn:aws:iam::aws:policy/AmazonSageMakerHyperPodInferenceGatewayAccess

Forneça o ARN dessa função como inferenceGateway.serviceAccount.roleArn quando você instala o complemento.

Instalar o complemento

O complemento HyperPod Inference instala o Inference Operator e o Inference Gateway. Instale-o com o comando a seguir. ParainferenceGateway.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::<ACCOUNT>:role/<EXEC_ROLE>",
    "tlsCertificateS3Bucket": "<TLS_BUCKET>",
    "inferenceOperator": { "enabled": true },
    "inferenceGateway": {
      "enabled": true,
      "serviceAccount": { "roleArn": "arn:aws:iam::<ACCOUNT>:role/<CERT_ISSUER_ROLE_NAME>" }
    },
    "keda": { "enabled": true, "auth": { "aws": { "irsa": { "enabled": true, "roleArn": "arn:aws:iam::<ACCOUNT>:role/<KEDA_IRSA_ROLE>" } } } },
    "alb": { "enabled": true, "serviceAccount": { "create": true, "roleArn": "arn:aws:iam::<ACCOUNT>:role/<ALB_IRSA_ROLE>" } },
    "jumpstartGatedModelDownloadRoleArn": "arn:aws:iam::<ACCOUNT>:role/<JUMPSTART_ROLE>"
  }'

Se o complemento já estiver instalado no cluster, create-addon substitua por update-addon e adicione--resolve-conflicts OVERWRITE. O resto do comando permanece inalterado. OVERWRITEaplica 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, consulteImplantação de modelos na Amazon SageMaker HyperPod.

Você anexa um modelo ao gateway por meio do operador, no recurso do modelo InferenceEndpointConfig (ouJumpStartModel), usando o spec.inferenceGateway campo:

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-<uuid>.

O operador espelha o estado do anexo no recurso do modelo abaixostatus.inferenceGateway, que relata um State de PendingReady,Failed, ou e o Name do anexoInferenceGatewayConfig. 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 agendadorname,, e modelNametargetPort, emodelSelector, 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:

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, consulteInstalando o operador de inferência com o complemento EKS. Para implantar os pods que servem modelos para os quais um programador encaminha, consulte. Implantar modelos de base e modelos personalizados e ajustados

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 PickerInferencePool, o HttpRoute e EnvoyExtensionPolicy os recursos subjacentes para cada agendador; você cria somente o recurso. InferenceGatewayConfig

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.

SchedulerSpec campos

Cada entrada spec.schedulers configura o roteamento e a seleção de terminais para um modelo. Um agendador nomeia os recursos geradosInferencePool, o Endpoint Picker, o HttpRoute e os recursos. EnvoyExtensionPolicy

Regras de validação

O InferenceGatewayConfig recurso impõe as seguintes regras de validação. Um recurso que viole qualquer uma dessas regras é rejeitado.

campos de status

O controlador relata o estado observado do gateway no status sub-recurso.

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 getlist, watchupdate,patch,,, e.

O controlador também cria as seguintes funções com namespace em tempo de execução, dependendo da configuração do gateway:

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, consulteImplementando a observabilidade da inferência em clusters HyperPod. Defina o campo como false para ignorar a injeção lateral. Para obter a referência de campo, veja observability abaixocampos de especificação.

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