从文本到像素：原生多模态训练数据工程的八个关键差异与五个掘金方向

综合调研 / 2026-04-01 面向已有纯文本 LLM 训练经验的数据工程师，拆解多模态带来的增量复杂度

---

前言：问题的出发点

做过 LLM 预训练数据的人都知道那条路有多长——Common Crawl 清洗、语言识别、去重、质量打分、配比调整。但当任务从”训一个语言模型”变成”训一个能看图、能生图、能听懂语音、能理解视频的原生多模态模型”时，数据工程的复杂度不是线性增长，而是出现了结构性变化。

纯文本数据处理的核心目标可以用一个词概括：去噪。多模态数据处理的核心目标需要三个词：去噪、对齐、融合。

这篇文章做三件事：

1. 盘点 GitHub / HuggingFace 上主流的带图片多模态数据集
2. 系统拆解多模态 vs 纯文本在数据工程上的八个关键差异
3. 识别五个有实操价值的数据挖掘方向

---

一、数据全景：GitHub 上有哪些带图片的多模态训练数据

1.1 图文配对数据集（Image-Text Pairs）

数据集	规模	来源	特点	开放状态
LAION-5B	58.5 亿对	Common Crawl	最大公开图文对，含 CLIP 分数和美学评分元数据	元数据开放，图片需自行下载
LAION-400M	4 亿对	Common Crawl	LAION-5B 的英文子集	同上
DataComp-1B	12.8 亿对	Common Crawl	NeurIPS 2023 benchmark，提供候选池 + 过滤竞赛框架	完全开放
COYO-700M	7.47 亿对	Common Crawl	Kakao Brain 发布，含丰富元属性（美学/水印/NSFW 分数）	完全开放
CC-12M / CC-3M	1200 万 / 330 万	Google 概念字幕	小规模高质量基准线	URL + 标题开放
SBU Captions	100 万	Flickr	早期经典，自然语言描述	完全开放
WIT	1150 万	Wikipedia	多语言维基百科图文，37 种语言	完全开放

1.2 交错图文数据集（Interleaved Image-Text）

数据集	规模	特点	开放状态
OmniCorpus	86 亿图 + 330 亿文档	迄今最大多模态语料，保留 DOM 结构	开放
OBELICS	1.41 亿网页，3.53 亿图	HuggingFace 发布，保留网页上下文结构	完全开放
MMC4	7.15 亿图 + 1.01 亿文档	基于 C4 扩展，句子级图文对齐	完全开放
MINT-1T	10 亿图 + 10T tokens	NeurIPS 2024，来自 HTML/PDF/arXiv	完全开放
CoMM	—	CVPR 2025，强调叙事连贯性和实体一致性	开放

1.3 视觉指令微调数据（Visual Instruction Tuning）

数据集	规模	特点
LLaVA-Instruct-150K	15 万	GPT-4 生成的图像对话/描述/推理
ShareGPT4V	100K GPT4V + 1.2M 模型生成	高质量详细描述，覆盖 SFT + 对齐
ALLaVA	100 万+	覆盖 caption + VQA + 复杂推理
Cambrian-10M	1000 万	120 个来源聚合，覆盖 OCR/图表/医学等

1.4 专项多模态数据

类型	代表数据集	规模	说明
图表/文档	ChartQA, DocVQA, InfoVQA	数万~数十万	文档理解必备
OCR	TextOCR, ICDAR	数十万	场景文字识别
视频	WebVid-10M, InternVid	千万级	视频-文本对
音频-文本	LibriSpeech, GigaSpeech	千~万小时	语音理解和生成
3D	Objaverse	80 万 3D 物体	空间理解
科学图表	SciGraphQA, AI2D	数万	科学推理

1.5 小结：数据是充足的，问题在于怎么用

GitHub 和 HuggingFace 上的多模态数据规模已不是瓶颈。LAION-5B + OmniCorpus 的量级足以支撑大规模预训练。真正的挑战在于：

• 原始数据噪声极大（LAION-5B 有效高质量数据不足 10%）
• 不同数据范式（配对 vs 交错 vs 指令）需要不同处理管线
• 质量标准从”文本层面可读”升级到”图文语义一致”

---

二、八个关键差异：多模态 vs 纯文本数据工程

差异 1：数据获取从”下载文本”变成”分布式图片采集”

