O que causa falhas no serving de LLM e como corrigi-las?
Tradução automática
Este artigo foi traduzido automaticamente a partir da versão original em inglês.
As falhas no serving de LLM resultam muitas vezes de memória insuficiente, mais trabalho simultâneo do que o serviço consegue processar ou novas tentativas que repetem pedidos dispendiosos. Identifique o recurso ou a fase que falha antes de alterar o runtime. O carregamento bem-sucedido de um modelo não demonstra que consegue processar o tráfego previsto.
Relacione o sintoma com os dados observados
| Sintoma | Primeiros dados a analisar | Alteração a testar |
|---|---|---|
| Erro de falta de memória na GPU | Pesos, alocação de KV, ativações, comprimentos dos pedidos | Lote ativo mais pequeno, limites mais curtos ou quantização suportada |
| A latência aumenta sem erros | Utilização de KV, interrupções, pedidos em espera | Menos pedidos admitidos em simultâneo ou mais capacidade confirmada por medições |
| Primeiro token lento | Fila, tokenização, prefill, tempos de rede | Corrigir a fase lenta; testar prefill por blocos se as fases interferirem entre si |
| A carga aumenta após tempos de espera excedidos | Número de novas tentativas e trabalho ainda em execução | Novas tentativas limitadas e cancelamento do trabalho abandonado |
O armazenamento dos pesos e o armazenamento de KV são separados. Um modelo de 70B em FP16 precisa de cerca de 140 GB apenas para os valores dos pesos. Com uma organização convencional da cache de atenção completa, uma sequência de Llama 3.1 70B com 128K tokens acrescenta 40 GiB de dados KV em FP16, antes da sobrecarga do runtime. Nenhum dos valores, por si só, representa a necessidade total de memória.
Verifique as interrupções antes de aumentar a fila
Quando o espaço para KV é insuficiente, um motor de serving pode interromper pedidos. O vLLM V1 normalmente volta a calcular o trabalho interrompido, o que aumenta a latência mesmo que a API acabe por responder com sucesso. Relacione o número de interrupções com os comprimentos dos prompts, as sequências ativas e a utilização de KV.
Reduza o trabalho admitido ou altere a alocação de memória testada. Para aumentar a utilização de memória da GPU, é necessário confirmar que as restantes alocações continuam a caber. Mover dados KV reutilizáveis para a CPU ou para o disco também acrescenta transferências; não garante que um pedido ativo demasiado grande caiba em memória.
Limite as novas tentativas
Repita operações após falhas transitórias dentro de um prazo e de um orçamento de novas tentativas. Use intervalos progressivos com variação aleatória e atribua as novas tentativas a uma única camada para que as da gateway e as do cliente não se multipliquem. As orientações SRE da Google explicam como as novas tentativas podem agravar a sobrecarga.
Propague o cancelamento quando o chamador abandonar o pedido, verifique que a geração para e teste este comportamento sob carga. Uma fila com maior capacidade adia a rejeição, mas não cria capacidade de processamento.
Leia a secção modos de falha no serving de LLM do guia para conhecer os conceitos de memória e escalonamento relacionados.