Discord机器学习平台重构：基于Ray与Kubernetes的分布式训练实战

Discord 近期分享了其机器学习平台的重构历程。在单GPU训练模式遭遇瓶颈后，公司通过标准化 Ray 和 Kubernetes、引入一键式集群CLI、并利用 Dagster 与 KubeRay 实现工作流自动化，成功将分布式训练转变为一项常规操作。这一转变不仅使得大型模型的每日重训成为可能，还助力一项关键广告排序指标实现了200%的提升。

随着定制模型的规模和更新频率不断增长，Uber、Pinterest、Spotify等公司也报告了类似的工程演进。它们共同描绘了一条从手动、团队各自维护的GPU设置，转向共享、可编程平台的路径，该路径优先考虑一致性、可观测性和更快的迭代速度。

Discord 的转变始于团队各自为政的时期。当时，工程师们通过复制开源示例并针对每个工作负载修改YAML文件来独立创建Ray集群。这导致了配置漂移、职责不清以及GPU使用不统一等问题。平台团队因此着手通过标准化集群的创建与管理方式来使分布式机器学习变得可预测。

重构后的平台以 Ray 和 Kubernetes 为核心，但其定义更多来自于顶层的抽象。工程师通过一个CLI，指定高级参数来申请集群，该工具会基于经过验证的模板，生成运行Ray所需的Kubernetes资源。这消除了团队理解底层集群配置的需求，并确保调度、安全和资源策略能够被一致地应用。

训练工作流被整合进 Dagster，后者与 KubeRay 交互，将Ray集群的创建与销毁作为流水线的一部分。过去需要手动设置的任务，现在通过统一的编排层运行，集群的生命周期由系统自动管理。

Discord 还构建了名为 X-Ray 的用户界面，用于展示活跃集群、作业日志和资源使用情况。这些组件共同将分布式训练从一次性的定制设置，转变为可预测的工作流。

据公司介绍，新平台使得大型模型的每日训练成为可能，并降低了工程师采用分布式技术的门槛。团队能够在不直接依赖平台组介入的情况下，实施新的训练框架。这些改进最终转化为可衡量的产品收益，例如广告相关性的提升。

其他组织也描述了类似的转型。Uber 将其 Michelangelo 平台的部分迁移到基于 Kubernetes 的 Ray 上，并报告了更高的吞吐量和GPU利用率。Pinterest 构建了一个 Ray 控制平面来管理集群生命周期并集中日志与指标，减少了机器学习平台工程师的操作摩擦。Spotify 创建了“Spotify-Ray”，这是一个基于GKE的环境，用户可以通过CLI或SDK启动Ray集群，以统一实验和生产工作流。

然而，也存在关于内部机器学习平台局限性的警示。今年早些时候，CloudKitchens 在一篇文章中描述，其首个基于Kubernetes的系统变得过于复杂，简单的ML作业启动耗时超过十分钟，且基于Bazel的工作流给Python用户带来了持续的维护负担。

综合来看，这些案例表明行业正在转向具有更清晰抽象和更可预测工作流的共享机器学习平台。此类平台可以解锁更快的迭代速度和更可靠的分布式计算资源访问，但同时也可能引入自身的设计与维护权衡。提升平台的可观测性是应对这些复杂性的关键策略之一。