生成式人工智能/大语言模型

在 NVIDIA DGX 云上使用 NVIDIA NeMo Curator 处理 PB 级视频

随着 物理 AI 的兴起,视频内容生成呈指数级增长。一辆配备摄像头的自动驾驶汽车每天可生成超过 1 TB 的视频,而机器人驱动的制造厂每天可生成 1 PB 的数据。

要利用这些数据来训练和微调 世界基础模型 (WFMs) ,您必须首先高效地处理这些数据。

传统的固定容量批量处理流水线难以应对这种规模,通常未充分利用 GPU,并且无法匹配所需的吞吐量。这些效率低下的情况减缓了 AI 模型的开发,并增加了成本。

为了应对这一挑战, NVIDIA NeMo Curator 团队 开发了一个灵活的 GPU 加速流式传输管道,用于大规模视频管护,现在可在 NVIDIA DGX Cloud 上使用 。在本文中,我们将探讨在管道中进行的优化,包括 自动扩展和负载均衡技术,以确保在充分利用可用硬件的同时优化各管道阶段的吞吐量。

结果如何?更高的吞吐量、更低的总体拥有成本(TCO)和加速的 AI 训练周期,从而加快最终用户的成果。

通过自动扩展实现负载均衡

传统的数据处理通常依赖于 批处理 ,即一次累积大量数据来处理,一次经历一个阶段。

A diagram shows a data processing pipeline with three swim lanes, originating from a command. Each swim lane follows the pattern of load data, pre-process the data, stash the data in cluster storage, retrieve the data for inferencing, then stashing to cluster storage again, before retrieving it for export to permanent storage.  The diagram highlights the separation between the CPU and GPU stages in this model, and how disruptive the storage and retrieval steps are to the steady flow of the pipeline.
图 1。具有单独阶段的批处理工作流,被集群存储和检索打断

这带来了两个主要问题:

  • 效率:很难有效利用异构资源。当批处理工作在 CPU 密集型阶段时,GPU 资源将被闲置,反之亦然。
  • 延迟:在处理阶段之间,存储中间数据产品以及从集群存储加载中间数据产品的需求会导致严重的延迟。

相比之下,流处理会直接在各个阶段之间输送中间数据产品,并在前几个阶段完成后立即开始对单个数据进行下一阶段处理。

A diagram shows a data processing pipeline where data flows between CPU tasks and GPU tasks through memory instead of cluster storage. The pipeline is broken into stages: CPU tasks such as fetching data from Amazon S3 and preprocessing it, GPU tasks such as segmentation models and classification models, and final CPU tasks such as writing the results to permanent storage. The lack of cluster storage stages between the CPU and GPU stages distinguishes the streaming process as more efficient than the batch process from Figure 1.
图 2。Ray 中简化的工作流程,数据保留在阶段之间的内存中

这里的挑战是需要平衡阶段之间的吞吐量,以及希望区分 CPU 主要和 GPU 主要工作负载。

平衡吞吐量

在最简单的情况下,如果您有两个阶段,其中一个阶段的运行速度是下一个阶段的两倍,那么慢阶段就像是一个瓶颈,并且管道的整体吞吐量和性能仅限于慢阶段。您还可能面临内存中构建中间工作产品的风险,这需要耗费昂贵的赶超时间,因为计算资源可能处于空闲状态。在这种情况下,您可以通过以数据并行方式运行两倍数量的慢速阶段副本来解决此问题。

从视觉上看,具有异构吞吐量且支持或不支持自动扩展和负载均衡的多阶段视频处理流水线可能具有显著的性能和硬件使用差异:

