(I)负载均衡器:为每个模型推理在线服务提供自动负载均衡能力 , 即将(H)压力测试/在线服务中产生大规模请求流量通过负载均衡算法将请求分配到各个计算节点的容器实例中 。负载均衡算法采用随机法、轮询法、原地址哈希法、加权轮询法、最小连接数法等 。
(J)系统/服务状态监控模块:对每个模型服务推理的准确性指标(如面向分类模型的精确率、召回率、F1值、AUC等和面向回归模型的MSE、RMSE、MAE等)、模型推理服务的使用情况以及资源的使用状态进行全方位的采集、存储 , 并进行不同时间粒度的汇总计算 , 主要的监控指标包括CPU使用率、GPU使用率、内存使用率、占用存储空间、上下行流量、服务请求数量、服务调用失败/成功数量、服务响应时延等 , 并计算反应模型服务性能稳定性和可靠性的衍生指标 , 如TP99、TP9999等 。该部分信息一方面是(K)监控面板上进行可视化的基础 , 另一方面也会反馈给(E)Kubernetes集群 , 用于指导资源的分配调度和服务的编排 。
(K)监控面板:将(J)系统/服务状态监控模块中采集、计算的指标进行可视化 , 方便用户了解模型在线推理服务的状态 。
3. 模型自动筛选与更新流程
机器学习模型往往会随着时间的推移进行迭代更新 , 为保障模型在线推理服务的准确性 , 需对其进行即时的升级 。本文提出一种模型自动化的模型筛选方法和策略 , 以减少人工操作 。具体流程如图2所示 。

文章插图
图2 模型自动筛选、更新流程示意图
用户根据系统提供的多种筛选策略模板 , 进行策略配置以初始化模型筛选器 , 模型筛选器对(B)模型仓库中的每个模型及其不同版本的元信息进行检测 , 筛选出符合策略所定义要求的模型文件 , 然后由(D)模型微服务引擎对模型在线推理服务在合适的时段(如(J)系统/服务状态监控模块监测到的服务调用量较低的时段或用户自定义的时段)进行更新 。
具体地 , 本文提出以下5种模型筛选策略模板:
① 由上游数据驱动的模型更新 , 即筛选出该驱动事件对应的模型;
② 模型推理准确性指标下降或低于一定阈值事件驱动的模型更新 , 即筛选出该驱动事件对应的模型 , 模型推理准确性指标由(J)系统/服务状态监控模块监测模块反馈 , 见图1;
③ 定期从当前众多版本中筛选出模型性能评估指标(可以是用户定义的加权指标 , 下同)最优的一个模型;
④ 定期从当前众多版本中筛选出模型性能评估指标在一定阈值之上的最新迭代的一个模型;
⑤ 人工手动指定的模型版本 。
4. 资源弹性扩缩容方法
大多数模型在线推理服务的调用量往往会随着业务的涨落而涨落 , 经常出现类似白天高、夜间低的服务请求量波动现象 , 一方面导致硬件资源在调用量较低期间使用率低 , 造成资源浪费 , 另一方面当用量过大时可能影响服务的稳定性和可用性 。本文提出一种模型服务资源的弹性扩缩容方法 , 既保证模型推理服务的资源需求 , 又减少资源的闲置浪费 。具体流程如图3所示 。

文章插图
图3 模型服务资源弹性扩缩容流程示意图
当模型在线推理服务成功部署上线后 , (J)系统/服务状态监控模块实时监测、计算该服务各容器实例的资源使用率等指标 , 如CPU使用率、GPU使用率、内存使用率、响应时延等 , 并进行不同时间粒度的汇总计算 。
对上一个时间窗口内资源使用率指标 , 采用本文提出的容器实例数量计算公式或用户定义自定义的公式进行计算 , 得到下一个时间窗口内期望的容器实例数量 , 然后借助Kubernetes中的横向自动扩缩容的功能(HorizontalPod Autoscaling , 简称 HPA) , 自动化地调整容器实例数量 , 然后(J)系统/服务状态监控模块继续实时监控更新后各容器实例的资源使用率等指标 , 以此循环 , 实现模型在线推理服务资源的动态调整 。
期望的容器实例数量计算公式如下所示:
推荐阅读
- 一篇短文介绍 Defer 是如何工作的
- python 如何使用HttpRunner做接口自动化测试
- 无服务器技术如何实现最佳的DevOps实践
- 如何用DL4J构建起一个人脸识别系统
- 如何看客厅风水是藏风纳气还是一泻千里?
- 客厅风水:客厅地板如何装饰?
- 如何让客厅风水带动家居运气
- 客厅的沙发应当如何摆放?
- 客厅风水:如何布置客厅的财位?
- 黄山毛峰茶的冲泡方法,黄山毛峰如何冲泡
