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

Este documento oferece 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 práticas recomendadas para 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 funções de usuário comuns do GKE.

Preparar para veiculação de inferência no GKE

Nesta seção, descrevemos as práticas recomendadas fundamentais 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 sua carga de trabalho:

  • Defina requisitos de desempenho e latência: determine os SLOs de latência e capacidade de processamento do aplicativo. As principais métricas a serem definidas incluem solicitações por segundo (RPS), latência de resposta, comprimento do token de entrada e saída e taxa ocorrência em cache de prefixo. Para mais informações, consulte Métricas de desempenho da inferência.
  • Avalie os requisitos e a escalonabilidade do modelo: as características do modelo escolhido influenciam diretamente as necessidades de infraestrutura. Considere o tamanho máximo do contexto que o modelo aceita e compare com o que sua carga de trabalho exige. Se o caso de uso não exigir contexto máximo, diminuir o tamanho máximo do contexto pode liberar memória do acelerador para um cache KV maior, aumentando potencialmente a capacidade de processamento.
  • Estabeleça restrições de custo e negócios: seu orçamento e objetivos de negócios são fatores importantes 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 transferência, e se o app pode tolerar latência variável.

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

Selecionar o 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 tarefa e modalidade: avalie os modelos com base nas tarefas designadas e nas modalidades compatíveis. Um modelo otimizado para uma tarefa específica quase sempre tem um desempenho melhor do que um modelo de uso 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 requisitos de recursos e o desempenho dele. Essa avaliação ajuda você a determinar se precisa aplicar técnicas de quantização. Verifique a precisão compatível para pesos de modelo, garanta a compatibilidade com o framework e verifique o tamanho máximo de contexto compatível do modelo.
  • Performance e custo-benefício: para tomar uma decisão orientada por dados, compare os modelos selecionados usando comparativos de mercado disponíveis publicamente e seus próprios testes internos. Use rankings como a Chatbot Arena para comparar modelos e avalie 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 as cargas de trabalho de inferência reduzindo o uso de memória do modelo. Ele converte os pesos, as ativações e o cache de chave-valor (KV) do modelo de formatos de ponto flutuante 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 a ocupação 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 KV maior.

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

  • Avalie a compensação de acurácia: a quantização às vezes pode resultar em uma perda de acurácia do modelo. Ao avaliar a troca de precisão da quantização, considere que a quantização de 8 bits geralmente resulta em uma perda mínima de precisão. Em contraste, a quantização de 4 bits pode reduzir 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 acurácia ainda esteja dentro de um intervalo aceitável. Para avaliar a perda de acurácia, use ferramentas como OpenCompass (link em inglês) e Language Model Evaluation Harness (link em inglês).
  • Avalie 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 de FP8.
  • Verifique se há modelos pré-quantizados: antes de quantizar um modelo por conta própria, 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 trazer benefícios de performance 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 fazer a quantização por conta própria. Servidores de inferência como o vLLM (link em inglês) aceitam a execução de modelos quantizados com várias 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 do cache KV: além de quantizar os pesos do modelo, você também pode quantizar o cache KV. Essa técnica reduz ainda mais a memória necessária para o cache de KV durante a 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

