本文知识点提炼：
1、端计算在移动设备上的应用探索 
2、技术方案与核心模块设计
3、总结与展望

背景

传统的云计算，使用的是端侧采集数据，云端处理消费，再反馈给端侧的模式。而伴随着数字化转型的浪潮、万物互联时代的到来，5G、大数据、人工智能等信息技术的快速发展，云计算已经无法特定场景对低延迟的高要求。此时基于路由器、交换机、基站等计算节点的边缘计算因运而生，其具有低延时、低成本、数据安全、数据丰富等特点。

而借鉴边缘计算的思想，并融合手淘电商的业务场景，我们在18年初提出并搭建了基于移动设备的第一代 端计算工程系统 DAI 。其基于 TensorFlow 的模型推理能力，将计算、决策前置到移动终端，获取最原始的数据，实时在端侧进行数据分析与决策，端到端的响应耗时可以做到百毫秒级别。同时将过滤后的数据传输上云，与云端形成协同效应，并减少服务端的带宽、运算成本。

18 年双十一期间，端计算在部分场景小范围尝试和落地，并在主会场的猜你喜欢，详情页的看了又看等业务上取得了不错的效果。

端计算DAI架构图

面临的挑战

今年我们加大投入，并联合了算法团队、搜索推荐工程团队、手淘基础链路团队，共建端计算的工程体系。随着端计算体系承载的业务数量与复杂度的快速增加，也对 DAI 等基础设施提出来了更多更严峻的挑战。

▐ 研发效率

初期的设计是算法同学通过控制台下发 TensorFlow 的 pb(protobuffer) 模型文件，所有的逻辑均在 pb 的网络结构中实现。这种模式下，存在如下一些不足的地方。

由于端侧集成的为精简版 TF Mobile ，算法同学编写的TF代码在端侧可能存在缺少算子而跑失败的情况。

新增或修改 Op 需要 Native 发版实现，周期长。

if、for 等流程控制在TF中难以处理。

TF 的端侧推理耗时较长，业务决策响应不及时。

▐ 稳定性

Android 出于包大小和动态性的考虑，采用了动态下发并加载动态库的模式。但是由于 Android 设备的碎片化，动态加载存在着诸多兼容性的问题，测试也不好验证。同时 JavaScriptCore 本身在 iOS 上是个黑盒，曾在 iOS9 上就出现过大量的 JavaScriptCore 的 Crash 问题。而端计算作为算法处理的基础设施，每日被调用的次数非常庞大。所以任何一个极小的不稳定因素，都有可能被放大。

并且端侧的故障，大部分是由于线上配置发布引起的。手淘对于线上变更有着严格的安全生产流程，涉及发布窗口、验证、灰度、观察等各个环节。而算法同学往往对端侧的指标不熟悉，一些潜在风险未必能及时发现。我们需要在各个环节加强完善设施能力，在风险发生前及时暴露，在发生中将影响减至最低。

▐ 任务治理

在年初的时候，我们进行了一次线上业务梳理。发现手淘环境中有5+的特征提取任务、4+的曝光任务。很多基础的数据特征，在不同的业务场景下都需要使用到，且对于同一特征的加工方式往往相识。若所有的特征均由各业务方自行进行加工，难免会造成开发成本及端上计算成本的浪费。而且无法高效地将已有能力复用到更多业务和App上。

▐ 场景覆盖

在端计算模式快速发展中，我们关注到部分业务域虽然不具备算法资源，但是希望借鉴端计算的思路，在一些输入因素相对比较固定的场景下，对用户特定的行为进行快速的响应与干预。同时初期 DAI 的触达能力比较单一，仅将执行结果以广播的方式通知到业务方，由业务方自行实现通知后的触达响应逻辑。而一些常规的触达途径，在大部分业务域都是相识的。比如Push、Poplayer（浮窗）、触发其他模型任务联动等。在这个环节需要有一套统一的多样的触达机制，满足不同场景不同定制。

端计算2.0 Walle

基于上述问题，我们对 DAI 进行了全面的升级，并改名为 Walle 。希望如电影 Walle 一样，将被遗忘在端上的数据汇集起来，成为挖掘金矿的工厂。

▐ 架构设计

Walle架构图

整体设计上，Walle 由端、云两部分组成。

端侧包括采集层、计算层、触达层三个模块。采集层对接了端侧不同的数据源，进行数据存储与特征加工。计算层内置了 MNN、AliML 等。所有模型任务经过调度系统后会在计算容器中进行实时的决策。决策结果经由触达层的多种途径触达用户。

