OPPO端云协同机器学习平台StarFire技术实践
作为一家全球领先的智能终端科技企业,OPPO 一直致力于为终端用户提供最佳的使用体验。为实现这一目标,我们不断探索能够更好地利用最新技术(包括云与人工智能)的方法。其中一个典型的例子是 OPPO 提出的安第斯智能云(AndesBrain)战略,致力于让终端设备变得更加智能。
人工智能有助于释放移动设备的潜力。一方面,在终端设备上运行 AI 模型可以将用户数据保留在移动硬件上,而不是将它们发送到云端,这样可以更好地保护用户隐私。另一方面,移动芯片的计算能力正在快速提升,能够支持更加复杂的人工智能模型。通过将云平台与移动芯片结合进行 AI 模型训练,我们可以利用云计算资源开发出能够适应不同移动硬件的高性能机器学习模型。
2022 年,我们开始通过 StarFire 来落地 AI 工程化战略,StarFire 是我们自研的机器学习平台,该平台把云端服务、算力与终端设备相结合,是安第斯智能云的六大核心能力之一。算法工程师能够利用 StarFire 提供的各种先进云技术来满足端云 AI 模型的开发验证需求。
端侧 AI 模型的开发是工程链路中必需解决的重要一环,StarFire 端云一体工作台(以下统称为 AI Workbench)是承接 OPPO 算法工程师开发验证端侧模型需求的重要载体。
在端模型的开发过程中,由于端侧场景的特殊性,算法工程师除了需要保证模型效果、关注快稳省指标,还需要解决很多工程链路的问题,尤其需要解决端云的开发协同问题。调研下来,我们发现工程侧的工作需要耗费算法大量的时间,如果没有完整的工具链支持,各个 AI 开发单元需要自研工具、独立部署、抢占资源,也带来大量的人工非标操作,无论从安全性,复用性还是沟通协作上来说,效率都十分低下,给算法开发和测试工作带来极大困扰。总结下来,主要有以下痛点:
-
端模型普遍面临提高运行速度、降低时延功耗的严苛要求,需要丰富的轻量化手段。 -
量化编译过程繁琐,无法通过 USI Search 等方式进行深度调优。 -
推理引擎及芯片平台的模型适配与升级优化,高频重复,人工操作成本高。 -
端模型开发迭代和部署过程中的端云资源利用率不高,限制了模型的迭代和部署效率。
针对上述业务痛点与挑战,我们构建了 StarFire AI Workbench 来承接端侧模型端云协同开发链路,涵盖了端侧模型开发过程中高频使用的模型压缩、转换编译、功耗测试、性能测试、x86云侧仿真等 pipeline 功能。
StarFire AI Workbench 架构图
StarFire 依托于安第斯智能云已经构建出一套相对完整的云上模型开发、部署流水线。针对端侧场景,StarFire AI Workbench 通过打通云侧与真机、功耗机之间的链路,将现有的云上工作流与端侧设备深度整合,可在 Workbench 中一键进行模型量化编译、端侧匹配、模型下发、批量验证和测试,优化后再进入下一次验证。通过 Workbench 可以减少大量重复性操作,并且省去了环境管理、设备管理等繁琐的步骤,同时借助于平台也可以对端侧设备进行有效共享。下面结合上述提到的业务痛点,将对 AI Workbench 中的一些重要特性进行展开介绍。
在端模型的开发过程中,由于端侧设备计算资源面临严格的大小和功率限制,移动端模型必须满足模型尺寸小、计算复杂度低、电池耗电量低、下发更新部署灵活等条件。如何在不显著降低准确性的情况下,实现对原始模型的压缩,一直是学术界和工业界都重点关注的研究领域。
StarFire AI Workbench 通过集成开源和自研的技术,包括常见的模型量化,模型剪枝、模型蒸馏等,可以支持多种主流深度学习框架的模型压缩,并针对硬件做了定制优化,可适应多种业务场景。同时,我们从算法工程师便捷使用的角度出发,构建了自动化压缩流程,在平台上形成了一站式工作流,极大地提升模型压缩工作的效率,并降低端模型部署时延。
StarFire 中的模型压缩技术
经过理想的压缩之后,端模型需要面向高通和 MTK 芯片的目标平台进行量化与编译工作,算法工程师一方面需要同时学习两个平台的量化编译流程,掌握众多的参数与配置文件,另一方面独立的量化编译工具功能有限(如对噪声的优化和高精度保证),最后还需要进行不同平台不同版本的量化编译环境配置,学习和实践成本较高。
StarFire AI Workbench 模型转换功能通过高效合理的服务封装和简单清晰的界面尽可能降低不同平台量化编译工具的使用成本。
-
易用性 :统一了各版本工具的配置环境,算法工程师无需关注 SDK 的版本和环境,只需要进行页面点选配置好参数就可以完成量化-编译的转换操作。 -
全面性 :具有多种模型量化噪声分析和优化功能,提高量化模型的精度。 -
灵活性:可以点选式配置必备参数,也提供可选填的扩展参数。
AI Workbench 功能界面
功耗测试架构图
算法工程师通过 AI Workbench 提交任务;
获取相关推理引擎环境及配置信息;
量化编译任务调度;
模型结果存储至自研存储 CubeFS;
-
获取相关配置信息,根据测试任务的需求及设备情况将任务调度至对应功耗机; -
推送功耗测试所需的配置文件至端侧设备,结果指标回传至对象存储/数据库中。
端模型基于其应用场景,对性能表现有极致的追求。StarFire 平台自主搭建了端云一体的模型开发和测试链路,支持本地真机的快速接入平台,同时平台内置完全解耦的推理引擎库、脚本库、模型库和运行环境镜像,算法工程师可以自定义地选择,实现对模型库/本地存储的模型转换、编译优化、量化、端侧推理时延和内存占用的性能测试、端云性能的对比。
整体性能测试架构如下图所示:
支持工控机/本地真机接入平台,快速构建定制化的端云协同开发和测试链路;
支持多个模型在单个芯片环境+推理引擎下的端云性能测试;
支持模型转换编译、模型端侧推理结果分析、端云性能对比;
维护了 OPPO 端侧模型开发团队常用的模型库和引擎 SDK;
支持注册工控机上连接的高通/MTK 手机芯片类型;
-
多访问方式 :支持 UI 和 API 接口访问,分别面向单仿真任务的可视化快速执行和工具链 pipeline 中的自由调用。 多任务并发能力:充分利用云侧计算集群的高伸缩性和多线程服务能力,支持 API 接口多任务并发能力;对外提供 python sdk,方便 pipeline 集成。
-
Workbench 将仿真输入信息上传至文件存储; -
基于 OPPO 的虚拟机构建驻守服务,实现与其上运行的 X86 架构成像调试仿真程序交互; -
驻守服务调用 X86 仿真程序进行成像仿真,将结果回传; -
Workbench 将结果下载到挂载的 CubeFS 中; -
仿真记录利用 RDS 存储,记录每次的仿真任务编号及状态,供驻守服务查询和使用。
相对于离线服务器的模式,云化仿真可以充分利用云上可伸缩的海量计算节点,提供更高效的相机调试仿真服务能力:
-
提升仿真效率 :快速通过安第斯智能云调度虚拟机补充仿真算力,提高任务效率; -
降低仿真成本 :任务低峰期释放资源,保留最小资源池,按需使用; -
提供底层运维支撑与技术支持 :节点层面、网络层面、系统层面、应用层面,能够很好支撑仿真任务高效、平稳运行。
StarFire 作为安第斯智能云承接 OPPO AI 工程化战略的重要载体,在 AI 端云协同开发的过程中还会进行更深层次的打磨和建设,包括联邦学习框架、智能端插件、模型管理和监控等。我们也会将更多 StarFire 在 AI 工程化建设中的实践,如算力资源利用率优化、推理功能建设、数据相关建设等,进一步与大家进行交流。
OPPO 安第斯智能云(AndesBrain)是服务个人、家庭与开发者的泛终端智能云,致力于“让终端更智能”。作为 OPPO 三大核心技术之一,安第斯智能云提供端云协同的数据存储与智能计算服务,是万物互融的“数智大脑”。
本文分享自微信公众号 - 安第斯智能云(OPPO_tech)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
研究思考丨关于软件复杂度的困局
作者:王洋(古训) 前言 大型系统的本质问题是复杂性问题。互联网软件,是典型的大型系统,如下图所示,数百个甚至更多的微服务相互调用/依赖,组成一个组件数量大、行为复杂、时刻在变动(发布、配置变更)当中的动态的、复杂的系统。而且,软件工程师们常常自嘲,“when things work, nobody knows why”。 本文将重点围绕软件复杂度进行剖析,希望能够帮助读者对软件复杂度成因和度量方式有所了解,同时,结合自身的实践经验谈谈我们在实际的开发工作中如何尽力避免软件复杂性问题。 导致软件复杂度的原因 导致软件复杂度的原因是多种多样的。 宏观层面讲,软件复杂是伴随着需求的不断迭代日积月累的必然产物,主要原因可能是: 1.对代码腐化的退让与一直退让。 2.缺乏完善的代码质量保障机制。如严格的 CodeReview、功能评审等等。 3.缺乏知识传递的机制。如无有效的设计文档等作为知识传递。 4.需求的复杂性导致系统的复杂度不断叠加。比如:业务要求今天 A 这类用户权益一个图标展示为✳️,过了一段时间,从 A 中切分了一部分客户要展示🌟。 对于前三点我觉得可以通过日常的工程师文化建设...
- 下一篇
从源码角度深入解析Callable接口
摘要:从源码角度深入解析Callable接口,希望大家踏下心来,打开你的IDE,跟着文章看源码,相信你一定收获不小。 本文分享自华为云社区《一个Callable接口能有多少知识点?》,作者: 冰 河。 并发编程一直是程序员们比较头疼的,如何编写正确的并发程序相比其他程序来说,是一件比较困难的事情,并发编程中出现的 Bug 往往也是特别诡异的。 之所以说并发编程出现的 Bug 比较诡异,是因为在并发编程中,很多时候出现的 Bug 不一定能完美的复现出来,也就是说,并发编程的 Bug 是很难重现,很难追踪的。 Callable接口介绍 Callable接口是JDK1.5新增的泛型接口,在JDK1.8中,被声明为函数式接口,如下所示。 @FunctionalInterface public interface Callable<V> { V call() throws Exception; } 在JDK 1.8中只声明有一个方法的接口为函数式接口,函数式接口可以使用@FunctionalInterface注解修饰,也可以不使用@FunctionalInterface注解修饰...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- 设置Eclipse缩进为4个空格,增强代码规范
- CentOS关闭SELinux安全模块
- Hadoop3单机部署,实现最简伪集群
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- CentOS7设置SWAP分区,小内存服务器的救世主
- SpringBoot2全家桶,快速入门学习开发网站教程