Implante modelos de IA generativa no Amazon EKS

Arquitetura JARK

O JupyterHub fornece uma plataforma compartilhada para executar notebooks populares em negócios, educação e pesquisa. Ele promove a computação interativa em que os usuários podem executar código, visualizar resultados e trabalhar juntos. Na área do GenAI, o JupyterHub acelera o processo de experimentação, especialmente no ciclo de feedback. É também onde os engenheiros de dados colaboram em modelos para o Prompt Engineering.

O Argo Workflows é um mecanismo de fluxo de trabalho nativo de contêiner de código aberto para orquestrar trabalhos paralelos no Kubernetes. Ele fornece um pipeline estruturado e automatizado, feito sob medida para o ajuste fino de modelos.

O pipeline de fluxo de trabalho do Argo é composto pelos seguintes estágios:

• Preparação de dados: organize e pré-processe conjuntos de dados de treinamento.
• Configuração do modelo: defina a arquitetura e os hiperparâmetros para o ajuste fino do LLM.
• Ajuste fino: execute o regime de treinamento.
• Validação: meça o desempenho do modelo ajustado.
• Ajuste de hiperparâmetros: otimize as configurações para obter desempenho máximo.
• Avaliação do modelo: Avalie a eficácia do modelo usando dados de teste separados.
• Implantação: hospede o modelo para atender às solicitações de inferência.

O Ray é um framework de computação distribuída de código aberto que facilita a escalabilidade de aplicativos e o uso de bibliotecas de aprendizado de máquina de última geração. O Ray é usado para distribuir o treinamento de modelos generativos em vários nós, o que acelera o processo e permite o manuseio de conjuntos de dados maiores.

O Ray Serve é uma poderosa biblioteca de serviços de modelos que facilita a criação de uma interface de programação de aplicativos (API) de inferência on-line. Notavelmente, é compatível com os principais frameworks, como PyTorch, Keras e Tensorflow. Ele é otimizado para atender LLMs com recursos como streaming de resposta, lote dinâmico de solicitações e suporte a vários nós/várias GPUs (unidade de processamento gráfico). Além de servir modelos, o Ray Serve permite a integração de vários modelos e regras de negócios em um único serviço. Desenvolvido com base no Ray, ele foi projetado para oferecer escalabilidade entre máquinas e oferece agendamento com eficiência de recursos. Em relação ao JupyterHub, embora o texto não indique explicitamente uma conexão, as duas ferramentas podem fazer parte de um ecossistema maior de ML, com o JupyterHub facilitando a computação interativa e o Ray Serve gerenciando a implantação e a disponibilização dos modelos.

O Kubernetes é uma poderosa plataforma de orquestração de contêineres que automatiza a implantação, o escalonamento e o gerenciamento de aplicativos em contêineres. O Kubernetes fornece a infraestrutura para executar e escalar modelos GenAI em contêineres, o que garante alta disponibilidade, tolerância a falhas e utilização eficiente de recursos.

Arquitetura da solução

Passo a passo

Guia detalhado sobre como ajustar e implantar um modelo generativo no Amazon EKS

Caso de uso

Como mencionamos anteriormente, a maioria dos casos de uso exige o ajuste fino de um LLM para tarefas específicas de acordo com seus requisitos de negócios. Normalmente, isso requer apenas um pequeno conjunto de dados com relativamente poucos exemplos e, na maioria dos casos, pode ser executado com uma única GPU. Neste blog, usamos o exemplo do Dreambooth para demonstrar como podemos adaptar um grande modelo de texto para imagem, como o Stable Diffusion
Commercial applications of Dreambooth may include:

para gerar imagens contextualizadas de um assunto (por exemplo, um cachorro) em cenas diferentes. O artigo da Dreambooth descreve uma abordagem para vincular um identificador exclusivo ao assunto (por exemplo, uma foto de [v] cachorro), a fim de sintetizar fotos do referido assunto em imagens fotorrealistas com base no prompt de entrada (por exemplo, uma foto de [v] cachorro na lua).

As aplicações comerciais do Dreambooth podem incluir:

