Para comparar o tempo até o primeiro token, ou TTFT, entre vLLM, TGI e SGLang em produção, use o mesmo modelo, hardware, conjunto de entradas e padrão de chegada de requisições. Meça a latência no cliente com resposta em streaming e publique percentis, falhas e configuração completa. Sem essas condições, um número menor pode refletir apenas uma carga mais fácil.
Este guia apresenta um protocolo reproduzível, sem resultados experimentais ou vencedor presumido. Há também uma diferença operacional relevante: na documentação consultada em 18 de outubro de 2026, a Hugging Face informa que o TGI está em modo de manutenção e recomenda considerar outros motores para novos projetos. Essa informação entra na avaliação de continuidade, separadamente dos resultados de desempenho.
Resumo rápido
- Defina exatamente quando o cronômetro começa e qual evento encerra o TTFT.
- Fixe modelo, tokenizer, precisão, GPU e versões dos motores.
- Separe cache frio, cache aquecido e inicialização do servidor.
- Compare a mesma taxa de chegada e contabilize erros e timeouts.
- Publique p50, p95, p99 e latência total, sem ocultar amostras ruins.
O que o TTFT mede e o que fica de fora
TTFT é o intervalo até o início da saída gerada. Em uma medição feita pelo cliente, proponha uma definição explícita: do instante imediatamente anterior ao envio HTTP até o recebimento do primeiro fragmento com conteúdo textual não vazio. Use um relógio monotônico, que mede intervalos sem depender de ajustes no relógio civil.
Essa definição operacional precisa ser aplicada aos três motores. Um evento de streaming que informa apenas o papel do assistente não deve encerrar a contagem. Um cabeçalho recebido também não equivale a texto disponível. Registre como o coletor identifica o conteúdo, sobretudo quando há campos separados para raciocínio, chamadas de ferramentas ou dados estruturados.
O primeiro fragmento recebido pode conter mais de um token. Portanto, a métrica do cliente aproxima a experiência de início da resposta e não revela necessariamente o instante de emissão de um token individual no servidor. Não apresente precisão maior do que o transporte e o coletor conseguem observar.
O TTFT do cliente incorpora rede, fila, processamento da entrada e entrega do início da saída. Ele não substitui a duração total nem a cadência posterior. Um motor pode começar rápido e terminar devagar. Para uma visão mais ampla, combine este protocolo com o guia de latência e TTFT em produção com vLLM.
Congele o ambiente e documente os motores
Crie um manifesto por rodada. Inclua identificador e revisão dos pesos, revisão do tokenizer, template de conversa, precisão numérica, quantização, limite de contexto e parâmetros de geração. Acrescente imagem de contêiner por digest, versão do motor, bibliotecas, driver e configuração de paralelismo. A palavra “latest” não permite reconstruir o ambiente depois.
Documente modelo e quantidade de GPUs, memória, CPU, RAM e região do cliente. Registre se existem outros processos usando o acelerador. O teste deve ocorrer em ambiente isolado ou em janela controlada com autorização. Não coloque um gerador de carga sem limite contra o endpoint utilizado pelos clientes da empresa.
A documentação de vllm bench serve oferece um cliente de benchmark de serviço. O projeto SGLang também documenta um cliente de carga online no seu guia de benchmark e profiling. Antes de comparar relatórios, confira a versão do cliente e a definição das métricas implementadas.
O aviso oficial do TGI informa manutenção voltada a pequenas correções, documentação e tarefas leves. Isso não demonstra que uma instalação existente será lenta. Para novos projetos, porém, justifica avaliar compatibilidade futura, atualização e custo de migração, em vez de decidir apenas por uma tabela de latência.
| Motor | O que registrar | Cuidado na comparação |
|---|---|---|
| vLLM | Versão, argumentos completos e configuração de cache. | Não assumir que padrões de uma versão valem para outra. |
| TGI | Imagem fixada, parâmetros e compatibilidade do modelo. | Separar desempenho medido da decisão sobre manutenção. |
| SGLang | Versão, configuração de execução e reaproveitamento de prefixos. | Não dar a um motor entradas repetidas que os outros não recebem. |
| Cliente comum | Versão do coletor, parser e fronteiras do cronômetro. | Descartar eventos vazios sem descartar a requisição lenta. |
Monte uma matriz de carga que represente o uso
Separe entradas curtas, médias e longas conforme a distribuição observada na aplicação. Use tokens do mesmo tokenizer para medir comprimentos. Caracteres não garantem equivalência, especialmente quando os textos misturam português, código e documentos. Guarde um conjunto anonimizado ou sintético com checksum e ordem de execução.
Inclua dois cenários de prefixo. No primeiro, cada pergunta começa com conteúdo distinto. No segundo, há um bloco inicial compartilhado, como instruções fixas de atendimento. Mantenha a mesma proporção e ordem nos três motores. Não apresente uma comparação de cache aquecido como se descrevesse qualquer conversa nova.
Escolha limites de saída, parâmetros de amostragem e critérios de parada comuns. Se uma implementação não aceitar um parâmetro, registre a limitação e adapte o cenário para todos. Não force uma comparação aparentemente uniforme quando os pedidos enviados têm semânticas diferentes ou templates que acrescentam volumes distintos de entrada.
Teste uma sequência de taxas de chegada crescente, com limites de concorrência definidos. Um cliente que só envia o próximo pedido após concluir o anterior reduz a pressão quando o servidor fica lento. Para representar chegadas externas, use um cronograma independente das conclusões e registre também atrasos que o próprio gerador introduzir.
Defina antecipadamente aquecimento, duração e repetições. Como proposta de protocolo, execute três rodadas por cenário, alternando a ordem dos motores. Essa quantidade é uma escolha operacional, não uma garantia estatística. Amplie a coleta quando a variabilidade observada ou o número de amostras não sustentar as conclusões pretendidas, especialmente para p99.
Execute o protocolo e preserve as amostras
Comece verificando uma requisição manual em cada endpoint. Confirme que o modelo carregado é o correto, que a saída chega progressivamente e que o proxy não acumula os fragmentos. Um intermediário com buffering pode fazer o cliente receber tudo de uma vez e invalidar a interpretação do TTFT como começo perceptível da resposta.
Depois, execute o aquecimento previamente definido e salve seus resultados em arquivo separado. Não misture carregamento de pesos com operação estabilizada. Se a inicialização também importa para a arquitetura, meça-a como cenário próprio, com definição de início e prontidão. Cache frio dentro de um servidor já pronto é uma condição diferente de servidor recém-iniciado.
Para cada requisição, grave identificador, cenário, horário programado, instante de envio, primeira saída útil, término, status, tamanho de entrada e saída e erro. Use identificadores para correlacionar cliente e servidor. Evite guardar documentos de clientes no arquivo de resultados; o benchmark precisa de medidas e referências, não de conteúdo sensível espalhado em logs.
A regra de coleta pode ser expressa assim: iniciar o relógio imediatamente antes do envio; ler eventos completos do streaming; ignorar comentários e eventos sem conteúdo; marcar a primeira saída útil uma única vez; continuar até o término ou timeout; registrar sempre o desfecho. Não confunda uma linha recebida com um evento completo do protocolo.
Preserve os pedidos que falharem antes da primeira saída. Eles não têm um TTFT concluído, mas continuam no denominador de sucesso. Publique quantos terminaram, quantos tiveram timeout e quantos retornaram erro. Um cenário que deixa de atender parte dos usuários não pode parecer melhor porque o relatório calculou percentis somente para os sobreviventes.
Salve os arquivos brutos e o comando completo. O procedimento de registro de seed e temperatura complementa o manifesto, sem prometer identidade absoluta entre execuções. Após qualquer alteração de configuração, gere uma rodada identificada como nova, em vez de substituir silenciosamente o resultado anterior.
Exemplo: suporte técnico de uma empresa em Recife
Este caso é ilustrativo e não apresenta medições reais. Uma empresa de suporte técnico em Recife quer comparar os três motores para um assistente que consulta procedimentos internos. A equipe monta perguntas fictícias sobre instalação, acesso e diagnóstico, com documentos de diferentes comprimentos e respostas verificadas por técnicos.
Ela separa o tempo de busca documental do TTFT do endpoint de geração. Para medir a experiência completa, mantém também um cronômetro desde a entrada no aplicativo até a primeira resposta exibida. Assim, uma mudança no mecanismo de busca não é atribuída indevidamente ao motor de inferência, mas continua aparecendo no indicador percebido pelo atendente.
A matriz inclui perguntas novas e solicitações que reutilizam instruções fixas. A equipe mantém o mesmo hardware e alterna as rodadas. Antes de executar, define os limites de espera aceitáveis para a operação e as condições de interrupção do teste, evitando disputar recursos com o atendimento real.
O relatório fica inicialmente sem números: cada célula será preenchida a partir dos arquivos de execução. A equipe só recomendará uma implantação depois de conferir latência, erros, qualidade das respostas e esforço de manutenção. O exemplo não permite afirmar que um motor vence outro, porque nenhum experimento foi realizado aqui.
Leia percentis e diagnostique o gargalo
Apresente p50, p95 e p99 junto com o número de amostras válidas e o total de tentativas. Percentis altos descrevem a cauda da distribuição, mas ficam instáveis quando há poucas observações. Declare o método de cálculo e mostre as rodadas separadas, além de qualquer agregação, para não esconder variações entre execuções.
Compare TTFT na mesma carga oferecida e acompanhe latência total, tokens de saída por segundo e erros. Se houver um objetivo de serviço, publique a fração de requisições que cumpre esse objetivo. Uma configuração com maior vazão pode não ser adequada quando as filas tornam o começo da resposta lento demais para o usuário.
Use métricas do servidor para investigar, sem substituir a observação do cliente. A documentação de métricas do TGI descreve o endpoint Prometheus e medidas de execução. Correlacione os períodos lentos com fila, uso de memória e processamento de lotes, verificando as unidades e definições da versão instalada.
Não tire conclusões causais só porque dois gráficos aumentaram juntos. Faça uma alteração por vez, repita o mesmo cenário e mantenha a configuração anterior disponível para comparação. Se o cliente estiver limitado por CPU ou conexão, corrigir o motor não resolve a coleta. O gerador também precisa ser observado durante o teste.
Erros comuns
Declarar vencedor com uma requisição. Um pedido isolado não revela filas nem variabilidade. Use rodadas e publique a carga. Conclusões devem se limitar ao hardware, modelo e cenário efetivamente testados.
Confundir resposta HTTP com conteúdo. Cabeçalhos, metadados e eventos vazios podem chegar antes do texto. Documente o parser e verifique exemplos brutos. Caso contrário, o relatório pode medir o início da conexão em vez do início da resposta útil.
Comparar condições diferentes de cache. Prefixos repetidos podem favorecer cenários específicos. Separe os grupos e registre aquecimento. Não escolha apenas a configuração mais favorável de um motor para comparar com padrões de outro.
Eliminar timeouts do relatório. Eles devem aparecer como falhas com contagem explícita. Um timeout não vira uma resposta instantânea nem desaparece da taxa de atendimento. Publique também os critérios que determinaram o encerramento do pedido.
Escolher só pela latência. Valide qualidade, compatibilidade, observabilidade e capacidade de manter a implantação. No caso do TGI, o estado de manutenção deve constar da análise de adoção, sem ser usado como substituto de uma medição.
Perguntas frequentes
Qual motor tem o menor TTFT?
Este guia não realizou medições. O resultado depende de modelo, hardware, carga, cache e configuração. Um ranking só pode ser apresentado com os dados e as condições que o sustentam.
Posso comparar resultados de clientes diferentes?
Somente depois de verificar definições, pontos do cronômetro e tratamento de erros. Prefira um coletor comum quando os endpoints permitirem. Se precisar de clientes diferentes, documente as diferenças e não esconda essa limitação.
Preciso testar com streaming?
Sim, para observar o começo da saída no cliente. Sem entrega progressiva, o cliente normalmente só recebe o corpo ao final, o que impede separar adequadamente início e conclusão da geração.
Modo de manutenção torna o TGI inutilizável?
O aviso oficial não demonstra isso. Ele descreve o escopo de manutenção aceito pelo projeto. Instalações existentes devem avaliar seus requisitos, enquanto novos projetos precisam considerar suporte futuro e alternativas recomendadas pela documentação.
Um TTFT bom garante boa experiência?
Não sozinho. Verifique se a saída continua fluindo, termina no prazo e responde corretamente. Em aplicações com busca e ferramentas, meça também o percurso completo percebido pelo usuário.