A diagram shows the importance of properly balanced allocation of compute resources to different stages. The before column shows a pipeline running top to bottom between fast, slow, and medium stages. Each stage has a simple GPU assigned, so the fast stage produces work faster than the slow stage can consume it, which results in a queue building up, while the final medium stage is racing ahead of the slow stage, with wasted compute resources. The after column shows the same stages but uses additional GPUs. Critically, the after column balances the GPUs correctly, so the slow stage has far more GPUs, and can both keep up with input from the fast stage and not starve the medium stage.
图 3. 在每个阶段分配适当计算之前和之后的视频处理管道

区分 CPU 主要工作负载和 GPU 主要工作负载

另一个关键见解是,需要将视频下载或剪辑转码等 CPU 主导任务从生成嵌入或运行 AI 分类器等 GPU 主导任务中分离出来。

思考此问题的一种实用方法是将每个 pipeline 阶段想象成二维资源空间中的一个向量,其中一个轴代表 CPU 需求,另一个轴代表 GPU 需求。如果您将所有繁重的工作组合到一个需要(例如)70% CPU 和 30% GPU 的阶段,则只能向上或向下扩展相同的比例,只需将该使用向量乘以不同的数量即可。当集群资源与该比率不匹配时,这通常会导致资源未得到充分利用。

相比之下,如果将任务划分为不同的 CPU 主导阶段和 GPU 主导阶段,则要处理的向量会更多。这可让您混合、匹配和重叠多个向量,以更紧密地与基础设施的实际 CPU 和 GPU 容量保持一致。因此,您可以同时使用 CPU 和 GPU 资源,从而避免一种资源闲置而另一种资源过载的情况。

架构和实现详情

我们的整个工作流将视频管护任务划分为 基于 Ray 构建的 几个阶段:

A diagram starts with an example input video, represented by an image of a robot placing fruits in a shopping bag. The first stage is Video Decode and Splitting, specified with the AI model called “Shot Detector” referring to a “shot” as in “scene” from cinematography. The second stage is Transcoding. The third stage is Filtering, with AI models listed as: Motion, Quality, Overlay Text, and Video Type. The fourth stage is Annotation, with AI models listed as Cosmos and Nemotron. The fifth and final stage shows the Video and Text Embeddings as part of the output, footnoted as training data. The final image repeats the robot image from the beginning, with the annotation implying that the image is kept alongside the metadata produced by the pipeline.
图 4。NeMo Video Curator 的各个阶段

视频管护流程涉及多个阶段 (图 4) ,首先是提取原始视频文件并将其拆分成多个片段 (视频解码和拆分) 、将片段转码为一致的格式、应用质量过滤器生成元数据、在标注阶段生成文本描述,最后是计算嵌入——包括文本描述和视频内容的嵌入。

对于每个阶段,主编排线程管理一个 Ray 行为者池,每个行为者都是该阶段的工作实例。多个 actor 可以并行处理不同的输入视频,因此阶段的吞吐量会随着 actor 池的大小呈线性扩展。

编排线程还管理每个阶段的输入队列和输出队列。当编排线程将已处理的 pipeline 负载 (即视频及其元数据) 从一个阶段移至下一个阶段时,它可以持续测量每个阶段的整体吞吐量。

编排线程根据相对吞吐量,以相应的 3 分钟间隔扩展每个阶段的演员池大小,因此较慢的阶段有更多的演员。然后,可以对纯 CPU 阶段进行过度配置,这样即使在管道中出现波动时,GPU 阶段也会保持忙碌状态。

值得一提的是,主编排线程不会在各个阶段之间移动实际数据。它是对象引用,可理解为指向全局 Ray 对象存储中实际数据的指针,该引用正从阶段 N 的输出队列移动到阶段 N+1 的输入队列。因此,编排线程的负载较低。

结果和影响

在比较批量执行与流数据流水线时,您可以使用流数据实现更优化的系统资源使用(图 5)。