1. Geração de imagens a partir de descrições de texto para plataformas de mídia social, sites de comércio eletrônico e outras plataformas on-line.
2. Criação de avatares personalizados de fotos de perfil para usuários.
3. Geração de imagens de produtos para lojas online.
4. Criação de materiais de marketing e conteúdo educacional que use recursos visuais, etc.

Vamos nos referir ao nosso modelo de amostra e serviço de inferência como dogbooth no restante deste blog. Para executar o ajuste fino do dogbooth no Amazon EKS, usamos várias tecnologias de código aberto para uma abordagem autogerenciada.

Além da pilha JARK, também aproveitamos estas duas bibliotecas do Hugging Face, que nos fornecem as ferramentas para personalizar o modelo de difusão estável: Accelerate e Diffusers.

O Accelerate é uma biblioteca de código aberto projetada especificamente para simplificar e otimizar o processo de treinamento e ajuste fino dos modelos de aprendizado profundo. Para nosso propósito, ele fornece uma API de alto nível que facilita a experimentação com diferentes hiperparâmetros e configurações de treinamento sem a necessidade de reescrever o ciclo de treinamento a cada execução e usar com eficiência os recursos de hardware disponíveis.

O Diffusers é um conjunto de bibliotecas ideais para modelos de difusão pré-treinados de última geração para gerar imagens, áudio e até estruturas 3D de moléculas. Eles fornecem exemplos de treinamento de fácil utilização como uma coleção de scripts, para demonstrar como usar com eficiência a biblioteca de difusores para uma variedade de tarefas de personalização, como treinamento incondicional, treinamento de texto para imagem, Dreambooth, ControlNet, difusão personalizada, etc.

Etapas para implantar o modelo Stable Diffusion no Amazon EKS

Pré-requisitos

1. AWS Command Line Interface (AWS CLI) v2 — a CLI para serviços da AWS
2. kubectl — a CLI do Kubernetes
3. Terraform 1.5 — uma ferramenta de infraestrutura como código
4. Hugging Face Token com writescope
5. jq — um processador JSON de linha de comando leve e flexível

Etapa 1: clone o repositório do GitHub

git clone https://github.com/awslabs/data-on-eks.git

Etapa 2: implantar a amostra do blueprint

Navegue até o diretório do blueprint ai-ml/jark-stack e execute o. script /install.sh. Esse script executa os comandos terraform init e terraform -apply. Observe que, por padrão, a solução é configurada na região us-west-2. Atualize o arquivo variables.tf para implantá-lo em outra região da AWS. Observe que pode levar aproximadamente 30 minutos para que a implantação seja concluída com êxito.

cd data-on-eks/ai-ml/jark-stack/terraform
export TF_VAR_huggingface_token=hf_XXXXXXXXXX

./install.sh  

Initializing ...
Initializing the backend...
Initializing modules...

Initializing provider plugins...
Terraform has been successfully initialized!
...
SUCCESS: Terraform apply of all modules completed successfully

O blueprint baseado no Terraform fornece o seguintes componentes:

• Amazon Virtual Private Cloud (Amazon VPC) com sub-redes, tabelas de rotas e NAT gateway.
• Cluster Amazon EKS (versão 1.27).
• Grupo de nós de trabalho gerenciados pelo Amazon EKS e usado para hospedar alguns dos complementos que provisionaremos no cluster.
• Outro grupo de nós de trabalho usado para provisionar instâncias baseadas em GPU. Para o propósito deste blog, optamos por usar as instâncias G5 do Amazon Elastic Compute Cloud (Amazon EC2) baseados nas GPUs NVIDIA A10G Tensor Core que apresentam 28 GB de memória por GPU.
• Um segredo do Kubernetes para o token Hugging Face e o configmap contendo nosso exemplo de notebook ipython que será montado no pod do notebook.
• Instalação de vários complementos que discutiremos na próxima seção.

Complementos

Vamos dar uma olhada nos complementos, que são os pods de software operacional implantados como parte da pilha.

aws eks update-kubeconfig --name jark-stack --region us-west-2

kubectl get deployments -A
                                                                
