Vista geral das práticas recomendadas de inferência no GKE

Este documento oferece uma vista geral das práticas recomendadas para executar cargas de trabalho de inferência no GKE.

Este documento destina-se a administradores de dados, operadores e programadores que querem adotar práticas recomendadas para as respetivas cargas de trabalho de inferência usando aceleradores, como GPUs e TPUs, com o Kubernetes e o GKE. Para saber mais sobre as funções comuns, consulte o artigo Funções e tarefas comuns de utilizadores do GKE.

Prepare-se para o serviço de inferência no GKE

Esta secção descreve as práticas recomendadas fundamentais que deve seguir quando se preparar para implementar uma carga de trabalho de inferência. Estas práticas incluem analisar o seu exemplo de utilização, escolher modelos e selecionar aceleradores.

Analise as caraterísticas do seu exemplo de utilização de inferência

Antes de implementar uma carga de trabalho de inferência, analise os respetivos requisitos específicos. Esta análise ajuda a tomar decisões arquitetónicas que equilibram o desempenho, o custo e a fiabilidade. Compreender o seu exemplo de utilização ajuda a selecionar os modelos, os aceleradores e as configurações adequados para cumprir os seus objetivos ao nível do serviço (SLOs).

Para orientar a sua análise, avalie as seguintes dimensões principais da sua carga de trabalho:

  • Defina os requisitos de desempenho e latência: determine os SLOs da sua aplicação para latência e débito. As principais métricas a definir incluem pedidos por segundo (RPS), latência de resposta, comprimento dos tokens de entrada e saída, e taxa de acertos da cache de prefixos. Para mais informações, consulte o artigo Métricas de desempenho da inferência.
  • Avalie os requisitos e a escala do modelo: as caraterísticas do modelo escolhido influenciam diretamente as suas necessidades de infraestrutura. Considere o comprimento máximo do contexto que o modelo suporta e compare-o com o que a sua carga de trabalho requer. Se o seu exemplo de utilização não exigir o contexto máximo, diminuir o comprimento máximo do contexto pode libertar memória do acelerador para uma cache KV maior, o que pode aumentar o débito.
  • Estabeleça restrições de custos e empresariais: o seu orçamento e objetivos empresariais são fatores essenciais na conceção de um serviço de inferência sustentável e rentável. Defina o custo por milhão de tokens alvo para entrada e saída, bem como o orçamento mensal total para esta carga de trabalho. Identifique o seu objetivo de otimização, como o desempenho em função do preço, a latência mais baixa ou o débito mais elevado, e se a sua app pode tolerar a latência variável.

Escolha os modelos certos para os seus exemplos de utilização de inferência

A seleção do modelo certo afeta diretamente o desempenho, o custo e a viabilidade da sua aplicação de inferência. Para selecionar o modelo ideal, avalie os candidatos com base nos seguintes critérios:

  • Alinhamento de tarefas e modalidades: avalie os modelos com base nas respetivas tarefas designadas e modalidades suportadas. Um modelo otimizado para uma tarefa específica tem quase sempre um desempenho superior a um modelo de utilização mais geral.
  • Características técnicas: a arquitetura e a precisão do tipo de dados de um modelo, como FP16, FP8 e FP4, são fatores importantes para determinar os respetivos requisitos de recursos e desempenho. Esta avaliação ajuda a determinar se precisa de aplicar técnicas de quantização. Verifique a precisão suportada para os pesos do modelo, certifique-se de que existe suporte para a framework e verifique o comprimento máximo do contexto suportado do modelo.
  • Desempenho e rentabilidade: para tomar uma decisão orientada por dados, compare os modelos pré-selecionados com base em testes de referência disponíveis publicamente e nos seus próprios testes internos. Use tabelas de classificação, como a Chatbot Arena, para comparar modelos e avaliar o custo por milhão de tokens de cada modelo no hardware de destino.

Aplique a quantização ao modelo

A quantização é uma técnica para otimizar as cargas de trabalho de inferência, reduzindo o impacto na memória do modelo. Converte os pesos, as ativações e a cache de chave-valor (KV) do modelo de formatos de ponto flutuante de alta precisão (como FP16, FP32 e FP64) para formatos de precisão inferior (como FP8 e FP4). Esta redução na memória pode levar a melhorias significativas no desempenho e na rentabilidade.

A quantização reduz a pegada de memória do modelo, o que, por sua vez, reduz a sobrecarga de transferência de dados e liberta memória para uma cache KV maior.

Para aplicar eficazmente a quantização aos seus modelos, siga estas recomendações:

  • Avalie a compensação da precisão: por vezes, a quantização pode resultar numa perda de precisão do modelo. Quando avaliar a compensação da precisão da quantização, considere que a quantização de 8 bits pode, muitas vezes, resultar numa perda mínima de precisão. Por outro lado, a quantização de 4 bits pode proporcionar uma redução até quatro vezes superior nos requisitos de memória do acelerador, mas também pode causar uma maior perda de precisão em comparação com a quantização de 8 bits. Avalie o desempenho do modelo quantizado no seu exemplo de utilização específico para garantir que a precisão continua dentro de um intervalo aceitável. Para avaliar a perda de precisão, pode usar ferramentas como o OpenCompass e o Language Model Evaluation Harness.
  • Avalie o suporte da aceleração de hardware: para tirar o máximo partido da quantização, use aceleradores que forneçam aceleração de hardware para os formatos de dados que o modelo quantizado usa. Por exemplo:
    • As GPUs NVIDIA H100 oferecem aceleração de hardware para operações FP8 e FP16.
    • As GPUs NVIDIA B200 oferecem aceleração de hardware para operações FP4, FP8 e FP16.
    • A Cloud TPU v5p oferece aceleração de hardware para operações FP8.
  • Verifique se existem modelos pré-quantizados: antes de quantizar um modelo, verifique repositórios de modelos públicos, como o Hugging Face. Idealmente, encontre um modelo que tenha sido preparado nativamente com uma precisão inferior, uma vez que isto pode oferecer vantagens de desempenho sem a potencial perda de precisão da quantização pós-preparação.
  • Use uma biblioteca de quantização: se não estiver disponível um modelo pré-quantizado, use uma biblioteca para realizar a quantização. Os servidores de inferência, como o vLLM, suportam a execução de modelos que foram quantizados com várias técnicas. Pode usar ferramentas como llm-compressor para aplicar técnicas de quantização a um modelo não quantizado.
  • Considere a quantização da cache KV: além de quantizar os pesos do modelo, também pode quantizar a cache KV. Esta técnica reduz ainda mais a memória necessária para a cache KV no tempo de execução, o que pode levar a um desempenho melhorado.

