Visão geral das práticas recomendadas de inferência no GKE

Neste documento, apresentamos uma visão geral das práticas recomendadas para executar cargas de trabalho de inferência no GKE.

Este documento é destinado a administradores de dados, operadores e desenvolvedores que querem adotar as práticas recomendadas para as cargas de trabalho de inferência usando aceleradores, como GPUs e TPUs, com o Kubernetes e o GKE. Para saber mais sobre papéis comuns, consulte Tarefas e papéis de usuário comuns do GKE.

Para uma visão geral consolidada de todas as práticas recomendadas do GKE, consulte Práticas recomendadas para o GKE.

Preparar-se para a disponibilização de inferência no GKE

Nesta seção, descrevemos as práticas recomendadas básicas que você precisa seguir ao se preparar para implantar uma carga de trabalho de inferência. Essas práticas incluem analisar seu caso de uso, escolher modelos e selecionar aceleradores.

Analisar as características do seu caso de uso de inferência

Antes de implantar uma carga de trabalho de inferência, analise os requisitos específicos dela. Essa análise ajuda você a tomar decisões de arquitetura que equilibram desempenho, custo e confiabilidade. Entender seu caso de uso ajuda a selecionar os modelos, aceleradores e configurações adequados para atender aos objetivos de nível de serviço (SLOs).

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

  • Defina os requisitos de desempenho e latência: determine os SLOs do aplicativo para latência e capacidade de processamento. As principais métricas a serem definidas incluem solicitações por segundo (RPS), latência de resposta, tamanho do token de entrada e saída e taxa de ocorrência em cache de prefixo. Para mais informações, consulte Métricas de performance de inferência.
  • Avalie os requisitos e a escala do modelo: as características do modelo escolhido influenciam diretamente suas necessidades de infraestrutura. Considere o tamanho máximo do contexto que o modelo aceita e compare-o com o que sua carga de trabalho exige. Se o caso de uso não exigir o contexto máximo, reduzir o tamanho máximo do contexto pode liberar memória do acelerador para um cache KV maior, o que pode aumentar a capacidade de processamento.
  • Estabeleça restrições de custo e de negócios: seu orçamento e seus objetivos de negócios são fatores essenciais para projetar um serviço de inferência sustentável e econômico. Defina o custo por milhão de tokens desejado para entrada e saída e o orçamento mensal total para essa carga de trabalho. Identifique sua meta de otimização, como custo-benefício, menor latência ou maior capacidade de processamento, e se o app pode tolerar latência variável.

Escolher os modelos certos para seus casos de uso de inferência

A seleção do modelo certo afeta diretamente o desempenho, o custo e a viabilidade do aplicativo 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 tarefas designadas e nas modalidades compatíveis. Um modelo otimizado para uma tarefa específica quase sempre supera um modelo de uso geral.
  • Características técnicas: a arquitetura de um modelo e a precisão do tipo de dados, como FP16, FP8 e FP4, são fatores importantes para determinar os requisitos de recursos e o desempenho. Essa avaliação ajuda a determinar se é necessário aplicar técnicas de quantização. Verifique a precisão aceita para os pesos do modelo, garanta o suporte ao framework e verifique o tamanho máximo do contexto aceito pelo modelo.
  • Desempenho e custo-benefício: para tomar uma decisão baseada em dados, compare os modelos selecionados usando comparativos de mercado disponíveis publicamente e seus próprios testes internos. Use rankings como o Chatbot Arena para comparar modelos e avaliar o custo por milhão de tokens de cada modelo no hardware de destino.

Aplicar quantização ao modelo

A quantização é uma técnica para otimizar suas cargas de trabalho de inferência reduzindo o consumo de memória do modelo. Ele converte os pesos, as ativações e o cache de chave-valor (KV) do modelo de formatos de usar pontos flutuantes de alta precisão (como FP16, FP32 e FP64) para formatos de menor precisão (como FP8 e FP4). Essa redução na memória pode levar a melhorias significativas no desempenho e na relação custo-benefício.

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

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

  • Avalie o impacto na acurácia: a quantização às vezes pode resultar em uma perda de acurácia do modelo. Ao avaliar o impacto da quantização na precisão, considere que a quantização de 8 bits geralmente resulta em uma perda mínima de precisão. Por outro lado, a quantização de 4 bits pode reduzir em até quatro vezes os requisitos de memória do acelerador, mas também pode causar uma perda maior de precisão em comparação com a quantização de 8 bits. Avalie o desempenho do modelo quantizado no seu caso de uso específico para garantir que a precisão ainda esteja dentro de um intervalo aceitável. Para avaliar a perda de acurácia, use ferramentas como o OpenCompass e o Language Model Evaluation Harness.
  • Avaliar o suporte à aceleração de hardware: para aproveitar ao máximo a quantização, use aceleradores que ofereçam aceleração de hardware para os formatos de dados usados pelo modelo quantizado. 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.
    • O Cloud TPU v5p oferece aceleração de hardware para operações FP8.
  • Verifique se há modelos pré-quantizados: antes de quantizar um modelo, verifique repositórios de modelos públicos, como o Hugging Face. O ideal é encontrar um modelo que tenha sido treinado nativamente com uma precisão menor, já que isso pode oferecer benefícios de desempenho sem a possível perda de acurácia da quantização pós-treinamento.
  • Use uma biblioteca de quantização: se um modelo pré-quantizado não estiver disponível, use uma biblioteca para realizar a quantização por conta própria. Servidores de inferência como o vLLM oferecem suporte à execução de modelos que foram quantizados com uma variedade de técnicas. É possível usar ferramentas como o llm-compressor para aplicar técnicas de quantização a um modelo não quantizado.
  • Considere a quantização de cache KV: além de quantizar os pesos do modelo, também é possível quantizar o cache KV. Essa técnica reduz ainda mais a memória necessária para o cache de chave-valor no momento da execução, o que pode melhorar o desempenho.

