O teste deve representar concorrência, tamanho e variabilidade dos prompts, tempo de resposta do modelo, chamadas de recuperação de contexto, integrações externas, consumo de tokens, limites de taxa do provedor e comportamento de fallback. Também é importante separar latência do modelo, latência de rede e tempo de processamento da própria aplicação — porque, sem essa separação, um teste de carga tradicional relata uma "latência média" que não diz onde está o problema nem como a experiência realmente se comporta em streaming.

O que torna esse cenário diferente de um teste de carga tradicional?

Ao contrário de uma API transacional convencional, agentes de IA generativa têm variabilidade intrínseca: dois prompts praticamente idênticos podem gerar tempos de resposta muito diferentes, dependendo do tamanho do contexto, da complexidade da resposta e da carga momentânea do provedor. Isso exige métricas de percentil (p95, p99) em vez de apenas médias, e cenários de teste que cubram prompts curtos e longos, respostas simples e complexas, e sessões de conversa com múltiplos turnos.

Ferramentas de carga tradicionais também tratam cada requisição como uma unidade fechada, registrando o tempo total de resposta. Isso mede o tempo total de geração, mas esconde a experiência real de streaming: um assistente pode ter tempo total aceitável e ainda assim parecer travado, porque o primeiro token demorou para aparecer ou porque os tokens seguintes chegaram de forma irregular.

As métricas que realmente importam

Um teste de performance para chatbots e agentes de IA generativa deve reportar, no mínimo, os seguintes indicadores — de preferência em percentis, não apenas em média:

  • TTFT (Time to First Token): tempo entre o envio da requisição e a chegada do primeiro token de resposta. É o indicador mais próximo da percepção de "o assistente está respondendo" e é sensível a filas, tamanho do prompt de entrada e contenção de recursos no servidor de inferência.
  • TPOT / Inter-Token Latency (ITL): tempo médio entre tokens após o primeiro. Determina se a resposta é lida em um ritmo fluido ou "engasga" durante o streaming. Um TPOT de 100ms por token equivale a cerca de 10 tokens por segundo — próximo do limite de leitura humana.
  • Latência ponta a ponta (E2E): soma do TTFT com o tempo total de geração. É o que efetivamente fecha a experiência do usuário, mas isoladamente não revela se o gargalo está no início ou na geração.
  • Throughput em tokens por segundo: substitui o tradicional "requisições por segundo" como unidade de capacidade, já que o custo computacional de uma requisição varia com o tamanho da entrada e da saída.
  • Taxa de erro e de throttling: proporção de respostas com erro, timeout ou limitação por rate limit sob cada nível de concorrência testado.

Uma boa prática adicional é aquecer o sistema antes de medir (warm-up), simular a chegada de requisições com um padrão realista (por exemplo, um processo de Poisson) em vez de picos artificiais sincronizados, e definir SLOs explícitos combinando os dois eixos — por exemplo, TTFT abaixo de um limite e latência total abaixo de outro — para calcular o "goodput": a fração de requisições que atende simultaneamente a ambos os critérios, não apenas o throughput bruto.

Modelando a carga: concorrência, variabilidade e padrão de chegada

Diferente de uma jornada de e-commerce, onde a variação entre usuários é relativamente previsível, um agente de IA generativa recebe prompts de tamanho, complexidade e intenção muito diferentes entre si. O plano de teste deve amostrar essa variabilidade de forma representativa: prompts curtos e diretos, prompts longos com bastante contexto, perguntas que disparam múltiplas chamadas de ferramentas (tool calls) e sessões de conversa que acumulam histórico ao longo de vários turnos — já que o contexto acumulado consome mais tokens e tende a aumentar a latência a cada novo turno.

A concorrência também deve refletir o padrão real de chegada de usuários, não apenas um número fixo de "usuários virtuais" martelando requisições sem pausa. Um padrão de chegada muito artificial mascara o comportamento de filas e de enfileiramento que aparece em produção sob uso orgânico.

RAG e dependências externas: onde a latência costuma se esconder

Quando o assistente usa RAG (Retrieval-Augmented Generation), a jornada completa inclui uma etapa de busca em um banco vetorial antes mesmo de a geração começar. Essa etapa tem seu próprio perfil de latência sob concorrência — bancos vetoriais em memória tendem a manter latência de cauda baixa mesmo sob carga, enquanto arquiteturas baseadas em disco ou com filtros de metadados complexos podem degradar significativamente conforme a concorrência de consultas aumenta.

No lado do modelo, a pressão sobre o KV cache (o buffer de memória da GPU que armazena o estado de atenção da conversa) cresce com o tamanho do contexto e com o número de requisições simultâneas. Quando esse cache satura, novas requisições ficam na fila em vez de serem processadas imediatamente — e esse é um dos motivos mais comuns de TTFT alto sob concorrência, mesmo quando a CPU e a rede parecem com folga.