Para mais informações, consulte o artigo Otimize cargas de trabalho de inferência de MDIs em GPUs.

Escolha os aceleradores certos

A seleção do acelerador certo afeta diretamente o desempenho, o custo e a experiência do utilizador do seu serviço de inferência. A escolha ideal depende de uma análise dos requisitos de memória do modelo, dos objetivos de desempenho e do orçamento.

Para escolher o acelerador certo para o seu exemplo de utilização específico, siga estes passos:

  1. Calcule os requisitos de memória: primeiro, calcule a memória do acelerador mínima necessária para carregar e executar o seu modelo. A memória total é a soma da memória necessária para as ponderações do modelo, a sobrecarga do motor de inferência, as ativações intermédias e a cache KV.

    Para estimar a memória necessária, use a seguinte equação:

    \[ \begin{aligned} \text{Required accelerator memory} = {} & (\text{Model weights} + \text{Overhead} + \text{Activations}) \\ & + (\text{KV cache per batch} \times \text{Batch size}) \end{aligned} \]

    Os termos na equação são os seguintes:

    • Ponderações do modelo: o tamanho dos parâmetros do modelo.
    • Sobrecarga: um buffer para o servidor de inferência e outra sobrecarga do sistema, normalmente 1 a 2 GB.
    • Ativação: a memória necessária para ativações intermédias durante a execução de um modelo.
    • KV cache per batch: a memória necessária para a KV cache para uma única sequência, que é dimensionada com o comprimento do contexto e a configuração do modelo.
    • Tamanho do lote: o número de sequências (max_num_sequences) que vão ser processadas em simultâneo pelo motor de inferência.

    Exemplo: calcula os requisitos de memória do acelerador para o Gemma 3

    Para calcular a memória do acelerador necessária para implementar um modelo de 27 mil milhões de parâmetros do Gemma 3 com uma precisão de BF16 para um exemplo de utilização de geração de texto, pode usar os seguintes valores.

    Para uma explicação interativa deste cálculo, consulte o artigo De quanta VRAM precisa o meu modelo? Bloco de notas do Colab.

    • Entradas:
      • Pesos do modelo: 54 GB
      • Tamanho do lote (max_num_sequences): 1
      • Tamanho médio da entrada: 1500 tokens
      • Tamanho médio da saída: 200 tokens
      • Sobrecarga do motor de inferência: 1 GB (estimado)
      • Tamanho do tipo de dados da cache KV: 2 (para BF16)
      • Vetores KV: 2 (um para a chave e um para o valor)
    • Configuração do modelo para um modelo otimizado para instruções Gemma 3 27B:
      • hidden_size: 5376
      • intermediate_size: 21504
      • num_attention_heads: 32
      • num_hidden_layers: 62
      • num_key_value_heads: 16
    • Cálculo da memória:
      • sequence_length = avg_input_length + avg_output_length = 1500 + 200 = 1700 símbolos
      • pytorch_activation_peak_memory = (max_num_sequences * sequence_length * (18 * hidden_size + 4 * intermediate_size)) / (1000^3) = ~0,31 GB (estimado).
      • head_dims = hidden_size / num_attention_heads = 5376 / 32 = 168
      • kv_cache_memory_per_batch = (kv_vectors * max_num_sequences * sequence_length * num_key_value_heads * head_dims * num_hidden_layers * kv_data_type_size) / (1000^3) = (2 * 1 * 1700 * 16 * 168 * 62 * 2) / (1000^3) = ~1,13 GB
      • Memória do acelerador necessária = Model weights + Overhead + Activations + KV cache per batch = 54 + 1 + 0,31 + 1,13 = ~56,44 GB

    A memória total estimada do acelerador necessária para implementar o modelo é de aproximadamente 57 GB.

  2. Avalie as opções de acelerador: depois de estimar os requisitos de memória, avalie as opções de GPU e TPU disponíveis no GKE.

    Além da quantidade de memória do acelerador, considere os seguintes requisitos do modelo para a sua avaliação:

    • Para modelos que requerem mais do que um acelerador, verifique a compatibilidade com a conetividade de alta velocidade, como NVLINK e GPUDirect, para reduzir a latência de comunicação.
    • Para modelos quantizados, use aceleradores com aceleração de hardware nativa para tipos de dados de menor precisão, como FP8 e FP4, para obter as maiores vantagens de desempenho.

    A sua escolha envolve uma solução de compromisso entre estas funcionalidades, o desempenho, o custo e a disponibilidade.

    Sugestão: para ver as recomendações mais recentes de aceleradores com base em referências de desempenho da publicação e na análise de custos, também pode usar a ferramenta de início rápido do GKE Inference. Para mais detalhes, consulte a documentação do Início rápido da inferência do GKE.

    Para ajudar a escolher os aceleradores certos para a sua carga de trabalho, a tabela seguinte resume as opções mais adequadas para exemplos de utilização de inferência comuns. Estes exemplos de utilização são definidos da seguinte forma:

    • Inferência de modelos pequenos: para modelos com alguns milhares de milhões de parâmetros, em que a carga computacional se limita a um único anfitrião.
    • Inferência de modelos grandes com um único anfitrião: para modelos com dezenas a centenas de milhares de milhões de parâmetros, em que a carga computacional é partilhada por vários aceleradores numa única máquina anfitriã.
    • Inferência de modelos grandes com vários anfitriões: para modelos com centenas de milhares de milhões a biliões de parâmetros, em que a carga computacional é partilhada por vários aceleradores em várias máquinas anfitriãs.
    Exemplo de utilização Aceleradores recomendados Machine Series Principais caraterísticas
    Inferência de modelos pequenos NVIDIA L4 G2 Opção económica para modelos pequenos (24 GB de memória por GPU).
    NVIDIA RTX Pro 6000 G4 Rentável para modelos com menos de 30 mil milhões de parâmetros e geração de imagens (96 GB de memória por GPU). Suporta a comunicação ponto a ponto direta da GPU, o que a torna adequada para a inferência de vários GPUs num único anfitrião.
    TPU v5e - Otimizada para a rentabilidade.
    TPU v6e - Oferece o valor mais elevado para modelos de transformadores e de texto para imagem.
    Inferência de modelos grandes de anfitrião único NVIDIA A100 A2 Adequado para a maioria dos modelos que cabem num único nó (até 640 GB de memória total).
    NVIDIA H100 A3 Ideal para cargas de trabalho de inferência que cabem num único nó (até 640 GB de memória total).
    NVIDIA B200 A4 Opção preparada para o futuro para modelos exigentes que cabem num único nó (até 1440 GB de memória total).
    TPU v4 - Oferece um bom equilíbrio entre custo e desempenho.
    TPU v5p - Uma opção de elevado desempenho para cargas de trabalho exigentes.
    Inferência de modelos grandes com vários anfitriões NVIDIA H200 A3 Ultra Adequado para modelos grandes que consomem muita memória (até 1128 GB de memória total).
    NVIDIA B200 / GB200 A4 / A4X Para as cargas de trabalho mais exigentes, de computação intensiva e dependentes da rede. As máquinas A4X usam CPUs baseadas em ARM, o que pode exigir a refatoração da carga de trabalho (alterações de código além de uma simples recompilação do contentor) se a sua carga de trabalho usar funcionalidades ou otimizações específicas de x86.
    TPU v5e - Otimizado para a rentabilidade e o desempenho para o serviço de LLMs de médio a grande porte.
    TPU v5p - Uma opção de elevado desempenho para inferência de vários anfitriões que requer paralelização em grande escala.
    TPU v6e - Otimizado para o fornecimento de transformadores, texto para imagem e CNN.

    Exemplo: escolha um acelerador para um modelo de 260 GB

    Imagine que precisa de implementar um modelo que requer 260 GB de memória do acelerador total (200 GB para o modelo, 50 GB para a cache KV e 10 GB para a sobrecarga).

    Com base apenas nos requisitos de memória, pode excluir as GPUs NVIDIA L4, uma vez que a maior máquina G2 oferece um máximo de 192 GB de memória do acelerador. Além disso, uma vez que as GPUs L4 não suportam a conetividade de alta velocidade e baixa latência entre aceleradores, a distribuição da carga de trabalho por vários nós não é uma opção viável para alcançar o desempenho desejado.

    Se quiser evitar a refatoração das suas cargas de trabalho x86-64 (ou seja, ter de modificar o código para que possa ser executado num tipo diferente de processador), também excluiria os aceleradores NVIDIA GB200 e GB300, que usam CPUs baseadas em Arm.

    Isto deixa-lhe as seguintes opções:

    • NVIDIA A100
    • NVIDIA RTX Pro 6000
    • NVIDIA H100
    • NVIDIA H200
    • NVIDIA B200

    Todos estes aceleradores têm memória suficiente. O passo seguinte é avaliar a disponibilidade dos mesmos nas suas regiões de destino. Suponhamos que descobre que apenas as GPUs NVIDIA A100 e NVIDIA H100 estão disponíveis numa determinada região. Depois de comparar a relação preço/desempenho destas duas opções, pode escolher o NVIDIA H100 para a sua carga de trabalho.

    GPUs de várias instâncias

    Para aumentar a utilização da GPU e otimizar os custos da GPU, pode usar configurações de GPU com várias instâncias. Com esta configuração, pode particionar uma GPU suportada para partilhar uma única GPU em vários contentores no GKE. Quando aprovisiona uma GPU multi-instância, anexa apenas GPUs inteiras aos seus nós do GKE e está sujeito aos preços de GPU correspondentes. Recomendamos que use GPUs de várias instâncias apenas com cargas de trabalho fidedignas.

    Por exemplo, pode anexar uma NVIDIA RTX PRO 6000 e fazer o seguinte:

    • Particione-o em quatro instâncias (cada instância oferece 24 GB de memória do acelerador) e execute modelos de difusão ou cargas de trabalho de inferência de modelos pequenos, como modelos que têm aproximadamente 8 mil milhões de parâmetros e usam a precisão do formato de dados FP16 para os pesos dos modelos. Esta partição pode ter uma melhor relação preço/desempenho em comparação com uma NVIDIA L4.
    • Particione-o em duas instâncias (cada instância oferece 48 GB de memória do acelerador) e execute cargas de trabalho de inferência de modelos pequenos, como modelos que têm aproximadamente 15 mil milhões de parâmetros e usam a precisão do formato de dados FP16 para os pesos do modelo. Esta partição pode ser uma alternativa à execução de cargas de trabalho de inferência numa GPU NVIDIA A100 de 40 GB.

    Para mais informações, consulte o artigo Executar GPUs de várias instâncias.

    Para mais informações, consulte os tipos de máquinas com GPU e a família de máquinas otimizada para aceleradores na documentação do Compute Engine.

  3. Selecione uma estratégia de distribuição de inferências: se o seu modelo for demasiado grande para um único acelerador, selecione uma estratégia de distribuição com base nos requisitos da sua carga de trabalho.

    Primeiro, escolha uma estratégia de distribuição com base na topologia do seu hardware:

    • Acelerador único: se o seu modelo couber num único acelerador, esta é a abordagem mais simples e recomendada.
    • Nó único, vários aceleradores: se o seu modelo couber num único nó com vários aceleradores, pode usar o paralelismo de tensores para distribuir o modelo pelos aceleradores nesse nó.
    • Vários nós, vários aceleradores: se o seu modelo for demasiado grande para um único nó, pode usar uma combinação de paralelismo de tensores e de pipelines para o distribuir por vários nós.

    Para implementar estas estratégias, pode usar as seguintes técnicas de paralelismo:

    • Paralelismo de tensores: esta técnica divide as camadas de um modelo em vários aceleradores. É altamente eficaz num único nó com interconexões de alta velocidade, como NVLINK ou PCIe direto ponto a ponto, mas requer uma comunicação significativa entre os aceleradores.

      Exemplo: paralelismo de tensores

      Por exemplo, considere que precisa de implementar um modelo com 109 mil milhões de parâmetros. Na sua precisão BF16 (16 bits) predefinida, o carregamento dos pesos do modelo na memória do acelerador requer aproximadamente 113 GB. Uma única GPU NVIDIA H100 oferece 80 GB de memória. Por conseguinte, mesmo sem ter em conta outros requisitos de memória, como a cache KV, precisa de, pelo menos, duas GPUs NVIDIA H100 para carregar o modelo, usando um tamanho de paralelismo de tensores de dois.

    • Paralelismo de pipeline: esta técnica divide as camadas de um modelo sequencialmente em vários nós. É adequado para distribuir um modelo por vários nós numa implementação de vários anfitriões e requer menos comunicação entre as classificações do modelo do que o paralelismo de tensores.

      Exemplo: paralelismo híbrido (tensor e pipeline)

      Para um modelo muito grande com mais de 600 mil milhões de parâmetros, o requisito de memória pode exceder 1,1 TB. Num cenário com 2 nós a3-megagpu-8g (cada um com 8 GPUs NVIDIA H100), o cluster total tem 1,28 TB de memória do acelerador. Para executar o modelo, implementaria uma estratégia híbrida: paralelismo de tensores de 8 vias em cada nó e paralelismo de pipeline de 2 vias nos dois nós. O modelo seria dividido em duas fases, com a primeira metade das camadas no primeiro nó e a segunda metade no segundo nó. Quando chega um pedido, o primeiro nó processa-o e envia os dados intermédios através da rede para o segundo nó, que conclui o cálculo.

    Para ver mais diretrizes sobre a escolha de uma estratégia de inferência distribuída para uma réplica de modelo único, consulte Paralelismo e escalabilidade na documentação do vLLM.

  4. Selecione um tipo de máquina otimizado para aceleradores: com base na sua escolha de acelerador e no número de aceleradores de que precisa, selecione um tipo de máquina que forneça esses recursos. Cada tipo de máquina oferece uma combinação específica de vCPUs, memória do sistema e largura de banda da rede, o que também pode afetar o desempenho da sua carga de trabalho. Por exemplo, se precisar de 16 GPUs NVIDIA H100, selecionaria o tipo de máquina a3-megagpu-16g.

  5. Execute as suas próprias referências: o desempenho da sua carga de trabalho de inferência depende muito do seu exemplo de utilização específico. Execute as suas próprias referências para validar as suas escolhas e otimizar a configuração.

