Retry e Fallback: Como Garantir a Confiabilidade de LLMs

Lucas (CEO Toolzz)
27 de março de 2026

Imagine que você implementou funcionalidades poderosas baseadas em Modelos de Linguagem Grandes (LLMs) e, de repente, 10% das chamadas à API do provedor começam a falhar. Se sua aplicação se conecta diretamente ao provedor, essas falhas impactam diretamente a experiência do usuário. Mas, com uma abordagem inteligente de retry e fallback, a maioria dessas falhas pode ser contornada sem intervenção manual ou alterações no código.

O Problema com Retentativas Simplistas

A estratégia mais básica de retry — “se falhar, tente novamente” — funciona em muitos casos, especialmente quando as falhas são transitórias. No entanto, no contexto de APIs de LLMs, retentativas simples podem ser ineficazes e até prejudiciais. Nem todas as falhas são temporárias; um erro de requisição malformada persistirá em todas as tentativas. Além disso, tentar repetidamente o mesmo provedor não resolve problemas de capacidade. A complexidade aumenta ainda mais com respostas em streaming, onde uma troca para outro provedor no meio da transmissão pode gerar dados inconsistentes. Por fim, a falta de visibilidade sobre as retentativas silenciosas dificulta a identificação e resolução de problemas.

Classificação de Erros: A Chave para a Resiliência

A Toolzz adota uma abordagem abrangente, classificando os erros em três categorias, cada uma acionando uma resposta específica:

Essa classificação evita o desperdício de tempo com erros irrecuperáveis e garante que o fallback seja utilizado apenas quando há uma chance real de sucesso. Se você busca uma solução robusta para lidar com essas complexidades, conheça a Toolzz e como podemos te ajudar.

O Loop de Execução

Com a classificação de erros implementada, o processo segue um fluxo claro:

1. Classificação e Ordenação dos Provedores: Antes da primeira requisição, a Toolzz avalia e ordena todos os provedores disponíveis para o modelo solicitado, com base em sua pontuação (detalhes sobre a pontuação abaixo). O provedor com a maior pontuação é selecionado como o primário.
2. Tentativa no Provedor Primário: A requisição é enviada ao provedor primário. Se a requisição for bem-sucedida, a resposta é retornada e o processo é finalizado.
3. Classificação da Falha: Se a requisição falhar, o erro é classificado.
   • Retry, então Fallback: O provedor primário é retentado uma vez. Se a segunda tentativa também falhar, o processo avança para a etapa 4.
   • Fallback Imediato: A etapa 4 é executada diretamente.
   • Retornar Erro: O erro é retornado ao cliente.
4. Tentativa com o Próximo Provedor: A requisição é enviada ao próximo provedor da lista. Cada provedor de fallback recebe apenas uma tentativa.
5. Esgotamento de Provedores: Se todos os provedores falharem, o último erro e os detalhes de todas as tentativas são retornados.

O provedor primário tem no máximo duas tentativas (inicial + uma retentativa), enquanto cada provedor de fallback recebe apenas uma tentativa. Isso garante que a latência permaneça controlada.

Pontuação dos Provedores: Escolhendo a Melhor Ordem de Fallback

A ordem de fallback não é aleatória. A Toolzz atribui uma pontuação a cada provedor com base em métricas em tempo real coletadas do tráfego recente. Os provedores são classificados pela taxa de sucesso, com os mais confiáveis no topo da lista. O sistema se adapta continuamente, recompensando provedores que se recuperam de incidentes.

Alguns detalhes importantes sobre a pontuação:

• Métricas Qualificadas por Data Center: O desempenho dos provedores pode variar por região. As métricas são armazenadas por data center para refletir a experiência real dos usuários.
• Comportamento Fail-Open: Se as métricas não estiverem disponíveis, todos os provedores recebem uma pontuação padrão de 1.0, garantindo que nenhum seja descartado por falta de dados.
• Desempate Aleatório: Em caso de empate, a ordem é aleatória para distribuir a carga de forma uniforme.
• Filtros de Provedores Desabilitados: Provedores podem ser desabilitados operacionalmente, mas o filtro é desativado se todos os provedores estiverem desabilitados.

O Caso Específico do Streaming

Respostas em streaming introduzem uma restrição: uma vez que o primeiro chunk de dados é enviado ao cliente, a Toolzz não pode mais realizar retentativas ou fallback de forma transparente. Uma troca no meio do streaming resultaria em dados inconsistentes. Portanto:

• Antes do Primeiro Chunk: O comportamento de retry e fallback é normal.
• Após o Primeiro Chunk: A resposta é confirmada. Se o provedor falhar, o erro é retornado ao cliente.

Essa é uma decisão deliberada, baseada na premissa de que a maioria das falhas ocorre antes do início do streaming.

BYOK e a Priorização de Chaves

A Toolzz suporta o uso de suas próprias chaves de API (BYOK). Nesses casos, a Toolzz prioriza provedores que utilizam as chaves do cliente, utilizando os provedores gerenciados pela Toolzz como fallback. Caso a organização não possua créditos suficientes na plataforma, apenas os provedores BYOK são utilizados.

Observabilidade Completa

Todas as tentativas de requisição, incluindo retentativas e fallbacks, são registradas para fins de monitoramento. Os logs incluem o provedor utilizado, o erro ocorrido e o tempo de resposta. Esses dados permitem identificar problemas e otimizar o desempenho.

Conclusão

Em ambientes de produção, a resiliência é fundamental. As estratégias de retry e fallback da Toolzz garantem que suas aplicações baseadas em LLMs permaneçam operacionais mesmo diante de falhas de provedores. Com visibilidade completa e automação inteligente, você pode se concentrar em construir experiências incríveis para seus usuários, sem se preocupar com a confiabilidade da infraestrutura. Para entender melhor como a Toolzz pode otimizar a confiabilidade da sua infraestrutura de LLMs, verifique nossos planos e preços.