Lyft 如何利用机器学习每天做出 1 亿次预测

Posted on 2025-06-11

数据库性能基准测试：虚拟大师班（赞助）

了解如何准确测量数据库性能

免费 2 小时大师课 | 2025 年 6 月 18 日

本大师班将向您展示如何设计和执行能够反映实际工作负载模式的有意义的测试。我们将讨论一些行之有效的策略，帮助您合理调整性能测试基础设施，考虑并发性的影响，识别和缓解协同遗漏，并理解概率分布。我们还将分享在对高性能数据库进行基准测试时避免常见陷阱的方法。

参加完本次免费的 2 小时大师班后，您将了解如何：

  • 根据数据库和工作负载需求调整查询和流量模式

  • 测量预热阶段、限制和内部数据库行为如何影响结果

  • 关联延迟、吞吐量和资源使用情况，以进行可行的性能调整

  • 报告清晰、可重复的基准测试结果

免费注册

免责声明：本文中的详细信息源自 Lyft 工程团队在线分享的文章/视频。所有技术细节的版权均归 Lyft 工程团队所有。原始文章和视频的链接位于文章末尾的参考资料部分。我们已尽力分析这些细节并提供意见。如果您发现任何不准确或遗漏之处，请留言，我们将尽力修正。

每天，数亿次机器学习推理都在为 Lyft 的决策提供支持。这些并非后台的批量作业。而是实时、高风险的预测，影响着体验的方方面面，从定价到标记欺诈行为，从预测预计到达时间到决定哪个司机能获得哪些奖励。

每次推理都面临压力，时间预算只有几毫秒。这意味着每秒要处理数百万个请求。数十个团队，每个团队都有不同的需求和模型，正在按计划推进更新。挑战在于保持灵活性，避免崩溃。

大规模实时机器学习分为两类问题：

  • 数据平面压力：热路径上发生的所有情况。包括 CPU 和内存使用情况、网络瓶颈、推理延迟以及吞吐量上限。

  • 控制平面复杂性：这涉及模型的一切。考虑部署和回滚、版本控制、重新训练、向后兼容、实验、所有权和隔离等方面。

早期，Lyft 依靠共享的单体式服务来为整个公司的机器学习模型提供服务。然而，单体式服务带来的摩擦多于灵活性。团队无法独立升级库。部署冲突频发，所有权模糊。一个模型的微小变化可能会破坏另一个模型，事故调查变成了侦探工作。

需求很明确：构建一个服务平台，让模型部署变得像编写模型一样自然。它必须快速、灵活、团队友好，并且不能掩盖大规模推理的复杂现实。

在本文中，我们将了解 Lyft 如何构建架构来满足这一要求以及他们面临的挑战。

架构和系统组件

LyftLearn Serving 并非另起炉灶。它巧妙地融入了 Lyft 现有微服务基础，而这些基础已经为 Lyft 的其他功能提供了支持。其目标并非从零开始构建定制的机器学习服务引擎，而是在现有成熟的基础架构上进行扩展，使其具备处理实时推理所需的智能，而不会导致系统臃肿或限制团队。

其核心是一个专用的微服务：轻量级、可组合且自包含。每个团队运行其实例，并由 Lyft 的服务网格和容器编排堆栈提供支持。其结果是：快速部署、可预测的行为以及清晰的所有权边界。

我们来分解一下这个架构流程图：

HTTP 服务层

每个对 LyftLearn Serving 服务的请求都会首先到达一个 HTTP 端点。该接口使用 Flask（一个极简的 Python Web 框架）构建。虽然 Flask 本身无法扩展到生产工作负载，但它可以与 Gunicorn（一个专为高并发性而设计的预分叉 WSGI 服务器）搭配使用。

为了使该堆栈达到生产级水平，Lyft 优化了设置，使其与位于所有内部微服务前端的服务网格 Envoy 保持一致。这些优化可确保：

  • 高请求量下的低尾部延迟。

  • 跨 Envoy-Gunicorn 边界的顺畅连接处理。

  • 抵御瞬态网络故障的能力。

该层使 HTTP 接口保持精简和高效，刚好足以路由请求和解析有效负载。

