Skip to main content
Les performances dépendent généralement d’une combinaison des facteurs suivants :
  • le nombre de runs dans un projet
  • le nombre d’étapes dans chaque run
  • le nombre de métriques distinctes que vous journalisez
  • la fréquence à laquelle vous appelez wandb.Run.log()
  • la quantité de données envoyées lors de chaque appel de journalisation
  • la configuration de votre workspace
Dans la plupart des cas, les problèmes de performances sont dus à la journalisation d’un trop grand nombre de métriques distinctes plutôt qu’à celle d’un trop grand nombre d’étapes.

Termes clés

Les termes suivants sont utilisés tout au long de cette page.

Étapes

Une étape correspond à une ligne logique de métriques dans un run. Une étape est finalisée lorsque wandb.Run.log() est appelé avec commit=True, ou implicitement lorsque ni commit ni step ne sont spécifiés.

Cardinalité des métriques

La cardinalité des métriques correspond au nombre de clés de métrique distinctes journalisées dans un projet, y compris les clés contenues dans des dictionnaires imbriqués. Par exemple, le code suivant journalise 4 clés de métrique distinctes : a, b.c, b.d.e et b.d.f.
W&B aplatit les dictionnaires imbriqués en noms de métriques dont les niveaux sont séparés par des points.

Points journalisés

Les points journalisés correspondent au nombre total de valeurs de métriques enregistrées. Par exemple, les deux extraits de code suivants produisent chacun trois points journalisés :

Fréquence de journalisation

La fréquence de journalisation correspond au nombre d’appels à wandb.Run.log() par minute.

Débit

Le débit correspond au nombre total de points journalisés par minute. Vous pouvez vous représenter le débit ainsi :
Ou, de façon équivalente :

Recommandations à grande échelle

Les recommandations décrites dans cette section s’appliquent uniquement au Cloud mutualisé de W&B. Si vous utilisez un autre type de déploiement W&B, renseignez-vous auprès de votre administrateur pour obtenir des recommandations ou des limites propres à votre déploiement.
Le tableau suivant résume les plages de fonctionnement recommandées pour la journalisation à grande échelle.
Ces valeurs sont indicatives et visent à maintenir de bonnes performances à grande échelle. W&B peut continuer à accepter des données au-delà de ces recommandations, mais le chargement et l’utilisation des pages peuvent alors ralentir.

Exemples de débit

Différents schémas de journalisation peuvent aboutir au même débit.

Exemples de journalisation de valeurs scalaires

Les valeurs indiquées dans le tableau s’appliquent uniquement au Cloud mutualisé de W&B. Si vous utilisez un autre type de déploiement W&B, renseignez-vous auprès de votre administrateur pour obtenir des recommandations ou connaître les limites propres à votre déploiement.

Exemples de journalisation de vidéos

Les valeurs indiquées dans le tableau s’appliquent uniquement au Cloud mutualisé de W&B. Si vous utilisez un autre type de déploiement W&B, renseignez-vous auprès de votre administrateur pour connaître les recommandations ou les limites propres à votre déploiement.

Considérations relatives à la journalisation

Utilisez wandb.Run.log() pour suivre les métriques de vos expériences.

Cardinalité des métriques

Maintenez la cardinalité totale des métriques (nombre de métriques distinctes) d’un projet dans la plage recommandée pour votre charge de travail. Une cardinalité des métriques élevée est l’une des causes les plus fréquentes de lenteur des workspaces.
Les problèmes de performances viennent souvent d’un trop grand nombre de métriques distinctes journalisées, et non d’un trop grand nombre d’étapes journalisées.
Comme W&B aplatit les clés imbriquées en noms de métriques séparés par des points, la cardinalité des métriques peut augmenter plus que prévu. Par exemple, le code suivant journalise 3 clés de métriques distinctes : a, b.c et b.d.
Si votre workspace ralentit soudainement, vérifiez si des runs récents ont introduit un grand nombre de nouvelles clés de métriques. Cela se traduit souvent par de nombreux graphiques n’affichant qu’un ou deux runs. Si ce n’était pas voulu, envisagez de supprimer puis de recréer ces runs avec un ensemble de noms de métriques plus restreint et plus stable.

Taille des valeurs

Veillez à ce que chaque valeur journalisée ne dépasse pas 1 Mo et que la taille totale d’un appel wandb.Run.log() reste inférieure à 25 Mo. Ces recommandations ne s’appliquent pas aux types wandb.Media, tels que wandb.Image et wandb.Audio, qui sont gérés différemment.
Les valeurs volumineuses peuvent ralentir le chargement des graphiques de l’ensemble du run, et pas seulement celui de la métrique qui contient la valeur volumineuse.
W&B stocke tout de même les données journalisées qui dépassent ces recommandations, mais le chargement des pages peut être plus lent.

