Journalisation à grande échelle et performances

Cette page décrit comment les schémas de journalisation affectent les performances dans W&B et fournit des recommandations pour adapter le suivi des expériences aux projets de grande taille.

Les performances sont généralement influencées par 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 que vous envoyez à chaque appel de journalisation
• la façon dont votre espace de travail est configuré

Dans la plupart des cas, les problèmes de performances sont plus souvent dus à la journalisation d’un trop grand nombre de métriques distinctes qu’à celle d’un trop grand nombre d’étapes.

​

Termes clés

Les termes suivants sont utilisés sur l’ensemble de cette page.

​

Étapes

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

import wandb

with wandb.init() as run:
    run.log({"loss": 0.42}, commit=True)

​

Cardinalité des métriques

La cardinalité des métriques correspond au nombre de clés de métrique distinctes enregistrées dans un project, y compris les clés contenues dans des dictionnaires imbriqués.

Par exemple, les éléments suivants enregistrent 4 clés de métrique distinctes : a, b.c, b.d.e et b.d.f.

import wandb

with wandb.init() as run:
    run.log(
        {
            "a": 1,
            "b": {
                "c": 2,
                "d": {
                    "e": 3,
                    "f": 4,
                },
            },
        }
    )

W&B met à plat les dictionnaires imbriqués sous forme de noms de métriques séparés par des points.

​

Points enregistrés

Les points enregistrés correspondent au nombre total de valeurs de métrique enregistrées.

Par exemple, les deux exemples de code suivants génèrent trois points enregistrés :

import wandb

with wandb.init() as run:
    run.log({"a": 1, "b": 2, "c": 3})

import wandb

with wandb.init() as run:
    run.log({"a": 1})
    run.log({"a": 2})
    run.log({"a": 3})

​

Fréquence de journalisation

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

log frequency = wandb.Run.log() calls per minute

​

Débit

Le débit correspond au nombre total de points enregistrés par minute.

Vous pouvez considérer le débit comme :

throughput = logged points per minute

Ou, de façon équivalente :

throughput = logged points × log frequency

Les sections suivantes s’appliquent à W&B SaaS Cloud. Si vous utilisez un autre type de déploiement W&B, consultez votre administrateur pour obtenir des conseils ou connaître les limites propres à ce déploiement.

​

Recommandations pour le passage à l’échelle

Le tableau suivant résume les valeurs de fonctionnement recommandées pour la journalisation à grande échelle.

Dimension	Recommandations à grande échelle
Runs par projet	10 000
Étapes par run	500 000
Cardinalité des métriques par projet	100 000
Fréquence de journalisation	1 000 lignes par minute
Débit	100 000 valeurs par minute
Débit vidéo	40 Mo par minute

Ces valeurs sont fournies à titre indicatif pour maintenir de bonnes performances à grande échelle. W&B peut continuer à accepter des données au-delà de ces recommandations, mais les pages peuvent devenir plus lentes à charger et à utiliser.

​

Exemples de débit

Différents modes de journalisation peuvent produire le même débit.

​

Exemples de journalisation de scalaires

Métriques par appel de journalisation	Fréquence de journalisation (par minute)	Débit (valeurs par minute)
100	1,000	100,000
1,000	100	100,000
10,000	10	100,000
20,000	5	100,000

​

Exemples de journalisation vidéo

Taille de la vidéo (Mo)	Fréquence de journalisation (par minute)	Débit vidéo (Mo par minute)
1	46	46
5	8	40
10	4	40
50	1	50
100	0.3	30
250	0.1	25
500	0.07	35

​

Considérations sur la journalisation

Utilisez wandb.Run.log() pour suivre les métriques de l’expérience.

​

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é élevée des métriques est l’une des causes les plus fréquentes de ralentissement des espaces de travail.

Les problèmes de performances sont souvent dus à la journalisation d’un trop grand nombre de métriques distinctes, et non à la journalisation d’un trop grand nombre d’étapes.

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 davantage que vous ne l’imaginez.

Par exemple, l’exemple suivant consigne 3 clés de métrique distinctes : a, b.c et b.d.

import wandb

with wandb.init() as run:
    run.log(
        {
            "a": 1,
            "b": {
                "c": "hello",
                "d": [1, 2, 3],
            },
        }
    )

Si votre espace de travail ralentit soudainement, vérifiez si des runs récents ont introduit un grand nombre de nouvelles clés de métriques. Cela se manifeste souvent par de nombreux graphiques où seuls un ou deux runs sont visibles. Si cela s’est produit involontairement, envisagez de supprimer, puis de recréer ces runs avec un ensemble de noms de métriques plus restreint et plus stable.

​

Taille de la valeur

Maintenez la taille d’une valeur enregistrée sous 1 Mo, et la taille totale d’un appel unique à wandb.Run.log() sous 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.

