本期内容整理自火山引擎数据平台产品总监王彦辉在 NVIDIA GTC上 的主题演讲。NVIDIA GTC 2026 开发者大会已于 3 月 16 日在美国圣何塞盛大开幕。
作为全球AI与高性能计算领域最具影响力的技术盛会之一，GTC 被誉为"AI 界春晚"，是洞察 AI 技术趋势与 NVIDIA 战略方向的重要窗口，本届大会继续聚焦AI算力基础设施的革新与商业化落地。
围绕"多模态数据湖的新一代人工智能应用技术实践"这一主题，全文将结合 NVIDIA 工具链 NeMo Curator 的落地经验，系统阐述 AI 时代数据基础设施的变革挑战、多模态数据湖架构、前沿工具应用及典型案例，展现算力革新浪潮下的技术探索与行业思考。
一、AI 时代数据基建变革与挑战
非结构化数据价值爆发，重塑数据生态
在 AI 时代，非结构化数据价值被迅速明确，正在重塑数据生态，正逐渐成为新的创新引擎。而在过往的大数据时代，企业主要围绕结构化数据来进行的计算、存储、加工和分析，主导业务增长和决策。
根据 IDC 的预测，2029 年中国数据生成量将从当前的 51 ZB 增长至 136 ZB，其中非结构化数据占比 80% 以上。而模型训练过程中，约 75% 的数据来自于非结构化数据，每年需要处理的非结构化数据量正在以 10 倍以上的速度增长。
传统数据湖面临的 5 大技术挑战
过往的传统的数据湖主要是围绕结构化数据来进行管理和计算，因此在 AI 时代，传统的数据湖将面临图中五大挑战。
- 首先在数据存储方面缺乏优雅的存储格式，传统数据库的存储格式主要是围绕 Iceberg 这类结构化数据，而非结构化数据主要采用 Web DataSet 这种数据格式，将元数据和实际的数据进行了分割存储，导致数据在性能和一致性上出现突出问题。
- 其次在数据处理层面， AI 时代要求数据处理引擎不仅需要支持 CPU 计算，更需要有效的支持 GPU 计算，同时需要更加灵活、轻量级，以契合算法人员的使用习惯。
- 第三是引擎和模型的联动性较差，传统数据引擎往往没有和大模型做很好的融合。
- 第四在数据管理层面，主要的传统数据管理的方法论围绕的是结构化数据，缺乏有效的非结构化数据管理平台，容易造成数据孤岛和数据碎片化。
- 最后，随着 Agent 的快速爆发和兴起，复杂的数据处理环节正在逐渐占据大量算法人员工作时间，处理效率非常低下。
二、多模态 AI 数据湖新架构
针对传统数据湖面临的五大挑战，我们推出了多模态数据湖的架构，主要在以下五个方面进行了针对升级。
处理推理一体
在存储方面，我们不仅兼容过往结构化数据的 Spark 数据湖存储，还结合了 Lance 这种非结构化数据存储格式。同时支持 MCAP、 LeRobot 等数据格式，比较有效的覆盖了自动驾驶、机器人等行业。
在数据湖处理环节，我们提出了处理和推理一体化平台，此平台不仅可以有效的运行在 CPU 上，还可以比较好的联动 GPU 计算资源，同时也可以比较好的跟模型结合。为此，我们重点推出了 Ray 和 Daft 以及 NeMo Curator 三个非结构化数据处理的引擎，通过结合一些开源模型比较好的实现了处理和推理的一体化。
基于多样的数据处理引擎，我们内置了 200 个数据处理算子。这些算子覆盖了文本、图片、视频、音频多种模态，能够极大方便算法工程师，让他们可以低门槛地实现各类场景下的数据处理需求。
在丰富的算子之上，为了更进一步降低用户的使用门槛，我们推出了 LAS Processing Agent 多模态数据处理智能体，它可以结合用户的处理需求，去调度底层的算子和算力资源。
在计算能力之外，我们还提出了数据湖的管理的能力，主要体现在以下三个方面：
- 首先是数据集管理方面，主要包括对数据的多模态、版本管理、数据探查、数据共享，做了数据集能力增强；
- 其次是 Catalog 管理方面，不仅支持了传统的 Hive Meta Store，同时也支持对 Gravitino 非结构化的数据的元数据管理；
- 最后是数据湖表管理方面，可以实现对数据湖文件的自动合并、自动清理、索引管理以及冷热流动。
AI 数据湖解决传统数据架构痛点
基于上述在多模态数据湖的存储、处理、算子、数据集管理和数据处理 Agent 的新架构，可以有效的解决多模态数据的计算、存储和加工问题。
三、多模态数据湖新工具
NVIDIA NeMo Curator 简介
NVIDIA 最近推出的 NeMo Curator，它可以比较有效的对非结构化的文本、图片和视频进行高精度的、可扩展的数据处理。
NeMo Curator Architecture: Text Processing
图中是 NeMo Curator 的文本数据处理工作流，可以对在本地和云端的数据，进行数据的导入、清洗、加工以及根据数据质量进行分类、数据去重，进行高质量数据集筛选，完成数据处理工作。
而以上的数据处理过程基于 NVIDIA 的：RAPIDS - cuDF，cuGraph & cuML 等平台同时在 GPU 进行性能加速。
NeMo Curator - Features
NeMo Curator 在文本数据处理上具有以下几个高精度的特点：
- 首先是数据高质量合成，通过 pipeline 实现对话和文本数据的合成和生成，轻松将 NeMo Curator 的功能集成到现有的工作流中。同时还可以结合 OpenAI API 标准。
- 其次是数据去重和数据分类，可以对文本数据进行识别和去重，针对不同的语义进行数据提取，可以使用数据分类模型对数据进行清洗分类。
- 最后是通过 RAPIDS 对 GPU 的性能加速。主要通过 cuDF、cuML、cuGraph 来实现。
General Purpose Data Processing & Curation Pipeline
图中是通过 General Purpose 来处理视频数据的过程。左侧是原视频，通过视频的解码和切分、转码和过滤之后，对关键帧进行标注，最后进行视频和文本的嵌入，从而完成对整个视频的处理工作。
根据以往时间计算，以此 200 万小时的视频为例，将占到 35 PB 的数据规模。通过 2, 000 核的 CPU 进行计算的话，需要 3.4 年的时间。这对于当前快速迭代的 AI 时代来说，是显然远远不能达到要求的。
NeMo Curator Data Processing & Curation Pipeline
图中是通过 NeMo Curator 来处理视频数据的过程，相同的操作流程、同样的视频时长和同样的数据规模，在使用 1, 000 张 Hopper GPU 进行计算后，耗时从之前的 3.4 年的压缩到 40 天。大大缩短了模型训练的整个周期。
Process High-Quality Videos with NeMo Curator
NeMo Curator 还可以进行高质量的视频数据处理、加工工作。目前在我们的实践过程中最高使用到了 100 PB 的数据处理。此外可以进一步降低 TCO 的使用成本、可以结合 SOTA 模型、可以模块化配置进行客户客制化。
四、多模态场景对湖存储的新诉求
首先不同的模态之间数据存储的差异化量值比较大。文本数据每一行、每一列的存储，所需空间比较小，但是对于视频数据、图片数据可能和文本数据的存储差异是非常大的。而且在不同的数据处理的过程中，需要针对不同的模态进行联合的处理、清洗、加工和操作。
在过往的实践过程中，经常会出现需要针对不同文件进行加列的情况。例如在模型训练过程中，需要对不同图片进行美学分的判定。由于美学分的判定标准并不统一，所以这一操作常常需要高频执行。同时，还需要对一些图像信息或视频数据生成相应的描述性文字（Caption）。这些重复性操作在很大程度上限制了模型训练的整体效率。
在模型训练前，经常需要对去数据进行重排，训练数据的 Shuffle 经常会造成内存的急剧膨胀，不仅带来了较高的计算成本，还容易引发内存溢出的问题，进一步影响训练的稳定性与效率。
新一代多模存储格式 Lance
基于上述问题，我们在大量调研和探查工作后，推出了Lance，我们认为它能够较好地解决这些问题。
Lance 是专门为 AI 时代而生的数据湖格式，其核心架构涵盖三个层面：Lance Format、Table Format 与 File Format，以及 Catalog。本次我们重点介绍的是列格式与文件格式（File Format）这两方面。
Lance 原生支持多模态的数据存储，提供高性能的随机访问，支持零成本加列。
- 首先是多模态的数据存储，它可以把多种模态的数据存储到一张表里进行统一管理，同时根据 RowID 进行点查和结构化的自适应编码，提供了多种形式的二级索引，提升随机访问的性能。
- 其次是支持高效加列，无需整个重写 fragment。对于 AI 场景下需要的大宽表，可以比较灵活地去添加数据列，不需要对数据进行重新的导入，从而提高模型训练的效率。通过多种形态的二级索引提升了 SCAN 的性能，而且它支持不同的透明压缩算法，可以避免些读取放大问题。
经过我们的一些实践，特别是在处理视频和图像数据时，Lance 能够显著降低存储成本，同时有效避免 I/O 问题。而且它能支持 Git 的元数据版本和分支管理。可以实现在算法实验时的数据隔离和数据回溯。例如，在进行算法实验时，如果需要回溯到几天前的数据状态，可以借助 Lance 的版本管理功能进行有效回溯。
多模态混合存储
上图是 Lance 的存储逻辑。比如说在 LanceDB dataset 里边可以看到有不同的数据存储列：Int 型、文本型、Float 型和 Vector 存的向量，这些都可以在一张表里进行管理和存储。Lance 既支持对标量数据进行 SQL 查询，也支持针对向量的 Vector search 以及文本查询。
File Format，更小更纯粹
File Format 通过 Page + Col DP + Footer 三级结构设计，灵活度高、扩展性强；列元数据支持按需加载，从而节约 IO；File schema 与 Table schema 独立，使得加列成本很低。通过并行计算，移除 Group 不会影响到 I/O，有利于大幅降低对首字节的延迟。
Table Format，零成本加列
在模型训练的过程中和大规模非结构化数据管理过程中，经常需要调整队列内容，进行加列操作。
在 Lance 添加新列时（add column），不需要重写 Fragment，而是向 Fragment 添加一个新的 DataFile。如图所示，当我们有了 column a 的时候，我们可以看到在 V1、V2 这两个版本里边分别是两个文件，那当我们想加 column b 的时候，我们只需要写一个新的 V3 文件，这个列就被加上了，达成需依赖于比较良好的文件和 table format 的隔离。
高性能随机访问，1-2 IOPS
Lance 也可以对 IOPS 的点查性能优化和透明压缩。
Daft：AI 场景对数据处理的新诉求
在 AI 处理数据的场景下，新的诉求主要包括非结构化数据的价值挖掘、 GPU 的联合调度使用率，以及在数据处理过程中的数据计算和模型调用。
此外很多的场景下，会出现单机的 Python 需要经过分布式计算，这个过程中需要对 Python 代码进行大量的修改和优化，而这往往会增加算法人员的负担。
同时在数据加载过程中往往会出现由于 CPU 的能性能限制GPU，造成了 GPU 的空跑线情况，大幅拉低 GPU 资源使用率，造成成本大幅浪费。
基于以上，我们重点推出了 Daft 和 Ray 两项技术。
Daft：新一代多模态数据处理引擎
Daft 原生支持对多模态数据的处理和清洗加工。支持对 GPU 和 CPU 的异构调度。支持 Python dataframe 和 SQL 的原生数据处理，支持 native 向量化执行操作。以 Rust 作为内核，更加稳定，而且性能更加强劲。通过极致轻量级和分布式扩展，支持 Daft on Ray 分布式扩展。同时可以与 Pytorch、Pandas、Hugging Face 等无缝对接。
统一多模态数据处理
Daft 原生支持多模态数据处理函数，也支持自定义数据处理函数；支持多种数据格式，例如 Esprida data HUDI、 parquet 和 Lance ；支持多种数据类型处理，例如视频、图片、WARC、文件。
Daft 已在主流云厂商中上线，可以结合不同模型。图中是通过 Daft 创建的 DataFrame 示例。通过简单的几行代码，就可以把视频文件、图片文件有效的加载进去。
优雅嵌入模型，处理推理一体化
Daft 比较优雅的嵌入了数据处理和推理模型，图中代码示例：通过 read huggingface 进行数据读取和数据过滤，可以同时调用我们的火山引擎的豆包模型进行推理，实现对多模态数据处理的加工，同时写入 Lance Format。
Pipeline Streaming + Morsel Adaptive
在数据处理过程中，Daft 采用了 Pipeline 执行模型，并结合了 Morsel 动态执行机制。根据不同数据处理的算子要求，对Morsel 进行动态调整，从而有效避免数据的 OM。基于 Pipeline 的执行方式，Daft 可以优化数据处理工作流的整体调度，减轻数据处理传输压力。
CPU & GPU 异构计算
在大模型时代，AI 计算最重要的一个需求是支持 GPU 和 CPU 的异构计算。
Daft 和 Ray 都可以调度 GPU 和 CPU 的算力，同时进行分布式计算和数据处理，其结果直接通过 PyTorch 进行模型训练。
多模数据的 Lazy Download
Daft 的另一项核心技术在于实现了数据的 Lazy Download 能力。
在图文混排的数据场景下，Lazy Download 可以延迟对图片字段的压缩和解析，从而有效减少对内存和 I/O 资源的占用。
Daft 在计算 UDF 和 Expression 等列操作时，能够避免对 DataFrame 进行不必要的拷贝，进一步降低内存开销。
基于 Rust 原生实现的 SQL 和 DataFrame 语法表达，可以有效的支撑数据聚合操作。
火山 LAS Daft 技术优化
火山引擎 Daft 在多个关键方向上进行了增强与优化。
首先是对算子能力的增强和补齐；支持 Daft 两种底层计算引擎；支持原生 shuffle 操作、 dataframe 和 SQL 操作；此外，火山引擎还将 Daft 与 LAS Catalog 进行了有效打通。
Ray：AI/ML 工作负载的分布式计算框架
Ray 也是一个高性能开源的分布式计算框架，通过简洁的 API 实现对 GPU 和 CPU 的异构调度和并发执行。对于已有的 Python 分布式脚本，迁移至 Ray 的过程十分容易，通过一定的装饰器的修改加工即可实现。
火山引擎 Ray 引擎增强优化
火山引擎 Ray 同样在多个关键方向上进行了增强与优化，主要包括系统稳定性、计算性能、可观测性以及运维能力等方面的提升。
Ray Data Checkpoint
在火山引擎对 Ray 的优化中，一项重要的增强是引入了 Ray Data Checkpoint 机制，这是开源 Ray 中不具备的能力。
该机制可以记录和保存 Ray 计算过的一些数据，包括失败中断的过程。当任务再次执行失败中断后，在恢复时可以跳过已经处理完的数据，从 checkpoint 点开始重新计算，这一机制有效避免了数据的重复处理，节省了 GPU 和 CPU 的计算资源，大幅降低了数据处理的成本。
Ray Data AutoScale
另一项关键优化是 Ray Data AutoScale 能力，通过在运行过程中引入自适应计算框架，Ray Data 运行时框架通过自适应的改变 Actor 数目来自动调整 Operator 并发度的能力。用户无需进行手动调优，就能实现资源的有效使用和提高处理效率。
图片右半部分展示了 Ray 集群 AutoScaler 联动，在数据处理的过程中，系统能够根据不同的数据处理需求，在读取数据阶段动态扩展 Actor 的数量，从而实现数据的弹性计算。
基于 GPU 的分布式向量去重
基于 GPU 的分布式向量去重工作，其核心在于充分利用 GPU 对向量运算的天然的加速优势，尤其在向量相似度计算、图结构构建及连通分量分析等，有较好效果。
在性能方面，该方案相较于传统的 CPU 分布式架构，整体处理效率提升了 10 到 100 倍，能够支持亿级向量规模下的分钟级去重任务。
这一能力在多个实际场景中具有广泛的应用价值，尤其适用于推荐系统、图像检索、多模态训练数据预处理等需要高频更新向量库的数据处理场景。
可观测性提升
在可观测性方面，火山引擎针对 Ray 原生的 History Server 存在的性能瓶颈进行了专项优化，并上线了 Flow Insight 能力。该能力能够在大量数据计算任务并发执行的情况下，仍保持 UI 的连续与稳定运行。
从内部测试情况来看，在数千至上万的任务执行过程中，都可以实现 Ray History Server 的有效展示。
基于 Ray/Daft 实现 Remote DataLoader
火山引擎进一步优化了 Ray 与 Daft 在 Remote Data Loader 的能力。传统的 Remote Data Loader 经常出现当CPU 的性能吃满时，会 block GPU 和 CPU 的通讯，造成 GPU 的空泡和性能使用率的大幅降低的情况。
针对这一问题，火山引擎通过部署外置的 Ray 与 Daft 集群，有效的分隔了 GPU 和 CPU 的算力，同时通过我们的 Remote Data Loader 可以实现数据的有效加载，实现数据处理集群在 CPU 集群的无限扩展，避免了 GPU 训练空置。
在数据加载环节，支持对象存储和 PFS 并行文件系统的快速加载。
当训练任务发生中断时，可以通过 Daft 来保存当前计算 step 的数据处理状态。
五、实践案例分享
案例1：某智驾公司 PB 级数据架构升级
我们以一家智能驾驶客户的实际落地场景为例。
在客户原有数据处理方案中，通过 Argo 进行数据工作流的调度，数据可以运行在 CPU 和 GPU 之上。但二者为相对独立的集群，通过 Argo 来进行资源调度和任务编排工作。处理后的数据存储到 TOS 中，格式是LMDB。通过 JSON 来进行 index 管理和元数据的管理。
数据处理完成后，在数据挖掘和管理的过程中，主要通过 CSV 和手动管理操作， 其中CSV 的数据处理仅仅能处理一些比较小的数据文件，而且它的数据管理的血缘关系也是通过手动的管理方式，处理完之后仍然是存到并行文件系统里，加载到模型训练的平台上。
引入火山引擎的新方案后，采用了基于 Ray 与 Daft 构建的统一集群，替代原有的 Argo 调度平台。新架构能够更高效地调度资源，实现对数据的清洗、拆解与打包等操作。核心优势在于，新方案显著提升了 GPU 与 CPU 的资源调度，同时迁移路径相对平滑，开发者只需进行适量的代码修改就可以实现，即可从原本依赖手动管理的分布式执行框架，转变为自动且有容错能力的分布式异构资源调度框架。
在存储层面，新方案引入 Lance Format，依托数据湖平台 LAS 实现元数据与数据血缘的自动管理，用户无需再手动维护索引和关系信息。通过数据入湖、分层存储等能力，进一步提升了数据治理的效率与规范性。
核心收益：成本降低 30%，效率提升 40%
通过以上解决方案，客户的数据的成本降低了 30%，而管理效率提升了 50%。通过 Remote Data Loader，客户的 GPU 资源也得到了大幅提升，从 60% 上升到 96%，资源交付的数据交付周期缩短 40% 以上。
这些收益主要得益于 Lance 的以下几项核心能力的支撑：Lance 的透明压缩， Lance 多模态数据存储以及 Lance 的点查能力，Remote Data Loader 能力以及 Ray 的推理性能优化。
案例2：国内某头部大模型公司
我们再来看一个国内头部模型训练厂商的实际案例，在客户过往的实践中，我们看到的最大的一个问题是，客户使用 WebDataset 进行数据存储，在预训练环节需要检索图片或文本数据时，流程十分复杂。通常需要根据索引找到对应的 tar 文件，解压后再进行查找。这一架构不仅不够优雅，还会引发严重的读放大问题。
此外，在图文混排的数据处理过程中，往往伴随着大规模的数据 Shuffle，开源 Spark 难以支撑如此量级的 Shuffle 操作，导致文本去重等任务频繁失败。
火山引擎提出的解决方案是将 WebDataset 迁移至 Lance 格式，将元数据作为列标签存储，图片则以二进制形式保存。借助 Lance 提供的列裁剪与随机点查能力，实现秒级对数十亿文件的高效点查，显著降低读放大效应。同时，Shuffle 过程仅需从少量字段中提取 Row ID，大幅减少了 I/O 开销与内存压力，最终实现高性能的数据交付。