Fréquence de journalisation et débit

Choisissez une fréquence de journalisation adaptée à la valeur des données que vous collectez. Une journalisation trop fréquente peut alourdir la charge du SDK et ralentir l’application, en particulier lorsqu’elle s’accompagne d’une cardinalité de métriques élevée ou de charges utiles volumineuses. Pour commencer, respectez les recommandations suivantes en matière de journalisation :
  • Fréquence de journalisation : moins de 1 000 appels wandb.Run.log() par minute
  • Débit : moins de 100 000 valeurs journalisées par minute
  • Débit vidéo : moins de 40 Mo par minute
Dans la mesure du possible, regroupez les métriques liées dans une même étape. Par exemple, l’extrait de code suivant journalise trois métriques dans la même étape, ce qui est plus efficace que de les journaliser séparément.

Taille de la configuration

Limitez la taille totale d’une configuration de run à moins de 10 Mo. Des configurations volumineuses peuvent ralentir les workspaces de projet ainsi que les opérations sur le tableau des runs.

Performances du workspace

Les performances d’un workspace dépendent à la fois des données sous-jacentes du projet et de la configuration du workspace.

Runs par projet

Pour les projets volumineux, maintenez le nombre de runs d’un projet sous la barre des 10 000 afin d’obtenir des performances optimales. Si votre équipe ne travaille régulièrement qu’avec une partie des runs, envisagez de déplacer les runs plus anciens ou moins utilisés vers un projet d’archive distinct. Voir Gérer les runs.

Nombre de panneaux

Par défaut, un workspace en mode automatique crée des panneaux standard pour chaque clé journalisée. Dans les projets volumineux, cela peut générer un trop grand nombre de panneaux et ralentir le workspace. Pour améliorer les performances :
  1. Réinitialisez le workspace pour le passer en mode manuel.
  2. Utilisez Ajout rapide pour n’ajouter que les panneaux dont vous avez besoin.
Supprimer les panneaux inutilisés un par un n’a généralement que peu d’effet. Réinitialisez plutôt le workspace, puis ajoutez uniquement les panneaux souhaités.
Pour plus de détails, voir Panneaux.

Nombre de sections

Un workspace comportant des centaines de sections peut nuire aux performances. Créez des sections basées sur de grands regroupements de métriques plutôt qu’une section par métrique. Si vous avez trop de sections, envisagez de les créer par préfixe plutôt que par suffixe, afin de regrouper les métriques associées dans un nombre réduit de sections.
Basculer le mode de création des sections

Nombreuses métriques par run

Lorsque vous journalisez des milliers de métriques par run, utilisez un workspace manuel afin de choisir les métriques à visualiser. Un ensemble restreint de panneaux se charge plus rapidement. Les métriques qui ne sont pas représentées dans un graphique sont tout de même collectées et stockées. Pour réinitialiser un workspace en mode manuel, cliquez sur le menu action () du workspace, puis sur Reset workspace. La réinitialisation d’un workspace n’a aucune incidence sur les métriques stockées pour les runs. Voir Gestion des panneaux du workspace.

Nombre de fichiers

Limitez à moins de 1 000 le nombre de fichiers téléversés pour un même run. Si vous devez journaliser un grand nombre de fichiers, utilisez plutôt W&B Artifacts. Au-delà de 1 000 fichiers pour un même run, le chargement des pages du run risque d’être ralenti.

Reports et workspaces

Un rapport est conçu pour communiquer et présenter des résultats. Un workspace est conçu pour une analyse interactive et approfondie portant sur de nombreux runs et de nombreuses métriques. Utilisez un workspace lorsque vous devez comparer un grand nombre de runs ou afficher de nombreux graphiques en même temps. Utilisez un rapport lorsque vous souhaitez présenter une sélection de résultats.

Performances des scripts Python

La journalisation peut alourdir l’exécution de votre script d’entraînement. Les principaux facteurs sont les suivants :
  1. Des charges utiles volumineuses
  2. La vitesse du réseau et la configuration du backend
  3. Des appels très fréquents à wandb.Run.log()
