Modèle / jeu de données
NVIDIA-NeMo/Curator avatar
NVIDIA-NeMo/Curator

NeMo Curator : industrialiser la curation de données d'entraînement, du laptop au cluster Ray

Scalable data pre processing and curation toolkit for LLMs

1 767 étoiles324 forksPythonApache-2.0
GitHub

En bref

De quoi s’agit-il ?
NVIDIA publie sous Apache-2.0 une boîte à outils Python qui transforme le filtrage, la déduplication et l'annotation de jeux de données en pipelines reproductibles, accélérés par GPU. Voici ce que le dépôt permet réellement de faire, et ce qu'il impose en retour.
À qui s’adresse-t-il ?
Adoptez NeMo Curator si vous produisez des corpus texte, image, vidéo ou audio destinés à l'entraînement et que la reproductibilité du pipeline compte autant que le résultat. Évitez-le si votre besoin se limite à un script pandas ponctuel : vous paierez une installation CUDA 12 et vLLM pour rien.
Puis-je l’utiliser commercialement ?
Oui. Apache-2.0 est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
Est-il encore maintenu ?
Oui. Le dépôt a reçu de nouveaux commits au cours des dernières 24 heures.
En quel langage est-il écrit ?
Principalement Python, d’après les statistiques de langage de GitHub.

Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.

ANALYSE OPEN SOURCE APPROFONDIE

Le problème : des notebooks jetables qui ne passent pas à l'échelle

Un pipeline de préparation de données pour l'entraînement commence souvent par un notebook. On charge un Parquet, on filtre les documents trop courts, on déduplique par hachage, on classifie le langage. Puis le corpus grossit, et le notebook ne tient plus. Le README positionne NeMo Curator exactement là : il s'adresse aux ingénieurs ML et aux équipes data qui ont besoin de pipelines de curation reproductibles plutôt que de scripts ad hoc. Le public visé est donc celui qui doit relancer la même transformation sur des corpus successifs, pas celui qui explore un jeu de données une fois. La promesse centrale tient en une phrase du README : exécuter le même pipeline sur un laptop ou sur un cluster Ray multi-nœuds. Cette contrainte de portabilité explique la plupart des choix d'architecture décrits plus bas, y compris ceux qui compliquent l'installation.

Quatre modalités, un même socle d'exécution

Le dépôt couvre le texte, l'image, la vidéo et l'audio, chacun avec ses opérations typiques. Pour le texte, le README cite la déduplication, la classification, le filtrage qualité et la détection de langue. Pour l'image : filtrage esthétique, détection NSFW, génération d'embeddings, déduplication. Pour la vidéo : détection de scènes, extraction de clips, filtrage de mouvement, déduplication. Pour l'audio : transcription ASR, évaluation de qualité, filtrage par WER. Les briques sont donc spécifiques à chaque modalité, mais l'exécution est mutualisée. Les notes de version indiquent qu'à partir de 26.02, l'architecture de pipeline repose sur Ray pour toutes les modalités, et que 26.04 a apporté une mise à niveau de Cosmos-Xenna en 0.2.0 ainsi qu'une API Resources simplifiée. Cette chronologie compte pour qui évalue la stabilité : la couche d'orchestration a bougé récemment, ce qui signifie que des exemples antérieurs peuvent ne plus correspondre à l'API actuelle.

Ce que la documentation montre du mécanisme

Le README ne détaille pas l'implémentation interne des étapes, et il faut le dire clairement : la mécanique fine de chaque filtre n'est pas exposée dans le matériel fourni. Ce qui est visible, c'est l'articulation générale. Un pipeline enchaîne des étapes qui chargent, filtrent, dédupliquent et transforment, et cette chaîne s'exécute sur Ray, ce qui permet de la lancer sur une machine unique ou de la répartir sur plusieurs nœuds. Les étapes lourdes en calcul (déduplication, classification, embeddings, inférence) sont celles que le projet destine au GPU. Le README mentionne l'usage de NVIDIA RAPIDS (cuDF, cuML, cuGraph) pour ces traitements, ainsi qu'un serveur d'inférence compatible OpenAI que l'on peut démarrer à l'intérieur du pipeline pour la génération de données synthétiques et la classification. Cette dernière brique est intéressante conceptuellement : au lieu d'appeler un service externe, l'inférence devient une étape du pipeline, ce qui simplifie la reproductibilité mais ajoute une dépendance GPU supplémentaire.

Installation : trois chemins, dont un qui refuse pip

