Fila Indiana de Chamadas (Serial Latency Stack) é um smell de IA, ou seja, um sinal de problema em sistemas com LLM, do grupo Operação. Cinco chamadas independentes rodam uma depois da outra e o usuário espera 20 segundos.
Os quatro primeiros passos não dependem uns dos outros, mas rodam em fila. Some: 1,1 + 2,4 + 1,8 + 0,9 + 2,2 = 8,4 s. O cliente fica mais de oito segundos em silêncio. Muitos desligam antes de ouvir a resposta.
No WhatsApp de um banco, o mesmo desenho atrasa a confirmação de um Pix. A pessoa já pagou no app e espera o bot dizer se caiu. Cada segundo extra aumenta o “já paguei, por que não aparece?”.
Sinais de Fila Indiana de Chamadas:
O código faz várias chamadas ao modelo ou a ferramentas, uma depois da outra, com await em sequência.
Algumas dessas chamadas não usam o resultado das anteriores.
O trace mostra spans em escada, sem nenhum sobreposto.
A latência total é a soma das latências, e cresce a cada passo novo.
Usuários reclamam de lentidão, mas cada chamada isolada é rápida.
flowchart LR
IN(["1. Entrada"]):::io --> A(["2. Intenção"]):::llm
A --> B(["3. Resumo do cliente"]):::llm
B --> C(["4. Política"]):::llm
C --> D(["5. Sentimento"]):::llm
D --> R(["6. Resposta"]):::llm
A entrada chega.
a 5. Quatro análises independentes rodam em fila, cada uma esperando a anterior terminar.
A resposta só começa depois de todas.
Por que acontece
Código escrito de cima para baixo. A forma mais natural de escrever é uma linha depois da outra.
Cada passo entrou numa época. O pipeline começou com um passo; os outros foram acrescentados ao fim da lista.
Paralelismo parece complicado.asyncio.gather ou Promise.all exigem pensar em dependências e erros.
Rate limit. Medo de estourar o limite do provedor faz o time evitar chamadas simultâneas.
Erro comum: paralelizar o que depende
A tentação, depois de ver o trace em escada, é jogar tudo num gather. Se a extração de campos precisa do tipo do documento, as duas em paralelo devolvem lixo ou uma corrida. O teste é simples: esta chamada usa o valor da outra? Se sim, a fila é honesta. Se não, ela está te cobrando espera de graça.
O guia “Building effective agents”, da Anthropic (dez. 2024), recomenda paralelizar chamadas de ferramenta independentes. O ponto não é “sempre paralelo”. É “não serialize por hábito”.
Quanto custa ignorar
Experiência. Em voz e em chat, cada segundo de espera aumenta o abandono.
Timeouts. Integrações com limite de tempo (webhooks, gateways) falham quando a soma passa do limite.
Escala. Cada passo novo piora a latência de forma linear, então ninguém quer acrescentar nada.
O custo em dinheiro não muda: são as mesmas chamadas. O que muda é o tempo.
Desenho
Tempo das quatro análises
Total até falar
Fila, como hoje
6,2 s
8,4 s
Quatro em paralelo
2,4 s
4,6 s
Sentimento em código, o resto em paralelo
2,4 s
4,6 s, uma chamada a menos
A terceira linha não fica mais rápida que a segunda neste exemplo, porque o resumo do cliente ainda manda. Ela fica mais barata e mais simples de manter.
Há passos que não dependem uns dos outros. Eles rodam ao mesmo tempo, e a latência passa a ser a do mais lento. Destinos: Seccionamento e Map-Reduce de Documentos.
Se alguns passos nem precisam de modelo (sentimento por regra, busca por id), troque por código. Veja LLM Fazendo Conta. E considere Cascata de Modelos para os passos que podem usar um modelo menor e mais rápido.
Antes de paralelizar, desenhe o grafo: seta só existe quando um passo lê o resultado do outro. O que ficar sem seta entre si sai no mesmo gather. Trate o rate limit com fila e teto de concorrência, não com uma fila indiana de propósito.
O que você ganha
Latência próxima à do passo mais lento, não à soma de todos.
Espaço para acrescentar análises sem piorar o tempo.
Um grafo de dependências explícito, que documenta o pipeline.
Quando ignorar
Passos realmente dependentes. Se cada passo usa o resultado do anterior, a fila é necessária. Reduza o número de passos ou o tamanho de cada um.
Processamento em lote. Se ninguém espera a resposta (um job noturno), latência importa pouco. Paralelize entre documentos, não dentro de cada um.
Rate limit apertado. Se o paralelismo vai causar erros de limite, trate o limite primeiro.
É esse smell?
Perguntas rápidas
O que é Fila Indiana de Chamadas?
Fila Indiana de Chamadas (Serial Latency Stack) é um smell de IA, ou seja, um sinal de problema em sistemas com LLM, do grupo Operação. Cinco chamadas independentes rodam uma depois da outra e o usuário espera 20 segundos.