Por isso, o teste deve instrumentar e medir separadamente: tempo de recuperação (retrieval), tempo de fila no servidor de inferência, tempo de geração do modelo e tempo de processamento da própria aplicação. Sem essa quebra, um agente de IA lento é indistinguível de uma dependência de terceiros lenta.

Rate limits dos provedores: o teto que você não controla

Provedores de LLM aplicam limites por minuto em múltiplas dimensões simultaneamente — normalmente requisições por minuto (RPM), tokens de entrada por minuto (ITPM) e tokens de saída por minuto (OTPM), com o limite de tokens costumando ser o gargalo real em produção, não o número de requisições. Ao ultrapassar qualquer um desses limites, a API retorna um erro 429 acompanhado de um cabeçalho indicando quanto tempo aguardar antes de tentar novamente.

Isso muda o que "carga máxima" significa: o teto pode estar no provedor, não na sua aplicação. O plano de teste deve incluir um cenário específico de esgotamento de rate limit — validando se a aplicação trata o erro com retentativa controlada (backoff) e fila, ou se simplesmente propaga a falha para o usuário final. Vale também medir o impacto de rate limiting na experiência: uma fila bem implementada pode absorver picos curtos sem que o usuário perceba nada além de uma resposta um pouco mais lenta.

Ferramentas para rodar esse teste

Ferramentas de carga tradicionais continuam úteis, mas raramente têm entendimento nativo de streaming ou das métricas específicas de LLM — por isso a instrumentação de TTFT e inter-token latency geralmente precisa ser construída por cima delas:

  • k6: forte para infraestrutura HTTP/SSE e integração em pipelines de CI/CD, com suporte a thresholds de aprovação/reprovação, mas exige scripts próprios para capturar métricas de streaming token a token.
  • Locust: por ser Python puro, costuma ser a escolha mais direta quando é preciso lógica customizada na requisição — parsing de resposta em streaming, chamadas de pré-autenticação, ou geração dinâmica de prompts a partir de um dataset.
  • NVIDIA AIPerf (sucessor do GenAI-Perf): ferramenta de linha de comando especializada em benchmarking de servidores de inferência, com métricas nativas de TTFT, inter-token latency e throughput de tokens, e suporte a padrões de chegada como Poisson e distribuições com rajadas (burstiness).
  • LLMPerf e ferramentas equivalentes: alternativas específicas para LLM quando o objetivo é comparar backends de inferência (vLLM, TensorRT-LLM) de forma padronizada.

A escolha depende menos de qual ferramenta é "melhor" e mais de qual perfil de teste você precisa: infraestrutura de carga genérica com scripts customizados, ou benchmarking especializado do próprio servidor de inferência.

Observabilidade: separando latência do modelo, da rede e da aplicação

Para investigar com precisão, é necessário correlacionar cada requisição de ponta a ponta — do clique do usuário até o último token gerado — passando pela aplicação, pela busca de contexto e pela chamada ao modelo. A convenção semântica de GenAI da OpenTelemetry padroniza como esses eventos são registrados (atributos como o modelo solicitado, o modelo efetivamente usado e o consumo de tokens de entrada e saída), permitindo que diferentes frameworks e SDKs alimentem o mesmo painel de observabilidade em vez de cada integração inventar seu próprio formato de log.

Isso importa especialmente para agentes com múltiplas etapas (chamadas de ferramentas, múltiplas idas ao modelo, recuperação de contexto): sem rastreamento estruturado, uma resposta lenta de 45 segundos é uma caixa-preta — pode ser o modelo, uma chamada de ferramenta específica, um retry silencioso ou a etapa de busca. Com instrumentação adequada, essa árvore de chamadas fica visível e o componente responsável pela lentidão é identificado diretamente.

O que avaliar além da latência

Avalie filas, timeouts, circuit breakers e fallbacks. Meça o impacto de rate limits do provedor na experiência do usuário. Teste explicitamente o comportamento quando o modelo retorna erro, quando demora acima do threshold aceitável, e quando o fallback (um modelo menor, uma resposta em cache, ou uma mensagem de indisponibilidade controlada) também precisa entrar em ação — porque um fallback que nunca foi testado sob carga real tem boas chances de falhar exatamente no momento em que é mais necessário.

Como a FATTO aborda esse escopo

Como agentes de IA generativa têm dependências variáveis e podem envolver APIs de terceiros, esse escopo exige planejamento específico, regras de segurança e autorização dos provedores. No playbook da FATTO, testes de chatbots, RAG e agentes de IA são enquadrados no pacote Custom, a partir de R$ 85.000, conforme a complexidade.

Próximo passo: defina os SLAs de latência (incluindo TTFT e inter-token latency, não apenas o tempo total) para seu assistente de IA e valide-os sob concorrência representativa em um ambiente controlado.

Referências