Para mais informações, consulte Otimizar cargas de trabalho de inferência de LLM em GPUs.

Escolha os aceleradores certos

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

Para escolher o acelerador certo para seu caso de uso específico, siga estas etapas:

  1. Calcule os requisitos de memória: primeiro, calcule a memória mínima do acelerador necessária para carregar e executar o modelo. A memória total é a soma da memória necessária para os pesos do modelo, a sobrecarga do mecanismo de inferência, as ativações intermediárias e o cache de chave-valor.

    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 da equação são os seguintes:

    • Pesos do modelo: o tamanho dos parâmetros do modelo.
    • Sobrecarga: um buffer para o servidor de inferência e outras sobrecargas do sistema, normalmente de 1 a 2 GB.
    • Ativação: a memória necessária para ativações intermediárias durante a execução de um modelo.
    • Cache de KV por lote: a memória necessária para o cache de KV de uma única sequência, que é dimensionada de acordo com o tamanho do contexto e a configuração do modelo.
    • Tamanho do lote: o número de sequências (max_num_sequences) que serão processadas simultaneamente pelo mecanismo de inferência.

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

    Para calcular a memória do acelerador necessária para implantar um modelo de 27 bilhões de parâmetros do Gemma 3 com uma precisão de BF16 para um caso de uso de geração de texto, use os valores a seguir.

    Para um tutorial interativo desse cálculo, consulte De quanta VRAM meu modelo precisa? notebook do Colab.

    • Entradas:
      • Pesos do modelo: 54 GB
      • Tamanho do lote (max_num_sequences): 1
      • Tamanho médio da entrada: 1.500 tokens
      • Tamanho médio da saída: 200 tokens
      • Sobrecarga do mecanismo de inferência: 1 GB (estimado)
      • Tamanho do tipo de dados do cache de KV: 2 (para BF16)
      • Vetores de chave-valor: 2 (um para chave, um para valor)
    • Configuração do modelo para um modelo Gemma 3 27B ajustado por instruções:
      • hidden_size: 5376
      • intermediate_size: 21504
      • num_attention_heads: 32
      • num_hidden_layers: 62
      • num_key_value_heads: 16
    • Cálculo de memória:
      • sequence_length = avg_input_length + avg_output_length = 1.500 + 200 = 1.700 tokens
      • 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 implantar 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 de modelo para sua avaliação:

    • Para modelos que exigem mais de um acelerador, verifique se há suporte para conectividade 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 aproveitar ao máximo os benefícios de desempenho.

    Sua escolha envolve uma compensação entre esses recursos, desempenho, custo e disponibilidade.

    Dica: para as recomendações mais recentes de aceleradores com base em comparativos de mercado de desempenho de exibição e análise de custos, use também a ferramenta de início rápido do GKE Inference. Para mais detalhes, consulte a documentação do Guia de início rápido do GKE Inference.

    Para ajudar você a escolher os aceleradores certos para sua carga de trabalho, a tabela a seguir resume as opções mais adequadas para casos de uso de inferência comuns. Esses casos de uso são definidos da seguinte maneira:

    • Inferência de modelos pequenos: para modelos com alguns bilhões de parâmetros, em que a carga computacional é limitada a um único host.
    • Inferência de modelos grandes em um único host: para modelos com dezenas a centenas de bilhões de parâmetros, em que a carga computacional é compartilhada entre vários aceleradores em uma única máquina host.
    • Inferência de modelos grandes em vários hosts: para modelos com centenas de bilhões a trilhões de parâmetros, em que a carga computacional é compartilhada entre vários aceleradores em várias máquinas host.
    Caso de uso Aceleradores recomendados Série de máquina Principais características
    Inferência de modelo pequeno NVIDIA L4 G2 Opção econômica para modelos pequenos (24 GB de memória por GPU).
    NVIDIA RTX Pro 6000 G4 Econômico para modelos com menos de 30 bilhões de parâmetros e geração de imagens (96 GB de memória por GPU). Oferece suporte à comunicação direta entre GPUs, o que o torna adequado para inferência de host único e várias GPUs.
    TPU v5e - Otimizado para custo-benefício.
    TPU v6e - Oferece o maior valor para modelos de transformador e de criação de imagens a partir de texto.
    Inferência de modelos grandes de host único NVIDIA A100 A2 Adequado para a maioria dos modelos que cabem em um único nó (até 640 GB de memória total).
    NVIDIA H100 A3 Ideal para cargas de trabalho de inferência que cabem em um único nó (até 640 GB de memória total).
    NVIDIA B200 A4 Opção preparada para o futuro para modelos exigentes que se encaixam em um único nó (até 1.440 GB de memória total).
    TPU v4 - Oferece um bom equilíbrio entre custo e desempenho.
    TPU v5p - Uma opção de alto desempenho para cargas de trabalho exigentes.
    Inferência de modelos grandes em vários hosts NVIDIA H200 A3 Ultra Adequado para modelos grandes que consomem muita memória (até 1.128 GB de memória total).
    NVIDIA B200 / GB200 / GB300 / Vera Rubin NVL72 A4 / A4X / A4X Max / A5X Para as cargas de trabalho mais exigentes, com uso intensivo de computação e vinculadas à rede. As máquinas A4X, A4X Max e A5X usam CPUs baseadas em Arm, o que pode exigir a refatoração da carga de trabalho (mudanças no código além de uma simples recriação de contêiner) se a carga de trabalho usar recursos ou otimizações específicos de x86.
    TPU v5e - Otimizado para custo-benefício e desempenho na disponibilização de LLMs de médio a grande porte.
    TPU v5p - Uma opção de alto desempenho para inferência de vários hosts que exige paralelização em grande escala.
    TPU v6e - Otimizado para disponibilização de transformadores, criação de imagens a partir de texto e CNNs.

    Exemplo: escolher um acelerador para um modelo de 260 GB

    Imagine que você precisa implantar um modelo que requer 260 GB de memória total do acelerador (200 GB para o modelo, 50 GB para o cache de chave-valor e 10 GB para sobrecarga).

    Com base apenas nos requisitos de memória, é possível excluir as GPUs NVIDIA L4, já que a maior máquina G2 oferece no máximo 192 GB de memória de acelerador. Além disso, como as GPUs L4 não são compatíveis com conectividade de alta velocidade e baixa latência entre aceleradores, distribuir a carga de trabalho em vários nós não é uma opção viável para alcançar o desempenho desejado.

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

    Isso deixa você com as seguintes opções:

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

    Todos esses aceleradores têm memória suficiente. A próxima etapa é avaliar a disponibilidade deles nas regiões de destino. Digamos que você descubra que apenas as GPUs NVIDIA A100 e NVIDIA H100 estão disponíveis em uma região específica. Depois de comparar o custo-benefício dessas duas opções, você pode escolher a NVIDIA H100 para sua carga de trabalho.

    GPUs de várias instâncias

    Para aumentar a utilização da GPU e otimizar os custos, use configurações de GPU de várias instâncias. Com essa configuração, você particiona uma GPU compatível para compartilhar uma única GPU em vários contêineres no GKE. Ao provisionar uma GPU de várias instâncias, você anexa GPUs inteiras apenas aos nós do GKE e está sujeito aos preços correspondentes da GPU. Recomendamos que você use GPUs de várias instâncias apenas com cargas de trabalho confiáveis.

    Por exemplo, é possível anexar uma NVIDIA RTX PRO 6000 e fazer o seguinte:

    • Particione-a em quatro instâncias (cada uma com 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 com aproximadamente 8 bilhões de parâmetros e que usam a precisão do formato de dados FP16 para pesos de modelo. Essa partição pode ter uma relação custo-benefício melhor em comparação com uma NVIDIA L4.
    • Particione-o em duas instâncias (cada uma com 48 GB de memória de acelerador) e execute cargas de trabalho de inferência de modelos pequenos, como modelos com aproximadamente 15 bilhões de parâmetros e que usam precisão de formato de dados FP16 para pesos de modelo. Essa partição pode ser uma alternativa à execução de cargas de trabalho de inferência em uma GPU NVIDIA A100 de 40 GB.

    Para mais informações, consulte Como executar GPUs com várias instâncias.

    Para mais informações, consulte Tipos de máquinas com GPU e Família de máquinas com otimização para aceleradores na documentação do Compute Engine.

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

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

    • Acelerador único: se o modelo couber em um único acelerador, essa é a abordagem mais simples e recomendada.
    • Nó único, vários aceleradores: se o modelo couber em um único nó com vários aceleradores, use o paralelismo de tensor para distribuir o modelo entre os aceleradores desse nó.
    • Vários nós, vários aceleradores: se o modelo for grande demais para um único nó, use uma combinação de paralelismo de tensor e pipeline para distribuí-lo em vários nós.

    Para implementar essas estratégias, use as seguintes técnicas de paralelismo:

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

      Exemplo: paralelismo de tensor

      Por exemplo, considere que você precisa implantar um modelo com 109 bilhões de parâmetros. Na precisão padrão BF16 (16 bits), 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. Portanto, mesmo sem considerar outros requisitos de memória, como o cache de KV, você precisa de pelo menos duas GPUs NVIDIA H100 para carregar o modelo, usando um tamanho de paralelismo de tensor de dois.

    • Paralelismo de pipeline: essa técnica particiona as camadas de um modelo sequencialmente em vários nós. Ele é adequado para distribuir um modelo em vários nós em uma implantação de vários hosts e requer menos comunicação entre as classificações do modelo do que o paralelismo de tensor.

      Exemplo: paralelismo híbrido (tensor e pipeline)

      Para um modelo muito grande com mais de 600 bilhões de parâmetros, o requisito de memória pode exceder 1,1 TB. Em um cenário com dois nós a3-megagpu-8g (cada um com oito GPUs NVIDIA H100), o cluster total tem 1,28 TB de memória de acelerador. Para executar o modelo, você implementaria uma estratégia híbrida: paralelismo de tensor de 8 vias em cada nó e paralelismo de pipeline de 2 vias nos dois nós. O modelo seria dividido em dois estágios, com a primeira metade das camadas no primeiro nó e a segunda metade no segundo nó. Quando uma solicitação chega, o primeiro nó a processa e envia os dados intermediários pela rede para o segundo nó, que conclui o cálculo.

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

  4. Selecione um tipo de máquina otimizado para acelerador: com base na sua escolha de acelerador e no número necessário, 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 de rede, o que também pode afetar o desempenho da carga de trabalho. Por exemplo, se você precisar de 16 GPUs NVIDIA H100, selecione o tipo de máquina a3-megagpu-16g.

  5. Execute seus próprios comparativos de mercado: o desempenho da carga de trabalho de inferência depende muito do seu caso de uso específico. Execute seus próprios comparativos de mercado para validar suas escolhas e ajustar sua configuração.

Otimizar a configuração do servidor de inferência

Para alcançar o desempenho ideal ao implantar a carga de trabalho de inferência, recomendamos um ciclo de comparativo de mercado e ajuste:

  1. Comece com o guia de início rápido de inferência do GKE para ter uma configuração de referência otimizada do Kubernetes para seu caso de uso.
  2. Execute comparativos de mercado para capturar métricas de capacidade de processamento e latência de referência.
  3. Ajuste a configuração do servidor de inferência.
  4. Execute as comparações novamente e compare os resultados para validar as mudanças.

As recomendações a seguir são baseadas no servidor de inferência vLLM, mas os princípios também se aplicam a outros servidores. Para orientações detalhadas sobre todas as configurações disponíveis, consulte a documentação de otimização e ajuste do vLLM:

  • Configurar o paralelismo:
    • Paralelismo de tensor (tensor_parallel_size): defina como o número de aceleradores em um único nó para fragmentar a carga de trabalho. Por exemplo, definir tensor_parallel_size=4 vai distribuir a carga de trabalho em quatro aceleradores. O aumento desse valor pode levar a uma sobrecarga excessiva de sincronização.
    • Paralelismo de pipeline (pipeline_parallel_size): defina como o número de nós em que você está distribuindo o modelo. Por exemplo, se você estiver implantando em dois nós com oito aceleradores cada, defina tensor_parallel_size=8 e pipeline_parallel_size=2. Aumentar esse valor pode introduzir penalidades de latência.
  • Ajustar o cache KV (gpu_memory_utilization): esse parâmetro controla a porcentagem de memória da GPU reservada para os pesos do modelo, as ativações e o cache KV. Um valor mais alto aumenta o tamanho do cache de chave-valor e pode melhorar a capacidade de processamento. Recomendamos definir um valor entre 0.9 e 0.95. Se você encontrar erros de falta de memória (OOM), reduza esse valor.
  • Configurar o tamanho máximo do contexto (max_model_len): para reduzir o tamanho do cache de KV e os requisitos de memória, defina um tamanho máximo de contexto menor que o padrão do modelo. Isso permite usar GPUs menores e mais econômicas. Por exemplo, se o caso de uso exigir apenas um contexto de 40.000 tokens, mas o padrão do modelo for 256.000, definir max_model_len como 40.000 vai liberar memória para um cache de KV maior, o que pode levar a uma maior capacidade de processamento.
  • Configure o número de solicitações simultâneas (max_num_batched_tokens, max_num_seqs): ajuste o número máximo de solicitações que o vLLM processa simultaneamente para evitar preempção quando o cache de KV estiver com pouco espaço. Valores mais baixos para max_num_batched_tokens e max_num_seqs reduzem os requisitos de memória, enquanto valores mais altos podem melhorar a capacidade de processamento, mas com o risco de erros de OOM. Para encontrar os valores ideais, recomendamos executar experimentos de desempenho e observar o número de solicitações de preempção nas métricas do Prometheus que o vLLM exporta.

Para saber mais, acesse os recursos a seguir:

Otimizar para latência e disponibilidade

Para garantir que o serviço de inferência seja responsivo e confiável, é necessário otimizar para baixa latência de inicialização e alta disponibilidade de recursos.

Otimizar a latência de inicialização a frio da carga de trabalho de inferência

Minimizar o tempo que as cargas de trabalho de inferência levam para iniciar é fundamental para a eficiência de custos e a experiência do usuário. Uma baixa latência de inicialização a frio permite que o cluster seja escalonar verticalmente rapidamente para atender à demanda, garantindo um serviço responsivo e minimizando a necessidade de provisionamento excessivo e caro.

Otimizar o tempo de inicialização do pod

O tempo que um pod leva para ficar pronto é determinado principalmente pelo tempo necessário para extrair a imagem do contêiner e fazer o download dos pesos do modelo. Para otimizar ambos, considere as seguintes estratégias:

  • Acelere o carregamento de modelos com um carregador de dados otimizado: o método usado para armazenar e carregar os pesos do modelo tem um impacto significativo no tempo de inicialização. Para as versões 0.10.2 e mais recentes do vLLM, a abordagem recomendada é usar o Run:ai Model Streamer para carregar modelos de IA por streaming diretamente de um bucket do Cloud Storage.

    Se o streamer não estiver disponível para seu caso de uso, monte um bucket do Cloud Storage usando o Cloud Storage FUSE e ajuste o desempenho dele ativando namespaces hierárquicos e usando técnicas como downloads paralelos e pré-busca. Para saber mais sobre essas técnicas, consulte Otimizar o driver CSI do Cloud Storage FUSE para o desempenho do GKE. Em ambos os casos, recomendamos usar o Rapid Cache para criar caches de leitura zonais de alto desempenho para seus buckets e ativar o acesso uniforme no nível do bucket para controlar de maneira uniforme o acesso aos buckets.

    Se você já usa o Managed Lustre para armazenamento de arquivos de alto desempenho nas suas cargas de trabalho de treinamento, também pode usá-lo para carregar pesos de modelo para inferência. Essa abordagem oferece acesso de baixa latência quando a localidade dos dados e a compatibilidade com POSIX são essenciais.

  • Ativar o streaming de imagens: para reduzir o tempo necessário para extrair as imagens de contêiner, ative o streaming de imagens no cluster do GKE. O streaming de imagens permite que os contêineres sejam iniciados antes que a imagem inteira seja baixada, o que pode reduzir drasticamente o tempo de inicialização do pod.

Ativar nós de inicialização rápida

Para cargas de trabalho que exigem escalonamento rápido, use os nós de início rápido no GKE. Os nós de inicialização rápida são recursos de hardware pré-inicializados que têm um tempo de inicialização significativamente menor do que os nós padrão. Se o cluster atender aos requisitos, o GKE vai ativar automaticamente os nós de inicialização rápida.

Planejar a flexibilidade, a eficiência e a disponibilidade da capacidade do acelerador

Aceleradores de alta demanda, como GPUs e TPUs, podem ter disponibilidade limitada. Por isso, uma estratégia proativa de planejamento de capacidade é essencial.

Planejar e reservar capacidade

Os aceleradores de alta demanda podem ter disponibilidade limitada, por isso uma estratégia proativa de planejamento de capacidade é essencial. Para garantir o acesso aos recursos necessários, siga estas recomendações:

  • Determinar o valor de referência de capacidade e o processamento de pico: planeje a capacidade de referência do acelerador que você precisa reservar. O valor a ser reservado depende do seu caso de uso. Por exemplo, é possível reservar 100% da capacidade necessária para cargas de trabalho críticas sem tolerância a atrasos ou reservar um determinado percentil (como o 90º ou o 95º) e adquirir o restante sob demanda para lidar com picos.

  • Reservar capacidade de referência: para receber recursos com um alto nível de garantia, crie reservas. É possível escolher um tipo de reserva com base nas suas necessidades. Por exemplo, para reservar recursos de alta demanda, como aceleradores, para um período específico no futuro, é possível criar reservas adiantadas no modo calendário.

  • Orquestrar a capacidade para picos: para demandas que excedem suas reservas de referência, é possível implementar uma estratégia de fallback usando outros tipos de capacidade, como VMs spot, sob demanda ou o Programador dinâmico de cargas de trabalho (DWS). É possível automatizar essa estratégia de substituição usando ComputeClasses personalizadas para definir uma ordem de prioridade para o provisionamento de diferentes tipos de capacidade.

  • Acesse preços com desconto: para sua capacidade de referência, compre descontos por compromisso de uso (CUDs) para receber preços com grandes descontos em troca de um compromisso de um ou três anos.

Use o Dynamic Workload Scheduler com o modo de provisionamento de início flexível se as cargas de trabalho tolerarem atrasos na aquisição de capacidade

Para cargas de trabalho que toleram algum atraso na aquisição de capacidade, o Dynamic Workload Scheduler (DWS) com o modo de provisionamento de início flexível é uma opção para conseguir aceleradores com desconto. O DWS permite colocar em fila solicitações de capacidade por até sete dias.

Ao usar o DWS com o modo de provisionamento de início flexível, recomendamos o seguinte:

  • Incorpore-o a uma ComputeClass: use uma ComputeClass para definir o DWS como parte de uma estratégia de substituição priorizada para adquirir capacidade.
  • Definir uma duração máxima de execução: o parâmetro maxRunDurationSeconds define o tempo de execução máximo para nós solicitados pelo DWS. Definir um valor menor que o padrão de sete dias pode aumentar as chances de receber os nós solicitados.
  • Ativar a reciclagem de nós: para evitar a inatividade das cargas de trabalho, ative a reciclagem de nós. Esse recurso começa a provisionar um novo nó antes que o antigo expire, garantindo uma transição mais tranquila.
  • Minimize as interrupções: para minimizar as interrupções causadas pela remoção e pelos upgrades de nós, configure janelas de manutenção e exclusões, desative o reparo automático de nós e aproveite a estratégia de upgrades de curta duração.

Usar ComputeClasses

As ComputeClasses são um recurso do GKE que permite definir uma lista priorizada de configurações de infraestrutura para suas cargas de trabalho. As ComputeClasses oferecem recursos importantes para melhorar a flexibilidade, a eficiência e a disponibilidade da capacidade do acelerador:

  • Prioridades de computação substitutas: é possível definir uma lista de configurações priorizadas. Se a opção preferida não estiver disponível durante um evento de escalonamento vertical, o escalonador automático vai usar automaticamente a próxima opção da lista, o que aumenta significativamente a probabilidade de adquirir capacidade.
  • Migração ativa para nós de prioridade mais alta: ao configurar esse recurso, o GKE substitui automaticamente os nós em execução em configurações de prioridade mais baixa por nós de configurações de prioridade mais alta à medida que eles ficam disponíveis. Isso ajuda a garantir que os pods sejam executados nos nós mais preferidos (e geralmente mais econômicos).

Com as ComputeClasses, é possível criar uma estratégia substituta para adquirir nós. Essa estratégia usa uma lista priorizada de diferentes tipos de capacidade, como VMs sob demanda, VMs spot ou reservas. Cada um desses tipos de capacidade tem um nível diferente de disponibilidade:

  • Reservas: oferecem o mais alto nível de garantia para conseguir capacidade. Ao consumir reservas com ComputeClasses, considere as restrições delas. Por exemplo, alguns tipos de reserva limitam os tipos de máquina que você pode reservar ou o número máximo de máquinas que pode solicitar.
  • Sob demanda: o modelo de provisionamento padrão, que oferece flexibilidade, mas pode estar sujeito a restrições de capacidade regional para recursos de alta demanda.
  • VMs spot: use a capacidade extra por um preço menor, mas que pode ser interrompida. Quando um evento de preempção acontece, o GKE fornece um período de encerramento normal de até 30 segundos para os pods afetados, com base no melhor esforço. Para aproveitar isso, torne suas cargas de trabalho tolerantes a eventos de preempção implementando checkpoints e mecanismos de repetição.
  • Dynamic Workload Scheduler (DWS): permite colocar em fila solicitações de recursos escassos com preços com desconto. Esse recurso é ideal para cargas de trabalho que podem tolerar atrasos na aquisição de capacidade.

A ordem da sua lista de prioridades deve mudar dependendo se o objetivo principal é minimizar a latência ou otimizar os custos. Por exemplo, é possível configurar as seguintes listas de prioridade para diferentes requisitos de carga de trabalho:

Prioridade Cargas de trabalho de baixa latência Cargas de trabalho com custo otimizado (tolerantes à latência)
1 Reservas (específicas e depois qualquer uma) Reservas (específicas e depois qualquer uma)
2 Sob demanda VMs spot
3 VMs spot Dynamic Workload Scheduler
4 Dynamic Workload Scheduler Sob demanda

Para casos de uso de baixa latência, a capacidade sob demanda é priorizada após as reservas, porque ela informa rapidamente a falta de capacidade, permitindo que a ComputeClass volte rapidamente para a próxima opção.

Para casos de uso com custo otimizado, as VMs spot e o DWS com início flexível são priorizados após as reservas para aproveitar os custos mais baixos. A capacidade on demand é usada como substituto final.

Configurar a política de localização dos clusters do GKE e pools de nós

A política de localização do escalonador automático de clusters controla como o GKE distribui nós entre zonas durante um evento de escalonamento vertical. Essa configuração é particularmente importante ao usar ComputeClasses, porque determina quais zonas o escalonador automático de cluster vai considerar antes de aplicar a lista de prioridades da ComputeClass.

Para melhorar suas chances de conseguir aceleradores, configure a política de local com base nos requisitos da carga de trabalho:

  • location-policy=ANY: prioriza a obtenção de capacidade em vez de equilibrar os nós de maneira uniforme entre as zonas. Essa configuração é particularmente relevante quando a ComputeClass inclui VMs spot ou tipos de máquina com disponibilidade variável, já que ANY permite que o escalonador automático de cluster escolha a zona com a melhor chance de atender aos tipos de nó priorizados da ComputeClass. Use essa configuração também para priorizar o uso de reservas não utilizadas. Ao usar essa política, recomendamos que você comece com num-nodes=0 para dar ao escalonador automático de clusters a máxima flexibilidade para encontrar capacidade.

  • location-policy=BALANCED: tenta distribuir os nós de maneira uniforme em todas as zonas disponíveis. Use essa política quando as cargas de trabalho usarem recursos fáceis de conseguir e você quiser manter a redundância zonal para alta disponibilidade.

É possível definir essa configuração ao criar ou atualizar um pool de nós.

Otimizar a eficiência e o custo

Ao monitorar cuidadosamente os aceleradores e escalonar de forma inteligente as cargas de trabalho, é possível reduzir significativamente o desperdício e os custos operacionais.

Observar os aceleradores e servidores de inferência

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

  • Monitorar as métricas do DCGM para GPUs NVIDIA: para monitorar a integridade e o desempenho das GPUs NVIDIA, configure o GKE para enviar métricas do NVIDIA Data Center GPU Manager (DCGM) ao Cloud Monitoring.
  • Ativar o monitoramento automático de aplicativos: para simplificar o processo de monitoramento dos servidores de inferência, ative o monitoramento automático de aplicativos no GKE.
  • Instrumente suas cargas de trabalho com o OpenTelemetry: para cargas de trabalho que não são compatíveis com o monitoramento automático de aplicativos, use o OpenTelemetry para coletar métricas personalizadas e traces.

Escalonar os pods automaticamente

Para garantir que as cargas de trabalho de inferência possam se adaptar dinamicamente às mudanças na demanda, use um Autoescalonador Horizontal de Pods (HPA) para escalonar automaticamente o número de pods. Para cargas de trabalho de inferência, é essencial basear as decisões de escalonamento 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 escalonamento automático das cargas de trabalho de inferência, recomendamos o seguinte:

  • Configurar o HPA com base em métricas que consideram a inferência: para otimizar o desempenho, configure o HPA para escalonar com base nas métricas do servidor de inferência. A melhor métrica depende se você está otimizando para baixa latência ou alta capacidade de processamento.

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

      • Utilização do cache de KV (por exemplo, vllm:gpu_cache_usage_perc): essa métrica costuma ser o melhor indicador de picos de latência iminentes. O uso elevado do cache de chave-valor indica que o mecanismo de inferência está se aproximando da capacidade máxima. O HPA pode usar esse indicador para adicionar réplicas de forma preventiva e manter uma experiência de usuário estável.
      • Número de solicitações em execução (tamanho do lote) (por exemplo,vllm:num_requests_running): essa métrica está diretamente relacionada à latência, já que tamanhos de lote menores geralmente resultam em latência mais baixa. No entanto, usá-la para escalonamento automático pode ser um desafio, porque maximizar a capacidade de processamento depende do tamanho das solicitações recebidas. Talvez seja necessário escolher um valor menor que o tamanho máximo possível do lote para garantir que o HPA seja escalonado adequadamente.

    • Para cargas de trabalho sensíveis à capacidade, faça o escalonamento com base no tamanho da fila (por exemplo, vllm:num_requests_waiting). Essa métrica mede diretamente o backlog de trabalho e é uma maneira simples de corresponder a capacidade de processamento à demanda recebida. Como essa métrica considera apenas as solicitações que estão aguardando, e não as que estão sendo processadas, ela pode não alcançar a menor latência possível em comparação com o escalonamento no tamanho do lote.

  • Defina um número mínimo de réplicas: para garantir uma disponibilidade consistente e uma experiência do usuário de referência, sempre defina um número mínimo de réplicas para sua implantação de inferência.

  • Ativar o perfil de HPA de desempenho: nas versões 1.33 ou mais recentes do GKE, o perfil de HPA de desempenho é ativado por padrão em clusters qualificados para melhorar o tempo de reação do HPA.

Para mais informações, consulte Configurar o HPA para cargas de trabalho de LLM em GPUs e Escalonar automaticamente cargas de trabalho de inferência de LLM em TPUs.

Aproximar os dados das cargas de trabalho

O tempo que as cargas de trabalho levam para carregar dados, como pesos de modelo, pode ser uma fonte significativa de latência. Ao aproximar os dados dos recursos de computação, é possível reduzir os tempos de transferência de dados e melhorar o desempenho geral.

  • Crie caches de leitura zonais com o Rapid Cache: se você usa o Cloud Storage para armazenar dados das suas cargas de trabalho de IA/ML, ative o Rapid Cache. O Rapid Cache cria caches de leitura zonais de alto desempenho para seus buckets do Cloud Storage.
  • Armazenar em cache dados acessados com frequência em SSDs locais: para cargas de trabalho que exigem acesso de latência extremamente baixa a dados temporários, use SSDs locais como um cache de alto desempenho. O uso de SSDs locais como armazenamento temporário de baixa latência para armazenar dados usados com frequência ajuda a reduzir o tempo de inatividade de recursos caros, como aceleradores, reduzindo drasticamente o tempo que os aceleradores esperam para que as operações de E/S sejam concluídas. Nem todas as séries de máquinas são compatíveis com SSDs locais, o que pode afetar sua escolha de aceleradores.
  • Gerenciar caches com o cache de dados do GKE: para cargas de trabalho que leem dados com frequência de discos permanentes, ative o cache de dados do GKE. O cache de dados do GKE usa SSDs locais para criar um cache gerenciado de alto desempenho para seus discos permanentes. Para a maioria das cargas de trabalho de produção, recomendamos o uso do modo Writethrough para evitar a perda de dados gravando dados de forma síncrona no cache e no disco permanente subjacente.

Otimizar para arquiteturas de escalonamento avançadas

Para atender às demandas de aplicativos de grande escala ou distribuídos globalmente, é possível adotar arquiteturas de escalonamento avançadas para melhorar o desempenho, a confiabilidade e o gerenciamento de tráfego.

Balancear o tráfego de carga com o GKE Inference Gateway

Para cargas de trabalho de inferência em um único cluster, recomendamos o uso do GKE Inference Gateway. O Inference Gateway é um balanceador de carga com reconhecimento de IA que monitora métricas de inferência para rotear solicitações para o endpoint ideal. Esse recurso melhora o desempenho e o uso do acelerador.

Ao usar o GKE Inference Gateway, recomendamos que você siga estas práticas recomendadas:

  • Agrupar pods de exibição em um InferencePool: defina um InferencePool para cada grupo de pods que exibe suas cargas de trabalho de inferência. Para mais informações, consulte Personalizar a configuração do GKE Inference Gateway.
  • Multiplexar cargas de trabalho críticas para latência: defina InferenceObjectives para especificar as propriedades de exibição do modelo, como nome e prioridade. O GKE Inference Gateway prioriza cargas de trabalho com maior prioridade, permitindo multiplexar cargas de trabalho críticas e tolerantes à latência e implementar políticas de redução de carga durante tráfego intenso.
  • Usar o roteamento com reconhecimento de modelo: para rotear solicitações com base no nome do modelo no corpo da solicitação, use o roteamento baseado no corpo. Ao usar o roteamento baseado em corpo, verifique se os back-ends estão altamente disponíveis. O gateway vai retornar um erro se a extensão não estiver disponível, impedindo que as solicitações sejam roteadas incorretamente.
  • Permitir que o gateway distribua o tráfego automaticamente: o GKE Inference Gateway encaminha o tráfego de forma inteligente monitorando as principais métricas dos servidores de inferência no InferencePool, como utilização do cache de chave-valor, comprimento da fila e índices de cache de prefixo. Esse balanceamento de carga em tempo real otimiza o uso do acelerador, reduz a latência de cauda e aumenta a capacidade de processamento geral em comparação com os métodos tradicionais.
  • Integração com a Apigee e o Model Armor: para maior segurança e gerenciamento, integre-se à Apigee para gerenciamento de APIs e ao Model Armor para verificações de segurança.

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

Para modelos muito grandes que não cabem em um único nó, é necessário distribuir a carga de trabalho de inferência em vários nós. Isso 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 sejam gerenciados como uma única unidade.

Considere estas práticas recomendadas:

  • Maximize a largura de banda e a capacidade de processamento da rede do acelerador: quando uma carga de trabalho é distribuída em vários nós, a rede se torna 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. Dependendo da escala do cluster e da intensidade da comunicação que a carga de trabalho exige, é possível escolher entre estas opções:

    • GPUDirect-TCPX: eficaz para uma variedade de cargas de trabalho de inferência de vários nós em execução no A3 High.
    • GPUDirect-TCPXO: oferece desempenho aprimorado com maior descarregamento e largura de banda, 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 maior largura de banda entre nós e a menor latência, permitindo o acesso direto à memória entre GPUs em nós diferentes, ignorando a CPU. É mais adequado para os cenários de inferência em grande escala mais exigentes em máquinas A3 Ultra e A4.

    Para mais informações, consulte:

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

  • Use o LeaderWorkerSet para gerenciar cargas de trabalho distribuídas: ao implantar uma carga de trabalho distribuída com estado, como um serviço de inferência multinó, é essencial gerenciar todos os componentes como uma única unidade. Para isso, use o LeaderWorkerSet, uma API nativa do Kubernetes que permite gerenciar um grupo de pods relacionados como uma única entidade. Um LeaderWorkerSet garante que todos os pods no conjunto sejam criados e excluídos juntos, o que é fundamental para manter a integridade de uma carga de trabalho distribuída.

  • Colocar nós em proximidade física usando o posicionamento compacto: a distância física entre os nós na carga de trabalho distribuída pode ter um impacto significativo na latência da rede entre nós. Para minimizar essa latência, use uma política de posicionamento compacto para os pools de nós do GKE. Uma política de posicionamento compacto instrui o GKE a colocar os nós em um pool de nós o mais próximo possível uns dos outros em uma zona.

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

Para aplicativos distribuídos globalmente que exigem alta disponibilidade e baixa latência, implantar as cargas de trabalho de inferência em várias regiões é uma prática recomendada essencial. Uma arquitetura multirregional pode ajudar a aumentar a confiabilidade, melhorar a flexibilidade, a eficiência e a disponibilidade da capacidade do acelerador, reduzir a latência inferida pelo usuário e atender aos requisitos regulatórios específicos do local.

Para implantar e gerenciar de maneira eficaz um serviço de inferência multirregional, siga estas recomendações:

  • Provisione clusters do GKE em várias regiões em que você tenha capacidade reservada ou preveja a necessidade de capacidade para lidar com picos de carga.
  • Escolha a estratégia de armazenamento certa para os pesos do modelo. Para otimizar a eficiência operacional, crie um bucket multirregional do Cloud Storage. Para otimizar o custo, crie um bucket regional em cada região e replique os pesos do modelo.
  • Use o Rapid Cache para criar caches de leitura zonais para seus buckets do Cloud Storage e reduzir a latência de rede e os custos de saída de dados.

Resumo das práticas recomendadas

A tabela a seguir resume as práticas recomendadas neste documento:

Tópico Tarefa
Implantação e configuração
  • Analisar as características do seu caso de uso de inferência
  • Escolher os modelos certos para seus casos de uso de inferência
  • Aplicar quantização ao modelo
  • Escolha os aceleradores certos
  • Escolher sua estratégia de distribuição de inferência
  • Otimizar a configuração do servidor de inferência
Latência de inicialização a frio
  • Otimizar o tempo de inicialização do pod
  • Ativar nós de início rápido
Planejamento de capacidade, flexibilidade, eficiência e disponibilidade
  • Planejar e reservar capacidade
  • Usar o Dynamic Workload Scheduler
  • Usar ComputeClasses
  • Configurar a política de localização dos clusters do GKE e pools de nós
Eficiência de recursos e aceleradores
  • Observar os aceleradores e servidores de inferência
  • Escalonar os pods automaticamente
  • Mover dados para mais perto das cargas de trabalho
Balanceamento de carga
  • Usar o GKE Inference Gateway para implantações de cluster único
Implantações em vários nós
  • Maximizar a largura de banda e a capacidade de processamento da rede do acelerador
  • Usar o LeaderWorkerSet para agrupar pods
  • Colocar nós em proximidade física usando o posicionamento compacto
Implantações multirregionais
  • Provisionar clusters do GKE em várias regiões
  • Balancear a carga do tráfego entre regiões
  • Armazenar pesos de modelos em buckets do Cloud Storage
  • Armazenar dados em cache com o Rapid Cache

A seguir