Este guia de práticas recomendadas mostra as métricas disponíveis e como selecionar métricas adequadas para configurar o Horizontal Pod Autoscaler(HPA) para as suas cargas de trabalho de inferência JetStream de anfitrião único com TPUs no GKE. O HPA é uma forma eficiente de garantir que os servidores do seu modelo são dimensionados adequadamente com a carga. Ajustar as definições do HPA é a principal forma de alinhar o custo do hardware aprovisionado com as exigências de tráfego para alcançar os objetivos de desempenho do servidor de inferência.
Para ver exemplos de como implementar estas práticas recomendadas, consulte o artigo Configure o dimensionamento automático para cargas de trabalho de MDIs em UTPs com o GKE.
Objetivos
Este guia destina-se a clientes de IA generativa, utilizadores novos ou existentes do GKE, engenheiros de ML e engenheiros de LLMOps (DevOps) interessados em otimizar as respetivas cargas de trabalho do JetStream de anfitrião único através de TPUs com o Kubernetes.
Depois de ler este guia, deve conseguir:
- Compreenda as principais métricas de dimensionamento automático para a inferência do JetStream de anfitrião único.
- Compreenda as compensações de alto nível quando considerar as métricas para dimensionamento automático.
Vista geral das métricas de escala automática para a inferência do JetStream
Recomendamos que use as seguintes métricas:
Métricas do servidor
O JetStream, como muitos outros servidores de inferência de MDIs, fornece métricas de desempenho. O GKE simplifica a monitorização e o ajuste de escala automático do JetStream com base nestas métricas ao nível do servidor. Para configurar qualquer dimensionamento automático, tem de compreender primeiro como o pipeline de pedidos do JetStream influencia os indicadores de desempenho principais. Todos os pedidos recebidos passam por uma fila de preenchimento, uma fila de transferência e uma fila de geração, tornando-se, em seguida, um pedido de descodificação. O JetStream aceita pedidos de descodificação de forma contínua e processa-os em simultâneo com um número fixo de threads de descodificação. A percentagem de motores de descodificação ocupados com o processamento de um pedido de descodificação num determinado momento é medida como a métrica jetstream_slots_used_percentage.
Para dimensionar o JetStream de anfitrião único, isto tem duas implicações para a latência e o débito:
- Os pedidos não ficam pendentes nas filas se a taxa de pedidos recebidos for inferior à taxa à qual os espaços de descodificação podem processar os pedidos. Se o JetStream não tiver atrasos, o débito será proporcional à taxa de pedidos recebidos. A latência vai permanecer praticamente constante, mas vai aumentar ligeiramente e proporcionalmente ao número de pedidos de descodificação simultâneos, uma vez que os pedidos de descodificação recentemente aceites vão interromper a descodificação.
- Os pedidos ficam em atraso nas filas quando a taxa de pedidos recebidos excede a taxa à qual os espaços de descodificação podem processar os pedidos. Se o JetStream tiver um atraso, a latência do pedido aumenta de forma mais significativa e proporcional ao número de pedidos em atraso, enquanto o débito permanece constante.
As seguintes métricas do servidor têm a correlação mais forte com estes indicadores de desempenho relevantes. Recomendamos que as use para o dimensionamento automático:
jetstream_prefill_backlog_size: o número de pedidos a aguardar processamento na fila do servidor (pendentes). Esta métrica tem uma forte correlação com a latência. Para saber mais, consulte a secção de práticas recomendadas relacionada.jetstream_slots_used_percentage: o número de pedidos em processamento de inferência como percentagem do número total de pedidos que o JetStream consegue processar. Esta métrica tem uma forte correlação com a taxa de transferência. Para saber mais, consulte a secção de práticas recomendadas relacionada.
Estas métricas são frequentemente resilientes às flutuações de desempenho e tráfego, o que as torna um ponto de partida fiável para o dimensionamento automático em diversas configurações de hardware de TPU.
Métricas da TPU
Uma vez que a publicação de MDIs é limitada pela memória e não pelo cálculo, recomendamos que dimensione o JetStream com a utilização de memória em vez de com outras métricas de TPUs, uma vez que reflete melhor a utilização de recursos do hardware. Para saber mais, consulte a secção de práticas recomendadas relacionada.
Considerações para escolher as métricas de escala automática
Use as seguintes considerações e práticas recomendadas para selecionar a melhor métrica para o dimensionamento automático no GKE de modo a cumprir os objetivos de desempenho da carga de trabalho de inferência.
Prática recomendada: use o tamanho da fila de pedidos pendentes de preenchimento para maximizar a taxa de transferência e minimizar o custo dentro de um determinado limite de latência alvo
Recomendamos o ajuste de escala automático do tamanho da fila de preenchimento quando otimizar o débito e o custo, e quando os seus objetivos de latência forem alcançáveis com o débito máximo do tamanho do lote por dispositivo do servidor do modelo.
O tamanho da fila de preenchimento está diretamente correlacionado com a latência do pedido. Os pedidos recebidos são colocados em fila na fila de pré-preenchimento dos servidores de modelos antes de serem processados, e este tempo de fila aumenta a latência geral. O tamanho da fila é um indicador sensível dos picos de carga, uma vez que o aumento da carga preenche rapidamente a fila.
A escala automática baseada no tamanho da fila de preenchimento minimiza o tempo de fila ao aumentar a escala sob carga e diminuir a escala quando a fila está vazia. Esta abordagem é relativamente fácil de implementar porque o tamanho da fila é independente do tamanho do pedido, do modelo ou do hardware.
Considere focar-se no tamanho da fila de preenchimento se quiser maximizar o débito de cada réplica do servidor do modelo. O tamanho da fila de preenchimento acompanha os pedidos pendentes, não os pedidos em processamento. O JetStream usa o processamento em lote contínuo, o que maximiza os pedidos simultâneos e mantém a fila baixa quando o espaço de lote está disponível. A fila cresce visivelmente quando o espaço de lotes é limitado, por isso, use o ponto de crescimento como um sinal para iniciar o aumento da escala. Ao combinar o ajuste de escala automático do tamanho da fila com o débito de lotes otimizado, pode maximizar o débito de pedidos.
Determine o valor de limite do tamanho da fila ideal para o HPA
Para escolher o limite de tamanho da fila correto, comece com um valor entre 3 e 5 e aumente-o gradualmente até que os pedidos atinjam a latência preferida. Use a ferramenta locust-load-inference para testes. Para limites inferiores a 10, ajuste as definições de expansão horizontal automática para processar picos de tráfego.
Também pode criar um painel de controlo personalizado do Cloud Monitoring para visualizar o comportamento das métricas.
Limitações
Tenha em atenção a tolerância do HPA, que é predefinida para um intervalo de não ação de 0,1 em torno do valor alvo para reduzir a oscilação.
O tamanho da fila de preenchimento não controla diretamente os pedidos simultâneos, pelo que o respetivo limite não pode garantir uma latência inferior à permitida pelo tamanho do lote por dispositivo. Como solução alternativa, pode reduzir manualmente o tamanho do lote por dispositivo ou dimensionar automaticamente o tamanho do lote.
Prática recomendada: use a percentagem de slots usados para atingir limites de latência alvo mais baixos do que o tamanho da fila
Recomendamos que escolha o ajuste de escala automático com base em slots_used se tiver cargas de trabalho sensíveis à latência em que o ajuste de escala com base em filas não é suficientemente rápido para satisfazer os seus requisitos.
O dimensionamento automático em slots_used garante que o débito das suas cargas de trabalho é dimensionado para maximizar o número de pedidos processados em paralelo de uma só vez e é reduzido quando há menos pedidos a serem processados em paralelo. Isto tem duas implicações para a latência. Primeiramente, uma vez que o dimensionamento automático baseado em slots_used é dimensionado para garantir um espaço para cada pedido recebido, a proximidade do limite definido para 1 corresponde à probabilidade de um pedido passar tempo na fila e, consequentemente, ter uma latência mais elevada. Em segundo lugar, os tamanhos dos lotes maiores aumentam o débito, mas também aumentam a latência devido à fase de preenchimento de alguns pedidos que interrompem a fase de descodificação de outros em servidores de modelagem de processamento em lote contínuo. Pode monitorizar padrões de tamanho do lote e usar o dimensionamento automático para minimizar os pedidos simultâneos durante picos de carga.
Se a dimensão da fila já cumprir os seus objetivos de latência, dê-lhe prioridade para o dimensionamento automático. Isto maximiza o débito e a rentabilidade. No entanto, slots_used é valioso para cargas de trabalho sensíveis à latência.
Também recomendamos que ajuste o tamanho do lote por dispositivo para um valor adequado antes de explorar o ajuste automático com base em slots_used. Opcionalmente, também pode associar esta funcionalidade ao dimensionamento automático baseado em filas.
Determine o valor de limite da percentagem de slots_used ideal para HPA
Para escolher o limite do tamanho do lote correto, aumente experimentalmente a carga no seu servidor e observe onde o tamanho do lote atinge o pico. Também recomendamos que use a ferramenta locust-load-inference para testes. Depois de identificar um tamanho do lote ideal por dispositivo em que a utilização da memória é maximizada, pode configurar a percentagem alvo de slots_used. Defina o valor alvo inicial ligeiramente abaixo de 1 e diminua-o até alcançar a latência preferida.
Também pode criar um painel de controlo personalizado do Cloud Monitoring para visualizar o comportamento das métricas.
Limitações
Tenha em atenção a tolerância de HPA, que é um intervalo de não ação predefinido de 0,1 em torno do valor alvo para reduzir a oscilação.
O ajuste automático de escala com base na percentagem de slots_used, embora seja útil para o controlo da latência, tem limitações. A variação dos tamanhos dos pedidos e as restrições de hardware dificultam a procura do limite percentual de slots_used adequado. Ter uma regra de dimensionamento que tenta manter a percentagem média de slots_used abaixo de 100% significa que a regra de dimensionamento está a tentar manter um número diferente de zero de slots disponíveis. Estes espaços disponíveis correspondem ao débito disponível que não está a ser usado, o que não é ideal se quiser tirar o máximo partido das suas UTPs disponíveis.
Prática recomendada: use a memória de largura de banda elevada (HBM) da TPU para maximizar a utilização do hardware
A utilização de memória de largura de banda elevada (HBM) da TPU tem a correspondência mais direta com a utilização do hardware, mesmo em comparação com as métricas do sistema, uma vez que não têm em conta os tamanhos dos pedidos. Embora o escalamento com o tamanho da fila maximize melhor a utilização do hardware, fá-lo à custa da latência. Se preferir basear-se em métricas do sistema em vez de métricas do servidor, recomendamos a utilização de HBM como a melhor alternativa para o dimensionamento automático com slots_used, uma vez que ambos correspondem ao débito. Para mais informações sobre a memória da TPU, consulte o artigo Como funciona uma TPU.
Aumentar o tamanho do lote para além do ponto ideal melhora o débito, mas também aumenta o risco de erros de falta de memória (OOM). Recomendamos vivamente que faça o escalonamento com base na métrica HBM para equilibrar o débito e a estabilidade. Recomendamos que não faça o escalonamento com o tamanho da fila de preenchimento e a utilização da HBM ao mesmo tempo, uma vez que, à medida que o carregamento aumenta, a utilização da HBM aumenta e aciona o escalonamento primeiro.
Determine o valor de limite de utilização de HBM de TPU ideal para o HPA
Antes de escolher o limite de utilização de memória, recomendamos que defina o tamanho do lote por dispositivo para um valor que maximize a memória utilizada quando estiver a funcionar com a carga máxima esperada. Tenha em atenção que este valor tem de ser determinado experimentalmente e depende muito do HBM total, bem como dos comprimentos esperados de comandos e respostas. Recomendamos que use a ferramenta locust-load-inference para a sua experimentação e testes.
Semelhante ao tamanho do lote por dispositivo, defina o limite para maximizar a utilização da memória da TPU e minimizar o risco de comportamento OOM.
Também pode criar um painel de controlo personalizado do Cloud Monitoring para visualizar o comportamento das métricas.
Limitações
Existem duas ressalvas que diminuem a força com que a latência e a taxa de transferência correspondem à utilização de HBM, nomeadamente a volatilidade da utilização de HBM e a taxa de amostragem inferior das métricas de TPU em geral. Além disso, embora ainda exista uma correspondência entre a utilização do HBM e a latência, os aumentos na utilização do HBM afetam a latência muito menos do que os aumentos no número de pedidos em fila.
Prática recomendada: otimize a configuração do HPA
Recomendamos que defina estas opções de configuração do HPA:
- Período de estabilização: use esta opção de configuração do HPA para evitar alterações rápidas na contagem de réplicas devido a métricas flutuantes. As predefinições são 5 minutos para a redução (evitando a redução prematura) e 0 para o aumento (garantindo a capacidade de resposta). Ajuste o valor com base na volatilidade das cargas de trabalho e na capacidade de resposta preferida.
- Políticas de escalabilidade: use esta opção de configuração do HPA para ajustar o comportamento de aumento e diminuição da escala. Pode definir o limite da política "Pods" para especificar o número absoluto de réplicas alteradas por unidade de tempo e o limite da política "Percentagem" para especificar pela percentagem de alteração.
Para saber mais acerca destas opções, consulte o artigo Escala automática horizontal de pods na documentação do Kubernetes de código aberto.