Novas capacidades do Amazon SageMaker HyperPod para inferência empresarial: captura de dados, Hugging Face, NVMe e Route 53

Inferência empresarial no SageMaker HyperPod: o que mudou

À medida que as organizações escalam suas cargas de trabalho de IA generativa, cresce também a demanda por infraestrutura de inferência mais rápida, observável e flexível. A AWS respondeu a esse desafio com um conjunto de novas capacidades no Amazon SageMaker HyperPod, voltadas para simplificar como equipes implantam e operam modelos de grande porte em produção.

As novidades cobrem cinco frentes: captura de dados em múltiplos níveis da cadeia de inferência, deploy direto a partir do Hugging Face Hub, carregamento de pesos via armazenamento NVMe local, gerenciamento automatizado de registros DNS com o Amazon Route 53 e controle granular de permissões por pod via contas de serviço personalizadas.

Captura de dados de inferência em múltiplas camadas

O recurso de captura de dados do HyperPod permite registrar as requisições e respostas de inferência para fins de monitoramento, depuração e melhoria de modelos. O fluxo de uma requisição passa pelo endpoint do SageMaker AI, depois pelo Balanceador de Carga de Aplicação (ALB) e, por fim, chega ao pod do modelo. Cada camada pode ser configurada de forma independente, oferecendo flexibilidade para escolher o nível de visibilidade adequado para cada caso de uso.

Pré-requisitos

