Erreurs du proxy - CoreWeave Docs

Les erreurs générées par le proxy ont la forme suivante :

{
  "error": {
    "message": "No task 'ticket-classifier' in entity 'personal-user'. Did you mean to pass metadata[\"wandb.entity\"]?",
    "type": "proxy_error"
  }
}

Chaque réponse contient l’en-tête x-proxy-request-id. Communiquez-le lorsque vous signalez un problème.

Échecs courants

Statut	Cause typique	Action
400	Modèle manquant, métadonnées non valides, destination de trace non sécurisée, JSON mal formé, valeur `wandb-cache-mode` non valide ou conflictuelle, ou requête de cache pour un appel en streaming	Corrigez le corps de requête ou supprimez l’en-tête de cache
401	Clé bearer W&B manquante ou non valide	Utilisez une clé API W&B en cours de validité
403	La clé n’a pas accès à l’entity demandé	Modifiez `wandb.entity` ou accordez l’accès à l’équipe
404	Projet, version ou fournisseur inconnu, ou chemin non pris en charge	Vérifiez l’entity, le nom du modèle proxy, la version et le déploiement du fournisseur
502	Le fournisseur est injoignable ou son flux de réponse a échoué	Vérifiez la disponibilité et les identifiants d’authentification du fournisseur
Statut du fournisseur	Le fournisseur sélectionné a renvoyé une erreur	Lisez la réponse du fournisseur ; le proxy conserve le statut et le corps de la réponse du service en amont

L’erreur la plus courante concernant l’entity

Une clé W&B personnelle utilise par défaut l’entity personnel de son propriétaire. Un projet d’équipe nécessite donc :

{"metadata": {"wandb.entity": "team-name"}}

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

Fournissez à l’agent l’URL de la requête, 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, dans l’ordre :

l’entity sélectionné dans metadata["wandb.entity"] ;
si model est un nom de modèle proxy, une version de projet épinglée ou une référence de fournisseur enregistrée ;
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.

Le schéma d’erreur lisible par machine figure dans la spécification OpenAPI du proxy d’inférence.

​Échecs courants

​L’erreur la plus courante concernant l’entity

​Une erreur d’ID du modèle n’est pas une erreur 404 du proxy

​Échecs de traçage

Échecs courants

L’erreur la plus courante concernant l’entity

Une erreur d’ID du modèle n’est pas une erreur 404 du proxy

Échecs de traçage