纯文本：拿到 Common Crawl 的 WARC/WET 文件后，核心工作是文本提取和清洗。数据基本是离线可得的，下载 → 解析 → 存储，管线简单。

多模态：原始数据通常只有 (URL, caption, metadata) 的元数据，图片需要从互联网实时下载。这带来三个工程问题：

1. 网络 I/O 成为主瓶颈：数十亿 URL 的下载耗时以周计，且面临 DNS 延迟、CDN 限速、失效链接（link rot）
2. 存储格式从文本文件变成 WebDataset：图片不能用 JSONL 存储，需要打包为 tar 归档（WebDataset 格式），避免文件系统 inode 耗尽
3. 需要专用工具链：img2dataset 是事实标准——基于 MapReduce 原理的分布式下载框架，支持异步 I/O + 流式归档

经验数字：LAION-5B 的完整图片下载（256px 分辨率），需要 ~100TB 存储，约 2-4 周下载时间（取决于带宽和重试策略）。

差异 2：预处理从 CPU 密集型变成 GPU 密集型

纯文本：tokenization、去重、质量打分主要是 CPU 操作。即使用 FastText 做语言检测或用小模型打分，CPU 集群通常就够了。

多模态：图像解码、resize、CLIP embedding 计算、美学评分——这些步骤如果在 CPU 上做，会成为 GPU 训练的严重瓶颈。

• NVIDIA DALI 将图像解码和变换移到 GPU 上执行，支持融合算子（裁剪+翻转+归一化一步完成），A100 上可达 3000-5000 FPS
• 视觉 Tokenizer 推理 本身也是 GPU 计算——VQ-VAE/VQGAN 等模型需要在 GPU 上将图片编码为离散 token
• 预处理和训练争抢 GPU 资源，需要专门的调度策略

差异 3：质量过滤维度从一维变成多维

纯文本质量轴：

• 语言检测（是不是目标语言）
• 文本质量（困惑度、是否自然语言）
• 去重（MinHash / SimHash）
• 安全（有毒内容检测）

多模态质量轴（在以上基础上新增）：

维度	具体指标	工具/模型	推荐阈值
图像美学	美学评分	LAION Aesthetic Predictor (CLIP+MLP)	预训练 > 4.5, 微调 > 6.0
图文对齐	CLIP 余弦相似度	OpenCLIP	通常保留 Top 50-70%
NSFW	色情/暴力分类	NeMo Curator / LAION Safety	生成模型需极严
水印检测	有无显著水印	专用分类器	生成模型必须过滤
图像分辨率	最小宽高	规则	通常要求 ≥ 256px
长宽比	极端比例	规则	过滤 > 3:1 或 < 1:3
重复图像	感知哈希/语义去重	pHash / Faiss	互联网 Meme 去重关键
文本长度	Caption 过短	规则	过滤 < 5 词

多模态数据质量打分从”一个分数决定去留”变成多维向量的联合决策。MLM-Filter [Wang et al., 2024] 提出用微调后的多模态语言模型做统一质量评估，效果优于 CLIP 分数单一指标。NeMo Curator 提供了从美学到 NSFW 的完整过滤器套件。

差异 4：去重从文本去重升级为跨模态去重

纯文本：MinHash（近似）或精确子串匹配。

多模态：需要同时处理三类重复：

1. 文本重复：同一 caption 配不同图（低信息增益）
2. 图像重复：同一图配不同 caption（互联网 Meme、stock photo 泛滥）
3. 跨模态重复：不同 caption + 不同 URL 但视觉语义相同的图

图像去重需要用感知哈希（pHash/dHash，快但粗糙）或语义 embedding 聚类（CLIP embedding + Faiss，精确但昂贵）。实操中通常两阶段：pHash 粗筛 → CLIP embedding 精筛。

真实数据：LAION-5B 中约 20-30% 的图像存在语义级重复。不去重会导致模型过拟合特定视觉模式。

差异 5：数据格式从”一种序列”变成”两种范式”

纯文本：所有数据本质上是 token 序列。JSONL 存储，tokenize 后直接拼接。

多模态：存在两种根本不同的数据组织范式，它们对应不同的模型训练目标：

范式 A：图文配对（Image-Text Pairs）

{"image": "s3://bucket/img_001.jpg", "caption": "A cat sitting on a windowsill"}

• 结构简单，样本独立
• 适合对比学习（CLIP）和基础视觉-语言映射
• 信号密度高，易于全局 shuffle

范式 B：交错文档（Interleaved Documents）

