Benchmark do vLLM: Reproduza Latência, Throughput e Custo de GPU Antes da Implantação

Um benchmark do vLLM só é útil quando se assemelha ao tráfego que sua aplicação realmente enviará. Um número de tokens por segundo em destaque pode ocultar um primeiro token lento, uma fila sobrecarregada ou uma distribuição de prompts que nunca aparece em produção. Este guia oferece um benchmark de serving reproduzível: escolha uma carga de trabalho, varie a carga oferecida, registre a distribuição de latência e o throughput juntos e compare configurações de GPU com a mesma meta de qualidade.

Resposta rápida: Use vllm bench serve com uma versão e um modelo do vLLM fixados em um servidor de GPU dedicado. Mantenha o modelo, a precisão, os comprimentos de prompt e saída, as configurações de amostragem, o estado do cache e a localização do cliente fixos. Execute várias taxas de solicitação, capture TTFT, TPOT, latência de ponta a ponta, taxa de solicitações bem-sucedidas e tokens de saída por segundo; em seguida, escolha a configuração de menor custo que atenda ao seu objetivo de serviço na carga de pico. Uma única execução de throughput máximo não é um plano de capacidade.

O que medir em um benchmark do vLLM

A documentação de benchmark do vLLM define TTFT, latência entre tokens e TPOT por seus pontos de medição. Use essas definições ao comparar ferramentas. Em particular, o TTFT do cliente inclui trabalho de transporte e de frontend; métricas opcionais do lado do servidor podem separar a espera no agendador da execução do modelo, mas ativá-las adiciona sobrecarga. Mantenha execuções de diagnóstico separadas dos resultados principais.

Fixe uma comparação justa antes de executar

Documente a revisão do modelo e o tokenizador, a versão do vLLM, o tipo e a quantidade de GPUs, o tamanho do paralelismo de tensor, as flags de serving, o formato de quantização, o comprimento de contexto e o ambiente de software. Use os mesmos prompts e metas de saída para cada candidato. Se você alterar o modelo, a precisão e a GPU ao mesmo tempo, o resultado não poderá informar qual mudança ajudou.

Escolha pelo menos duas cargas de trabalho. Uma carga de trabalho sintética de comprimento fixo é útil para varreduras controladas; um rastreamento sanitizado de comprimentos de solicitações reais é melhor para uma decisão de produção. Preserve a distribuição de prompts longos, respostas curtas e picos. Para um produto de chat, meça o endpoint de chat com o backend de benchmark correspondente. Para uma carga de trabalho de completions, use o backend de completions. Não compare seus números como se a formatação das solicitações fosse idêntica.

Defina os critérios de aprovação antes da execução. Por exemplo, estabeleça uma taxa necessária de solicitações bem-sucedidas e TTFT p95 e latência de ponta a ponta p95 máximos para sua própria carga de trabalho. Não publicamos um limite universal: ele depende da experiência do usuário e do tamanho da saída. Uma tabela de aceitação com os limites, os resultados medidos e o motivo de aprovação/reprovação é mais útil do que uma única pontuação de desempenho.

Execute um teste de serving controlado

O atual guia da CLI do vLLM lista vllm bench serve para medições de serving online e recomenda o extra bench para suas dependências. O esquema a seguir usa o exemplo de completions documentado do vLLM. Substitua o modelo e o conjunto de dados por recursos que você esteja licenciado a executar e que sejam compatíveis com seu hardware. Estes comandos são um modelo reproduzível, não resultados medidos da Flatkey.

python -m pip install 'vllm[bench]'
vllm serve YOUR_MODEL_ID

Em um segundo shell, após o servidor estar pronto:

vllm bench serve \
  --backend vllm \
  --model YOUR_MODEL_ID \
  --endpoint /v1/completions \
  --dataset-name sharegpt \
  --dataset-path /path/to/ShareGPT_V3_unfiltered_cleaned_split.json \
  --num-prompts 1000 \
  --request-rate 1 \
  --save-result \
  --save-detailed

Em seguida, repita com uma curta série de valores mais altos de --request-rate, mantendo as outras entradas fixas. Use prompts suficientes para evitar interpretar um pequeno número de solicitações como uma distribuição de latência de cauda. Salve os resultados brutos e o comando exato de cada execução. O exemplo de benchmark online oficial mostra os campos de saída e explica como --save-result e --save-detailed preservam as evidências. Para solicitações de chat, use o backend openai-chat documentado e o endpoint /v1/chat/completions com um conjunto de dados e um modelo que ofereçam suporte à formatação de chat.

Não execute este benchmark em um endpoint de produção compartilhado sem um plano de tráfego. Ele cria carga intencionalmente. Use uma implantação de teste isolada ou uma janela de manutenção controlada e registre qualquer trabalho em segundo plano que possa afetar o resultado.

Faça uma varredura até encontrar o ponto de inflexão da latência

