Passer au contenu principal
Public : développeurs et clients utilisant l’inférence multi-fournisseur / le routage API de modèles.

​
1) Termes clés

Fournisseur (vendor) : fournisseur d’origine qui exécute réellement l’inférence du modèle. Fournisseurs autorisés : fournisseurs que nous avons intégrés et validés vers lesquels nous pouvons router le trafic. Modèle : instance de modèle concrète et invocable (par ex. modèle X version Y). Requête : un seul appel d’inférence / API. Statut fournisseur : état opérationnel d’un fournisseur (par ex. sain / dégradé / indisponible).

​
2) Modes et limites de disponibilité

​
Mode fournisseur fixé (vous définissez explicitement vendor)

Si le fournisseur indiqué est indisponible (« down »), nous ne sommes pas responsables de l’indisponibilité ni des échecs de cette requête.

​
Mode automatique (vendor=auto, routage parmi les fournisseurs autorisés)

Si tous les fournisseurs autorisés pour ce modèle sont indisponibles (« down »), nous ne sommes pas responsables de l’indisponibilité ni des échecs qui en résultent. Détermination du statut : pages de statut ou annonces des fournisseurs, combinées à notre supervision (taux d’erreur / timeouts, etc.). Une confrontation croisée avec les journaux des deux côtés peut être utilisée.

​
3) Vérification par en-têtes de réponse (uniquement si stream:false)

Pour les réponses non streamées (stream:false), nous ajoutons des en-têtes de vérification pour confirmer le fournisseur et le compte réellement utilisés :
  • X-Vendor-Messages-Id — non masqué ; identique au messages_id du fournisseur pour le rapprochement et la traçabilité. Ce n’est pas un secret d’authentification et ne permet pas d’invoquer des appels.
  • X-Vendor-Api-Key — masqué ou dérivé de façon irréversible de la clé API fournisseur utilisée pour la requête. À des fins de vérification / audit uniquement ; non utilisable pour invoquer des appels.
Pour stream:true, ces en-têtes ne sont pas inclus (ou peuvent être vides). Ce seul fait n’implique pas une violation ni une incohérence. Si une vérification est nécessaire pour le streaming, fournissez l’ID de requête ; nous auditerons via les journaux serveur et les reçus fournisseur.

​
Sécurité et conservation

Nous conservons pendant 3 jours uniquement :
  • notre ID de requête interne, et
  • les en-têtes de réponse de vérification listés ci-dessus.
Nous ne conservons pas les valeurs brutes des clés API fournisseur ; seules des formes masquées ou unidirectionnelles apparaissent dans les journaux. X-Vendor-Messages-Id n’est pas un secret et ne peut servir à l’authentification ni à des appels secondaires. Si vous utilisez des proxys ou CDN, autorisez et préservez les en-têtes X-Vendor-* pour éviter qu’ils soient supprimés ou réécrits.

​
Exemple non streamé

HTTP/1.1 200 OK
Content-Type: application/json
X-Vendor-Messages-Id: msg_7f8e3aa2b9c14d23
X-Vendor-Api-Key: vk_live_****_1a2b_hash_9f12

{"id":"req_123","vendor":"acme","model":"model-x","output":"..."}

​
4) Cohérence des modèles et traitement des écarts

Exigence de cohérence : le champ vendor dans la réponse (ou les métadonnées) doit correspondre au fournisseur qui a réellement servi la requête.

​
Critères d’écart (l’un des cas suivants) :

  • La valeur vendor de la réponse diffère du fournisseur réel d’exécution.
  • Pour stream:false, les en-têtes de vérification et nos journaux de routage / reçus fournisseur ne concordent pas, sauf approbation écrite préalable d’une exception.

​
Remède et compensation

Un « décalage de modèle » confirmé est compensé à 2× les frais de la requête (par défaut en crédits ou compensation de facture ; en espèces si le contrat ou un accord écrit l’exige). Preuves et processus : fournissez l’ID de requête, les horodatages et la réponse brute (y compris les en-têtes si disponibles). Nous vérifions à l’aide des en-têtes de vérification, des journaux de routage serveur et des reçus / facturation fournisseur. En-têtes manquants ou anormaux (non streaming) : si des en-têtes manquent temporairement en raison de limites ou maintenance côté fournisseur, nous fournirons des preuves équivalentes (ID de reçu fournisseur, enregistrements de facturation, attestations signées, journaux serveur). Si nous ne pouvons fournir aucune preuve équivalente dans un délai raisonnable et que vos éléments sont complets, le cas peut être présumé être un écart et la compensation 2× s’applique.

​
5) Appels typiques

​
Fournisseur fixé

curl https://api.yourouter.ai/v1/chat/completions \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -H "vendor: openai" \
  -d '{
    "model": "gpt-4o",
    "messages": [{"role": "user", "content": "Hello from OpenAI!"}]
  }'

​
Routage automatique

curl https://api.yourouter.ai/v1/chat/completions \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -H "vendor: auto" \
  -d '{
    "model": "gpt-4o",
    "messages": [{"role": "user", "content": "Hello from OpenAI!"}]
  }'

​
6) FAQ

Q : Comment vérifier les réponses en streaming ? R : stream:true n’inclut pas les en-têtes de vérification. Ouvrez un ticket avec l’ID de requête ; nous auditerons via les journaux de routage et les reçus fournisseur. Q : dégagez-vous toujours toute responsabilité si un fournisseur est down ? R : en mode fournisseur fixé, si le fournisseur choisi est down, nous ne sommes pas responsables de l’indisponibilité de cette requête. En mode automatique, si tous les fournisseurs autorisés pour le modèle sont down, nous ne sommes pas non plus responsables. Q : l’exposition de X-Vendor-Messages-Id fuit-elle des données sensibles ? R : non. C’est un identifiant de traçage / rapprochement, pas un secret. X-Vendor-Api-Key est masqué de façon irréversible.