从模型诞生到上线：Ray 在小红书 AI 数据生产中的算力调度实践｜AICon上海

从模型诞生到上线：Ray 在小红书 AI 数据生产中的算力调度实践｜AICon上海

一句话看懂：小红书数据引擎工程师陈宇将在AICon上海大会上，首次公开分享他们如何用一套基于Ray的算力调度体系，贯穿AI模型从训练数据准备、到离线推理、再到实时入库的全生命周期。这套方案的核心判断是：算力供给模式必须匹配业务阶段，而非一刀切。

事件核心：发生了什么

小红书数据引擎团队以Ray为统一底座，构建了一套覆盖AI数据生产全流程的算力调度方案。该方案将AI数据生产划分为三个阶段：训练数据准备（稳定常驻集群、多引擎如RayData与DataJuicer协同）；离线刷库（短期爆发、容忍驱逐、跨云GPU弹性）；近线增量入库（7×24小时流式处理、分钟级延迟、精确断点恢复）。团队通过不同框架组合与资源供给策略，驱动了弹性CPU上亿核时/月、GPU百万卡时/月的算力规模。陈宇在本次演讲中将详细拆解三个阶段的工程实践：训练数据阶段如何用RuntimeEnv做依赖隔离并解决大规模集群的GCS与日志稳定性；离线刷库阶段如何从Virtual Kubelet跨集群聚合演进到KubeRay Federation联邦调度；近线入库阶段自研了Ray Klein，基于一致性快照实现Kafka offset级恢复与自动反压平衡。

为什么重要

这一实践回答了当前AI基础设施领域的一个核心矛盾：不同业务阶段对算力的需求差异极大（稳定长期vs.瞬时爆发vs.流式持续），而行业常见做法是为每个阶段部署一套独立引擎，导致维护成本高、资源利用率低、数据流转割裂。小红书的方案证明了Ray作为统一调度底座，通过KubeRay Federation跨集群联邦、Ray Klein流批统一等创新，能够在一个技术栈内兼容多种算力供给模式。这直接降低了AI数据生产链条的工程复杂度，尤其是对于需要同时管理预训练、SFT增量训练和线上推理的中大型团队，具备很高的参考价值。陈宇作为KubeRay Federation方案的提出者，其经验推动了Ray开源社区在跨集群调度方向的发展。

对用户/开发者/创作者的影响

对于AI应用开发者和数据工程师：如果你正在自建或使用大模型，这套方案中的流批统一引擎Ray Klein的设计思路可以直接借鉴——它解决了离线与近线代码割裂的痛点，一套代码支持流批处理，并通过检查点粒度保障可靠性。对于企业技术决策者：小红书的经验表明，选择算力调度方案时，应优先评估其是否支持异构资源（CPU/GPU/Multi-Cloud）和弹性扩缩容，而非仅关注单点吞吐性能。对于依赖AI能力的内容创作平台：这类底层基础设施的优化，最终会通过更快的模型迭代周期和更稳定的在线推理服务体现为产品体验的提升，例如推荐内容生成延迟的降低。

值得关注的后续

目前公开信息显示，小红书团队将在社区推进KubeRay Federation的成熟度，并探索Ray Serverless化以及Daft（分布式DataFrame）在多模态数据处理中的规模化落地。这些进展将直接影响Ray生态在多模态大模型训练数据工程领域的实用性。另外，InfoQ的大会（6月26-27日）上，其他50余家企业的演讲也可能揭示更多关于Agent工程化、智算架构升级的对比案例，值得从事AI infra的开发者保持跟踪。

来源：InfoQ CN