Latência de LLM em produção: onde medir e como otimizar

Latência de LLM em produção raramente está onde você imagina. A maioria dos times que me pede ajuda para "deixar o modelo mais rápido" descobre, depois de instrumentar o pipeline, que o modelo responde em 1.2 segundos e o pipeline inteiro leva 6. O gargalo está em outro lugar.

Então antes de qualquer conversa sobre otimização, a pergunta que faço é sempre a mesma: o que exatamente você está medindo? A resposta para isso muda tudo o que vem depois.

O que é latência de LLM (e por que tem mais de uma)

Quando alguém diz "meu LLM está lento", pode estar falando de coisas bem diferentes. Existem pelo menos três métricas distintas que importam dependendo do contexto:

• TTFT (time to first token): tempo até a primeira palavra aparecer. É a métrica que mais impacta a percepção de velocidade em interfaces interativas.
• Latência de geração: quantos tokens por segundo o modelo produz depois que começa. Determina quanto tempo leva para a resposta completa chegar.
• Latência fim a fim (E2E): o tempo total desde a requisição do usuário até a resposta processada e entregue. Inclui retrieval, chamada ao modelo, pós-processamento, guardrails e serialização.

Pipeline que monitora só o tempo de resposta da API do modelo está vendo, no melhor dos casos, 40% do problema.

Os componentes reais de um pipeline de LLM

Um pipeline de LLM em produção tem mais peças do que aparece no demo. Cada etapa tem sua fatia de latência:

• Construção do prompt: busca em banco de dados, recuperação de histórico de conversa, formatação
• Retrieval (se houver RAG): embedding da query, busca vetorial, reranking, injeção dos chunks no contexto
• Chamada à API do modelo: tempo de fila, TTFT e geração
• Pós-processamento: parse da saída, validação de formato, extração de campos
• Guardrails e filtros: classificadores de conteúdo, validações de segurança em tempo real

A chamada à API aparece como um bloco único nos logs. Mas a latência E2E é a soma de tudo isso. Os sistemas que vejo chegam a 60-70% do tempo gasto fora do modelo.

Como medir latência de LLM em produção antes de otimizar qualquer coisa

Você não precisa de uma ferramenta sofisticada para começar. O que precisa é de timestamps consistentes em cada etapa do pipeline.

Se você estiver usando IA para ajudar no desenvolvimento, o pedido é direto: peça para a IA instrumentar cada etapa com registro de tempo de entrada e saída, incluindo o identificador da requisição, o nome do componente e a duração em milissegundos. Com isso em mão, você já consegue montar uma tabela básica de onde o tempo vai.

O que você quer responder com esses dados:

• Qual componente tem a maior mediana de duração?
• Qual componente tem o maior P99 (o pior caso dos 1% mais lentos)?
• Existe correlação entre tamanho do contexto enviado e latência de geração?

Ferramentas como Langfuse, que a gente já cobriu aqui com instruções para rastreamento de LLMs com Docker, fazem esse rastreamento por etapa de forma visual. Mas mesmo um CSV com timestamps já te dá o suficiente para saber onde agir.

Onde o gargalo real costuma estar

Spoiler: quase nunca é só o modelo.

Na minha experiência, a distribuição mais comum em pipelines RAG fica assim: embedding e busca vetorial respondem por 20-30% do tempo total, a chamada ao modelo por 40-50%, e pós-processamento (incluindo parse e guardrails) pelos 20-30% restantes.

Essa distribuição muda completamente dependendo do caso:

• Pipeline com reranking: retrieval pode passar de 50% do tempo total se o índice não estiver otimizado.
• Pipeline com guardrails em cascata: classificadores rodando em sequência adicionam 1-2 segundos com facilidade.
• Pipeline com saídas estruturadas e validação: o loop de retry por parsing inválido vira um custo oculto que ninguém monitorou.

O artigo sobre guardrails para LLMs em tempo real entra bem nos trade-offs de colocar filtros no caminho crítico da requisição. Vale ler antes de decidir quantos guardrails empilhar.

As variáveis que mais movem a agulha na latência de LLM

Depois de medir, você tem três alavancas principais.

Tamanho do contexto

É a variável mais subestimada. TTFT tem correlação direta com o número de tokens no prompt. Dobrar o contexto não dobra o tempo de geração, mas aumenta significativamente o tempo de processamento do input. Antes de trocar de modelo, verifique se você está mandando o contexto mínimo necessário. O artigo sobre janela de contexto trata exatamente disso: como decidir o que entra e o que fica de fora.

Escolha e roteamento do modelo

Modelos menores têm TTFT e geração mais rápidos, mas isso não significa usar o menor para tudo. A questão correta é: para quais requisições a qualidade do modelo menor é suficiente? Para as outras, você pode aceitar mais latência ou pré-computar offline.

