Runpod mostra como o GuideLLM ajuda a extrair o máximo do vLLM

A Runpod publicou em seu blog um guia sobre o uso conjunto de vLLM e GuideLLM. A ideia é simples: antes de liberar o modelo para os usuários, rode uma simulação de tráfego real e observe três números: o tempo até o primeiro token, a latência entre tokens e o throughput. São eles que definem de quantas GPUs você vai precisar e quanto pagará por milhão de tokens. A publicação original é curta e funciona mais como anúncio de um guia prático, por isso não traz benchmarks concretos em placas. Mesmo assim, a metodologia merece uma análise.

Por que «rápido no meu notebook» não significa nada

O vLLM já se tornou um dos motores padrão para inferência de modelos abertos. Ele usa continuous batching e PagedAttention para gerenciar o KV-cache e funciona muito bem com poucas requisições. Os problemas aparecem sob carga. Quando dezenas de requisições chegam ao mesmo tempo, com prompts de tamanhos diferentes, o cache enche, a fila cresce e a latência do primeiro token pode aumentar várias vezes.

Uma requisição isolada não mostra isso. É preciso um gerador de carga que se comporte como usuários reais: as requisições chegam em ondas, não uma a uma, e prompts e respostas têm tamanhos variados. O GuideLLM foi criado para isso. É uma ferramenta aberta do ecossistema vLLM. Ela se conecta a um endpoint compatível com a API da OpenAI, envia requisições sintéticas ou definidas por você e coleta estatísticas.

Como é uma rodada de teste

O esquema na Runpod é o padrão. Você sobe um pod ou um worker serverless com vLLM, obtém o endereço do endpoint e executa o GuideLLM a partir dele ou de outra máquina. Em seguida, define o perfil de carga: tamanho da entrada e da saída em tokens, modo de envio das requisições e duração. Em geral estão disponíveis taxa fixa, fluxo de Poisson, modo de throughput máximo e execução sequencial, em que o servidor não é sobrecarregado. Para um primeiro reconhecimento, o sweep é prático: ele percorre cargas crescentes e mostra onde a curva de latência se quebra. Os nomes exatos das flags mudam de versão para versão, e o melhor é conferi-los na documentação.

Na saída, você recebe um relatório com os seguintes indicadores:

• TTFT, tempo até o primeiro token: determina quão responsivo o chat parece;
• ITL, latência entre tokens: dela depende a fluidez do streaming;
• latência de ponta a ponta da requisição inteira, importante para APIs e cadeias de agentes;
• requisições por segundo que o servidor sustenta antes de degradar;
• tokens por segundo por placa, o valor-chave para calcular o custo;
• número de requisições simultâneas a partir do qual as filas crescem.

O ponto está na comparação. Se o TTFT fica dentro da meta sob determinada carga e depois dispara, esse é o seu teto de operação na configuração atual.

Na prática: das métricas à conta da GPU

A ordem das ações é esta.

1. Descreva o seu tráfego real: tamanho médio e máximo do prompt, tamanho da resposta e pico de carga. Se você ainda não tem logs, use estimativas conservadoras e refine depois.

2. Defina metas de TTFT e ITL. Elas serão diferentes para uma interface de chat e para o processamento em lote de documentos.

3. Rode o sweep em várias configurações: GPUs diferentes, quantizações diferentes, valores distintos de comprimento máximo de contexto e de fração de memória reservada ao KV-cache. 4.

Para cada configuração, encontre a carga máxima em que as metas são cumpridas e divida o preço por hora da placa pelo número de tokens obtido. Esse é o preço real do token. 5.

Em implantações serverless, verifique também a inicialização a frio (cold start) e o comportamento diante de um crescimento abrupto da fila. Um benchmark estático não mostra nenhum dos dois.

Há uma ressalva. A carga sintética continua sendo um modelo, não a realidade. Se os seus usuários têm prompts de sistema longos com prefixo comum, ativar o prefix caching muda o quadro, e o teste precisa ser montado levando isso em conta. Além disso, os resultados dependem da versão do vLLM, dos drivers e da placa específica, então vale repetir a rodada após atualizações.

O principal valor de um guia como esse está na disciplina. Escolher GPU e configurações no feeling costuma terminar em pagar a mais por uma folga que ninguém usa. Meia hora de teste de carga rende números que você pode levar ao financeiro.