Por que uma GPU mais rápida não resolve o tempo até o primeiro token (TTFT)

Quando o primeiro token demora a aparecer, a conclusão parece óbvia: a GPU deve estar lenta. Aí a equipe troca A100 por H100, adiciona placas — e a conta sobe. A latência do primeiro token cai alguns pontos percentuais e, sob carga real, não cai nada. O problema continua lá, mas com mais hardware e mais dinheiro gasto. É o erro mais caro da inferência de LLMs, e ele nasce de uma confusão simples sobre para onde o tempo realmente vai.

O tempo até o primeiro token (TTFT, na sigla em inglês) é o intervalo entre o envio da requisição e a aparição do primeiro token de saída. Em um cluster de produção desagregado, o prefill — a etapa de processamento do prompt que uma GPU mais rápida de fato acelera — responde por apenas 2% a 23% do TTFT no percentil 95 (P95). Os outros 77% a 98% ficam em fila de espera e transferência de cache KV. É isso que um artigo conceitual da DigitalOcean, escrito pela engenheira Haimantika, desmonta com dados de produção.

Do que o TTFT é feito de verdade

Para um produto interativo, o TTFT é o número que o usuário sente como “já começou?”. O caminho completo de uma requisição num endpoint de inferência em produção tem quatro etapas, e apenas uma delas é acelerada por GPU.

Só uma linha dessa tabela — a computação do prefill — é acelerada por uma GPU ou kernel mais rápido. Todas as outras são definidas por como você provisiona e como você agenda.

Prefill e decode são trabalhos opostos

Toda requisição de LLM roda em duas fases que estressam a GPU em direções contrárias.

O prefill processa o prompt inteiro de uma vez. Num prompt de 2.000 tokens, o modelo empurra os 2.000 tokens por um único forward pass, constrói o cache KV (o estado de atenção reutilizado no resto da requisição) e emite o primeiro token. Como milhares de tokens passam juntos, as unidades de computação ficam ocupadas — nas medições citadas no artigo, o prefill manteve a utilização dos multiprocessadores de streaming entre 75% e 84%. Prefill é limitado por computação, e é exatamente isso que uma GPU mais rápida acelera.

O decode produz o restante da resposta um token por vez. Para gerar o token 501, o modelo faz um forward pass completo que lê todos os pesos da memória para produzir um único token — e repete para o 502, 503 e assim por diante. Uma resposta de 500 tokens são 500 passadas sequenciais. A uma taxa morna de ~30 ms por token, isso dá cerca de 15 segundos de decode. Cada passada move uma quantidade enorme de memória para produzir um token, então o limite é largura de banda de memória, não computação. Nas mesmas medições, o decode nunca passou de 27% de utilização de computação.

Dois números resumem a assimetria: 75% a 84% de utilização no prefill, menos de 27% no decode. O prefill é onde a GPU ganha o preço; o decode é onde ela fica ociosa. E o primeiro susto é que, mesmo no prefill — onde a GPU está genuinamente ocupada —, a computação ainda não é o que torna o TTFT lento.

A evidência: prefill é minoria no P95

Um estudo de 2026 sobre agendamento de prefill com consciência de carga mediu isso diretamente. Num cluster estilo produção com A100 em configuração 2P2D (dois nós de prefill e dois de decode), os autores quebraram o TTFT no P95 em espera de fila de prefill, execução do prefill, transferência de cache KV e espera de fila de decode. Resultado: a execução do prefill respondeu por só 2% a 23% do P95 do TTFT. Fila e transferência de cache KV entre nós ficaram com os outros 77% a 98% (estudo “Towards Load-Aware Prefill Deflection for Disaggregated LLM Serving”).

As GPUs não estavam ociosas — os nós de prefill rodavam a 75%-84% de utilização. A computação estava ocupada, mas não era lá que morava a latência de cauda. Alguns números do mesmo estudo:

• Com prompts longos (perto de 14K tokens) a ~1 requisição por segundo, só a fila de prefill alcançou centenas de milissegundos por engine, e a transferência de cache KV adicionou mais de 1,5 segundo no P95 — subindo para perto de 3,5 segundos sob pressão de memória nos nós de decode.
• Com prompts curtos, a fila de prefill caiu abaixo de 60 ms, mas o P95 de ponta a ponta continuou acima de 6 segundos por causa do congestionamento no lado do decode, com transferência de cache KV chegando a 4,2 segundos no P95.
• Sob tráfego em rajada, a fila de prefill disparou para 840 ms enquanto a transferência de cache KV bateu 2,1 segundos no P95.

A correção que funcionou no paper não foi um chip mais rápido: foi um agendador mais inteligente que deixou os nós de decode absorverem o trabalho de prefill em passos fatiados e pulou a transferência de rede por completo. Essa mudança cortou o P95 do TTFT em até 81%. Uma decisão de agendamento moveu o número quatro vezes mais do que um upgrade de hardware conseguiria de forma realista.

Não é resultado de um único paper. Uma avaliação separada de vLLM desagregado em oito GPUs AMD MI300X encontrou que a transferência de cache KV adicionou cerca de 1,9x ao TTFT em média, e a penalidade era pior para prompts curtos — que dão menos computação de prefill para sobrepor à transferência. No momento em que você desagrega, converte o cache KV num payload de rede, e esse payload cai bem dentro do TTFT.

Como você provisiona define seu “imposto de cold start”

