Ray Data 多模态管线架构：GPU 利用率 35% 到满负荷的分解式流式方案

一句话结论

Anyscale AI 工程师 Marwan 用一场 52 分钟研讨会讲透多模态 AI 管线的核心矛盾：视频、激光雷达等重数据让 GPU 长期饥饿在 35% 利用率，解法是”分解式流式”——CPU 预处理集群与 GPU 推理集群独立伸缩、流式衔接，Ray Data 用动态重分区和背压把这套架构变成了几行 Python 代码。

多模态数据把 GPU 饿到 35%

研讨会开场直接抛出问题：自动驾驶场景中，单条训练样本包含视频、激光雷达点云、传感器数据和文本标注，动辄几百 MB；百万级样本的训练管线就是几百 TB 到 PB 级数据量。同样的模式正在物理 AI、多媒体市场、生物科技（影像+测序数据）等行业重演——主讲人特意强调这不是自动驾驶的专属问题，而是”数据天然变多模态”的行业趋势。

具体到一条视频处理管线：先从对象存储下载 MP4 到磁盘，CPU 解码成帧，送模型（视觉语言模型或目标检测/感知模型）做嵌入或推理，结果再写回对象存储。整条链路混合了 IO、CPU 密集和 GPU 密集三种性质完全不同的负载。

Marwan 给出的典型观察是：GPU 利用率往往只有 35% 左右，而目标应该是 90%。原因有三：视频大小不均导致负载失衡，batch 要按最大视频预留；CPU 解码和变换是资源密集型操作，GPU 只能干等 batch 到位；贵重的加速器长时间运行在过小的 chunk 上。结果是花大钱买的 GPU 只跑出三分之一的算力，吞吐和成本双双受损。

两种天真架构的代价

方案一：分阶段批处理。 用 Spark 之类工具先把视频全部预处理成帧、写入 S3，再把帧读进 GPU 集群。问题在于中间数据爆炸——500 TB 压缩视频解成帧后可能变成 PB 级；预写回读是无谓的往返；最重要的是前一阶段跑完之前 GPU 全程闲置。唯一好处是中间产物落盘可查、可调试，但后文会说明流式方案同样能做调试。

具体展开这笔账：分阶段执行的时间线是”读完所有视频 → 全部预处理 → 写出帧 → 再读进 GPU”，四个环节串行。压缩视频解成帧的体积放大通常是数量级的，PB 级中间数据的存储成本、写入读出时间、以及这一来一回占用的网络带宽全部是纯开销。GPU 集群在第一个阶段结束前的每一分钟都在烧钱空转。主讲人特别点出：这个格局会随着数据集变大而持续恶化，不是”忍一忍就过去”的问题。

方案二：全塞进 GPU 节点。 视频在 S3 上切好，直接均衡负载到 H100 节点。算一笔账：一台 8 卡 H100 节点通常只配 192 个 CPU 核，摊到每张 GPU 只有 24 核——对重预处理远远不够；换 A100 时代更是只剩 12 核/GPU。CPU 比例卡死后 GPU 照样闲置，且数据倾斜仍会造成长尾。优点只是架构简单：只有 GPU 节点、把视频分发上去就行。

两种方案的共同死穴：CPU 与 GPU 的比例在硬件层被焊死，你无法独立地扩预处理。

解法：分解式流式与四个分布式原语

Anyscale 的主张是”分解式流式”（disaggregated streaming）：预处理 CPU 集群与 GPU 集群彻底分开、独立伸缩，CPU 侧持续产出均匀 batch 流式喂给 GPU，GPU 时间线从锯齿状变成持续饱和。同时 CPU 侧做动态重分区，保证每个 batch 大小一致。这样中间数据不再物化落盘，执行重叠流水线化——CPU 在解码下一段视频时，GPU 正在处理上一段。收益清单直接来自主讲人的总结：不付中间存储和物化的成本；CPU 与 GPU 独立扩缩，不再受单节点比例约束；读取和预处理始终跑在 GPU 前面（流水线重叠）；重分区让 GPU 均衡进食。

支撑这套架构需要四个分布式原语，全部由 Ray 提供：

• 有状态 worker（actor 模型）：模型加载一次、持续处理多个 batch。对比无状态 task 模型每轮重新加载模型的浪费——对视觉语言模型这种加载即数十秒的负载，这是数量级的差别。
• 增量输出（streaming generators）：CPU 解码出足够一个 batch 就立刻发送，不等整段视频处理完。
• 高效数据传输（Ray object store）：节点间用 gRPC 协议高效传输，节点内多进程共享内存。C++ 实现，纯内存存储。
• 细粒度容错（lineage）：单个 batch 失败只重跑那个 batch，不重放整条管线；节点被抢占后按 lineage 追溯重建数据继续推进，分布式调度无单点。