Otimize a configuração do seu servidor de inferência

Para alcançar o desempenho ideal quando implementa a sua carga de trabalho de inferência, recomendamos um ciclo de testes de referência e ajuste:

  1. Comece com o início rápido da inferência do GKE para obter uma configuração do Kubernetes de base otimizada para o seu exemplo de utilização.
  2. Execute testes de referência para captar as métricas de débito e latência de base.
  3. Ajuste a configuração do servidor de inferência.
  4. Execute novamente testes de referência e compare os resultados para validar as alterações.

As seguintes recomendações baseiam-se no servidor de inferência vLLM, mas os princípios também se aplicam a outros servidores. Para receber orientações detalhadas sobre todas as definições disponíveis, consulte a documentação Otimização e ajuste do vLLM:

  • Configurar paralelismo:
    • Paralelismo de tensores (tensor_parallel_size): defina este valor para o número de aceleradores num único nó para dividir a carga de trabalho. Por exemplo, a definição tensor_parallel_size=4 distribui a carga de trabalho por quatro aceleradores. Tenha em atenção que o aumento deste valor pode levar a uma sobrecarga de sincronização excessiva.
    • Paralelismo de pipelines (pipeline_parallel_size): defina este valor para o número de nós nos quais está a distribuir o seu modelo. Por exemplo, se estiver a implementar em dois nós com oito aceleradores cada, deve definir tensor_parallel_size=8 e pipeline_parallel_size=2. Aumentar este valor pode introduzir penalizações de latência.
  • Ajuste a cache KV (gpu_memory_utilization): este parâmetro controla a percentagem de memória da GPU reservada para os pesos do modelo, as ativações e a cache KV. Um valor mais elevado aumenta o tamanho da cache KV e pode melhorar o débito. Recomendamos que defina este valor entre 0.9 e 0.95. Se encontrar erros de falta de memória (OOM), diminua este valor.
  • Configurar o comprimento máximo do contexto (max_model_len): para reduzir o tamanho da cache KV e os requisitos de memória, pode definir um comprimento máximo do contexto inferior ao predefinido do modelo. Isto permite-lhe usar GPUs mais pequenas e rentáveis. Por exemplo, se o seu exemplo de utilização só precisar de um contexto de 40 000 tokens, mas o valor predefinido do seu modelo for 256 000, definir max_model_len como 40 000 liberta memória para uma cache KV maior, o que pode levar a um débito mais elevado.
  • Configure o número de pedidos simultâneos (max_num_batched_tokens, max_num_seqs): ajuste o número máximo de pedidos que o vLLM processa em simultâneo para evitar a preempção quando a cache KV tem pouco espaço. Os valores mais baixos para max_num_batched_tokens e max_num_seqs reduzem os requisitos de memória, enquanto os valores mais elevados podem melhorar o débito ao risco de erros de falta de memória. Para encontrar os valores ideais, recomendamos que execute experiências de desempenho e observe o número de pedidos de preemptção nas métricas do Prometheus que o vLLM exporta.