Scale-to-zero é o recurso que torna a economia de GPU serverless atraente: sem requisições, a GPU desliga e você não paga nada. A contrapartida é que a próxima requisição precisa acordar uma máquina fria — e acordar uma máquina que carrega um modelo grande é lento.

Um cold start de LLM é uma sequência de etapas mensuráveis:

1. Pull da imagem do container — imagens de inferência de GPU são grandes, de 10 a 30 GB. Sem cache, pode ser a maior fase, levando minutos.
2. Carregamento dos pesos na VRAM — um modelo 70B em FP16 tem ~140 GB de pesos. Transmitir isso para a memória da GPU leva 40 segundos ou mais, mesmo a 3-4 GB/s.
3. Inicialização do contexto CUDA e captura de grafos — mais 10 a 30 segundos em configurações típicas de vLLM.
4. Warmup opcional — compilação de kernels e inicialização do cache KV podem estender a primeira requisição ainda mais.

Somando tudo, cold starts de LLM serverless ficam tipicamente entre 30 e 90 segundos, chegando a vários minutos com imagem grande sem cache. Compare com inferência quente, que gera tokens em ~30 ms cada. A diferença entre um primeiro token frio e um quente é da ordem de 1000x. E cold starts não são raros sob tráfego real: uma análise de traces de produção serverless encontrou que mais de 40% das funções tiveram taxa de cold start acima de 25% numa janela de keep-alive de 5 minutos. Se um quarto das suas requisições pode cair num caminho frio, sua cauda é definida pelo caminho frio.

As alavancas aqui são todas de arquitetura: manter uma réplica mínima quente (paga-se por GPU ociosa, mas para produto interativo esse custo costuma ser menor que perder usuários para um primeiro token de 60 segundos), usar streaming de pesos e snapshots de memória (reduções médias de cold start em torno de 71%, até 88% no vLLM) e enxugar e cachear a imagem do container. O ponto é que nenhuma delas é uma compra de hardware — uma GPU mais rápida ainda precisa puxar a imagem e carregar os pesos.

Agregado vs desagregado: TTFT contra tokens por segundo

A segunda alavanca é onde prefill e decode rodam fisicamente. Eles podem dividir a mesma GPU (agregado/colocado) ou viver em pools separados (desagregado), cada um ajustado de forma independente.

Frameworks open source como vLLM, SGLang, Dynamo e llm-d já suportam serving desagregado, e a transferência pode trafegar por NIXL, CXL ou NVMe-oF. Existe ainda um caminho do meio: o prefill fatiado (chunked prefill), que quebra um prefill longo em pedaços menores intercalados com passos de decode, limitando o bloqueio de cabeça de fila sem pagar transferência de rede completa. Abordagens cache-aware vão além, separando prompts frios dos quentes e reutilizáveis.

Quando a GPU é, sim, a alavanca certa

Honestidade é o ponto do argumento, então aqui está o caso contra ele. Existe um regime em que a computação do prefill domina de verdade o TTFT: contexto muito longo. O trabalho de prefill cresce com o tamanho do prompt e, em comprimentos extremos, deixa de ser erro de arredondamento e vira o orçamento inteiro. Um exemplo trabalhado num modelo 8B com prompt de 1 milhão de tokens coloca o tempo de prefill teórico numa única A100 em cerca de 14,5 minutos — e frameworks reais rodam 1,5x a 2x mais devagar que o teórico. Atingir um TTFT de 20 segundos nesse comprimento exige algo como 65 A100s ou mais, 20 H100s ou mais, ou uma mudança algorítmica como atenção esparsa dinâmica.

A regra, então, não é “GPU nunca importa”. É que GPU importa no regime limitado por prefill — e a maior parte do tráfego de produção não está nesse regime:

• Prompts curtos a médios, tráfego interativo: você é limitado por fila e por provisionamento. Corrija agendamento e cold start primeiro — uma GPU mais rápida quase não move o TTFT aqui.
• Contexto muito longo, prompts em escala de documento ou codebase: você é limitado por prefill. Computação mais rápida, kernels melhores ou atenção esparsa são os investimentos certos.

Uma estrutura de decisão

Como medir na sua própria stack

Você não gerencia o que reporta como um número único. A razão pela qual tantos times recorrem a uma GPU mais rápida é que medem o TTFT como um valor opaco, e o único botão visível ligado a “latência” no modelo mental deles é “velocidade do chip”. Quebre o número e os botões reais aparecem:

1. Instrumente o TTFT em suas etapas: cold start (por fase), espera de fila, prefill e transferência de cache KV — registre cada uma separadamente.
2. Reporte P95 e P99, não médias. Cold starts e filas são fenômenos de cauda, e médias os escondem.
3. Faça benchmark da sua carga real, incluindo estrutura multi-turno e reuso de prefixo, não prompts sintéticos de um tiro só.
4. Expresse cada troca em latência e em dinheiro — provisionamento e agendamento são decisões econômicas.

A conclusão do artigo é direta: a GPU sempre leva a culpa porque é a única parte da stack com etiqueta de preço e folha de especificações. Fila, cold start e transferência de cache KV não aparecem em benchmark de fornecedor — ficam invisíveis até dominarem sua latência de cauda. Antes de aprovar o upgrade, quebre o número e olhe honestamente: o segundo mais rápido e barato que você vai economizar é aquele que estava prestes a pagar caro para uma GPU consertar.