Video Captioning at scale: 600 TB in 95 minutes with Anyscale on CoreWeave

大规模视频字幕生成：600 TB仅需95分钟 | CoreWeave博客

发布于

2026年8月25日

5

分钟阅读

在CoreWeave上使用Anyscale实现大规模视频字幕生成：600 TB仅需95分钟

作者

Jeff Braunstein

Xinyu Zhang

已复制

数据处理现已成为GPU工作负载

大型语言模型（LLMs）的应用早已超越聊天场景。物理AI、药物发现、推荐系统和创意生成都需要相同的基础：经过发现、过滤并转化为模型可训练形式的互联网级多模态数据。

这项工作已无法仅依赖CPU完成。视频、音频、LiDAR和卫星数据需要解码、过滤、特征提取和归一化处理，而当规模达到艾字节级别时，必须使用GPU。搭建基础设施通常需要团队耗费数周甚至数月时间才能看到首个结果。

Anyscale与CoreWeave构建了覆盖数百万视频片段的字幕生成流水线，验证了这一流程的实际速度。从账户注册到生产作业启动：不到24小时。以下是实现过程及1600个GPU下的性能表现。

视频字幕生成的双层基础设施架构

两个层级共同支撑了这一流程，且彼此协同加速。在时间轴分析前值得单独说明：

Ray负责的部分

Ray开源项目与Anyscale负责工作负载层。Ray在集群中调度任务和Actor，通过流水线传输数据，并根据需求动态扩展工作者数量。Ray无法感知硬件状态，无法识别节点因过热限频或某个GPU卡顿导致阶段延迟。

CoreWeave底层负责的部分

CoreWeave层负责AI基础设施。CoreWeave Kubernetes服务直接在裸金属节点上运行Kubernetes，预装GPU驱动、网络和存储接口以及可观测性插件，这正是Anyscale安装仅需1小时而非整个季度的原因。CoreWeave Mission Control持续监控整个集群，评估节点和集群健康状况，提前发现可能拖慢作业的滞后节点并自动替换故障节点。

存储系统处于相同层级。CoreWeave AI对象存储（CAIOS）以无出站、请求或交易费用的单一全局命名空间保存数据集，CAIOS本地对象传输加速器（LOTA）在每个CoreWeave节点运行，绕过标准网关直接在本地NVMe缓存获取对象。这使得重复读取（尤其是模型权重）无需经过网络，可直接在GPU附近完成。

Ray Data决定任务分配位置并保持流水线持续运行。CoreWeave确保AI基础设施健康、存储速度足够支撑数据传输，并在节点失效时保持集群完整性。GPU易于分配却难以持续保持高利用率，这两者之间的差距正是工作负载层无需补偿的基础设施优势。

• 第1小时。Anyscale 以操作员安装的方式部署到 CKS，因为 CKS 已经处理了托管控制平面、GPU 驱动程序、网络和节点生命周期。

• 第2小时。编排测试：CKS 运行节点层，而 Anyscale 操作员运行 Ray 集群生命周期管理、GPU 自动扩展、工作负载放置以及开发者接口与预留资源的交互。

• 第10小时。我们在 Ray Data 中以单一流式作业的形式编写了流水线，其中 CPU 解码和过滤为 GPU 字幕生成提供数据。我们在 Anyscale Workspaces 中与实时集群进行交互式开发。

• 第15小时。我们通过 Anyscale Observability、CoreWeave AI 对象存储带宽和更快的模型加载方式，对 GPU 利用率和吞吐量进行了优化。

• 第20小时。我们将相同代码直接提升为具有容错能力的 Anyscale Job，无需重写，支持重试和自动扩展以完成全规模运行。

该流水线本身包含两个阶段。

• CPU 阶段：视频解码、场景边界分割和过滤。

• GPU 阶段：使用 Qwen3-VL-8B 对生成的视频片段进行字幕和注释推理。

从 Ray Core 到 Ray Data

我们的验证从简单开始。在将任何内容指向完整的 1,600 GPU 预留之前，我们先在固定池的 256 GPU 上针对 600 GB 数据集运行了流水线，也正是在这里首次发现了性能瓶颈。

首次视频字幕生成使用了 Ray Core。远程函数读取视频数据集并在 CPU 上解码关键帧：

@ray.remote(num_cpus=1) def read_and_decode_shard(path: str) -> List[Dict[str, Any]]: # 解码逻辑在此处

推理在 Ray Actor 上运行。Actor 是 Ray 固定到长期运行的工作进程的 Python 类，因此昂贵的状态只需初始化一次并在多次调用中重复使用，而不是每次请求都重新构建。每个 Actor 持有一个 GPU 和一个加载好的 vLLM 引擎。

我们手动创建和管理这些 Actor。驱动程序维护一个固定列表用于轮询调度，因此这种实现方式无法根据需求自动扩展：

@ray.remote(num_gpus=1) class CaptionActor: # vLLM 推理逻辑在此处 # 手动管理 Actor actors = [CaptionActor.remote() for _ in range(num_gpus)]

Ray Data 取消了这种管理方式。它流式执行并根据工作负载需求自动扩展资源。直接从 Parquet 清单读取数据，将数据摄入与视频解码解耦，实现更优的流水线处理：