[Text] 今天去了故宫...
[Image: palace_gate.jpg]
[Text] 走过午门，眼前是太和殿...
[Image: hall_of_supreme_harmony.jpg]
[Text] 殿内的龙椅依然威严...

• 保留文档级上下文和叙事结构
• 适合训练文档理解、多图推理、少样本学习
• 处理复杂度远高于配对数据——需要保持图文顺序、处理跨页引用

实操策略（来自 MM1 [Apple, 2024] 和 InternVL3 [2025] 的经验）：预训练早期约 80% 配对数据 + 20% 交错数据。配对数据打基础映射，交错数据注入上下文推理能力。后期逐渐提高交错数据比例。

差异 6：Tokenization 从查表操作变成模型推理

纯文本：BPE/WordPiece tokenizer 是确定性函数。给定 vocabulary，token 化是纯 CPU 查表操作，速度极快。

多模态：图像 token 化本身就是一个深度学习推理任务。两条技术路线并存：

路线 A：离散 token（VQ-VAE / VQGAN）

• 将图像编码为离散 codebook index，可直接和文本 token 拼接
• 代表模型：Chameleon（Meta）、Emu3（BAAI）
• 优点：与语言模型天然兼容，可用同一个 softmax 损失
• 缺点：离散化导致信息损失，重建质量依赖 codebook 大小（通常 8192-16384）
• 2025-2026 新进展：TokenFlow (CVPR 2025) 提出统一理解和生成的 tokenizer；SoftVQ-VAE 实现 1D 连续 token 化，压缩率更高

路线 B：连续 token（ViT Patch Embedding）

• 用视觉编码器（ViT/SigLIP）将图像编码为连续向量序列
• 代表模型：LLaVA、InternVL、Qwen-VL
• 优点：信息保留完整
• 缺点：需要额外的对齐模块（MLP/Q-Former），且无法直接用于图像生成

路线 C：混合方案（Transfusion / BAGEL）

• 理解用连续 token，生成用离散/扩散 token
• 代表：Transfusion（Meta FAIR）——文本走自回归，视觉走扩散
• 这是目前效果最好的路线，但数据管线最复杂——同一张图需要同时准备两种表示

数据工程影响：采用离散 token 路线的模型，其数据预处理管线中需要多一步”图像 → VQ token 序列”的推理，这需要 GPU 资源且引入了 tokenizer 质量对最终模型的强依赖。

差异 7：数据配比从”语种/领域”升级为”模态/分辨率/复杂度”

纯文本：配比主要考虑语种（中英比例）、领域（代码/数学/通用）、数据源（书籍/网页/学术）。

多模态：配比维度爆炸式增长：

配比维度	具体决策	影响
模态比例	文本 vs 图文对 vs 交错 vs 视频 vs 音频	核心，决定模型能力分布
图像分辨率	256/512/1024 混合比例	高分辨率数据占用存储/计算，但对细粒度理解必要
Caption 粒度	短 caption vs 详细描述 vs 结构化标注	短的利于对齐，长的利于细节理解
训练阶段	不同阶段不同配比（多阶段 annealing）	Emu3 使用 4 阶段，每阶段配比不同
合成 vs 自然	合成 caption（Recaptioning）占比	InternVL3 发现合成数据过多导致幻觉
图文对齐严格度	严格对齐 vs 宽松对齐的比例	过严丢失长尾数据，过松引入噪声

Chameleon (Meta) 的经验是一个典型案例：它在预训练中使用了文本、图文对、交错文档三种数据，但发现文本数据比例低于 50% 时语言能力会显著下降。最终采用”文本为主、多模态为辅”的配比策略，在多模态能力和语言能力之间取得平衡。

差异 8：数据管线从”单流水线”变成”多管线编排”

纯文本管线：

下载 → 语言检测 → 质量过滤 → 去重 → tokenize → 存储

一条直线，各环节串联。

多模态管线：

                   ┌─ 图文对 ─── 图片下载 ─── 图像质量过滤 ─── CLIP 对齐过滤 ─── 美学评分 ─┐
文本处理管线 ──────┤                                                                      ├── 合并 ── 配比 ── 多阶段训练
（同纯文本）       ├─ 交错文档 ─ DOM 解析 ─── 图文位置对齐 ─── 文档级连贯性 ──────────────┤
                   ├─ 视频 ──── 帧提取 ──── 时序对齐 ──── 关键帧选择 ──────────────────────┤
                   └─ 音频 ──── ASR ─────── 语音-文本对齐 ──── 说话人识别 ─────────────────┘

