引言：模型训练之前，团队先被数据链路"训练"了一遍
一个多模态模型，从原始数据走到可训练状态，要经历多少步骤
以视频理解为例，团队需要先从对象存储读取海量视频，再完成格式校验、切分、抽帧、音频提取、画质过滤、图文匹配、内容安全检测和 Caption 生成；随后把处理结果转换为训练集，交给 GPU 集群进行分布式训练；训练结束后，还要保存模型产物、部署推理服务，并持续观察资源与任务状态。
问题在于，这条链路往往并不在一个平台里完成。
数据工程团队使用 Spark 和脚本做清洗，算法团队用 Python、OpenCV、Librosa 等工具处理图片和音视频，训练任务再迁移到独立 GPU 集群。不同系统之间反复导入导出，既带来数据搬运成本，也让环境、权限、依赖、调度和故障恢复变得更加复杂。当数据规模从 TB 走向 PB、数据类型从文本扩展到图片、音频和视频，这套"工具拼接式"架构会很快触碰上限：CPU 忙时 GPU 空闲，训练高峰又临时抢不到卡；长链路中的任一步失败，都可能导致任务从头再来；数据处理和模型训练彼此割裂，问题定位需要跨多个团队和平台。
企业需要的，不是再增加一个处理工具或训练框架，而是一套能够把多模态数据处理、模型训练与推理服务统一承载起来的生产级 Data+AI 基础设施。
基于腾讯云弹性 MapReduce（EMR）的 EMR-Ray，正在让这条链路变得更短：通过 Xpark 与 TCRay，将多模态数据处理、分布式训练和在线推理统一到同一套 Ray 技术栈与 CPU+GPU 异构资源池中，让数据少搬运、算力按需用、任务可恢复、链路可观测。"EMR-Ray"，指腾讯云 EMR 面向 Ray 工作负载提供的相关产品能力；在 EMR on TKE AI 部署形态中，可部署 TCRay 组件并创建 TCRayCluster。TCRay 是底层 Ray 运行与调度基座，Xpark 则是运行其上的分布式多模态数据计算引擎。
多模态AI进入生产，首先要跨过四道"断点"
真实的多模态 AI 项目，难点往往不只在模型本身，而在模型之前和之后的工程链路。
断点一：数据形态变了，处理方式仍停留在脚本拼装
传统数据平台擅长处理结构化表，但多模态场景面对的是文档、图片、音频、视频及其 Embedding。一次数据准备任务，常常需要串联 Spark、Python 函数、图像与音频工具库，以及多个模型推理服务。
工具多、接口多、依赖多，意味着开发调试周期长，也意味着每增加一种数据类型，都可能重新搭建一套处理链路。
断点二：数据处理与模型训练分属两套平台
数据完成清洗后，通常还要从大数据平台导出到训练平台。由此产生的，不只是一次数据复制，还包括权限重新配置、格式转换、环境适配和版本对齐。
当数据集频繁迭代时，"搬数据、等数据、核对数据"会成为训练流水线中最隐蔽的时间成本。
断点三：CPU 与 GPU 各自为战
多模态预处理并非全程依赖 GPU。格式解析、过滤、去重等任务更适合 CPU，Embedding、Caption 生成、训练和推理则需要 GPU。如果两类资源被拆分到不同集群，平台很难根据任务阶段灵活调度，容易出现一边排队、一边闲置。
断点四：长链路失败，代价被持续放大
多阶段任务可能运行数小时甚至数天。单条脏数据、单个节点异常或中间模型服务抖动，都可能让作业失败。缺少细粒度重试和 Checkpoint 时，团队只能全量重跑，不仅浪费算力，也会拖慢模型迭代节奏。
EMR-Ray：把Data、Train、Tune放回一条链路
腾讯云 EMR-Ray 的核心思路，是以 TCRay 作为统一调度与运行底座，衔接 Ray Data、Ray Train 与 Ray Serve，并以 Xpark 提供开箱即用的分布式多模态数据处理能力；Ray Tune 则可用于超参数搜索和并行实验。
在这套架构中，企业可以通过 COS、HDFS、CFS 等方式接入数据；使用 Xpark 完成文本、图片、音频、视频的分布式预处理；处理后的数据直接进入 Ray Train 开展分布式训练，并可结合 Ray Tune 进行超参数搜索；训练完成后，再通过 Ray Serve 承载在线推理服务。
整个过程中，TCRay 负责 CPU 与 GPU 的统一调度、任务恢复、资源弹性和运行时隔离，Ray Dashboard 则提供作业、节点、Task、Actor 与资源使用情况的可视化观测。
EMR-Ray 端到端架构图
这意味着，多模态数据处理和模型训练不再是两段彼此割裂的任务，而是运行在同一套基础设施上的连续 Pipeline。
第一步：多源数据统一接入，让训练数据"就地开工"
EMR-Ray 支持从 HDFS、CFS、本地文件系统以及腾讯云对象存储 COS 读取数据。对于企业已有的大数据资产，可以在保留原有存储体系的基础上接入 Ray 计算链路；对于需要反复迭代的数据集，中间结果也可以写回 COS，以对象存储承接数据复用和版本沉淀。
相比先把数据下载到单机、处理后再上传训练平台，分布式读取与统一存储访问可以减少不必要的中间落盘和跨平台搬运。数据工程师与算法工程师围绕同一份数据工作，也更容易保持数据口径、权限和版本的一致性。
第二步：Xpark 把多模态预处理从"脚本工程"变成标准化 Pipeline
Xpark 是腾讯云自研、基于 Python 生态的分布式多模态数据计算引擎，底层基于 Ray Data 扩展 Xpark DataSet，覆盖文本、图片、音频、视频等多种数据类型，并内置数十种常用处理算子与 Pipeline。
在典型多模态任务中，开发者可以使用统一的 Dataset 语义串联：
-
文本处理：清洗、语言识别、质量过滤、MinHash 去重、Exact Substring 去重、隐私脱敏、Tokenization；
-
图片处理：解码、尺寸与质量过滤、数据增强、Embedding、图文相似度筛选、内容理解；
-
音频处理：音频抽取、格式转换、语音识别与内容分析；
-
视频处理：视频切分、关键帧抽取、画面质量过滤、Caption 生成与安全检测；
-
模型调用：调用兼容 OpenAI 协议的内置开源模型、外部模型 API 或企业自定义模型。
过去，完成这些任务往往需要在 Spark、Ray Data、Python 函数和模型服务之间多次切换；现在，处理链路可以在同一套 Python 生态下完成编排，并根据算子特点按需使用 CPU 或 GPU。
Xpark 的文本 MinHash 去重算子性能可达 Data-Juicer v1.4.2 的 8.5 倍，分布式 Exact Substring 去重较对比的开源版本快 47.8 倍。测试结果会随数据规模、集群规格、参数配置与算子组合变化，实际效果请以业务环境验证为准。与此同时，Xpark 通过算子级重试、任务重分配、异常数据跳过、血缘重建和任务级 Checkpoint，降低局部故障触发全量重跑的概率。
对企业而言，Xpark 的关键价值不是再提供一批函数，而是把多模态处理从个人脚本变成可以复用、调度、恢复和治理的平台任务。
Xpark架构图
第三步：处理结果直接进入 Ray Train，减少跨平台等待
数据准备完成后，训练任务可以继续在 EMR-Ray 上执行。
Ray Train 提供统一的分布式训练接口，兼容主流深度学习框架。以 PyTorch 为例，开发者可以通过训练封装自动完成 DistributedDataParallel、分布式采样、设备与通信环境设置，再通过 ScalingConfig 配置 Worker 数量及是否使用 GPU，将本地训练代码扩展为多节点训练任务。
对于模型开发团队，这种衔接方式带来三点变化：
-
减少跨平台数据搬运。预处理结果可直接被训练任务消费，减少导出、复制和二次校验；
-
训练规模可以按需扩展。从单机验证到多 Worker、多 GPU 训练，保留统一的 Python 开发体验；
-
实验流程更容易标准化。可开展大规模超参数搜索和并行实验，减少手工管理多组训练任务的复杂度。
TCRay 进一步面向腾讯云大数据 AI Infra，对 Ray Core、Ray Data、Ray Train、Ray Serve 进行优化，增强作业调度、任务恢复、资源弹性、运行时隔离和大规模作业稳定性。在同一套底座上，企业可以覆盖分布式训练、大模型微调、批量推理、RAG 和多 Agent 等多类 AI 工作负载。
RayCluster创建流程
第四步：从训练结果到推理服务，形成可持续迭代的闭环
模型训练不是终点。训练完成后，企业还需要开展模型评估、产物保存、批量推理或在线服务部署。
批量推理可以继续沿用 Ray Data 等离线处理链路，在线推理服务则可通过 Ray Serve 部署；离线数据处理、训练和在线推理可以复用同一套资源体系。对于存在明显波峰波谷的业务，平台可以根据负载调配资源，避免长期按峰值为推理或训练分别预留集群。
与此同时，处理结果、特征、Embedding 和模型产物可以写回 COS 或统一数据湖，形成"原始数据---处理数据---训练集---模型---推理结果"的数据闭环，为后续增量训练、效果评估和版本回溯提供基础。
不只是跑通，更要在生产环境里跑稳、跑省
把 Demo 跑起来，并不等于能够长期支撑生产。EMR-Ray 更关注整条链路的工程化能力。
CPU+GPU 统一调度：把资源用在更合适的阶段
多模态任务中的数据解码、清洗、过滤、去重和训练，对资源类型的需求并不相同。TCRay 以 CPU+GPU 统一调度为基础，让不同阶段按需申请异构资源，并支持在数据处理、训练与推理任务之间复用资源池。
对于高优先级训练任务，可以保障资源供给；在业务低峰期，则可通过弹性能力减少闲置资源。相比为数据处理和 AI 训练分别维护独立集群，统一底座有助于降低资源碎片与重复建设。
细粒度容错：让长链路不因一个异常从头再来
Xpark 提供算子级重试、任务重分配、跳过策略、血缘重建和任务级 Checkpoint；TCRay 则在任务恢复与大规模作业稳定性方面持续增强。两者结合，可以缩小故障影响范围，降低多阶段作业全量重算的概率。
可视化观测：从作业状态看到资源与执行细节
通过 Ray Dashboard，用户可以查看作业状态、Task 与 Actor 执行关系、节点健康度、CPU/GPU 分配、日志与 Task Timeline，定位序列化、调度、执行或资源使用上的瓶颈。对于跨数据处理和训练阶段的问题，统一观测入口也能减少团队之间反复排查与信息对齐。
开放生态：保留企业已有框架与模型资产
EMR-Ray 以开源 Ray 生态为基础，支持企业继续使用熟悉的 Python、PyTorch、TensorFlow 和 scikit-learn 等工具，并支持veRL，支持上传自定义镜像；多模态部分Xpark 支持外部模型 API、自定义模型、自定义算子和自定义镜像接入，避免平台能力与企业既有技术资产割裂。
结语：Data+AI的下一站，是一条真正连续的生产线
过去，企业建设 AI 平台时，往往先关注"选择什么模型、购买多少 GPU"。但进入多模态 AI 规模化落地阶段，更值得追问的是：数据能否高效变成训练集？CPU 和 GPU 能否统一调度？处理与训练失败后能否快速恢复？模型上线后能否持续迭代？
答案不应是继续堆叠更多孤立工具。
基于 EMR-Ray，腾讯云弹性 MapReduce 正在把多模态数据处理、分布式训练与推理服务收敛到一套统一、弹性、可观测的 Data+AI 计算底座上：Xpark 让文本、图片、音频和视频的处理流程更标准化，Ray Train 让模型训练自然衔接，Ray Serve 承接推理服务，TCRay 则统一管理底层 CPU 与 GPU 资源。
从一份原始视频、一批图文数据，到一个可训练、可部署、可持续迭代的模型，企业需要的不再是若干条彼此断开的流水线，而是一条真正连续的 AI 生产线。Agent 所需的持续数据供给和快速进化，也将由此获得统一的落地载体。