核心服务库

这才是真正的逻辑所在。LyftLearn Serving 库负责处理繁重的工作：

  • 模型加载和卸载：从保存的工件中动态地将模型带入内存

  • 版本控制：清晰地跟踪和管理不同的模型版本

  • 影子：通过对新模型并行运行推理来实现安全测试，而不会影响实时结果

  • 监控和日志记录：为每个推理请求发出结构化日志、指标和跟踪

  • 预测日志：捕获输出以供以后审计、分析或模型调试

此库是所有团队使用的通用运行时。它集中化了“平台契约”，因此各个团队无需重新实现基础功能。同时，它也不限制自定义。

自定义 ML/预测代码

核心库依赖注入了团队拥有的推理逻辑。每个团队提供两个 Python 函数：

 def load(self, file: str) -> Any:    # Custom deserialization logic for the trained model    ... def predict(self, features: Any) -> Any:    # Custom inference logic using the loaded model    ...

来源： Lyft 工程博客

这种设计使平台保持了灵活性。团队可以使用任何模型结构、特征格式或业务逻辑，只要它们遵循基本接口即可。这是因为预测路径与传输层和编排层解耦。

第三方机器学习库支持

LyftLearn Serving 对机器学习框架没有任何预设。无论模型使用的是 TensorFlow、PyTorch、LightGBM、XGBoost 还是自主研发的解决方案，都无关紧要。

只要模型通过 Python 加载和预测，它就兼容。这使得团队可以：

  • 无需协调即可升级到较新的框架版本。

  • 使用小众或实验性的图书馆。

  • 避免供应商锁定或僵化的 SDK。

框架的选择成为建模者的决定，而不是平台的限制。

与 Lyft 基础设施集成

该微服务与 Lyft 现有的生产堆栈深度集成：

  • 指标和跟踪插入公司范围的可观察性管道。

  • 日志和预测事件输入中央分析系统。

  • Kubernetes 负责处理服务编排和自动扩展。

  • Envoy 服务网格提供安全、可发现的网络通信。

这种协调避免了重复劳动。团队可以继承 Lyft 其他基础设施的可靠性、可见性和安全性，而无需自行配置。

隔离和所有权原则

当数十个团队独立部署和运行机器学习模型时，共享的基础设施很快就会变成共同的痛点。一次部署失败就可能阻碍其他五个部署。一次库升级就需要数周的协调，调试也最终演变成互相推卸责任。LyftLearn Serving 的初衷正是避免这种情况。

其设计基础是通过存储库进行硬隔离，这不是一项策略，而是在堆栈的每一层强制执行的技术边界。

一个仓库，一个服务，一个所有者

每个使用 LyftLearn Serving 的团队都有自己的 GitHub 仓库。这个仓库不仅用于存放代码，还定义了整个模型服务生命周期：

  • 服务代码包括自定义 load() 和 predict() 逻辑。

  • 用于部署和编排的配置文件。

  • CI/CD、监控和指标的集成挂钩。

无需管理中央存储库，也无需协调共享运行时。如果团队需要五个模型，他们可以选择将它们托管在一个存储库中，也可以将它们拆分到五个存储库中。

独立部署管道

每个仓库都自带部署管道，与其他仓库完全解耦。其中包括：

  • 暂存和生产环境。

  • 运行模型自检和 linting 的 CI 作业。

  • 版本标记和发布推广。

如果一个团队推送了有问题的代码，不会影响其他团队。如果另一个团队需要修复错误，他们可以立即部署。隔离机制消除了在高风险生产变更期间进行跨团队协调的需要。

通过 Kubernetes 和 Envoy 实现运行时隔离

LyftLearn Serving 在 Lyft 的 Kubernetes 和 Envoy 基础架构上运行。该平台为每个团队分配：

  • Envoy 服务网格中的专用命名空间

  • 隔离的 Kubernetes 资源（Pod、服务、配置图）

  • 可定制的 CPU、内存和副本设置

  • 团队特定的自动缩放和警报配置

这确保了运行时不会出现故障，无论是内存泄漏、CPU 使用率过高还是部署不当。一个团队模型的流量激增不会造成另一个团队的资源匮乏。一个容器的崩溃不会导致服务基础设施瘫痪。