直接优化的数据摄入 ds = ray.data.read_parquet(input_path, **read_kwargs) # 通过简单的映射操作应用解码逻辑 ds = ds.flat_map(decode_row, num_cpus=1)

批量模型推理已内置支持。无需通过 Ray Actor 部署和编排 vLLM 引擎，只需将配置传递给批量处理器，流水线即可简化为 read_parquet → flat_map → processor → write_parquet 的结构：

vlm_processor = build_processor( vLLMEngineProcessorConfig(**config_kwargs), preprocess=vlm_preprocess, postprocess=vlm_postprocess, ) ds = vlm_processor(ds)

将数据集扩展 1,000 倍，CoreWeave AI 对象存储同步扩展

大多数团队真正关心的问题不是流水线能否运行，而是当数据集扩大 1,000 倍时，单位工作成本会发生什么变化。我们对此进行了验证。

我们通过 Ray Data 流水线将 600 GB 数据集扩展到 600 TB，该流水线使用 FFmpeg 为每个视频生成 1,000 个合成变体。第一阶段通过关键帧裁剪和播放速率调整进行重新封装。第二阶段通过空间裁剪、翻转、颜色抖动、噪声、速度调整和 libx264 重新编码进行处理。

Anyscale 的开发者中心和 Ray 工作负载仪表板展示了此次扩展事件对基础设施利用率、吞吐量和工作负载分配的影响。在峰值时，35,820 个 CPU 核心将 43,700 个原始视频片段处理成了 7000 万个。

CoreWeave AI 对象存储以 40 GB/s 的速度吸收了写入请求，网络带宽达到饱和，PUT 操作的 p50 延迟为 9.1 秒，p99 延迟为 18.8 秒。

1,600 个 GPU 同时运行

在完整的 600 TB 数据集上运行视频字幕生成时，吞吐量保持稳定。即使没有缓存，CoreWeave AI 对象存储仍通过约 46 个 CPU 节点实现了 110 至 120 GB/s 的吞吐量，每个节点约 2.4 GB/s，整体处理了约 8,500 个单流 GET 请求。字幕生成在 95 分钟内完成。

视频字幕生成基准测试结果

Ray Core 与 Ray Data（600 GB 数据集）

将 43,700 个视频片段处理成 100 万个字幕时，Ray Data 使用了 Ray Core 所需 GPU 时间的 73%，并在每 GPU 小时内生成了 3.7 倍的字幕数量。自动扩展和计算流水线是造成这一差距的原因。流式处理持续为 GPU 提供数据；固定大小的演员池则无法做到这一点。

600 GB 与 600 TB

将 GPU 集群规模扩大约 6 倍，从 256 个扩展到 1,600 个 GPU，每 GPU 小时的字幕生成效率保持稳定。总吞吐量增长了 10.2 倍，从每秒 1,273 个字幕提升至每秒 12,666 个字幕。吞吐量的增长超过了集群规模的扩展，因为更大的 CPU 池使解码阶段始终领先于 GPU，而不是让 GPU 等待资源。

在无存储瓶颈的情况下为 1,600 个 GPU 提供数据

流式处理管道的速度取决于其底层存储。同时将 Qwen3-VL 加载到每个 GPU 上时，需要传输约 4.3 TB 的张量数据，最多有 255 个节点同时请求相同的数据块。这种“羊群效应”会压垮传统对象存储。

这就是 CoreWeave AI 对象存储的 LOTA 缓存组件发挥作用的地方。由于它在 CPU 和 GPU 节点本地的 NVMe 上进行缓存，第二个请求相同张量的引擎根本无需访问后端存储。

模型加载（17 GB Qwen3-VL）

• 每个引擎以 8.68 GB/s 的速度读取数据，LOTA 从本地缓存提供模型
• 整个 17 GB 模型在约 2 秒内加载完成
• 这比第三方对象存储快 1.88 倍，比 CoreWeave AI 对象存储的冷读快 1.28 倍

LOTA 是让 17 GB 模型在 2 秒内加载完成的关键。

数据集读取

对于原始数据摄入，1,357 个并行任务读取了 677 GB 的 MP4 文件。通过约 960 个并发单 CPU 读取器，CoreWeave AI 对象存储的流式传输保持在约 4.5 GB/s，耗时 140 秒完成。

实现大规模视频字幕生成的关键要素

在如此规模的数据处理中，整个技术栈的协同调度是关键，每一层都必须同时保持稳定：无需花费四分之一成本即可部署的托管 Kubernetes，能够保持 1,600 个 GPU 持续运行的调度器，以及永远不会成为瓶颈的存储系统。

在不到 24 小时内，从系统部署到生产就完成了处理 600 TB 视频和生成 7000 万个字幕的任务。如果您的数据整理积压以月为单位计算，瓶颈很可能不是您的模型。

如果您的流水线受存储限制，请从 CoreWeave AI 对象存储文档开始。

在 1,600 个 GPU 上处理 600 TB 视频所需的要素：从 Ray Core 迁移到 Ray Data，存储吞吐量，以及 24 小时内完成作业运行的路径。

分享本文： /think