现场问答补充了 object store 细节：它是内存池，满载时 Ray Data 会先触发背压而不是直接溢写磁盘；磁盘溢写只作为最后安全阀。另有观众问多节点计算对比分布式训练优势何在，主讲人的回应点破了一个常见误区：分布式训练和多模态推理管线面临的是同一个问题——GPU 必须持续被喂数据，昂贵预处理无论是塞进 GPU 盒子还是拆成独立阶段都在付同样的代价，Ray 架构对两者一视同仁。

Ray Data：把架构变成几行代码

Ray Data 在四原语之上实现流式执行引擎，核心概念是 block：读取和预处理阶段产出大小均匀的 block（约 128 MB）流入 object store，再按下游模型最合适的 batch 尺寸分发给 worker。四个关键机制：

• 动态重分区：每个 stage 之后流式重切，解决静态分区浪费；下游按需取用。
• 自动伸缩 actor 池：给视觉语言模型（如 Qwen）起多个副本，block 自动负载均衡到副本。
• 动态资源分配：管线启动初期没有东西可写，CPU 全给读取和预处理；随着推进再动态调整读/写 CPU 配比，最大化吞吐。对比静态分配（例如固定 80% 读、20% 写）的浪费：启动阶段写侧闲置、稳态阶段配比又未必最优。
• 背压（backpressure）：队列式跟踪各 stage 输出，GPU 跟不上时自动暂停上游提交，内存保持有界。磁盘溢写只作为最后的安全阀，正常工况不触发。

背压机制值得多看一眼，因为它是”内存有界”的关键。观众中有人指出 object store 是个装未压缩数据的巨型内存池，涨到上限要么溢写磁盘要么背压。主讲人回应：两者都由 Ray Data 控制，策略是优先背压——当队列达到容量阈值，暂停提交读取和预处理任务，等 GPU 消化掉存量再恢复。这样既不丢数据也不用碰慢速磁盘，代价只是上游短暂降速，而这恰恰是流式架构预期的行为：整条管线的速度由最慢的环节决定，快的环节自动对齐。

API 层面是声明式的三段式：read_videos 指向 S3 的 MP4 → map_batches 传入 Qwen 视觉语言模型处理帧 → 写出 Parquet。执行是惰性的，Ray Data 拿到变换图后自行优化执行计划，再落到 task/actor 原语上。主讲人现场念了这段代码，全部逻辑不超过十行——对比手写 Spark 作业加自管 GPU 调度的传统方案，这就是”分解式流式”从架构理念变成工程实践的距离。

客户账本：Bedrock 85 倍扩展、字节选型对比、Notion 嵌入

三个真实客户背书这套架构的收益：

• Bedrock Robotics：“我们的负载既用 CPU 也用 GPU，能混搭吞吐才是最优配置——Spark 根本不是为此设计的。“在 Anyscale 平台上无缝扩展 85 倍算力。机器人负载的特点是预处理（传感器数据解码、点云处理）和推理（策略模型）交替出现，单一类型集群怎么配都浪费。
• 字节跳动：“对比 Spark 等方案，Ray（尤其是 Ray Data）在大规模模型并行推理上更灵活、更可扩展。“这家以数据工程规模著称的公司把 Ray Data 用在模型并行推理上，选型证词的分量在于对比对象正是 Spark 系。
• Notion：用 Ray Data 大规模生成嵌入，“水平扩展开箱即用，低延迟推理随业务增长无缝扩容”。文档类产品的嵌入生成是典型的”重 CPU 预处理（分块、清洗）+ GPU 推理”混搭管线，正是分解式流式的目标场景。

主讲人补充：更多客户案例可在 Anyscale 官网和每年 Ray Summit 大会上找到，这里只挑了三家有公开证词的。三家分别覆盖机器人、互联网大模型推理、SaaS 文档产品三个行业，负载形态各异但架构诉求同源。

演示：Claude Code 装技能生成 Ray 管线

Demo 环节展示了 Anyscale 平台的 agentic 开发体验：给 Claude Code 安装 Anyscale 技能包（platform/infra/workload 三类，其中 workload 含 Ray Data 和 Ray Train 技能——离线批推理用 Ray Data，分布式训练用 Ray Train，在线常驻服务用 Ray Serve），启动后技能会逐步询问管线的用途（离线批推理？是否含 LLM 推理？），生成 spec 后自动产出管线代码文件和提交作业用的 job.yaml。