工具：配置生成器

将模型投入生产并不意味着学习多种配置格式、连接运行时机密或调试因缺少数据库条目而导致的部署中断。

为了简化这一流程，LyftLearn Serving 包含一个配置生成器：这是一个引导工具，它将从零开始构建一个可用的机器学习服务微服务所需的一切连接起来。启动一个新的 LyftLearn Serving 实例需要将基础设施堆栈中的各个部分拼接在一起：

  • Terraform 用于配置云基础设施。

  • 用于 Kubernetes 和服务网格配置的 YAML 和 Salt。

  • Python用于定义服务接口。

  • 用于安全凭证访问的运行时秘密。

  • 用于模型版本控制或功能查找的数据库条目。

  • Envoy 网格注册用于服务发现。

期望每个机器学习团队都手动完成此设置，会导致偏差、重复和用户引导延迟。配置生成器将这种复杂性简化为几个引导式输入。

该生成器在 Yeoman 上运行，Yeoman 是一个常用于引导 Web 项目的脚手架框架，但在此针对 Lyft 的内部系统进行了定制。

运行生成器的新团队进行了一次简短的互动会议：

  • 定义团队名称。

  • 指定服务命名空间。

  • 选择可选的集成（例如，日志管道和模型阴影）。

然后，该工具会发出一个完整的 GitHub 仓库，其中包含：

  • load() 和 predict() 函数的工作示例代码。

  • 预先连接的部署脚本和基础设施配置。

  • 内置测试数据支架和 CI 设置。

  • 挂钩监控和可观察性。

一旦生成 repo 并提交代码，团队就获得了一个可正常运行的微服务，可以接收模型、运行推理，并在 Lyft 网格内服务于真实流量。团队可以立即迭代模型逻辑，而无需先理清基础设施。

模型自测试系统

当新的依赖项悄悄出现时，模型服务经常会发生漂移，从而略微改变输出行为。例如，训练脚本更新后，没有人注意到预测的变化。或者，容器升级悄无声息地破坏了反序列化。等到有人发现性能下降时，数百万个糟糕的推理已经交付了。

为了解决这个问题，LyftLearn Serving 引入了内置的模型自测试系统。它是一个嵌入在模型内部的合约，旨在验证两个最重要的时间点的行为：合并前和部署后。

