预训练数据管线的工程实践：从 datatrove 到 NeMo Curator，构建万亿 Token 级数据工厂的架构设计与工具选型
系统解读构建万亿 token 级预训练数据管线的工程全景——五大开源管线框架（datatrove/NeMo Curator/Dolma Toolkit/DCLM/DataFlow）的架构对比、Nemotron-CC 的分类器集成+合成回收范式、FineWeb2 的多语言自适应管线、Dolma 3 的三阶段数据策略、以及 NVIDIA 'Data, Data Everywhere' 的管线消融实验揭示的工程优先级
本期主题：当数据策展从「研究课题」变成「工程系统」
前 21 期我们系统覆盖了预训练数据工程的几乎所有维度——去重、过滤、配比、合成、安全、治理、评估、多模态、token 级操作。但如果你回头看这些工作的落地载体，一个有趣的事实浮现了：
绝大多数论文只描述了”做什么”，而没有描述”怎么跑起来”。
一篇论文说”我们用 MinHash 去重”，但不会告诉你：在 100 个 Common Crawl 快照、几十 TB 原始数据上跑 MinHash，你需要什么样的计算集群？数据怎么分片？中间状态怎么管理？管线跑到一半挂了怎么恢复？质量过滤的分类器推理成本和数据处理吞吐量怎么平衡？
这些”怎么跑起来”的问题，就是数据管线工程——预训练数据工程中最不性感但最关键的一层。
2024-2026 年间，五大开源框架的成熟彻底改变了这个局面：
预训练数据管线工程的演进：
2020-2022（手工脚本时代）：
→ 每个团队自己写 Python 脚本
→ 用 Spark/MapReduce 做大规模处理
→ 管线代码是一次性的，不可复用
→ "我们的管线跑了 3 个月，中间挂了 17 次"
2023（框架萌芽期）：
→ Dolma Toolkit（Allen AI）：Rust 编写，高性能文本处理
→ datatrove（HuggingFace）：Python，模块化管线
→ NeMo Data Curator（NVIDIA）：GPU 加速去重
→ 开始有了"标准化管线"的概念
2024-2025（框架成熟期）：
→ NeMo Curator 1.0-1.1：四模态支持（文本/图像/视频/音频）
→ DCLM（多机构联盟）：首个数据策展竞赛平台
→ FineWeb/FineWeb2：datatrove 构建的万亿级参考管线
→ Nemotron-CC：NeMo Curator 构建的 6.3T 生产管线
→ DataFlow（北大 DCAI）：LLM 驱动的可视化管线
→ Dolma 3：5.9T 三阶段数据策略
2026（生产化时代）： ← 当前
→ 不再需要从零搭建管线
→ 选择框架 → 组装模块 → 调参部署
→ 数据管线成为"基础设施"而非"研究项目"本期不讨论”做什么”——前 21 期已经覆盖了。本期聚焦”怎么做”：五大框架的架构设计与选型、三条生产级管线的工程细节、以及管线各步骤的优先级排序。
一、五大开源管线框架横评
1.1 框架全景
| 框架 | 组织 | 语言 | 核心优势 | 计算模型 | 模态 | 生产案例 | GitHub |
|---|---|---|---|---|---|---|---|
| datatrove | HuggingFace | Python | 模块化、平台无关、社区活跃 | CPU + SLURM/本地 | 文本 | FineWeb (15T), FineWeb2 (20TB) | 3.6k★ |
| NeMo Curator | NVIDIA | Python | GPU 加速、多模态、工业级 | GPU + RAPIDS + Ray | 文本/图像/视频/音频 | Nemotron-CC (6.3T) | 1.5k★ |
| Dolma Toolkit | Allen AI | Rust + Python | 极致性能、可审计 | CPU + 多线程 | 文本 | Dolma 3 (5.9T), OLMo 3 | 1.0k★ |
| DCLM | 多机构联盟 | Python | 竞赛平台、标准化评估 | CPU + Ray | 文本 | DCLM-Baseline | 0.5k★ |
| DataFlow | 北大 DCAI | Python | LLM 驱动、可视化、200+ 算子 | CPU + LLM API | 文本 | 6 领域验证 | 0.9k★ |
1.2 架构设计理念对比
五大框架的设计哲学：
datatrove（HuggingFace）：
"像搭乐高一样搭管线"
┌───────────────────────────────┐
│ Pipeline = [Reader, Filter, │
│ Processor, Deduplicator, │
│ Writer] │
│ │
│ Executor = Local / SLURM │
└───────────────────────────────┘
→ 每个 Block 独立、可替换
→ 执行器与处理逻辑解耦
→ 零 GPU 依赖，纯 CPU 即可运行
→ 适合：资源有限但追求灵活性的团队
NeMo Curator（NVIDIA）：
"用 GPU 碾压一切"
┌───────────────────────────────┐
│ cuDF DataFrame 为核心数据结构 │
│ → RAPIDS 加速数据操作 │
│ → Ray 分布式调度 │
│ → 内置 30+ 启发式过滤器 │
│ → Nemotron-CC 管线可复现 │
└───────────────────────────────┘
→ 去重速度比 CPU 快 16 倍
→ 总拥有成本降低 40%
→ 多模态一站式（文本/图像/视频/音频）
→ 适合：拥有 GPU 集群的大型团队
Dolma Toolkit（Allen AI）：
"用 Rust 写高性能，用 Python 写接口"
┌───────────────────────────────┐
│ 核心处理引擎：Rust │
│ → 多线程 + 零拷贝 │
│ Python CLI：用户接口 │
│ → taggers / mixers / dedup │
└───────────────────────────────┘
→ 极致的单机吞吐量
→ 数据血缘追踪（每个文档记录处理历史）
→ 适合：追求性能和可审计性的研究团队
DCLM（多机构联盟）：
"标准化的数据策展竞赛平台"
┌───────────────────────────────┐
│ 固定模型 + 固定评估 = 比数据 │
│ → 240T token 原始池 │
│ → 标准化提交接口 │
│ → 自动训练 + 评估 + 排行榜 │
└───────────────────────────────┘
→ 首个让"数据策展"可公平比较的平台
→ 适合：需要 benchmark 验证策展方法的研究
DataFlow（北大 DCAI）：
"用自然语言描述你要什么管线"
┌───────────────────────────────┐
│ DataFlow-Agent │
│ → 自然语言 → 算子合成 │
│ → 流水线规划 → 迭代验证 │
│ 200+ 可复用算子 │
│ 6 大领域预设管线 │
└───────────────────────────────┘
→ LLM 参与数据生成与变换闭环
→ 10K 数据超越 1M Infinity-Instruct
→ 适合：快速原型、SFT 数据准备1.3 选型决策树
你该选哪个框架？
Q1: 你有 GPU 集群吗？
├── Yes → Q2
└── No → Q3
Q2: 你需要处理多模态数据吗？
├── Yes → NeMo Curator（唯一支持图像/视频/音频）
└── No → 数据规模 > 10T token？
├── Yes → NeMo Curator（GPU 去重快 16x）
└── No → datatrove 或 Dolma Toolkit
Q3: 你的主要需求是什么？
├── 预训练数据策展 → datatrove（FineWeb 验证）
│ 或 Dolma Toolkit（Dolma 3 验证）
├── SFT/指令数据准备 → DataFlow（LLM 驱动，快速迭代）
├── 策展方法 benchmark → DCLM（标准化对比平台）
└── 需要最大灵活性 → datatrove（模块化 + 社区生态）
Q4: 团队技术栈？
├── Python 优先 → datatrove / DataFlow
├── 性能优先 → Dolma Toolkit（Rust 核心）
└── NVIDIA 生态 → NeMo Curator二、三条万亿级生产管线的工程解剖
前一节是框架。这一节看框架之上搭建的真实生产管线——它们是预训练数据工程”最佳实践”的活样本。
2.1 Nemotron-CC：NVIDIA 的 6.3T Token 管线
“Nemotron-CC: Transforming Common Crawl into a Refined Long-Horizon Pretraining Dataset” (NVIDIA / ACL 2025)
Nemotron-CC 是目前公开文档最详细的万亿级预训练数据管线。它的核心创新不在于某一步做得比别人好，而在于整体管线的设计哲学。
Nemotron-CC 管线全景：
┌─────────────────────────────────────────────────┐
│ Common Crawl │
│ (100 个快照, ~200TB WARC) │
└──────────────────────┬──────────────────────────┘
│
┌────────────┴────────────┐
│ Step 1: 文本提取 │
│ → trafilatura │
│ → 保留文档结构信息 │
└────────────┬────────────┘
│
┌────────────┴────────────┐
│ Step 2: 轻量启发式过滤 │
│ → 减少启发式依赖 │
│ → 只保留必要的规则 │
│ (语言检测/极短文档) │
└────────────┬────────────┘
│
┌────────────┴────────────┐
│ Step 3: 分类器集成 │ ← 核心创新 ①
│ → 多个质量分类器投票 │
│ → 比单分类器更鲁棒 │
│ → 留存率显著高于 │
│ FineWeb-Edu/DCLM │
└────────────┬────────────┘
│
┌────────┴────────┐
│ │
┌─────────┴─────┐ ┌───────┴──────────┐
│ 高质量文档 │ │ 中低质量但有价值 │
│ → 直接保留 │ │ → 合成数据回收 │ ← 核心创新 ②
│ (4.4T token) │ │ (LLM 改写) │
└───────────────┘ │ → 1.9T token │
└───────┬──────────┘
│
┌────────────────────┴────────────┐
│ Step 4: 去重 │
│ → NeMo Curator GPU MinHash │
│ → 跨快照去重 │
└────────────────────┬────────────┘
│
┌────────────────────┴────────────┐
│ 最终输出: 6.3T token │
│ (4.4T 真实 + 1.9T 合成回收) │
│ 唯一真实 token = DCLM 的 4 倍 │
└─────────────────────────────────┘两个关键工程决策：
① 分类器集成取代单分类器。 FineWeb-Edu 用一个 fastText 分类器，DCLM 用一个 fastText 分类器——它们的过滤率都超过 90%。Nemotron-CC 的洞察是：单分类器的假阴性（误杀好数据）不可忽视，而多分类器投票可以显著降低误杀率。结果：在保持 MMLU 比 DCLM +5.6 的同时，数据留存率大幅提升。
② 合成数据回收（Synthetic Data Reclamation）。 被分类器判为”中低质量”的文档不是直接丢弃，而是用 LLM 改写后回收。这产出了 1.9T token 的合成数据——占总量的 30%。这是一个非常激进的设计选择，但实验证明它对长 horizon 训练至关重要：当训练到 15T token 时，6.3T 的总量（含合成回收）让模型看到足够多的唯一 token，避免了过度重复。
工程经验：
Nemotron-CC 最大的工程教训是不要过度过滤。FineWeb-Edu 和 DCLM 通过激进过滤在短 horizon（1-2T token）训练中取得了出色的 benchmark 分数，但当训练延长到 10T+ token 时，数据多样性不足的问题就暴露了。Nemotron-CC 的分类器集成 + 合成回收范式，在”质量”和”数量”之间找到了更好的帕累托前沿。
2.2 FineWeb2：自动适配 1000+ 语言的管线
“FineWeb2: One Pipeline to Scale Them All” (HuggingFace / 2025)
如果说 Nemotron-CC 解决的是”如何在英语上做到极致”，FineWeb2 解决的是一个更难的工程问题：如何让一条管线自动适配所有语言？
| 指标 | FineWeb (v1) | FineWeb2 |
|---|---|---|
| 语言 | 仅英语 | 1000+ 语言 |
| 快照数 | ~96 个 | ~100 个 |
| 数据规模 | 15T token | 50 亿文档 / 20TB |
| 过滤策略 | 手工设计 | 自动适配 |
| 构建工具 | datatrove | datatrove |
核心工程创新：数据驱动的语言自适应
传统的多语言管线需要为每种语言手工调整过滤阈值——中文的”好文档”标准和阿拉伯语的”好文档”标准完全不同。FineWeb2 的做法是：
- 消融驱动的设计：在 9 种多样化语言上系统性消融每个管线步骤的参数，找到可泛化的规律
- 自适应阈值：过滤阈值根据语言特性自动调整，而非人工逐语言设定
- 评估任务选择方法论：用可量化标准筛选评估基准——避免”在不可靠的 benchmark 上调参”
- 质量感知再平衡：联合考虑重复度和质量两个因素来重新平衡各语言数据
FineWeb2 的多语言适配流程：
┌─────────────────────────────────┐
│ Common Crawl (~100 snapshots) │
└──────────────┬──────────────────┘
│
┌───────────┴───────────┐
│ 语言检测 + 分流 │
│ → 1000+ 语言桶 │
└───────────┬───────────┘
│
┌───────────┴───────────┐
│ 自适应过滤 │
│ → 不同语言不同阈值 │
│ → 参数自动调整 │
│ → 无需人工逐语言调参 │
└───────────┬───────────┘
│
┌───────────┴───────────┐
│ 跨语言去重 │
└───────────┬───────────┘
│
┌───────────┴───────────┐
│ 质量感知再平衡 │
│ → 重复度 × 质量 联合 │
│ → 低资源语言保护 │
└───────────┬───────────┘
│
┌───────────┴───────────┐
│ 50 亿文档 / 20 TB │
│ 1000+ 语言 │
└───────────────────────┘工程经验：
FineWeb2 的最大贡献不是数据集本身，而是证明了”一条管线可以服务所有语言”。此前，做多语言预训练数据的团队要么为每种语言单独建管线（工程成本极高），要么用英语管线粗暴套用到其他语言（效果差）。FineWeb2 的数据驱动自适应方法提供了第三条路。
2.3 Dolma 3：三阶段数据策略
Dolma 3 (Allen AI / 2025) 为 OLMo 3 系列模型构建，其最有价值的不是管线工具，而是数据策略。
| 数据集 | 规模 | 阶段 | 目标 |
|---|---|---|---|
| Dolma 3 Mix | 5.9T token | 预训练 | 通用能力 |
| Dolma 3 Dolmino Mix | 100B token | 中训练 | 数学/代码/QA/指令/思维链 |
| Dolma 3 Longmino Mix | 50B token | 长上下文训练 | 65K context |
三个关键工程决策：
① 质量上采样（Quality Upsampling）。 高质量数据源在 mix 中被赋予更高的采样权重——高质量数据被看到多次，低质量数据只看一次。这是一个比”过滤掉低质量数据”更精细的策略：不丢弃任何数据，而是通过采样频率来反映质量差异。
② 能力导向的中训练数据。 Dolmino Mix 明确瞄准 5 个能力维度——数学、代码、QA、指令遵循、思维链。这与 Vol.12 讨论的 CPT 方法论高度一致：中训练不是”更多的预训练”，而是有靶向的能力注入。
③ 长上下文专项数据。 单独构建 50B 的长上下文数据集（Longmino Mix），而不是简单地在预训练数据上拉长序列。这意味着长上下文能力需要专门的数据工程——随机截取长文档是不够的。
完全可复现：Dolma 3 的全部数据构建流程（代码 + 配置）以 Apache-2.0 开源，这在万亿级数据集中极为罕见。
三、管线步骤的优先级：哪些步骤最值得投入？
3.1 “Data, Data Everywhere” 的消融实验
“Data, Data Everywhere: A Guide for Pretraining Dataset Construction” (NVIDIA / EMNLP 2024 Oral)
这篇论文是预训练数据管线的”缺失手册”——它首次对管线的每个步骤进行了系统性消融实验，量化了各步骤对下游性能的贡献。
核心发现：不是所有步骤都同等重要
管线步骤的 ROI 排序（从消融实验推断）：
投入产出比
↑
│ ★★★★★ 质量过滤（模型分类器）
│ → 对下游性能影响最大
│ → 投入：训练一个分类器（几天）
│ → 收益：MMLU 等基准大幅提升
│
│ ★★★★ 去重
│ → 跨文档去重对训练稳定性至关重要
│ → 投入：计算密集但工具成熟
│ → 收益：减少记忆化，提升泛化
│
│ ★★★ 文本提取质量
│ → 从 HTML 中提取干净文本
│ → 差的提取器会引入大量噪声
│ → 投入：选对工具即可
│
│ ★★ 启发式过滤
│ → 文档长度、特殊字符、重复度等规则
│ → 边际收益递减——加太多规则反而误杀
│
│ ★ 高级后处理（PII 移除等）
│ → 对安全必要，但对性能影响有限
│
└─────────────────────────────→ 工程复杂度论文还引入了四维属性标注来精炼数据：
| 属性维度 | 作用 |
|---|---|
| 毒性（Toxicity） | 识别和移除有害内容 |
| 质量（Quality） | 区分高质量和低质量文档 |
| 语言类型（Type of Speech） | 文本体裁/语体分类 |
| 领域（Domain） | 主题/知识领域标注 |
3.2 五大管线的工程共识
纵观 Nemotron-CC、FineWeb2、Dolma 3、DCLM 和 DataFlow 的管线设计，有几个跨框架的工程共识正在形成：
共识 1：模型分类器 > 启发式规则
所有顶级管线都在从”规则过滤”转向”模型过滤”。FineWeb-Edu 用 fastText 教育质量分类器，DCLM 用 fastText 质量分类器，Nemotron-CC 用分类器集成。原因很简单：启发式规则的天花板是”不犯明显错误”，而模型分类器可以学到更细粒度的质量信号。
共识 2：不要过度过滤
FineWeb-Edu 和 DCLM 都过滤掉了 90%+ 的数据，这在短 horizon 训练中表现优异，但在长 horizon 训练中导致数据多样性不足。Nemotron-CC 的”分类器集成 + 合成回收”范式（留存率显著更高）在 15T token 训练中超越了这两者。
共识 3：去重是非可选步骤
每个顶级管线都包含去重，且去重对训练稳定性的影响被反复验证（Vol.10 详细讨论过）。分歧在于去重粒度——文档级 MinHash 是共识，子串级和语义级是否值得额外计算成本仍有争论。
共识 4：管线必须可复现
FineWeb2 和 Dolma 3 都全量开源了管线代码和配置，DCLM 提供了标准化的提交接口。管线的可复现性不再是”加分项”，而是”准入条件”——你无法在不可复现的管线上做严肃的消融实验。
四、NeMo Curator 1.1：多模态数据管护的工程细节
值得单独展开讨论的是 NeMo Curator 的最新版本（v1.1，2026 年 2 月），因为它是目前唯一支持四模态数据管护的框架，且在工程化水平上远超其他选项。
4.1 GPU 加速的实际收益
| 指标 | 数值 | 对比基线 |
|---|---|---|
| 模糊去重速度 | 16 倍 | CPU 方案 |
| 总拥有成本 | 降低 40% | CPU 方案 |
| 扩展性（1→4 H100 节点） | 2.05h → 0.50h | 近线性扩展 |
| 测试数据集 | 8TB RedPajama v2 (1.78T token) | — |
这些数字的工程含义：在 CPU 上跑 MinHash 去重一个 10T token 的数据集可能需要几天到一周。用 NeMo Curator + 4 个 H100 节点，几小时就能完成。对于需要快速迭代管线参数的团队，这个差异是质的变化。
4.2 四模态处理能力
NeMo Curator 1.1 四模态管线：
📝 文本模态：
├── 30+ 启发式过滤器（文档长度/重复度/特殊字符/...）
├── GPU 加速分类器（领域/质量/安全/内容类型）
├── 语言检测（fastText + GPU 推理）
├── 三级去重（精确/MinHash 模糊/语义去重）
├── PII 检测与移除
└── Nemotron-CC 合成数据管线（改写/摘要/提取）
🖼️ 图像模态：
├── 美学评分过滤
├── NSFW 内容检测
├── CLIP 嵌入生成
└── 图像去重
🎬 视频模态：
├── TransNetV2 场景检测
├── 片段提取与运动过滤
├── GPU H.264 编码
└── Cosmos-Embed1 嵌入 + 去重
🔊 音频模态：
├── ASR 自动转录
├── WER 质量评估
├── 时长分析
└── 质量过滤对实践的启示：
如果你的团队正在从文本预训练扩展到多模态预训练（Vol.19 详细讨论了多模态数据工程的挑战），NeMo Curator 是目前唯一能在单一框架内处理文本、图像、视频和音频的选择。其他框架（datatrove、Dolma Toolkit）专注于文本模态，多模态数据需要自己搭建管线。
五、DataFlow：LLM 驱动的管线自动化
5.1 新范式：用自然语言描述管线
“DataFlow: An LLM-Driven Framework for Unified Data Preparation” (北大 DCAI 团队 / 2025)
DataFlow 代表了一种不同于前四个框架的设计哲学：不是让人写代码搭管线，而是让 LLM 理解你的需求后自动搭建。
核心机制——DataFlow-Agent 的三步自动化：
- 算子合成（Operator Synthesis）：根据自然语言描述，自动选择或生成合适的数据处理算子
- 流水线规划（Pipeline Planning）：将选定的算子组合成完整的管线
- 迭代验证（Iterative Verification）：在样本数据上运行管线，评估输出质量，必要时回退修正
5.2 惊人的数据效率
DataFlow 最引人注目的实验结果：
| 对比 | 数据量 | 性能 |
|---|---|---|
| DataFlow 生成 | 10K 样本 | 基础模型超越 1M 对照 |
| Infinity-Instruct | 1M 样本 | 基线 |
10K 样本超越 100 万样本——这意味着 DataFlow 的数据准备质量极高，每一条数据的信息密度远超批量采集的数据。
5.3 定位差异
需要明确的是，DataFlow 的主要定位与其他四个框架不同：
| 维度 | datatrove / NeMo Curator / Dolma | DataFlow |
|---|---|---|
| 主要用途 | 预训练数据策展 | SFT/指令数据准备 |
| 数据来源 | Common Crawl 等网页爬取 | LLM 合成 + 清洗 |
| 规模 | 万亿 token | 万~百万条 |
| 管线构建方式 | 代码 / CLI | 自然语言 + Agent |
DataFlow 不是 datatrove 的替代品——它们解决不同阶段的问题。但 DataFlow 的 LLM 驱动管线自动化思路，与 Vol.21 讨论的 DataEvolve 的 AI 自主进化策展策略，共同指向一个趋势：数据管线的设计和优化正在从人工走向自动化。
本期思考
回顾本期讨论的五大框架和三条生产管线，一个宏观认知正在清晰化：预训练数据管线正在从”研究副产品”升级为”独立工程学科”。
第一，工具标准化消除了基础门槛。 两年前，搭建一条万亿 token 级数据管线需要几个月的工程开发。今天，用 datatrove 或 NeMo Curator，一周内就能搭建起可用的管线——FineWeb 和 Nemotron-CC 的管线代码都是开源的，可以直接复用。竞争的焦点从”能不能搭管线”转移到了”管线的每个参数是否最优”。
第二，“Data, Data Everywhere” 的消融实验给出了明确的优先级。 如果你只有有限的工程资源：先投入模型分类器做质量过滤（ROI 最高），再做去重（非可选），然后是文本提取质量。启发式过滤和高级后处理的边际收益较低——不要在这里过度投入。
第三，过度过滤正在被修正。 FineWeb-Edu/DCLM 的”丢弃 90%“范式在短 horizon 训练中有效，但 Nemotron-CC 的”分类器集成 + 合成回收”范式证明了：保留更多数据 + 改写中低质量数据，在长 horizon 训练中表现更好。这对正在规划数据管线的团队是一个重要信号——不要盲目追求过滤率。
第四，多模态是下一个战场。 NeMo Curator 1.1 是目前唯一的多模态数据管护框架。随着多模态预训练成为主流（Vol.19），图像/视频/音频数据的策展工具需求会快速增长。这是一个明显的基础设施空白。
给数据工程团队的行动清单：
- 本周可做：评估你当前的数据管线用了什么工具。如果还在用一次性脚本，选择一个框架迁移——datatrove（最灵活）或 NeMo Curator（最强性能）
- 本月可做：在你的管线中加入模型分类器做质量过滤。从 fastText 开始——FineWeb-Edu 的分类器是开源的，可以直接用或在此基础上微调
- 本季度规划：评估 Nemotron-CC 的”合成回收”策略是否适用于你的场景。克隆 NeMo Curator 仓库，在你的中低质量数据上测试 LLM 改写 + 重新过滤的效果
- 长期关注：多模态数据管线工具的演进。如果你的 roadmap 包含 VLM 或多模态模型训练，现在就开始评估 NeMo Curator 的图像/视频管线模块
下期预告：代码数据的策展方法论——当预训练语料中代码占比越来越大，代码数据的质量评估、去重、安全审计和配比优化有哪些独特挑战？