Limites et performances d’Experiments

Gardez vos pages W&B rapides et réactives en respectant ces limites de journalisation recommandées.

Pour que vos pages dans W&B restent rapides et réactives, veillez à journaliser dans les limites recommandées ci-dessous.

​

Considérations sur la journalisation

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

​

Nombre de métriques distinctes

Pour de meilleures performances, maintenez le nombre total de métriques distinctes dans un projet en dessous de 10 000.

import wandb

with wandb.init() as run:
    run.log(
        {
            "a": 1,  # "a" est une métrique distincte
            "b": {
                "c": "hello",  # "b.c" est une métrique distincte
                "d": [1, 2, 3],  # "b.d" est une métrique distincte
            },
        }
    )

W&B aplatit automatiquement les valeurs imbriquées. Cela signifie que si vous passez un dictionnaire, W&B le transforme en un nom séparé par des points. Pour les valeurs de configuration, W&B prend en charge 3 points dans le nom. Pour les valeurs de summary, W&B prend en charge 4 points.

Les noms de métriques doivent respecter certaines contraintes de nommage imposées par GraphQL. Voir les contraintes de nommage des métriques pour plus de détails.

Si votre Workspace ralentit soudainement, vérifiez si des runs récents ont involontairement enregistré des milliers de nouvelles métriques. (Le plus simple pour le repérer est de chercher des sections contenant des milliers de graphiques, où seuls un ou deux runs sont visibles.) Si c’est le cas, envisagez de supprimer ces runs et de les recréer avec les métriques souhaitées.

​

Taille des valeurs

Limitez la taille d’une valeur enregistrée à moins de 1 Mo et la taille totale d’un appel wandb.Run.log() à moins de 25 Mo. Cette limite ne s’applique pas aux types wandb.Media comme wandb.Image, wandb.Audio, etc.

import wandb

with wandb.init(project="wide-values") as run:

    # déconseillé
    run.log({"wide_key": range(10000000)})

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

Des valeurs trop larges peuvent allonger le temps de chargement des graphiques pour toutes les métriques du run, et pas seulement pour la métrique qui contient ces valeurs.

Les données sont enregistrées et suivies même si vous journalisez des valeurs plus larges que la taille recommandée. Cependant, vos graphiques peuvent se charger plus lentement.

​

Fréquence des métriques

Choisissez une fréquence de journalisation adaptée à la métrique que vous enregistrez. En règle générale, enregistrez moins souvent les valeurs volumineuses que les valeurs plus compactes. W&B recommande :

• Scalaires : <100,000 points enregistrés par métrique
• Médias : <50,000 points enregistrés par métrique
• Histogrammes : <10,000 points enregistrés par métrique

import wandb

with wandb.init(project="metric-frequency") as run:
    # Non recommandé
    run.log(
        {
            "scalar": 1,  # 100 000 scalaires
            "media": wandb.Image(...),  # 100 000 images
            "histogram": wandb.Histogram(...),  # 100 000 histogrammes
        }
    )

    # Recommandé
    run.log(
        {
            "scalar": 1,  # 100 000 scalaires
        },
        commit=True,
    )  # Soumettre ensemble les métriques groupées par étape

    run.log(
        {
            "media": wandb.Image(...),  # 50 000 images
        },
        commit=False,
    )
    
    run.log(
        {
            "histogram": wandb.Histogram(...),  # 10 000 histogrammes
        },
        commit=False,
    )

W&B continue d’accepter vos données enregistrées, mais les pages risquent de se charger plus lentement si vous dépassez les recommandations.

​

Taille de la configuration

Limitez la taille totale de la configuration de votre run à moins de 10 Mo. L’enregistrement de valeurs volumineuses peut ralentir les espaces de travail du projet et les opérations de la table Runs.

import wandb 

# Recommandé
with wandb.init(
    project="config-size",
    config={
        "lr": 0.1,
        "batch_size": 32,
        "epochs": 4,
    }
) as run:
    # Votre code d'entraînement ici
    pass

# Non recommandé
with wandb.init(
    project="config-size",
    config={
        "large_list": list(range(10000000)),  # Grande liste
        "large_string": "a" * 10000000,  # Grande chaîne
    }
) as run:
    # Votre code d'entraînement ici
    pass

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

​

Considérations concernant le Workspace

​

Nombre de runs

Pour réduire les temps de chargement, gardez le nombre total de runs dans un même projet en dessous de :

• 100,000 sur SaaS Cloud
• 10,000 sur Cloud dédié ou Autogéré

