Benchmark de la parallélisation du pré‑traitement des données avec Workflow v6 : SSD, NVMe et stockage réseau

Contexte et objectifs

L’étape de pré‑traitement des données représente souvent le goulet d’étranglement d’un pipeline d’entraînement IA, surtout lorsque les jeux de données atteignent plusieurs téraoctets. Workflow v6 propose des primitives de parallélisation (tasks, fan‑out, caching) qui permettent d’exploiter le stockage sous‑jacent. L’objectif de ce benchmark est d’évaluer, de façon comparable, l’impact de trois configurations de stockage :

• SSD SATA (typique d’un serveur de développement)
• NVMe PCIe (stockage haut débit local)
• Stockage réseau (NFS 10 GbE)

Nous mesurons le temps total du pré‑traitement, le taux d’occupation CPU et la bande passante I/O, afin de déterminer le ratio coût/performance le plus favorable pour les pipelines de grande échelle.

Méthodologie

Données et workflow

• Dataset : 200 GB d’images JPEG, réparties en 2 M d’exemples, avec des métadonnées CSV.
• Opérations : 1️⃣ lecture du CSV, 2️⃣ décodage d’image, 3️⃣ redimensionnement 256→224, 4️⃣ normalisation, 5️⃣ écriture au format TFRecord.
• Parallélisation : 8 workers, chacun traitant un batch de 1 000 images.

Le workflow Workflow v6 est défini de façon identique pour les trois configurations, le seul paramètre variable étant le point de montage du répertoire data.

# workflow_v6_preprocess.yaml
steps:
  - name: load_metadata
    type: csv_reader
    params:
      path: /mnt/data/metadata.csv
  - name: decode_resize
    type: map
    parallelism: 8
    function: |
      def process(record):
          img = Image.open(record['path'])
          img = img.resize((224, 224))
          return np.array(img) / 255.0
  - name: write_tfrecord
    type: tfrecord_writer
    params:
      output_dir: /mnt/data/tfrecords/

Environnement de mesure

• Hardware : serveur Intel Xeon 6248R (2 GHz, 24 cœurs), 128 GB RAM.
• OS : Ubuntu 22.04, kernel 5.15.
• Outils de mesure : perf pour les I/O, psutil pour l’usage CPU, time pour le temps global.
• Répétitions : chaque configuration est exécutée 5 fois, les valeurs présentées sont la moyenne arithmétique.

Résultats observés

Configuration	Temps total (s)	CPU moyen (%)	Bande passante I/O (MB/s)
SSD SATA	842	68	210
NVMe PCIe	527	73	420
Stockage NFS	923	55	180

Analyse

• NVMe PCIe : le gain de 37 % de temps par rapport à la SSD SATA s’explique par la bande passante I/O doublée, ce qui réduit les temps d’attente lors du décodage des images. Le CPU reste légèrement plus sollicité, signe d’un meilleur équilibre entre calcul et I/O.
• Stockage réseau : malgré une latence réseau maîtrisée (10 GbE), la bande passante effective reste inférieure à celle d’une SSD locale, ce qui entraîne le plus long temps total. La charge CPU plus faible indique que les workers passent une part importante du temps à attendre les données.
• Stabilité : l’écart‑type des mesures est inférieur à 3 % pour chaque configuration, confirmant la reproductibilité du benchmark.

Recommandations pratiques

1. Prioriser le stockage local NVMe pour les étapes de pré‑traitement intensives en I/O, surtout lorsqu’on travaille avec des images haute résolution.
2. Utiliser le cache de Workflow v6 (cache: true dans la définition du step) pour les jeux de données réutilisés, ce qui compense partiellement les limitations du stockage réseau.
3. Dimensionner le nombre de workers en fonction du débit du stockage : augmenter la parallélisation au‑delà de la capacité I/O (ex. >8 workers sur SSD) n’apporte aucun bénéfice et peut même dégrader les performances.
4. Planifier la migration des données vers le stockage NVMe au moment du lancement du pipeline, en automatisant le copy avec un step rsync intégré au workflow.
5. Surveiller les métriques (perf et psutil) en production pour détecter les dérives de performance et ajuster dynamiquement le degré de parallélisation.

Conclusion

Ce benchmark montre que le choix du support de stockage a un impact direct et mesurable sur le temps de pré‑traitement des données dans Workflow v6. En misant sur le stockage NVMe et en adaptant le degré de parallélisation, les équipes produit peuvent réduire le temps de mise à disposition des données de plusieurs dizaines de minutes, tout en conservant une utilisation CPU optimale. La méthodologie présentée, basée sur des mesures reproductibles, peut être réutilisée pour d’autres charges de travail (extraction de texte, audio, etc.) afin d’optimiser les pipelines d’entraînement à grande échelle.