每种模态有独立的采集、清洗、token 化管线，最后在配比层面汇合。管线之间存在资源竞争（GPU 同时要做图像 embedding 和视频帧提取）和节奏差异（文本处理快，图片下载慢，视频最慢）。

推荐用 Ray Data 而非 Spark 做多模态清洗——因为清洗涉及大量深度学习推理（CLIP/美学模型），Ray 的 Actor 机制允许模型常驻 GPU 内存，避免反复加载的开销。

---

三、五个值得深挖的数据方向

基于以上差异分析，以下五个方向是我认为在多模态数据工程中有实操价值且相对未被充分开发的：

方向 1：Recaptioning 工程——用大模型重写低质量 caption

背景：LAION-5B 等大规模数据集的 caption 来自网页 alt-text，质量极差——大量是文件名、SEO 关键词、乱码。但图片本身可能是高质量的。

方法：用强力 VLM（如 LLaVA-1.6、InternVL2.5、Qwen2-VL）对图片重新生成详细描述。

已有工作：

• ShareGPT4V：用 GPT-4V 对 100K 图片生成高质量 caption，证明 caption 质量 >> 数量
• LLaMA-3 Recaptioning（OpenReview, 2025）：用 LLaMA-3 对数十亿网页图片重写，发现详细 caption 显著提升下游模型表现
• Qwen3-Coder-Next 中训练：用 480B 模型将网页数据重写为 Markdown，MultiPL-E +12.33%——虽然是代码场景，但 recaptioning 的逻辑完全相同

可挖掘点：

• 层级化 caption：同时生成短 caption（一句话）+ 中 caption（一段）+ 长 caption（详细描述），用于不同训练阶段
• 结构化 caption：不是自由文本，而是 {物体: [], 场景: "", 动作: [], 关系: [], 文字: []} 的结构化标注
• 领域特化 recaptioning：针对科学图表、医学影像、工程图纸等专业领域的定制化描述

方向 2：交错数据的高质量构建——目前最大的缺口

背景：配对数据丰富但浅薄，交错数据更接近人类认知但质量参差不齐。OBELICS 等数据集直接从网页提取，存在图文不相关、广告图片混入、叙事断裂等问题。

核心问题：如何自动判断一张图片在文档中是否真正和上下文文本相关？

可挖掘点：

• 图文因果链检测：判断一张图是在”解释上文”还是”引出下文”还是”纯装饰”
• 文档级连贯性评分：不只评估单张图和周围文本的对齐，而是评估整个文档的图文叙事是否连贯
• 合成交错文档：从高质量配对数据出发，用 LLM 生成连接多张图的叙事文本，构建合成的交错文档
• 教科书/论文风格数据：学术论文和教科书是最高质量的交错文档——图-公式-表格-文字的结构化组织。arXiv LaTeX 源文件 + PDF 渲染是一个金矿

方向 3：跨模态对齐数据的精细化

背景：当前的图文对齐主要依赖 CLIP 余弦相似度，这是一个粗粒度的全局指标。一张复杂场景图片可能包含 10 个实体，但 caption 只描述了其中 3 个。

可挖掘点：

• 区域级对齐（Grounding）：不只是”图和文是否匹配”，而是”图中哪个区域对应文本中哪个短语”
• 负样本挖掘：构造”看起来匹配但有细微语义差异”的困难负样本对
• 时序对齐（视频场景）：视频帧和字幕的时间戳级对齐，而不只是视频-文本的全局匹配
• 代码-图表对齐：这是站点已有研究 [code-diagram-alignment] 的延伸——代码执行结果的截图与代码本身的精确对应

方向 4：多模态数据的合成管线

背景：纯文本领域的合成数据已经非常成熟（Self-Instruct、Evol-Instruct、WizardLM 式数据飞轮）。多模态合成面临额外挑战：合成文本容易（调 LLM），合成高质量图像也可以（调 Diffusion），但合成高质量的图文对齐数据困难得多。

可挖掘点：

