Ordenar fornecedores e controlar fallback
Compreenda o ranking de preço, latência e throughput do ShareAI, fornecedores ordenados, medições indisponíveis e limites seguros de fallback.
Nesta página
Preço#
O ranking de preço compara a taxa aplicável ao nível de entrada mais a taxa base de saída. Não é uma previsão do custo total do pedido. Reveja os preços de entrada, saída e cache para o fornecedor selecionado e a sua carga de trabalho esperada.
Latência e throughput#
A latência utiliza o tempo decorrido observado de pedidos concluídos, não o tempo até ao primeiro token. O throughput utiliza tokens de saída observados por segundo decorrido. As observações recentes abrangem uma janela de cinco minutos. Estas medições orientam o roteamento; não garantem tempo de resposta ou capacidade.
Fornecedores sem observação necessária de preço ou desempenho classificam-se após os fornecedores medidos em qualquer direção. Identificadores estáveis resolvem empates.
Ordem antes da classificação#
Uma ordem explícita de fornecedores tem precedência sobre a classificação. Dentro das escolhas elegíveis restantes, a classificação selecionada determina o ranking. Fornecedores ignorados, apenas externos, operações não suportadas e fornecedores excluídos por permissões-chave permanecem inelegíveis.
| Política | Escolhas elegíveis |
|---|---|
allow_fallbacks: true | Outros fornecedores elegíveis podem ser considerados, dentro de cada restrição rígida. |
allow_fallbacks: false com order | Apenas os fornecedores listados explicitamente em ordem. |
allow_fallbacks: false sem order | Apenas o fornecedor classificado em primeiro lugar. |
O fallback mantém o mesmo modelo#
O fallback do fornecedor altera a infraestrutura elegível para o modelo solicitado exato. Não muda para outra tag de modelo. Qualquer escolha de fornecedor upstream feita dentro do fornecedor ShareAI é separada da identidade pública do criador e da política de execução do fornecedor.
Gerir pedidos interrompidos#
O roteamento não tenta novamente automaticamente após um despacho bem-sucedido, uma resposta incerta ou saída parcial. Isso evita trabalho duplicado e cobranças. Preserve a saída parcial e deixe a aplicação decidir se deve iniciar um novo pedido. Evite loops de repetição ilimitados.
Exemplos#
JSON
{
"provider": {
"sort": {
"by": "latency",
"direction": "asc"
},
"allow_fallbacks": true
}
}
Para preferir o maior throughput, use {"by":"throughput","direction":"desc"}. Inverta qualquer direção apenas quando essa ordem corresponder ao seu teste ou carga de trabalho pretendida.
Última atualização a 16 de setembro de 2026