Para obter mais informações, consulte os seguintes recursos:

Otimize em função da latência e da disponibilidade

Para garantir que o seu serviço de inferência é reativo e fiável, tem de o otimizar para uma baixa latência de arranque e uma elevada disponibilidade de recursos.

Otimize a latência de início a frio da carga de trabalho de inferência

Minimizar o tempo que as cargas de trabalho de inferência demoram a iniciar é fundamental para a rentabilidade e a experiência do utilizador. Uma latência de arranque a frio baixa permite que o cluster seja dimensionado rapidamente para satisfazer a procura, garantindo um serviço com capacidade de resposta e minimizando a necessidade de aprovisionamento excessivo dispendioso.

Otimize o tempo de arranque do agrupamento

O tempo que um pod demora a ficar pronto é determinado, em grande parte, pelo tempo que demora a extrair a imagem do contentor e a transferir os pesos do modelo. Para otimizar ambos, considere as seguintes estratégias:

  • Acelere o carregamento do modelo com um carregador de dados otimizado: o método que usa para armazenar e carregar os pesos do modelo tem um impacto significativo no tempo de arranque. Para as versões 0.10.2 e posteriores do vLLM, a abordagem recomendada é usar o Run:ai Model Streamer para carregar modelos através do streaming direto a partir de um contentor do Cloud Storage.

    Se o streamer não estiver disponível para o seu exemplo de utilização, pode montar um contentor do Cloud Storage através do Cloud Storage FUSE e otimizar o respetivo desempenho ativando os namespaces hierárquicos e usando técnicas como pré-obtenção e transferências paralelas. Para saber mais acerca destas técnicas, consulte o artigo Otimize o controlador CSI FUSE do Cloud Storage para o desempenho do GKE. Em qualquer dos casos, recomendamos que use a cache em qualquer lugar para criar caches de leitura zonais de alto desempenho para os seus contentores e que ative o acesso uniforme ao nível do contentor para controlar uniformemente o acesso aos seus contentores.

    Se já estiver a usar o Managed Lustre para o armazenamento de ficheiros de alto desempenho para as suas cargas de trabalho de preparação, também o pode usar para carregar ponderações do modelo para inferência. Esta abordagem oferece acesso de baixa latência quando a localidade dos dados e a compatibilidade com POSIX são essenciais.

  • Ative a stream de imagens: para reduzir o tempo necessário para extrair as imagens dos contentores, ative a stream de imagens no cluster do GKE. O streaming de imagens permite que os seus contentores sejam iniciados antes de a imagem completa ser transferida, o que pode reduzir drasticamente o tempo de arranque do pod.

Ative os nós de início rápido

Para cargas de trabalho que requerem um escalonamento rápido, pode tirar partido dos nós de início rápido no GKE. Os nós de início rápido são recursos de hardware pré-inicializados que têm um tempo de início significativamente mais curto do que os nós padrão. Se o cluster cumprir os requisitos, o GKE ativa automaticamente os nós de início rápido.

Planeie a capacidade e maximize a obtenção de aceleradores

Os aceleradores de elevada procura, como as GPUs e as TPUs, podem ter uma disponibilidade limitada, pelo que é essencial uma estratégia de planeamento de capacidade proativa.

Planeie e reserve capacidade

Os aceleradores de elevada procura podem ter uma disponibilidade limitada, pelo que é essencial uma estratégia de planeamento de capacidade proativa. Para garantir o acesso aos recursos de que precisa, siga estas recomendações:

  • Determine a base de referência da capacidade e o processamento de picos: planeie a capacidade do acelerador de base de referência que precisa de reservar. O valor a reservar depende do seu exemplo de utilização. Por exemplo, pode reservar 100% da capacidade necessária para cargas de trabalho críticas sem tolerância para atrasos ou pode reservar um determinado percentil (como o 90.º ou o 95.º) e adquirir o resto a pedido para processar picos.

  • Reserve a capacidade de base: para obter recursos com um elevado nível de garantia, crie reservas. Pode escolher um tipo de reserva com base nas suas necessidades. Por exemplo, para reservar recursos de elevada procura, como aceleradores, para um período futuro específico, pode criar reservas futuras no modo de calendário.

  • Orquestre a capacidade para picos: para a procura que exceda as suas reservas de base, pode implementar uma estratégia alternativa com outros tipos de capacidade, como a capacidade a pedido, as VMs Spot ou o Dynamic Workload Scheduler (DWS). Pode automatizar esta estratégia alternativa através das classes de computação personalizadas para definir uma ordem de prioridade para o aprovisionamento de diferentes tipos de capacidade.

  • Aceda a preços com desconto: para a sua capacidade de base, compre descontos por fidelização (CUDs) para receber preços significativamente reduzidos em troca de um compromisso de um ou três anos.

Use o programador de carga de trabalho dinâmico com o modo de aprovisionamento de início flexível se as suas cargas de trabalho tolerarem atrasos na aquisição de capacidade

Para cargas de trabalho que podem tolerar algum atraso na aquisição de capacidade, o Dynamic Workload Scheduler (DWS) com o modo de aprovisionamento de início flexível é uma opção para obter aceleradores a um preço com desconto. O DWS permite-lhe colocar pedidos de capacidade em fila durante um máximo de sete dias.

Quando usar o DWS com o modo de aprovisionamento de início flexível, recomendamos o seguinte:

  • Incorporá-lo numa classe de computação personalizada: use uma classe de computação personalizada para definir o DWS como parte de uma estratégia de alternativa prioritária para adquirir capacidade.
  • Defina uma duração máxima de tempo de execução: o parâmetro maxRunDurationSeconds define o tempo de execução máximo para nós pedidos através do DWS. Se definir este valor para um valor inferior ao predefinido de sete dias, pode aumentar as suas hipóteses de obter os nós pedidos.
  • Ative a reciclagem de nós: para evitar o tempo de inatividade das suas cargas de trabalho, ative a reciclagem de nós. Esta funcionalidade começa a aprovisionar um novo nó antes de o antigo expirar, garantindo uma transição mais suave.
  • Minimize as interrupções: para minimizar as interrupções da remoção e das atualizações de nós, configure janelas de manutenção e exclusões, desative a autorreparação de nós e tire partido da estratégia de atualizações de curta duração.

Use classes de computação personalizadas