Roteamento de LLMs é uma leitura direta se você está considerando estratificar requisições por complexidade para ganhar velocidade sem abrir mão de qualidade nos casos que importam.

Streaming

Se a interface suporta streaming, ativá-lo muda a percepção de velocidade sem alterar nada no pipeline. TTFT de 800ms com streaming parece muito mais rápido do que 5 segundos esperando a resposta completa chegar. Não é otimização do pipeline, mas é uma das maiores alavancas de experiência disponíveis sem custo extra.

Quando latência de LLM realmente importa para o negócio

Nem todo caso de uso tem o mesmo requisito. Antes de investir em otimização, vale calibrar o contexto:

• Interface conversacional em tempo real: P50 abaixo de 2 segundos é o mínimo aceitável. P99 acima de 8 segundos começa a quebrar a experiência.
• Processamento em batch: latência por request importa pouco. Throughput total é o que vale monitorar.
• API interna consumida por outro serviço: depende do SLA do consumidor. Às vezes 10 segundos é aceitável se a chamada for assíncrona.
• Agente com múltiplas chamadas em sequência: latência por step multiplica pelo número de steps. Um agente com 8 chamadas de 3 segundos cada vira 24 segundos de wall clock.

Esse último caso é onde a latência acumula de forma não-óbvia. Você pode estar dentro do SLA por chamada e totalmente fora do SLA de experiência. Benchmarks externos como os do Artificial Analysis comparam TTFT e throughput entre provedores em condições padronizadas. Útil como referência, mas não substitui medir no seu pipeline com os seus dados reais.

O custo de otimizar no lugar errado

Acontece assim: o time percebe que a resposta está lenta, alguém sugere trocar o modelo por um "mais rápido", faz a troca, a latência melhora 15% e o problema principal continua intocado. Porque o problema principal era o retrieval fazendo quatro chamadas serializadas para um banco vetorial sem índice.

Otimização sem medição é caro e lento. Não porque a tentativa seja inútil, mas porque você pode gastar semanas no lugar errado enquanto o gargalo real continua ativo.

A estrutura que funciona: medir cada etapa, identificar o componente com maior impacto, otimizar aquele componente, medir de novo. Esse loop tem que ser curto.

FAQ

Qual a diferença entre P50 e P99 e qual devo monitorar?

P50 é a mediana: metade das requisições ficam abaixo desse valor. P99 é o pior caso dos 99% mais rápidos. Em produção, monitore os dois. P50 alto indica problema sistêmico. P99 alto indica problema em casos específicos que aparecem pouco, mas causam timeout e frustração nos momentos mais visíveis.

Streaming sempre melhora a experiência do usuário?

Para interfaces com humano na ponta, sim, quase sempre. Para pipelines que precisam da resposta completa antes de continuar (agentes, pós-processamento, validação de formato), streaming não ajuda e pode complicar a lógica de tratamento. Ative onde o usuário final está esperando. No restante do pipeline, a resposta completa costuma ser mais simples de lidar.

Vale trocar de provedor de LLM para reduzir latência de LLM?

Depende de quanto da sua latência E2E é a chamada ao modelo. Se for menos de 40%, trocar de provedor vai mover pouco. Se for mais de 60%, faz sentido comparar. Use benchmarks externos como referência inicial, mas teste com os seus padrões reais de request (tamanho de contexto, frequência de chamadas) antes de qualquer decisão.

O tamanho do prompt sempre afeta o TTFT?

Sim, e de forma não-linear. Prompts maiores exigem mais processamento de input antes de o modelo começar a gerar. O efeito é mais pronunciado em modelos com arquiteturas de atenção mais pesadas. Na prática, reduzir o contexto de 8k para 4k tokens pode cortar o TTFT em 30-50%, dependendo do modelo e do provedor.

Conclusão: medir antes de otimizar

Latência de LLM em produção é um problema de medição antes de ser um problema de otimização. Você não consegue otimizar o que não instrumentou. E instrumentar só a chamada ao modelo é suficiente para demos, não para sistemas reais.

Instrumenta todas as etapas, olha para P50 e P99, identifica onde o tempo vai e, depois disso, decide onde agir. Essa sequência parece óbvia escrita assim, mas a maioria dos times pula direto para a solução.

Próximos passos:

• Adicione registro de tempo em cada etapa do seu pipeline e calcule a distribuição por componente
• Compare P50 e P99 para identificar onde a variância é maior: variância alta indica problema intermitente, não sistêmico
• Se ainda não tem rastreamento visual, comece pelo Langfuse self-hosted com Docker para ganhar visibilidade por etapa sem depender de serviço externo
• Depois de ter os números, questione se o problema é latência real ou perceptual: às vezes habilitar streaming resolve mais do que qualquer otimização de pipeline