Marwan 给 Claude 的指令只需四要素：指向 S3 视频路径、输出路径、最多用 2 张 GPU、三个阶段（读 MP4 → 帧送 Qwen → 写 Parquet）。Agent 自动生成管线文件，通过 job.yaml 一条命令提交到集群。主讲人坦言现场跑生成要几分钟，所以展示的是提前用同一流程生成的结果——流程本身零剪辑。

运行后在 UI 里能看到 DAG 视图（解码 → vLLM 准备 → 视觉语言模型推理 → detokenize → 写 Parquet）、每个节点的结构化日志、按节点粒度的硬件利用率（CPU/内存/磁盘/GPU/DRAM/功耗，DCGM 指标也齐）。作业提交后集群自动拉起，跑完的作业可以看到写出了多少行结果。日志可程序化下载——下载下来喂给自己的 Claude agent 做诊断是明确演示的工作流。

排障同样 agentic：把作业路径丢给 Claude 说”DRAM 使用有毛刺，帮我看看怎么优化 GPU 利用率”，它会自己去读日志和指标、给出优化建议。这呼应了 Q&A 里”能否用历史运行统计优化后续运行”的问题——Anyscale 侧内置了 agentic 调优系统帮助迭代管线参数，把调优经验沉淀成 agent 能力而不是留给用户人肉试参。

主讲人最后给的行动指引也简单直接：下一步去读 Ray Data 官方文档（Ray 文档站内），感兴趣的可以上 Anyscale 试用平台，Bedrock Robotics 和 Notion 的客户故事是公开的，可对照本文的架构叙述细读。

现场观众画像：谁在为多模态管线发愁

研讨会中段 Julian 发起两组现场投票，值得记录。第一组问观众正在处理哪类多模态数据，结果显示视频、图像、文本、文档、激光雷达全都有人举手——分布相当均匀，主讲人据此判断”接下来讲的内容对所有这些格式都适用”。第二组调查 Ray 的熟悉度，结果约七成观众处于探索阶段，少数已在生产环境使用。这场分享的实际定位由此变得清晰：帮探索期工程师建立”Ray 能解决什么问题、架构上为什么合适”的心智模型，而不是深入 API 细节。

这个画像对国内团队同样有参照意义：多模态数据管线的痛点（数据体积大、预处理重、GPU 昂贵但喂不饱）是跨行业通病，而选型阶段的工程师往往卡在”Spark 还是自研调度”的旧框架里，缺少”分解式流式”这个第三选项的认知。研讨会的价值在于把这个选项的完整逻辑链——问题定义、天真方案为何失败、正确原语组合、代码落地、客户验证——一次讲完。

观众的提问质量也侧面印证了内容深度：object store 的实现语言与故障行为、幂等性设计、K8s 网络要求、按列分区与嵌入缓存、并行分支编排、时间窗堆叠——这些都不是入门问题，说明参会者中有相当比例正在真实建设此类管线。

Ray Data 与 vLLM 的组合细节

Ray Data 对推理引擎的集成值得单独说明。视觉语言模型普遍通过 vLLM 部署，Ray Data 的 actor 池会拉起多个 vLLM 副本，把解码好的帧 block 自动负载均衡过去，输出 detokenize 后流式写入 Parquet。整个 DAG 在平台 UI 里清晰可见：读取 MP4 → 解码 → vLLM 准备 → 模型推理 → detokenize → 写出。主讲人强调这个 DAG 视图不是花架子——分布式系统里每个节点有自己的日志、每个组件有自己的日志，能在一处看到全链路是排障的第一需求。

细粒度容错在这里同样生效：某个 block 对应的副本挂掉，管线其余部分继续跑，失败 block 走恢复流程重新生成再写出——对长时间运行的批作业，这决定了”挂一次重跑三天”还是”挂一个补一个”。

Block 机制再补充一层：128 MB 的目标 block 尺寸是 Ray Data 在”并行度”与”传输开销”之间权衡的结果。block 太小则调度和传输的固定成本占比飙升，太大则流水线容易卡顿、内存压力大。观众问答中有人问”能不能按数据集特定列做细粒度分区”（例如按安防摄像头 ID 分区，让重叠帧命中同一个 VLM 副本的嵌入缓存），主讲人确认 Ray Data 支持指定分区键并禁止重切，也支持在线 group by 加全量 shuffle 重分区——这是把缓存友好性做进管线拓扑的具体手段。

另一个实操问题关于时间窗：有些视频任务没有帧级独立性，需要堆叠时间窗做处理。主讲人给出两条路——数据在盘上已按窗口切好时直接告诉 Ray Data 不要重切，整窗口流入推理；需要动态切窗时把每个窗口作为数据集的一行，逐行跑 stage，“需要一些数据整理功夫，但客户高频使用”。