Selecionar o acelerador certo afeta diretamente a performance, o custo e a experiência do usuário do seu 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 seus requisitos de memória: primeiro, calcule a memória mínima do acelerador necessária para carregar e executar seu 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 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:

    • Pesos do modelo: o tamanho dos parâmetros do modelo.
    • Sobrecarga: um buffer para o servidor de inferência e outras sobrecargas do sistema, geralmente 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 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 a 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 seguintes valores.

    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
      • Comprimento 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 KV: 2 (para BF16)
      • Vetores KV: 2 (um para chave e 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 da 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 do 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, e aproveite ao máximo os benefícios de desempenho.

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

    Dica: para conferir as recomendações mais recentes de aceleradores com base em comparativos de mercado de desempenho de serviço e análise de custos, use a ferramenta de início rápido da inferência do GKE. Para mais detalhes, consulte a documentação do Início rápido da inferência do GKE.

    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 comuns de inferência. Esses casos de uso são definidos da seguinte maneira:

    • Inferência de modelo pequeno: para modelos com alguns bilhões de parâmetros, em que a carga computacional é confinada a um único host.
    • Inferência de modelo grande de host único: 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 de GPU ponto a ponto, o que a torna adequada para inferência de várias GPUs em um único host.
    TPU v5e - Otimizado para eficiência de custos.
    TPU v6e - Oferece o maior valor para modelos transformadores e de texto para imagem.
    Inferência de modelo grande 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 cabem 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 e com uso intensivo de memória (até 1.128 GB de memória total).
    NVIDIA B200 / GB200 A4 / A4X Para as cargas de trabalho mais exigentes, com uso intensivo de computação e vinculadas à rede. As máquinas A4X usam CPUs baseadas em Arm, o que pode exigir refatoração da carga de trabalho (mudanças no código além de uma simples recriação do contêiner) se ela usar recursos ou otimizações específicos de x86.
    TPU v5e - Otimizado para eficiência de custos e desempenho para veiculação de LLMs de médio a grande porte.
    TPU v5p - Uma opção de alta performance para inferência multi-host que exige paralelização em grande escala.
    TPU v6e - Otimizada para disponibilização de transformadores, conversão de texto em imagem e CNNs.

    Exemplo: escolher um acelerador para um modelo de 260 GB

    Imagine que você precise implantar um modelo que requer 260 GB de memória total do acelerador (200 GB para o modelo, 50 GB para o cache KV 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 um máximo de 192 GB de memória do acelerador. Além disso, como as GPUs L4 não oferecem suporte à 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 e GB300, 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 a relação preço-performance dessas duas opções, você pode escolher a NVIDIA H100 para sua carga de trabalho.

    GPUs com várias instâncias

    Para aumentar a utilização e otimizar os custos da GPU, 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 de 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:

    • Divida em quatro instâncias (cada uma fornece 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 precisão de formato de dados FP16 para pesos de modelo. Essa partição pode ter uma relação preço-performance melhor do que uma NVIDIA L4.
    • Divida em duas instâncias (cada uma fornece 48 GB de memória do acelerador) e execute pequenas cargas de trabalho de inferência de modelo, 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 para executar 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 otimizada 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, escolha 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 hardware:

    • Acelerador único: se o modelo couber em um único acelerador, essa será 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 tensores para distribuir o modelo entre os aceleradores nesse nó.
    • Vários nós e aceleradores: se o modelo for muito grande 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 direto ponto a ponto, mas exige uma comunicação significativa entre aceleradores.

      Exemplo: paralelismo de tensores

      Por exemplo, considere que você precisa implantar um modelo com 109 bilhões de parâmetros. Na precisão BF16 (16 bits) padrão, 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 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. É adequado para distribuir um modelo em vários nós em uma implantação de vários hosts e exige menos comunicação entre as classificações de modelo do que o paralelismo de tensores.

      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 oito vias em cada nó e paralelismo de pipeline de duas vias nos dois nós. O modelo seria dividido em duas etapas, 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 a computação.

    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 aceleradores: 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 da rede, o que também pode afetar o desempenho da sua 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 sua carga de trabalho de inferência depende muito do seu caso de uso específico. Execute seus próprios comparativos para validar suas escolhas e ajustar a configuração.

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

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

  1. Comece com o guia de início rápido da inferência do GKE para ter uma configuração otimizada de base do Kubernetes para seu caso de uso.
  2. Execute comparativos 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 comparativas de mercado novamente e compare os resultados para validar suas 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 Otimização e ajuste do vLLM:

  • Configurar paralelismo:
    • Paralelismo de tensor (tensor_parallel_size): defina isso 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. Aumentar esse valor pode causar 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 gerar penalidades de latência.
  • Ajuste o cache KV (gpu_memory_utilization): esse parâmetro controla a porcentagem da 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 KV e pode melhorar a capacidade de transferência. Recomendamos definir um valor entre 0.9 e 0.95. Se você encontrar erros de falta de memória (OOM), diminua esse valor.
  • Configure 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 do 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 KV maior, o que pode levar a uma taxa de transferência mais alta.
  • 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 a substituição quando o cache 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 aumentam o risco de erros de falta de memória (OOM). Para encontrar os valores ideais, recomendamos executar experimentos de desempenho e observar o número de solicitações de remoção forçada nas métricas do Prometheus exportadas pelo vLLM.

Para saber mais, acesse os recursos a seguir:

Otimizar para latência e disponibilidade

Para garantir que seu 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 necessário para iniciar as cargas de trabalho de inferência é fundamental para a eficiência de custos e a experiência do usuário. Com uma baixa latência de inicialização a frio, seu cluster pode escalonar verticalmente rapidamente para atender à demanda, garantindo um serviço responsivo e minimizando a necessidade de provisionamento excessivo 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 os dois, considere as seguintes estratégias:

  • Acelere o carregamento do modelo 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 transmitindo-os 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 a performance dele ativando os 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 qualquer caso, recomendamos usar o Anywhere Cache para criar caches de leitura zonais de alta performance para seus buckets e ativar o acesso uniforme no nível do bucket para controlar o acesso aos buckets de maneira uniforme.

    Se você já usa o Managed Lustre para armazenamento de arquivos de alta performance para suas cargas de trabalho de treinamento, também é possível 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.

  • Ative 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 do download da imagem inteira, 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, aproveite os nós de inicialização rápida 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 capacidade e maximizar a disponibilidade de aceleradores

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, é essencial ter uma estratégia proativa de planejamento de capacidade. Para garantir o acesso aos recursos necessários, siga estas recomendações:

  • Determine o valor de referência da capacidade e o processamento de picos: planeje a capacidade de aceleração de valor de referência 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 95º) e adquirir o restante sob demanda para lidar com picos.

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

  • Orquestrar a capacidade para picos: para demandas que excedam suas reservas de base, implemente uma estratégia de fallback usando outros tipos de capacidade como sob demanda, VMs spot ou o Programador de carga de trabalho dinâmica (DWS). É possível automatizar essa estratégia de substituição usando Classes de computação personalizadas para definir uma ordem de prioridade para provisionar diferentes tipos de capacidade.

  • Acesse preços com desconto: para sua capacidade básica, compre descontos por uso contínuo (CUDs) e receba 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 modo de provisionamento de início flexível é uma opção para obter aceleradores a um preço com desconto. Com o DWS, é possível enfileirar 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 em uma classe de computação personalizada: use uma classe de computação personalizada para definir o DWS como parte de uma estratégia de substituição prioritária para adquirir capacidade.
  • Defina uma duração máxima de execução: o parâmetro maxRunDurationSeconds define a duração máxima de execução para nós solicitados pelo DWS. Definir um valor menor que o padrão de sete dias pode aumentar suas chances de receber os nós solicitados.
  • Ative a reciclagem de nós: para evitar inatividade nas 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.
  • Minimizar interrupções: para minimizar as interrupções causadas pela remoção e upgrades de nós, configure janelas e exclusões de manutenção, desative o reparo automático de nós e aproveite a estratégia de upgrades de curta duração.

Usar classes de computação personalizadas

As classes de computação personalizadas (CCCs, na sigla em inglês) são um recurso do GKE que permite definir uma lista priorizada de configurações de infraestrutura para suas cargas de trabalho. Os CCCs oferecem recursos importantes projetados para melhorar a capacidade de obtenção de aceleradores:

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

Com as classes de computação personalizadas (CCCs, na sigla em inglês), é 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 de disponibilidade diferente:

  • Reservas: oferecem o mais alto nível de garantia para conseguir capacidade. Ao consumir reservas com CCCs, considere as restrições delas. Por exemplo, alguns tipos de reserva limitam os tipos de máquina que podem ser reservados ou o número máximo de máquinas que podem ser solicitadas.
  • 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: usam capacidade extra a um preço menor, mas podem ser preemptivas. Quando um evento de preempção acontece, o GKE oferece um período de encerramento normal de até 30 segundos para os pods afetados, da melhor maneira possível. Para aproveitar isso, torne suas cargas de trabalho tolerantes a eventos de remoção implementando checkpoints e mecanismos de repetição.
  • Dynamic Workload Scheduler (DWS): permite enfileirar solicitações de recursos escassos a preços promocionais. Esse recurso é ideal para cargas de trabalho que podem tolerar atrasos na aquisição de capacidade.

A ordem da sua lista de prioridades muda dependendo se o objetivo principal é minimizar a latência ou otimizar o custo. 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 otimizadas para custos (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 Programador dinâmico de cargas de trabalho
4 Programador dinâmico de cargas de trabalho Sob demanda

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

Para casos de uso otimizados para custos, 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 sob demanda é usada como o último recurso.

Configurar a política de local dos clusters do GKE e dos pools de nós

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

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

  • location-policy=ANY: prioriza a obtenção de capacidade em vez de balancear os nós de maneira uniforme entre as zonas. Essa configuração é especialmente relevante quando o CCC inclui VMs spot ou tipos de máquina com disponibilidade variável, já que o ANY permite que o escalonador automático de cluster escolha a zona com a maior chance de atender aos tipos de nós priorizados do CCC. 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 autoescalador de cluster a máxima flexibilidade na busca de capacidade.

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

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

Otimizar para eficiência e custo

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

Observar seus 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 você a monitorar aceleradores e servidores de inferência:

  • Monitore 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.
  • Ative 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 e rastreamentos personalizados.

Escalonar automaticamente seus pods

Para garantir que suas cargas de trabalho de inferência possam se adaptar dinamicamente às mudanças na demanda, use um escalonador automático 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 refletem 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 para suas cargas de trabalho de inferência, recomendamos o seguinte:

  • Configure o HPA com base em métricas de inferência: para ter uma performance ideal, configure o HPA para escalonar com base em métricas do seu 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 KV (por exemplo, vllm:gpu_cache_usage_perc): essa métrica geralmente é o melhor indicador de picos de latência iminentes. Uma alta utilização do cache KV indica que o mecanismo de inferência está chegando à capacidade máxima. O HPA pode usar esse indicador para adicionar réplicas de maneira preventiva e manter uma experiência do 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 menor. No entanto, usá-lo para escalonamento automático pode ser difícil, porque a maximização da 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 corretamente.

    • Para cargas de trabalho sensíveis à capacidade de processamento, 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 atingir 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 disponibilidade consistente e uma experiência básica do usuário, sempre defina um número mínimo de réplicas para sua implantação de inferência.

  • Ative o perfil de desempenho do HPA: nas versões 1.33 ou mais recentes do GKE, o perfil de desempenho do HPA é 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 necessário para que suas cargas de trabalho carreguem dados, como pesos de modelo, pode ser uma fonte significativa de latência. Ao mover seus dados para mais perto dos recursos de computação, você pode reduzir os tempos de transferência de dados e melhorar o desempenho geral.

  • Crie caches de leitura zonais com o Anywhere Cache: se você usa o Cloud Storage para armazenar dados das suas cargas de trabalho de IA/ML, ative o Anywhere Cache. O Anywhere Cache cria caches de leitura zonais de alta performance 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. Usar SSDs locais como um armazenamento temporário de baixa latência para armazenar dados usados com frequência ajuda a reduzir o tempo ocioso de recursos caros, como aceleradores, diminuindo drasticamente o tempo que os aceleradores esperam a conclusão das operações de E/S. 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 GKE Data Cache: para cargas de trabalho que leem dados com frequência de discos permanentes, ative o GKE Data Cache. 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 usar o 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çado

Para atender às demandas de aplicativos em 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.

Fazer o balanceamento de carga do tráfego com o GKE Inference Gateway

Para cargas de trabalho de inferência em um único cluster, recomendamos usar o GKE Inference Gateway. O gateway de inferência é um balanceador de carga compatível com IA que monitora métricas de inferência para rotear solicitações para o endpoint mais adequado. Esse recurso melhora o desempenho e a utilização do acelerador.

Ao usar o gateway de inferência do GKE, recomendamos que você siga estas práticas recomendadas:

  • Agrupe os pods de serviço em um InferencePool: defina um InferencePool para cada grupo de pods que atendem às suas cargas de trabalho de inferência. Para mais informações, consulte Personalizar a configuração do gateway de inferência do GKE.
  • Multiplexar cargas de trabalho sensíveis à latência: defina InferenceObjectives para especificar as propriedades de veiculação do modelo, como nome e prioridade. O GKE Inference Gateway dá preferência a cargas de trabalho com prioridade mais alta, permitindo multiplexar cargas de trabalho sensíveis e tolerantes à latência e implementar políticas de redução de carga durante tráfego intenso.
  • Usar roteamento com reconhecimento de modelo: para rotear solicitações com base no nome do modelo no corpo da solicitação, use o roteamento com base no corpo. Ao usar o roteamento com base no 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, evitando que as solicitações sejam encaminhadas incorretamente.
  • Permitir que o gateway distribua o tráfego automaticamente: o GKE Inference Gateway encaminha o tráfego de maneira inteligente monitorando as principais métricas dos servidores de inferência no InferencePool, como utilização do cache KV, comprimento da fila e índices de cache de prefixo. Esse balanceamento de carga em tempo real otimiza a utilização 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 melhorar a segurança e o gerenciamento, faça a integração com a Apigee para gerenciamento de APIs e com o 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 exige 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 da rede de aceleradores: 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 de comunicação exigida pela carga de trabalho, você pode escolher entre estas 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 desempenho aprimorado com maior descarregamento e maior 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.
    • RDMA do GPUDirect: oferece a maior largura de banda entre nós e a menor latência, permitindo o acesso direto à memória entre GPUs em diferentes nós, ignorando a CPU. É mais adequado para os cenários de inferência mais exigentes e em grande escala em máquinas A3 Ultra e A4.

    Veja mais informações em:

    Para validar se a configuração de rede de vários nós está funcionando como 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 de vários nós, é essencial gerenciar todos os componentes como uma única unidade. Para fazer 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 é essencial para manter a integridade de uma carga de trabalho distribuída.

  • Posicione os nós em proximidade física usando o 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 de rede entre nós. Para minimizar essa latência, use uma política de posicionamento compacto para seus 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óximos 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 capacidade de obtenção de aceleradores, reduzir a latência percebida pelo usuário e atender aos requisitos regulamentares específicos de cada local.

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

  • Provisione clusters do GKE em várias regiões onde você tem capacidade reservada ou prevê 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 Anywhere Cache para criar caches de leitura zonais para seus buckets do Cloud Storage e reduzir a latência da 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
  • Escolha os modelos certos para seus casos de uso de inferência
  • Aplicar quantização ao modelo
  • Escolha os aceleradores certos
  • Escolha 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 inicialização rápida
Planejamento de capacidade e disponibilidade de aceleradores
  • Planejar e reservar capacidade
  • Usar o Dynamic Workload Scheduler
  • Usar classes de computação personalizadas
  • Configurar a política de localidade dos clusters do GKE e dos pools de nós
Eficiência de recursos e aceleradores
  • Observe seus aceleradores e servidores de inferência
  • Escalonar automaticamente seus pods
  • Aproximar os dados das cargas de trabalho
Balanceamento de carga
  • Usar o gateway de inferência do GKE para implantações de cluster único
Implantações de vários nós
  • Maximizar a largura de banda e a capacidade da rede do acelerador
  • Usar LeaderWorkerSet para agrupar pods
  • Colocar nós em proximidade física usando posicionamento compacto
Implantações multirregionais
  • Provisionar clusters do GKE em várias regiões
  • Fazer o balanceamento de carga do tráfego entre regiões
  • Armazenar pesos de modelo em buckets do Cloud Storage
  • Armazenar dados em cache com o Anywhere Cache

A seguir