云侧分为运维平台、数据服务、触达服务三部分。运维平台负责日常的运维监控、数据服务为云端协同提供通道支撑、触达服务配合端上的触达层，进行人群圈定和事件分发。

▐ 解决思路

更高效易用的计算容器

为了解决算法模型的迭代部署效率，我们需要一套脚本语言环境来承载复杂控制与业务定制化逻辑。基于新版的计算容器，大幅降低算法同学的认知与学习成本，无缝衔接服务端算法应用流程，极大提升部署与迭代效率。

同时我们使用自研的轻量级深度学习引擎 MNN 替代 TF ，扩展了机器学习计算集 AliML ，集成了高性能时序数据库 ProtoDB ，为用户提供了一套低成本、高效、快速迭代的端侧模型预测与训练的执行环境。

计算容器

更夯实的稳定性保障措施

作为逐步大规模应用的端计算基础设施，稳定性可谓重中之重。我们对端计算的开发、发布、运行时、监控、降级等全链路进行了详细梳理，针对一些有风险的环节进行重点保障。

• 开发测试阶段

代码覆盖率。在SDK中内置了代码覆盖率与性能热点的采集与上报功能。配合Jarvis平台的真机验证系统，可以在发布阶段更全面地度量真机验证的效果，将风险暴露在上线前。

Mock系统。为了实现自动化测试能力，我们开发了Mock系统。支持基于基线数据，对端计算任务的入参、出参、异常逻辑进行Mock验证。

• 运行时

单机熔断。由于算法模型的迭代频率较高，为了避免在日常的迭代过程中引入新问题，我们在端侧引入了单机熔断的机制。既某个模型任务的执行耗时超过阈值或者执行线程卡死时，我们会重启执行线程，并对当前的模型任务进行一定时间段的熔断处理，以免影响其他模型任务的正常执行。

高危模块移除。移除了So动态加载、JS等存在潜在风险的模块，使用更优雅的方案替代。

疑难问题解决。端计算演进期间，我们攻克了诸多内存 Abort 、 Crash 、 多线程锁等疑难问题，整体Crash率有大幅降低。

• 监控

调试工具。支持验证版本的生效配置，扫码拉取端侧日志，对任务异常进行实时调试排查。

监控大盘。面向App运维同学，可全局地观察整个端计算整体关键指标，以及每个任务的资源消耗排名，异常情况排名等。

任务报表。面向算法同学，包含全链路多维度监控，长尾报表等，可直观地实时反馈任务上线后的运行情况。

Crash定向监控。为了更准确实时地定位线上Crash问题，我们与Emas团队合作开发了模型Crash定向监控能力。在Emas平台上，现在可以直观地看到所有模型任务的Crash分布情况，以及Crash调用栈明细。

更体系化的数据能力

从共享端侧特征、降低重复计算与使用成本、提升特征查询效率等方面考虑，我们建立了端侧基础特征服务DBFS。基于基础特征分层抽象出了统计特征、用户画像、情景计算等高维业务特征，同时支持算法同学进行特征op的自定义扩展。DBFS目前提供100+个基础特征op，10+中间层业务特征op，涵盖电商场景最常用的点击、收藏、加购、下单等行为。

DBFS架构图

更丰富的场景覆盖能力

为了满足不同场景对端计算能力的诉求，我们建设了端计算的触达中心，其包含两部分能力：

• 在端侧实现了一套简化的CEP（复杂事件处理）引擎，支持根据预置的规则序列，使用滑动窗口的模式匹配用户的操作行为，进行实时的用户干预。对于一些轻量化场景，可以直接使用CEP来定义行为，而无需引入机器学习模型。
• 同时在触达层面，对接了奥格的人群系统，支持针对特定人群进行CEP规则或者模型任务的投放。在行为命中后的业务响应环节，我们统一扩展了Push、Poplayer、Broadcast、WalleTask、UT、NativeCallback等多种途径触达用户。

触达中心

总结

今年双十一期间，端计算首次在手淘大规模落地，覆盖主搜、信息流推荐、云主题、会场、智能Push、红包雨、促升、直播等场景。双十一当日共执行了2235亿次运算，在大幅提升GMV的同时，也为用户带来了更好的交互体验。同时除了手淘外，目前端计算也已在猫客、闲鱼、AE、CBU、零售通、优酷等App有成熟方案落地。

端计算的出现，填补了云计算在网络延时、数据丰富、隐私安全、算力成本方面的不足。而端计算与云计算也会以共存与互补的姿态，拥抱智能化浪潮。随着端计算体系的成熟以及基础设施的完善，相信未来算法同学们会有越来越多的创新项目孵化与应用，我们共同期待。

原文链接
本文为阿里云原创内容，未经允许不得转载。