Latência é quanto tempo o sistema leva para responder; throughput é quanto ele processa por unidade de tempo. Parecem duas formas de medir a mesma coisa — velocidade — e são exatamente o contrário: otimizar uma piora a outra. Em IA, a latência se divide em duas métricas que valem distinguir: o tempo até o primeiro token, que determina a sensação de rapidez para quem espera na tela, e a velocidade de geração em tokens por segundo, que determina quanto se espera pelo texto completo. Modelos de topo em 2026 vão de menos de 0,3 segundo até o primeiro token, nos mais enxutos, a mais de 1.400 tokens por segundo de geração, nos otimizados para volume. São perfis diferentes para problemas diferentes — e contratar infraestrutura otimizada para a métrica errada é caro nos dois sentidos.
⚠️ Por que as duas métricas brigam
A tensão é estrutural, não é defeito de implementação. Processar requisições em lote aproveita melhor a placa de vídeo e eleva o throughput — mas cada requisição individual espera o lote se formar, e a latência piora.
A literatura técnica descreve o mecanismo: a fase que lê o prompt tem latência alta e ocupa bem a GPU, enquanto a fase que gera a resposta token a token tem latência baixa e ocupa mal. Agrupar requisições intercala as duas fases, e é isso que torna difícil obter throughput alto e latência baixa ao mesmo tempo.
Sistemas que atacam essa tensão relatam ganhos expressivos sob restrição de latência — de 2,6 a 5,6 vezes mais throughput conforme o modelo e o hardware. O que confirma o ponto: não é que a tensão não tenha solução, é que ela precisa ser um objetivo explícito de projeto. Quem não decide, herda o padrão do fornecedor.
Cuidado com os números que circulam
Uma nota de método, porque este é um assunto especialmente contaminado. Ao procurar medições de latência de 2026, o que aparece em volume são blogs sem metodologia publicada, com números específicos e nenhuma descrição de como foram obtidos. Não os usamos.
Duas ressalvas sobre os números que usamos: eles vêm de um serviço de medição independente, mas comercial; e as duas métricas não estavam disponíveis para os mesmos modelos no momento da consulta — por isso apresentamos faixas, e não uma tabela comparando modelo a modelo. Valores de desempenho mudam sem aviso: consulte na data da sua decisão.
O que isso muda na prática
A pergunta certa não é “qual modelo é mais rápido”, e sim qual das duas métricas o seu caso exige. Elas correspondem a tipos de aplicação bem distintos:
| Caso de uso | Métrica que manda | Por quê |
|---|---|---|
| Chatbot no site, assistente ao vivo | Latência | O usuário está esperando; o tempo até o primeiro token domina a percepção |
| Enriquecimento noturno de base, classificação em massa | Throughput | Ninguém espera; o custo por mil registros é que decide |
| Geração de conteúdo com revisão humana | Equilíbrio | Nem instantâneo, nem em lote — o gargalo é a revisão |
O erro caro é contratar infraestrutura otimizada para a métrica errada: pagar por throughput altíssimo num chatbot em que o usuário desiste antes da resposta, ou por latência mínima num processamento em lote que roda de madrugada.
Duas orientações que valem para qualquer caso:
- Meça em português e com o seu prompt real. Prompt de sistema longo entra em toda chamada e afeta o tempo até o primeiro token. E o português consome de 25% a 40% mais tokens, o que alonga a geração.
- Em agente, multiplique. Um agente com oito chamadas encadeadas acumula oito latências — a experiência do usuário é a soma, não a média.
O custo por trás dessas escolhas está em inferência e em GPU e TPU.
Fontes
- Taming Throughput-Latency Tradeoff in LLM Inference — documenta a tensão entre as duas métricas
- Medições de latência e velocidade por modelo — serviço comercial independente; consultar na data da decisão
Leitura das fontes em 17/08/2026.