As classes de computação personalizadas (CCCs) são uma funcionalidade do GKE que lhe permite definir uma lista prioritária de configurações de infraestrutura para as suas cargas de trabalho. Os CCCs oferecem capacidades importantes concebidas para melhorar a obtenção de aceleradores:

  • Prioridades de computação alternativas: pode definir uma lista prioritária de configurações. Se a sua opção preferencial não estiver disponível durante um evento de expansão, o redimensionador automático recorre automaticamente à seguinte na lista, o que aumenta significativamente a probabilidade de adquirir capacidade com êxito.
  • Migração ativa para nós de prioridade mais elevada: quando configura esta funcionalidade, o GKE substitui automaticamente os nós executados em configurações de prioridade mais baixa por nós de configurações de prioridade mais elevada à medida que ficam disponíveis. Isto ajuda a garantir que os seus pods são executados nos nós mais preferidos (e, muitas vezes, mais rentáveis).

Com as classes de computação personalizadas (CCCs), pode criar uma estratégia alternativa para adquirir nós. Esta estratégia usa uma lista prioritária de diferentes tipos de capacidade, como VMs a pedido, VMs Spot ou reservas. Cada um destes tipos de capacidade tem um nível de disponibilidade diferente:

  • Reservas: oferecem o nível de garantia mais elevado para obter capacidade. Ao consumir reservas com CCCs, tenha em atenção as respetivas restrições. Por exemplo, alguns tipos de reservas limitam os tipos de máquinas que pode reservar ou o número máximo de máquinas que pode pedir.
  • A pedido: o modelo de aprovisionamento padrão, que oferece flexibilidade, mas pode estar sujeito a restrições de capacidade regionais para recursos de elevada procura.
  • VMs do Spot: use capacidade disponível a um preço mais baixo, mas podem ser anuladas. Quando ocorre um evento de preempção, o GKE oferece um período de encerramento elegante de até 30 segundos aos pods afetados com base no melhor esforço. Para tirar partido desta funcionalidade, torne as suas cargas de trabalho tolerantes a eventos de preemptção implementando checkpoints e mecanismos de repetição.
  • Dynamic Workload Scheduler (DWS): permite colocar em fila pedidos de recursos escassos a preços com desconto. Esta funcionalidade é ideal para cargas de trabalho que podem tolerar atrasos na aquisição de capacidade.

A ordem da lista de prioridades deve mudar consoante o objetivo principal seja minimizar a latência ou otimizar em função do custo. Por exemplo, pode configurar as seguintes listas de prioridades para diferentes requisitos de carga de trabalho:

Prioridade Cargas de trabalho de baixa latência Cargas de trabalho otimizadas em função dos custos (tolerantes à latência)
1 Reservas (específicas e, em seguida, quaisquer) Reservas (específicas e, em seguida, quaisquer)
2 A pedido VMs do Spot
3 VMs do Spot Dynamic Workload Scheduler
4 Dynamic Workload Scheduler A pedido

Para exemplos de utilização de baixa latência, a capacidade a pedido é prioritária após as reservas, porque comunica rapidamente as escassez de capacidade, o que permite que o CCC recorra rapidamente à opção seguinte.

Para exemplos de utilização otimizados em função dos custos, as VMs Spot e as DWS com início flexível têm prioridade após as reservas para tirar partido dos custos mais baixos. A capacidade a pedido é usada como alternativa final.

Configure a política de localização dos seus clusters do GKE e node pools

A política de localização do redimensionador automático de clusters controla a forma como o GKE distribui os nós pelas zonas durante um evento de expansão. Esta definição é particularmente importante quando usa classes de computação personalizadas, porque determina as zonas que o redimensionador automático de clusters vai considerar antes de aplicar a lista de prioridades das CCCs.

Para melhorar as suas hipóteses de obter aceleradores, configure a política de localização com base nos requisitos da sua carga de trabalho:

  • location-policy=ANY: dá prioridade à obtenção de capacidade em vez de equilibrar os nós uniformemente entre zonas. Esta definição é particularmente relevante quando o CCC inclui VMs de spot ou tipos de máquinas com disponibilidade variável, uma vez que ANY permite que o Cluster Autoscaler escolha a zona com a maior probabilidade de satisfazer os tipos de nós prioritários do CCC. Use esta definição também para dar prioridade à utilização de reservas não utilizadas. Quando usar esta política, recomendamos que comece com num-nodes=0 para dar ao Cluster Autoscaler a máxima flexibilidade na procura de capacidade.

  • location-policy=BALANCED: tenta distribuir os nós uniformemente por todas as zonas disponíveis. Use esta política quando as suas cargas de trabalho usam recursos facilmente obteníveis e quer manter a redundância zonal para alta disponibilidade.

Pode configurar esta definição quando criar ou atualizar um conjunto de nós.

Otimize em função da eficiência e do custo

Ao monitorizar cuidadosamente os aceleradores e dimensionar de forma inteligente as cargas de trabalho, pode reduzir significativamente o desperdício e diminuir os custos operacionais.

Observe os seus aceleradores e servidores de inferência

Uma estratégia de observabilidade abrangente é essencial para compreender o desempenho e a utilização das suas cargas de trabalho de inferência. O GKE oferece um conjunto de ferramentas para ajudar a monitorizar os aceleradores e os servidores de inferência:

  • Monitorize as métricas do DCGM para GPUs NVIDIA: para monitorizar o estado e o desempenho das suas GPUs NVIDIA, configure o GKE para enviar métricas do NVIDIA Data Center GPU Manager (DCGM) para o Cloud Monitoring.
  • Ative a monitorização automática de aplicações: para simplificar o processo de monitorização dos seus servidores de inferência, ative a monitorização automática de aplicações no GKE.
  • Instrumente as suas cargas de trabalho com o OpenTelemetry: para cargas de trabalho que não são suportadas pela monitorização automática de aplicações, use o OpenTelemetry para recolher métricas e rastreios personalizados.

Dimensione automaticamente os seus pods

