Inteligência artificial, sem ruído.
Tutoriais3 min

Como migrar do TorchServe para o Ray Serve com os Deep Learning Containers da AWS

Com o TorchServe sem manutenção, a AWS lança o Ray Serve DLC para servir modelos como o Qwen3-VL em EKS, com a pilha de GPU pronta e patcheada.

Como migrar do TorchServe para o Ray Serve com os Deep Learning Containers da AWS

O TorchServe não recebe mais manutenção ativa. O aviso oficial do projeto informa que não há atualizações, correções de bugs, novos recursos ou patches de segurança planejados — e que vulnerabilidades podem não ser tratadas. Para equipes que rodam inferência de modelos com TorchServe hoje, isso significa assumir sozinhas toda a cadeia de dependências: escolher versões compatíveis entre a pilha de GPU, corrigir vulnerabilidades em cada camada e depurar falhas quando algum componente sai do alinhamento.

A alternativa: Ray Serve DLC

Os AWS Deep Learning Containers (DLCs) já resolviam esse problema para treinamento. Agora, com o lançamento do Ray Serve DLC, a mesma abordagem chega à inferência: um container pré-construído e otimizado que empacota o framework, suas dependências e a pilha de GPU em uma combinação testada e corrigida.

  • Variante GPU: baseada na imagem oficial NVIDIA Amazon Linux 2023, inclui o runtime CUDA.
  • Adiciona por cima: PyTorch, a camada de serving Ray Serve (com FastAPI e Uvicorn) e utilitários para visão, áudio e multimodal.
  • Inclui FFmpeg compilado com aceleração NVIDIA para pré-processamento de vídeo.

Menos código de infraestrutura

Com o Ray Serve, um endpoint de modelo é uma classe Python decorada com @serve.deployment. Você implementa __call__ para lidar com as requisições HTTP e usa .bind() para registrá-lo. Não há model archiver, hierarquia de handlers nem arquivo config.properties — o que substitui o boilerplate típico do TorchServe.

O exemplo da AWS serve o modelo de visão-linguagem Qwen3-VL-2B em uma instância g5.xlarge (uma GPU NVIDIA A10G, 24 GB de VRAM). O código da aplicação é injetado via ConfigMap, mantendo o deploy flexível sem precisar reconstruir a imagem.

Como testar

Após provisionar o cluster EKS e o grupo de nós GPU, verifique se o pod está rodando e a GPU alocada:

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

Faça o port-forward e envie uma requisição de teste:

kubectl port-forward -n inference deploy/ray-cluster 8000:8000
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."}'

Para confirmar que a inferência roda na GPU: kubectl exec -n inference deploy/ray-cluster -- nvidia-smi.

Por que isso importa

Para times brasileiros que hoje mantêm o TorchServe, a migração elimina o version drift, simplifica upgrades a uma troca de tag e garante patches de segurança gerenciados pela AWS. Para cargas que precisam escalar além de um único nó, o KubeRay estende essa base para serving distribuído. O código completo está no repositório oficial da AWS.


Descubra mais sobre noticiAI

Assine para receber nossas notícias mais recentes por e-mail.

R
Sobre o autorRedação Noticiai

Equipe editorial dedicada a explicar inteligência artificial com clareza, independência e contexto.