Testes de carga em sistema com LLM: simular o provedor sem pagar por ele

O primeiro problema de rodar teste de carga contra a API real não é o custo, é a atribuição. Quando você dispara mil requisições por minuto e observa a latência subir, existem pelo menos três explicações possíveis e o teste não separa nenhuma delas: o seu sistema está saturado, a sua cota no provedor está estourando, ou o provedor está com um dia ruim para todo mundo. As três produzem o mesmo gráfico. Como você não controla duas dessas variáveis e nem consegue observá-las direito, o resultado é um teste que não é reproduzível: rodar de novo na terça dá um número diferente de rodar na quinta, e nenhuma das duas execuções diz se a mudança que você fez no código melhorou ou piorou alguma coisa.

O segundo problema é que o rate limit do provedor funciona como um teto artificial que esconde o comportamento que você queria observar. Se a sua cota é de trezentas requisições por minuto e você quer testar o sistema a mil, o provedor devolve erro de limite nas setecentas excedentes, e o teste passa a exercitar o seu caminho de tratamento de erro em vez do seu caminho de sucesso sob carga. É um teste válido, mas é outro teste. A pergunta original, se a aplicação aguenta mil requisições por minuto de trabalho real, continua sem resposta, e o único jeito honesto de respondê-la é remover o teto: substituir o provedor por algo que aceita a carga toda e devolve respostas com o mesmo formato e o mesmo perfil de tempo.

O dublê ingênuo devolve uma resposta fixa depois de esperar um tempo fixo, e é isso que transforma o teste de carga num teatro. A latência de um LLM não é uma constante, é uma distribuição de cauda longa: a maioria das respostas chega perto da mediana e uma fração pequena demora várias vezes mais. Essa cauda é o que faz o sistema quebrar. Com latência constante, a sua fila nunca acumula, porque cada worker libera no mesmo ritmo previsível; com latência de cauda longa, alguns workers ficam presos em respostas lentas enquanto a fila cresce atrás deles, e é exatamente aí que o pool esgota, o timeout dispara e o backpressure precisa entrar em ação. Um teste com latência constante passa com folga num sistema que vai cair na primeira sexta-feira movimentada.

A latência de um LLM também não é independente do pedido, e isso importa mais do que parece. O tempo até o primeiro token depende do tamanho do prompt, e o tempo total depende principalmente de quantos tokens a resposta tem, porque a geração é sequencial. Um dublê que ignora isso e sorteia um tempo aleatório qualquer perde a correlação que produz os piores casos reais: as requisições com mais contexto tendem a ser as que geram respostas mais longas, então o pico de carga tende a coincidir com o pico de duração, e não a se cancelar. Modelar tempo até o primeiro token em função do tamanho do prompt e depois um tempo por token na geração reproduz essa correlação sem nenhuma sofisticação estatística.

// test/fake-llm/latency.js
// A latencia de um LLM tem duas fases com causas diferentes:
// TTFT cresce com o prompt (prefill), e a geracao e sequencial
// por token. Modelar isso reproduz a correlacao que quebra o sistema.

export function sampleLatency(request, profile, rng) {
  const promptTokens = estimateTokens(request.messages);
  const outputTokens = sampleOutputTokens(profile.outputTokens, rng);

  // Prefill: cresce com o tamanho do prompt, com um piso de rede.
  const ttft =
    profile.networkFloorMs +
    profile.prefillMsPerKToken * (promptTokens / 1000) +
    lognormalJitter(profile.ttftJitter, rng);

  // Geracao: sequencial, entao o total cresce com os tokens de saida.
  const perToken = profile.msPerOutputToken * lognormal(profile.tokenJitter, rng);

  // A cauda longa e o que quebra o sistema. Sem ela o teste passa
  // com folga e a producao cai na primeira sexta movimentada.
  const isSlowTail = rng() < profile.slowTailRate;
  const tailFactor = isSlowTail ? profile.slowTailFactor : 1;

  return {
    ttftMs: ttft * tailFactor,
    totalMs: (ttft + perToken * outputTokens) * tailFactor,
    outputTokens,
  };
}

De onde tirar os números do perfil é a parte que costuma travar o time, e a resposta é mais simples do que parece: da produção, se você já tem tráfego, ou de uma amostra pequena e barata contra a API real, se ainda não tem. Bastam algumas centenas de chamadas com prompts representativos para estimar o piso de rede, o custo por mil tokens de prompt, o tempo por token de saída e a fração de respostas na cauda. Isso custa alguns centavos e vale para milhões de requisições simuladas. O perfil deve ser um arquivo versionado no repositório, com data de coleta, porque ele envelhece: o provedor muda de infraestrutura, você troca de modelo, e um perfil de seis meses atrás descreve um sistema que não existe mais.

