NeMo Curator を採用する前に読む: GPU 前処理パイプラインの実像と導入条件
Scalable data pre processing and curation toolkit for LLMs
ひと目でわかる
- これは何？
- テキスト・画像・動画・音声のキュレーションを Ray 上で組む NVIDIA 製ツールキット。CPU スモークテストから text_cuda12 の依存解決、Slurm 配備まで、README とリリースノートから読み取れる範囲で判断材料を整理する。
- 誰に向いている？
- 採用すべきなのは、テキスト以外に画像・動画・音声も同じパイプライン基盤で扱いたいチームと、Nemotron-CC 系のレシピを再現したいチームである。単発のクリーニングスクリプトで足りる規模、あるいは GPU を持たず CPU だけで完結させたい用途には過剰で、text_cpu extra で足りるかどうかを最初に確認すべきである。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。直近 1 日以内に新しいコミットがあります。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
Curator が埋めるのは「前処理の再現性」という穴
LLM の学習データ作成は、一度きりのノートブックで済ませがちである。フィルタの閾値がどこにも記録されず、dedupe の結果が誰の手元のファイルなのか分からない。NeMo Curator が解こうとしているのはこの問題で、README は「repeatable, GPU-accelerated pipelines」という表現で、繰り返し実行できるパイプラインであることを前面に出している。対象読者は ML エンジニアとデータチームであり、想定される作業はテキストの重複排除、分類、品質フィルタ、言語判定、画像の美的フィルタや NSFW 判定、動画のシーン検出とクリップ抽出、音声の ASR 書き起こしと WER フィルタである。つまり単一の前処理ツールではなく、モダリティごとの部品を同じ実行基盤に載せるための枠組みだと読める。README が挙げる採用条件も明白で、一度きりのスクリプトではなく再現可能なパイプラインが必要なこと、dedupe や分類や埋め込み生成のようなデータ量の多い段に GPU と分散実行が必要なこと、そして Nemotron や Nemotron-CC といった NVIDIA の学習ワークフローに対応するレシピが欲しいことである。逆に言えば、この 3 条件のどれも当てはまらないなら、Curator を選ぶ理由は薄い。
Ray と Cosmos-Xenna の上でモダリティ別パイプラインが動く
リリースノートによれば、2026-02 のリリースでテキスト・画像・動画・音声の全モダリティが Ray ベースのパイプラインアーキテクチャに移行し、2026-04 のリリースで Cosmos-Xenna 0.2.0 への更新、Resources API の簡素化、Ray ランタイムの更新が行われた。README の「Run the same pipeline on a laptop or across a multi-node Ray cluster」という記述はこの設計を指しており、ローカルの単一プロセスから複数ノードの Ray クラスタまで、同じパイプライン記述を使い回すことを狙っている。GPU を使う段は RAPIDS (cuDF, cuML, cuGraph) に依存しており、重複排除や分類、埋め込み生成、推論といった処理がそこに乗る。テキスト以外のモダリティでは、パイプライン内に OpenAI 互換の LLM エンドポイントを立てる Inference Server が用意され、合成データ生成や分類に使えると README は説明している。ここで注意したいのは、Curator が学習そのものを行うツールではない点である。データを読み込み、フィルタし、重複を除き、変換して書き出すところまでが責務で、その出力をどう学習に回すかは利用者側の設計に残る。アーキテクチャの実装詳細、たとえばステージ間のデータ表現やバックプレッシャの扱いは、提示された資料からは確認できない。
インストールは 3 経路、text_cuda12 だけは uv が必須
README は用途別に 3 つの導入経路を示している。まず uv 自体の導入が前提で、curl -LsSf https://astral.sh/uv/install.sh | sh を実行する。経路 A は GPU 不要の CPU スモークテストで、uv venv && source .venv/bin/activate の後、uv pip install "nemo-curator[text_cpu]" を実行し、python -c "import nemo_curator; print(nemo_curator.__version__)" でバージョンを確認する。環境が正しく組めたかを確かめる最短の手順である。経路 B は CUDA 12 の GPU テキストパイプラインで、前提として CUDA 12 ツールキット、CUDA 12 対応の NVIDIA ドライバ、Linux x86_64、約 16 GB の GPU メモリ、Hugging Face へのネットワーク到達性が挙げられている。手順は requirements/text_cuda12-overrides.txt を取得したうえで、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]" を実行し、python tutorials/quickstart.py を走らせる。ここが Curator 導入で最も見落とされやすい点で、README は text_cuda12 について標準の pip install をサポートしないと明言している。理由も書かれている。vLLM と RAPIDS が互換性のない Numba の要件を宣言しているためである。nemo-curator[all] を含め、text_cuda12 を含む uv pip install には必ずこの override ファイルを添える必要がある。ソースチェックアウトから入れる場合は uv sync --extra text_cuda12 または uv sync --extra all がプロジェクトの override を自動適用する。経路 C は Docker で、動画と音声ではこちらが推奨される。システムのコーデックライブラリに依存するため、NGC の nemo-curator コンテナにそれらが設定済みで入っているという説明である。
依存解決の制約は Curator 側では消せない
text_cuda12 の導入が uv と override ファイルに縛られるという事実は、単なる手順の面倒さではなく、依存ツリーの衝突が上流に存在することを示している。vLLM と RAPIDS が宣言する Numba の要件が噛み合わないという説明は README にある通りで、Curator はそれを自前のテスト済み override で吸収している。裏を返せば、利用者が独自にパッケージを追加して同じ環境に同居させようとすると、この override の前提が崩れる可能性がある。CUDA 12 対応の Linux x86_64 という条件も固定的で、README の経路 B には他のプラットフォーム向けの代替手順が示されていない。GPU メモリの目安が約 16 GB とされている点も、手元のカードで quickstart が動くかどうかの一次判定に使える。動画と音声については、コーデックという Python の外側にある依存があるため、pip ではなくコンテナが推奨されている。これは Curator の設計上の欠陥ではなく、マルチメディア処理一般の性質だが、結果として「pip だけで完結させたい」という希望とは相容れない。CPU のみで試したい場合は text_cpu extra があるが、これは README の位置づけでは環境確認用の小さなパイプラインであり、GPU 段を含む本番構成の代わりにはならない。
マルチノードと Slurm は学習基盤との接続を想定している
README の What's Hot では Curator on Slurm が取り上げられ、HPC クラスタ上でテキスト・画像・動画・音声のマルチノード Ray パイプラインを動かすための配備ガイドへリンクしている。ラップトップからマルチノード Ray クラスタまで同じパイプラインを使うという主張は、この配備経路があって初めて意味を持つ。クラスタ側の実行基盤をすでに持っている組織にとっては、前処理をその基盤に載せられることが導入の決め手になりうる。一方で、Slurm 配備ガイドの具体的な設定項目や必要とするスケジューラのバージョンは、提示された資料からは確認できない。同様に、Ray クラスタのノード数や GPU 構成ごとのスループットも README には数値として示されていない。判断材料として使えるのは、Nemotron-4 の事前学習データセットが 8 兆トークン超の多言語ウェブデータに対して Curator のテキストパイプラインでキュレーションされたという記述と、Nemotron-CC のキュレーションパイプラインが Common Crawl の抽出から言語 ID、完全一致・曖昧一致・部分文字列の重複排除、アンサンブル品質分類、LLM による合成データ生成まで Curator を end-to-end で使っているという記述である。どちらも NVIDIA 自身のワークロードであり、第三者の環境での性能を示すものではない。
汎用のデータ処理基盤と何が違うのか
同じ規模の前処理を組む手段としては、Ray Data や Spark の上に自前のフィルタを書く方法がある。違いは抽象度の位置にある。汎用基盤は分散実行の仕組みを提供するが、重複排除のアルゴリズムや品質分類器、言語判定、動画のシーン検出といった処理は利用者が用意する。Curator はそこをモダリティ別の部品として同梱し、Nemotron-CC のレシピのように工程の並びまで提示する。とくに効くのは GPU を使う段で、RAPIDS を前提にした重複排除や埋め込み生成が最初から組み込まれている点は、Spark 上で同等のものを自作する場合と比べて作業量が変わる。逆に、汎用基盤の側に利があるのは既存のデータ基盤との統合である。すでに Spark で社内のデータレイクを回している組織にとって、Ray ベースの別系統を立てることは運用対象の増加を意味する。Curator を選ぶという判断は、前処理の部品を自前で維持するコストと、実行基盤を二重に持つコストの比較になる。README はこの比較には踏み込んでおらず、NVIDIA の学習ワークフローとの接続を採用理由として挙げるにとどまる。
バージョン追従とライセンスの扱い
リリースは v1.1.0 (2026-02-23)、v1.2.0 (2026-05-14)、v1.3.0 (2026-07-27) と約 3 か月間隔で並んでいる。2026-02 のリリースで全モダリティが Ray ベースに移行し、2026-04 で Cosmos-Xenna 0.2.0 と Resources API の簡素化が入っているため、この時期をまたぐアップグレードでは API の変更を前提にすべきである。とくに Resources API の簡素化は、リソース指定を書いているパイプラインに影響しうる。依存関係の面では、text_cuda12 の override ファイルがプロジェクト側で更新され続ける必要があり、CUDA や vLLM の側が動けば追従が発生する。この追従コストは Curator を使う限り継続する。ライセンスは Apache-2.0 で、リポジトリの LICENSE ファイルが参照されている。Apache-2.0 は商用利用や改変、再配布を許容する寛容型だが、特許条項や NOTICE の扱いなど条件の解釈は利用形態によって変わるため、ここで法的な助言はできない。組織の法務や OSS ポリシー担当が確認すべき事項である。なお、同梱されるモデルやコンテナ、NGC 経由で取得するもののライセンス条件は Apache-2.0 とは別に定まる可能性があり、この点は提示された資料からは判断できない。
編集部の結論
採用すべきなのは、テキスト以外に画像・動画・音声も同じパイプライン基盤で扱いたいチームと、Nemotron-CC 系のレシピを再現したいチームである。単発のクリーニングスクリプトで足りる規模、あるいは GPU を持たず CPU だけで完結させたい用途には過剰で、text_cpu extra で足りるかどうかを最初に確認すべきである。導入前に検証するのは 3 点: CUDA 12 対応の Linux x86_64 と約 16 GB の GPU メモリが手元にあるか、uv pip install に text_cuda12-overrides.txt を必ず添える運用にできるか、そして動画・音声を扱うなら NGC の nemo-curator コンテナを使う前提でよいか。この 3 つが噛み合わないなら、Curator の採用は後回しでよい。
コミュニティノート