Para avaliar latência e TTFT em produção com vLLM, meça a experiência do cliente e o comportamento do servidor em paralelo. TTFT é o tempo até o primeiro token; ele não informa sozinho quando a resposta termina nem se o texto chega sem pausas. Compare percentis por tipo de requisição, acompanhe erros e teste a carga com entradas representativas.
Uma avaliação útil entrega uma faixa operacional: sob quais volumes e tamanhos de contexto o serviço atende ao objetivo definido pelo produto. Não existe um número universal de tokens por segundo que comprove qualidade de atendimento, e resultados de uma configuração não devem ser transferidos para outra sem teste.
Resumo rápido
- Separe primeiro token, intervalo entre tokens e conclusão da resposta.
- Instrumente cliente, gateway e motor para localizar a espera.
- Registre tamanho dos prompts, saídas, concorrência e erros.
- Teste carga crescente e rajadas sem esconder requisições lentas.
- Promova mudanças somente após comparar latência e qualidade.
Quais medidas representam a experiência
Uma aplicação com transmissão incremental pode mostrar texto antes de a geração terminar. Esse comportamento exige medir etapas distintas. O usuário percebe tanto a espera inicial quanto as pausas durante a leitura. Para uma tarefa que precisa receber um documento completo antes de agir, a duração total pode ser mais relevante do que o primeiro fragmento. Defina a prioridade a partir do fluxo real.
| Medida | Pergunta respondida | Limite da leitura isolada |
|---|---|---|
| TTFT | Quanto demora para começar a receber conteúdo? | Não descreve a duração do restante da geração |
| Latência entre tokens | Como a geração progride? | Uma média pode esconder pausas perceptíveis |
| Latência total | Quando a resposta está completa? | Depende bastante do comprimento da saída |
| Vazão | Quanto trabalho o serviço conclui? | Pode crescer enquanto a espera individual piora |
| Erros e cancelamentos | Quais pedidos não tiveram uma entrega utilizável? | Excluir essas tentativas favorece resultados enganosos |
Escolha um marco explícito para o início da medição no cliente. Pode ser o envio da requisição ou o início do fluxo completo na aplicação, incluindo etapas anteriores. Os dois são úteis, mas respondem a perguntas diferentes. Também diferencie o recebimento de cabeçalhos, o primeiro evento do protocolo e o primeiro conteúdo exibível. Um evento vazio não deve encerrar o cronômetro do primeiro texto.
Tokens são unidades do processamento do modelo, não necessariamente palavras. Fragmentos de rede também não precisam coincidir com tokens individuais. Se o cliente recebe vários tokens em um único bloco, sua medição de intervalos descreve blocos recebidos. Rotule o dado corretamente para evitar comparar uma medição de transporte com uma métrica interna de geração como se fossem idênticas.
Instrumente o servidor sem perder o caminho do cliente
A documentação de métricas de produção do vLLM descreve o endpoint /metrics e os histogramas de tempo até o primeiro token, duração da requisição e outras etapas. Confira os nomes efetivamente expostos pela versão instalada antes de importar um painel. Um gráfico vazio pode representar uma consulta incompatível, não ausência de lentidão.
Registre um identificador de requisição ao atravessar aplicação, gateway e serviço de inferência. No cliente, guarde tempos relativos usando um relógio apropriado para durações. No servidor, acompanhe a execução com a instrumentação disponível. Evite subtrair diretamente horários de máquinas diferentes sem controlar sincronização: isso pode produzir intervalos incorretos e apontar um gargalo que não existe.
O painel inicial deve relacionar tráfego recebido, requisições concluídas, falhas, espera e distribuição de tamanhos. Acrescente métricas de recursos para ajudar no diagnóstico, mas não trate utilização alta da GPU como prova de bom atendimento. O serviço pode estar ocupado e, ao mesmo tempo, acumular uma fila incompatível com o produto. A pergunta operacional é o que chega ao cliente dentro da meta.
Se a diferença entre o tempo observado no cliente e no motor aumentar, investigue gateway, rede, autenticação e processamento da aplicação. Verifique também se alguma camada acumula fragmentos antes de repassá-los. Uma conexão que funciona para respostas completas pode prejudicar a percepção de transmissão incremental. Faça uma requisição de controle pelo caminho normal e outra diretamente ao serviço, em ambiente autorizado, mantendo o restante comparável.
O guia de tracing de chamadas a modelos ajuda a ligar as etapas da aplicação. Para esta avaliação, registre conteúdo sensível apenas quando houver justificativa e controle de acesso. Comprimentos, códigos de resultado e identificadores costumam bastar para a primeira análise de latência.
Construa um teste representativo e reproduzível
Monte um conjunto de entradas a partir das características do uso real, sem copiar dados pessoais desnecessários. Separe mensagens curtas, contextos médios e documentos longos. Represente também saídas curtas e respostas extensas. Uma bateria com prompts quase idênticos e respostas sempre pequenas pode favorecer uma configuração que falha justamente nos pedidos mais relevantes do negócio.
Guarde a versão do vLLM, revisão do modelo, configuração do servidor, hardware, tokenizer e parâmetros de geração. Registre ainda o caminho de rede do gerador de carga e a versão do próprio teste. Sem esse inventário, uma diferença de resultado pode vir da infraestrutura, do conteúdo ou do cliente, e não do ajuste que a equipe pretende avaliar.
O comando vllm bench serve oferece controles de taxa de requisições e concorrência máxima. A referência oficial do benchmark distingue esses controles e permite salvar resultados. Consulte vllm bench serve --help no ambiente utilizado: a documentação da versão instalada deve orientar os argumentos do teste.
Taxa de chegada e concorrência não são a mesma coisa. Se um gerador espera a resposta anterior para enviar a próxima, o próprio sistema lento reduz a pressão exercida pelo teste. Para estudar uma demanda externa que continua chegando, represente esse padrão e registre o que de fato foi enviado. Compare a taxa planejada com a observada para detectar limitações do cliente de carga.
Execute aquecimento separado, depois uma janela estável e, por fim, cenários de rajada e recuperação. O objetivo não é manter a máquina saturada indefinidamente, mas descobrir onde a fila cresce e como volta ao normal. Defina antecipadamente condições de interrupção para proteger ambientes compartilhados. Um teste em produção deve ter escopo controlado, observabilidade e um responsável por encerrá-lo.
Repita cada condição suficiente para distinguir comportamento consistente de variação ocasional. Preserve as falhas e os pedidos interrompidos no relatório. Compare também períodos de cache frio e quente quando essa diferença fizer parte do uso. Informar apenas a melhor execução esconde justamente a variabilidade que o planejamento de capacidade precisa considerar.
Interprete percentis e transforme sinais em hipóteses
A mediana descreve o centro da distribuição. Percentis altos ajudam a observar a cauda, onde ficam pedidos mais lentos. Exiba a quantidade de observações e a janela usada, pois um percentil de uma amostra pequena não tem a mesma estabilidade de uma medição prolongada. Separe classes de tamanho para não atribuir toda mudança ao servidor quando a composição do tráfego mudou.
No Prometheus, histogramas permitem estimar quantis a partir de grupos de observações. A documentação de histogramas e summaries explica as diferenças e os cuidados de agregação. Não faça a média simples dos percentis de várias réplicas. Agregue os dados apropriados e preserve as dimensões necessárias à pergunta operacional.
Use um roteiro de diagnóstico. Se a espera inicial sobe com a fila, teste reduzir a pressão ou aumentar a capacidade disponível. Se o primeiro token demora principalmente em entradas longas, investigue o processamento do contexto. Se a geração inicia rápido, mas apresenta pausas, examine concorrência, escalonamento e transporte. Essas relações são hipóteses para experimentos, não conclusões automáticas extraídas de um único gráfico.
A documentação de otimização do vLLM discute o equilíbrio entre processamento inicial e geração incremental, incluindo o ajuste de tokens por lote. Não copie parâmetros de outro equipamento como receita. Altere uma variável por vez e compare TTFT, progressão da resposta, vazão, memória e qualidade no mesmo conjunto de tarefas.
Para avaliar capacidade útil, conte entregas que satisfazem simultaneamente os critérios do produto. Uma resposta rápida, porém incorreta ou truncada, não é uma entrega bem-sucedida. O conteúdo sobre avaliação de qualidade em português complementa esse teste. Mantenha a avaliação semântica junto ao relatório de desempenho quando mudar modelo, quantização ou parâmetros de saída.
Exemplo: atendimento de uma empresa em Curitiba
Imagine uma empresa de manutenção predial em Curitiba que usa um assistente para explicar procedimentos aos atendentes. Este é um cenário ilustrativo, sem resultados medidos. Há consultas curtas sobre agenda e perguntas que incluem relatórios técnicos longos. O time percebe demora no início de algumas respostas, mas ainda não sabe se ela ocorre na busca de documentos, na inferência ou no envio ao navegador.
A equipe define três marcos: início da solicitação, primeiro conteúdo útil e resposta concluída. O rastreamento separa recuperação de documentos e chamada ao motor. Depois, monta uma bateria com as mesmas proporções de tamanhos observadas no serviço, usando textos sintéticos equivalentes em estrutura. O teste conserva limites de saída para impedir que uma configuração pareça rápida apenas porque responde menos.
O relatório agrupa resultados por tamanho de entrada e mostra também erros. Uma mudança no processamento de lotes só é promovida se o grupo de consultas curtas continuar aceitável e o grupo de documentos longos não perder qualidade. A equipe verifica a apresentação no navegador, porque um intermediário que acumula dados pode esconder melhorias feitas no servidor.
O aceite inclui um exercício de recuperação: retirar a mudança e confirmar que o serviço volta à configuração anterior. Também exige que o painel tenha volume de tráfego e distribuição de tamanhos ao lado das latências. Assim, uma semana com mais relatórios longos não será confundida automaticamente com regressão da infraestrutura.
Erros comuns
Publicar apenas tokens por segundo. Vazão total não explica a espera por pessoa. Mostre os tempos de resposta por classe e o volume de pedidos concluídos dentro dos critérios definidos.
Medir primeiro byte como primeiro token. Cabeçalhos e eventos sem conteúdo podem chegar antes do texto. Documente o que interrompe o cronômetro e verifique essa condição no cliente.
Ignorar falhas e cancelamentos. Uma configuração pode parecer melhor se os pedidos mais difíceis desaparecerem da amostra. Registre tentativas, conclusões, erros, expirações e cancelamentos como resultados distintos.
Mudar várias condições de uma vez. Alterar modelo, quantização, contexto e concorrência impede atribuir o efeito a uma causa. Faça experimentos pequenos, conserve a linha de base e mantenha um procedimento de retorno.
Comparar percentis de populações diferentes. Antes de concluir que houve melhora, confira tamanhos de entrada e saída, carga, cache e janela. A diferença pode estar no trabalho recebido, e não na velocidade de execução.
Perguntas frequentes
Qual TTFT é considerado bom?
O limite depende do fluxo e da expectativa do usuário. Defina uma meta com o responsável pelo produto e valide com uso representativo. Não transforme um resultado de laboratório de outra aplicação em compromisso de atendimento.
Posso medir apenas no servidor?
Isso ajuda a investigar o motor, mas não cobre toda a experiência. O cliente inclui rede, intermediários e comportamento da interface. Mantenha as duas medições com nomes e pontos de início claramente definidos.
Por que a média melhora e ainda há reclamações?
A média pode esconder uma cauda lenta ou uma classe específica de requisições. Examine percentis, volume e distribuição por tamanho. Verifique ainda pausas durante a transmissão e duração total das respostas.
Mais concorrência sempre aumenta a capacidade?
Não necessariamente a capacidade útil. O serviço pode concluir mais trabalho agregado e deixar pedidos individuais esperando além da meta. A decisão deve combinar vazão, latência, erros, consumo de recursos e qualidade das respostas.