Para garantir que as suas cargas de trabalho de inferência se podem adaptar dinamicamente às alterações na procura, use um redimensionador automático de pods horizontal (HPA) para dimensionar automaticamente o número de pods. Para cargas de trabalho de inferência, é essencial basear as suas decisões de escalamento em métricas que reflitam diretamente a carga no servidor de inferência, em vez de métricas padrão de CPU ou memória.

Para configurar o escalamento automático para as suas cargas de trabalho de inferência, recomendamos o seguinte:

  • Configure o HPA com base em métricas com reconhecimento de inferência: para um desempenho ideal, configure o HPA para ser dimensionado com base em métricas do seu servidor de inferência. A melhor métrica depende de estar a fazer a otimização em função da baixa latência ou do elevado débito.

    • Para cargas de trabalho sensíveis à latência, tem duas opções principais:

      • Utilização da cache de KV (por exemplo, vllm:gpu_cache_usage_perc): esta métrica é frequentemente o melhor indicador de picos de latência iminentes. A elevada utilização da cache KV indica que o motor de inferência está a aproximar-se da capacidade máxima. O HPA pode usar este sinal para adicionar antecipadamente réplicas e manter uma experiência do utilizador estável.
      • Número de pedidos em execução (tamanho do lote) (por exemplo,vllm:num_requests_running): esta métrica está diretamente relacionada com a latência, uma vez que os tamanhos dos lotes mais pequenos resultam normalmente numa latência inferior. No entanto, usá-lo para criar uma escala automática pode ser difícil, porque a maximização da taxa de transferência depende do tamanho dos pedidos recebidos. Pode ter de escolher um valor inferior ao tamanho do lote máximo possível para garantir que o HPA é dimensionado adequadamente.

    • Para cargas de trabalho sensíveis ao débito, faça o escalonamento com base no tamanho da fila (por exemplo, vllm:num_requests_waiting). Esta métrica mede diretamente o atraso no trabalho e é uma forma simples de fazer corresponder a capacidade de processamento à procura recebida. Uma vez que esta métrica só considera os pedidos que estão em espera e não os que estão a ser processados, pode não atingir a latência mais baixa possível em comparação com o escalamento com base no tamanho do lote.

  • Defina um número mínimo de réplicas: para garantir uma disponibilidade consistente e uma experiência do utilizador de base, defina sempre um número mínimo de réplicas para a sua implementação de inferência.

  • Ative o perfil de HPA de desempenho: nas versões do GKE 1.33 ou posteriores, o perfil de HPA de desempenho está ativado por predefinição nos clusters elegíveis para melhorar o tempo de reação do HPA.

Para mais informações, consulte os artigos Configure o HPA para cargas de trabalho de GMLs em GPUs e Aumente/diminua automaticamente a escala das cargas de trabalho de inferência de GMLs em TPUs.

Mova os dados para mais perto das suas cargas de trabalho

O tempo que as cargas de trabalho demoram a carregar dados, como as ponderações dos modelos, pode ser uma fonte significativa de latência. Ao aproximar os dados dos recursos de computação, pode reduzir os tempos de transferência de dados e melhorar o desempenho geral.

  • Crie caches de leitura zonais com a cache em qualquer lugar: se usar o Cloud Storage para armazenar dados para as suas cargas de trabalho de IA/AM, ative a cache em qualquer lugar. A cache em qualquer lugar cria caches de leitura zonais de elevado desempenho para os seus contentores do Cloud Storage.
  • Coloque em cache os dados acedidos com frequência em SSDs locais: para cargas de trabalho que exijam acesso de latência extremamente baixa a dados temporários, use SSDs locais como uma cache de alto desempenho. A utilização de SSDs locais como armazenamento temporário de baixa latência para guardar dados usados com frequência ajuda a reduzir o tempo de inatividade de recursos dispendiosos, como aceleradores, reduzindo drasticamente o tempo que os aceleradores esperam que as operações de E/S sejam concluídas. Tenha em atenção que nem todas as séries de máquinas suportam SSDs locais, o que pode afetar a sua escolha de aceleradores.
  • Faça a gestão das caches com a GKE Data Cache: para cargas de trabalho que leem dados com frequência de discos persistentes, ative a GKE Data Cache. A cache de dados do GKE usa SSDs locais para criar uma cache gerida de elevado desempenho para os seus discos persistentes. Para a maioria das cargas de trabalho de produção, recomendamos a utilização do modo Writethrough para evitar a perda de dados escrevendo dados de forma síncrona na cache e no disco persistente subjacente.

Otimize para arquiteturas de escalabilidade avançadas

Para satisfazer as exigências de aplicações de grande escala ou distribuídas globalmente, pode adotar arquiteturas de escalabilidade avançadas para melhorar o desempenho, a fiabilidade e a gestão do tráfego.

Equilibre a carga do tráfego com o GKE Inference Gateway

Para cargas de trabalho de inferência num único cluster, recomendamos a utilização do GKE Inference Gateway. O Inference Gateway é um equilibrador de carga com reconhecimento de IA que monitoriza as métricas de inferência para encaminhar pedidos para o ponto final mais otimizado. Esta funcionalidade melhora o desempenho e a utilização do acelerador.

Quando usar o GKE Inference Gateway, recomendamos que siga estas práticas recomendadas:

  • Agrupe a publicação de agrupamentos num InferencePool: defina um InferencePool para cada grupo de agrupamentos que publicam as suas cargas de trabalho de inferência. Para mais informações, consulte o artigo Personalize a configuração do GKE Inference Gateway.
  • Multiplexar cargas de trabalho críticas para a latência: defina InferenceObjectives para especificar as propriedades de publicação do seu modelo, como o nome e a prioridade. O GKE Inference Gateway dá preferência a cargas de trabalho com uma prioridade mais elevada, o que lhe permite multiplexar cargas de trabalho críticas para a latência e tolerantes à latência, bem como implementar políticas de redução de carga durante períodos de tráfego intenso.
  • Usar o encaminhamento com reconhecimento do modelo: para encaminhar pedidos com base no nome do modelo no corpo do pedido, use o encaminhamento baseado no corpo. Quando usa o encaminhamento baseado no corpo, certifique-se de que os seus back-ends estão altamente disponíveis. O gateway devolve um erro se a extensão não estiver disponível, o que impede o encaminhamento incorreto de pedidos.
  • Permita que a gateway distribua automaticamente o tráfego: A GKE Inference Gateway encaminha o tráfego de forma inteligente monitorizando as principais métricas dos servidores de inferência no InferencePool, como a utilização da cache KV, o comprimento da fila e os índices da cache de prefixos. Este equilíbrio de carga em tempo real otimiza a utilização do acelerador, reduz a latência final e aumenta o débito geral em comparação com os métodos tradicionais.
  • Integre com o Apigee e o Model Armor: para uma segurança e uma gestão melhoradas, integre com o Apigee para a gestão de APIs e com o Model Armor para verificações de segurança.