NAMESPACE              NAME                                                 READY   UP-TO-DATE   AVAILABLE   AGE
ingress-nginx          ingress-nginx-controller                             1/1     1            1           36h
jupyterhub             hub                                                  1/1     1            1           36h
jupyterhub             proxy                                                1/1     1            1           36h
kube-system            aws-load-balancer-controller                         2/2     2            2           36h
kube-system            coredns                                              2/2     2            2           2d5h
kube-system            ebs-csi-controller                                   2/2     2            2           2d5h
kuberay-operator       kuberay-operator                                     1/1     1            1           36h
nvidia-device-plugin   nvidia-device-plugin-node-feature-discovery-master   1/1     1            1           36h

Controlador CSI do Amazon EBS

O driver da interface de armazenamento de contêiner (CSI) do Amazon Elastic Block Store (Amazon EBS) permite que os clusters do Amazon Elastic Kubernetes Service (Amazon EKS) gerenciem o ciclo de vida dos volumes do Amazon EBS para volumes persistentes.

Defina o StorageClass padrão como gp3.

Controlador do AWS Load BalancerO controlador do AWS Load Balancer gerencia os AWS Elastic Load Balancers para um cluster Kubernetes. Você precisa de um Network Load Balancer para acessar nossos notebooks Jupyter e, eventualmente, outro Network Load Balancer que forneça uma entrada para nosso endpoint de inferência auto-hospedado, que será discutido posteriormente neste blog.

Plug-in de dispositivo NVIDIA

O plug-in de dispositivo NVIDIA para Kubernetes é um DaemonSet que permite expor automaticamente o número de GPUs ao Kubernetes, permitindo que executemos contêineres habilitados para GPU em nosso cluster.

Se você examinar a pasta data-on-eks/ai-ml/jark-stack/terraform/helm-values, você verá o arquivo de valores dos três valores HELM. Neste exemplo, use um valor mínimo de values.yaml para o heml chart que habilita os recursos gpu-feature-discovery e node-feature-discovery, bem como uma tolerância que permite que os pods de node-feature-discovery sejam executados nos nós da GPU que criamos por meio do blueprint. Vamos nos aprofundar na configuração avançada do NVIDIA Device Plugin/NVIDIA GPU Operator em outro post.

gfd:
  enabled: true
nfd:
  enabled: true
  worker:
    tolerations:
      - key: nvidia.com/gpu
        operator: Exists
        effect: NoSchedule
      - operator: "Exists"

JupyterHub 

Da mesma forma, você verá um jupyterhub-values.yaml. O script do Terraform instalou o JupyterHub. Neste exemplo, passamos um values.yaml para o helm chart que configura o JupyterHub para usar um Load Balancer para acesso, especificar o requisito de GPU no recurso e um volume de armazenamento baseado no Amazon EBS para persistência de dados. Observe que mostramos o uso da autenticação básica de usuário com base no nome de usuário e senha dos notebooks apenas para fins de demonstração. Para configuração no mundo real, considere usar um provedor de identidade.

...
proxy:
  service:
    annotations:
      service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip
      service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
      service.beta.kubernetes.io/aws-load-balancer-type: external
      service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: 'true'
      service.beta.kubernetes.io/aws-load-balancer-ip-address-type: ipv4
singleuser:
  image:
    name: public.ecr.aws/h3o5n2r0/gpu-jupyter
    tag: v1.5_cuda-11.6_ubuntu-20.04_python-only
    pullPolicy: Always
..
  extraResource:
    limits:
      nvidia.com/gpu: "1"
  extraEnv:
    HUGGING_FACE_HUB_TOKEN:
      valueFrom:
        secretKeyRef:
          name: hf-token
          key: token
  storage:
    capacity: 100Gi
...
      - name: notebook
        configMap:
          name: notebook
...

O dockerfile da imagem do contêiner que usamos para o notebook é fornecido no repositório dentro do diretório src/notebook/Dockerfile.

Ingress-Nginx

