Weights & Biases : suivi d'expériences, Weave, CoreWeave et usages

Weights & Biases, abrégée W&B, est l'entreprise qui édite l'une des plateformes les plus utilisées pour suivre les expériences de machine learning. Lorsqu'une équipe lance des dizaines d'entraînements avec des hyperparamètres et des jeux de données différents, la plateforme enregistre pour chaque exécution les métriques, la configuration, le code et les fichiers produits, puis permet de les comparer dans des tableaux de bord.

L'entreprise est fondée en 2017 à San Francisco par Lukas Biewald, Chris Van Pelt et Shawn Lewis. Les deux premiers avaient auparavant lancé Figure Eight, une société d'annotation de données. L'outil est né d'un besoin d'expérimentation, notamment auprès d'équipes de recherche comme celles d'OpenAI, avant de s'élargir en plateforme MLOps : artefacts, registre de modèles, recherche d'hyperparamètres et rapports. Avec l'essor des modèles de langage, elle lance Weave, dédié aux applications LLM et aux agents.

En mars 2025, CoreWeave, fournisseur de cloud GPU, annonce son intention de racheter la société. L'opération est finalisée le 5 mai 2025. CoreWeave indique vouloir associer son infrastructure aux outils de développement de W&B, tout en maintenant l'interopérabilité de la plateforme avec d'autres clouds, modèles et frameworks.

Dans la chaîne de valeur, W&B se situe entre le code d'entraînement et la décision de mise en production. Il ne calcule rien lui-même : il observe ce que font les frameworks, les GPU et les pipelines, et rend ces observations lisibles par toute l'équipe. C'est ce qui le distingue d'un laboratoire comme OpenAI, qui conçoit des modèles, et d'une plateforme de distribution comme Hugging Face, qui héberge des modèles et des jeux de données.

L'adoption s'est faite d'abord par les chercheurs et les data scientists, qui installaient l'outil sans passer par les équipes d'infrastructure. Cette entrée par le bas explique la place de W&B dans de nombreux laboratoires et projets de deep learning, et pourquoi il apparaît souvent dans les parcours de formation MLOps comme premier outil de suivi.

À retenir : Weights & Biases ne remplace ni le framework d'entraînement ni l'orchestrateur. C'est la couche de mémoire et de comparaison des expériences, que l'on branche sur les outils existants.

La plateforme se répartit en deux familles. W&B Models regroupe les outils classiques du cycle d'entraînement, W&B Weave ceux des applications LLM. Depuis le rachat, des services d'inférence et de post-entraînement s'y ajoutent, adossés à l'infrastructure de CoreWeave.

L'intégration passe par un SDK Python : quelques lignes ajoutées à une boucle d'entraînement PyTorch suffisent pour que les métriques apparaissent en temps réel. Pour de la recherche d'hyperparamètres, la fonction de sweeps s'appuie notamment sur l'optimisation bayésienne.

Comment choisir entre Models et Weave ?

Le critère est la nature du projet. Pour entraîner ou affiner un modèle, avec des courbes de perte, des hyperparamètres et des jeux de données versionnés, W&B Models est le point d'entrée. Pour une application qui appelle un LLM, orchestre des outils ou enchaîne des étapes d'agent, la question devient celle de la trace : quel prompt, quel contexte, quelle réponse, quel coût et quelle latence. Weave répond à ce besoin, et son évaluation sur des jeux d'exemples complète les métriques classiques. Beaucoup d'équipes utilisent les deux, car un modèle affiné se retrouve ensuite derrière une application à surveiller.

Les services d'inférence et de post-entraînement sont plus récents. Ils reposent sur l'infrastructure de CoreWeave et étaient décrits en préversion publique dans la documentation consultée : leurs conditions et leur tarification sont à vérifier avant tout projet.

La réponse dépend de la couche considérée, car l'entreprise distingue ses bibliothèques de sa plateforme.

• Le SDK Python wandb est publié sur GitHub et s'installe librement, mais il envoie par défaut ses données vers le serveur de la plateforme.
• Weave est publié sous licence Apache 2.0 et peut être utilisé pour tracer et évaluer des applications LLM.
• Le serveur et l'interface constituent le produit commercial. Ils sont disponibles en service hébergé par l'éditeur, ou en déploiement dédié ou auto-géré pour les offres payantes.

Cette architecture explique la comparaison fréquente avec MLflow, dont le serveur est lui-même open source et librement auto-hébergeable. Pour une entreprise soumise à des règles strictes sur la localisation des données, la possibilité d'un déploiement chez le client pèse autant que la licence.

Le modèle économique suit cette répartition. L'offre gratuite facilite l'adoption individuelle et académique, les abonnements par utilisateur financent les équipes, et les déploiements dédiés répondent aux grandes organisations. Depuis le rachat, CoreWeave peut aussi y voir un moyen d'attirer des charges de travail vers son cloud GPU, ce qu'il convient de garder en tête dans l'évaluation de la neutralité de l'outil, même si l'entreprise affirme maintenir l'interopérabilité.

À retenir : utiliser le SDK ne rend pas la plateforme open source. La vraie question est de savoir où vivent les données d'expériences et qui exploite le serveur.

Les deux outils couvrent le suivi d'expériences et le registre de modèles. MLflow est devenu le standard open source, notamment dans les environnements Databricks, tandis que W&B est la solution commerciale de référence pour les équipes de recherche et de deep learning.

Lequel choisir ? W&B convient aux équipes qui veulent une interface prête à l'emploi, des comparaisons riches et du partage sans exploiter de serveur. MLflow convient mieux quand l'auto-hébergement, la maîtrise des coûts ou l'intégration à une plateforme de données priment. Sur la partie LLM, la comparaison se déplace vers Weave face à MLflow Tracing ou à Langfuse, et les écarts de fonctionnalités changent vite : ils se vérifient dans la documentation du moment. Les deux peuvent coexister, et il vaut mieux tester sur un projet réel avant de généraliser. Le guide MLflow, l'outil indispensable du MLOps détaille l'autre côté de la comparaison, et LLMOps replace l'observabilité LLM dans la chaîne complète.