SageMaker+Kubernetes混合架构：Lyft重构LyftLearn训练与推理

Lyft 近期对其机器学习平台 LyftLearn 进行了重构，采用“离线计算上云托管、在线推理保留自建”的混合方案：将训练与批处理等离线工作负载迁移到 AWS SageMaker，同时继续使用 Kubernetes 承载在线模型服务。该决策思路是：在运维复杂度最高的环节优先使用托管服务，在需要成本效率与控制力的环节保留自定义基础设施。

架构拆分：Compute 迁移 SageMaker，Serving 继续跑在 Kubernetes

LyftLearn 主要由两部分组成：

• LyftLearn Compute：负责训练、批处理等离线计算
• LyftLearn Serving：负责实时在线推理（inference）

工程团队将 LyftLearn Compute 迁移至 AWS SageMaker，以减少在自建批处理计算基础设施上的投入；而 LyftLearn Serving 保留在 Kubernetes 上，因为现有架构已能满足性能要求，并且与内部工具链结合紧密。

迁移动因：自建离线计算的运维成本持续攀升

LyftLearn 每天支撑数亿次预测请求，覆盖派单优化、定价、风控等业务；平台每天运行数千个训练任务，服务数百名数据科学家与机器学习工程师。平台最初完全构建在 Kubernetes 上，但随着规模扩大，运维复杂度显著增加：

• 新增任意 ML 能力往往需要额外的编排与控制逻辑
• 为了同步 Kubernetes 状态与平台数据库，需要维护多个 watcher 服务
• 事件乱序、容器状态迁移等带来“最终一致性”的状态管理问题
• 集群自动扩缩容与后台守护服务消耗大量工程时间

在这些问题上，离线计算尤其“重运维”，成为团队优先下放给托管服务的部分。

SageMaker 如何缓解离线痛点：事件驱动与按需资源

对离线工作负载，SageMaker 的托管能力直接命中痛点：

• 以 AWS EventBridge + SQS 替代 watcher 架构，转为事件驱动的状态管理
• 采用按需资源拉起，减少闲置集群容量带来的成本浪费

但迁移并非“改代码就能跑”，团队要求对既有 ML 代码保持高度兼容，避免大规模重写。

关键实现：跨平台 Docker 镜像与 Train-Serve 一致性

Lyft 构建了跨平台的 Docker 镜像，使 SageMaker 中的运行时尽可能复刻 Kubernetes 环境，并在镜像/兼容层中透明处理：

• 凭证注入（credential injection）
• 指标采集（metrics collection）
• 配置管理（configuration management）

这种兼容层还带来一个重要收益：同一份 Docker 镜像既用于 SageMaker 训练，也用于 Kubernetes 服务部署，从机制上减少了 train-serve 不一致问题，提升线上稳定性与可回溯性。

启动时延优化：SOCI 索引与 Warm Pools

对于每 15 分钟重训一次的时延敏感工作负载，团队需要把 SageMaker 的启动耗时压到接近 Kubernetes 的水平。为此他们引入：

• Seekable OCI（SOCI）索引（用于 notebook 场景）
• SageMaker warm pools（用于训练任务）

以缩短镜像拉取与实例冷启动时间。

复杂难点：Spark 在 SageMaker Studio 与 EKS 间的双向通信

迁移中最棘手的问题之一来自 Spark：其执行器（executors）需要对 notebook 驱动（driver）发起入站连接，但 SageMaker 默认网络设置会阻断这类入站通信，导致 Studio 与 EKS（Kubernetes 集群）之间的联动受限。

Lyft 与 AWS 协作，在 Studio Domains 中启用自定义网络配置，解决了 Spark 的网络连通性问题，并未引入明显性能损失。

灰度方式：按仓库逐步迁移、双栈并行

迁移采取“repository by repository”的节奏推进，两个基础设施并行运行，只需做少量配置改动即可逐步切换。Lyft 表示迁移后：

• 基础设施相关故障（incidents）减少
• 工程团队从繁琐运维中释放出来，将精力转向 ML 平台能力建设与迭代速度提升

平台工程的关键不在于你运行了什么技术栈，而在于你隐藏了多少复杂度、释放了多少交付速度。——Lyft 工程团队总结

架构图：LyftLearn 混合高层架构

图源：Lyft 工程博客

延伸阅读

• Lyft 工程博客原文：https://eng.lyft.com/lyftlearn-evolution-rethinking-ml-platform-architecture-547de6c950e1
• AWS SageMaker 介绍：https://docs.aws.amazon.com/next-generation-sagemaker/latest/userguide/what-is-sagemaker.html
• EventBridge：https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html
• SQS：https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html
• Spark：https://spark.apache.org/

在实践层面，这一案例给 机器学习 平台团队提供了一个更务实的对照：与其追求“全统一平台”，不如围绕组织成本与控制边界做拆分——把最耗运维的部分交给托管，把最需要定制化与性价比的部分留在自建体系中。