本期内容整理自火山引擎数据平台产品总监王彦辉在 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 - cuDFcuGraph cuML 等平台同时在 GPU 进行性能加速。NeMo Curator - FeaturesNeMo 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 CuratorNeMo 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 三级结构设计灵活度高、扩展性强列元数据支持按需加载从而节约 IOFile 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 IOPSLance 也可以对 IOPS 的点查性能优化和透明压缩。DaftAI 场景对数据处理的新诉求在 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 DownloadDaft 的另一项核心技术在于实现了数据的 Lazy Download 能力。在图文混排的数据场景下Lazy Download 可以延迟对图片字段的压缩和解析从而有效减少对内存和 I/O 资源的占用。Daft 在计算 UDF 和 Expression 等列操作时能够避免对 DataFrame 进行不必要的拷贝进一步降低内存开销。基于 Rust 原生实现的 SQL 和 DataFrame 语法表达可以有效的支撑数据聚合操作。火山 LAS Daft 技术优化火山引擎 Daft 在多个关键方向上进行了增强与优化。首先是对算子能力的增强和补齐支持 Daft 两种底层计算引擎支持原生 shuffle 操作、 dataframe 和 SQL 操作此外火山引擎还将 Daft 与 LAS Catalog 进行了有效打通。RayAI/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 开销与内存压力最终实现高性能的数据交付。
基于多模态数据湖的新一代人工智能应用——Nvidia 工具链落地实践的深度洞察
本期内容整理自火山引擎数据平台产品总监王彦辉在 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 - cuDFcuGraph cuML 等平台同时在 GPU 进行性能加速。NeMo Curator - FeaturesNeMo 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 CuratorNeMo 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 三级结构设计灵活度高、扩展性强列元数据支持按需加载从而节约 IOFile 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 IOPSLance 也可以对 IOPS 的点查性能优化和透明压缩。DaftAI 场景对数据处理的新诉求在 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 DownloadDaft 的另一项核心技术在于实现了数据的 Lazy Download 能力。在图文混排的数据场景下Lazy Download 可以延迟对图片字段的压缩和解析从而有效减少对内存和 I/O 资源的占用。Daft 在计算 UDF 和 Expression 等列操作时能够避免对 DataFrame 进行不必要的拷贝进一步降低内存开销。基于 Rust 原生实现的 SQL 和 DataFrame 语法表达可以有效的支撑数据聚合操作。火山 LAS Daft 技术优化火山引擎 Daft 在多个关键方向上进行了增强与优化。首先是对算子能力的增强和补齐支持 Daft 两种底层计算引擎支持原生 shuffle 操作、 dataframe 和 SQL 操作此外火山引擎还将 Daft 与 LAS Catalog 进行了有效打通。RayAI/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 开销与内存压力最终实现高性能的数据交付。
