Blog

O problema do cold start em inferência de LLMs

Quem trabalha com implantação de Modelos de Linguagem de Grande Escala (LLMs) no Amazon SageMaker HyperPod conhece bem a frustração do cold start: você solicita um pod, mas ele só começa a responder requisições depois de um longo tempo de espera. Esse atraso é dominado por duas etapas sequenciais de download que acontecem toda vez que um pod sobe.

A primeira etapa é o download da imagem de contêiner do servidor de inferência a partir do Registro de Contêineres Elástico da Amazon (Amazon ECR). Imagens de servidores como vLLM ou LMI são volumosas — múltiplos gigabytes — porque empacotam drivers de GPU, bibliotecas CUDA e o próprio framework de serving. Esse processo costuma levar de 5 a 7 minutos.

A segunda etapa, e geralmente a mais demorada, é o download dos pesos do modelo a partir da fonte de armazenamento configurada, que pode ser o Serviço de Armazenamento Simples da Amazon (Amazon S3), o Amazon FSx for Lustre ou o HuggingFace Hub. Para um modelo de 145 GB hospedado no S3, essa etapa pode consumir mais de 20 minutos. Para modelos ainda maiores, como o DeepSeek-R1 com mais de 600 GB, o tempo ultrapassa os 30 minutos.

O cenário piora durante eventos de escalonamento horizontal. Se um pico de tráfego acionar o Autoescalador Horizontal de Pods (HorizontalPodAutoscaler) para criar cinco novos pods simultaneamente, cada um deles passa pelo mesmo ciclo de download de forma independente. A política de autoscaling reage em segundos, mas o tráfego adicional só começa a ser atendido 25 a 30 minutos depois — porque cada pod fica bloqueado aguardando os downloads.

Cache de modelos: como a AWS resolve o problema

A AWS anunciou o lançamento do cache de modelos para inferência no SageMaker HyperPod. A ideia central é simples: pré-carregar os pesos do modelo e a imagem de contêiner nos nós do cluster antes que os pods precisem deles. Quando o pod sobe, ele lê os dados do armazenamento NVMe local — a velocidades de aproximadamente 7 GB/s — em vez de baixar tudo pela rede. O resultado prático é que pods que antes levavam dezenas de minutos para iniciar passam a estar prontos em segundos.

O recurso introduz duas capacidades independentes que podem ser habilitadas juntas ou separadamente.

Cache de pesos (Weights Cache)

O cache de pesos baixa os pesos do modelo para o armazenamento NVMe local de cada nó com antecedência. O fluxo funciona assim:

• Você adiciona a seção modelCacheConfig com weightsCache habilitado ao seu recurso InferenceEndpointConfig ou JumpStartModel e aplica a configuração.
• O Operador de Inferência do HyperPod cria automaticamente um recurso ModelDataCacheConfig e inicia o download dos pesos a partir da fonte configurada (S3, FSx for Lustre, HuggingFace Hub ou JumpStart) para o NVMe local de todos os nós alvo.
• Após o download ser concluído em um nó, o operador marca esse nó como cache-ready (cache pronto).
• O operador aguarda que todos os nós alvo estejam marcados como prontos antes de criar o deployment de inferência, garantindo que os pods sempre encontrem os dados localmente disponíveis.
• O cache persiste entre reinicializações de pods no mesmo nó. Durante eventos de escalonamento, novos pods que forem alocados em nós com o cache já populado iniciam imediatamente.

Cache de imagem (Image Cache)

O cache de imagem realiza o pré-download da imagem de contêiner do servidor de inferência nos nós, eliminando a espera pelo pull do ECR. O comportamento é ligeiramente diferente do cache de pesos:

• O operador cria um DaemonSet que baixa a imagem de contêiner em todos os nós alvo.
• Ao contrário do cache de pesos, o cache de imagem não bloqueia a criação do deployment — ele é criado imediatamente.
• Se um pod iniciar antes que o cache de imagem esteja completo naquele nó, o pull acontece normalmente pelo ECR, sem falhas.
• Múltiplos deployments que usam a mesma imagem de contêiner compartilham um único recurso de cache de imagem. O operador rastreia as referências e só remove o cache quando nenhum deployment o referencia mais.

Comportamento de fallback

Ambas as capacidades utilizam agendamento preferencial, não obrigatório. Os pods preferem nós com cache disponível, mas nunca ficam bloqueados por isso. Se um pod for alocado em um nó sem cache — por exemplo, durante um escalonamento rápido que supera o número de nós com cache populado — ele baixa os pesos normalmente do S3 ou FSx e puxa a imagem do ECR. Não há falha, não há intervenção manual necessária e o comportamento é idêntico ao de um pod rodando sem cache habilitado.

Arquitetura e recursos customizados (CRDs)

O operador introduz dois Recursos de Definição Customizada (CRDs) para gerenciar o ciclo de vida do cache. Eles são criados e gerenciados automaticamente — você não precisa criá-los diretamente.

O ModelDataCacheConfig gerencia o ciclo de vida completo do cache de pesos: controla o download para o NVMe local, marca os nós como prontos, monitora a saúde do cache e realiza a limpeza quando o recurso pai é deletado. Você pode inspecionar o estado do cache a qualquer momento:

kubectl get modeldatacacheconfig -n <namespace>
NAME                  STATE   TARGET   READY   AGE
example-model-cache   Ready   10       10      5m

O ModelImageCache gerencia o ciclo de vida do cache de imagens: controla o pré-download da imagem nos nós, relata o status por nó e realiza a limpeza quando nenhum deployment referencia mais o cache.

kubectl get inferenceimagecache -n hyperpod-inference-system
NAME                                      PHASE      CACHED   TARGET   AGE
iic-vllm-openai-ml-g5-24xlarge-a1b2      Complete   10       10       3m

Quando você altera a fonte do modelo — por exemplo, apontando para um novo caminho no S3 com pesos atualizados — o operador cria um novo cache, implanta o deployment atualizado e só então remove o cache antigo. O mesmo se aplica a mudanças de imagem, garantindo transições sem downtime e sem dados desatualizados.

Como habilitar o cache de modelos

Para ativar o recurso, basta adicionar a seção modelCacheConfig ao seu recurso InferenceEndpointConfig ou JumpStartModel existente. Nenhuma infraestrutura adicional é necessária.

Exemplo com InferenceEndpointConfig:

apiVersion: inference.sagemaker.aws.amazon.com/v1
kind: InferenceEndpointConfig
metadata:
  name: example-model
  namespace: default
spec:
  modelName: example-model
  modelSourceConfig:
    modelSourceType: s3
    s3Storage:
      bucketName: example-bucket
      region: us-west-2
      modelLocation: "models/example-model"
  modelCacheConfig:
    weightsCache:
      enabled: true
    imageCache:
      enabled: true
  instanceType: ml.g5.24xlarge
  worker:
    image: vllm/vllm-openai:latest
    modelInvocationPort:
      containerPort: 8000
    modelVolumeMount:
      name: model-weights
      mountPath: /opt/ml/model
    resources:
      limits:
        nvidia.com/gpu: "4"

Exemplo com JumpStartModel:

apiVersion: inference.sagemaker.aws.amazon.com/v1
kind: JumpStartModel
metadata:
  name: example-jumpstart-model
  namespace: default
spec:
  model:
    modelId: "meta-textgeneration-llama-3-1-8b-instruct"
    acceptEula: true
  server:
    instanceType: ml.g5.24xlarge
    modelCacheConfig:
      weightsCache:
        enabled: true
      imageCache:
        enabled: true