Au-delà de ces seuils, le nombre de runs peut ralentir les opérations impliquant les espaces de travail du projet ou les tableaux de runs, en particulier lors du regroupement de runs ou de la collecte d’un grand nombre de métriques distinctes pendant les runs. Voir également la section Nombre de métriques.

Si votre équipe accède souvent au même ensemble de runs, par exemple les runs récents, envisagez de déplacer en masse les runs moins souvent utilisés vers un nouveau projet « archive », afin de conserver un ensemble plus restreint de runs dans votre projet de travail.

​

Performances du Workspace

Cette section fournit des conseils pour optimiser les performances de votre Workspace.

​

Nombre de panneaux

Par défaut, un Workspace est automatique et génère des panneaux standard pour chaque clé enregistrée. Si le Workspace d’un grand projet comprend des panneaux pour un grand nombre de clés enregistrées, il peut être lent à charger et à utiliser. Pour améliorer les performances, vous pouvez :

1. Réinitialiser le Workspace en mode manuel, qui n’inclut aucun panneau par défaut.
2. Utiliser Quick add pour ajouter de façon sélective les panneaux des clés enregistrées que vous souhaitez visualiser.

Supprimer les panneaux inutilisés un par un a peu d’effet sur les performances. Réinitialisez plutôt le Workspace, puis rajoutez uniquement les panneaux dont vous avez besoin.

Pour en savoir plus sur la configuration de votre Workspace, consultez Panels.

​

Nombre de sections

Avoir des centaines de sections dans un Workspace peut nuire aux performances. Envisagez de créer des sections à partir de regroupements généraux de métriques et évitez la mauvaise pratique qui consiste à créer une section pour chaque métrique.

Si vous constatez que vous avez trop de sections et que les performances se dégradent, envisagez d’utiliser le paramètre du Workspace qui permet de créer des sections par préfixe plutôt que par suffixe, ce qui peut réduire le nombre de sections et améliorer les performances.

​

Nombre de métriques

Lorsque vous enregistrez entre 5 000 et 100 000 métriques par run, W&B recommande d’utiliser un Workspace manuel. En mode manuel, vous pouvez facilement ajouter et supprimer des panneaux en masse pour explorer différents ensembles de métriques. Avec un ensemble de graphiques plus ciblé, le Workspace se charge plus rapidement. Les métriques qui ne sont pas affichées restent collectées et stockées comme d’habitude.

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

​

Nombre de fichiers

Gardez le nombre total de fichiers téléversés pour un seul run en dessous de 1 000. Vous pouvez utiliser W&B Artifacts lorsque vous devez journaliser un grand nombre de fichiers. Dépasser 1 000 fichiers dans un seul run peut ralentir les pages de votre run.

​

Reports vs. Workspaces

Un rapport est une composition libre, avec une disposition flexible de panneaux, de texte et de médias, qui vous permet de partager facilement vos analyses avec vos collègues.

À l’inverse, un Workspace permet d’analyser de façon dense et performante des dizaines à des milliers de métriques sur des centaines à des centaines de milliers de runs. Les Workspaces offrent des capacités optimisées de caching, de requête et de chargement par rapport aux rapports. Les Workspaces sont recommandés pour un projet principalement utilisé à des fins d’analyse plutôt que de présentation, ou lorsque vous devez afficher 20 graphiques ou plus ensemble.

​

Performances du script Python

Les performances de votre script Python peuvent être réduites de plusieurs façons :

1. La taille de vos données est trop importante. Un volume de données élevé peut ajouter une surcharge de plus de 1 ms à la boucle d’entraînement.
2. La vitesse de votre réseau et la façon dont le backend W&B est configuré
3. Si vous appelez wandb.Run.log() plus de quelques fois par seconde. Cela s’explique par une légère latence ajoutée à la boucle d’entraînement chaque fois que wandb.Run.log() est appelé.

Une journalisation fréquente ralentit-elle vos runs d’entraînement ? Consultez ce Colab pour découvrir comment améliorer les performances en modifiant votre stratégie de journalisation.

W&B n’impose pas d’autres limites que la limite de débit. Le W&B Python SDK applique automatiquement un « backoff » exponentiel et réessaie les requêtes qui dépassent les limites. Le W&B Python SDK affiche « Network failure » en Ligne de commande. Pour les comptes non payants, W&B peut vous contacter dans des cas extrêmes où l’utilisation dépasse des seuils raisonnables.

​

Limites de débit

