Fallback entre providers

Quando um provider retorna erro (timeout, rate limit, 503), o LiteLLM tenta automaticamente em outro provider que hospeda o mesmo modelo. Isso acontece sem nenhuma configuracao do seu lado — basta usar a API normalmente.

Como funciona

O LiteLLM mantem uma lista de "deployments" (instancias de provider) para cada modelo. Quando o primeiro falha com um erro retentavel, o proxy tenta o proximo deployment da lista. O numero maximo de tentativas depende da quantidade de deployments disponiveis para aquele modelo.

Erros que disparam retry

O que voce ve nos logs

Quando o fallback acontece, voce ve nos logs duas (ou mais) entradas para a mesma chamada logica:

• A primeira com status de erro e o provider que falhou
• A segunda com status de sucesso e o provider que respondeu

O custo cobrado e sempre do provider que completou a chamada com sucesso. Chamadas que falharam nao geram cobranca para voce (o custo upstream e absorvido pelo Tokia).

Modelos com multiplos providers

Nem todo modelo tem fallback. Modelos proprietarios hospedados por um unico provider (ex: o4-mini so existe na OpenAI) nao tem para onde fazer fallback. Modelos open-source populares (ex: deepseek-v3) podem ter deployments em mais de um provider.

Impacto na latencia

Cada retry adiciona latencia: o timeout do primeiro provider mais a latencia do segundo. Para chamadas sensiveis a tempo, considere usar modelos com alta disponibilidade ou com fallback configurado.

Quando todos os providers falham

Se todos os deployments falharem, o Tokia retorna o erro do ultimo provider tentado. O codigo HTTP e a mensagem de erro vem diretamente do provider.