> ## Documentation Index
> Fetch the complete documentation index at: https://docs.coreweave.com/llms.txt
> Use this file to discover all available pages before exploring further.
> Cette page décrit l’impact des pratiques de journalisation sur les performances dans W&B et fournit des conseils pour mettre à l’échelle le suivi des expériences dans les projets de grande taille.
# Journalisation à grande échelle et performances
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.
```python theme={"system"}
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 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`.
```python theme={"system"}
import wandb
with wandb.init() as run:
run.log(
{
"a": 1,
"b": {
"c": 2,
"d": {
"e": 3,
"f": 4,
},
},
}
)
```
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 :
```python theme={"system"}
import wandb
with wandb.init() as run:
run.log({"a": 1, "b": 2, "c": 3})
```
```python theme={"system"}
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** correspond au nombre d’appels à `wandb.Run.log()` par minute.
```text theme={"system"}
fréquence de journalisation = 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 :
```text theme={"system"}
débit = points journalisés par minute
```
Ou, de façon équivalente :
```text theme={"system"}
débit = points journalisés × fréquence de journalisation
```
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.
| Dimension | Recommandation à 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 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.
| 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 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.
| 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 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`.
```python theme={"system"}
import wandb
with wandb.init() as run:
run.log(
{
"a": 1,
"b": {
"c": "hello",
"d": [1, 2, 3],
},
}
)
```
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.
```python theme={"system"}
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)
```
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.
```python theme={"system"}
import wandb
with wandb.init(project="metric-frequency") as run:
# Recommandé : regrouper les métriques scalaires associées
run.log(
{
"loss": 0.12,
"accuracy": 0.98,
"lr": 1e-4,
},
commit=True,
)
```
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.
```python theme={"system"}
import json
import wandb
# Recommandé
with wandb.init(
project="config-size",
config={
"lr": 0.1,
"batch_size": 32,
"epochs": 4,
},
) as run:
pass
# Déconseillé
with wandb.init(
project="config-size",
config={
"large_list": list(range(10000000)),
"large_string": "a" * 10000000,
},
) as run:
pass
# Déconseillé
with open("large_config.json", "r") as f:
large_config = json.load(f)
wandb.init(config=large_config)
```
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](/fr/products/wandb/runs/manage-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](/fr/products/wandb/app/features/panels#quick-add) 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](/fr/products/wandb/app/features/panels).
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.
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](/fr/products/wandb/app/features/panels).
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.
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](https://wandb.me/log-hf-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.
| Nom de l’en-tête | Description |
| - | - |
| `RateLimit-Limit` | Quota disponible dans la fenêtre de temps en cours, sur une échelle de 0 à 1000 |
| `RateLimit-Remaining` | Quota restant dans la fenêtre en cours, sur une échelle de 0 à 1000 |
| `RateLimit-Reset` | Nombre de secondes avant la réinitialisation du quota en cours |
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](/fr/products/wandb/ref/cli/wandb-sync).
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.
```python theme={"system"}
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 synchroniser manuellement, utilisez `wandb sync `. Voir [`wandb sync`](/fr/products/wandb/ref/cli/wandb-sync).
Limites de débit de l’API GraphQL
La W\&B App et l’[API publique](/fr/products/wandb/ref/python/public-api/api) 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.
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.
## Related topics
- [Architecture de référence](/fr/products/wandb/platform/hosting/self-managed/ref-arch.md)