近年来随着大数据时代的到来和计算能力的晋升，人工智能在各个领域都获得了显著的停顿。原先在云端进行特色的存储与解决、模型的训练、在线推理，在客户端进行数据的展现的架构展现出越来越多的毛病和局限性。本文将联合端智能的劣势，联合哈啰一站式 AI 平台的现状，讲述一站式 AI 平台如何反对多端智能（服务端、flink 端、挪动端）。
云端推理模式
具体流程
图 1 -1 云端推理模式流程图
- 首先云端会将客户端上报的的离线特色和在线特色数据进行存储
- 云端将离线特色数据喂给模型进行模型训练
- 模型在云端训练结束后进行模型上线或者模型更新
- 客户端触发在线推理申请调用云端进行在线预测
- 云端在线推理联合特色数据和模型文件进行预测
- 云端返回排序后果和数据在客户端展现
问题
- 带宽和提早问题：所有客户端用户的申请都要先到云端进行推理后，能力在客户端进行展现，网络传输存在肯定耗时；若推理所需特色较大（如图片，视频等），会导致提早很高，以及网络带宽压力十分大
- 数据安全：用户的数据都须要通过网络传输上传到云端，存在透露危险
- 数据隐衷：局部数据为用户隐衷数据，无奈存储在云端
- 老本问题：所有的在线推理都在云端，则云端须要部署大量服务器提供在线推理能力，老本微小
- 中心化问题：所有的在线推理都须要走云端接口，若网络异样或者云端服务异样，则会导致推理能力生效
端智能模式
端智能技术是指将计算、存储和推理从中心化的云端转移到网络边缘设施（如智能手机、物联网设施等）的技术。
具体流程
图 1 -2 端智能推理模式流程图
- 首先云端会将客户端上报的的离线特色和在线特色数据进行存储
- 云端将原有的离线特色数据和新上报的离线特色数据喂给模型进行模型训练
- 模型在云端训练结束后的模型进行模型上线或者模型更新
- 客户端定时触发模型版本更新，云端辨认到客户端模板版本过旧会通知客户端须要更新模型
- 客户端定时触发云端特色查问，会将云端查问的数据和历史数据存储起来
- 客户端联合特色数据和模型文件进行在线推理
- 客户端进行排序和后果展现
端智能劣势
- 客户端的在线推理依赖的特色和模型都在本地运行，无网络带宽和提早问题
- 数据本地化存储，无数据安全和隐衷问题
- 在线推理本地化，云端故障或者网络故障不会导致无奈在线推理
- 在线推理本地化，云端无需提供服务，可降低成本
哈啰一站式 AI 平台以后现状
整体架构
图 2 -1 一站式 AI 平台架构图
- 一站式 AI 平台从划分来说划分为训练平台、模型平台、特色平台、决策平台
- 训练平台
提供离在线模型的训练、模型开发环境资源管控、模型训练资源管控、离线模型推理、离线模型治理、分布式训练、分布式预测 - 模型平台
提供 tf1/tf2、pmml、python、python-gpu 四类在线模型的模型治理、模型资源管控、在线推理能力 - 特色平台
提供离在线特色存储、实时特色计算、特色关联、特色加工、特征选择、特色荡涤、特色查问等能力 - 决策平台
基于 DAG 流程编排能力，提供了串联 groovy 脚本、多模型，多特色的流程编排，对立对外提供在线推理能力
整体流程
图 2 -2 AI 平台繁难流程图
如图 2 - 2 所示，示意了繁难的一站式 AI 平台的流程图。
1. 特色创立和变更
- 在线特色存储：用户在 AI 平台先创立特色，将离线特色转为在线特色存储起来
- 在线特色新增和变更：特色和特色存储的关系会通过 AI 平台的配置变更，同步给在线特色服务 FeatureService
2. 模型训练和创立，以及模型版本治理
- 模型训练：用户在 AI 平台通过远端工作触发模型的训练，训练实现后产生模型文件，生成本地文件或者上传到 oss
- 新增模型：用户在 AI 平台通过新增模型模块将本地模型文件或者 oss 模型文件和模型绑定
- 模型变更：用户可通过离线训练形式手动在 AI 平台更新模型，也能够通过定时工作训练模型后触发主动模型更新
3. 在线推理
- 用户在决策平台先绑定模型和特色的关系以及 groovy 规定的关系，生成决策
- 业务服务调用决策服务，通过 groovy 规定、灰度、特色查问、特色预处理后传给模型进行在线推理
- 决策服务将推理后果返回给业务零碎
挪动端智能
整体流程
图 3 -1 AI 平台挪动端智能计划繁难流程图
如图 3 - 1 所示，示意了挪动端智能计划繁难流程图，和 2 - 1 比照差别点如下。
1. 模型模块
- 模型版本治理：原先模型版本治理是在一站式 AI 平台实现，业务调用方只须要给出决策 id 就能晓得可运行的模型，而端智能后，前端须要配合进行模型治理
- 模型文件散发：原先模型文件产生后，会将模型文件散发到云端的模型服务 ModelService，端智能后须要将模型文件散发到每个用户的挪动端
- 模型运行环境：原先模型的运行环境是在 ModelService 集成的，当初模型在线推理在挪动端，须要在挪动端反对模型的运行环境
2. 特色模块
- 特色的存储原先只在云端，端智能后端上会存储数据
- 在线推理不再依赖云端数据，而是依赖本地特色数据（端智能后挪动端会定时拉取云端特色到本地）
3. 决策模块
- 原先决策是作为服务给业务方调用，端智能后须要打成 sdk 包给挪动端调用
- 决策服务原先只给后端服务调用，端智能后须要反对挪动端申请拜访
挑战和计划
- 端上版本更新挑战
在端上运行模型会依赖特色数据、特色预处理逻辑、模型文件、groovy 规定，依赖库会有依赖关系，如果局部是实时散发更新，局部是依赖挪动端发版，则可能会导致不统一，且依赖挪动版发版工夫。
- 计划
将能够动静公布的模型文件、特色预处理文件，groovy 规定，依赖库打包成一个算法包，反对动静更新和对立版本治理
- 模型文件散发挑战
从 ModelService 转为挪动端，数量大大增加。ModelService 为云端零碎 pod 数，根本是几百，挪动端是用户收集 app，则会在千万级别。
- 计划
云端通过用户手动或者主动训练完模型后更新的 oss，用户关上 App 后定时 check 算法包是否存在更新，若存在更新，则从用户最近的 CDN 节点拉取算法包到 app
- 包大小挑战
因为端上资源无限，因而对新增的决策 sdk 包和模型文件大小以及计算资源会有肯定限度。
- 计划
决策：对决策做最大化的瘦身，只保留一站式决策可运行的最小版本能力（如：groovy 规定、特色预处理）
模型：管制模型的参数量级、拆分部署；基于 MNN 框架对模型进行压缩
- 适配挑战
挪动端因为每个用户的设施都不一样，会有不同的适配老本。计划目前一期仅反对在基于 MNN 在安卓设施进行，IOS 兼容计划仍在摸索中 - 模型运行挑战
模型文件须要在端上运行，端侧得反对可运行模型文件的环境。
- 计划
图 3 -4 基于 MNN 的运行结构图
基于淘宝 MNN 开源引擎，在端侧适配模型可运行的环境
flink 端智能
整体流程
图 4 -1 AI 平台 flink 端智能计划繁难流程图
如图 4 - 1 所示，示意了 flink 端智能计划繁难流程图，和 2 - 1 比照差别点如下。
1. 触发逻辑
- 原先云端的模型触发都是基于 soa 接口方式触发，改为 flink 端后，在线推理都是基于音讯触发
2. 模型模块
- 模型运行环境：原先模型的运行环境是在 ModelService 集成的，当初模型在线推理在 flink，须要在 flink 端反对模型的运行
- 模型更新交互变动：原先模型的加载都是 ModelService 中监听模型新增或者批改，当初模型的新增和更新须要在 flink 端监听 apollo 配置变动，在 flink 端替换新模型
3. 特色模块特色
- 存储介质变动：特色的存储原先只在云端的在线存储中，flink 端智能后须要将特色存在在本地磁盘或者内存中
- 特色更新交互变动：原先特色的新增或者批改都是在 FeatureService 监听特色的变动，将特色和存储的关系保护在特色服务中，当初须要在 flink 端监听特色变动，且须要将特色间接拉取到 flink 本地磁盘或者内存中
4. 决策模块
- 原先决策是作为服务给业务方调用，端智能后须要打成 sdk 包给 flink 端调用
挑战和计划
1. 模型调用本地化
模型调用由 SOA 形式改为本地调用。
- 计划
图 4 -2 模型调用本地化
flink 会接入决策 SDK，并通过 tf for java 将模型加载到本地，提供模型在线推理能力。模型更新后由 AI 治理平台更新 apollo 配置信息，flink 端通过监听 apollo 形式进行模型更新。
2. 特色本地化
通过将在线数据预加载到内存或者本地磁盘，进行特色的加工解决和本地调用。
- RocksDB 计划
图 4 -3 RocksDB 计划
a. 特色变更
- 特色散发零碎会监听 hive 表特色变更，在特色散发零碎将特色数据转成 SST 文件
- 特色散发零碎会将 SST 文件上传到 oss，并将配置变更告诉 apollo 配置核心
- flink 端监听 apollo 配置变更，将 sst 文件拉到本地磁盘
b. 特色查问
flink 端执行在线推理会从 RocksDB 查问本地磁盘的数据
- 内存存储的计划
图 4 -4 内存计划
通过 flink hive connector 的革新，将 hive 的离线数据，通过 Partitioned 的形式，让每个 taskmanager 只加载局部所需的维表数据。
- 内存存储的优化挑战
a. Partition 分区如何做？
基于用户 id 对数据进行预设分区
b. 内存如何优化？
图 4 -5 自研序列号计划
基于团队自研的 fast_bytes 序列化计划，能够将内存数据升高为之前的三分之一
利用端智能
利用端智能即在业务应用服务中，间接存储特色数据，运行模型进行在线推理。
整体流程
图 5 -1 业务利用端智能计划繁难流程图
如图 5 - 1 所示，示意了利用端智能计划繁难流程图，和 2 - 1 比照差别点如下。
1. 模型模块
- 模型运行环境：原先模型的运行环境是在 ModelService 集成的，当初模型在线推理在业务利用，须要在业务利用反对模型的运行
- 模型更新交互变动：原先模型的加载都是 ModelService 中监听模型新增或者批改，当初模型的新增和更新须要在业务利用监听 apollo 配置变动，在业务利用替换新模型
2. 特色模块
- 特色存储介质变动：特色的存储原先只在云端的在线存储中，业务利用智能后须要将特色存在在本地磁盘
- 特色更新交互变动：原先特色的新增或者批改都是在 FeatureService 监听特色的变动，将特色和存储的关系保护在特色服务中，当初须要在业务利用监听特色变动，且须要将特色间接拉取到业务利用本地磁盘或者内存中
3. 决策模块
- 原先决策是作为服务给业务方调用，端智能后须要打成 sdk 包给业务利用本地执行在线推理
挑战和计划
- SDK 设计
图 5 -2 决策 sdk 设计图
如图 5 - 2 所示，展现了决策 sdk 的整体设计。
- 模型服务将模型的加载，监听模型变更，优雅预热等逻辑打包成模型 sdk
- 特色服务将特色的加载，监听特色变更等逻辑打包成特色 sdk
- 决策在线服务将 ABTest，流程编排，计算逻辑，特色预处理逻辑以及模型 sdk，特色 sdk 逻辑打包为决策 sdk，给业务利用调用
- 模型类型兼容挑战
以后的业务利用如为 java 利用，则在运行时，只反对 tf 和 pmml 模型，python 和 python-gpu 模型无奈反对。
- 计划
目前短期解决方案为将局部 python 模型转为 tf 或者 pmml 模型打入业务利用进行运行，长期来说 AI 平台会摸索为各类模型提供一个对立的运行环境，或者可反对的转换工具反对各类模型在同一环境中运行
- 模型本地化
模型调用由 SOA 形式改为本地调用。
- 模型运行计划
图 5 -3 模型调用本地化
业务利用会接入决策 SDK，并通过 tf for java 将模型加载到本地，提供模型在线推理能力。模型更新后由 AI 治理平台更新 apollo 配置信息，业务利用通过监听 apollo 形式进行模型更新。
- 模型生命周期治理
计划新增或者批改模型上传到 oss，告诉 apollo 配置变更，应用服务监听配置变更，调用 jni 的 tf 接口加载模型到内存。在新老模型预热结束后调用 api 接口卸载模型。
- 模型更新计划
a. 新老模型如何同步运行？
创立两个模型对象进行治理，反对同模型新老版本同时运行。
b. 新老版本更新的如何优雅预热？
基于模型历史一小时的 rt 均值，以及以后最近 20 次申请 rt 是否小于该均值进行判断是否预热胜利。如果预热胜利则新老模型切换。
- 特色本地化挑战
本地化特色存在特色数据过大，导致业务利用启动过慢，无奈疾速扩容等问题。
- 计划
将特色加载从单线程转为多线程加载，并最大限度用上 ESSD 盘或 NAS 盘的 IO 下限
- 在线特色挑战
在线特色如果业务利用间接调用，会存在连接池无奈管控，调用量无奈管控，在线存储压力过大导致相互影响等问题。
- 计划
图 5 -4 在线特色治理图
通过 AI 平台对立的连接池治理，外围业务在线存储隔离以及限流机制防止在线存储的压力过大，相互影响问题。
目前一站式 AI 平台曾经可能反对在多端进行在线推理能力，然而很多细节点须要继续优化。后续一站式 AI 会基于以后问题对各端智能计划进行继续优化，也会基于业界支流的 AI 平台架构和计划，继续对 AutoML、AutoFE、模型 Fass 化部署、分布式训练和预测进行继续的建设和演进工作。
（本文作者：柳健强）