Publique um MDG com a TPU Trillium no GKE com o vLLM

Padrão Autopilot

Este tutorial mostra como publicar grandes modelos de linguagem (GMLs) usando unidades de processamento tensor (TPUs) no Google Kubernetes Engine (GKE) com a framework de publicação vLLM. Neste tutorial, vai publicar o Llama 3.1 70b, usar a TPU Trillium e configurar a escala automática de pods horizontal usando métricas do servidor vLLM.

Este documento é um bom ponto de partida se precisar do controlo detalhado, da escalabilidade, da resiliência, da portabilidade e da rentabilidade do Kubernetes gerido quando implementa e publica as suas cargas de trabalho de IA/ML.

Contexto

Ao usar a TPU Trillium no GKE, pode implementar uma solução de publicação robusta e pronta para produção com todas as vantagens do Kubernetes gerido, incluindo escalabilidade eficiente e maior disponibilidade. Esta secção descreve as principais tecnologias usadas neste guia.

TPU Trillium

As TPUs são circuitos integrados específicos da aplicação (ASICs) desenvolvidos pela Google. As TPUs são usadas para acelerar a aprendizagem automática e os modelos de IA criados com frameworks como o TensorFlow, o PyTorch e o JAX. Este tutorial usa a TPU Trillium, que é a TPU de sexta geração da Google.

Antes de usar as TPUs no GKE, recomendamos que conclua o seguinte percurso de aprendizagem:

1. Saiba mais sobre a arquitetura do sistema da TPU Trillium.
2. Saiba mais sobre as TPUs no GKE.

vLLM

O vLLM é uma framework de código aberto altamente otimizada para publicar GMLs. O vLLM pode aumentar a taxa de transferência de publicação em TPUs, com funcionalidades como as seguintes:

• Implementação do transformador otimizada com PagedAttention.
• Processamento em lote contínuo para melhorar o débito geral da publicação.
• Paralelismo de tensores e publicação distribuída em várias UTPs.

Para saber mais, consulte a documentação do vLLM.

Nota: este tutorial centra-se na implementação do vLLM numa configuração de anfitrião único, o que é ideal para modelos que podem ser publicados a partir de uma única fatia de TPU, como o Llama 3.1 70b num tipo de máquina ct6e-standard-8t. É importante ter em atenção que as configurações com vários anfitriões não são suportadas quando usa o vLLM com TPUs no GKE. A falta de suporte para vários anfitriões limita a utilização do vLLM para publicar modelos extremamente grandes (por exemplo, mais de 400 mil milhões de parâmetros) que requerem a memória agregada e o cálculo de vários anfitriões. Para sistemas ou modelos de produção que requerem uma configuração com vários anfitriões, a solução recomendada e otimizada para o desempenho é usar o JetStream, o motor da Google para a inferência de TPUs. Para começar com uma implementação de vários anfitriões, consulte o artigo Inferência de JetStream MaxText na TPU v6e.

Cloud Storage FUSE

O Cloud Storage FUSE fornece acesso do seu cluster do GKE ao Cloud Storage para pesos de modelos que residem em contentores de armazenamento de objetos. Neste tutorial, o contentor do Cloud Storage criado vai estar inicialmente vazio. Quando o vLLM é iniciado, o GKE transfere o modelo do Hugging Face e coloca em cache os pesos no contentor do Cloud Storage. No reinício do pod ou no aumento da escala de implementação, os carregamentos de modelos subsequentes transferem dados em cache do contentor do Cloud Storage, tirando partido das transferências paralelas para um desempenho ideal.

Para saber mais, consulte a documentação do controlador CSI FUSE do Cloud Storage.

Objetivos

Este tutorial destina-se a engenheiros de MLOps ou DevOps, ou administradores de plataformas que queiram usar as capacidades de orquestração do GKE para publicar MDIs.

Este tutorial abrange os seguintes passos:

1. Crie um cluster do GKE com a topologia de TPU Trillium recomendada com base nas caraterísticas do modelo.
2. Implemente a framework vLLM num node pool no seu cluster.
3. Use a framework vLLM para publicar o Llama 3.1 70b através de um balanceador de carga.
4. Configure a escala automática horizontal de pods através das métricas do servidor vLLM.
5. Publique o modelo.