O Ingress-nginx nos permite usar algumas regras de reescrita de caminho para expor o painel do Ray e o endpoint de inferência usando o mesmo balanceador de carga. Esse modelo também nos permite executar vários endpoints do Ray Serve e usar o roteamento baseado em caminhos para disponibilizar diferentes versões do modelo usando o mesmo balanceador de carga.

Operador Kuberay

O KubeRay Operator facilita a implantação e o gerenciamento de clusters Ray no Kubernetes. Os clusters são definidos como um recurso RayCluster personalizado e gerenciados por um controlador Ray tolerante a falhas. O KubeRay Operator automatiza o gerenciamento do ciclo de vida do cluster Ray, o escalonamento automático e outras funções críticas.

Posteriormente neste blog, vamos descrever como criar um serviço de inferência para dogbooth usando a definição de recurso personalizada RayService no cluster.

Etapa 3: ajuste fino do modelo de difusão estável

Agora você está pronto para começar a experimentar nosso modelo e preparar um notebook que nos ajude a personalizá-lo de acordo com suas necessidades. Obtenha o DNS do Load Balancer.

kubectl get svc proxy-public -n jupyterhub --output jsonpath='{.status.loadBalancer.ingress[0].hostname}'

Acesse o nome do host DNS retornado (por exemplo, k8s-jupyterh-proxypub-xxx. elb.us-west-2.amazonaws.com) no navegador web.

Faça login usando o usuário user1 e a senha especificada no jupyterhub-values.yaml.

Isso aciona um pod jupyter-user1 que será provisionado na instância g5. Você pode ver o pod se executar o comando kubectl get pods -n jupyterhub .

Após o lançamento bem-sucedido, você deve ser redirecionado para o console do notebook no navegador.

Inicie o notebook python fornecido no diretório dogbooth no navegador de arquivos, conforme mostrado na figura a seguir.

Em seguida, você poderá percorrer as células do notebook, conforme mostrado na figura a seguir. A primeira célula executa a interface de gerenciamento do sistema NVIDIA (nvidia-smi) para verificar se a instância do notebook está provisionada corretamente no nó da GPU e confirmar a GPU NVIDIA A10G subjacente.

As próximas quatro células configuram nosso ambiente de desenvolvimento clonando o repositório GitHub dos difusores Hugging Face e instalando algumas dependências de python que os difusores precisam. Além disso, instalam o XFormers para permitir uma atenção eficiente em termos de memória, conforme descrito no exemplo do dreambooth.

Depois de concluir essas tarefas, instalam bitsandbytes para usar o otimizador de 8 bits para reduzir ainda mais os requisitos de memória.

Após a instalação bem-sucedida do bitsandbytes, configure os requisitos para executar o script de treinamento do dreambooth. Isso inclui instalar algumas dependências adicionais, definir uma configuração padrão para o accelerate, fazer login no Hugging Face e baixar um conjunto de dados de amostra do Hugging Face.

Agora, você pode iniciar o treinamento depois de configurar as variáveis de ambiente para a localização do modelo de entrada, do diretório do conjunto de dados e do diretório de saída do modelo ajustado. O Hugging Face accelerate faz todo o trabalho pesado para nos ajudar a experimentar o modelo. Os hiperparâmetros usados na amostra a seguir são otimizados para que o treinamento seja executado com êxito em 1 GPU NVIDIA A10G com 24 GB de memória.

Isso leva cerca de 90 minutos para ser concluído — o momento perfeito para pegar um pouco de comida. Você pode reduzir a quantidade de tempo de treinamento alterando alguns dos hiperparâmetros (por exemplo, —max_train_steps=400), mas isso prejudica o desempenho e a precisão do modelo.

Depois que o script de treinamento for concluído, você poderá verificar se o modelo foi criado e executar um exemplo de inferência para verificar seu desempenho.

Abra o arquivo dog-bucket.png. Esta imagem é armazenada na pasta /home/jovyan/diffusers/examples/deambooth

Como o accelerate também carrega o modelo para o Hugging Face, você pode até mesmo testar uma amostra de inferência na API Hosted Inference. Você o encontrará se navegar até https://huggingface.co/spaces/<huggingface_username>/dogbooth ou o valor fornecido pelo $OUTPUT_DIR.

