- Distribuir o tráfego entre várias contas de provedores para ficar dentro dos limites de taxa por chave.
- Fazer testes A/B de provedores roteando uma porcentagem configurável do tráfego para cada um.
- Espalhar o tráfego entre vários provedores para reduzir o impacto da indisponibilidade de um único provedor.
- Maximizar a vazão quando a capacidade de um provedor é um gargalo.
- Minimizar o tempo de resposta roteando para o modelo disponível mais rápido.
Início rápido
Distribua requisições entre vários provedores usando roteamento ponderado.Configuração
Cálculo dos pesos:
- Os pesos são normalizados:
[0.4, 0.8]→[33%, 67%]. - Peso maior = mais tráfego.
- Peso mínimo:
0.001. - O peso é ignorado na seleção round robin; todos os modelos da lista continuam recebendo uma parcela igual do tráfego.
load_balancer seleciona um modelo por requisição. Ele não repete uma chamada com falha em outro modelo do pool. O model de nível superior é usado como está apenas quando load_balancer não consegue produzir uma seleção, por exemplo, com uma lista models vazia. Para ter failover quando uma chamada falha, combine load_balancer com Fallbacks.Roteamento por latência
Roteie cada requisição para o modelo com a menor latência observada recentemente, em vez de uma divisão fixa do tráfego.- A latência é acompanhada por modelo como uma média móvel que dá mais peso às chamadas recentes, de modo que a seleção se adapta rapidamente quando um provedor fica mais rápido ou mais lento.
- Com dados recentes (amostras dos últimos 5 minutos) para todos os modelos configurados, o modelo com menor latência é selecionado. Um modelo sem dados, ou com dados desatualizados, é sondado novamente em vez de ser descartado.
- Dez por cento das seleções exploram o pool completo de acordo com o peso configurado, para manter as medições de latência atualizadas. Chamadas com falha são penalizadas para que uma falha rápida não pareça um sucesso rápido.
- Os pesos configurados decidem a exploração e os quase empates: quando os dois modelos mais rápidos estão a até 0,5 ms um do outro, vence o de maior peso. Com dados claros, a menor latência sempre vence.
Fluxo completo de seleção
Fluxo completo de seleção
Veja também: balanceamento de carga no nível da organização
Para aplicar balanceamento de carga em toda a sua organização sem alterar o código das requisições, use as Routing Rules para configurar as estratégias Fallback, Latency, Weighted e Round Robin no nível do workspace.
Roteamento por peso
Divida o tráfego entre modelos por pesos percentuais em vez de latência ou de uma rotação fixa.Padrões
Casos de uso
Roteamento Round Robin
Alterne entre os modelos configurados de forma uniforme, uma requisição por vez, em vez de dividir o tráfego por peso ou latência.- Cada requisição seleciona, na sua vez, o próximo modelo da lista, voltando ao primeiro modelo depois do último. Com dois modelos, as requisições se alternam; com três, a rotação percorre os três.
- Os pesos devem ser incluídos na requisição, mas não afetam a seleção: o round robin é puramente rotativo, então todos os modelos recebem uma parcela igual do tráfego ao longo do tempo, independentemente dos pesos.
- O round robin apenas seleciona um modelo por requisição; ele não repete nem faz failover de uma chamada com falha.
O round robin seleciona um modelo por requisição, mas não faz failover quando esse modelo apresenta erro. Para adicionar failover ao round robin, combine
load_balancer com Fallbacks.Exemplos de código
Monitoramento
Acompanhe estas métricas para um balanceamento de carga ideal:- Distribuição do tráfego: porcentagens reais vs. esperadas.
- Custo por modelo: monitore os gastos entre provedores.
- Tempos de resposta: compare a latência por modelo.
- Taxas de erro: acompanhe as falhas por provedor.
latency_based, o tempo de resposta já é o sinal de seleção. Não é necessário ajustar os pesos manualmente para desempenho; ajuste os pesos apenas para influenciar a exploração, a sondagem na partida a frio e o comportamento em quase empates.
Solução de problemas
Distribuição desigual- Verifique se os pesos estão normalizados corretamente.
- Confirme que há volume suficiente de requisições (mínimo de 100 requisições para ter precisão).
- Monitore por períodos mais longos.
- Acompanhe a distribuição de custos real vs. esperada.
- Monitore o uso excessivo de modelos caros.
- Configure alertas de custo por provedor.
- Verifique as diferenças de latência entre os modelos.
- Monitore lentidões específicas de provedores.
- Ajuste os pesos com base nos dados de desempenho.
latency_based
- Esperado quando um modelo é consistentemente o mais rápido. Dez por cento das requisições continuam explorando o restante do pool para manter seus dados de latência atualizados.
- Confirme que
load_balancer.typeestá definido com a estratégia pretendida, caso se esperasse uma divisão igual.
- Esperado. O histórico de latência fica em memória: após uma reinicialização, todos os modelos são tratados como desconhecidos até que novas amostras sejam coletadas.
Limitações
- Roteamento probabilístico: no curto prazo, o tráfego pode não corresponder exatamente aos pesos.
- Volume mínimo necessário: requer requisições suficientes para ter precisão estatística.
- Variações nas respostas: modelos diferentes podem retornar saídas de qualidade variável.
- Complexidade de custos: gerenciamento de cobrança entre vários provedores.
- Dependências de provedores: requer acesso por API a todos os modelos.
- Estado de latência em memória: com
latency_based, o histórico de latência fica em memória e não persiste entre reinicializações.