Antes de começar

Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Enable the required API.

Roles required to enable APIs

To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

Enable the API

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Enable the required API.

Roles required to enable APIs

To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

Enable the API

• Make sure that you have the following role or roles on the project: roles/container.admin, roles/iam.serviceAccountAdmin, roles/iam.securityAdmin, roles/artifactregistry.writer, roles/container.clusterAdmin

  Check for the roles

  1. In the Google Cloud console, go to the IAM page.

     Go to IAM
  2. Select the project.

  3. In the Principal column, find all rows that identify you or a group that you're included in. To learn which groups you're included in, contact your administrator.

  4. For all rows that specify or include you, check the Role column to see whether the list of roles includes the required roles.

  Grant the roles

  1. In the Google Cloud console, go to the IAM page.

     Aceder ao IAM
  2. Selecione o projeto.
  3. Clique em Conceder acesso.

  4. No campo Novos responsáveis, introduza o identificador do utilizador. Normalmente, este é o endereço de email de uma Conta Google.

  5. Na lista Selecionar uma função, selecione uma função.
  6. Para conceder funções adicionais, clique em Adicionar outra função e adicione cada função adicional.
  7. Clique em Guardar.
  • Crie uma conta Hugging Face, se ainda não tiver uma.
  • Certifique-se de que o seu projeto tem quota suficiente para o Cloud TPU no GKE.

  Prepare o ambiente

  Nesta secção, aprovisiona os recursos de que precisa para implementar o vLLM e o modelo.

  Aceda ao modelo

  Tem de assinar o contrato de consentimento para usar o Llama 3.1 70b no repositório do Hugging Face.

  Gere um token de acesso

  Se ainda não tiver um, gere um novo token do Hugging Face:

  1. Clique em O seu perfil > Definições > Tokens de acesso.
  2. Selecione Novo token.
  3. Especifique um nome à sua escolha e uma função de, pelo menos, Read.
  4. Selecione Gerar um token.

  Inicie o Cloud Shell

  Neste tutorial, vai usar o Cloud Shell para gerir recursos alojados no Google Cloud. O Cloud Shell é pré-instalado com o software necessário para este tutorial, incluindo o kubectl e a CLI gcloud.

  Para configurar o seu ambiente com o Cloud Shell, siga estes passos:

  1. Na Google Cloud consola, inicie uma sessão do Cloud Shell clicando em Ativar Cloud Shell na Google Cloud consola. Esta ação inicia uma sessão no painel inferior da consola. Google Cloud

  2. Defina as variáveis de ambiente predefinidas:

     gcloud config set project PROJECT_ID && \
     gcloud config set billing/quota_project PROJECT_ID && \
     export PROJECT_ID=$(gcloud config get project) && \
     export PROJECT_NUMBER=$(gcloud projects describe ${PROJECT_ID} --format="value(projectNumber)") && \
     export CLUSTER_NAME=CLUSTER_NAME && \
     export CONTROL_PLANE_LOCATION=CONTROL_PLANE_LOCATION && \
     export ZONE=ZONE && \
     export HF_TOKEN=HUGGING_FACE_TOKEN && \
     export CLUSTER_VERSION=CLUSTER_VERSION && \
     export GSBUCKET=GSBUCKET && \
     export KSA_NAME=KSA_NAME && \
     export NAMESPACE=NAMESPACE
     

     Substitua os seguintes valores:

     • PROJECT_ID : o seu Google Cloud ID do projeto.
     • CLUSTER_NAME : o nome do seu cluster do GKE.
     • CONTROL_PLANE_LOCATION: a região do Compute Engine do plano de controlo do seu cluster. Indique uma região que suporte a TPU Trillium (v6e).
     • ZONE : uma zona que suporta a TPU Trillium (v6e).
     • CLUSTER_VERSION : a versão do GKE, que tem de suportar o tipo de máquina que quer usar. Tenha em atenção que a versão predefinida do GKE pode não ter disponibilidade para a TPU de destino. A TPU Trillium (v6e) é suportada nas versões do GKE 1.31.2-gke.1115000 ou posteriores.
     • GSBUCKET : o nome do contentor do Cloud Storage a usar para o Cloud Storage FUSE.
     • KSA_NAME : o nome da ServiceAccount do Kubernetes que é usada para aceder aos contentores do Cloud Storage. O acesso ao contentor é necessário para o Cloud Storage FUSE funcionar.
     • NAMESPACE : o namespace do Kubernetes onde quer implementar os recursos do vLLM.

  Crie um cluster do GKE

  Pode publicar MDIs em TPUs num cluster do GKE Autopilot ou Standard. Recomendamos que use um cluster do Autopilot para uma experiência do Kubernetes totalmente gerida. Para escolher o modo de funcionamento do GKE mais adequado às suas cargas de trabalho, consulte o artigo Escolha um modo de funcionamento do GKE.

  Piloto automático

  1. Crie um cluster do GKE Autopilot:

     gcloud container clusters create-auto ${CLUSTER_NAME} \
         --cluster-version=${CLUSTER_VERSION} \
         --location=${CONTROL_PLANE_LOCATION}
     

     Nota: se a sua instância do Cloud Shell se desligar durante a execução do tutorial, repita o passo anterior.

  Standard

  1. Crie um cluster padrão do GKE:

     gcloud container clusters create ${CLUSTER_NAME} \
         --project=${PROJECT_ID} \
         --location=${CONTROL_PLANE_LOCATION} \
         --node-locations=${ZONE} \
         --cluster-version=${CLUSTER_VERSION} \
         --workload-pool=${PROJECT_ID}.svc.id.goog \
         --addons GcsFuseCsiDriver
     

  2. Crie um node pool de fatia de TPU:

     gcloud container node-pools create tpunodepool \
         --location=${CONTROL_PLANE_LOCATION} \
         --node-locations=${ZONE} \
         --num-nodes=1 \
         --machine-type=ct6e-standard-8t \
         --cluster=${CLUSTER_NAME} \
         --enable-autoscaling --total-min-nodes=1 --total-max-nodes=2
     

     O GKE cria os seguintes recursos para o GML:

     • Um cluster padrão do GKE que usa a federação do Workload Identity para o GKE e tem o controlador CSI do FUSE do Cloud Storage ativado.
     • Um conjunto de nós da TPU Trillium com um tipo de máquina ct6e-standard-8t. Este conjunto de nós tem um nó, oito chips de TPU e o dimensionamento automático ativado.

  Configure o kubectl para comunicar com o seu cluster

  Para configurar o kubectl para comunicar com o cluster, execute o seguinte comando:

    gcloud container clusters get-credentials ${CLUSTER_NAME} --location=${CONTROL_PLANE_LOCATION}
  

  Crie um segredo do Kubernetes para as credenciais do Hugging Face

  1. Crie um espaço de nomes. Pode ignorar este passo se estiver a usar o espaço de nomes default:

     kubectl create namespace ${NAMESPACE}
     

  2. Crie um segredo do Kubernetes que contenha o token do Hugging Face, execute o seguinte comando:

     kubectl create secret generic hf-secret \
         --from-literal=hf_api_token=${HF_TOKEN} \
         --namespace ${NAMESPACE}
     

  Crie um contentor do Cloud Storage

  No Cloud Shell, execute o seguinte comando:

  gcloud storage buckets create gs://${GSBUCKET} \
      --uniform-bucket-level-access
  

  Isto cria um contentor do Cloud Storage para armazenar os ficheiros do modelo que transfere do Hugging Face.

  Configure uma conta de serviço do Kubernetes para aceder ao contentor

  1. Crie a ServiceAccount do Kubernetes:

     kubectl create serviceaccount ${KSA_NAME} --namespace ${NAMESPACE}
     

  2. Conceda acesso de leitura/escrita à conta de serviço do Kubernetes para aceder ao contentor do Cloud Storage:

     gcloud storage buckets add-iam-policy-binding gs://${GSBUCKET} \
       --member "principal://iam.googleapis.com/projects/${PROJECT_NUMBER}/locations/global/workloadIdentityPools/${PROJECT_ID}.svc.id.goog/subject/ns/${NAMESPACE}/sa/${KSA_NAME}" \
       --role "roles/storage.objectUser"
     

  3. Em alternativa, pode conceder acesso de leitura/escrita a todos os contentores do Cloud Storage no projeto:

     gcloud projects add-iam-policy-binding ${PROJECT_ID} \
     --member "principal://iam.googleapis.com/projects/${PROJECT_NUMBER}/locations/global/workloadIdentityPools/${PROJECT_ID}.svc.id.goog/subject/ns/${NAMESPACE}/sa/${KSA_NAME}" \
     --role "roles/storage.objectUser"
     

     O GKE cria os seguintes recursos para o GML:

     1. Um contentor do Cloud Storage para armazenar o modelo transferido e a cache de compilação. Um controlador CSI FUSE do Cloud Storage lê o conteúdo do contentor.
     2. Volumes com o armazenamento em cache de ficheiros ativado e a funcionalidade de transferência paralela do Cloud Storage FUSE.
     Prática recomendada:

     Use uma cache de ficheiros suportada por tmpfs ou Hyperdisk / Persistent Disk consoante o tamanho esperado dos conteúdos do modelo, por exemplo, ficheiros de ponderação. Neste tutorial, usa a cache de ficheiros do FUSE do Cloud Storage suportada pela RAM.

  Implemente o servidor de modelos vLLM

  Para implementar o servidor do modelo vLLM, este tutorial usa uma implementação do Kubernetes. Uma implementação é um objeto da API Kubernetes que lhe permite executar várias réplicas de pods distribuídas entre os nós num cluster.

  1. Inspecione o seguinte manifesto de implementação guardado como vllm-llama3-70b.yaml, que usa uma única réplica:

     
     apiVersion: apps/v1
     kind: Deployment
     metadata:
       name: vllm-tpu
     spec:
       replicas: 1
       selector:
         matchLabels:
           app: vllm-tpu
       template:
         metadata:
           labels:
             app: vllm-tpu
           annotations:
             gke-gcsfuse/volumes: "true"
             gke-gcsfuse/cpu-limit: "0"
             gke-gcsfuse/memory-limit: "0"
             gke-gcsfuse/ephemeral-storage-limit: "0"
         spec:
           serviceAccountName: KSA_NAME
           nodeSelector:
             cloud.google.com/gke-tpu-topology: 2x4
             cloud.google.com/gke-tpu-accelerator: tpu-v6e-slice
           containers:
           - name: vllm-tpu
             image: docker.io/vllm/vllm-tpu:73aa7041bfee43581314e6f34e9a657137ecc092
             command: ["python3", "-m", "vllm.entrypoints.openai.api_server"]
             args:
             - --host=0.0.0.0
             - --port=8000
             - --tensor-parallel-size=8
             - --max-model-len=4096
             - --model=meta-llama/Llama-3.1-70B
             - --download-dir=/data
             - --max-num-batched-tokens=512
             - --max-num-seqs=128
             env: 
             - name: HUGGING_FACE_HUB_TOKEN
               valueFrom:
                 secretKeyRef:
                   name: hf-secret
                   key: hf_api_token
             - name: VLLM_XLA_CACHE_PATH
               value: "/data"
             - name: VLLM_USE_V1
               value: "1"
             ports:
             - containerPort: 8000
             resources:
               limits:
                 google.com/tpu: 8
             readinessProbe:
               tcpSocket:
                 port: 8000
               initialDelaySeconds: 15
               periodSeconds: 10
             volumeMounts:
             - name: gcs-fuse-csi-ephemeral
               mountPath: /data
             - name: dshm
               mountPath: /dev/shm
           volumes:
           - name: gke-gcsfuse-cache
             emptyDir:
               medium: Memory
           - name: dshm
             emptyDir:
               medium: Memory
           - name: gcs-fuse-csi-ephemeral
             csi:
               driver: gcsfuse.csi.storage.gke.io
               volumeAttributes:
                 bucketName: GSBUCKET
                 mountOptions: "implicit-dirs,file-cache:enable-parallel-downloads:true,file-cache:parallel-downloads-per-file:100,file-cache:max-parallel-downloads:-1,file-cache:download-chunk-size-mb:10,file-cache:max-size-mb:-1"
     ---
     apiVersion: v1
     kind: Service
     metadata:
       name: vllm-service
     spec:
       selector:
         app: vllm-tpu
       type: LoadBalancer	
       ports:
         - name: http
           protocol: TCP
           port: 8000  
           targetPort: 8000
     

     Se aumentar a implementação para várias réplicas, as escritas simultâneas no VLLM_XLA_CACHE_PATH causam o erro: RuntimeError: filesystem error: cannot create directories. Para evitar este erro, tem duas opções:

     1. Remova a localização da cache XLA removendo o seguinte bloco do YAML de implementação. Isto significa que todas as réplicas recompilam a cache.

        - name: VLLM_XLA_CACHE_PATH
          value: "/data"
        

     2. Dimensione a implementação para 1 e aguarde que a primeira réplica fique pronta e escreva na cache XLA. Em seguida, expanda para réplicas adicionais. Isto permite que as restantes réplicas leiam a cache sem tentar escrevê-la.

  2. Aplique o manifesto executando o seguinte comando:

     kubectl apply -f vllm-llama3-70b.yaml -n ${NAMESPACE}
     

  3. Veja os registos do servidor de modelos em execução:

     kubectl logs -f -l app=vllm-tpu -n ${NAMESPACE}
     

     O resultado deve ser semelhante ao seguinte:

     INFO:     Started server process [1]
     INFO:     Waiting for application startup.
     INFO:     Application startup complete.
     INFO:     Uvicorn running on http://0.0.0.0:8080 (Press CTRL+C to quit)
     

  Publique o modelo

  1. Para obter o endereço IP externo do serviço VLLM, execute o seguinte comando:

     export vllm_service=$(kubectl get service vllm-service -o jsonpath='{.status.loadBalancer.ingress[0].ip}' -n ${NAMESPACE})
     

  2. Interaja com o modelo através de curl:

     curl http://$vllm_service:8000/v1/completions \
     -H "Content-Type: application/json" \
     -d '{
         "model": "meta-llama/Llama-3.1-70B",
         "prompt": "San Francisco is a",
         "max_tokens": 7,
         "temperature": 0
     }'
     

     O resultado deve ser semelhante ao seguinte:

     {"id":"cmpl-6b4bb29482494ab88408d537da1e608f","object":"text_completion","created":1727822657,"model":"meta-llama/Llama-3-8B","choices":[{"index":0,"text":" top holiday destination featuring scenic beauty and","logprobs":null,"finish_reason":"length","stop_reason":null,"prompt_logprobs":null}],"usage":{"prompt_tokens":5,"total_tokens":12,"completion_tokens":7}}
     

  Configure o escalador automático personalizado

  Nesta secção, configura o dimensionamento automático de pods horizontal através de métricas personalizadas do Prometheus. Usa o serviço gerido do Google Cloud para métricas do Prometheus a partir do servidor vLLM.

  Para saber mais, consulte o Google Cloud Managed Service for Prometheus. Esta opção deve estar ativada por predefinição no cluster do GKE.

  1. Configure o adaptador do Stackdriver de métricas personalizadas no seu cluster:

     kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-stackdriver/master/custom-metrics-stackdriver-adapter/deploy/production/adapter_new_resource_model.yaml
     

  2. Adicione a função Leitor do Monitoring à conta de serviço que o adaptador do Stackdriver de métricas personalizadas usa:

     gcloud projects add-iam-policy-binding projects/${PROJECT_ID} \
         --role roles/monitoring.viewer \
         --member=principal://iam.googleapis.com/projects/${PROJECT_NUMBER}/locations/global/workloadIdentityPools/${PROJECT_ID}.svc.id.goog/subject/ns/custom-metrics/sa/custom-metrics-stackdriver-adapter
     

     Nota: certifique-se de que a conta de serviço que o seu cluster do GKE usa tem a função Escritor de métricas de monitorização. Este tutorial usa a conta de serviço predefinida do Compute Engine.

  3. Guarde o seguinte manifesto como vllm_pod_monitor.yaml:

     
     apiVersion: monitoring.googleapis.com/v1
     kind: PodMonitoring
     metadata:
      name: vllm-pod-monitoring
     spec:
      selector:
        matchLabels:
          app: vllm-tpu
      endpoints:
      - path: /metrics
        port: 8000
        interval: 15s
     

  4. Aplique-o ao cluster:

     kubectl apply -f vllm_pod_monitor.yaml -n ${NAMESPACE}
     

  Êxito: o Google Cloud Managed Service for Prometheus está agora configurado para extrair as métricas do servidor vLLM e torná-las visíveis para o controlador de escala automática de pods horizontal.

  Crie carga no ponto final do vLLM

  Crie carga para o servidor vLLM para testar como o GKE é dimensionado automaticamente com uma métrica vLLM personalizada.

  1. Execute um script bash (load.sh) para enviar N pedidos paralelos ao ponto final vLLM:

     #!/bin/bash
     N=PARALLEL_PROCESSES
     export vllm_service=$(kubectl get service vllm-service -o jsonpath='{.status.loadBalancer.ingress[0].ip}' -n ${NAMESPACE})
     for i in $(seq 1 $N); do
       while true; do
         curl http://$vllm_service:8000/v1/completions -H "Content-Type: application/json" -d '{"model": "meta-llama/Llama-3.1-70B", "prompt": "Write a story about san francisco", "max_tokens": 1000, "temperature": 0}'
       done &  # Run in the background
     done
     wait
     

     Substitua PARALLEL_PROCESSES pelo número de processos paralelos que quer executar.

  2. Execute o script bash:

     chmod +x load.sh
     nohup ./load.sh &
     

  Verifique se o serviço gerido do Google Cloud para Prometheus introduz as métricas

  Depois de o serviço gerido do Google Cloud para Prometheus extrair as métricas e de adicionar carga ao ponto final da vLLM, pode ver as métricas no Cloud Monitoring.

  1. Na Google Cloud consola, aceda à página Explorador de métricas.

     Aceda ao explorador de métricas

  2. Clique em < > PromQL.

  3. Introduza a seguinte consulta para observar as métricas de tráfego:

     vllm:num_requests_waiting{cluster='CLUSTER_NAME'}
     

  Um gráfico de linhas mostra a sua métrica de vLLM (num_requests_waiting) medida ao longo do tempo. A métrica vLLM aumenta de 0 (pré-carregamento) para um valor (pós-carregamento). Este gráfico confirma que as suas métricas de vLLM estão a ser carregadas no Google Cloud Managed Service for Prometheus. O gráfico de exemplo seguinte mostra um valor de pré-carregamento inicial de 0, que atinge um valor de pós-carregamento máximo de quase 400 no prazo de um minuto.

  

  Implemente a configuração do redimensionador automático horizontal de pods

  Ao decidir em função de que métrica fazer o ajuste de escala automático, recomendamos as seguintes métricas para a TPU vLLM:

  • num_requests_waiting: esta métrica está relacionada com o número de pedidos à espera na fila do servidor do modelo. Este número começa a aumentar de forma percetível quando a cache KV está cheia.

  • gpu_cache_usage_perc: esta métrica está relacionada com a utilização da cache KV, que está diretamente correlacionada com o número de pedidos que estão a ser processados para um determinado ciclo de inferência no servidor do modelo. Tenha em atenção que esta métrica funciona da mesma forma em GPUs e TPUs, embora esteja associada ao esquema de nomenclatura de GPUs.

  Recomendamos que use num_requests_waiting quando otimizar o débito e o custo, e quando os seus alvos de latência forem alcançáveis com o débito máximo do servidor do modelo.

  Recomendamos que use gpu_cache_usage_perc quando tiver cargas de trabalho sensíveis à latência em que o escalamento baseado em filas não é suficientemente rápido para satisfazer os seus requisitos.

  Para uma explicação mais detalhada, consulte as práticas recomendadas para o dimensionamento automático de cargas de trabalho de inferência de modelos de linguagem (conteúdo extenso) (MDI/CE) com as TPUs.

  Quando selecionar um averageValuealvo para a configuração do HPA, tem de o determinar experimentalmente. Consulte a publicação no blogue Poupe em GPUs: escala automática mais inteligente para as suas cargas de trabalho de inferência do GKE para ver ideias adicionais sobre como otimizar esta parte. O profile-generator usado nesta publicação no blogue também funciona para a TPU vLLM.

  Nas instruções seguintes, implementa a configuração do HPA através da métrica num_requests_waiting. Para fins de demonstração, define a métrica para um valor baixo, para que a configuração do HPA dimensione as réplicas do vLLM para duas. Para implementar a configuração do Horizontal Pod Autoscaler com num_requests_waiting, siga estes passos:

  1. Guarde o seguinte manifesto como vllm-hpa.yaml:

     
     apiVersion: autoscaling/v2
     kind: HorizontalPodAutoscaler
     metadata:
      name: vllm-hpa
     spec:
      scaleTargetRef:
        apiVersion: apps/v1
        kind: Deployment
        name: vllm-tpu
      minReplicas: 1
      maxReplicas: 2
      metrics:
        - type: Pods
          pods:
            metric:
              name: prometheus.googleapis.com|vllm:num_requests_waiting|gauge
            target:
              type: AverageValue
              averageValue: 10
     

     As métricas vLLM no Google Cloud Managed Service for Prometheus seguem o formato vllm:metric_name.

     Prática recomendada:

     Use num_requests_waiting para dimensionar a taxa de transferência. Use gpu_cache_usage_perc para exemplos de utilização de TPUs sensíveis à latência.

  2. Implemente a configuração do redimensionador automático horizontal de pods:

     kubectl apply -f vllm-hpa.yaml -n ${NAMESPACE}
     

     O GKE agenda outro pod para implementação, o que aciona o escalador automático do conjunto de nós para adicionar um segundo nó antes de implementar a segunda réplica do vLLM.

  3. Acompanhe o progresso do ajuste de escala automático de pods:

     kubectl get hpa --watch -n ${NAMESPACE}
     

     O resultado é semelhante ao seguinte:

     NAME       REFERENCE             TARGETS       MINPODS   MAXPODS   REPLICAS   AGE
     vllm-hpa   Deployment/vllm-tpu   <unknown>/10   1         2         0          6s
     vllm-hpa   Deployment/vllm-tpu   34972m/10      1         2         1          16s
     vllm-hpa   Deployment/vllm-tpu   25112m/10      1         2         2          31s
     vllm-hpa   Deployment/vllm-tpu   35301m/10      1         2         2          46s
     vllm-hpa   Deployment/vllm-tpu   25098m/10      1         2         2          62s
     vllm-hpa   Deployment/vllm-tpu   35348m/10      1         2         2          77s
     

     Êxito: o GKE aumenta a escala do servidor vLLM através de métricas personalizadas do Prometheus.

  4. Aguarde 10 minutos e repita os passos na secção Verifique se o serviço gerido do Google Cloud para Prometheus ingere as métricas. O Google Cloud Managed Service for Prometheus ingere agora as métricas de ambos os pontos finais do vLLM.

  Limpar

  Para evitar incorrer em custos na sua conta do Google Cloud pelos recursos usados neste tutorial, elimine o projeto que contém os recursos ou mantenha o projeto e elimine os recursos individuais.

  Elimine os recursos implementados

  Para evitar incorrer em custos na sua Google Cloud conta pelos recursos que criou neste guia, execute os seguintes comandos:

  ps -ef | grep load.sh | awk '{print $2}' | xargs -n1 kill -9
  

  gcloud container clusters delete ${CLUSTER_NAME} \
    --location=${CONTROL_PLANE_LOCATION}
  

  O que se segue?

  • Saiba mais sobre as TPUs no GKE.
  • Saiba mais sobre as métricas disponíveis para configurar o Horizontal Pod Autoscaler.
  • Explore o repositório do GitHub do vLLM e a documentação.