x-proxy-request-id. Communiquez-le lorsque vous signalez un problème.
Échecs courants
L’erreur la plus courante concernant les projets
OpenAI-Project attend le nom du projet Weights & Biases, et non son alias. Les deux diffèrent lorsque le projet a été créé avec un nom différent de son alias. Dans ce cas, indiquer l’alias dans OpenAI-Project renvoie une erreur 404 accompagnée du message No routing configuration for project. Copiez la valeur depuis l’en-tête du projet dans Studio :
Une erreur d’ID du modèle n’est pas une erreur 404 du proxy
Le proxy valide le nom du fournisseur, mais pas chaque ID du modèle en amont. Si le fournisseur existe mais pas le modèle, le fournisseur sélectionné renvoie sa propre erreur. Cette distinction permet de différencier les problèmes de configuration d’acheminement des écarts liés à l’évolution du catalogue du fournisseur.
Échecs de traçage
Les écritures de traces sont asynchrones : elles ne transforment pas une réponse réussie du fournisseur en échec côté client. Les opérateurs surveillent les événements structurés d’échec d’écriture, qui portent le même ID de requête du proxy. Dans la mesure du possible, les problèmes déterministes liés aux entrées de trace sont rejetés avant l’envoi au fournisseur.API : Diagnostiquer un échec
API : Diagnostiquer un échec
Fournissez à l’agent l’URL de la requête, la valeur de l’en-tête
OpenAI-Project, le corps de requête masqué, le statut HTTP, le corps de réponse complet et x-proxy-request-id. Ne communiquez ni la clé bearer ni l’identifiant d’authentification du fournisseur.Un agent doit vérifier les points suivants, dans l’ordre :- La valeur de
OpenAI-Project, et si le projet indiqué correspond au nom du projet Weights & Biases et non à l’alias du projet. - Si
modelvautrouterou un remplacement de modèle, et quelle versionforge.project_versionsélectionne. - Si le fournisseur et le déploiement d’acheminement ont bien été appliqués.
- Si le corps de réponse provient du proxy ou du fournisseur en amont.