Pular para o conteúdo principal
Casos de uso
  • 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-3 para equilibrar confiabilidade e velocidade.
  • Sempre inclua 429 (rate limits) em on_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.
Tempos de resposta lentos
  • 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.
Os erros continuam
  • 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 em on_codes.

Uso avançado

Configurações por ambiente:
Com outros recursos:
Lógica de retry personalizada (no cliente):

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
Definir apenas "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 com fallback_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.