每个模型类都定义一个 test_data 属性：具有预期输出的结构化样本输入：

 class SampleModel(TrainableModel):    @property    def test_data(self) -> pd.DataFrame:        return pd.DataFrame([            [[1, 0, 0], 1], # Input should predict close to 1            [[1, 1, 0], 1]        ], columns=["input", "score"])

来源： Lyft 工程博客

这不是完整的数据集。它只是一组精挑细选的样本，充当金丝雀预警。如果某个更改破坏了这些输入的预期行为，则可能存在更深层次的问题。测试数据会随模型二进制文件一起传输，并成为服务生命周期的一部分。

两个重要的检查点如下：

部署运行时期间

模型加载到 LyftLearn Serving 实例后，会立即对其 test_data 进行预测。结果如下：

  • 在指标仪表板中记录并显示。

  • 如果预测与预期相差太远，则会触发警报。

  • 提供运行时完整性的即时信号。

这会捕获由环境不匹配导致的细微故障。例如，一个在 Python 3.8 中训练的模型，却部署到依赖项不兼容的 Python 3.10 容器中。

在拉取请求期间

当开发人员在模型仓库中打开 PR 时，CI 就会启动。它执行以下活动：

  • 加载新的模型工件。

  • 对存储的测试数据运行预测。

  • 将输出与先前已知的良好结果进行比较。

如果输出结果超出可接受的增量范围，即使代码编译通过、服务构建顺利，PR 也会失败。下图展示了一个典型的开发流程：

推理请求生命周期

实时推理系统存在于 HTTP 请求和 JSON 响应之间的几毫秒内。这短短的几毫秒内，承载的远不止模型数学运算。路由、验证、预测、日志记录和监控都汇聚于此。

LyftLearn Serving 保持推理路径精简但结构化。每个请求都遵循可预测且强化的生命周期，在不牺牲控制力的情况下实现灵活性。

以下是处理请求的具体步骤：

  • 请求到达 Flask 端点：服务通过 Flask 暴露一个 /infer 路由，并由 Gunicorn workers 支持。Envoy 负责处理上游路由。传入的有效负载被解析并传递给核心服务库。

  • 核心库检索模型：运行时使用 model_id 查找相应的模型。如果模型尚未加载到内存中，系统将调用团队提供的 load() 函数并按需加载。这时，版本控制逻辑、缓存和模型生命周期控制就会发挥作用。没有全局注册表，也没有共享内存。每个服务都拥有并管理其模型。

  • 输入验证和预处理：在运行推理之前，平台会对特征对象执行健全性检查，例如类型或形状验证、必填字段是否存在以及可选的模型特定钩子。此步骤可防止格式错误的输入，并防止下游逻辑中出现未定义的行为。

  • 用户定义的 predict() 函数负责执行推理：一旦输入被视为有效，系统就会将控制权移交给建模者编写的自定义 predict() 函数。该函数将输入转换为预期格式，并调用底层机器学习框架（例如 LightGBM、TensorFlow）返回预测输出。predict() 函数是热路径代码，每天运行数百万次。其性能和正确性直接影响延迟和下游决策。

  • 日志、指标和分析：生成输出后，平台会自动记录请求和响应，以便进行调试和审计跟踪。它还会发出延迟、吞吐量和错误率指标，并触发流入仪表板或实时监控的分析事件。此可观察性层确保每个推理都可追踪，每个服务行为都可衡量。

  • 返回给调用者的响应：最终将结果打包成 JSON 响应，并通过 Flask 返回。从请求到响应，整个路径都针对速度、可追溯性和安全性进行了优化。

结论

实时服务机器学习模型不仅仅关乎吞吐量或延迟，还关乎创建团队可以信赖、可顺利演进和调试的系统。

LyftLearn Serving 并非从零开始或全新设计。它是在规模化、隔离以及保持数十个团队快速运转且不互相干扰的压力下构建的。

在此过程中，我们得到了一些教训，值得我们去理解：

  • “模型”对不同的人来说有不同的含义。序列化对象、训练脚本和预测端点都属于同一标签。如果工具和团队之间没有明确的定义，混乱很快就会蔓延。

  • 文档是产品的一部分。如果团队无法在未征求平台团队同意的情况下进行上线、调试或扩展，系统就无法扩展。LyftLearn Serving 将文档视为“一等公民”。

  • 一旦模型部署到 API 后面，就会有人在某个地方持续调用它。因此，对于任何期望投入生产的服务系统来说，稳定性都是必需的。

  • 权衡取舍并非可有可无。无缝用户体验与灵活的可组合性相冲突。结构化流程与自定义工作流相冲突。每个决策都会使某件事变得更容易，也可能使另一件事变得更难。关键在于了解系统真正面向的对象，并诚实地对待需要优化的内容。

  • 平台由高级用户塑造。优先为最先进、要求最高的团队构建。如果平台满足了他们的需求，那么它很可能也能满足其他所有人的需求。如果不能，它就无法超越最初的几个采用者。

  • 宁可尝试那些枯燥的技术，只要它能用就行。稳定性、可调试性和操作成熟度是需要考虑的关键因素。

LyftLearn Serving 仍在不断发展，但其基础依然牢固。它不会试图隐藏复杂性，而是将其隔离开来。此外，它还强制执行关于模型在生产环境中如何表现的契约。

参考：

赞助我们

将您的产品展示给超过 1,000,000 名技术专业人士。

我们的时事通讯将您的产品和服务直接呈现给重要的受众——数十万工程领导和高级工程师——他们对重大技术决策和大宗采购有影响力。

房间很快订满 – 立即预订

广告位通常提前4周左右售罄。为了确保您的广告能够触达这些极具影响力的受众，请立即发送电子邮件至[email protected]预订您的广告位。

原文： https://blog.bytebytego.com/p/how-lyft-uses-ml-to-make-100-million