Para habilitar a captura de dados, é necessário ter um bucket do Amazon S3 (com URI no formato s3://amzn-s3-demo-bucket ou s3://amzn-s3-demo-bucket/prefix) e as permissões de Gerenciamento de Identidade e Acesso (IAM) corretas para que o operador possa gravar nele. Caso nenhum URI seja informado, o sistema utiliza o bucket do certificado TLS como destino padrão. A AWS também recomenda o uso de uma chave do Serviço de Gerenciamento de Chaves (AWS KMS) para criptografar os dados capturados.

As três camadas de captura

A captura de dados suporta três camadas, cada uma registrando em um ponto diferente do fluxo:

• Camada 1 – Endpoint do SageMaker AI ({s3Uri}/{hash}/sme/): captura os payloads completos de entrada e saída na fronteira da API do SageMaker AI Runtime. Indicada para compatibilidade com o SageMaker AI Model Monitor.
• Camada 2 – Balanceador de Carga de Aplicação (ALB) ({s3Uri}/{hash}/alb/): ativa os logs de acesso do ALB, que registram metadados como IPs de clientes, caminhos de requisição e latências.
• Camada 3 – Pod do modelo ({s3Uri}/{hash}/pod/): captura os payloads completos diretamente no contêiner de inferência, com amostragem, buffer e limites de tamanho configuráveis. Funciona sem registro de endpoint do SageMaker AI — ideal para quem precisa da visibilidade mais próxima possível do modelo.

Configurando a captura de dados

A captura é habilitada adicionando uma seção dataCapture ao recurso personalizado de definição (CRD) InferenceEndpointConfig ou JumpStartModel. O exemplo abaixo mostra a estrutura completa com as três camadas ativas:

dataCapture:
  s3Uri: s3://amzn-s3-demo-bucket/captures/ # Optional. Defaults to TLS bucket.
  sagemakerEndpoint:
    enabled: true
    initialSamplingPercentage: 100
    kmsKeyId: arn:aws:kms:us-east-2:123456789012:key/my-key-id
    captureOptions:
      - captureMode: Input
      - captureMode: Output
    captureContentTypeHeader:
      jsonContentTypes:
        - application/json
  loadBalancer:
    enabled: true
  modelPod:
    enabled: true
    initialSamplingPercentage: 100
    kmsKeyId: arn:aws:kms:us-east-2:123456789012:key/my-key-id
    captureOptions:
      - captureMode: Input
      - captureMode: Output
    bufferConfig:
      batchSize: 100
      flushIntervalSeconds: 60
    payloadConfig:
      maxPayloadSizeKB: 1024

Permissões IAM necessárias

Para habilitar a captura em clusters existentes, é preciso adicionar a seguinte permissão ao papel de execução do Operador de Inferência:

{
  "Sid": "DataCaptureS3Access",
  "Effect": "Allow",
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::hyperpod-tls*/data-capture/*",
  "Condition": {
    "StringEquals": {
      "aws:ResourceAccount": "${aws:PrincipalAccount}"
    }
  }
}

Se for utilizada uma chave KMS gerenciada pelo cliente, adicione também:

{
  "Sid": "DataCaptureKmsAccess",
  "Effect": "Allow",
  "Action": [
    "kms:Decrypt",
    "kms:GenerateDataKey"
  ],
  "Resource": "arn:aws:kms:*:*:key/*",
  "Condition": {
    "StringLike": {
      "kms:ViaService": "s3.*.amazonaws.com",
      "kms:EncryptionContext:aws:s3:arn": "arn:aws:s3:::hyperpod-tls*"
    },
    "StringEquals": {
      "aws:ResourceAccount": "${aws:PrincipalAccount}"
    }
  }
}

Para mais detalhes, consulte a documentação de captura de dados para inferência no HyperPod.

Deploy direto a partir do Hugging Face Hub

O HyperPod agora permite implantar modelos diretamente do Hugging Face Hub, sem a necessidade de pré-carregar os pesos no Amazon S3 ou no Amazon FSx. Essa integração suporta modelos restritos (gated) via tokenSecretRef, fixação de revisões via commitSHA e isolamento de tokens. É compatível com os runtimes vLLM, TGI e SGLang. Consulte como fazer deploy de modelos a partir do S3, FSx ou Hugging Face Hub com kubectl para mais detalhes.

Passos para implantar um modelo do Hugging Face

Primeiro, crie um Kubernetes Secret com o token da API do Hugging Face. Esse token é obrigatório para modelos restritos e recomendado para todos os downloads. Você pode gerar um token em huggingface.co/settings/tokens.

kubectl create secret generic hf-token-secret --from-literal=token=hf_YOUR_TOKEN_HERE \
  -n $CLUSTER_NAMESPACE

Em seguida, defina o nome do endpoint do SageMaker:

export SAGEMAKER_ENDPOINT_NAME="mistral7b-hf"

Monte o YAML de deploy. Para o YAML completo, consulte a seção Hugging Face em Deploy models from Amazon S3, Amazon FSx, or Hugging Face Hub using kubectl:

modelName: mistral-7b
modelSourceConfig:
  modelSourceType: huggingface
  prefetchEnabled: true
  huggingFaceModel:
    modelId: "mistralai/Mistral-7B-Instruct-v0.3"
    tokenSecretRef:
      name: hf-token-secret
      key: token
instanceType: "ml.g5.24xlarge"

Aplique o arquivo com o kubectl:

kubectl apply -f deploy_hf_inference.yaml

Verifique o status do deploy e do endpoint criado:

kubectl describe InferenceEndpointConfig $SAGEMAKER_ENDPOINT_NAME -n $CLUSTER_NAMESPACE
kubectl describe SageMakerEndpointRegistration $SAGEMAKER_ENDPOINT_NAME -n $CLUSTER_NAMESPACE

Para depurar erros, verifique os eventos do Kubernetes:

kubectl get events -n $CLUSTER_NAMESPACE

Para testar o endpoint implantado:

aws sagemaker-runtime invoke-endpoint \
  --endpoint-name $SAGEMAKER_ENDPOINT_NAME \
  --content-type "application/json" \
  --body '{"inputs": "What is AWS SageMaker?"}' \
  --region $REGION \
  --cli-binary-format raw-in-base64-out \
  /dev/stdout

Gerenciamento de DNS com o Route 53

O SageMaker HyperPod agora se integra ao Amazon Route 53 para criar e gerenciar automaticamente registros DNS para os endpoints de inferência. Basta especificar um ID de zona hospedada no CRD e o operador cuida da criação, atualização e remoção dos registros para o domínio personalizado.

Pré-requisitos

• Um certificado do Gerenciador de Certificados da AWS (ACM) no estado Issued cobrindo o domínio desejado.
• Uma zona hospedada no Route 53 para esse domínio.
• As permissões IAM corretas adicionadas ao papel de execução do Operador de Inferência.

Permissões IAM para o Route 53

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ACMCustomCertificateAccess",
      "Effect": "Allow",
      "Action": [
        "acm:DescribeCertificate",
        "acm:GetCertificate"
      ],
      "Resource": "arn:aws:acm:<region>:<account-id>:certificate/*"
    },
    {
      "Sid": "S3CertificateUpload",
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:PutObjectTagging"
      ],
      "Resource": "arn:aws:s3:::<tls-certificate-bucket>/*",
      "Condition": {
        "StringEquals": {
          "s3:RequestObjectTag/CreatedBy": "HyperPodInference"
        }
      }
    },
    {
      "Sid": "Route53DNSManagement",
      "Effect": "Allow",
      "Action": [
        "route53:GetHostedZone",
        "route53:ListResourceRecordSets",
        "route53:ChangeResourceRecordSets"
      ],
      "Resource": "arn:aws:route53:::hostedzone/<hosted-zone-id>"
    }
  ]
}

Configurando o gerenciamento de DNS

Habilite o Route 53 adicionando as seções tlsConfig e dnsConfig ao YAML de deploy do modelo:

tlsConfig:
  customCertificateConfig:
    acmArn: arn:aws:acm:us-west-2:123456789012:certificate/abc12345-1234-1234-1234-abc123456789
    domainName: api.example.com
    tlsCertificateOutputS3Uri: s3://my-tls-bucket
dnsConfig:
  hostedZoneId: Z1234567890ABC

O domainName deve corresponder a um domínio coberto pelo certificado ACM. Para certificados wildcard (por exemplo, *.example.com), especifique o subdomínio exato (por exemplo, api.example.com).

Para verificar o status do DNS:

kubectl describe InferenceEndpointConfig my-model -n my-namespace

Verifique a seção dnsStatus. Quando o campo Dns Health mostrar Active, o endpoint estará acessível pelo domínio personalizado. Para mais informações, consulte a documentação sobre certificados personalizados e gerenciamento de DNS com Route 53 para o HyperPod Inference.

Carregamento de modelos via NVMe local

O SageMaker HyperPod agora suporta o carregamento de pesos de modelos diretamente do armazenamento NVMe local do nó, em vez de transferi-los pela rede a partir do S3 ou do FSx. Ao eliminar o salto de rede durante a inicialização do pod, essa abordagem reduz significativamente o tempo de cold-start. É especialmente útil em eventos de autoescalonamento, cargas de trabalho scale-from-zero e failovers sensíveis à latência. O armazenamento NVMe local está disponível tipicamente nas famílias de instâncias P, G e Trn.

Passos para implantar um modelo a partir do NVMe

Antes de tudo, certifique-se de que os pesos do modelo estão pré-carregados no armazenamento NVMe local dos nós de destino. Em seguida, monte o YAML de deploy. Para o YAML completo, consulte como fazer deploy de modelos a partir do armazenamento NVMe local com kubectl:

spec:
  modelSourceConfig:
    modelSourceType: kubernetesVolume
    kubernetes:
      volumes:
        - name: model-weights
          hostPath:
            path: /opt/dlami/nvme/<YOUR_MODEL>
            type: Directory
  worker:
    modelVolumeMount:
      name: model-weights
      mountPath: /opt/ml/model

Aplique o arquivo com o kubectl:

kubectl apply -f deploy_nvme_k8s_volume.yaml

Verifique o status do deploy:

kubectl describe InferenceEndpointConfig nvme-k8s-volume -n $CLUSTER_NAMESPACE

Contas de serviço personalizadas com permissões por pod

Por padrão, os pods de inferência usam a ServiceAccount padrão do namespace. Para cargas de trabalho que precisam de credenciais AWS — como o download de pesos do S3 em um initContainer de fallback — é possível atribuir uma ServiceAccount personalizada com suporte a IRSA (Funções IAM para Contas de Serviço).

Habilitando o suporte a contas de serviço personalizadas

Esse recurso permanece desativado por padrão. Um administrador do cluster deve habilitá-lo:

helm upgrade hyperpod-inference-operator <CHART_PATH> \
  --set enableCustomServiceAccounts=true \
  --reuse-values

Se o operador estiver implantado como um complemento (add-on) do Amazon EKS, atualize a configuração do add-on para incluir enableCustomServiceAccounts: true nas configurações avançadas.

Configurando uma conta de serviço personalizada

Crie uma ServiceAccount do Kubernetes anotada com o ARN do papel IRSA:

kubectl create sa my-inference-sa -n my-namespace
kubectl annotate sa my-inference-sa -n my-namespace \
  eks.amazonaws.com/role-arn=arn:aws:iam::<ACCOUNT_ID>:role/<ROLE_NAME>

Adicione o rótulo user-assignable à ServiceAccount. Apenas contas com esse rótulo podem ser referenciadas por endpoints de inferência — esse é um controle de segurança para evitar escalada não autorizada de privilégios:

kubectl label serviceaccount my-inference-sa \
  sagemaker.amazonaws.com/user-assignable=true \
  -n my-namespace

Referencie a ServiceAccount no InferenceEndpointConfig:

apiVersion: inference.sagemaker.aws.amazon.com/v1
kind: InferenceEndpointConfig
metadata:
  name: my-inference-endpoint
  namespace: my-namespace
spec:
  kubernetes:
    serviceAccountName: my-inference-sa

A AWS recomenda criar uma ServiceAccount dedicada por carga de trabalho de inferência, sem reutilização entre workloads não relacionadas. Os papéis IAM associados via IRSA devem ser escopados ao bucket S3 e prefixo específicos que contêm os pesos do modelo — evite políticas amplas como AmazonS3FullAccess.

Como começar

Para aproveitar todas essas capacidades, a AWS orienta atualizar o Operador de Inferência para a versão v3.2 e experimentar a adição de uma seção dataCapture ou dnsConfig a um deploy existente. As referências completas de configuração estão disponíveis na documentação oficial de cada funcionalidade.

Fonte

Enhancing enterprise inference on Amazon SageMaker HyperPod with data capture, Hugging Face, NVMe, and Route 53 integration (https://aws.amazon.com/blogs/machine-learning/enhancing-enterprise-inference-on-amazon-sagemaker-hyperpod-with-data-capture-hugging-face-nvme-and-route-53-integration/)