小红书数据引擎团队核心成员,负责 RED-Ray 分布式计算平台的研发与落地。专注 AI 数据基础设施方向,覆盖大规模预训练数据处理、模型离线刷库与近线推理入库等核心场景;主导向 KubeRay 开源社区提出并设计 KubeRay Federation 跨集群联邦方案(kuberay#4561)。在 AI 算力供给与弹性调度方向有丰富的一线实战经验。

小红书数据引擎团队核心成员,负责 RED-Ray 分布式计算平台的研发与落地。专注 AI 数据基础设施方向,覆盖大规模预训练数据处理、模型离线刷库与近线推理入库等核心场景;主导向 KubeRay 开源社区提出并设计 KubeRay Federation 跨集群联邦方案(kuberay#4561)。在 AI 算力供给与弹性调度方向有丰富的一线实战经验。
AI 数据生产贯穿模型研发的完整生命周期:模型诞生前,需要大规模准备预训练语料或 SFT 精调数据;模型上线前,需要对存量数据完成批量推理入库;模型上线后,需要对持续产生的增量数据实时推理入库。
这三个阶段对算力的诉求截然不同,没有一种资源供给模式能一劳永逸地满足所有场景。
小红书数据引擎团队以 Ray 为统一引擎底座,基于 Ray 引擎的统一调度能力与丰富的上层框架,覆盖了 AI 数据生产三个阶段截然不同的算力诉求——同一套引擎底座,通过不同的框架组合与资源供给策略,驱动从稳定常驻集群到海量弹性算力的全场景落地。
阶段一 · 训练数据准备: 预训练和 SFT 数据处理链路天然异构——去重依赖大规模 Shuffle,AI 质量打分依赖 GPU 批量推理,多模态内容处理需要高效的格式解析。我们在同一个 Ray 集群上通过 RuntimeEnv 沙箱隔离让 RayDP、Ray Data、Daft、DataJuicer 多种引擎共存协同,持续打磨万核百卡异构Ray集群稳定性。
阶段二 · 模型上线前离线刷库: 存量数据回扫是典型的"来得急、量级大、一次性"需求,但 GPU 资源天然离散在多家云厂商、多个可用区。我们经历了两代方案演进:第一代通过 Virtual Kubelet 将跨 K8s 集群的 CPU 混部资源汇聚为统一算力入口;第二代提出"存算分离"架构,以稳定 CPU 集群承载数据编排,通过 Ray Serve 联邦驱动弹性 GPU 资源完成推理,支持行级重试与断点续推,将原本因资源离散导致的长尾问题大幅收敛。此外,我们正在向 KubeRay 开源社区提出 KubeRay Federation 方案(kuberay#4561)。
阶段三 · 模型上线后近线增量入库: 新笔记、新商品需要分钟级持续入库,流量波动大且需要7*24h运行。我们自研了流批统一引擎 Ray Klein,基于 Chandy-Lamport 快照算法实现精确 Kafka offset 断点恢复,支持一套业务代码在全量批推与近线增量之间无缝切换。
本演讲将以这三个阶段为线索,分享 Ray 引擎如何凭借统一的调度底座,通过不同的框架组合与资源供给策略,覆盖 AI 数据生产全生命周期中截然不同的算力诉求,以及我们在工程实践中形成的核心判断:算力供给模式必须匹配业务阶段的特征,而非用单一模式覆盖所有场景。
演讲提纲:
听众收益:



微信咨询

电话咨询
微信联系我们