Se o modelo tiver overfitting ou underfitting, consulte uma análise aprofundada do dreambooth realizada pela Hugging Face para ajudá-lo a ajustar os hiperparâmetros para melhorar o desempenho do modelo. Essas recomendações estão além do escopo deste blog.

Etapa 4: disponibilizando o LLM

Agora que você ajustou o modelo, crie um endpoint de inferência para dogbooth em nosso cluster Amazon EKS.

Você pode usar a definição de recursos personalizados (CRD) do RayService para implantar um RayCluster com um aplicativo RayServe que extrai o modelo dogbooth do Hugging Face que você enviou anteriormente por meio do script de treinamento  do accelerate como resultado do experimento de ajuste fino.

Definir ponto de entrada para RayService

O aplicativo RayServe python é empacotado em uma imagem de contêiner que pode ser baixada para o RayCluster durante a implantação. A documentação do Ray fornece um código de exemplo para criar um aplicativo para inferência usando o Ray Serve e o FastAPI. Ajustamos o código python fornecido para passar nosso modelo dogbooth personalizado que foi enviado para o Hugging Face como model_id passando uma variável de ambiente MODEL_ID para a configuração do RayService, conforme mostrado nas etapas a seguir. Revise o aplicativo python em src/service/dogbooth.py. Para examinar o Dockerfile usado para criar uma imagem de contêiner para o RayCluster, os nós head e worker, consulte src/service/Dockerfile.

A configuração avançada do RayService é deixada como um exercício para o leitor.

Definir RayService

Agora você está pronto para implantar o RayService. Fornecemos um ray-service.yaml no diretório data-on-eks/ai-ml/jark-stack/terraform/src/service. Observe o seguinte manifesto ray-service.yaml que:

1. Cria um namespace chamado dogbooth onde implantamos o RayCluster.
2. Cria um Ingress para que você possa expor o endpoint RayService via ingress-nginx ao AWS Network Load Balancer com roteamento baseado em caminhos para o painel e os serviços de inferência.
3. Edita o MODEL_ID emenv_vars para alterar o repositório do modelo para aquele que você criou durante o ajuste fino.

---
apiVersion: v1
kind: Namespace
metadata:
  name: dogbooth
---
apiVersion: ray.io/v1alpha1
kind: RayService
metadata:
  name: dogbooth
  namespace: dogbooth
spec:
...
  serveConfig:
    importPath: dogbooth:entrypoint
    runtimeEnv: |
      env_vars: {"MODEL_ID": "askulkarni2/dogbooth"}
  rayClusterConfig:
    rayVersion: '2.6.0'
    headGroupSpec:
...
      template:
        spec:
          containers:
            - name: ray-head
              image: $SERVICE_REPO:0.0.1-gpu
              resources:
                limits:
                  cpu: 2
                  memory: 16Gi
                  nvidia.com/gpu: 1
...
    workerGroupSpecs:
      - replicas: 1
...
        template:
          spec:
            containers:
              - name: ray-worker
                image: $SERVICE_REPO:0.0.1-gpu
...
                resources:
                  limits:
                    cpu: "2"
                    memory: "16Gi"
                    nvidia.com/gpu: 1
...
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: dogbooth
  namespace: dogbooth
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: "/\$1"
spec:
  ingressClassName: nginx
  rules:
  - http:
      paths:
        - path: /dogbooth/(.*)
          pathType: ImplementationSpecific
          backend:
            service:
              name: dogbooth-head-svc
              port:
                number: 8265
        - path: /dogbooth/serve/(.*)
          pathType: ImplementationSpecific
          backend:
            service:
              name: dogbooth-head-svc
              port:
                number: 8000

Execute kubectl apply -f src/service/ray-service.yaml para criar o RayService no namespace dogbooth.

Depois de aplicados, o nó principal e o nó de trabalho do RayCluster são programados nos nós da GPU e o endpoint de inferência está disponível por meio do nome de host DNS do balanceador de carga. Devido ao grande tamanho da imagem base rayproject/ray-ml:2.6.0-gpu baseada em GPU, isso pode levar até oito minutos para ser concluído.

