Trier les fournisseurs et contrôler les solutions de repli

Comprendre le classement des prix, de la latence et du débit de ShareAI, les fournisseurs ordonnés, les mesures indisponibles et les limites de secours sûres.

Voir en Markdown

Sur cette page

Prix#

Le classement des prix compare le tarif applicable par niveau d'entrée plus le tarif de sortie de base. Ce n'est pas une prévision de la facture totale de la requête. Consultez les prix d'entrée, de sortie et de cache pour le fournisseur sélectionné et votre charge de travail prévue.

Latence et débit#

La latence utilise le temps écoulé des requêtes terminées observées, et non le temps jusqu'au premier jeton. Le débit utilise les jetons de sortie observés par seconde écoulée. Les observations récentes couvrent une fenêtre de cinq minutes. Ces mesures guident le routage ; elles ne garantissent pas un temps de réponse ou une capacité.

Les fournisseurs sans observation requise de prix ou de performance sont classés après les fournisseurs mesurés dans les deux sens. Les identifiants stables départagent les égalités.

Ordre avant tri#

Un ordre explicite de fournisseurs prévaut sur le tri. Parmi les choix restants éligibles, le tri sélectionné détermine le classement. Les fournisseurs ignorés, uniquement externes, les opérations non prises en charge et les fournisseurs exclus par des autorisations clés restent inéligibles.

Politique	Choix éligibles
`allow_fallbacks: true`	D'autres fournisseurs éligibles peuvent être pris en compte, dans le respect de chaque restriction stricte.
`allow_fallbacks: false` avec `order`	Uniquement les fournisseurs explicitement listés dans l'ordre.
`allow_fallbacks: false` sans `order`	Uniquement le fournisseur classé en premier.

Le secours conserve le même modèle#

Le secours du fournisseur modifie l'infrastructure éligible pour le modèle exact demandé. Il ne passe pas à une autre étiquette de modèle. Tout choix de fournisseur en amont effectué à l'intérieur du fournisseur ShareAI est distinct de l'identité publique du créateur et de la politique du fournisseur d'exécution.

Gérer les requêtes interrompues#

Le routage ne réessaie pas automatiquement après un envoi réussi, une réponse incertaine ou une sortie partielle. Cela évite le travail et les frais en double. Conservez la sortie partielle et laissez l'application décider de lancer une nouvelle requête. Évitez les boucles de réessai illimitées.

Exemples#

JSON

{
  "provider": {
    "sort": {
      "by": "latency",
      "direction": "asc"
    },
    "allow_fallbacks": true
  }
}

Pour privilégier le débit le plus élevé, utilisez {"by":"throughput","direction":"desc"}. Inversez dans un sens ou dans l'autre uniquement si cet ordre correspond à votre test ou charge de travail prévue.

Dernière mise à jour le 16 septembre 2026