Pular para o conteúdo principal
Casos de uso
  • 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.
Uma Routing Rule correspondente com seus próprios modelos de destino configurados substitui completamente este parâmetro load_balancer, independentemente do que a requisição envia. A estratégia e os modelos da própria Routing Rule são usados no lugar; as duas configurações nunca são mescladas.
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.
Como funciona a seleção:
  • 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.

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.
Como funciona a seleção:
  • 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:
Métricas principais:
  • 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.
Com 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.
Custos inesperados
  • Acompanhe a distribuição de custos real vs. esperada.
  • Monitore o uso excessivo de modelos caros.
  • Configure alertas de custo por provedor.
Problemas de desempenho
  • 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.
Todo o tráfego indo para um único modelo com 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.type está definido com a estratégia pretendida, caso se esperasse uma divisão igual.
A seleção demora a se adaptar após um deploy ou uma reinicialização
  • 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.

Uso avançado por peso

Pesos específicos por ambiente:
Ajuste dinâmico de pesos:
Com outras funcionalidades: