- Contornar erros transitórios dos provedores sem expor falhas aos usuários finais.
- Failover automático para um provedor de backup quando o principal está degradado ou com rate limit atingido.
- Absorver picos curtos de rate limit sem intervenção manual nem lógica de retry personalizada.
- Cumprir SLAs de disponibilidade em recursos de produção sem adicionar código de retry a cada serviço.
Retries
Tente novamente solicitações com falha automaticamente, com backoff exponencial. Configure quais códigos de erro HTTP disparam retries e quantas tentativas fazer.
Fallbacks
Roteie para outro modelo quando o principal falhar. Defina uma cadeia de fallback entre provedores para alta disponibilidade.
Retries
Tente novamente solicitações com falha automaticamente, com backoff exponencial.Início rápido
Configuração
Quando
retry é omitido, o gateway tenta novamente duas vezes nos códigos padrão. Defina "retry": {"count": 0} para fazer exatamente uma chamada por modelo.
Códigos de erro
Estratégias de retry
Algoritmo de backoff
Backoff exponencial com jitter
- Tentativa 1: 1s (±25%).
- Tentativa 2: 2s (±25%).
- Tentativa 3: 4s (±25%).
- Tentativa 4: 8s (±25%).
- Tentativa 5: 16s (±25%). Atraso total máximo: ~31 segundos para 5 retries
Exemplos de código
Boas práticas
Recomendações para produção
Siga estas orientações para uma configuração de produção sólida:- Use
count: 2-3para equilibrar confiabilidade e velocidade. - Sempre inclua
429(rate limits) emon_codes. - Monitore as taxas de retry para detectar problemas sistêmicos.
- Implemente um circuit breaker para falhas persistentes.
Tratamento de erros
Solução de problemas
Taxas de retry altas- Verifique se os rate limits estão sendo atingidos com frequência.
- Confirme se as chaves de API têm cotas suficientes.
- Acompanhe as páginas de status dos provedores para identificar interrupções.
- Reduza a quantidade de retries em aplicações sensíveis à latência.
- Use valores de timeout menores com retries.
- Considere fallbacks para alternativas mais rápidas.
- Verifique se os códigos de erro estão na lista
on_codes. - Confirme se a quantidade de retries não se esgotou.
- Consulte a documentação de erros específica do provedor.
Monitoramento
Acompanhe estas métricas de retry:Limitações
- Aumento da latência: os retries adicionam atraso (até 31s para 5 retries).
- Impacto nos custos: solicitações com falha ainda podem gerar cobranças.
- Consumo de rate limit: os retries são executados dentro do gateway em uma única solicitação recebida; assim, um retry conta uma vez para os rate limits e budgets da plataforma, enquanto cada tentativa conta para os rate limits do próprio provedor.
- Retries limitados: no máximo 5 retries por modelo após a tentativa inicial (até 6 chamadas), para evitar atrasos excessivos.
- Erros sem retry: um código de status só é tentado novamente quando está listado em
on_codes. A maioria dos erros de cliente 4xx, como 400 e 403, não é tentada novamente; o 429 é tentado novamente quando está listado emon_codes.
Uso avançado
Configurações por ambiente:Fallbacks
Alterne automaticamente para outro modelo quando o principal falhar.Início rápido
Configuração
Defina
fallback_on_codes no nível superior da solicitação. Uma lista personalizada substitui os códigos padrão. Por exemplo, inclua 400 junto com os padrões para fazer fallback em erros de solicitação inválida:
JSON
"fallback_on_codes": [400] limita o fallback a 400; rate limits e erros de servidor deixam de dispará-lo. Omita o campo ou use um array vazio para restaurar os padrões.
Condições de disparo
Por padrão, os fallbacks são ativados nos erros abaixo. Substitua esse conjunto comfallback_on_codes em uma solicitação ou no models_config de uma regra de roteamento de Fallback. Informe até 20 inteiros únicos entre 400 e 599. Uma regra de roteamento correspondente substitui os modelos e códigos de fallback definidos na solicitação.
Por exemplo, "fallback_on_codes": [429, 503] limita o fallback a rate limits e indisponibilidade do serviço. Solicitações canceladas nunca fazem fallback. Modelos sem um recurso necessário são ignorados, independentemente dos códigos configurados.
Boas práticas
Use no máximo 3 modelos de fallback. Ordene-os por preferência ou custo e escolha modelos com recursos semelhantes.Exemplos de código
Limitações
- Consistência das respostas: modelos diferentes podem retornar estilos de saída variados.
- Suporte a parâmetros: nem todos os provedores aceitam parâmetros idênticos.
- Impacto nos custos: solicitações com falha ainda podem gerar cobranças do provedor principal.
- Impacto na latência: tentativas sequenciais aumentam o tempo de processamento.
- Dependências de provedores: exige chaves de API para todos os provedores de fallback.

