Como o TTFT funciona
Uma medição de TTFT precisa de duas marcações de tempo:
TTFT = momento da primeira saída − momento de início da solicitação
A fórmula é simples. A escolha das marcações de tempo, não.
Um TTFT observado pelo cliente começa quando o cliente envia a solicitação e termina quando recebe o primeiro token ou bloco transmitido que contém conteúdo. Esse intervalo pode incluir:
- Envio da solicitação ao serviço.
- Autenticação, roteamento e enfileiramento.
- Conversão do prompt em tokens.
- Processamento do prompt completo, uma etapa chamada prefill.
- Seleção do primeiro token de saída.
- Conversão e envio dessa saída de volta ao cliente.
Durante o prefill, o modelo processa a entrada e prepara as informações de atenção armazenadas que reutilizará ao gerar os tokens seguintes. Prompts mais longos geralmente exigem mais trabalho de prefill. Um serviço ocupado pode adicionar enfileiramento antes do início desse trabalho.
Um TTFT no nível do mecanismo pode usar limites mais restritos. Por exemplo, a métrica de servidor do vLLM começa na chegada ao frontend, atualmente quando a tokenização começa. Portanto, ela não inclui o caminho de rede do cliente nem o trabalho realizado por uma aplicação upstream.
É por isso que o TTFT não é um número universalmente comparável. A documentação de benchmarking da NVIDIA o define desde o envio da consulta até o recebimento do primeiro token. O glossário do Google Cloud o descreve desde o recebimento do prompt pelo modelo até a produção do primeiro token. Ambas as convenções são úteis, mas medem partes diferentes da solicitação.
Exemplo prático
Suponha que uma solicitação transmitida tenha esta linha do tempo:
- 0 ms: O cliente envia o prompt e inicia o cronômetro.
- 40 ms: O serviço recebe a solicitação.
- 110 ms: O enfileiramento termina e o processamento começa.
- 350 ms: O processamento do prompt termina e o primeiro token é gerado.
- 390 ms: O cliente recebe o primeiro bloco que contém conteúdo.
O TTFT observado pelo cliente é de 390 ms.
Uma medição no servidor que começa quando a solicitação chega e termina quando o token é gerado é de 310 ms: 350 ms menos 40 ms.
A diferença de 80 ms vem do escopo da medição. Ela não indica que nenhum dos cronômetros esteja impreciso.
O mesmo exemplo também mostra por que você não deve interpretar o TTFT como a latência total. A geração continua após 390 ms. Os intervalos entre tokens posteriores e o tempo até o token final são medições separadas.
Quando e por que o TTFT é importante
O TTFT é mais importante quando a saída pode ser usada assim que começa. Interfaces de chat, assistentes de programação e sistemas de texto ao vivo podem mostrar progresso após a chegada do primeiro conteúdo. Um TTFT menor reduz a pausa silenciosa antes desse retorno.
Ele é menos importante por si só quando a aplicação precisa esperar a resposta completa. Um trabalho de sumarização em lote, por exemplo, pode se preocupar mais com o tempo total de conclusão ou com a vazão geral.
Use o TTFT para investigar o início de uma solicitação. Um valor alto pode indicar um prompt longo, uma oportunidade perdida de usar o cache de prompts, enfileiramento sob carga, um worker frio, sobrecarga do frontend ou distância de rede. O TTFT, sozinho, não consegue dizer qual etapa é responsável. Combine-o com traces ou medições separadas de enfileiramento, prefill e rede.
Ao comparar sistemas, mantenha a carga de trabalho constante. Use a mesma distribuição de comprimento dos prompts, o mesmo estado de cache, a mesma simultaneidade, o mesmo comportamento de streaming, a mesma localização do cliente e os mesmos eventos de início e término. Relate uma distribuição, como a mediana e os percentis de cauda, em vez de uma única solicitação excepcionalmente rápida. A metodologia de benchmark da MLCommons usa cenários definidos e trata o TTFT da fase do prompt separadamente da temporização da fase de geração por esse motivo.
Equívocos comuns
Um TTFT baixo não significa que a resposta completa seja rápida. Um sistema pode começar rapidamente e depois gerar lentamente. Outro pode começar devagar e produzir rapidamente o restante da saída.
O streaming não reduz automaticamente o tempo de computação do modelo. Ele permite que o cliente observe uma saída parcial antes da conclusão da resposta. O buffering em um servidor, proxy ou cliente pode tornar o TTFT observado mais longo, mesmo quando o modelo gera o primeiro token no mesmo momento.
O primeiro bloco nem sempre corresponde a um único token. Os protocolos de streaming podem agrupar vários tokens em um único evento. Eventos vazios ou metadados não devem interromper o cronômetro se o objetivo for medir quando uma saída utilizável aparece.
Não existe um TTFT “bom” independentemente do contexto. O comprimento do prompt, a carga, o hardware, o cache, o caminho de rede e os limites da medição alteram o resultado. Uma meta deve descrever a carga de trabalho e o percentil a que se aplica.
Próximos passos
Leia O que é latência de inferência? para situar o TTFT na linha do tempo completa da solicitação. Leia O que são tokens por segundo? para entender a taxa de geração após a chegada do primeiro token. Para comparar a espera inicial com a velocidade de geração e a capacidade do sistema, use Latência vs. TTFT vs. tokens por segundo vs. vazão.