Você pode habilitar cada capacidade de forma independente. Se quiser apenas o cache de imagem, basta omitir weightsCache ou defini-lo como false. O cache de pesos também suporta um override opcional de hostPath caso você queira usar um caminho de montagem NVMe diferente do padrão (/opt/dlami/nvme). Quando configurado via SageMaker JumpStart, a configuração é mantida em cada deployment originado dali.

Fontes de modelo suportadas

O cache de modelos funciona com todas as fontes de modelo suportadas pelo HyperPod Inference:

• Amazon S3 — cache de pesos e cache de imagem suportados
• Amazon FSx for Lustre — cache de pesos e cache de imagem suportados
• HuggingFace Hub — cache de pesos e cache de imagem suportados
• Amazon SageMaker JumpStart (não bloqueado) — cache de pesos e cache de imagem suportados
• Amazon SageMaker JumpStart (bloqueado) — cache de pesos e cache de imagem suportados

Benchmarks

Os resultados divulgados pela AWS mostram ganhos expressivos. Em modelos entre 57 e 145 GB, o cache de pesos proporcionou cerca de 60% de redução no tempo de escalonamento. O cache de imagem eliminou mais de dois minutos do tempo de pull de imagem, representando uma redução de até 97% em comparação com o pull direto do ECR a cada inicialização de pod.

O benefício cresce proporcionalmente ao tamanho do modelo, já que há mais dados que precisariam ser baixados pela rede. Para modelos acima de 600 GB, como o DeepSeek-R1, o cache elimina o que seria um download de mais de 30 minutos.

Armazenamento de instância e limitações importantes

Como o cache de modelos armazena os pesos no NVMe local, o tipo de instância precisa ter capacidade de armazenamento suficiente para o modelo. A AWS disponibiliza a seguinte referência:

• ml.g5.xlarge — 250 GB de NVMe
• ml.g5.12xlarge — 3.800 GB de NVMe
• ml.g5.48xlarge — 7.600 GB de NVMe
• ml.p4d.24xlarge — 8.000 GB de NVMe
• ml.p5.48xlarge — 30.000 GB de NVMe

Há algumas limitações que vale conhecer antes de adotar o recurso:

• Cache por nó: cada nó mantém sua própria cópia dos pesos do modelo. O consumo de NVMe escala com o número de nós.
• Download inicial obrigatório: na primeira vez que o cache é habilitado para um modelo, o download da fonte remota ainda acontece. Após isso, os pods naqueles nós partem do armazenamento local.
• Capacidade finita: se o modelo tem 300 GB e o tipo de instância oferece apenas 250 GB de NVMe, o cache não funcionará. Escolha o tipo de instância considerando o tamanho do modelo.
• Atualizações não são detectadas automaticamente: se você atualizar os arquivos do modelo no mesmo caminho do S3 sem alterar o spec do InferenceEndpointConfig, o operador continuará servindo a versão em cache. Para capturar os novos pesos, atualize o spec — por exemplo, alterando o caminho do modelo ou adicionando um sufixo de versão.

Limpeza automática

Quando você deleta o recurso InferenceEndpointConfig ou JumpStartModel, o operador remove automaticamente todos os dados em cache, DaemonSets e labels de nós do cluster. Nenhuma limpeza manual é necessária e o armazenamento NVMe fica disponível para outras cargas de trabalho.

Disponibilidade

O cache de modelos para inferência no Amazon SageMaker HyperPod está disponível de forma geral em todas as regiões onde o SageMaker HyperPod opera. Para começar a usar, basta adicionar a seção modelCacheConfig ao spec do seu deployment existente e aplicar a configuração — o operador cuida do restante. Para a documentação completa, consulte a documentação do SageMaker HyperPod Inference.

Fonte