import json
import wandb

with wandb.init(project="wide-values") as run:
    # Déconseillé
    run.log({"wide_key": list(range(10000000))})

    # Déconseillé
    with open("large_file.json", "r") as f:
        large_data = json.load(f)
        run.log(large_data)

Des valeurs élevées peuvent ralentir le chargement des graphiques pour l’ensemble du run, et pas seulement pour la métrique contenant cette valeur élevée.

W&B stocke toujours les données enregistrées qui dépassent ces recommandations, mais les pages peuvent se charger plus lentement.

​

Fréquence de journalisation et débit

Choisissez une fréquence de journalisation adaptée à la valeur des données que vous collectez. Journaliser trop souvent peut augmenter la charge du SDK et ralentir l’application, en particulier en cas de forte cardinalité des métriques ou de charges utiles volumineuses.

Pour commencer, respectez les recommandations suivantes :

• Fréquence de journalisation : moins de 1 000 appels wandb.Run.log() par minute
• Débit : moins de 100 000 valeurs enregistrées par minute
• Débit vidéo : moins de 40 Mo par minute

Regroupez les métriques associées dans la même étape lorsque cela est possible. Par exemple, l’extrait de code suivant enregistre trois métriques dans la même étape, ce qui est plus efficace que de les enregistrer séparément.

import wandb

with wandb.init(project="metric-frequency") as run:
    # Recommandé : regrouper les métriques scalaires associées dans le même appel
    run.log(
        {
            "loss": 0.12,
            "accuracy": 0.98,
            "lr": 1e-4,
        },
        commit=True,
    )

​

Taille de la configuration

Limitez la taille totale de la configuration de votre run à moins de 10 Mo.

Les configurations volumineuses peuvent ralentir les espaces de travail du projet et les opérations du tableau de runs.

import json
import wandb

# Recommandé
with wandb.init(
    project="config-size",
    config={
        "lr": 0.1,
        "batch_size": 32,
        "epochs": 4,
    },
) as run:
    pass

# Non recommandé
with wandb.init(
    project="config-size",
    config={
        "large_list": list(range(10000000)),
        "large_string": "a" * 10000000,
    },
) as run:
    pass

# Non recommandé
with open("large_config.json", "r") as f:
    large_config = json.load(f)
    wandb.init(config=large_config)

​

Performances de l’espace de travail

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

​

Runs par projet

Pour les projets volumineux, veillez à maintenir le nombre de runs d’un projet sous la barre des 10 000 pour obtenir les meilleures performances.

Si votre équipe travaille régulièrement avec seulement un sous-ensemble de runs, envisagez de déplacer les runs plus anciens ou moins souvent utilisés vers un projet d’archive distinct. Voir Gérer les runs.

​

Nombre de panneaux

Par défaut, un espace de travail en mode automatique crée des panneaux standard pour chaque clé enregistrée. Dans les projets volumineux, cela peut générer trop de panneaux et ralentir l’espace de travail.

Pour améliorer les performances :

1. Réinitialisez l’espace de travail et passez-le 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 a généralement peu d’effet. Réinitialisez l’espace de travail et rajoutez uniquement les panneaux souhaités.

Voir Panneaux pour en savoir plus.

​

Nombre de sections

Des centaines de sections dans un espace de travail peuvent nuire aux performances.

Créez des sections à partir de regroupements généraux de métriques plutôt que de créer une section par métrique. Si vous avez trop de sections, envisagez de créer des sections par préfixe plutôt que par suffixe afin de regrouper les métriques associées dans un nombre plus réduit de sections.

​

De nombreuses métriques par run

Lorsque vous enregistrez des milliers de métriques par run, utilisez un espace de travail manuel afin de pouvoir choisir les métriques à visualiser.

Un ensemble de panneaux plus ciblé se charge plus rapidement. Les métriques qui ne sont pas affichées restent collectées et stockées.

Pour réinitialiser un espace de travail en mode manuel, cliquez sur le menu d’action () de l’espace de travail, puis sur Réinitialiser l’espace de travail. La réinitialisation d’un espace de travail n’a aucun impact sur les métriques stockées pour les Runs. Voir la gestion des panneaux de l’espace de travail.

​

Nombre de fichiers

Gardez le nombre de fichiers téléversés pour un seul run en dessous de 1 000.

Si vous devez journaliser un grand nombre de fichiers, utilisez plutôt W&B Artifacts. Dépasser 1 000 fichiers dans un seul run peut ralentir les pages de votre run.

​

Reports et espaces de travail

Un rapport est conçu pour la communication et la présentation. Un espace de travail est conçu pour une analyse dense et interactive sur de nombreux runs et de nombreuses métriques.