Um dublê que só responde com sucesso testa metade do sistema. Sob carga, o provedor real erra de maneiras específicas, e cada uma delas exercita um caminho diferente do seu código: o erro de limite de taxa, que vem com uma indicação de quanto esperar e deveria alimentar o seu backoff; o erro transitório de servidor, que justifica retentativa; o erro de contexto excedido, que nunca deve ser retentado porque vai falhar igual; e o pior de todos, a resposta que começa a transmitir e morre no meio, deixando o seu cliente com um texto truncado e uma conexão pendurada. Se o dublê não produz esses casos, o teste de carga mede o desempenho de um sistema que só existe em condições ideais.

A injeção de falha precisa ser determinística para o teste servir de comparação entre execuções. Falha aleatória com semente fixa dá as duas coisas ao mesmo tempo: a distribuição parece realista e a sequência é idêntica em toda execução, então quando você muda o código e o resultado muda, a diferença é sua e não do acaso. Vale expor a semente e a taxa de cada tipo de falha como configuração do cenário, porque assim o mesmo dublê serve para o teste de carga em regime normal, para o teste de resiliência com quinze por cento de erro e para o exercício de modo degradado com o provedor totalmente fora.

Se a sua aplicação usa streaming, o dublê que devolve a resposta inteira de uma vez apaga a característica mais importante do sistema sob carga: a conexão fica aberta durante toda a geração. Numa API tradicional, a requisição ocupa um slot por alguns milissegundos; com streaming, ela ocupa por vários segundos, e o número de conexões simultâneas passa a ser o recurso escasso em vez da taxa de requisições. Um sistema que aguenta mil requisições por minuto sem streaming pode esgotar file descriptors muito antes disso com streaming, e o dublê precisa emitir os eventos ao longo do tempo, no ritmo de tokens do perfil, para que esse custo apareça no teste.

// test/fake-llm/stream.js
// O dublê emite eventos ao longo do tempo, no ritmo de tokens do
// perfil. Sem isso, a conexao nao fica aberta e o teste nao mede
// o recurso que realmente escasseia com streaming: conexao simultanea.

export async function streamResponse(res, request, profile, rng) {
  const { ttftMs, totalMs, outputTokens } = sampleLatency(request, profile, rng);
  const perTokenMs = (totalMs - ttftMs) / Math.max(outputTokens, 1);

  res.writeHead(200, {
    'Content-Type': 'text/event-stream',
    'Cache-Control': 'no-cache',
    Connection: 'keep-alive',
  });

  await sleep(ttftMs);

  // Falha no meio do stream: o caso que o dublê ingenuo nunca produz
  // e que deixa conexao pendurada e resposta truncada em producao.
  const dropAt = rng() < profile.midStreamDropRate
    ? Math.floor(rng() * outputTokens)
    : -1;

  for (let i = 0; i < outputTokens; i += 1) {
    if (i === dropAt) {
      res.destroy(); // encerra sem evento de fim, de proposito
      return { outcome: 'mid_stream_drop', tokensSent: i };
    }

    res.write(`data: ${JSON.stringify({ delta: nextToken(rng) })}\n\n`);
    await sleep(perTokenMs);
  }

  res.write('data: [DONE]\n\n');
  res.end();
  return { outcome: 'complete', tokensSent: outputTokens };
}

Onde inserir o dublê também é uma decisão de fidelidade. Substituir o cliente do provedor por um objeto falso dentro do processo é o mais fácil e o menos fiel, porque remove serialização, rede, pool de conexões e o próprio custo de manter a conexão aberta, que é justamente o que você quer medir. Subir o dublê como um servidor de verdade e apontar a variável de ambiente da URL base para ele mantém todo o caminho intacto e troca apenas quem responde do outro lado. O segundo custa alguns minutos a mais de infraestrutura de teste e é o único que responde a pergunta que motivou o teste.

Com o provedor substituído, as métricas que importam deixam de ser as dele e passam a ser as suas. A latência da chamada ao dublê é conhecida por construção, você mesmo a definiu, então medi-la não informa nada. O que informa é o que acontece entre a borda da sua aplicação e essa chamada: quanto tempo a requisição passou na fila antes de virar chamada, quantos workers estavam ocupados, quantas conexões simultâneas o processo sustentou, quanta memória a fila consumiu no pico e quantas requisições foram recusadas na entrada porque o sistema aplicou o freio. É essa a diferença entre um teste de carga que produz um número e um que produz uma decisão.

