Latência em LLMs: Como Definir Orçamentos para Aplicações Interativas

Você já tentou conversar com um chatbot que demora tanto para responder que você esquece o que perguntou? Ou pior, a resposta chega tão devagar que parece que a IA está "pensando" demais enquanto você espera? Essa sensação de lentidão não é apenas irritante; ela mata a usabilidade. Para aplicações interativas baseadas em Grandes Modelos de Linguagem (LLMs), definir um orçamento de latência claro não é um luxo técnico, é uma necessidade de sobrevivência do produto.

Mas o que exatamente significa "orçamento de latência" nesse contexto? Não se trata apenas de fazer tudo rápido. Trata-se de equilibrar a velocidade de resposta com a qualidade da saída e o custo da infraestrutura. Se você quer que sua aplicação sinta-se humana e reativa, precisa entender como os modelos geram texto, onde estão os gargalos e quais alavancas você pode puxar para manter a experiência fluida. Vamos descomplicar isso, olhando para as métricas reais que importam em 2026.

A Anatomia da Latência: Prefill vs. Decode

Para controlar a latência, primeiro você precisa saber onde ela acontece. A inferência de um LLM ocorre em duas fases distintas, e cada uma tem suas próprias regras físicas.

A primeira fase é o Prefill. Aqui, o modelo lê todo o seu prompt (entrada) e constrói uma cache interna chamada Key-Value (KV). Essa etapa é intensiva em computação e altamente paralelizável. Pense nisso como ler um livro inteiro antes de começar a escrever um resumo. Se o seu prompt for longo - digamos, 10.000 tokens de contexto recuperado via RAG - essa fase domina o tempo total. Não há como "batchear" (agrupar) essa parte sem aumentar a latência na cauda para usuários individuais.

A segunda fase é o Decode. O modelo gera o texto token por token, sequencialmente. Cada nova palavra depende das anteriores. Diferente do prefill, o decode é limitado pela largura de banda da memória, não pela potência bruta de cálculo. É aqui que a maioria dos gargalos invisíveis mora. Quanto maior o modelo ou mais complexo o raciocínio, mais lenta tende a ser essa fase de geração.

As Duas Métricas Que Definem a Experiência

Engenheiros costumam olhar para o tempo total de resposta, mas para o usuário final, isso é enganoso. Existem duas métricas críticas que você deve monitorar separadamente:

• Time to First Token (TTFT): O tempo desde que o usuário envia a pergunta até a primeira letra aparecer na tela. Esta é a métrica de "responsividade". Se o TTFT for alto, o usuário acha que o sistema travou.
• Tokens por Segundo (TPS): A velocidade com que o restante da resposta aparece após o primeiro token. Isso define a fluidez da leitura.

Um erro comum é otimizar apenas o TPS. Você pode ter um modelo voando a 50 tokens por segundo, mas se ele demorar 3 segundos para cuspir a primeira palavra, a experiência será ruim. Em aplicações interativas, o TTFT é frequentemente mais crítico para a percepção de qualidade do que a velocidade total de conclusão. O cérebro humano interpreta feedback imediato como sinal de eficiência, mesmo que a tarefa completa leve alguns segundos a mais.

O Dilema do Batching: Velocidade vs. Custo

Para reduzir custos, a indústria adota o batching: processar várias requisições simultaneamente na mesma GPU. Soa ótimo, certo? Mais requisições por dólar. Mas existe um preço oculto: a latência individual aumenta.

Imagine uma fila de banco. Se você atende clientes um por um, o primeiro sai rápido, mas a fila anda devagar. Se você agrupa 8 clientes para processar juntos, a eficiência geral sobe, mas cada cliente individual espera mais tempo para ser atendido completamente. Dados recentes mostram que para modelos como o Qwen 2.5 7B, o aumento do batch size pode reduzir a latência agregada, mas aumenta significativamente o tempo de espera para requisições específicas na cauda da distribuição.

Além disso, os ganhos de throughput têm retornos decrescentes. Dobrar o tamanho do batch de 1 para 2 quase dobra a eficiência. Mas ir de 16 para 32 traz ganhos marginais porque a memória fica saturada. Para aplicações interativas, onde a previsibilidade importa, batches muito grandes podem quebrar seu orçamento de latência durante picos de tráfego.

Estratégias Avançadas para Reduzir Latência

Se ajustar o batch size não basta, você precisa de técnicas mais cirúrgicas. Aqui estão três abordagens comprovadas para 2026:

Decodificação Especulativa (Speculative Decoding)

Esta técnica troca poder computacional por latência. Um modelo pequeno e rápido (o "speculator") prevê vários tokens à frente. O modelo grande e preciso só verifica essas previsões. Se estiverem corretas, você pula etapas caras. Implementações documentadas mostram reduções de latência entre 2x e 4x. É ideal para cargas de trabalho longas onde você tem orçamento de hardware extra.

Quantização Inteligente

Usar pesos de menor precisão (como MXFP4 ou INT8) reduz o uso de memória e acelera o acesso aos dados. Modelos como o GPT OSS 20B conseguem rodar em GPUs menores com quantização agressiva, mantendo uma qualidade aceitável para muitas tarefas. O trade-off? Uma pequena perda de acurácia em tarefas de raciocínio complexo.

Caching Estratégico

Em sistemas RAG (Retrieval-Augmented Generation), muitos prompts são semelhantes. Armazenar respostas frequentes ou partes intermediárias do cálculo evita recalcular o prefill repetidamente. Isso é vital quando seus prompts têm milhares de tokens de contexto.

Escolhendo o Modelo Certo para Seu Orçamento

Não existe "melhor modelo", existe o melhor modelo para o seu orçamento de latência e custo. Um modelo de 109 bilhões de parâmetros pode exigir três GPUs H100 para rodar confortavelmente, enquanto um modelo de 8 bilhões cabe em uma única placa. A diferença de custo mensal pode ser brutal - estamos falando de dezenas de milhares de dólares para startups que escalaram rápido.

Modelos menores (como variações mini) podem ser 5x a 10x mais rápidos que seus irmãos maiores. Pergunte-se: a qualidade extra vale a latência adicional? Para um chatbot de suporte ao cliente, talvez não. Para um assistente jurídico que precisa citar jurisprudências exatas, sim.

Checklist para Definir Seu Orçamento de Latência

Antes de lançar sua aplicação, valide estes pontos:

1. Defina o TTFT máximo aceitável: Geralmente abaixo de 1-2 segundos para conversas casuais.
2. Estime o comprimento médio do output: Latência é proporcional ao número de tokens gerados, não lidos.
3. Simule carga concorrente: Teste o comportamento do sistema com 10x o volume esperado de usuários simultâneos.
4. Monitore a cauda da latência: Não olhe apenas a média. O 95º percentil (P95) é o que afeta a experiência do usuário insatisfeito.
5. Considere o custo de falha: Se uma resposta errada custa caro, priorize modelos maiores e aceitem latências maiores.