Utilisez un espace de travail lorsque vous devez comparer un grand nombre de runs ou afficher de nombreux graphiques côte à côte. Utilisez un rapport lorsque vous souhaitez présenter des résultats sélectionnés.

​

Performances du script Python

La journalisation peut ajouter une surcharge à votre script d’entraînement. Les principaux facteurs sont les suivants :

1. Charges de données volumineuses
2. Vitesse du réseau et configuration du backend
3. Appels très fréquents à wandb.Run.log()

Si vous appelez wandb.Run.log() trop souvent, chaque appel peut ajouter un peu de latence à la boucle d’entraînement. Regrouper plusieurs métriques dans un plus petit nombre d’appels de journalisation améliore généralement les performances.

Une journalisation fréquente ralentit-elle vos runs d’entraînement ? Voir ce Colab pour découvrir des stratégies permettant d’améliorer les performances en ajustant votre manière de journaliser.

W&B n’applique pas de limites strictes de produit à ces recommandations, au-delà de la limite de débit de l’API. Si vous dépassez les indications de cette page, W&B peut continuer à accepter vos données, mais l’application ou le SDK peuvent ralentir.

​

Limites de débit

Les API W&B SaaS Cloud utilisent des limites de débit pour préserver la fiabilité et la disponibilité du service.

Les limites de débit sont susceptibles de changer.

Si vous atteignez une limite de débit, le serveur renvoie le code HTTP 429 Rate limit exceeded et inclut des en-têtes de limitation de débit dans la réponse.

​

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

Nom de l’en-tête	Description
RateLimit-Limit	Quota disponible dans la fenêtre temporelle actuelle, exprimé sur une échelle de 0 à 1000
RateLimit-Remaining	Quota restant dans la fenêtre actuelle, exprimé sur une échelle de 0 à 1000
RateLimit-Reset	Le nombre de secondes avant la réinitialisation du quota actuel

​

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 incluent à la fois le taux de requêtes et la taille totale des requêtes sur une fenêtre temporelle glissante. Les offres payantes ont des limites plus élevées que les offres gratuites.

Si vous dépassez une limite de débit, le SDK W&B relance automatiquement les requêtes avec temporisation exponentielle. 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 d’atteindre une limite de débit :

• Utilisez la dernière version du SDK W&B.
• Réduisez la fréquence de journalisation.
• Regroupez les métriques liées dans un nombre plus restreint d’appels de journalisation.
• Utilisez la journalisation hors ligne et synchronisez plus tard si nécessaire.

import random
import wandb

with wandb.init(project="basic-intro") as run:
    for epoch in range(10):
        accuracy = 1 - 2 ** -epoch - random.random() / (epoch + 1)
        loss = 2 ** -epoch + random.random() / (epoch + 1)

        if epoch % 5 == 0:
            run.log({"acc": accuracy, "loss": loss})

Pour effectuer une synchronisation manuelle, utilisez wandb sync <run-file-path>. Voir wandb sync.

​

Limites de débit de l’API GraphQL

W&B App et l’API publique utilisent des requêtes GraphQL pour interroger et modifier les données.

Pour le SaaS Cloud :

• les requêtes non authentifiées sont soumises à une limite de débit par adresse IP
• les requêtes authentifié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 en fonction du temps d’exécution des requêtes de base de données

Les offres Teams et Enterprise ont des limites plus élevées que l’offre Free.

Si vous effectuez un grand nombre de requêtes vers l’API publique, attendez au moins une seconde entre chaque requête lorsque c’est possible. Si vous recevez 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.

​

Dépannage des projets lents

Si un projet ou un espace de travail semble lent, vérifiez d’abord les points suivants :

1. Des runs récents ont-ils introduit un grand nombre de nouveaux noms de métriques ?
2. Enregistrez-vous des données trop fréquemment ?
3. Les appels run.log() individuels sont-ils très volumineux ?
4. L’espace de travail 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 ?

Dans bien des cas, les performances s’améliorent après avoir réduit la cardinalité des métriques, regroupé les appels de journalisation et basculé les grands espaces de travail en mode manuel.

​

Considérations sur le navigateur

L’application W&B peut être gourmande en mémoire et fonctionne mieux avec Chrome. Selon la mémoire de votre ordinateur, avoir W&B actif dans 3 onglets ou plus en même temps peut dégrader les performances. Si vous constatez des ralentissements inattendus, envisagez de fermer d’autres onglets ou applications.

​

Signaler des problèmes de performances à W&B

W&B prend les performances au sérieux et examine chaque signalement de ralentissement. Pour accélérer l’analyse, lorsque vous signalez des chargements lents, pensez à activer le journal de performances intégré de W&B, qui capture les métriques clés et les événements de performance. Ajoutez le paramètre d’URL &PERF_LOGGING à une page qui se charge lentement, puis partagez le contenu de votre console avec votre équipe de compte ou l’assistance.