Skip to main content
Un projet représente le comportement stable que sollicite votre application. Il comprend un projet W&B, des datasets, des modèles fine-tunés, des évaluations, des analyses et une ou plusieurs versions d’acheminement. Cette page explique comment s’articulent les projets, les noms de modèles proxy et les versions, afin que vous puissiez modifier l’acheminement d’un projet sans perturber le trafic que votre application envoie déjà.
Dans l’API de gestion, un projet est appelé une tâche (task). Les chemins d’API commencent par /tasks/{alias}, où alias est le nom du modèle proxy. Voir Conventions de l’API.

​
Nom de modèle proxy

Le nom de modèle proxy est la chaîne de modèle qu’utilise votre application, par exemple ticket-classifier. Il est unique au sein d’une entity W&B et reste stable même lorsque les modèles changent. Il peut différer du nom du projet W&B dans lequel sont stockées les traces du projet. Utilisé seul, le nom de modèle proxy désigne toujours la version 1 :
Fixez explicitement une version plus récente :

​
Quand créer une version

Créez une nouvelle version lorsque vous souhaitez tester une autre combinaison de modèles ou d’autres paramètres de fournisseur sans affecter le trafic actuel de l’application. Chaque version dispose de sa propre configuration d’acheminement, indépendante des autres.
La création d’une version ne redirige pas le trafic. Un appelant n’y accède qu’après avoir remplacé la valeur de model par name@vN.

​
Ce que les versions ne copient pas

Une version n’est pas une copie du projet. Les datasets, les modèles fine-tunés et les évaluations restent des ressources rattachées au projet. Les requêtes de dataset permettent de choisir la version du projet dont le trafic doit être utilisé. Pour valider une nouvelle version avant qu’elle ne reçoive le moindre trafic de production, procédez comme suit :
  1. Maintenez la production sur le nom de modèle proxy seul et la version 1.
  2. Créez une nouvelle version avec l’acheminement proposé.
  3. Envoyez le trafic interne ou canari vers name@vN.
  4. Examinez les analyses et les évaluations.
  5. Ne modifiez le modèle configuré de l’application que lorsque la nouvelle version est prête.
Le trafic de votre application utilise alors l’acheminement de la nouvelle version.
Cette requête crée la version suivante avec son propre acheminement. La réponse contient le numéro de version attribué.
Pour consulter l’opération complète, voir Créer une version de tâche.
Dernière modification le 30 septembre 2026