Este guia de práticas recomendadas mostra as métricas disponíveis e como selecionar as métricas adequadas para configurar o Escalonador automático horizontal de pods (HPA) para suas cargas de trabalho de inferência de JetStream com um único host e TPUs no GKE. O HPA é uma forma eficiente de garantir que os servidores de modelo escalonem corretamente com a carga. O ajuste de detalhes das configurações do HPA é a principal forma de alinhar seu custo de hardware provisionado com demandas de tráfego para alcançar suas metas de performance de servidor de inferência.
Para exemplos de como implementar essas práticas recomendadas, consulte Configurar escalonamento automático para cargas de trabalho de LLM em TPUs com GKE.
Objetivos
Este guia é destinado a clientes de IA generativa, usuários novos ou atuais do GKE, engenheiros de ML e engenheiros de LLMOps (DevOps) interessados em otimizar cargas de trabalho de host único do JetStream usando TPUs com Kubernetes.
Após ler este guia, você será capaz de:
- Entenda as principais métricas de escalonamento automático para inferência de host único do JetStream.
- Entender as vantagens e desvantagens de alto nível ao considerar quais métricas serão usadas no escalonamento automático.
Visão geral das métricas de escalonamento automático para inferência de JetStream
Recomendamos usar as seguintes métricas:
Métricas do servidor
O JetStream, assim como muitos outros servidores de inferência de LLM, fornece métricas de desempenho. O GKE simplifica o monitoramento e o escalonamento automático do JetStream com base nessas métricas no nível do servidor. Para configurar qualquer escalonamento automático, primeiro entenda como o pipeline de solicitação do JetStreams influencia os indicadores principais de desempenho. Todas as solicitações recebidas passam por uma fila de pré-preenchimento, uma fila de transferência e uma fila de geração, depois se tornando uma solicitação de decodificação. O JetStream aceita solicitações de decodificação de forma contínua e as processa simultaneamente usando um número fixo de linhas de execução de decodificação. A porcentagem de mecanismos de decodificação ocupados ao processar uma solicitação de decodificação em um determinado ponto é medida como a métrica jetstream_slots_used_percentage.
Para escalonar o JetStream de host único, isso tem duas implicações para a latência e a capacidade de processamento:
- As solicitações não serão acumuladas nas filas se a taxa de solicitações recebidas for menor do que a taxa em que os slots de decodificação podem processar as solicitações. Se o JetStream não tiver pendências, a capacidade de processamento será proporcional à taxa de solicitações recebidas. A latência vai permanecer praticamente constante, mas vai aumentar um pouco e proporcionalmente ao número de solicitações de decodificação simultâneas, já que as solicitações de decodificação recém-aceitas vão interromper a decodificação.
- As solicitações serão acumuladas nas filas quando a taxa de solicitações recebidas exceder a taxa em que os slots de decodificação podem processá-las. Se o JetStream tiver um backlog, a latência da solicitação aumentará de maneira mais significativa e proporcional ao número de solicitações acumuladas, enquanto a capacidade de processamento permanecerá constante.
As métricas de servidor a seguir têm a maior correlação com esses indicadores de desempenho relevantes. Recomendamos o uso delas para o escalonamento automático:
jetstream_prefill_backlog_size: o número de solicitações aguardando processamento na fila do servidor (backlog). Essa métrica tem uma forte correlação com a latência. Para saber mais, consulte a seção de práticas recomendadas relacionada.jetstream_slots_used_percentage: o número de solicitações em processo de inferência como uma porcentagem do número total de solicitações que o JetStream pode processar. Essa métrica tem forte correlação com a capacidade de processamento. Para saber mais, consulte a seção de práticas recomendadas relacionada.
Essas métricas geralmente são resilientes à performance e às variações de tráfego, o que faz delas um ponto de partida confiável para escalonamento automático em várias TPUs e configurações de hardware.
Métricas de TPU
Como a disponibilização do LLM apresenta um gargalo de memória e não de computação, recomendamos que você escalone o JetStream com o uso da memória em vez de com outras métricas de TPU, porque isso reflete melhor a utilização de recursos do hardware. Para saber mais, consulte a seção de práticas recomendadas relacionada.
Considerações para escolher métricas de escalonamento automático
Use as considerações e práticas recomendadas a seguir para selecionar a melhor métrica para escalonamento automático no GKE a fim de atender às metas de performance de carga de trabalho de inferência.
Prática recomendada: use o tamanho do backlog (fila) de preenchimento automático para maximizar a capacidade de processamento e minimizar o custo dentro de um determinado limite de latência de destino
Recomendamos o escalonamento automático de do tamanho da fila de pré-preenchimento ao otimizar a capacidade de processamento e o custo e quando as metas de latência forem alcançáveis com a capacidade de processamento máxima do seu tamanho máximo do lote do servidor de modelo.
O tamanho da fila de pré-preenchimento está diretamente relacionado à latência da solicitação. As solicitações recebidas enfileiram na fila de pré-preenchimento dos servidores de modelo antes de serem processadas, e esse tempo na fila aumenta a latência geral. O tamanho da fila é um indicador sensível de picos de carga, na medida em que a carga rapidamente preenche a fila.
O escalonamento automático com base no tamanho da fila de pré-preenchimento minimiza o tempo da fila ao escalonar verticalmente sob carga, e reduzindo a escala vertical quando a fila está vazia. Essa abordagem é relativamente fácil implementar porque o tamanho da fila é independente do tamanho, do modelo ou do hardware da solicitação.
Considere se concentrar no tamanho da fila de pré-preenchimento se quiser maximizar a capacidade de processamento de cada réplica do servidor de modelo. O tamanho da fila de pré-preenchimento rastreia solicitações pendentes, não em processamento. O JetStream usa lotes contínuos, o que maximiza as solicitações simultâneas e mantém a fila baixa quando o espaço em lote está disponível. A fila cresce visivelmente quando o espaço do lote é limitado, portanto, use o ponto de crescimento um sinal para iniciar o escalonamento vertical. Ao combinar o escalonamento automático de tamanho de fila com a capacidade de processamento em lote otimizada, é possível maximizar a capacidade de processamento das solicitações.
Determinar o limite ideal do tamanho da fila para o HPA
Para escolher o limite correto de tamanho da fila, comece com um valor entre 3 e 5 e aumente gradualmente até que as solicitações atinjam a latência preferencial. Use a ferramenta locust-load-inference para testes. Para limites abaixo de 10, ajuste as configurações de escalonamento vertical do HPA para lidar com picos de tráfego.
Também é possível criar um painel personalizado do Cloud Monitoring para visualizar o comportamento da métrica.
Limitações
Tenha atenção à tolerância de HPA, cujo padrão é um intervalo sem ação de 0,1 ao redor do valor de destino para reduzir a oscilação.
O tamanho da fila de pré-preenchimento não controla diretamente as solicitações simultâneas. Portanto, o limite não pode garantir uma latência menor do que o tamanho do lote por dispositivo permite. Como solução alternativa, é possível reduzir manualmente o tamanho do lote por dispositivo ou escalonar automaticamente no tamanho do lote.
Prática recomendada: use a porcentagem slots_used para alcançar limites de latência de destino menores do que o tamanho da fila
Recomendamos escolher slots_used com base em escalonamento automático se você tiver cargas de trabalho sensíveis à latência em que o escalonamento baseado em fila não é rápido o suficiente para atender aos seus requisitos.
O escalonamento automático em slots_used garante que a capacidade de processamento das cargas de trabalho seja aumentada para maximizar o número de solicitações processadas em paralelo de uma só vez e reduz a escala vertical quando menos solicitações são processadas em paralelo. Isso tem duas implicações para a latência. Primeiro, como o escalonamento automático baseado em slots_used é escalonado para garantir um slot para cada solicitação recebida, a proximidade do limite definido como 1 vai corresponder à probabilidade de uma solicitação passar tempo na fila e, consequentemente, ter uma latência maior. Em segundo lugar, tamanhos de lote maiores aumentam a capacidade de processamento, mas também aumentam a latência devido à fase de preenchimento inicial de algumas solicitações que interrompem a fase de decodificação de outras em servidores de modelo de lotes contínuos. É possível monitorar padrões de tamanho do lote e usar o escalonamento automático para minimizar solicitações simultâneas durante picos de carga.
Se o tamanho da fila já atender às metas de latência, priorize-a para escalonamento automático. Isso maximiza a capacidade de processamento e a eficiência de custos. No entanto, slots_used é útil para cargas de trabalho sensíveis à latência.
Também recomendamos ajustar o tamanho do lote por dispositivo para um valor adequado antes de explorar o escalonamento automático com base em slots_used. Também é possível combinar isso com o escalonamento automático baseado em fila.
Determinar o valor ideal do limite de porcentagem de slots_used para o HPA
Para escolher o limite certo de tamanho de lote, aumente de forma experimental a carga no seu servidor e observe onde o tamanho do lote atinge o pico. Também recomendamos o uso da
ferramenta locust-load-inference para testes. Depois de identificar um tamanho do lote ideal por dispositivo em que o uso de memória é maximizado, você pode configurar a meta de porcentagem slots_used. Defina o valor desejado inicial um pouco abaixo de 1 e diminua-o até que a latência preferencial seja alcançada.
Também é possível criar um painel personalizado do Cloud Monitoring para visualizar o comportamento da métrica.
Limitações
Tenha atenção à tolerância de HPA, que é um intervalo padrão sem ação de 0,1 em torno do valor de destino para reduzir a oscilação.
O escalonamento automático na porcentagem de slots_used, embora útil para o controle de latência, tem limitações. Vários tamanhos de solicitações e restrições de hardware fazem com que seja difícil encontrar o limite de porcentagem de slots_used certo. Ter uma regra de escalonamento que tenta manter a porcentagem slots_used média abaixo de 100% significa que a regra de escalonamento está tentando manter um número diferente de zero de slots disponíveis. Esses slots disponíveis correspondem à capacidade de processamento disponível que não está sendo usada, o que não é ideal se você quiser aproveitar ao máximo as TPUs disponíveis.
Prática recomendada: use a memória de alta largura de banda (HBM) da TPU para maximizar a utilização do hardware
O uso da memória de alta largura de banda (HBM) da TPU tem a correspondência mais direta com a utilização de hardware, mesmo em comparação com as métricas do sistema, já que elas não consideram os tamanhos de solicitação. Embora o escalonamento com o tamanho da fila maximize melhor a utilização do hardware, isso acontece à custa da latência. Se você preferir usar as métricas do sistema em vez das métricas do servidor, recomendamos o uso da HBM como a melhor alternativa para o escalonamento automático com slots_used, já que ambas correspondem à capacidade de processamento. Para mais informações sobre a memória da TPU, consulte Como uma TPU funciona.
Aumentar o tamanho do lote além do ponto ideal melhora a capacidade de processamento, mas também aumenta o risco de erros de falta de memória (OOM). Recomendamos o escalonamento com base na métrica de HBM para equilibrar a capacidade de processamento e a estabilidade. Recomendamos não dimensionar com o tamanho da fila de pré-preenchimento e o uso da HBM ao mesmo tempo, porque, à medida que a carga aumenta, o uso da HBM aumenta e aciona o dimensionamento primeiro.
Determinar o valor limite ideal de uso do HBM da TPU para o HPA
Antes de definir o limite de uso da memória, recomendamos definir o tamanho do lote por dispositivo para um valor que maximize a memória usada ao operar abaixo da carga máxima esperada. Esse valor precisa ser determinado experimentalmente e depende muito do HBM total, bem como das durações esperadas de comando e resposta. Recomendamos o uso da ferramenta locust-load-inference para experimentos e testes.
Assim como no tamanho do lote por dispositivo, defina o limite para maximizar a utilização da memória de TPU e minimizar o risco de comportamento por falta de memória.
Também é possível criar um painel personalizado do Cloud Monitoring para visualizar o comportamento da métrica.
Limitações
Há duas ressalvas que diminuem a força com que a latência e a capacidade de processamento correspondem ao uso da HBM, ou seja, a volatilidade do uso da HBM e a taxa de amostragem mais baixa das métricas de TPU em geral. Além disso, embora ainda exista uma correspondência entre o uso do HBM e a latência, os aumentos no uso do HBM afetam a latência muito menos do que o aumento no número de solicitações na fila.
Prática recomendada: otimizar a configuração do HPA
Recomendamos definir estas opções de configuração do HPA:
- Janela de estabilização: use essa opção de configuração do HPA para evitar mudanças rápidas na contagem de réplicas devido à flutuação das métricas. O padrão é 5 minutos para redução da escala vertical (evitando redução prematura) e 0 para escalonamento vertical (garantindo capacidade de resposta). Ajuste o valor com base na volatilidade da carga de trabalho e capacidade de resposta preferencial.
- Políticas de escalonamento: use essa opção de configuração do HPA para ajustar o comportamento de escalonamento vertical e horizontal. É possível definir o limite de política de "Pods" para especificar o número absoluto de réplicas alteradas por unidade de tempo, e o limite de política de "Percentual" a ser especificado pela alteração percentual.
Para saber mais sobre essas opções, consulte Escalonamento automático horizontal de pods na documentação do Kubernetes de código aberto.