万亿 Token 级数据管线的工程全景：从 Common Crawl 到训练就绪，Nemotron-CC、FinePhrase 与 Apple 配比定律的实践启示
系统解读构建万亿 token 级预训练数据集的完整工程链条——从 Nemotron-CC 的三阶段管线（提取-分级-合成）到 FinePhrase 的 90 组消融实验得出的合成数据最佳配方，从 TxT360 的全局去重工程到 Apple 的数据配比 Scaling Laws，以及 Nemotron-CC-Math 的数学内容提取新范式
本期主题：从原始网页到训练就绪——万亿 Token 级数据管线的工程实践
前 16 期我们系统讨论了预训练数据工程的各个环节——去重、选择、配比、评估、合成数据、治理。但这些技术被拆解成独立模块讨论时，一个关键问题被隐藏了：在万亿 token 的真实规模下，这些模块是怎么串联成一条完整管线的？
这不是一个学术问题。当你面对 Common Crawl 的 99 个快照（每个快照 ~200TB 压缩 HTML）时，“先去重再过滤再评分”这种教科书式的描述完全不够——你需要回答：HTML 怎么转文本？哪种解析器最好？去重是按快照内还是跨快照全局做？质量分类器怎么选？合成数据怎么嵌入管线？最终的域配比怎么定？
2025-2026 年的一个重要转变是：多个团队开始完整地公开他们的万亿级数据管线——不只是发布数据集，而是发布整条管线的工程细节和消融实验。
万亿 Token 级数据管线的工程拓扑：
原始 HTML 训练就绪数据
│ ▲
▼ │
┌─────────────────────────────────────────────────────────┐
│ Stage 1 提取与清洗 │
│ HTML → 文本提取（jusText / trafilatura / Lynx） │
│ → 语言检测（fastText lid） │
│ → Unicode 规范化 + 编码修复 │
│ → 启发式过滤（28+ 规则） │
│ → 困惑度过滤（KenLM） │
├─────────────────────────────────────────────────────────┤
│ Stage 2 去重 │
│ 精确去重（文档级 hash） │
│ → 模糊去重（MinHash + LSH，Jaccard 相似度） │
│ → 可选：跨快照全局去重（TxT360 路线） │
├─────────────────────────────────────────────────────────┤
│ Stage 3 质量分级 │
│ 多分类器集成（fastText + DeBERTa + LLM-based） │
│ → 分数融合 → 质量分桶（High / Medium-High / Medium） │
├─────────────────────────────────────────────────────────┤
│ Stage 4 数据增强与合成 │
│ 高质量数据 → 改写 / QA / 知识提取 / 翻译 │
│ 低质量数据 → Wiki 风格重写，回收有用信息 │
├─────────────────────────────────────────────────────────┤
│ Stage 5 配比与打包 │
│ 域权重优化（Scaling Laws / 代理实验） │
│ → Tokenization → Sequence packing → 训练就绪 │
└─────────────────────────────────────────────────────────┘本期从三个维度全面解读这条管线：工程实现（各环节的最佳实践和工具选型）、消融验证（每个环节的决策有多少实验支撑）、规模挑战（从 TB 到 PB 级别的工程瓶颈和解法）。
一、Nemotron-CC：万亿级数据管线的工业参考实现
1.1 从论文到工程的完整公开
Nemotron-CC: Transforming Common Crawl into a Refined Long-Horizon Pretraining Dataset (NVIDIA / ACL 2025)
Nemotron-CC 是目前公开最完整的万亿级数据管线工程案例。NVIDIA 不仅发布了 6.3T token 的数据集，还将整条管线开源到 NeMo Curator 仓库中——从 HTML 提取到合成数据生成的每一步都可以复现。
为什么说它是”工业参考实现”？
| 维度 | Nemotron-CC | 对比 FineWeb / DCLM |
|---|---|---|
| 规模 | 6.3T tokens（含 2T 合成） | FineWeb 15T / DCLM ~3T |
| 管线阶段 | 3 阶段：提取→分级→合成 | 通常 2 阶段：提取→过滤 |
| 质量分类 | 多分类器集成（3 个） | 单一分类器 |
| 数据恢复 | ✅ 用合成重写回收低质量数据 | ❌ 丢弃即丢弃 |
| 管线开源 | ✅ 完整代码 + 配置 | 部分开源 |
| 训练验证 | Llama 3.1 8B 15T token | 较小规模验证 |
关键创新——“不只是过滤，而是回收”：传统数据管线的逻辑是”过滤掉坏数据，保留好数据”。但 Nemotron-CC 的实验表明，激进过滤会丢失 90% 的数据——这对需要 15T token 的长视距训练是不可接受的。Nemotron-CC 的第三阶段（合成数据生成）的核心目的不是”生成新数据”，而是回收被过滤掉的数据中的有用信息。
1.2 三阶段管线的工程细节
Stage 1：提取与启发式过滤
Nemotron-CC Stage 1 处理流程：
Common Crawl WARC 文件
│
▼
jusText HTML→文本提取
│ ← 为什么选 jusText？
│ 比 trafilatura 快，比 readability 准确度高
│ 在 boilerplate 去除上表现最优
│
▼
fastText 语言检测 → 保留英语
│
▼
Unicode 规范化 + 格式化字符修复
│
▼
28 种启发式过滤器：
├── 非字母数字内容比例 > 阈值 → 丢弃
├── URL 密度过高 → 丢弃（广告/导航页）
├── 空白不一致 → 丢弃（OCR 残留）
├── N-gram 重复率 → 丢弃（模板化内容）
├── 数值比例过高 → 丢弃（数据表/日志）
└── ... 其他 23 种规则
│
▼
KenLM 困惑度过滤
│ ← 困惑度范围：保留中间段
│ 过低 = 重复/模板；过高 = 乱码/非自然文本
│
▼
精确去重（文档级 SHA-256 hash）
│
▼
模糊去重（MinHash + LSH, Jaccard > 0.8）
│ ← NVIDIA RAPIDS 加速：比纯 CPU 快 16×
│
▼
Stage 1 输出：清洁文本语料28 种启发式过滤器这个数字值得注意。这不是拍脑袋的 5-6 条规则，而是经过大量消融实验筛选出的规则集。每条规则都有明确的阈值和验证数据。
Stage 2：质量分级——多分类器集成
这是 Nemotron-CC 管线最有工程借鉴价值的环节。他们没有用单一的质量分类器，而是使用了三个分类器的集成：
| 分类器 | 类型 | 训练数据 | 偏好 |
|---|---|---|---|
| FastText Quality | fastText | 自标注 | 通用文本质量 |
| FineWeb Mixtral Edu | DeBERTa | Mixtral 标注 | 教育价值 |
| FineWeb Nemotron-4 Edu | DeBERTa | Nemotron-4 标注 | 教育价值（不同分布） |
集成策略：每个分类器输出 0-5 分 → 映射为 0-19 的整数类别 → 取三个分类器的最大值作为最终分数。
为什么取最大值而不是平均值？
这个设计选择的直觉是：不同分类器有不同的”视野”。一段代码可能在教育价值分类器上得分低，但在通用质量分类器上得分高——取最大值意味着只要有一个分类器认为这条数据有价值，就保留它。这与 Vol.15 讨论的 FIRE 框架的”木桶效应”（取最小值）正好相反，代表了一种更激进的数据保留策略——而这正是长视距训练所需要的。
最终语料被分为五个质量级别，供下一步差异化处理。
Stage 3：合成数据生成——回收而非丢弃
Nemotron-CC 的合成数据生成策略：
对低质量数据（质量分 < 阈值）：
┌──────────────────────────────────┐
│ Wiki 风格重写 │
│ Prompt: "将以下文本重写为维基百科 │
│ 风格的清晰、结构化的文章" │
│ → 回收有用信息，丢弃噪声 │
└──────────────────────────────────┘
对高质量数据（质量分 > 阈值）：
┌──────────────────────────────────┐
│ 四种增强方式并行： │
│ │
│ 1. 多样化 QA 对 │
│ 是/否 + 多选 + 开放式问题 │
│ │
│ 2. 蒸馏 │
│ 将文本压缩为简洁清晰的段落 │
│ │
│ 3. 知识提取 │
│ 重写核心知识，忽略无信息内容 │
│ │
│ 4. 知识列表 │
│ 将关键信息提取为结构化列表 │
└──────────────────────────────────┘
合成数据规模：~2T tokens
→ 原始 4.4T + 合成 2T = 总计 6.3T tokens核心结果（Llama 3.1 8B，1T token 训练）：
| 数据集 | MMLU 得分 |
|---|---|
| FineWeb-Edu | 42.9 |
| DCLM | 53.4 |
| Nemotron-CC | 59.0 |
在 15T token 的长视距训练中（包含 7.2T Nemotron-CC 数据），MMLU 达到 70.3，比原始 Llama 3.1 的 65.3 提升了 5 个百分点。
对实践的启示：Nemotron-CC 的核心工程教训是——过滤不是目的，获取最大量的高质量训练信号才是目的。如果你的训练预算需要 10T+ token，单靠过滤无法提供足够的数据。三阶段管线（提取→分级→合成回收）是目前最成熟的万亿级数据管线架构。质量分类器的集成策略（多分类器取最大值）值得直接借鉴。
1.3 Nemotron-CC 的扩展：v2.1 与垂域数据
NVIDIA 在 Nemotron-CC 基础上持续扩展，截至 2025 年底已发展为一个完整的数据集家族：
| 数据集 | 规模 | 内容 |
|---|---|---|
| Nemotron-CC v1 | 6.3T tokens | 原始 + 合成英文 |
| Nemotron-CC v2 | 6.6T tokens | 更新快照 + 扩展合成 |
| Nemotron-CC v2.1 | 2.5T tokens | 新增翻译+QA+合成重写 |
| Nemotron-CC-Code v1 | 428B tokens | CC 代码页面提取 |
| Nemotron-CC-Math v1 | 133B tokens | CC 数学内容提取 |
Nemotron-CC-Math 尤其值得关注。它解决了一个长期困扰数据工程的难题：如何从嘈杂的网页 HTML 中可靠地提取数学公式？
传统方法依赖 DOM 解析来提取 MathJax/KaTeX 标签，但这种方法极其脆弱——不同网站的 HTML 结构千差万别，解析器经常漏掉公式或提取出乱码。Nemotron-CC-Math 的解法是用 Lynx（一个纯文本浏览器）渲染网页，然后从渲染结果中提取数学内容，再用轻量 LLM（Phi-4）将其标准化为 LaTeX。
传统 DOM 解析：
HTML → 正则/XPath 匹配 <math> <span class="MathJax"> 标签
→ 问题：格式五花八门，覆盖率低
→ "MathML" "KaTeX" "MathJax" "纯 Unicode 公式" 各需不同规则
Nemotron-CC-Math 的方法：
HTML → Lynx 渲染为纯文本
→ 渲染结果保留了布局信息和数学结构
→ Phi-4 清洗 + LaTeX 标准化
→ 得到统一格式的数学文本
结果：
Nemotron-CC-Math-4+：52B tokens
→ 质量超越 FineMath-4+、OpenWebMath
→ 规模是 FineMath-4+ 的 5.5×
→ 在 Nemotron-T 8B 上：MATH +12.6, MBPP+ +14.3对实践的启示：如果你在构建需要数学/科学内容的训练数据，放弃正则表达式和 DOM 解析。Lynx 渲染 + LLM 清洗的管线虽然推理成本更高，但覆盖率和准确率的提升远超成本增加。这个思路可以推广到所有”结构化内容嵌入在 HTML 中”的场景——代码片段、表格、化学公式。
二、FinePhrase：90 组实验磨出的合成数据最佳配方
2.1 HuggingFace 的大规模消融
The Synthetic Data Playbook: Generating Trillions of the Finest Tokens (HuggingFace FineData Team / 2026)
如果说 Nemotron-CC 是”工业管线的参考实现”，FinePhrase 则是”合成数据配方的系统性消融实验”。HuggingFace 的 FineData 团队投入了 12.7 GPU 年，跑了 90 组实验，生成了超过 1 万亿 token，最终产出了 FinePhrase——一个 486B token 的合成预训练数据集。
为什么需要 90 组实验？
合成数据用于预训练有太多超参数需要调：
合成数据的超参数空间：
1. 种子数据来源
FineWeb 原始文本？FineWeb-Edu 子集？高质量过滤后的子集？
2. 合成方法
改写（Rephrasing）？知识蒸馏？QA 生成？教科书风格？
3. 生成模型
7B？13B？70B？API 模型？指令模型？基础模型？
4. 生成参数
Temperature？Top-p？Max length？Prompt 模板？
5. 混合比例
合成数据占总数据的比例？
不同类型合成数据之间的比例？
6. 后处理
对合成输出做质量过滤？多样性过滤？去重？
假设每个维度 3 个选项 → 组合空间 3^6 = 729
实际需要结构化消融来缩小搜索空间FinePhrase 的核心发现：
经过 90 组实验的系统性消融，FinePhrase 团队得出了几个关键的工程结论——这些结论与 Vol.16 讨论的学术研究形成了工程层面的相互验证：
| 发现 | FinePhrase 实验验证 | 对应学术工作 |
|---|---|---|
| 改写优于从零生成 | 改写（Rephrasing）类合成数据在所有设定下优于教科书/QA 类 | Meta FAIR (Vol.16) |
| 种子数据质量决定上限 | 用高质量子集做种子，生成的合成数据效果显著优于用全集 | Ultra-FineWeb 验证策略 |
| 合成数据有明确的”甜蜜点” | 486B token 是在质量和数量之间的最优平衡 | SynthLLM 300B 天花板 (Vol.16) |
| 后处理过滤不可省略 | 对合成输出做质量过滤，效果显著优于不过滤 | 自验证 (NeurIPS 2025) |
486B token 的最终数据集表现”明显优于”（原文：clearly outperforms）等规模的纯自然数据，这为合成数据用于预训练提供了目前最大规模的正面工程证据。
对实践的启示：FinePhrase 的价值不在于数据集本身（虽然数据集也很有用），而在于 90 组实验给出的”配方”。如果你要在自己的管线中加入合成数据：(1) 先用高质量子集做种子，不要直接用全集；(2) 改写（Rephrasing）是默认最安全的合成方法；(3) 合成数据的规模不是越大越好——投入资源做质量过滤比增加生成量的 ROI 更高；(4) 12.7 GPU 年的消融成本看似巨大，但考虑到它能指导数十万 GPU 时的预训练，这个投入完全值得。
三、TxT360：全局去重的工程挑战
3.1 为什么”跨快照全局去重”很难
TxT360: Trillion eXtracted Text (LLM360 / 2024-2025)
去重是数据管线中看似简单但实则最具工程挑战的环节。大多数数据集（包括 FineWeb）只在单个 Common Crawl 快照内做去重。TxT360 做了一件更彻底的事：跨 99 个 Common Crawl 快照 + 14 个外部数据源进行全局去重。
为什么要全局去重？
Common Crawl 快照间的重复情况：
快照 A (2023-09)： 文档 1, 2, 3, 4, 5, 6 ...
快照 B (2023-14)： 文档 1, 2, 3, 7, 8, 9 ... ← 1,2,3 是重复的
快照 C (2023-23)： 文档 1, 2, 10, 11, 12 ... ← 1,2 又重复了
...
快照 ZZ (2025-26)：文档 1, 500, 501, ... ← 1 跨了 99 个快照
如果只在每个快照内去重：
→ 文档 1 出现了 99 次
→ 训练时这些重复文档会被过度采样
→ 浪费计算资源 + 潜在的过拟合风险
全局去重后：
→ 文档 1 只保留一次
→ 训练数据更高效、分布更合理工程挑战：
99 个 CC 快照的去重不是简单地把所有文档放在一起跑 MinHash。数据量太大——数十亿文档级别——传统的 MinHash LSH 需要巨大的内存和计算资源。
TxT360 的解法是分层处理：
- 快照内精确去重：每个快照独立做文档级 hash 去重
- 跨快照 URL 去重：同一 URL 的不同快照版本只保留最新的
- 跨快照模糊去重：用 MinHash 做跨快照的近似重复检测
- 跨源去重：检查 CC 数据与 14 个外部源（FreeLaw、PG-19、StackExchange 等）的重叠
结果：TxT360 最终产出了约 15T token 的全局去重数据集。在下游实验中，全局去重数据训练的模型性能优于 FineWeb 和 RedPajama。
对实践的启示：如果你的训练数据跨越多个 CC 快照（这在长视距训练中是常见需求），跨快照去重不是可选项。不做全局去重意味着你的训练数据中有大量隐性重复，这会浪费宝贵的训练步数。TxT360 的分层去重策略（精确→URL→模糊→跨源）是工程上最可行的方案。如果全局去重的计算资源太高，至少做 URL 级别的跨快照去重——这是性价比最高的第一步。
四、Apple 数据配比 Scaling Laws：给数据混合一个数学公式
4.1 从试错到预测
Scaling Laws for Optimal Data Mixtures (Apple + 索邦大学 / NeurIPS 2025)
来自 Mustafa Shukor, Louis Bethune, Dan Busbridge, David Grangier, Enrico Fini, Alaaeldin El-Nouby, Pierre Ablin
当数据管线的前几个阶段（提取、去重、分级、合成）完成后，最后一个关键决策是：各域数据的混合比例怎么定？
Vol.4 讨论过复旦 Moss 团队的 Data Mixing Laws，但那项工作的预测对象仅限于 LLM。Apple 的这篇 NeurIPS 2025 论文将数据配比 Scaling Laws 扩展到了三种基础模型，证明了同一套数学框架的普适性。
核心公式：
给定：
N = 模型参数量
D = 训练 token 数
h = (h₁, h₂, ..., hₖ) 域权重向量（各域数据的比例）
预测模型的验证损失：
L(N, D, h) = f(N, D) × g(h) + L_∞
其中：
f(N, D) 是经典 Scaling Law（Chinchilla 风格）
g(h) 是配比函数，捕捉不同域数据比例对性能的影响
L_∞ 是不可约损失
关键性质：
1. f 和 g 可分离 → 可以独立估算
2. g(h) 对 h 可微 → 可以用梯度方法优化
3. 参数估计只需少量小规模实验三种基础模型上的验证：
| 模型类型 | 训练数据 | 域数量 | 预测误差 |
|---|---|---|---|
| LLM（语言模型） | 文本 | ~10 域 | < 2% |
| NMM（原生多模态） | 文本+图像+视频 | ~5 域 | < 3% |
| LVM（大视觉编码器） | 图像 | ~8 域 | < 2.5% |
最重要的工程含义：你可以用 3-5 次小规模实验（每次用总预算的 1-5%）来估计公式参数，然后在不做大规模训练的情况下预测什么样的配比最优。
传统配比优化（试错法）：
配比 A → 训练 7B 模型 → 评估 → 不够好
配比 B → 训练 7B 模型 → 评估 → 稍好
配比 C → 训练 7B 模型 → 评估 → 还行
→ 成本 ≈ 3× 完整训练
Apple 配比 Scaling Laws：
3-5 次小实验 → 估计公式参数
→ 用公式预测所有可能配比的效果
→ 选最优配比 → 一次大规模训练
→ 成本 ≈ 0.15× 完整训练 + 1× 完整训练 = 1.15×
省时省力比：≈ 2.6×与 Vol.4 Data Mixing Laws 的对比：
| 维度 | Data Mixing Laws (复旦) | Apple Scaling Laws |
|---|---|---|
| 适用模型 | 仅 LLM | LLM + NMM + LVM |
| 变量 | 数据配比 | 配比 × 模型规模 × 数据量 |
| 外推能力 | 同规模内推 | 跨规模外推 |
| 验证规模 | ~7B | 多规模多模态 |
对实践的启示：如果你还在用”跑几组实验比较一下”的方式选数据配比，这篇论文提供了一个更系统化的替代方案。核心流程：(1) 定义你的域划分（如 web/code/academic/book）；(2) 跑 3-5 次小规模实验，每次用不同配比；(3) 拟合 Scaling Law 公式的参数；(4) 用公式预测最优配比。这个流程的投入很低，但可以避免”拍脑袋选配比导致整轮训练浪费”的风险。
五、数据管线工具生态：2026 年的格局
构建万亿级数据管线不可能从零开始。2025-2026 年，工具生态已经足够成熟，大部分环节都有现成的高质量工具：
| 环节 | 工具 | 维护方 | 核心优势 | 适用场景 |
|---|---|---|---|---|
| HTML 提取 | jusText | 社区 | 快速，boilerplate 去除好 | 通用网页 |
| trafilatura | 社区 | 支持格式多，覆盖广 | 需要保留更多结构 | |
| Lynx 渲染 | GNU | 布局感知，数学/代码保留 | 科学/技术页面 | |
| 去重 | MinHash (datasketch) | 社区 | 纯 Python，部署简单 | 中小规模 |
| RAPIDS cuML MinHash | NVIDIA | GPU 加速，16× 加速 | 大规模 | |
| Milvus MinHash LSH | Zilliz | 向量数据库集成 | 增量去重 | |
| 质量过滤 | NeMo Curator | NVIDIA | GPU 加速全流程 | GPU 资源充足 |
| datatrove | HuggingFace | 声明式管线 | HF 生态集成 | |
| fastText 分类器 | 社区 | CPU 可运行，~100K doc/s | 大规模粗筛 | |
| 合成生成 | Nemotron-CC SDG | NVIDIA | 4 种生成模式 | 工业规模合成 |
| FinePhrase pipeline | HuggingFace | 消融验证的配方 | 研究/中等规模 | |
| 全流程 | Dolma toolkit | Allen AI | 3T token 验证 | OLMo 生态 |
| NeMo Curator | NVIDIA | 文本/图像/视频/音频 | 多模态管线 |
工具选型建议：
资源有限的研究团队（< 100 GPU）：
datatrove + fastText 分类器 + datasketch MinHash
→ 优点：纯 CPU/少量 GPU，成本低，HF 生态无缝对接
→ 局限：大规模去重性能受限
中等规模（100-1000 GPU）：
NeMo Curator（GPU 加速） + FinePhrase 合成配方
→ 优点：端到端 GPU 加速，去重/过滤/合成一站式
→ 局限：需要 NVIDIA GPU 和 RAPIDS 环境
工业规模（1000+ GPU）：
NeMo Curator + 定制化合成管线 + 全局去重
→ 优点：可扩展到 PB 级，Nemotron-CC 级别的完整管线
→ 需要：多节点 Dask 集群，专业运维特别推荐：datatrove v0.5.0 的更新值得关注。它新增了分布式执行支持、改进的分词处理和去重性能优化，正在快速缩小与 NeMo Curator 的差距——而且不需要 NVIDIA GPU。
六、全景视图：万亿 Token 级数据管线的工程决策树
万亿 Token 数据管线的关键决策点：
Q1: 你需要多少 token？
├── < 1T token → 标准过滤管线即可（FineWeb 路线）
└── > 1T token → 需要合成数据回收（Nemotron-CC 路线）
│
Q2: 你的 CC 快照数量？
├── 单个快照 → 快照内去重即可
└── 多个快照 → 需要跨快照去重（TxT360 路线）
│ 至少做 URL 级去重
│
Q3: 你需要数学/代码内容吗？
├── 否 → 标准 jusText 提取
└── 是 → Lynx 渲染 + LLM 清洗（Nemotron-CC-Math 路线）
│
Q4: 质量分类器选什么？
├── 预算有限 → 单个 fastText（~100K doc/s）
└── 预算充足 → 多分类器集成（fastText + DeBERTa + LLM）
│ 取最大值融合（Nemotron-CC 策略）
│
Q5: 合成数据加不加？
├── 否（数据够用） → 跳过 Stage 3
└── 是（需要更多高质量数据）
│ → 改写为主（FinePhrase 验证）
│ → 高质量种子（不用全集做输入）
│ → 后处理过滤（不能跳过）
│ → 比例 ≤ 30%（Meta FAIR 结论）
│
Q6: 域配比怎么定？
├── 快速粗估 → 参考 Llama/Nemotron 公开的配比
└── 精确优化 → Apple Scaling Laws（3-5 次小实验 → 公式预测）本期思考
回顾本期解读的五项重要工作，一个核心观察浮现：预训练数据工程正在从”学术论文中的单点优化”走向”可复现的端到端工程系统”。
三个趋势值得关注：
第一，“过滤”正在被”回收”取代。 Nemotron-CC 的三阶段管线代表了一个范式转变——传统管线的目标是”从噪声中筛选出信号”，新范式的目标是”从噪声中提取并增强信号”。当你需要 15T token 时，激进过滤丢失的 90% 数据不是”垃圾”，而是”未被开发的矿藏”。合成数据生成的角色从”凭空创造”变成了”精炼回收”。
第二，消融实验正在取代经验法则。 FinePhrase 的 90 组实验、Apple 的 Scaling Laws、Nemotron-CC 的 28 种过滤规则——这些数字背后是一个共识：数据管线的每个决策都应该有实验支撑。“别人用了这个参数效果不错”不再是充分的理由。好消息是，消融实验的成本正在下降——用 1B 参数的代理模型做 1-2 天的验证实验，就可以指导 70B 模型的万亿 token 训练。
第三，工具生态的成熟降低了门槛。 两年前构建万亿级管线需要从零开发大部分组件。现在，NeMo Curator 提供了 GPU 加速的全流程工具，datatrove 提供了轻量但灵活的替代方案，Dolma 提供了经过 3T token 验证的工具包。“构建自己的数据管线”不再是只有 Google/Meta 才能做的事。
给数据工程团队的行动清单：
- 今天就做：审视你的管线架构——是不是还在用”过滤→训练”的两阶段模式？如果数据量不够用，考虑加入合成数据回收阶段
- 本周可做：评估跨快照去重的必要性。如果你用了多个 CC 快照，至少做 URL 级别的跨快照去重
- 本月可做：搭建代理模型验证框架——用 1B 模型 + 少量 token 快速验证管线中每个环节的决策（过滤阈值、分类器选型、合成配比）
- 本季度规划：评估是否从单一质量分类器升级到多分类器集成；是否引入 Apple Scaling Laws 来优化域配比
下期预告：持续预训练与领域适应——当通用预训练完成后，如何高效地将模型适配到垂直领域（代码、医疗、金融），数据策略有何不同