端计算 Walle：2235 亿次运算，为了无法计算的端智能价值（二）

面临的挑战

今年我们加大投入，并联合了算法团队、搜索推荐工程团队、手淘基础链路团队，共建端计算的工程体系。随着端计算体系承载的业务数量与复杂度的快速增加，也对 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（浮窗）、触发其他模型任务联动等。在这个环节需要有一套统一的多样的触达机制，满足不同场景不同定制。

本文转载自淘系技术公众号。

原文链接：https://mp.weixin.qq.com/s/V2QrhvW-F8asXvtyg7i0XA