Le projet s'installe via uv, que le README fait installer par le script officiel : curl -LsSf https://astral.sh/uv/install.sh | sh. Le chemin A sert de test de fumée sans GPU : uv venv && source .venv/bin/activate, puis uv pip install "nemo-curator[text_cpu]", et une vérification par python -c "import nemo_curator; print(nemo_curator.__version__)". Le chemin B vise le texte sur GPU et exige CUDA 12, un pilote NVIDIA compatible, Linux x86_64, environ 16 Go de mémoire GPU et un accès réseau à Hugging Face. Il faut d'abord récupérer le fichier d'overrides, puis installer avec uv pip install --override text_cuda12-overrides.txt --torch-backend cu129 --extra-index-url https://wheels.vllm.ai/0.22.0/cu129 "nemo-curator[text_cuda12]", avant de lancer python tutorials/quickstart.py. Le point le plus important est une contrainte dure : pip install standard n'est pas pris en charge pour text_cuda12, car vLLM et RAPIDS déclarent des exigences Numba incompatibles. Toute commande uv pip install incluant text_cuda12, y compris nemo-curator[all], doit donc passer le fichier d'overrides. Depuis un checkout source, uv sync --extra text_cuda12 et uv sync --extra all appliquent l'override automatiquement. Le chemin C recommande Docker pour la vidéo et l'audio, car ces pipelines dépendent de bibliothèques de codecs système que le conteneur NGC fournit déjà configurées.

La limite la plus concrète : l'installation GPU n'est pas négociable

C'est ici que le projet perd une partie de son audience. Le chemin GPU impose Linux x86_64, CUDA 12 et un pilote compatible. Pas de macOS, pas de Windows dans les prérequis affichés. La contrainte Numba entre vLLM et RAPIDS n'est pas un détail de packaging : elle signifie que l'environnement d'installation doit suivre exactement la procédure documentée, et qu'un pip install classique échouera. Pour un utilisateur qui voulait simplement dédupliquer un corpus texte de quelques gigaoctets, c'est un coût de mise en place disproportionné. Le chemin CPU existe, mais le README ne décrit pas ce qu'il couvre réellement : on peut vérifier que l'import fonctionne, pas en déduire que toutes les étapes y sont disponibles. Autre réserve : la documentation renvoie massivement vers des guides externes sur docs.nvidia.com, et le README lui-même ne contient presque aucun exemple de code de curation. Évaluer la qualité des filtres à partir de ce dépôt seul est donc impossible. Le matériel fourni ne permet pas non plus de savoir comment le pipeline se comporte quand un nœud Ray tombe en cours de traitement.

Face à une alternative : Spark ou Dask sur CPU

L'alternative la plus évidente pour une équipe déjà outillée est un pipeline Spark ou Dask exécuté sur CPU, en écrivant soi-même les filtres et la déduplication. La différence n'est pas cosmétique. Avec Spark, vous contrôlez chaque transformation et vous restez sur du matériel standard, sans CUDA 12 ni vLLM. Avec NeMo Curator, vous héritez d'étapes préécrites pour quatre modalités et d'une exécution GPU sur Ray, mais vous acceptez la chaîne d'installation décrite plus haut et un rythme de publication soutenu (v1.1.0 en février, v1.2.0 en mai, v1.3.0 en juillet 2026 d'après les versions publiées). Le choix se joue donc sur le volume et la nature des données : un corpus texte modeste ne justifie pas la dépendance GPU, tandis qu'un flux vidéo avec détection de scènes et déduplication par embeddings s'écrit difficilement à la main sans réimplémenter ce que le conteneur NGC fournit déjà.

Maintenance, versions et licence Apache-2.0

Le rythme de publication est rapide : trois versions mineures entre février et juillet 2026, avec des changements d'architecture annoncés (Cosmos-Xenna 0.2.0, API Resources simplifiée, montée de version du runtime Ray). Une équipe qui épingle une version devra prévoir du temps pour suivre ces évolutions, car une API simplifiée signifie généralement que l'ancienne forme change. La licence est Apache-2.0, ce qui autorise l'usage commercial et la modification, avec les obligations habituelles de conservation des mentions de copyright et du fichier de licence, et une clause de brevets. Le README ne signale aucune restriction additionnelle. Pour un avis juridique sur votre cas précis, il faut consulter un juriste : ce paragraphe décrit seulement ce que le dépôt déclare. Enfin, le rattachement au catalogue NGC pour les conteneurs implique de vérifier les conditions propres à ce canal de distribution si vous passez par l'image Docker.

Conclusion éditoriale

Adoptez NeMo Curator si vous produisez des corpus texte, image, vidéo ou audio destinés à l'entraînement et que la reproductibilité du pipeline compte autant que le résultat. Évitez-le si votre besoin se limite à un script pandas ponctuel : vous paierez une installation CUDA 12 et vLLM pour rien. Avant de vous engager, vérifiez trois points sur votre machine : la version du pilote NVIDIA face à CUDA 12, la disponibilité du fichier requirements/text_cuda12-overrides.txt, et la présence des bibliothèques de codecs système pour les charges vidéo et audio, que seule l'image NGC embarque.

Sources officielles

  1. Issues
  2. License: Apache-2.0
  3. NVIDIA-NeMo/Curator on GitHub
  4. README
  5. Releases
Notes de la communauté

Notes de la communauté