Trace a taxa de solicitações oferecida no eixo horizontal. Trace solicitações concluídas por segundo, TTFT p95, latência ponta a ponta p95 e tokens de saída por segundo como séries separadas. Inicialmente, o throughput pode aumentar aproximadamente em proporção à carga oferecida. Além da região sustentável, a fila cresce, a latência de cauda aumenta e o throughput bem-sucedido pode se estabilizar. Esse ponto de inflexão importa mais do que o maior número impresso em uma única execução.

Mantenha uma execução de aquecimento separada. O vLLM alerta que repetir um benchmark no mesmo servidor pode reutilizar prefixos em cache e inflar o throughput. Se a reutilização de cache não fizer parte da carga de trabalho do produto, varie a seed ou redefina o servidor ou o cache de acordo com as orientações oficiais de benchmark. Se a reutilização de cache for realista, informe a taxa de acertos de cache e inclua uma comparação com cache frio. Um benchmark sem uma política de cache declarada é difícil de reproduzir.

Quando uma execução não atingir sua meta, inspecione a sequência. Um aumento de TTFT com uma fila crescente pode indicar saturação ou controle de admissão. TPOT ruim com tempo de fila estável pode indicar decodificação, largura de banda de memória, paralelismo ou uma escolha ineficiente de precisão. Se as falhas aumentarem, examine timeouts, OOMs e logs do servidor antes de ajustar as configurações do modelo. Alterar várias variáveis de uma vez oculta a causa.

Compare opções de GPU pelo trabalho aceito, não pela velocidade bruta

Uma GPU maior pode produzir mais tokens de saída por segundo, mas ainda assim custar mais por solicitação aceita. Calcule um custo aproximado para cada configuração:

Custo de GPU por 1.000 solicitações bem-sucedidas = custo horário da GPU ÷ solicitações bem-sucedidas por hora × 1.000

Use uma cotação atual para a região e o compromisso exatos e inclua infraestrutura que não seja GPU ou incrementos mínimos de cobrança se forem relevantes. Compare apenas execuções que atendam às suas metas de latência e erro. Uma configuração mais barata que não atinge o TTFT p95 não é uma forma mais barata de fornecer o mesmo serviço.

Para uma comparação inicial na nuvem, mantenha o modelo e a configuração de serving fixos enquanto altera apenas o tipo de GPU. Em seguida, teste um pequeno número de ajustes, como configurações de lote e memória, um de cada vez. Capture utilização, margem de VRAM, profundidade da fila, taxa de sucesso das solicitações e o artefato de benchmark. O Flatkey Compute pode ser uma opção de capacidade a avaliar; verifique a GPU oferecida, a região e a cotação atual antes de usá-lo em uma comparação de custos. Este guia não afirma que uma GPU específica seja sempre mais rápida ou mais barata.

Um resultado de benchmark do vLLM que você pode entregar a um revisor

Para cada execução, registre: modelo e revisão; versões do vLLM e do driver; GPU e topologia; comando e checksum do conjunto de dados; distribuição dos comprimentos de entrada/saída; localização do cliente; política de cache; taxa de solicitações; solicitações concluídas e com falha; TTFT p50/p95/p99; latência ponta a ponta p50/p95/p99; throughput de tokens de saída; utilização de GPU e VRAM; cotação horária; custo por solicitação aceita; e aprovação/reprovação em relação à meta predeterminada.

Este também é o momento de manter a segurança e a qualidade visíveis. Os prompts de benchmark devem ser limpos de dados de clientes, e a qualidade da saída deve ser verificada ao comparar modelos quantizados ou diferentes revisões de modelo. Um ganho aparente de velocidade que altera a qualidade da tarefa não é uma vitória comparável.

Perguntas comuns

O vllm bench throughput é igual ao vllm bench serve?

Não. O primeiro visa ao throughput de inferência offline; o segundo envia solicitações online para um servidor em execução e mede o comportamento de atendimento voltado ao cliente. Use bench serve para o planejamento de latência e capacidade de uma implantação de API. A referência da CLI do vLLM lista ambos os comandos.

Qual número devo otimizar primeiro?

Comece pelo objetivo de serviço: taxa de sucesso e latência de cauda no pico de tráfego esperado. Em seguida, minimize o custo entre as configurações aprovadas. O throughput agregado de tokens é útil para diagnosticar capacidade, mas não pode substituir uma meta de latência voltada ao usuário.

Posso comparar números de benchmark publicados por diferentes provedores?

Apenas se o modelo, a precisão, a carga de trabalho, o comprimento da saída, o endpoint, a política de cache, o regime de taxa de solicitações e as definições de medição estiverem alinhados. Na maioria dos casos, executar novamente a mesma carga de trabalho em ambos os ambientes fornece uma comparação mais defensável.

Próximo passo: escolha um rastreamento representativo, defina os critérios de aprovação, execute uma breve varredura de taxa em duas configurações de GPU e mantenha os resultados completos junto com a decisão. Se você também estiver alterando a precisão, use o guia de quantização do vLLM separado para avaliar memória e qualidade antes de atribuir qualquer diferença de velocidade à GPU.