还有观众关心并行分支：多类数据各自变换后汇入同一训练管线怎么办。答案有二：没有严格依赖的变换按序串跑即可（Ray Data 自动流水线化，实际效果接近并行）；确需并行分支结构时，下沉到底层 Ray 框架编排。这说明 Ray Data 的声明式 API 覆盖常见拓扑，复杂图结构留了逃生门。

Q&A 环节沉淀了几个值得记录的实操判断：

1. 幂等性：Ray Data 内置变换天然幂等；自定义 UDF 的幂等性责任在用户，设计管线时要保证重试无副作用。
2. CPU/GPU 网络分离：实践中不做 CPU 与 GPU 的硬切割，GPU 节点自身 CPU 仍参与，只是用独立 CPU 节点补充。只要数据供给跟得上 GPU 消费速度，网络不是瓶颈；要硬切才需要网络优化型节点。
3. 并行分支汇合：多类数据各自变换后汇入同一训练管线时，两个选择——没有严格依赖的变换按序串跑即可（Ray Data 会自动流水线化）；确需并行分支时直接用底层 Ray 框架编排。
4. 时间窗堆叠：数据在盘上已按窗口切好时，告诉 Ray Data 别再重切，整窗口直接流入推理；需要动态切窗就把每个窗口作为数据集一行，逐行跑 stage。
5. 学习率随 GPU 数自动缩放（Ray Train + Lightning 集成）：学习率按 per-worker 设置，GPU 扩缩时自动调整，多任务训练的复杂调度策略暂未成为瓶颈。
6. 数据隐私：PII 脱敏在数据准备步骤完成，且因为整条数据环路是迭代的，新标准可以回填重处理历史数据。

部署形态上：Anyscale 常见模式是部署在客户自己的云账号（BYOC），直接用客户预留的 GPU，HIPAA 等合规场景走客户 VPC；也可由 Anyscale 提供算力。作业调度支持每日定时运行，也支持自有编排器通过 CLI 提交。Ray 本身是开源的，任何 Kubernetes 集群都能跑，Anyscale 的增值在于开发体验与调优工具链。

可观测性与调优闭环：从指标到 agentic 诊断

Demo 后半段聚焦 observability。Anyscale 平台对每条管线提供多层指标：管线级吞吐（每秒产出字节数）、按节点的硬件利用率（CPU、内存、磁盘、GPU、DRAM、功耗），GPU 细粒度指标走 DCGM。日志带结构化元数据，可程序化下载——下载下来喂给自己的 Claude agent 做诊断，是主讲人明确演示的工作流。

这个环节的实际意义在于把”调优”从专家经验变成可复现的流程：先看吞吐曲线判断 GPU 是否饥饿（对应管线问题），再看 DRAM 毛刺（对应 batch 尺寸或 shuffle 策略），最后把作业路径交给 agent 技能自动分析日志给出建议。对缺分布式系统专家的团队，这套闭环等于把 Anyscale 的调优经验产品化了。

给选型者的三条判断依据

综合整场内容，对正在为多模态管线选型的团队，可以提炼三条直接可用的判断：

1. 先算 CPU/GPU 比例账。如果你的预处理（解码、变换、增强）重到单节点 CPU 喂不饱 GPU（24 核/GPU 以下要警惕），分解式流式是唯一正解，分阶段批处理会把中间数据放大并让 GPU 空转。
2. Spark 不是多模态管线的对标物。Bedrock 和字节的选型证词都指向同一点：Spark 为批式表格数据设计，多模态重预处理+流式推理的混搭负载需要的是 actor 池+流式 generator+细粒度容错的原语组合。
3. 调优能力必须内建，不能靠人肉。背压、动态重分区、按节点指标、agentic 诊断——这些决定了管线从”能跑”到”持续跑在 90% 利用率”的距离。

最后一条来自结尾问答的补充：有观众问统一内存节点（unified memory）对 Ray 是否有额外收益，主讲人的回答很克制——Ray 最终只是在节点上编排 Python 进程并高效传输数据，节点层的任何硬件优化它都能自然受益，没有也不需要特殊适配。这侧面印证了 Ray 架构的通用性：它不挑硬件，挑的是负载形态。

原文信息

• 原视频标题：Multimodal data: Architecting pipelines that don’t break at scale
• 频道：Anyscale
• 讲者：Marwan（Anyscale AI 工程师）、Julian（产品 GTM 负责人）
• 发布日期：2026-05-14
• 视频时长：约 52 分钟