OmniForce: On Human-Centered, Large Model Empowered and Cloud-Edge Collaborative AutoML System

autoML旨在用最少的人力投入构建机器学习框架. 先前的工作很少关注在开放世界的良好工作, 一个解决方案是人机交互, 具有机器学习版本管理, 基于流水线的开发与部署, 灵活的搜索策略框架, 广泛提供并众包的应用算法(包括大模型)以及几分钟内提供远程服务这些特点, MaaS(Model as a Service)

介绍

机器学习在多领域取得成功, 催生产业应用. autoML: "设计定制超参数并在无需人工干预的情况下全自动地识别用于训练的神经网络".(好像是无监督学习)

讲了autoML在算法层面(遗传算法, 随机搜索等)和系统层面([开源]:Optuna, Ray-Tuna等, [闭源]:Google Cloud AutoML等)的进展.

分析系统没有得到广泛应用的原因: 1) 只关注闭环问题; 2) 忽略了推理和部署阶段; 3) 只有预定义或内置的应用算法, 而在实践中存在大量的各种AI应用.

为了解决这个问题, autoML坚持这些主张: 1) 用户可以通过与OmniForce交互处理业务逻辑和数据收集; 2) 云边协同实践, 将AI的开发(云)与实际运行(边)看作一个有机的整体, 确保搜索出来的AI应用在云端准确落地, 在资源受限的边缘端稳定落地; 3) 众包应用算法, 属于生态建设.

这里介绍了一个HAML的流程, 原文很清楚详细但是不好理解, 下面是我结合一个具体例子工厂质检的解释, 1) Data collection, 用户收集数据, 隐私啥的就不说了; 2) Feature, 借助ML提取特征, 还有一些人类可以干预的交互; 3) Application Algorithm & Search Space, 查找合适的算法(或用户选择), 超参数自动给一个大致的范围, 人类可以调节; 4) Searching, Training, Deploying. 框定超参数大致范围后云端找出评分最高的用于云端训练, 然后边缘端部署; 5) Visualization, 专家或人类反馈意见, 下一步的数据收集.

Omniforce-intro

系统结构

Omniforce-overview

组件

Job Estimator. (Search Space和Searching)假设你同时开启了 10 个测试任务, 传统做法(全同步)必须等这 10 个任务全部跑完, 才能总结经验开始下一轮; Job Estimator(半同步)设置了一个"最大等待时间", 会果断放弃超时的任务, 直接利用已有的结果去生成下一批更好的测试方案.
Worker. (Searching)核心职责是评估候选任务, 从任务队列里领走一个"算法+参数"的组合, 在实际的数据集上运行这个模型, 计算出这个组合的准确率, 耗时, 功耗等指标, 并将结果反馈回去.
TTE (Training Task Entity). (Training)真正执行"训练"代码的实体, 支持云原生环境, 弹性分布式训练.
DTE (Deployment Task Entity). (Deploying & Evaluation)用于"评估部署性能"的实体, TTE 练好模型后, DTE 会接手, 确保云端练出来的模型在边缘设备上也能跑得通.
Task Sidecar. (贯穿整个执行全流程)连接 Worker, TTE 和 DTE, 处理那些琐碎的通信逻辑(报告进度, 传输模型文件等), 保证信息传递不掉线.
Manager. 负责创建, 调度和回收所有的云端资源, 把复杂的机器学习操作(如启动 Pytorch 训练任务,部署推理服务)封装成一个统一的 Kubeflow Pipeline.
Advisor. 连接"AI 自动化"和"人类决策"的桥梁, 拥有大数据分析能力的"专家助手"

System Workflow

展示了各组件间的相互交互, 其实把上面组件的功能想明白了, 不需要看原文中每个序号的含义.

这套流程用刀现代人与人间合作还挺不错的.

介绍

机器学习在多领域取得成功, 催生产业应用. autoML: "设计定制超参数并在无需人工干预的情况下全自动地识别用于训练的神经网络".(好像是无监督学习)

讲了autoML在算法层面(遗传算法, 随机搜索等)和系统层面([开源]:Optuna, Ray-Tuna等, [闭源]:Google Cloud AutoML等)的进展.

分析系统没有得到广泛应用的原因: 1) 只关注闭环问题; 2) 忽略了推理和部署阶段; 3) 只有预定义或内置的应用算法, 而在实践中存在大量的各种AI应用.

组件

Job Estimator. (Search Space和Searching)假设你同时开启了 10 个测试任务, 传统做法(全同步)必须等这 10 个任务全部跑完, 才能总结经验开始下一轮; Job Estimator(半同步)设置了一个"最大等待时间", 会果断放弃超时的任务, 直接利用已有的结果去生成下一批更好的测试方案.

Worker. (Searching)核心职责是评估候选任务, 从任务队列里领走一个"算法+参数"的组合, 在实际的数据集上运行这个模型, 计算出这个组合的准确率, 耗时, 功耗等指标, 并将结果反馈回去.

TTE (Training Task Entity). (Training)真正执行"训练"代码的实体, 支持云原生环境, 弹性分布式训练.

DTE (Deployment Task Entity). (Deploying & Evaluation)用于"评估部署性能"的实体, TTE 练好模型后, DTE 会接手, 确保云端练出来的模型在边缘设备上也能跑得通.

Task Sidecar. (贯穿整个执行全流程)连接 Worker, TTE 和 DTE, 处理那些琐碎的通信逻辑(报告进度, 传输模型文件等), 保证信息传递不掉线.

Manager. 负责创建, 调度和回收所有的云端资源, 把复杂的机器学习操作(如启动 Pytorch 训练任务,部署推理服务)封装成一个统一的 Kubeflow Pipeline.

Advisor. 连接"AI 自动化"和"人类决策"的桥梁, 拥有大数据分析能力的"专家助手"

OmniForce: On Human-Centered, Large Model Empowered and Cloud-Edge Collaborative AutoML System

On this page