Como planear a capacidade de GPU e o escalamento automático para LLMs?

Tradução automática

Este artigo foi traduzido automaticamente a partir da versão original em inglês.

Dimensione o conjunto de réplicas a partir do débito medido à latência exigida e, depois, verifique se cada réplica consegue alojar as sequências ativas previstas. Use distribuições reais dos comprimentos dos prompts e das saídas. Arredonde por excesso para réplicas completas de serving, incluindo todas as GPUs necessárias para o paralelismo de tensores ou de pipeline.

Verifique a memória antes do débito

Com uma organização convencional de cache de atenção completa, o Llama 3.1 70B precisa de 1.25 GiB de dados KV em FP16 para uma sequência de 4,096 tokens. Um orçamento hipotético de 40 GiB para KV aloja, por isso, no máximo 32 sequências desse tipo, antes de contabilizar a sobrecarga do alocador e do runtime. Com 131,072 tokens, uma sequência usa os 40 GiB completos.

Conte em conjunto os tokens de entrada e os gerados. A fórmula muda para arquiteturas como MLA e atenção com janela deslizante, e a alocação por dispositivo depende da partição. Este é um limite de memória, não uma previsão da dimensão do lote que cumpre os objetivos de latência. O cálculo de KV cache no guia apresenta os pressupostos e um cálculo executável.

Calcule réplicas completas

Suponha que as medições mostraram que uma réplica com duas GPUs consegue manter 1,200 tokens de saída por segundo com a TTFT e o TPOT exigidos para uma carga de trabalho fixa. A procura máxima prevista é de 4,000 tokens de saída por segundo. Um fator de segurança hipotético de 1.3 dá:

replicas=⌈4,000×1.31,200⌉=5\text{replicas} = \left\lceil \frac{4{,}000 \times 1.3}{1{,}200} \right\rceil = 5

Cinco réplicas com duas GPUs exigem dez GPUs. Estes valores ilustram o cálculo; não são resultados de benchmarks de hardware. Repita as medições quando mudar o modelo, a distribuição dos contextos, a topologia ou o SLO. Um fator de 1.3 significa um débito 30% superior à procura antes do arredondamento, e não 30% de capacidade por utilizar.

Aumente a capacidade antes de ultrapassar os prazos

Combine o comprimento da fila e o tempo de espera com o uso de KV, as preempções e o goodput que cumpre o SLO. A utilização de GPU pode manter-se elevada depois de o serviço ficar sobrecarregado. O vLLM documenta estas métricas de serving; determine os limiares a partir de testes de carga.

Meça a transferência de imagens, o carregamento dos pesos, a inicialização do modelo e o aquecimento antes de escolher os limiares de escalamento automático. Os controlos de escalamento de implementações do KEDA permitem reduzir as cargas de trabalho até zero, mas não eliminam a latência de arranque do modelo. Mantenha capacidade pronta quando os pedidos não puderem esperar pelo arranque.

Leia a secção sobre planeamento de capacidade e escalamento automático no guia para conhecer as decisões relacionadas com o hardware e a admissão de pedidos.