Implemente cargas de trabalho de inferência em vários nós

Para modelos muito grandes que não cabem num único nó, tem de distribuir a carga de trabalho de inferência por vários nós. Isto requer uma arquitetura que minimize a latência de comunicação entre nós e garanta que todos os componentes da carga de trabalho distribuída são geridos como uma única unidade.

Tenha em conta estas práticas recomendadas:

  • Maximize a largura de banda e o débito da rede do acelerador: quando uma carga de trabalho é distribuída por vários nós, a rede torna-se um fator de desempenho crítico. Para minimizar a latência de comunicação entre nós, use tecnologias de rede de alto desempenho, como o NVIDIA GPUDirect. Consoante a escala do cluster e a intensidade da comunicação exigida pela carga de trabalho, pode escolher entre as seguintes opções:

    • GPUDirect-TCPX: eficaz para uma variedade de cargas de trabalho de inferência de vários nós executadas no A3 High.
    • GPUDirect-TCPXO: oferece um desempenho melhorado com maior descarregamento e largura de banda mais elevada, o que é benéfico para clusters maiores em comparação com o TCPX padrão, e é executado em máquinas A3 Mega.
    • GPUDirect RDMA: oferece a largura de banda entre nós mais elevada e a latência mais baixa, permitindo o acesso direto à memória entre GPUs em diferentes nós, ignorando a CPU, e é mais adequado para os cenários de inferência mais exigentes e de grande escala em máquinas A3 Ultra e A4.

    Para mais informações, consulte:

    Para validar se a configuração de rede com vários nós está a ter o desempenho esperado, recomendamos que execute testes com ferramentas como a NVIDIA Collective Communications Library (NCCL).

  • Use LeaderWorkerSet para gerir cargas de trabalho distribuídas: quando implementa uma carga de trabalho distribuída com estado, como um serviço de inferência de vários nós, é essencial gerir todos os respetivos componentes como uma única unidade. Para tal, use o LeaderWorkerSet, uma API nativa do Kubernetes que lhe permite gerir um grupo de Pods relacionados como uma única entidade. Um LeaderWorkerSet garante que todos os pods no conjunto são criados e eliminados em conjunto, o que é fundamental para manter a integridade de uma carga de trabalho distribuída.

  • Coloque nós em proximidade física através do posicionamento compacto: a distância física entre os nós na sua carga de trabalho distribuída pode ter um impacto significativo na latência da rede entre nós. Para minimizar esta latência, use uma política de posicionamento compacta para os seus conjuntos de nós do GKE. Uma política de posicionamento compacto indica ao GKE que posicione os nós num conjunto de nós o mais próximos possível uns dos outros numa zona.

Implemente cargas de trabalho de inferência em várias regiões

Para aplicações distribuídas globalmente que requerem elevada disponibilidade e baixa latência, a implementação das cargas de trabalho de inferência em várias regiões é uma prática recomendada essencial. Uma arquitetura multirregião pode ajudar a aumentar a fiabilidade, melhorar a obtenção de aceleradores, reduzir a latência percebida pelo utilizador e cumprir os requisitos regulamentares específicos da localização.

Para implementar e gerir eficazmente um serviço de inferência multirregional, siga estas recomendações:

  • Aprovisione clusters do GKE em várias regiões onde tem capacidade reservada ou prevê precisar de capacidade para processar cargas máximas.
  • Escolha a estratégia de armazenamento certa para os pesos do modelo. Para otimizar a eficiência operacional, crie um contentor do Cloud Storage multirregional. Para otimizar os custos, crie um contentor regional em cada região e replique os pesos do modelo.
  • Use a cache em qualquer lugar para criar caches de leitura zonais para os seus contentores do Cloud Storage, de modo a reduzir a latência da rede e os custos de saída de dados.

Resumo das práticas recomendadas

A tabela seguinte resume as práticas recomendadas neste documento:

Tópico Tarefa
Implementação e configuração
  • Analise as caraterísticas do seu exemplo de utilização de inferência
  • Escolha os modelos certos para os seus exemplos de utilização de inferência
  • Aplique a quantização ao modelo
  • Escolha os aceleradores certos
  • Escolha a sua estratégia de distribuição de inferências
  • Otimize a configuração do seu servidor de inferência
Latência de início a frio
  • Otimize o tempo de arranque do agrupamento
  • Ative nós de início rápido
Planeamento de capacidade e obtenção de aceleradores
  • Planeie e reserve capacidade
  • Use o Dynamic Workload Scheduler
  • Use classes de computação personalizadas
  • Configure a política de localização dos seus clusters do GKE e conjuntos de nós
Eficiência dos recursos e do acelerador
  • Observe os seus aceleradores e servidores de inferência
  • Aumente automaticamente a escala dos seus pods
  • Mova os dados para mais perto das suas cargas de trabalho
Balanceamento de carga
  • Use o GKE Inference Gateway para implementações de cluster único
Implementações de vários nós
  • Maximize a largura de banda e o débito da rede do acelerador
  • Use LeaderWorkerSet para agrupar pods
  • Coloque nós em proximidade física através do posicionamento compacto
Implementações multirregionais
  • Aprovisione clusters do GKE em várias regiões
  • Equilibre o tráfego entre regiões
  • Armazene os pesos dos modelos em contentores do Cloud Storage
  • Dados da cache com a cache em qualquer lugar

O que se segue?