Pour de meilleures performances, veillez à ce que le nombre total de métriques distinctes dans un projet reste inférieur à 10 000.
import wandbwith 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 transmettez un dictionnaire, W&B le convertit en nom séparé par des points. Pour les valeurs de configuration, W&B prend en charge jusqu’à 3 points dans le nom. Pour les valeurs de synthèse, W&B prend en charge jusqu’à 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 en savoir plus.Si votre espace de travail ralentit soudainement, vérifiez si des runs récents ont enregistré involontairement des milliers de nouvelles métriques. (Le plus simple pour le repérer est de chercher des sections contenant des milliers de graphiques, alors qu’un ou deux runs seulement y sont visibles.) Si c’est le cas, envisagez de supprimer ces runs et de les recréer avec les métriques souhaitées.
Limit the size of a single logged value to under 1 MB and the total size of a single wandb.Run.log() call to under 25 MB. This limit does not apply to wandb.Media types like wandb.Image, wandb.Audio, etc.
import wandbwith 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)
Wide values can affect the plot load times for all metrics in the run, not just the metric with the wide values.
Data is saved and tracked even if you log values wider than the recommended amount. However, your plots may load more slowly.
Pick a logging frequency that is appropriate to the metric you are logging. As a general rule of thumb, log wider values less frequently than narrower values. W&B recommends:
Limitez la taille totale de la configuration de votre run à moins de 10 Mo. L’enregistrement de valeurs volumineuses peut ralentir les Workspaces du projet et les opérations du tableau de 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)), # Liste volumineuse "large_string": "a" * 10000000, # Chaîne volumineuse }) 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)
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.
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 :
Réinitialiser le Workspace en mode manuel, qui n’inclut aucun panneau par défaut.
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.
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.
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.
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.
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.
Les performances de votre script Python peuvent être réduites de plusieurs façons :
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.
La vitesse de votre réseau et la façon dont le backend W&B est configuré
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.
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 429Rate limit exceeded, et la réponse inclut des en-têtes HTTP de limitation de débit.
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 429Rate limit exceeded, et la réponse inclut les en-têtes HTTP de limitation de débit.
Conseils 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 wandbimport randomwith 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.
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 429Rate 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 429Rate 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.
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.
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.