Si vous appelez wandb.Run.log() trop souvent, chaque appel peut ajouter une légère latence à la boucle d’entraînement. Regrouper plusieurs métriques dans un plus petit nombre d’appels de journalisation permet généralement d’améliorer les performances.
Une journalisation trop fréquente ralentit vos runs d’entraînement ? Consultez ce Colab pour découvrir comment améliorer les performances en adaptant votre façon de journaliser.
W&B n’impose pas de limites strictes au niveau du produit pour ces recommandations, en dehors de la limite de débit de l’API. Si vous dépassez les recommandations de cette page, W&B peut continuer à accepter vos données, mais l’application ou le SDK risquent de ralentir.

Limites de débit

Les API du Cloud mutualisé de W&B appliquent des limites de débit afin de garantir la fiabilité et la disponibilité du service.
Les limites de débit sont susceptibles d’être modifiées.
Si vous atteignez une limite de débit, le serveur renvoie le code HTTP 429 Rate limit exceeded et ajoute des en-têtes de limite de débit à la réponse.

En-têtes HTTP de limitation du débit

Limites de débit de l’API de journalisation des métriques

wandb.Run.log() envoie les données d’entraînement à W&B, soit directement en ligne, soit ultérieurement via la synchronisation hors ligne. Les limites de débit de la journalisation des métriques s’appliquent au niveau du projet et portent à la fois sur le débit des requêtes et sur leur taille totale au cours d’une fenêtre de temps glissante. Les forfaits payants bénéficient de limites plus élevées que les forfaits gratuits. Si vous dépassez une limite de débit, le SDK W&B relance automatiquement les requêtes avec un délai d’attente progressif (backoff). Dans certains cas, cela peut retarder run.finish() jusqu’à la réinitialisation de la fenêtre de limite de débit. Pour réduire le risque de limitation de débit :
  • Utilisez la dernière version du SDK W&B.
  • Réduisez la fréquence de journalisation.
  • Regroupez les métriques associées afin de réduire le nombre d’appels de journalisation.
  • Le cas échéant, utilisez la journalisation hors ligne et synchronisez les données ultérieurement.
Pour synchroniser manuellement, utilisez wandb sync <run-file-path>. Voir wandb sync.

Limites de débit de l’API GraphQL

La W&B App et l’API publique utilisent des requêtes GraphQL pour interroger et modifier les données. Pour le Cloud mutualisé :
  • les requêtes non autorisées sont soumises à une limite de débit par adresse IP
  • les requêtes autorisées sont soumises à une limite de débit par utilisateur
  • certaines requêtes du SDK qui spécifient un chemin de projet peuvent également être limitées par projet, selon le temps d’exécution des requêtes en base de données
Les offres Teams et Enterprise bénéficient de limites plus élevées que les offres Free. Si vous effectuez un grand nombre de requêtes à l’API publique, patientez si possible au moins une seconde entre deux requêtes. Si vous recevez l’erreur HTTP 429 Rate limit exceeded ou si RateLimit-Remaining=0 s’affiche, attendez le nombre de secondes indiqué dans RateLimit-Reset avant de réessayer.

Résoudre les problèmes de lenteur des projets

Si un projet ou un workspace semble lent, vérifiez d’abord les points suivants :
  1. Les runs récents ont-ils introduit un grand nombre de nouveaux noms de métriques ?
  2. Journalisez-vous trop fréquemment ?
  3. Les appels run.log() individuels sont-ils très volumineux ?
  4. Le workspace est-il en mode automatique avec trop de panneaux ou de sections ?
  5. Le projet contient-il plus de runs que votre équipe n’en utilise activement ?
Bien souvent, il suffit de réduire la cardinalité des métriques, de regrouper les appels de journalisation par lots et de basculer les workspaces volumineux en mode manuel pour améliorer les performances.

Considérations relatives au navigateur

La W&B App peut être gourmande en mémoire et fonctionne de manière optimale dans Chrome. Selon la mémoire de votre ordinateur, garder W&B ouvert dans trois onglets ou plus en même temps peut dégrader les performances. En cas de lenteur inhabituelle, essayez de fermer d’autres onglets ou applications.

Signaler des problèmes de performances à W&B

W&B prend les performances très au sérieux et examine chaque signalement de lenteur. Pour accélérer l’analyse lorsque vous signalez des temps de chargement lents, pensez à activer le logger de performances intégré de W&B, qui capture les métriques clés et les événements liés aux performances. Ajoutez le paramètre d’URL &PERF_LOGGING à une page qui se charge lentement, puis transmettez la sortie de votre console à votre équipe de compte ou à l’assistance.
Ajout de PERF_LOGGING
Dernière modification le 30 septembre 2026