A diagram compares the efficiency of a sequential batched pipeline against overlapping streamed pipelines. The pipeline shown has four stages: video download, cutscene detection, clip extraction, and clip transcoding. The top of the diagram shows this batch being run twice in sequence, across eight time steps. The bottom shows how stages with different resource utilization can be run in parallel so that a CPU-heavy stage can run at the same time as a GPU decoder-heavy stage, and at the same time as a GPU compute-heavy stage. This shows more efficient use of the resources and more results delivered more quickly.
图 5。与高效的流式传输流水线相比,批处理流水线效率低下

在这种情况下,流式传输 pipeline 需要约 195 秒来处理每个 GPU 一个小时的视频,而批量处理 pipeline 需要约 352 秒来执行同样的操作:结果是速度提高了约 1.8 倍。

后续步骤

我们在自动扩展和负载均衡方面的努力只是性能优化工作的一部分,该工作使我们迄今为止的性能比基准提高了 89 倍,从而使工作流能够在一天内在 2k 个 H100 GPUs 上处理约 100 万小时的 720p 视频数据。

A bar chart shows processing time taken for the initial baseline implementation of the video processing logic taking 3.4 years to complete, compared with 41 days with the 31x speed-up resulting from the optimizations and efficiency of NeMo Curator run on H100 + L40S, and 14 days with the 89x speed up running on GB200 + L40S.
图 6。借助 NeMo Video Curator 缩短计算时间

* 在 2K CPU 和 128 个 DGX 节点上与 ISO 功耗相比的性能。

通过跟踪执行期间 NeMo Curator 工作流 GPU 阶段的工作者利用率,可以进一步证明 GPU 资源的高效利用。

A line graph shows GPU usage during a run of the NeMo Curator. Usage starts at 0% when the job starts, quickly jumps up to an average around 50% during the first stage, and then hits 100% from the second stage until the end of the run.
图 7。运行 NeMo curator 工作流期间的 GPU-worker 使用情况

图 7 显示,在初始预热期结束后,自动缩放器可以重新排列资源,使 GPU 阶段工作人员在超过 99.5% 的时间内保持忙碌状态。

我们在四个节点上使用 32 个 GPU 完成了这一实验。如果您使用更少的 GPU 运行,则 GPU 工作节点的使用量会更低,因为自动扩展程序的 GPU 分配粒度较粗。如果您使用更多 GPU 运行,GPU 工作进程的使用率将更接近 100%。

要通过示例进行解释,假设 GPU 阶段 X 比其他 GPU 阶段 Y 快 20 倍:

  • 在当前的 32-GPU 实验中,我们为 X 阶段分配了两个 GPU,为 Y 阶段分配了 30 个 GPU。
  • 在只有 8 个 GPU 的情况下,我们仍需为 X 阶段分配 1 个 GPU,为 Y 阶段分配 7 个 GPU,从而导致 X 阶段的 GPU 更频繁地闲置。
  • 借助 64 个 GPU,我们在 X 阶段使用了 3 个 GPU,在 Y 阶段使用了 61 个 GPU,实现了近乎完美的分解。GPU 阶段工作人员的总体利用率几乎达到 100%。

这正是我们在一项作业中增加 GPU 数量时观察到超线性吞吐量可扩展性的原因。

申请抢先体验

我们一直积极与各种早期访问账户合作伙伴合作,为视频数据管护实现出色的 TCO,为物理 AI 和其他领域解锁新一代多模态模型:

  • Blackforest Labs
  • Canva
  • Deluxe Media
  • Getty Images
  • Linker Vision
  • Milestone Systems
  • Nexar
  • Twelvelabs
  • 优步

您可以通过在 NVIDIA DGX Cloud 上抢先体验 NeMo Video Curator,无需自己的计算基础架构即可开始使用。将您对视频数据管护和模型微调的兴趣提交至 NVIDIA NeMo Curator 抢先体验计划,并在提交兴趣时选择“托管服务”。

NeMo Video Curator 也可以通过早期访问作为可下载的 SDK,适合在您自己的基础设施上运行,也可以通过早期访问计划获得。

 

 

标签