L’API W&B SaaS Cloud applique une limite de débit afin de préserver l’intégrité du système et d’en assurer la disponibilité. Cette mesure empêche qu’un seul utilisateur monopolise les ressources disponibles dans l’infrastructure partagée, afin que le service reste accessible à tous les utilisateurs. Vous pouvez être soumis à une limite de débit plus basse pour diverses raisons.

Les limites de débit sont susceptibles de changer.

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

​

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

Le tableau ci-dessus décrit les en-têtes HTTP de limitation de débit :

Nom de l’en-tête	Description
RateLimit-Limit	La quantité de quota disponible par fenêtre temporelle, exprimée sur une échelle de 0 à 1000
RateLimit-Remaining	La quantité de quota dans la fenêtre actuelle de limite de débit, exprimée 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() journalise vos données d’entraînement dans W&B. Cette API est utilisée soit avec une synchronisation en ligne, soit avec une synchronisation hors ligne. Dans les deux cas, elle applique un quota de limite de débit sur une fenêtre temporelle glissante. Cela inclut des limites sur la taille totale des requêtes et sur leur fréquence, cette dernière correspondant au nombre de requêtes sur une durée donnée.

W&B applique des limites de débit par projet W&B. Ainsi, si vous avez 3 projets dans une équipe, chaque projet a son propre quota de limite de débit. Les utilisateurs disposant de plans payants ont des limites de débit plus élevées que ceux des plans gratuits.

Si vous atteignez une limite de débit, vous recevez une erreur HTTP 429 Rate limit exceeded, et la réponse inclut les en-têtes HTTP de limitation de débit.

​

Suggestions pour rester sous la limite de débit de l’API de journalisation des métriques

Dépasser la limite de débit peut retarder run.finish() jusqu’à la réinitialisation de cette limite. Pour éviter cela, envisagez les stratégies suivantes :

• Mettez à jour la version de votre SDK Python W&B : assurez-vous d’utiliser la dernière version du SDK Python W&B. Le SDK Python W&B est régulièrement mis à jour et inclut des mécanismes améliorés pour réessayer les requêtes proprement et optimiser l’utilisation du quota.
• Réduisez la fréquence de journalisation des métriques : Réduisez au minimum la fréquence de journalisation des métriques afin de préserver votre quota. Par exemple, vous pouvez modifier votre code pour consigner des métriques toutes les cinq époques au lieu de chaque époque :

import wandb
import random

with wandb.init(project="basic-intro") as run:
    for epoch in range(10):
        # Simuler l'entraînement et l'évaluation
        accuracy = 1 - 2 ** -epoch - random.random() / epoch
        loss = 2 ** -epoch + random.random() / epoch

        # Consigner des métriques toutes les 5 époques
        if epoch % 5 == 0:
            run.log({"acc": accuracy, "loss": loss})

• Synchronisation manuelle des données : W&B stocke localement les données de votre run si vous atteignez la limite de débit. Vous pouvez synchroniser manuellement vos données avec la commande wandb sync <run-file-path>. Pour plus de détails, voir la Référence wandb sync.

​

Limites de débit sur l’API GraphQL

L’UI de W&B Models et l’API publique du SDK envoient des requêtes GraphQL au serveur pour interroger et modifier des données. Pour toutes les requêtes GraphQL dans le SaaS Cloud, W&B applique des limites de débit par adresse IP pour les requêtes non authentifiées et par utilisateur pour les requêtes authentifiées. La limite est basée sur le taux de requêtes (requêtes par seconde) dans une fenêtre de temps fixe, les limites par défaut étant déterminées par votre plan de tarification. Pour les requêtes SDK concernées qui spécifient un chemin de projet (par exemple, Reports, Runs, Artifacts), W&B applique des limites de débit par projet, mesurées en temps de requête de base de données.

Les utilisateurs des plans Teams et Enterprise bénéficient de limites de débit plus élevées que ceux du plan Free. Lorsque vous atteignez la limite de débit en utilisant l’API publique du SDK W&B Models, un message d’erreur correspondant s’affiche dans la sortie standard.

Si vous atteignez une limite de débit, vous recevez une erreur HTTP 429 Rate limit exceeded et la réponse inclut les en-têtes HTTP de limitation de débit.

​

Conseils pour ne pas dépasser la limite de débit de l’API GraphQL

Si vous récupérez un grand volume de données à l’aide de l’API publique du SDK W&B Models, envisagez d’attendre au moins une seconde entre les requêtes. Si vous recevez une erreur HTTP 429 Rate limit exceeded ou si RateLimit-Remaining=0 apparaît dans les en-têtes de réponse, attendez le nombre de secondes indiqué dans RateLimit-Reset avant de réessayer.

​

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.