Reduce inference cold starts on Amazon SageMaker HyperPod with model caching (https://aws.amazon.com/blogs/machine-learning/reduce-inference-cold-starts-on-amazon-sagemaker-hyperpod-with-model-caching/)

O que foi anunciado

A AWS anunciou a integração entre o AWS Lambda Durable Functions e o Pydantic AI, framework open source para construção de agentes de Inteligência Artificial (IA) em Python. A novidade foi divulgada em setembro de 2026 e está disponível em todas as regiões da AWS onde o Lambda Durable Functions já opera.

Como a integração funciona

O AWS Lambda Durable Functions passa a salvar automaticamente o progresso do agente Pydantic AI durante a execução. Isso significa que, se ocorrer uma interrupção — como um timeout — o agente retoma a execução a partir do último passo já concluído, em vez de começar tudo do zero.

Cada chamada de modelo e cada chamada de ferramenta feita pelo agente é tratada como um passo de execução durável. Ou seja, se a execução for interrompida no meio do caminho, os passos que já foram concluídos não são repetidos.

O ponto importante aqui é que o desenvolvedor não precisa escrever a lógica de checkpoint e retry por conta própria — a tolerância a falhas vem embutida na integração.

Por que isso importa na prática

A integração resolve dois problemas concretos que afetam agentes de IA em produção:

• Custo de reprocessamento: em fluxos que envolvem várias chamadas de modelo — como revisar um conjunto de documentos ou pesquisar um tema em múltiplas fontes — reiniciar a execução do zero significa pagar novamente pelos tokens já consumidos. Com a execução durável, apenas os passos pendentes são executados.
• Efeitos colaterais indesejados: retomar uma execução sem controle pode causar ações duplicadas, como cobrar um cliente duas vezes. A durabilidade evita esse tipo de problema ao garantir que cada passo seja executado exatamente uma vez.

Infraestrutura e disponibilidade

Por rodar sobre o AWS Lambda, a solução mantém o modelo serverless: sem servidores para gerenciar e com cobrança apenas pelo tempo de computação efetivamente utilizado. A integração pode ser usada em qualquer função Python que utilize o AWS Lambda Durable Functions.

Como começar

Para utilizar a integração, basta instalar o Pydantic AI e seguir as instruções disponíveis na página de durabilidade do AWS Lambda dentro da documentação oficial do Pydantic AI. Os detalhes técnicos da integração também estão disponíveis na referência do SDK de execução durável. Para uma visão mais ampla sobre o serviço, a AWS disponibiliza o guia do desenvolvedor e a página oficial do AWS Lambda.

Fonte

AWS Lambda durable functions integrates with Pydantic AI (https://aws.amazon.com/about-aws/whats-new/2026/09/aws-lambda-durable-pydantic-ai/)

O problema que ninguém quer resolver manualmente

Vídeos e imagens representam uma fatia enorme do conhecimento corporativo — e também uma das partes mais difíceis de pesquisar. Equipes de esportes, segurança, educação, mídia e varejo convivem diariamente com o desafio de encontrar momentos específicos em horas de gravação. Fazer isso hoje, de forma semântica (ou seja, pesquisando por significado e não por palavras-chave exatas), exige montar um pipeline complexo: transcrição de áudio, extração de frames, modelos de embedding, banco de dados vetorial, lógica de sincronização — tudo isso mantido e orquestrado pela própria equipe.

A AWS endereçou diretamente esse problema ao anunciar a disponibilidade geral do TwelveLabs Marengo Embed 3.0 como opção de modelo de embedding dentro do Amazon Bedrock Knowledge Bases.

O que é o Marengo Embed 3.0

O Marengo Embed 3.0 é um modelo de embedding multimodal desenvolvido pela TwelveLabs. Ele codifica conjuntamente vídeo, áudio, imagens e texto em um espaço vetorial compacto de 512 dimensões — o que significa que todos esses tipos de conteúdo são representados em um mesmo espaço de busca, permitindo que uma consulta em texto encontre resultados em vídeo, e vice-versa.

Com esse modelo disponível no Amazon Bedrock Knowledge Bases, a geração de embeddings multimodais passa a ser totalmente gerenciada. O serviço captura sinais visuais, textuais, de fala e de áudio em uma representação vetorial unificada, sem que o time de desenvolvimento precise se preocupar com a infraestrutura por trás disso.

Como funciona dentro do Amazon Bedrock Knowledge Bases

O Amazon Bedrock Knowledge Bases é um serviço gerenciado de Geração Aumentada por Recuperação (RAG — Retrieval Augmented Generation) que cuida de armazenamento, ingestão, embedding, re-ranking e recuperação de conteúdo. Ele suporta arquivos de vídeo (MP4, MOV), imagens (JPEG, PNG) e faixas de áudio, com conectores nativos para o Amazon Simple Storage Service (S3), SharePoint, Confluence e outros.

A combinação do Bedrock Knowledge Bases com o Marengo 3.0 — chamada de Managed Knowledge Bases (MKB Gerenciado) — automatiza toda a cadeia: segmentação do conteúdo, amostragem de frames, transcrição de áudio e geração de embeddings para cada segmento, com os vetores escritos diretamente no índice.

Passo a passo: criando uma knowledge base com Marengo 3.0

A AWS publicou um walkthrough completo usando um clipe de 10 minutos da final da Copa do Mundo FIFA 2022 como exemplo prático. Veja como o fluxo funciona:

1. Prepare os arquivos de mídia

Faça o upload dos arquivos de vídeo para um bucket do Amazon S3. Nenhum pré-processamento é necessário — o MKB Gerenciado cuida internamente da segmentação, amostragem de frames e transcrição.

2. Crie a knowledge base gerenciada

No console do Amazon Bedrock, acesse a seção Knowledge Bases e selecione a opção de criar uma KB Gerenciada. Nas configurações adicionais, o modelo de embedding padrão é o Amazon Titan Text — basta alterar para o TwelveLabs/Marengo Embed 3.0. Em seguida, configure a fonte de dados apontando para o bucket S3 com os arquivos de vídeo.

Nas configurações avançadas, é possível ajustar a duração dos segmentos de áudio e vídeo. O padrão é de 4 segundos para ambas as modalidades.

3. Sincronize e ingira os dados

Após criar a knowledge base, basta iniciar o processo de sincronização. O MKB Gerenciado extrai os frames, transcreve o áudio, gera os embeddings com o Marengo 3.0 para cada segmento e grava os vetores no índice automaticamente.

4. Execute buscas semânticas

A busca pode ser testada diretamente pelo console, sem nenhum código adicional. É possível configurar quantos chunks de resultado recuperar, aplicar filtros de metadados e executar consultas como “show me the penalty kicks from this soccer match”. Os resultados retornam ranqueados com metadados que incluem tempo de início do chunk, tempo de fim, URI de origem e tipo de embedding — o suficiente para extrair os trechos relevantes do vídeo original.

5. Integre com sua aplicação

Para uso em produção, a AWS disponibiliza a API de Recuperação (Retrieve API) do Amazon Bedrock, acessível via SDK Boto3 em Python. A arquitetura completa prevê que o conteúdo multimodal flua do Amazon S3 pelo MKB Gerenciado com Marengo 3.0 para indexação e embedding, sendo consultado pelas aplicações via Boto SDK Retrieve API ou como destino do Amazon Bedrock AgentCore.

6. Limpeza dos recursos

Para remover os recursos criados durante o teste, a AWS recomenda excluir a knowledge base pelo console do Bedrock (anotando o nome da role de Gerenciamento de Identidade e Acesso (IAM — Identity and Access Management) e o Nome de Recurso Amazon (ARN — Amazon Resource Name) do índice S3 Vector antes de deletar), remover a role de serviço pelo console do IAM e excluir os arquivos do bucket S3.

Casos de uso por segmento

A AWS destaca aplicações práticas em diferentes setores:

• Análise esportiva: encontrar jogadas, formações ou ações de jogadores em temporadas inteiras de filmagem.
• Mídia e entretenimento: gestão de acervo de mídia e busca semântica em arquivos ou serviços de streaming.
• Segurança e proteção: buscar em imagens de câmeras de segurança por incidentes ou atividades específicas.
• Educação e treinamento: localizar segmentos de aulas por conceito, não apenas por palavras-chave.
• Varejo: buscar em vídeos de demonstração de produtos por funcionalidades específicas.

Disponibilidade e preços

O Managed Knowledge Bases para Amazon Bedrock com Marengo Embed 3.0 está disponível nas regiões US East — Norte da Virgínia (us-east-1) e US West — Norte da Califórnia (us-west-1). Para a lista completa de modelos e regiões suportadas, consulte a documentação de modelos suportados por região no Amazon Bedrock.

O modelo de cobrança é baseado no que é armazenado e recuperado. A geração de embeddings com o Marengo Embed 3.0 é cobrada pela taxa padrão de invocação de modelos do Amazon Bedrock. Mais detalhes estão disponíveis na página de preços do Bedrock.

Próximos passos

Para quem quiser se aprofundar, a AWS disponibiliza alguns recursos complementares:

• Documentação técnica: Amazon Bedrock Knowledge Bases e o guia para construir uma knowledge base gerenciada.
• Exemplos de código: o repositório de exemplos do Amazon Bedrock no GitHub conta com notebooks práticos sobre recuperação multimodal.
• Detalhes técnicos do modelo: a documentação do Marengo 3.0 traz informações mais aprofundadas sobre o funcionamento do embedding.

Fonte

Video and image search in Amazon Bedrock Knowledge Base using Marengo 3.0 (https://aws.amazon.com/blogs/machine-learning/video-and-image-search-in-amazon-bedrock-knowledge-base-using-marengo-3-0/)

O modelo: Qwen3.8-2.4T-A95B em perspectiva

Em 12 de agosto de 2026, a equipe Qwen da Alibaba lançou o Qwen3.8-2.4T-A95B — a primeira vez que um modelo da classe Qwen-Max é disponibilizado como open weights. Os números impressionam: 2,4 trilhões de parâmetros totais, com 95 bilhões ativados por token. A arquitetura combina atenção linear com atenção completa (hybrid linear-plus-full-attention), e o contexto nativo chega a 262 mil tokens, extensível até 1 milhão.

O perfil de uso é claramente voltado para cargas agênticas e de raciocínio intenso: codificação em múltiplos passos, planejamento de longo horizonte e uso autônomo de ferramentas. O fato de ser open weights traz controle total — os dados ficam na sua infraestrutura, o comportamento de inferência pode ser customizado e não há cobrança por token em escala. O custo, porém, é operacional: hospedar um modelo de 2,4 trilhões de parâmetros exige infraestrutura de GPU especializada e uma stack de serving otimizada.

Este artigo é o segundo de uma série da AWS sobre deploy de modelos open trillion-parameter no Amazon SageMaker HyperPod. O primeiro, cobrindo o Kimi K3, está disponível em Deploying Kimi K3 on Amazon SageMaker HyperPod and Amazon EKS.

Arquitetura do modelo

A estrutura interna do Qwen3.8 é relevante para entender as decisões de deploy. São 92 camadas organizadas em um padrão repetido: três blocos de Gated DeltaNet seguidos de Mistura de Especialistas (MoE — Mixture of Experts), mais um bloco de Gated Attention com MoE. Das 92 camadas, 69 usam atenção linear com estado recorrente de tamanho fixo (DeltaNet), enquanto as 23 restantes usam atenção quadrática completa.

Essa proporção 3:1 é a chave para inferência eficiente em contextos longos: as camadas DeltaNet não crescem com o contexto, mantendo memória e computação limitadas mesmo ao se aproximar de 1 milhão de tokens. Já o MoE distribui a capacidade entre 512 especialistas pequenos, ativando apenas cerca de 95 bilhões de parâmetros por passagem — o custo de serving acompanha os parâmetros ativados, não os 2,4 trilhões totais.

O modelo também inclui controle nativo de raciocínio via parâmetro reasoning_effort (baixo, médio, alto) e cabeças de rascunho MTP (Predição Multi-Token — Multi-Token Prediction) integradas nos próprios pesos, o que permite decodificação especulativa sem necessidade de um modelo separado.

Por que o Amazon SageMaker HyperPod para MoE de grande escala

Hospedar um modelo de 2,4 trilhões de parâmetros vai muito além de ter GPUs suficientes. É preciso orquestração que cuide de download de pesos, agendamento de contêineres, monitoramento de saúde, autoescalonamento e recuperação de falhas de nós — tudo sem intervenção manual. O Amazon SageMaker HyperPod foi projetado exatamente para essa classe de workload.

Os clusters HyperPod usam o Amazon Elastic Kubernetes Service (Amazon EKS) como plano de controle. Isso significa acesso ao ecossistema completo do Kubernetes — kubectl, Helm charts, definições de recursos customizados — enquanto a AWS gerencia o ciclo de vida da infraestrutura subjacente: rede, armazenamento, instalação de drivers de GPU e o plugin de dispositivos NVIDIA.

O HyperPod Inference Operator fornece um único CRD (Definição de Recurso Customizado — Custom Resource Definition) chamado InferenceEndpointConfig, que declara de forma declarativa o modelo, a imagem de contêiner, os recursos de GPU e os argumentos do vLLM. O operador cuida de download dos pesos (do Hugging Face Hub, Amazon S3 ou Amazon FSx), agendamento de contêineres, verificações de saúde, atualizações contínuas e autoescalonamento via KEDA com métricas do Amazon CloudWatch ou Prometheus.

Entre os recursos adicionais do Inference Operator v3.x, destacam-se: Prefill e Decode Desagregados (DPD), que separa as fases de prefill e decode em pools de GPU distintos para latência previsível; captura de dados de inferência em nível de endpoint, load balancer ou pod; deploy com NVMe local para reduzir latência de cold-start; e gerenciamento de DNS via Amazon Route 53 para registros de domínio customizados.

Dimensionamento de infraestrutura: a instância ml.p6-b300

A instância ml.p6-b300.48xlarge oferece a densidade de computação necessária para serving do Qwen3.8 em um único nó. São 8 GPUs NVIDIA B300 (Blackwell Ultra) com 288 GB de memória HBM3e cada (2,1 TB no total), largura de banda de memória de 8 TB/s por GPU, interconexão NVLink + NVSwitch com 14,4 TB/s de largura de banda bissecionada, ~15 PFLOPS por GPU em FP4, 192 vCPUs, 4.096 GiB de memória de sistema, rede de 6.400 Gbps EFA e 3,8 TB de armazenamento NVMe local.

Essa instância não está disponível sob demanda — é necessário adquirir capacidade via Flexible Training Plan, uma reserva comprometida de disponibilidade de GPU para o cluster HyperPod, sem concorrência com pools on-demand e sem risco de indisponibilidade no cold-start.

Por que quantização NVFP4

Em precisão BF16, os 2,4 trilhões de parâmetros do Qwen3.8 exigiriam aproximadamente 4,8 TB apenas para os pesos — excedendo um único nó de 8 GPUs. A quantização NVFP4 (W4A4) comprime os pesos para cerca de 4 bits por parâmetro, reduzindo o footprint total para aproximadamente 1,2 TB. Isso cabe confortavelmente nos 2,1 TB de memória GPU agregada do p6-b300, deixando espaço para KV-cache e ativações.

A arquitetura híbrida de atenção é uma vantagem adicional: as 69 camadas DeltaNet mantêm um estado recorrente de tamanho fixo independentemente do comprimento do contexto, ao contrário de modelos tradicionais onde o KV-cache cresce linearmente com todas as camadas. Apenas as 23 camadas de atenção completa contribuem para o crescimento de memória dependente do contexto.

Configuração do vLLM em profundidade

A configuração de serving do vLLM para o Qwen3.8 em um único nó p6-b300 é baseada na receita oficial do vLLM para Qwen3.8 no B300 (NVFP4). O comando completo de serving é:

vllm serve Inferact/Qwen3.8-2.4T-A95B-NVFP4 \
  --tensor-parallel-size 8 \
  --quantization nvfp4 \
  --load-format fastsafetensors \
  --trust-remote-code \
  --enable-prefix-caching \
  --moe-backend auto \
  --reasoning-parser qwen3 \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3 \
  --speculative-config '{"method":"mtp","num_speculative_tokens":1}' \
  --served-model-name Qwen3.8

Os flags mais relevantes: --tensor-parallel-size 8 distribui o modelo pelas 8 GPUs B300; --quantization nvfp4 ativa a quantização NVIDIA FP4 (W4A4); --enable-prefix-caching reutiliza blocos de KV-cache entre requisições que compartilham prefixos de prompt — crítico para conversas agênticas multi-turno; --reasoning-parser qwen3 extrai o conteúdo de raciocínio dos blocos <think>...</think> do modelo, separando-o na resposta da API; e --speculative-config '{"method":"mtp","num_speculative_tokens":1}' ativa a decodificação especulativa usando as cabeças de rascunho nativas do Qwen3.8, sem necessidade de modelo separado.

Passo a passo do deploy no SageMaker HyperPod

Os manifestos e scripts completos estão disponíveis no repositório GitHub. O pré-requisito é ter um cluster HyperPod em execução com capacidade p6-b300: crie o cluster com orquestração EKS no console do Amazon SageMaker AI, provisione um Flexible Training Plan cobrindo a instância ml.p6-b300.48xlarge, adicione um grupo de workers com pelo menos 1 instância e aguarde o cluster atingir o estado Active com nós GPU saudáveis.

O manifesto InferenceEndpointConfig para deploy do Qwen3.8 é:

apiVersion: inference.sagemaker.aws.amazon.com/v1
kind: InferenceEndpointConfig
metadata:
  name: qwen38
spec:
  modelName: qwen38
  instanceType: ml.p6-b300.48xlarge
  invocationEndpoint: v1/chat/completions
  replicas: 1
  modelSourceConfig:
    huggingFaceModel:
      modelId: Inferact/Qwen3.8-2.4T-A95B-NVFP4
    modelSourceType: huggingface
  worker:
    image: vllm/vllm-openai:qwen38
    modelInvocationPort:
      containerPort: 8000
      name: http
    modelVolumeMount:
      mountPath: /opt/ml/model
      name: model-weights
    resources:
      limits:
        nvidia.com/gpu: 8
      requests:
        nvidia.com/gpu: 8
    args:
      - "--model"
      - "/opt/ml/model"
      - "--serving-model-name"
      - "Qwen3.8"
      - "--linear-backend"
      - "flashinfer_cutedsl"
      - "--trust-remote-code"
      - "--enable-prefix-caching"
      - "--enable-auto-tool-choice"
      - "--tool-call-parser"
      - "qwen3_coder"
      - "--reasoning-parser"
      - "qwen3"
      - "--served-model-name"
      - "Qwen3.8"
      - "--tensor-parallel-size"
      - "8"
    environmentVariables:
      - name: "VLLM_ENGINE_READY_TIMEOUT_S"
        value: "1800"

Para aplicar e monitorar o deploy:

kubectl apply -f qwen.yaml

# Acompanhar o status do InferenceEndpointConfig
kubectl get inferenceendpointconfig qwen38 -w

# Verificar status dos pods (download do modelo e inicialização do contêiner)
kubectl get pods -l model-name=qwen38

# Ver logs de inicialização do vLLM
kubectl logs -f <pod-name> --tail=100

O deploy passa pelas etapas de download dos pesos (~1,2 TB do Hugging Face), carregamento na memória GPU e verificações de saúde. Em um deploy inicial sem cache, espera-se de 15 a 30 minutos. Reinicializações subsequentes com cache NVMe local são significativamente mais rápidas.

Chamando o endpoint: exemplos práticos

Após o endpoint estar pronto, ele expõe uma API compatível com OpenAI. Exemplo básico de chat com raciocínio:

from openai import OpenAI

client = OpenAI(
    base_url="http://<service-endpoint>:8000/v1",
    api_key="unused",  # vLLM não exige auth por padrão
)

response = client.chat.completions.create(
    model="Qwen3.8",
    messages=[{"role": "user", "content": "Explain the trade-offs of MoE vs dense models for inference."}],
    temperature=0.6,
    top_p=0.95,
)

# Trace de raciocínio (o pensamento do modelo)
print("Thinking:", response.choices[0].message.reasoning_content)
# Resposta final
print("Answer:", response.choices[0].message.content)

Para desativar o raciocínio por requisição:

response = client.chat.completions.create(
    model="Qwen3.8",
    messages=[{"role": "user", "content": "What is 2+2?"}],
    extra_body={"chat_template_kwargs": {"enable_thinking": False}},
)

Exemplo de tool calling com schema estrito:

tools = [{
    "type": "function",
    "function": {
        "name": "get_stock_price",
        "description": "Get the current stock price for a ticker symbol",
        "parameters": {
            "type": "object",
            "properties": {
                "ticker": {"type": "string", "description": "Stock ticker, e.g. 'AMZN'"}
            },
            "required": ["ticker"],
            "additionalProperties": False,
        },
        "strict": True,
    }
}]

response = client.chat.completions.create(
    model="Qwen3.8",
    messages=[{"role": "user", "content": "What's Amazon's stock price right now?"}],
    tools=tools,
    tool_choice="auto",
)

print("Thinking:", response.choices[0].message.reasoning_content)
tool_call = response.choices[0].message.tool_calls[0].function
print(f"Function: {tool_call.name}, Args: {tool_call.arguments}")

Os parâmetros de sampling recomendados para a maioria dos casos de uso são temperature=0.6, top_p=0.95 e top_k=20. Para tarefas de raciocínio complexo, defina max_tokens generosamente (32.768–65.536), já que o reasoning_content conta para o orçamento de tokens.

Benchmarks e otimizações de performance

A AWS realizou benchmarks do Qwen3.8-2.4T-A95B em uma única instância p6-b300 (8× B300 GPUs) com 512 requisições de 1.024 tokens de entrada e 1.024 tokens de saída, com concorrência de 32. Foram testadas quatro configurações para isolar o impacto do Paralelismo de Especialistas (EP — Expert Parallelism) e da decodificação especulativa MTP:

O MTP é a otimização dominante para o Tempo até o Primeiro Token (TTFT — Time to First Token): habilitar a decodificação especulativa com apenas 1 token de rascunho reduz o TTFT em quase 59%, de 1.244 ms para 513 ms. O EP sozinho oferece ganhos modestos (~3,5% no TTFT). A combinação EP+MTP entrega o melhor resultado geral: 59,7% de redução no TTFT, 12,2% de redução na latência total e 12,6% de aumento no throughput de saída. A recomendação para produção é habilitar ambos: --enable-expert-parallel combinado com --speculative-config '{"method":"mtp","num_speculative_tokens":1}'.

Outros ajustes relevantes: o prefix caching (--enable-prefix-caching) pode reduzir o TTFT em 50–80% em conversas com alto reúso de prefixo. Para MTP, monitore a taxa de aceitação via endpoint /metrics do vLLM — se ficar acima de 70–80%, aumentar num_speculative_tokens para 2–3 é lucrativo; abaixo de 50%, reduza ou desative. Em cargas de alta concorrência, o overhead do MTP pode reduzir o throughput agregado, então considere desativá-lo nesse cenário.

Para gerenciamento de memória, o parâmetro --gpu-memory-utilization (padrão 0,9) controla quanto da memória GPU o vLLM pré-aloca para KV-cache. Com NVFP4, os pesos ocupam ~57% da memória, deixando ~43% (~900 GB) para cache. Reduzir para 0,85 em caso de erros de memória (OOM) em requisições de contexto longo sacrifica capacidade de batch mas evita cascatas de preempção. O parâmetro --max-model-len limita o comprimento máximo de sequência aceito — defini-lo abaixo do contexto nativo de 262K libera mais slots de KV-cache para requisições mais curtas.

Monitoramento

O vLLM expõe métricas Prometheus no endpoint /metrics. As principais a monitorar são: vllm:num_requests_running (tamanho atual do batch), vllm:gpu_cache_usage_perc (utilização do KV-cache — acima de 95% indica risco de preempção), vllm:num_preemptions_total, vllm:spec_decode_acceptance_rate (taxa de aceitação do MTP) e vllm:e2e_request_latency_seconds. Em deploys HyperPod, essas métricas podem ser coletadas pelo Amazon Managed Prometheus e visualizadas no Grafana, ou alimentar decisões de autoescalonamento no KEDA.

Limpeza dos recursos

Para evitar cobranças contínuas, remova os recursos na ordem inversa:

# Deletar o endpoint de inferência
kubectl delete inferenceendpointconfig qwen38

# (Opcional) Escalar ou deletar o cluster HyperPod
# via console do SageMaker AI ou CLI

A exclusão do cluster interrompe as cobranças de computação. O compromisso do Flexible Training Plan permanece até o fim do prazo independentemente do uso.

Próximos passos

Com o endpoint em produção, a AWS sugere alguns caminhos de evolução: benchmarkar com sua distribuição real de prompts usando vllm bench serve; integrar o endpoint em pipelines agênticos via LangChain, CrewAI ou SDK OpenAI padrão; fazer fine-tuning para domínios específicos com NVIDIA NeMo ou jobs de treinamento do SageMaker, trocando apenas o model ID no manifesto; e adicionar guardrails de segurança de conteúdo (como NVIDIA NeMo Guardrails ou proxy customizado) na frente do endpoint vLLM.

Referências

• Qwen3.8-2.4T-A95B Model Card
• vLLM Recipe: Qwen3.8 no B300 NVFP4
• Documentação vLLM Reasoning Outputs
• vLLM MTP Speculative Decoding
• Documentação vLLM Tool Calling
• NVIDIA Blog: Serve Qwen3.8 no GB300 NVL72
• Deploying Kimi K3 on SageMaker HyperPod (referência)
• Documentação Amazon SageMaker HyperPod
• https://github.com/aws-samples/sagemaker-genai-hosting-examples/tree/main/SageMakerHyperpod/Qwen3.8-2.4T-A95B

Fonte

Deploying Qwen3.8-2.4T-A95B on Amazon SageMaker HyperPod with vLLM (https://aws.amazon.com/blogs/machine-learning/deploying-qwen3-8-2-4t-a95b-on-amazon-sagemaker-hyperpod-with-vllm/)

O que mudou no AWS Lambda

A AWS anunciou uma atualização significativa para o AWS Lambda: o suporte a um timeout de função de até 90 minutos para invocações assíncronas e por mapeamento de fonte de eventos (ESM) no Lambda Managed Instances (LMI). Isso representa um aumento de 6 vezes em relação ao limite anterior de 15 minutos.

Por que esse limite era um problema

Muitas equipes que usam o Lambda para construir aplicações serverless — como processadores orientados a eventos, backends de API e pipelines de processamento de dados — esbarravam constantemente no teto de 15 minutos. Cargas de trabalho mais pesadas, como transcodificação de mídia, cálculos financeiros complexos (como simulações de Monte Carlo) e inferência de IA, exigiam execuções contínuas mais longas. O resultado prático era a necessidade de adotar contornos arquiteturais que aumentavam a complexidade dos sistemas.

O que o Lambda Managed Instances oferece

O Lambda Managed Instances permite processar múltiplas requisições simultâneas por instância, acessar configurações de computação especializadas e obter eficiência de custo por meio das vantagens de precificação do EC2 — tudo isso sem precisar gerenciar infraestrutura diretamente.

Com o novo limite de 90 minutos, passa a ser possível executar diretamente no Lambda cargas de trabalho de processamento de dados, transcodificação de mídia, cálculos financeiros, inferência de IA e processamento em lote que exigem execução contínua mais longa, sem precisar reestruturar as aplicações.

Integração com Lambda Durable Functions

O timeout estendido também se aplica a invocações dentro das Lambda durable functions, que permitem fazer checkpoint e replay de etapas em execuções de longa duração. Quando invocada de forma assíncrona, uma execução durável com múltiplas etapas pode rodar por até 1 ano.

Como configurar o novo timeout

O timeout de até 90 minutos pode ser configurado para invocações assíncronas e ESM por meio do Console do AWS Lambda, AWS CLI, APIs do Lambda, ferramentas de Infraestrutura como Código (IaC) ou o Agent Toolkit for AWS.

Vale destacar: invocações síncronas mantêm o timeout máximo existente de 15 minutos — essa mudança não os afeta.

Disponibilidade

O recurso está disponível em todas as regiões AWS onde o Lambda Managed Instances já está presente.

Para saber mais sobre como configurar o timeout de 90 minutos, consulte o guia do desenvolvedor do Lambda. Para combinar timeouts estendidos com resiliência de checkpoint e replay, veja a documentação de durable functions. Para detalhes de preços, acesse a página de preços do AWS Lambda. Para conhecer mais sobre o AWS Lambda, visite aws.amazon.com/lambda.

Fonte

AWS Lambda now supports 90-minute function timeout on Lambda Managed Instances (https://aws.amazon.com/about-aws/whats-new/2026/09/aws-lambda-90-minute-function/)

Um agosto movimentado para quem constrói com IA na AWS

Agosto de 2026 foi um mês denso de novidades para o ecossistema de IA da AWS. O Amazon Bedrock — plataforma usada por mais de 225 mil clientes ativos, incluindo mais de 80% das empresas da Fortune 100 — recebeu atualizações importantes em contexto de modelos, controle de custos, segurança e suporte a ambientes regulados. Ao mesmo tempo, o AgentCore evoluiu com novos controles para agentes de longa duração, e o Strands Agent Harness SDK ganhou integração com robótica física.

A tendência central que a AWS reforça com essas atualizações é clara: não basta ter modelos mais capazes — é preciso construir sistemas ao redor deles que sejam confiáveis, governáveis e capazes de operar com autonomia real em ambientes de produção.

Raciocínio sobre contextos maiores com mais controle

Janelas de contexto de um milhão de tokens e busca na web

Os modelos GPT-5.6 Sol, Terra e Luna da OpenAI, disponíveis no Amazon Bedrock, passaram a suportar janelas de contexto de um milhão de tokens com prompt caching — o que ajuda a reduzir custos e latência quando o mesmo contexto é reutilizado em múltiplas chamadas.

Além disso, a funcionalidade de Web Search permite que esses modelos busquem informações atuais além dos dados de treinamento, incorporem resultados relevantes às respostas e forneçam citações — sem que o desenvolvedor precise integrar um provedor de busca separado. Para casos que exigem dados ainda mais frescos, como preços em tempo real ou documentações recém-publicadas, os modelos também podem recuperar conteúdo diretamente de sites públicos.

Na prática, isso significa que é possível analisar uma base de código inteira ou um documento regulatório, cruzar seu conteúdo com as informações públicas mais recentes e obter uma resposta citada — tudo a partir de uma única chamada de API.

Inferência global sem costurar regiões manualmente

Com a atualização de inferência entre regiões, é possível acessar os modelos GPT-5.6 Sol, Terra e Luna a partir de mais de 25 regiões AWS. Os perfis globais oferecem a maior capacidade disponível com preços menores por token, enquanto os perfis geográficos (Geo profiles) mantêm o processamento de inferência dentro de uma geografia específica — útil para requisitos de residência de dados.

Visibilidade e controle sobre os custos de inferência

A alocação de custos por principal do IAM (Gerenciamento de Identidade e Acesso) permite atribuir gastos de inferência a usuários, times, projetos, aplicações ou centros de custo específicos. Paralelamente, o AWS Cost Anomaly Detection (Detecção de Anomalias de Custo) passou a monitorar gastos com modelos de fundação de terceiros no Amazon Bedrock, fornecendo análises de causa raiz quando os custos mudam de forma inesperada.

A OpenAI também anunciou redução de preços para a família GPT-5.6 no Amazon Bedrock, incluindo os modelos Luna, Terra e Sol. Com essas atualizações combinadas, os times ganham mais clareza sobre quem está gerando qual gasto, conseguem identificar variações incomuns mais cedo e tomam decisões mais embasadas à medida que as cargas de trabalho de IA crescem.

Defesa cibernética mais rápida: da detecção à resposta

A AWS passou a disponibilizar os modelos Daybreak Red e Daybreak Blue da OpenAI para clientes elegíveis no Amazon Bedrock. O Daybreak Blue é voltado para trabalhos defensivos, como descoberta de vulnerabilidades, engenharia de detecção e resposta a incidentes. Já o Daybreak Red suporta tarefas ofensivas autorizadas, como pesquisa de vulnerabilidades, reprodução de exploits e desenvolvimento de mitigações.

Com esses modelos, equipes de segurança podem investigar e endereçar vulnerabilidades com mais velocidade, contando com verificação de identidade mais robusta, monitoramento aprimorado, controles de acesso e infraestrutura com zero acesso de operadores.

Agentes que ficam em execução por mais tempo — e com mais controle

Sessões de até 14 dias em compute dedicado

As instâncias de runtime do AgentCore permitem executar agentes em compute dedicado do Amazon EC2 — incluindo instâncias com aceleração de GPU (Unidade de Processamento Gráfico), otimizadas para memória e para processamento — com sessões que podem durar até 14 dias. O AgentCore também expandiu sua disponibilidade para as regiões US West (N. California) e Asia Pacific (Hyderabad).

Isso abre caminho para delegar aos agentes trabalhos de longa duração — pesquisa, codificação, monitoramento — com cada carga de trabalho alocada ao tipo de compute mais adequado e executada mais perto dos usuários e sistemas que atende.

Mais autonomia, com limites claros de comportamento e gasto

As políticas temporais (Temporal policies) avaliam cada ação de um agente considerando o que ele já fez, permitindo impor sequências, pré-requisitos, portões de aprovação, correspondência de valores entre chamadas e frescor de dados. O rate limiting (limitação de taxa) controla requisições, tokens de inferência e conexões simultâneas por usuário ou grupo.

O AgentCore payments permite que agentes acessem e paguem por APIs, recursos MCP (Protocolo de Contexto de Modelos) e conteúdo pago, com limites de gasto impostos pela infraestrutura e observabilidade de ponta a ponta. Em conjunto, essas atualizações permitem dar mais independência aos agentes enquanto se controla o que pode acontecer, em que ordem, a que ritmo e dentro de qual orçamento.

Contexto atualizado sem enfraquecer os limites dos dados

A Web Search no AgentCore permite que os agentes incluam ou excluam domínios e filtrem resultados por data de publicação, ajudando-os a recuperar informações atuais de fontes aprovadas. A memória do AgentCore passou a extrair memórias de longo prazo a partir de logs de atividade, eventos comportamentais, eventos de sistema e outros dados JSON estruturados — não apenas de conversas. O controle de acesso granular pode então isolar essas memórias por usuário ou tenant (inquilino).

Com isso, é possível ancorar agentes em fontes confiáveis, construir memória a partir de eventos de negócio e manter esse contexto isolado — sem precisar adicionar lógica de autorização personalizada em cada aplicação.

Catálogo de agentes e ferramentas aprovadas

O AWS Agent Registry oferece um catálogo pesquisável e governado para agentes, servidores MCP, habilidades e recursos personalizados. A detecção em nível organizacional consegue identificar agentes no AgentCore Runtime e servidores MCP no AgentCore Gateway em contas AWS conectadas, enquanto recursos aprovados também podem aparecer no Amazon Quick. O objetivo é encontrar capacidades confiáveis por intenção ou nome, reutilizá-las em diferentes fluxos de trabalho e reduzir a proliferação de agentes duplicados.

Mais opções para ambientes regulados

O Claude Opus 5 passou a estar disponível nas regiões AWS GovCloud (US) com retenção zero de dados habilitada por padrão. Os modelos OpenAI GPT-5.6 Terra e Luna também chegaram às regiões AWS GovCloud (US), com janelas de contexto de um milhão de tokens e prompt caching.

O Amazon Nova Multimodal Embeddings traz recuperação de informações em texto, documentos, imagens, vídeo e áudio para o AWS GovCloud (US-West), enquanto a memória, políticas e o harness gerenciado do AgentCore adicionam contexto gerenciado, controles e orquestração. Isso permite construir agentes de codificação, sistemas de análise de documentos, aplicações de recuperação multimodal e fluxos de trabalho de agentes governados no AWS GovCloud, com um conjunto de capacidades cada vez mais próximo do que está disponível nas regiões comerciais.

Agentes de IA no mundo físico: robótica com Strands

Do registro de demonstrações ao deploy físico em um único fluxo

O Strands Robots conecta o Strands Agents, o LeRobot e os Hugging Face Storage Buckets, permitindo registrar demonstrações, transmitir datasets no formato LeRobot, treinar políticas e fazer deploy em hardware simulado ou físico — sem precisar converter os dados subjacentes. Isso permite iterar sobre políticas de robótica usando um único formato de dados e um único fluxo de agente, desde a simulação até o deploy físico.

Coordenação de múltiplos robôs sem reescrever o agente

O Strands Robots suporta descoberta e coordenação baseada em mesh entre dispositivos simulados e físicos. O Zenoh conecta robôs na mesma rede local, enquanto o AWS IoT Core (Internet das Coisas) suporta frotas geograficamente distribuídas. O Strands Robots e a AWS também estão participando da pré-visualização de pesquisa limitada do Model Hardware Standard, tornando mais fácil prototipar fluxos de trabalho com múltiplos robôs em simulação e movê-los entre frotas locais e conectadas à nuvem com menos mudanças de código.

Por onde começar

Para quem quer explorar essas novidades na prática, a AWS disponibiliza três pontos de entrada: o Amazon Bedrock, o AgentCore CLI para deploy de agentes, e o Strands Harness SDK para quem quer construir seu primeiro agente. Equipes interessadas em entender como o Amazon Bedrock pode apoiar seus projetos também podem entrar em contato com a AWS para iniciar uma conversa.

Fonte

ICYMI: What landed for AI builders in August 2026 (https://aws.amazon.com/blogs/machine-learning/icymi-what-landed-for-ai-builders-in-august-2026/)

O fim do suporte ao TorchServe e o que isso significa na prática

O TorchServe não está mais sendo mantido ativamente. O aviso oficial do projeto deixa claro: não há previsão de atualizações, correções de bugs, novos recursos ou patches de segurança, e vulnerabilidades podem ficar sem resposta.

Para equipes que hoje rodam inferência de modelos com TorchServe, isso significa duas consequências diretas: os patches de segurança param de chegar e as atualizações de compatibilidade com versões mais recentes do PyTorch e do CUDA também param. O time passa a ser responsável por toda a cadeia de dependências — escolher versões compatíveis na pilha de GPU, corrigir vulnerabilidades em cada camada e depurar falhas sutis quando qualquer componente sai de alinhamento. É um trabalho sem diferencial competitivo que atrasa a entrega de modelos sem agregar valor ao produto final.

O que são os AWS Deep Learning Containers e como o Ray Serve DLC se encaixa

Os AWS Deep Learning Containers (DLCs) já resolvem esse tipo de problema há algum tempo para cargas de trabalho de treinamento. São imagens Docker pré-construídas e otimizadas para desempenho que empacotam um framework, suas dependências e a pilha de GPU em uma combinação testada e com patches aplicados — pronta para uso imediato.

Com o lançamento do Ray Serve DLC, essa mesma abordagem chega agora à inferência. O resultado é um container construído especificamente para servir modelos atrás de um endpoint HTTP, mantido e testado pela AWS, com toda a pilha de inferência já montada.

Como o Ray Serve DLC é construído

A variante de CPU do Ray Serve DLC é baseada na imagem Amazon Linux 2023. Já a variante de GPU é construída sobre a imagem oficial da NVIDIA para Amazon Linux 2023, que inclui tanto a camada do sistema operacional quanto as bibliotecas de runtime do CUDA. Sobre essa base, o DLC adiciona:

• O framework de deep learning PyTorch
• A camada de serving do Ray Serve com FastAPI e Uvicorn
• Utilitários comuns para cargas de trabalho de visão, áudio e multimodal
• FFmpeg compilado com aceleração de hardware NVIDIA para pré-processamento de vídeo

Todos os componentes são validados e testados juntos antes de cada release, o que elimina o problema de versões incompatíveis entre o runtime do CUDA, o framework e a camada de serving. Patches de segurança são aplicados no momento do build.

O Ray Serve DLC é publicado como imagens separadas para o Amazon Elastic Kubernetes Service (EKS), para o Amazon Elastic Compute Cloud (EC2) e para o Amazon SageMaker — cada um com um entrypoint dedicado adequado ao contrato de serving daquele ambiente. Todos compartilham a mesma pilha e dependências subjacentes. Para a lista atual de tags de imagem disponíveis, consulte a página de imagens disponíveis do Ray DLC.

Compondo a aplicação Ray Serve

O DLC já entrega a pilha de inferência comum, então muitos modelos — incluindo o modelo Qwen3-VL-2B — rodam nele sem necessidade de uma imagem customizada. Para modelos que precisam de bibliotecas extras, é possível adicioná-las em camadas sobre a mesma base testada.

No exemplo apresentado pela AWS, a versão GPU do Ray Serve DLC é usada para servir o modelo vision-language Qwen3-VL-2B. A aplicação é injetada no container por meio de um ConfigMap, o que mantém o deploy flexível: é possível alterar o código de serving sem reconstruir a imagem. O DLC já fornece a pilha de GPU, PyTorch, Ray Serve e Transformers.

Escrevendo a aplicação de serving

Com o Ray Serve, um endpoint de modelo é uma classe Python decorada com @serve.deployment. O método __call__ trata as requisições HTTP e .bind() registra o deployment. Não há archiver de modelo, hierarquia de classes handler nem arquivo de configuração de propriedades.

Para quem vem do TorchServe, isso substitui o handler customizado, a etapa do torch-model-archiver e o arquivo config.properties.

O exemplo a seguir carrega o modelo vision-language Qwen3-VL-2B na GPU e o expõe como um endpoint HTTP. Quando uma requisição chega com uma URL de imagem e um prompt de texto, o modelo gera uma resposta em linguagem natural descrevendo ou respondendo perguntas sobre a imagem:

from ray import serve
from transformers import AutoModelForImageTextToText, AutoProcessor
import torch

@serve.deployment(ray_actor_options={"num_gpus": 1})
class QwenVLService:
    def __init__(self):
        model_name = "Qwen/Qwen3-VL-2B-Instruct"
        self.processor = AutoProcessor.from_pretrained(model_name)
        self.model = AutoModelForImageTextToText.from_pretrained(
            model_name, torch_dtype=torch.float16
        ).to("cuda")

    async def __call__(self, request):
        try:
            body = await request.json()
            image_url = body.get("image_url")
            prompt = body.get("prompt")
            messages = [{"role": "user", "content": [
                {"type": "image", "image": image_url},
                {"type": "text", "text": prompt},
            ]}]
            inputs = self.processor.apply_chat_template(
                messages,
                tokenize=True,
                add_generation_prompt=True,
                return_dict=True,
                return_tensors="pt"
            ).to("cuda")
            generated_ids = self.model.generate(**inputs, max_new_tokens=200)
            trimmed = [o[len(i):] for i, o in zip(inputs.input_ids, generated_ids)]
            output = self.processor.batch_decode(trimmed, skip_special_tokens=True)[0]
            return {"response": output}
        Except Exception:
            logger.exception("Qwen inference request failed")
            return {"error": "Unable to generate a response. Please try again later."}

app = QwenVLService.bind()

Toda a lógica de serving em qwen_serve.py é adicionada a um ConfigMap chamado qwen-serve-code. O decorator @serve.deployment com ray_actor_options={"num_gpus": 1} instrui o Ray a agendar esse deployment em um worker com uma GPU disponível. O modelo é carregado em float16 para caber nos 24 GB de VRAM disponíveis na GPU A10G usada no exemplo.

Deploy no Amazon EKS

O deploy é feito com o Ray Serve DLC junto ao ConfigMap qwen-serve-code. A arquitetura resultante é um cluster Amazon EKS com um único nó de GPU rodando um pod que serve o modelo via HTTP na porta 8000.

O deploy usa uma única instância g5.xlarge (uma GPU NVIDIA A10G, 24 GB de VRAM). É uma configuração de inferência em nó único: um pod, uma GPU, uma máquina. Para serving distribuído em múltiplos nós — paralelismo de modelo entre máquinas ou autoescala horizontal com múltiplas réplicas — seria necessário construir sobre essa base usando KubeRay para orquestrar workers do Ray entre nós.

O repositório disponibilizado pela AWS inclui scripts que automatizam a configuração da infraestrutura:

• deploy_cluster.sh: provisiona um cluster EKS usando eksctl, com rede de Nuvem Privada Virtual (VPC), um provedor OIDC para autenticação de pods baseada em Gerenciamento de Identidade e Acesso (IAM) e add-ons essenciais do cluster.
• deploy_node_group.sh: adiciona um grupo de nós de GPU gerenciado com uma única instância g5.xlarge rotulada como role=gpu-worker.
• deploy_ray_cluster.sh: aplica o ConfigMap com o qwen_serve.py, faz o deploy de um manifesto Kubernetes que agenda o pod no nó de GPU e inicia o Ray Serve na porta 8000.

Após executar os três scripts, é possível verificar que o pod está rodando e a GPU está alocada:

kubectl get pods -n inference
kubectl describe pod -n inference -l app=ray-serve | grep "nvidia.com/gpu"

Com o pod reportando como pronto, basta fazer o port-forward para testá-lo:

kubectl port-forward -n inference deploy/ray-cluster 8000:8000

Em outro terminal, é possível enviar uma requisição pedindo ao modelo Qwen3-VL-2B que descreva uma imagem:

curl -X POST http://127.0.0.1:8000/ \
  -H "Content-Type: application/json" \
  -d '{
    "image_url": "https://s3.amazonaws.com/model-server/inputs/kitten.jpg",
    "prompt": "Describe this image briefly."
  }'

A resposta será um JSON com a descrição gerada pelo modelo. Para confirmar que a inferência está rodando na GPU:

kubectl exec -n inference deploy/ray-cluster -- nvidia-smi

Observação: o pod reporta como pronto um ou dois minutos antes do Ray Serve começar a responder, porque o modelo ainda está sendo carregado. Se a primeira requisição for recusada, basta aguardar um minuto e tentar novamente.

Limpeza dos recursos

Para evitar cobranças contínuas, os recursos devem ser removidos na ordem inversa:

./delete_ray_cluster.sh  # Remove o deploy do Ray Serve
./delete_node_group.sh   # Remove o grupo de nós de GPU
./delete_cluster.sh      # Exclui o cluster EKS

Conclusão e próximos passos

Ao final desse processo, o resultado é um endpoint de inferência funcional — sem precisar manter compatibilidade com CUDA manualmente, sem escrever boilerplate de handler do TorchServe e sem montar um Dockerfile de múltiplos estágios que costura a pilha de GPU do zero. É exatamente para isso que o Ray Serve DLC foi projetado: oferecer um container com suporte e pré-testado para que as equipes possam focar no código do modelo, não na manutenção de infraestrutura.

Para equipes que ainda estão no TorchServe, esse é um caminho de migração sólido. O DLC elimina o problema de versões incompatíveis, simplifica upgrades para uma simples troca de tag e fornece patches de segurança regulares gerenciados pela AWS. Para cargas de trabalho que precisam escalar além de um único nó, o KubeRay estende essa mesma base para serving distribuído em múltiplos nós.

Para começar, acesse o exemplo de código completo com o deploy end-to-end. Para navegar por todas as imagens DLC disponíveis, incluindo variantes de CPU e outros frameworks, consulte a referência de AWS Deep Learning Containers.

Fonte

Simplify and support your TorchServe workloads using Ray Serve Deep Learning Containers (https://aws.amazon.com/blogs/machine-learning/simplify-and-support-your-torchserve-workloads-using-ray-serve-deep-learning-containers/)