1. Tempo de espera na fila separado do tempo de chamada, porque a soma esconde qual dos dois está estourando o orçamento de tempo do cliente.
2. Profundidade máxima da fila e memória no pico, que dizem quanto tempo o sistema aguenta um pico antes de estourar em vez de degradar.
3. Conexões simultâneas sustentadas, que com streaming costumam esgotar antes da CPU e antes da taxa de requisições.
4. Taxa de recusa na borda e o código devolvido, para confirmar que o freio está atuando na entrada e não deixando a fila crescer sem limite.
5. Latência no percentil alto ponta a ponta, não a média, porque a média some com a cauda que é exatamente o que quebra a experiência.
6. Trabalho cancelado corretamente quando o cliente desiste, medido como chamadas abortadas sobre desistências, que deveria ser praticamente um.

Teste de carga com dublê de provedor: onde medir

  gerador de carga (perfil de trafego real, nao rajada uniforme)
     |
     v
  [ borda da aplicacao ] <-- MEDIR: taxa de recusa, codigo devolvido
     |
     v
  [ fila ] <----------------- MEDIR: tempo de espera, profundidade, memoria
     |
     v
  [ pool de workers ] <------ MEDIR: ocupacao, conexoes simultaneas
     |
     v
  ================= FRONTEIRA =================
     |
     v
  [ dublê do provedor ]   <-- NAO medir: a latencia daqui voce definiu
     |
     +-- TTFT em funcao do tamanho do prompt
     +-- tempo por token na geracao (streaming real, evento a evento)
     +-- cauda longa com fracao configurada
     +-- falhas deterministicas por semente:
           limite de taxa / transitorio / contexto excedido
           stream que morre no meio / provedor fora / provedor lento

  Resultado util: "a fila estoura em X req/min com Y de memoria"
  Resultado inutil: "a latencia media foi Z" (voce mesmo escolheu Z)

O gerador de carga também merece cuidado, porque a rajada uniforme é irreal e otimista. Tráfego de atendimento chega em ondas, com correlação entre chegadas, e o mesmo volume total distribuído em ondas produz picos de fila que a distribuição uniforme nunca alcança. Vale ainda modelar o comportamento do cliente que desiste: uma fração das conversas é abandonada antes da resposta chegar, e se o seu sistema não cancela o trabalho correspondente, ele continua queimando worker e token para ninguém, o que sob carga é uma forma silenciosa de amplificar a sobrecarga.

O dublê responde perguntas sobre o seu sistema e não responde nenhuma pergunta sobre o provedor. Se o que você precisa saber é qual a cota real da sua conta, como o provedor se comporta quando você passa dela, se a latência dele piora nos horários de pico globais ou se o modelo novo é mais lento que o antigo, nenhuma simulação substitui uma medição contra a API real. A diferença é que essas perguntas se respondem com um teste pequeno e barato, de algumas centenas de chamadas, e não com um teste de carga de dez mil. A divisão saudável é usar a API real para calibrar o perfil e validar suposições, e usar o dublê para tudo que envolve volume.

Também vale ter uma execução periódica de fumaça contra a API real, pequena e barata, com dois objetivos. O primeiro é detectar deriva do perfil: se a latência medida na amostra afastou do que o dublê simula, o seu teste de carga está descrevendo um provedor que não existe mais e precisa ser recalibrado. O segundo é pegar mudança de contrato, porque o dublê responde no formato que você programou nele, e se o provedor mudar um campo ou a semântica de um erro, o seu teste continuará passando alegremente enquanto a produção quebra. Um dublê bem calibrado é uma ferramenta poderosa, e é também uma foto do provedor num instante do passado.

• Calibração do perfil: precisa de API real, com amostra pequena, e deve ser refeita quando o modelo ou o provedor mudar.
• Descoberta de cota e comportamento no limite: API real, porque é uma propriedade da sua conta e não do seu código.
• Qualidade de resposta e regressão de prompt: fora do escopo do teste de carga, é avaliação, e o dublê não tem opinião sobre conteúdo.
• Capacidade, fila, memória, conexões e freio na borda: dublê, porque é o seu sistema que está sendo medido e o volume é caro.
• Contrato da API e formato de erro: teste de contrato contra a API real, periódico, para o dublê não virar ficção.