关于机器学习:一文详解AI模型部署策略

36次阅读

共计 3807 个字符,预计需要花费 10 分钟才能阅读完成。

编者按:模型部署是 AI 开发生产流程中的重要步骤。对于许多组织而言,抉择最佳的模型部署策略以扩大到生产级零碎,都是一项简单且具备挑战的工作。
明天 IDP 将和大家一起,追随 Yashawi Nayak,全面理解模型部署策略。
“这篇文章是为那些想理解 ML 模型如何在生产中部署以及在部署这些模型时能够应用什么策略的人筹备的。本文将阐明部署 ML 模型的根本办法,能够采取的不同部署策略,以及这些策略个别在哪里施行。每个数据迷信团队都会有一套不同的要求,所以要慎重考虑。”
以下是译文,Enjoy!

作者 | Yashawi Nayak
编译 | 岳扬

一、理解机器学习模型的部署

与部署软件或应用程序相比,模型部署是不一样的。一个简略的 ML 模型生命周期会有如下这些阶段,如范畴界定、数据收集、数据工程、模型训练、模型验证、部署和监控。

ML 生命周期(图片由本文作者提供)

当咱们在部署 ML 模型时,须要思考一些因素,比方:

  1. 模型的大小和打包——模型的大小对咱们如何打包有微小的影响。较小的模型通常能够被搁置在 FastAPI 服务器中,并在 Docker 容器中进行封装。然而,较大的模型可能须要在部署期间加载——从近程存储中拉取,并通过模型服务器(如 TFServing 或 TorchServer)运行。
  2. 模型的再训练和版本保护——对模型的再训练频率影响着部署策略。你是否常常须要比拟你的模型性能?你在生产环境中须要多长时间能力更新你的模型?你会在生产环境中保护你的模型的不同版本吗?
  3. 流量和申请路由——依据流量和模型的类型决定实时推理或批量模型部署。你想将多少流量分流到每个版本的模型?有多少用户会有机会拜访某一个模型版本?
  4. 数据和概念漂移——随着工夫的推移,事实世界的数据在一直变动,这可能不会被反映在模型中。比如说,购买力与工资的关系如何,可能每年或每月都在变动。或者在新冠疫情期间,消费者的购买模式如何变动。但模型大多依赖于历史数据,这影响到咱们的部署架构设计:咱们应该从新训练和重新部署吗?咱们是否应该临时只对模型进行从新训练和阶段性的调整?这个因素在数据迷信团队的长期部署策略中施展较大的作用。

对于这些因素,咱们有模型部署的六个常见策略。这些策略次要是从 DevOps 和 UX 方法论中借用的,在 ML 场景中也同样实用。

通常,在技术层面上,生产环境中的模型部署波及到 API 端点网关、负载平衡器、虚拟机集群、服务层、某种模式的持久性数据存储和模型自身。
       

通用模型的部署(图片由本文作者提供)

部署策略通常在负载均衡器和服务层面进行配置,次要是配置路由和入口规定。

以一个动物辨认和分类零碎为例。从一个简略的猫狗分类器开始,这将是模型的首个版本。假如咱们曾经训练了一个模型的副原本辨认考拉,所以第二个版本是一个猫狗考拉分类器。咱们将如何部署模型的最新版本?

模型版本 (图片由本文作者提供)

二、模型部署策略

2.1 Big Bang:重新部署

WHAT:这种模式的部署是一种“从头开始”的部署形式。你必须移除现有的部署,能力部署新的。

WHERE:在开发环境中个别是能够承受的。能够用不同的配置从新创立部署,次数不限。通常状况
下,部署管道会移除现有的资源,并在其地位上创立新的版本。

重新部署 (图片由本文作者提供)

这种部署形式会造成到肯定工夫的中断。当初这样的机器学习开发的速度是不可承受的。在咱们的例子中,咱们用版本 2 替换版本 1,这过程中就会替换掉所有相干的基础设施和库配置。

2.2 滚动更新策略

WHAT:滚动更新策略是逐个更新模型 / 应用程序的所有实例。假如你目前有 4 个正在运行应用程序的 pod,而后应用滚动更新策略部署新版本的模型,这样一个接一个的 pod 会被替换成新的。这种办法造成服务中断的工夫为零。

WHERE:当你想用一个新的版本疾速更新你的整个模型集时会很有用。应用这种策略也容许你在须要时回滚到旧版本。该策略次要用于测试环境,当团队须要测试新版本的模型时。

滚动更新策略 (图片由本文作者提供)

一般来说,这不会是生产零碎中的惟一实现办法,除非你仅在整个零碎中部署一个特定版本的模型。在上述例子中,咱们只替换了模型利用 pod,放弃其余基础设施原样不动。

2.3 🔵Blue/Green🟢部署

WHAT:这种部署模式实质上是一种服务器替换的部署模式。在这种部署模式中,有两个雷同的零碎可用,用户的申请被转到其中一个零碎,而更新则在另一个零碎上实现。一旦更新通过测试和验证,用户的申请就会被路由到较新的零碎,其实实质上是把旧的模型换成新的。

