Esta página foi traduzida pela API Cloud Translation.

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

Este tutorial mostra como publicar grandes modelos de linguagem (GMLs) usando unidades de processamento tensor (TPUs) no Google Kubernetes Engine (GKE) com a estrutura 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:

Saiba mais sobre a arquitetura do sistema da TPU Trillium.
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.

FUSE do Cloud Storage

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.

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

Crie um cluster do GKE Autopilot:

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

Standard

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

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

Crie um espaço de nomes. Pode ignorar este passo se estiver a usar o espaço de nomes default:
```
kubectl create namespace ${NAMESPACE}
```

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

Crie a ServiceAccount do Kubernetes:

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

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"

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.

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: vllm/vllm-tpu:latest
        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:

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"
```
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.

Aplique o manifesto executando o seguinte comando:

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

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

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})

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.

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

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.

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

Aplique-o ao cluster:

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

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.

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.

Execute o script bash:
```
chmod +x load.sh
nohup ./load.sh &
```

Verifique se o serviço gerido do Google Cloud para Prometheus ingere 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.

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

Aceda ao explorador de métricas
Clique em < > PromQL.
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.

vllm:num_requests_waiting

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 Save on GPUs: Smarter autoscaling for your GKE inferencing workloads 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:

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 serviço gerido da Google Cloud para 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 TPU sensíveis à latência.

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.

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

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.