Vista geral
Este guia mostra como publicar grandes modelos de linguagem (GMLs) de vanguarda, como o DeepSeek-R1 671B ou o Llama 3.1 405B no Google Kubernetes Engine (GKE) usando unidades de processamento gráfico (GPUs) em vários nós.
Este guia demonstra como usar tecnologias portáteis de código aberto, como o Kubernetes, o vLLM e a API LeaderWorkerSet (LWS), para implementar e publicar cargas de trabalho de IA/ML no GKE, tirando partido do controlo detalhado, da escalabilidade, da resiliência, da portabilidade e da rentabilidade do GKE.
Antes de ler esta página, certifique-se de que conhece o seguinte:
Contexto
Esta secção descreve as principais tecnologias usadas neste guia, incluindo os dois MDIs usados como exemplos neste guia: DeepSeek-R1 e Llama 3.1 405B.
DeepSeek-R1
O DeepSeek-R1, um modelo de linguagem (conteúdo extenso) com 671 mil milhões de parâmetros da DeepSeek, foi concebido para inferência lógica, raciocínio matemático e resolução de problemas em tempo real em várias tarefas baseadas em texto. O GKE processa as exigências computacionais do DeepSeek-R1, suportando as respetivas capacidades com recursos escaláveis, computação distribuída e redes eficientes.
Para saber mais, consulte a documentação do DeepSeek.
Llama 3.1 405B
O Llama 3.1 405B é um modelo de linguagem (conteúdo extenso) da Meta concebido para uma vasta gama de tarefas de processamento de linguagem natural, incluindo geração de texto, tradução e resposta a perguntas. O GKE oferece a infraestrutura robusta necessária para suportar as necessidades de preparação e publicação distribuídas de modelos desta escala.
Para saber mais, consulte a documentação do Llama.
Serviço Kubernetes gerido do GKE
Google Cloud oferece uma vasta gama de serviços, incluindo o GKE, que é adequado para implementar e gerir cargas de trabalho de IA/AA. O GKE é um serviço Kubernetes gerido que simplifica a implementação, o dimensionamento e a gestão de aplicações contentorizadas. O GKE fornece a infraestrutura necessária, incluindo recursos escaláveis, computação distribuída e redes eficientes, para processar as exigências computacionais dos MDIs.
Para saber mais sobre os principais conceitos do Kubernetes, consulte o artigo Comece a saber mais sobre o Kubernetes. Para saber mais sobre o GKE e como este ajuda a dimensionar, automatizar e gerir o Kubernetes, consulte a vista geral do GKE.
GPUs
As unidades de processamento gráfico (GPUs) permitem acelerar cargas de trabalho específicas, como a aprendizagem automática e o processamento de dados. O GKE oferece nós equipados com estas GPUs potentes, o que lhe permite configurar o cluster para um desempenho ideal em tarefas de aprendizagem automática e processamento de dados. O GKE oferece uma variedade de opções de tipo de máquina para a configuração de nós, incluindo tipos de máquinas com GPUs NVIDIA H100, L4 e A100.
Para saber mais, consulte o artigo Acerca das GPUs no GKE.
LeaderWorkerSet (LWS)
O LeaderWorkerSet (LWS) é uma API de implementação do Kubernetes que aborda padrões de implementação comuns de cargas de trabalho de inferência de vários nós de IA/ML. O fornecimento com vários nós tira partido de vários pods, cada um potencialmente executado num nó diferente, para processar a carga de trabalho de inferência distribuída. O LWS permite tratar vários pods como um grupo, o que simplifica a gestão da publicação de modelos distribuídos.
vLLM e publicação em vários anfitriões
Quando publicar LLMs com elevada intensidade computacional, recomendamos que use o vLLM e execute as cargas de trabalho em GPUs.
O vLLM é uma framework de publicação de LLMs de código aberto altamente otimizada que pode aumentar a taxa de transferência de publicação em GPUs, 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
- Publicação distribuída em várias GPUs
Com MDIs/CEs especialmente intensivos em termos computacionais que não cabem num único nó de GPU, pode usar vários nós de GPU para publicar o modelo. O vLLM suporta a execução de cargas de trabalho em GPUs com duas estratégias:
O paralelismo de tensores divide as multiplicações de matrizes na camada de transformador em várias GPUs. No entanto, esta estratégia requer uma rede rápida devido à comunicação necessária entre as GPUs, o que a torna menos adequada para executar cargas de trabalho em nós.
O paralelismo de pipeline divide o modelo por camada ou verticalmente. Esta estratégia não requer comunicação constante entre GPUs, o que a torna uma melhor opção quando executa modelos em nós.
Pode usar ambas as estratégias no serviço de vários nós. Por exemplo, quando usa dois nós com oito GPUs H100 cada, pode usar ambas as estratégias:
- Paralelismo de pipeline bidirecional para dividir o modelo nos dois nós
- Paralelismo de tensores de oito vias para dividir o modelo nas oito GPUs em cada nó
Para saber mais, consulte a documentação vLLM.
Crie um cluster do GKE
Pode publicar modelos usando o vLLM em vários nós de GPU num cluster padrão ou do GKE Autopilot. 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
No Cloud Shell, execute o seguinte comando:
gcloud container clusters create-auto ${CLUSTER_NAME} \
--project=${PROJECT_ID} \
--location=${REGION} \
--cluster-version=${CLUSTER_VERSION}
Standard
Crie um cluster padrão do GKE com dois nós de CPU:
gcloud container clusters create CLUSTER_NAME \ --project=PROJECT_ID \ --num-nodes=2 \ --location=REGION \ --machine-type=e2-standard-16Crie um node pool A3 com dois nós, cada um com oito H100s:
gcloud container node-pools create gpu-nodepool \ --node-locations=ZONE \ --num-nodes=2 \ --machine-type=a3-highgpu-8g \ --accelerator=type=nvidia-h100-80gb,count=8,gpu-driver-version=LATEST \ --placement-type=COMPACT \ --cluster=CLUSTER_NAME --location=${REGION}
Configure o kubectl para comunicar com o seu cluster
Configure o kubectl para comunicar com o cluster com o seguinte comando:
gcloud container clusters get-credentials CLUSTER_NAME --location=REGION
Crie um segredo do Kubernetes para as credenciais do Hugging Face
Crie um segredo do Kubernetes que contenha o token do Hugging Face através do seguinte comando:
kubectl create secret generic hf-secret \
--from-literal=hf_api_token=${HF_TOKEN} \
--dry-run=client -o yaml | kubectl apply -f -
Instale o LeaderWorkerSet
Para instalar o LWS, execute o seguinte comando:
kubectl apply --server-side -f https://github.com/kubernetes-sigs/lws/releases/latest/download/manifests.yaml
Valide se o controlador LeaderWorkerSet está a ser executado no espaço de nomes lws-system
através do seguinte comando:
kubectl get pod -n lws-system
O resultado é semelhante ao seguinte:
NAME READY STATUS RESTARTS AGE
lws-controller-manager-546585777-crkpt 1/1 Running 0 4d21h
lws-controller-manager-546585777-zbt2l 1/1 Running 0 4d21h
Implemente o servidor de modelos vLLM
Para implementar o servidor do modelo vLLM, siga estes passos:
Aplique o manifesto, consoante o MDG que quer implementar.
DeepSeek-R1
Inspecione o
vllm-deepseek-r1-A3.yamlmanifesto.Aplique o manifesto executando o seguinte comando:
kubectl apply -f vllm-deepseek-r1-A3.yaml
Llama 3.1 405B
Inspecione o
vllm-llama3-405b-A3.yamlmanifesto.Aplique o manifesto executando o seguinte comando:
kubectl apply -f vllm-llama3-405b-A3.yaml
Aguarde a conclusão da transferência do ponto de verificação do modelo. Esta operação pode demorar vários minutos a ser concluída.
Veja os registos do servidor de modelos em execução com o seguinte comando:
kubectl logs vllm-0 -c vllm-leaderO resultado deve ser semelhante ao seguinte:
INFO 08-09 21:01:34 api_server.py:297] Route: /detokenize, Methods: POST INFO 08-09 21:01:34 api_server.py:297] Route: /v1/models, Methods: GET INFO 08-09 21:01:34 api_server.py:297] Route: /version, Methods: GET INFO 08-09 21:01:34 api_server.py:297] Route: /v1/chat/completions, Methods: POST INFO 08-09 21:01:34 api_server.py:297] Route: /v1/completions, Methods: POST INFO 08-09 21:01:34 api_server.py:297] Route: /v1/embeddings, Methods: POST INFO: Started server process [7428] 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
Configure o encaminhamento de portas para o modelo executando o seguinte comando:
kubectl port-forward svc/vllm-leader 8080:8080
Interaja com o modelo através do curl
Para interagir com o modelo através do curl, siga estas instruções:
DeepSeek-R1
Num novo terminal, envie um pedido para o servidor:
curl http://localhost:8080/v1/completions \
-H "Content-Type: application/json" \
-d '{
"model": "deepseek-ai/DeepSeek-R1",
"prompt": "I have four boxes. I put the red box on the bottom and put the blue box on top. Then I put the yellow box on top the blue. Then I take the blue box out and put it on top. And finally I put the green box on the top. Give me the final order of the boxes from bottom to top. Show your reasoning but be brief",
"max_tokens": 1024,
"temperature": 0
}'
O resultado deve ser semelhante ao seguinte:
{
"id": "cmpl-f2222b5589d947419f59f6e9fe24c5bd",
"object": "text_completion",
"created": 1738269669,
"model": "deepseek-ai/DeepSeek-R1",
"choices": [
{
"index": 0,
"text": ".\n\nOkay, let's see. The user has four boxes and is moving them around. Let me try to visualize each step. \n\nFirst, the red box is placed on the bottom. So the stack starts with red. Then the blue box is put on top of red. Now the order is red (bottom), blue. Next, the yellow box is added on top of blue. So now it's red, blue, yellow. \n\nThen the user takes the blue box out. Wait, blue is in the middle. If they remove blue, the stack would be red and yellow. But where do they put the blue box? The instruction says to put it on top. So after removing blue, the stack is red, yellow. Then blue is placed on top, making it red, yellow, blue. \n\nFinally, the green box is added on the top. So the final order should be red (bottom), yellow, blue, green. Let me double-check each step to make sure I didn't mix up any steps. Starting with red, then blue, then yellow. Remove blue from the middle, so yellow is now on top of red. Then place blue on top of that, so red, yellow, blue. Then green on top. Yes, that seems right. The key step is removing the blue box from the middle, which leaves yellow on red, then blue goes back on top, followed by green. So the final order from bottom to top is red, yellow, blue, green.\n\n**Final Answer**\nThe final order from bottom to top is \\boxed{red}, \\boxed{yellow}, \\boxed{blue}, \\boxed{green}.\n</think>\n\n1. Start with the red box at the bottom.\n2. Place the blue box on top of the red box. Order: red (bottom), blue.\n3. Place the yellow box on top of the blue box. Order: red, blue, yellow.\n4. Remove the blue box (from the middle) and place it on top. Order: red, yellow, blue.\n5. Place the green box on top. Final order: red, yellow, blue, green.\n\n\\boxed{red}, \\boxed{yellow}, \\boxed{blue}, \\boxed{green}",
"logprobs": null,
"finish_reason": "stop",
"stop_reason": null,
"prompt_logprobs": null
}
],
"usage": {
"prompt_tokens": 76,
"total_tokens": 544,
"completion_tokens": 468,
"prompt_tokens_details": null
}
}
Llama 3.1 405B
Num novo terminal, envie um pedido para o servidor:
curl http://localhost:8080/v1/completions \
-H "Content-Type: application/json" \
-d '{
"model": "meta-llama/Meta-Llama-3.1-405B-Instruct",
"prompt": "San Francisco is a",
"max_tokens": 7,
"temperature": 0
}'
O resultado deve ser semelhante ao seguinte:
{"id":"cmpl-0a2310f30ac3454aa7f2c5bb6a292e6c",
"object":"text_completion","created":1723238375,"model":"meta-llama/Llama-3.1-405B-Instruct","choices":[{"index":0,"text":" top destination for foodies, with","logprobs":null,"finish_reason":"length","stop_reason":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 para usar 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.yamlAdicione 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-adapterGuarde o seguinte manifesto como
vllm_pod_monitor.yaml:Aplique o manifesto ao cluster:
kubectl apply -f vllm_pod_monitor.yaml
Crie carga no ponto final do vLLM
Crie carga no servidor vLLM para testar como o GKE é dimensionado automaticamente com uma métrica vLLM personalizada.
Configure o encaminhamento de porta para o modelo:
kubectl port-forward svc/vllm-leader 8080:8080Execute um script bash (
load.sh) para enviarNpedidos paralelos ao ponto final vLLM:#!/bin/bash # Set the number of parallel processes to run. N=PARALLEL_PROCESSES # Get the external IP address of the vLLM load balancer service. export vllm_service=$(kubectl get service vllm-service -o jsonpath='{.status.loadBalancer.ingress[0].ip}') # Loop from 1 to N to start the parallel processes. for i in $(seq 1 $N); do # Start an infinite loop to continuously send requests. while true; do # Use curl to send a completion request to the vLLM service. 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": 100, "temperature": 0}' done & # Run in the background done # Keep the script running until it is manually stopped. waitSubstitua PARALLEL_PROCESSES pelo número de processos paralelos que quer executar.
Execute o script bash:
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.
Clique em < > PromQL.
Introduza a seguinte consulta para observar as métricas de tráfego:
vllm:gpu_cache_usage_perc{cluster='CLUSTER_NAME'}
A imagem seguinte é um exemplo de um gráfico após a execução do script de carregamento. Este gráfico mostra que o Google Cloud Managed Service for Prometheus está a carregar as métricas de tráfego em resposta à carga adicionada ao ponto final vLLM:
Implemente a configuração do redimensionador automático horizontal de pods
Quando decidir em função de que métrica fazer o ajuste de escala automático, recomendamos as seguintes métricas para o vLLM:
num_requests_waiting: esta métrica está relacionada com o número de pedidos em espera na fila do servidor do modelo. Este número começa a aumentar significativamente 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 processados para um determinado ciclo de inferência no servidor do modelo.
Recomendamos que use num_requests_waiting quando otimizar em função do débito e do 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 o artigo 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 GPUs.
Quando seleciona um averageValue alvo para a configuração do HPA, tem de determinar em que métrica fazer o dimensionamento automático de forma experimental. Para ver ideias adicionais sobre como otimizar as suas experiências, 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. O profile-generator usado nesta publicação no blogue também funciona para o vLLM.
Para implementar a configuração do redimensionador automático horizontal de pods através de num_requests_waiting, siga estes passos:
Guarde o seguinte manifesto como
vllm-hpa.yaml: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_waitingpara dimensionar a taxa de transferência. Usegpu_cache_usage_percpara exemplos de utilização da GPU sensíveis à latência.Implemente a configuração do redimensionador automático horizontal de pods:
kubectl apply -f vllm-hpa.yamlO 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 --watchO resultado é semelhante ao seguinte:
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE lws-hpa LeaderWorkerSet/vllm 0/1 1 2 1 6d1h lws-hpa LeaderWorkerSet/vllm 1/1 1 2 1 6d1h lws-hpa LeaderWorkerSet/vllm 0/1 1 2 1 6d1h lws-hpa LeaderWorkerSet/vllm 4/1 1 2 1 6d1h lws-hpa LeaderWorkerSet/vllm 0/1 1 2 2 6d1h
Acelere os tempos de carregamento de modelos com o Google Cloud Hyperdisk ML
Com estes tipos de GMLs, o GMLv pode demorar um período significativo a ser transferido, carregado e aquecido em cada nova réplica. Por exemplo, esse processo pode demorar cerca de 90 minutos com o Llama 3.1 405B. Pode reduzir este tempo (para 20 minutos com o Llama 3.1 405B) transferindo o modelo diretamente para um volume de ML do Hyperdisk e montando esse volume em cada Pod. Para concluir esta operação, este tutorial usa um volume ML do Hyperdisk e uma tarefa do Kubernetes. Um controlador de tarefas no Kubernetes cria um ou mais pods e garante que executam com êxito uma tarefa específica.
Para acelerar os tempos de carregamento dos modelos, siga estes passos:
Guarde o seguinte manifesto de exemplo como
producer-pvc.yaml:kind: PersistentVolumeClaim apiVersion: v1 metadata: name: producer-pvc spec: # Specifies the StorageClass to use. Hyperdisk ML is optimized for ML workloads. storageClassName: hyperdisk-ml accessModes: - ReadWriteOnce resources: requests: storage: 800GiGuarde o seguinte manifesto de exemplo como
producer-job.yaml:DeepSeek-R1
Llama 3.1 405B
Siga as instruções em Acelere o carregamento de dados de IA/ML com o Hyperdisk ML, usando os dois ficheiros que criou nos passos anteriores.
Após este passo, criou e preencheu o volume de ML do Hyperdisk com os dados do modelo.
Implemente a implementação do servidor de GPU de vários nós do vLLM, que vai usar o volume de ML do Hyperdisk recém-criado para dados do modelo.
DeepSeek-R1
Llama 3.1 405B