WHERE:次要是在一般应用程序或网络应用场景中应用该种部署形式,也能够用于模型部署,在批处理和实时推理部署中都能够应用。因为该模式是将负载平衡指向一组不同的机器,因而造成服务中断的工夫基本上为零。

蓝绿部署(图片由本文作者提供)

如你所见,咱们用新的模型版本创立一个新的雷同零碎,而后只需将流量切换到新的零碎。然而,咱们须要把保护两个雷同的基础设施零碎的老本思考进去。是否抉择这种办法取决于基础设施的规模和承受能力。

2.4 🐦金丝雀(Canary)部署

WHAT:在 Canary 部署中,咱们将更新后的模型部署到咱们现有的零碎中,并给局部用户推送新版本模型。这意味着咱们的一小部分用户将可能拜访最新的模型,其余的用户仍将应用旧的版本。这种部署形式次要是用来测试新版本的运行状况。通常,一小部分用户(大概 5%-30%)会接触到最新版本,因为这有助于 ML 工程师和开发人员理解哪些性能可能须要推出,哪些须要重构。

WHERE:当团队须要理解新模型的性能时,通常会在模仿环境(staging)和生产环境(production)中进行 Canary 部署。这能够通过两种形式进行:金丝雀滚动部署金丝雀并行部署       

金丝雀部署(左侧为滚动部署,右侧为并行部署)

滚动部署(Rolling Deployment)将最新模型放到同一集群内的大量实例上,并将一组用户申请发送到这些 pod。

并行部署(Parallel Deployment)在现有实例旁边创立了一组较小的新实例,并将肯定比例的用户申请发送到这些 pod 上。

用户的申请通常通过头信息进行标记,而后通过负载均衡器的配置,将其发送到相应的目的地。这意味着有一组用户被抉择来查看最新的模型,而且同一组用户每次都会看到最新模型。用户申请不会被随机地发送到新的 pod。这阐明 Canary 部署具备会话亲和性。

在上文的猫狗考拉分类器例子中,假如选定 10% 的用户能够向模型提交图像,这 10% 的用户提交的图像将用考拉选项进行分类,其余用户只能应用猫狗分类器。

2.5 A/ B 测试

WHAT:这种办法在用户体验钻研中应用最多,能够用来评估用户喜爱什么。在机器学习场景中,咱们能够应用这种部署形式来理解用户喜爱什么,哪种模式可能对他们更无效。

WHERE:寰球范畴内的举荐零碎部署中大多采纳此种部署模式。依据人口统计学,例如一个在线购物网站采纳了两种不同类型的举荐引擎,一个服务于个别的用户,一个服务于特定的天文区域——有更多的母语反对。工程师们能够在一段时间后确定哪种引擎能给用户带来更顺畅的体验。

为什么咱们须要 A / B 测试 (图片来自本文作者)

回到咱们举的那个例子中,假如咱们在寰球范畴内部署了猫狗分类器,但咱们在澳大利亚 - 太平洋岛屿地区部署了版本 1 和版本 2,用户申请有可能被随机发送到版本 2。而后从新训练版本 2 以辨认更多的当地动物种类并部署它,你认为澳大利亚的人们会喜爱哪个版本?

Note:那么 Canary 和 A / B 测试之间有什么区别?
次要的区别是:

  • Canary 是基于会话亲和性(来自客户端的申请总是路由到同一个服务器进行解决)的,大多数状况下,同一组用户将看到最新的模型,而在 A / B 测试中,用户被随机发送到不同的版本。
  • Canary 是专门用来测试应用程序或模型是否按预期工作的,而 A / B 更多的是为了理解用户体验。
  • Canary 的用户比例从未超过 50%,很小比例的用户申请(现实状况下低于 35%)被发送到较新的测试版本。

2.6 影子部署(Shadow)👻

WHAT:影子部署用于生产环境中,用生产数据测试最新版本的模型。生成用户申请的正本并发送给新模型,但现有的零碎也会同时给出响应。

WHERE:如果有一个高流量的生产零碎,为了验证新模型如何解决生产数据和流量负载,能够用影子模式部署新模型。每次向模型发送申请时,都会向更新的版本发送一个申请正本。只由现有的模型发送响应,而新模型不发送响应。

影子部署 (图片来自本文作者)

影子部署次要是用来理解生产负荷、流量和模型性能,其次要用于高容量预测服务。零碎架构和设计的复杂性随着应用这种部署形式而减少。咱们必须有包含服务网格、申请路由和基于用例的简单数据库设计。

在本文举的例子中,咱们可能会将版本 2 应用影子部署,以理解版本 2 如何解决生产负载,也理解从哪里失去更多的考拉分类申请😉或任何特定类型的模型申请模式。

当初咱们对如何在各种状况下部署模型有了根本理解。依据不同的要求,数据迷信团队可能须要应用这些办法的组合,这须要依据具体的业务场景来决定。

END

IDP-Inspiration 是 IDP 常设专栏。在这里,咱们会分享国内外数据科学家和算法工程师在实战中总结的贵重教训,为想要从事数据迷信和 AI 开发生产相干工作的小伙伴提供借鉴!

AI 相干技术投稿,请分割 Alex@baihai.ai

正文完
 0