• 图像条件化对话生成：给定真实图片，用 VLM 生成多轮 QA/推理/描述，形成视觉指令数据
• 文本条件化图像生成：给定高质量教科书文本，用 Diffusion 模型生成配图——风险是引入视觉幻觉
• 图表自动化生成：给定数据和代码，自动执行并截图，构建”代码→图表→描述”的三元组
• 视频合成：从长文本描述出发，用视频生成模型合成教学/演示视频，配合 ASR 生成对齐数据
• 对抗性合成：专门构建”图文不匹配”的负样本，训练模型的辨别能力

方向 5：Visual Tokenizer 数据——被忽视的基础层

背景：对于采用离散 token 路线的原生多模态模型（Chameleon/Emu3 等），Visual Tokenizer 的质量直接决定了模型的上限。但 tokenizer 的训练数据和预训练数据是两套独立的管线。

可挖掘点：

• 高保真重建数据：Visual Tokenizer 需要高分辨率、高质量的图片进行训练。当前大多用 ImageNet + COCO，但这些数据分布偏向特定场景。扩展 tokenizer 训练数据的多样性（加入科学图表、医学影像、卫星图、艺术品等）可能显著提升下游多模态模型在这些领域的表现
• 超分辨率训练对：构建”模糊→清晰”的图像对，用于训练 tokenizer 的解码器
• Tokenizer Distillation 数据：将大 tokenizer（codebook 65536）蒸馏为小 tokenizer（codebook 8192），在降低计算成本的同时保持重建质量
• 领域自适应 Codebook：为特定领域（如医学/遥感/文档）训练专用 codebook，提升该领域的 token 化精度

---

四、实操建议：从纯文本 LLM 迁移到多模态的路线图

如果你的团队已经有成熟的纯文本数据管线，以下是迁移到多模态的优先级建议：

Phase 1：最小可行多模态数据管线（2-4 周）

1. 从 DataComp-1B 开始而非 LAION-5B——DataComp 有更好的过滤框架和基准线
2. 用 img2dataset 搭建图片下载管线，WebDataset 格式存储
3. 用 OpenCLIP 做基本的图文对齐过滤（cosine similarity > 0.28）
4. 先跑通配对数据管线，不要一开始就做交错数据

Phase 2：质量工程（2-4 周）

1. 集成美学评分和 NSFW 过滤（NeMo Curator 有现成方案）
2. 用 pHash + CLIP embedding 做两阶段图像去重
3. Recaptioning：对 top 10% 高美学分的图片用 VLM 重写 caption——ROI 最高的投入
4. 构建质量仪表盘，可视化各维度分布

Phase 3：交错数据与合成数据（4-8 周）

1. 基于 OBELICS/OmniCorpus 构建交错数据管线
2. 开发文档级连贯性评分模型
3. 搭建视觉指令数据合成管线
4. 开始尝试视频数据（从 WebVid-10M 入手）

Phase 4：规模化与优化（持续）

1. 多阶段数据配比实验
2. Visual Tokenizer 训练数据扩展
3. 领域特化数据的定制采集
4. 全链路数据质量自动监控

---

五、总结

从纯文本到多模态，数据工程不是”加了一种文件格式”那么简单。它带来了八个结构性变化：

#	差异	纯文本	多模态
1	数据获取	离线文件	分布式在线下载
2	预处理瓶颈	CPU	GPU
3	质量过滤	一维（文本质量）	多维（美学+对齐+安全+分辨率）
4	去重	文本去重	跨模态语义去重
5	数据范式	单一序列	配对 + 交错两种范式
6	Tokenization	确定性查表	深度模型推理
7	数据配比	语种/领域	模态/分辨率/复杂度/阶段
8	管线架构	单流水线	多管线编排

五个最值得投入的方向：Recaptioning 工程、交错数据构建、跨模态精细对齐、多模态合成管线、Visual Tokenizer 数据扩展。

对于从纯文本迁移的团队，建议的优先级是：先跑通配对数据管线 → 再做质量工程和 recaptioning → 最后攻坚交错数据和合成数据。不要试图一步到位。

---

附录：核心参考资源

资源	说明
Awesome-MLLM-Datasets	HuggingFace 维护的多模态数据集索引
Awesome-Native-Multimodal-Models	原生多模态模型论文集
Awesome-Unified-Multimodal-Models	统一多模态模型综述
img2dataset	大规模图片下载工具
NeMo Curator	NVIDIA 的多模态数据清洗工具套件
DataComp	多模态数据集竞赛与基准
MLM-Filter	基于多模态 LM 的数据过滤框架

---

从文本到像素：原生多模态训练数据工程 | Maxwell | 2026-04-01