Aguarde até que os pods estejam prontos, execute kubectl get pods -n dogbooth —watch e, em seguida, obtenha o nome de host DNS do balanceador de carga e explore o Ray Dashboard no navegador.

kubectl get ingress dogbooth -n dogbooth --output jsonpath='{.status.loadBalancer.ingress[0].hostname}'

Acesse essa URL em um navegador web http://k8s-ingressn-ingressn-xxx.elb.us-east-1.amazonaws.com/dogbooth/

Agora você pode ver o RayService na guia Serve no painel.

Por fim, verifique a implantação do nosso modelo dogbooth com um prompt como:

 http://k8s-ingressn-ingressn-xxx.elb.us-east-1.amazonaws.com/dogbooth/serve/imagine?prompt=a photo of [v]dog on the beach

Mas e quanto aos fluxos de trabalho do Argo?

Que bom que você perguntou e não, não esquecemos. As etapas anteriores que discutimos acima são ótimas para experimentação em fases iniciais de formação de problemas e análise de casos de uso. Depois de encontrar os modelos que atendem às metas específicas, para implantá-los na produção, a abordagem de Operações de Aprendizado de Máquina (MLOps) é usada para colaborar entre cientistas de dados, desenvolvedores, equipes de operações e especialistas no domínio. Essa colaboração garante que o modelo seja desenvolvido, implantado e gerenciado de forma eficaz, atenda às metas de negócios e atenda aos requisitos operacionais. Geralmente, é aí que um mecanismo de fluxo de trabalho entra em ação. As opções populares incluem Kubeflow Pipelines (que são baseados em Argo Workflows), Apache Airflow, AWS Step Functions, etc. Discutimos uma abordagem semelhante neste post, onde apresentamos o uso do Argo Events e do Argo Workflows como um mecanismo de fluxo de trabalho nativo do Kubernetes para orquestrar o processamento de dados usando o Spark. Estendendo essa abordagem aos MLOps, podemos começar a ver como podemos construir uma plataforma MLOps para projetos GenAI. Vamos nos aprofundar muito mais nesse tópico e em outros nos próximos blogs e workshops do re:Invent.

Limpando

Para destruir e limpar toda a infraestrutura criada neste blog, basta executar o script ./cleanup.sh. Ele excluirá o RayService e executará terraform destroy para destruir todos os recursos de infraestrutura criados.

./cleanup.sh

Conclusão

Neste post, mostramos o advento dos modelos GenAI, suas vantagens, os principais casos de uso e a natureza intensiva de recursos necessária para criar resultados robustos. Também falamos sobre as principais vantagens que o Amazon EKS oferece para esses casos de uso por meio de sua escalabilidade, resiliência e implantações repetíveis integradas em todos os ambientes, permitindo que os clientes tenham mais controle e flexibilidade, além de impulsionar a relação custo-benefício. Em seguida, passamos pelas etapas para implantar um modelo GenAI no EKS utilizando a pilha JARK.

A AWS também oferece a capacidade de acelerar a adoção do ML por meio da iniciativa DataOnEKS. O DataOnEKS é um projeto de código aberto da AWS que fornece melhores práticas, relatórios de benchmark, modelos de infraestrutura como código (Terraform), exemplos de implantação e arquiteturas de referência para a implantação de cargas de trabalho de dados no EKS.

Além disso, a AWS fornece soluções gerenciadas de ML, como o Amazon Bedrock e o Amazon Sagemaker, que podem ser usadas para implantar e servir facilmente modelos de fundação prontos para uso ou criar e executar seus próprios modelos.

A GenAI está em um estágio muito inicial e evolui em ritmo acelerado com inovações contínuas quase todos os dias. A AWS tem o prazer de ser sua parceira para apoiar todas as necessidades da sua GenAI, talvez com o conjunto mais amplo e completo de recursos de ML do mercado. Estamos ansiosos para trabalhar com você em sua jornada de GenAI e ML e no caminho que temos pela frente!

Este artigo foi traduzido do Blog da AWS em Inglês.