Latência e throughput: otimizar uma piora a outra

**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](https://clubmartech.com.br/blog/ia-marketing-vendas-inteligentes/), 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](https://clubmartech.com.br/blog/infraestrutura-[dados](https://clubmartech.com.br/blog/dados-transformar-volume-acionavel/)-ia-meses/) otimizada para a métrica errada é caro nos dois sentidos.## ⚠️ Por que as duas métricas brigamA 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 circulamUma 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](https://clubmartech.com.br/blog/sem-avancado-estrategia-roi/) 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áticaA 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:

O erro caro é contratar [infraestrutura](https://clubmartech.com.br/blog/infraestrutura-[dados](https://clubmartech.com.br/blog/dados-transformar-volume-acionavel/)-ia-meses/) 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](https://clubmartech.com.br/significado/experiencia-usuario/) é a soma, não a média.

O custo por trás dessas escolhas está em

e em

.## 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.*