0、导论
为了打破主流基于云的机器学习 (ML) 范式的瓶颈，我们采用设备-云协作 ML 并构建第一个端到端的通用系统，称为 Walle，作为基础。 Walle包含一个部署平台，将ML任务及时分发到亿级设备；数据管道，高效地准备任务输入；和计算容器，提供跨平台和高性能的执行环境，同时促进日常任务迭代。具体来说，计算容器基于移动神经网络 (MNN)，这是一个张量计算引擎以及数据处理和模型执行库，它们通过改进的 Python 线程级虚拟机 (VM) 公开，以支持各种 ML 任务和并发任务执行。 MNN 的核心是算子分解和半自动搜索的新机制，大大减少了为数十个硬件后端手动优化数百个算子的工作量，并进一步快速识别最佳后端与计算图的运行时优化。数据管道引入了一个设备上的流处理框架，可以在源头处理用户行为数据。部署平台采用高效的push-then-pull方式发布ML任务，支持多粒度部署策略。我们在实际的电子商务应用场景中评估 Walle，以证明其有效性、效率和可扩展性。广泛的微基准测试也突出了 MNN 和 Python 线程级 VM 的卓越性能。 Walle已经在阿里巴巴大规模生产使用，而MNN已经开源，在社区产生了广泛的影响。
1、介绍
为行业内数百万乃至数十亿智能手机用户提供智能服务，主流范式是让移动设备通过原始数据发送请求，并在数据处理和模型执行后让云端返回结果。然而，这种范式遇到了三个主要瓶颈：
(1) 高延迟：每个移动设备与云端之间的网络延迟加上云端的请求处理延迟以秒为单位，这对于一些实时交互应用来说是无法接受的。例如，计算机视觉（CV）、自然语言处理（NLP）和推荐任务的实际延迟要求在数百甚至数十毫秒；
(2) 成本高、负载重：在设备端，如果没有Wi-Fi，上传原始数据会产生很高的蜂窝数据使用量。在云端，接收和存储来自海量移动设备的海量原始数据，通过多样复杂的机器学习算法对数据进行处理，并及时返回结果，不可避免地会产生高昂的开销。例如60s长的视频或音频的大小以MB为单位，每个用户每天推荐的原始数据大小以MB为单位。进一步乘以移动设备的规模，原始数据的总规模是巨大的；
(3) 数据安全和隐私：上传包含敏感内容（例如个人信息和用户行为）的原始数据可能会引起用户严重的安全和隐私问题。在云端存储和处理原始数据可能会面临数据泄露的风险。
通过解构基于云的ML范式，我们可以发现它只是简单地将移动设备视为交互界面，而忽略了经过10年发展的移动设备现在可以承担适当的数据处理和模型执行负载。因此，它没有利用设备端靠近用户和数据源的天然优势，从而减少延迟和通信成本，减轻云端负载，并将私有数据保存在本地设备上。为了克服主流基于云的机器学习范式的瓶颈，出现了端云协作机器学习范式，它提倡将部分机器学习任务卸载到移动设备上，让云端和移动设备协同完成机器学习任务。现有工作倾向于关注推理或训练阶段的算法决策（例如，设备-云任务拆分策略 [29] 和协作/交互范式 [34]），通常针对特定应用程序（例如，视频分析） lytics [6,11,31]，文本处理 [5]，推荐 [17,44]）。然而，实际工业场景往往涉及服务于数百万甚至数十亿移动设备的各种CV、NLP和推荐应用的全周期，构建通用系统将端云协同ML大规模生产成为一个难题。新要求。
我们构建了一个名为 Walle 的端到端系统，其总体目标是通过交换任何必要的信息（例如，数据、特征、样本、模型、模型更新和中间结果），在不同 ML 任务的每个阶段支持普遍的设备-云协作（例如，单设备-云和多设备-云）。如图 1 所示，Walle 支持移动设备和云服务器上在开发（例如，日常 ML 任务迭代的频繁实验和部署的实际需要）和运行（即 ML 任务执行和设备-云数据传输）阶段的整个 ML 任务周期（即预处理、模型训练和模型推理以及后处理）。遵循构建通用系统而不是集成大量特定于应用程序或特定于平台的解决方案的理念，Walle 作为具有标准 API 的基础 ML 基础架构，并保持移动应用程序的轻量级限制，已支持 1,000 + 大规模生产中的各种CV、NLP和推荐任务。
在构建 Walle 的过程中，我们遇到了一些促使我们做出设计决策的实际要求和挑战。Walle 以 ML 任务为导向，由部署平台、数据管道和计算容器组成，分别面向 ML 任务部署、输入准备和执行。
(1) 对于计算容器，一个主要需求是将 ML 任务迭代与移动 APP 的每月/每周更新解耦，使得将新功能集成到 APP 中的经典方法不可行。另一个关键要求是跨不同操作系统 (OS) 以及移动设备和云服务器的异构硬件支持具有高性能的各种 ML 任务。这就需要用C/C++构建张量计算引擎，对每个硬件后端做算子级和计算图级的优化。两种主要策略是手动优化（例如，在几乎所有 ML 引擎中），其工作量非常大，只能覆盖一些常见情况；和自动调整（例如，在 TVM [9] 中），它不能支持运行时优化，并且在涉及大量异构设备或需要频繁/快速 ML 任务迭代的工业场景中不可行。基于张量计算引擎，库应该以统一的方式实现预处理、模型训练和推理、后处理以及移动设备和云服务器，而不是单独和不完整的方式，如NumPy、OpenCV、TensorFlow（精简版）和 PyTorch（移动版）。没有集成设计，张量计算引擎的高性能无法暴露给不同的库，异构后端优化各个库的工作量大，包大；
(2) 对于数据管道，首要目标是准备原始数据，这些数据可以来自不同的来源并以各种格式构建，作为设备端或云端 ML 模型输入。将所有设备端原始数据上传到云端进行聚合处理的主流范式效率低且容易出错；
(3) 对于部署平台，其关键要求是在给定海量 ML 任务部署需求、间歇性设备可用性的情况下，以细粒度、及时和稳健的方式为众多移动设备管理、发布和部署 ML 任务，以及潜在的任务失败。
我们克服了上述关键挑战并建立了 Walle。
(1) 我们选择动态类型的、广泛使用的 Python 作为 Walle 中开发 ML 任务的脚本语言，通过对 CPython 的两个方面的改进，实现了一个 Python VM 作为计算容器的核心：一是放弃全局解释器锁（GIL）并支持具有VM隔离和数据隔离的任务级多线程；二是针对实际的设备端需求进行裁剪。这样的设计使日常 ML 任务迭代成为可能。在计算容器的底部，我们实现了一个张量计算引擎以及标准数据处理和模型执行库，称为 MNN [2]。 MNN首先引入了一种新颖的几何计算机制，将变换和复合算子分解为原子算子，从而大大减少了为数十个后端手动优化数百个算子的工作量；然后引入了一种新颖的半自动搜索机制，可以通过一系列算子的运行时优化快速识别最佳后端。在计算容器的顶部，我们将 MNN 作为标准 API 暴露给 Python 线程级 VM，支持具有标准数据输入的各种 ML 任务的整个周期。
(2) Walle中的数据流水线，我们主要构建了一个新的端侧流处理框架，实现对用户行为数据的源头处理。关键的新颖之处在于管理多个流处理任务的触发条件，以生成具有并发触发的 trie 结构的不同特征。我们还建立了一个实时隧道，将设备端的新鲜特性传输到云端使用。
(3) Walle的部署平台，我们提出使用git管理任务实体，将任务相关文件分为共享文件和独占文件，方便多粒度部署，发布任务采用高效的push-then-pull方式，按步骤。
Walle 现在是阿里巴巴 ML 骨干基础设施的一部分，每天被调用超过 1530 亿次，支持超过 3 亿的日活跃用户、30 多个移动应用程序和 300 多种 ML 任务。 MNN 现在是开源的，在 GitHub 上有 6,600 多个星标和 1,300 多个分支，并且还在 10 多家其他公司中用于生产。在示例真实应用程序（即直播和推荐）和平台统计中对 Walle 的评估证明了有效性、效率和可扩展性。 MNN 和 Python 线程级 VM 的微基准测试显示出优越性。
我们将主要贡献总结如下：
(1) Walle 是第一个端到端的、通用的、大规模的设备云协作 ML 生产系统，在底层屏蔽了硬件和软件的异构性，并且支持每日迭代周期和高性能的多样化 ML 任务；
(2) Walle 中的计算容器包括 MNN，它引入几何计算以大幅减少手动操作员级优化的工作量，以及半自动搜索以识别具有运行时优化的最佳后端；以及Python VM，率先摒弃GIL，支持任务级多线程，也是率先移植到移动端；
(3) Walle中的数据管道引入了基于trie的并发任务触发的设备端流处理，能够在源头处理用户行为数据；
(4) Walle中的部署平台支持细粒度的任务发布和部署到亿级设备，时效性和健壮性强。
2、前言
在本节中，我们首先阐述了为端云协作 ML 构建通用系统的背景和动机。然后我们详细说明主要的设计挑战。我们最终得出了系统需求。
2.1 背景和动机
机器学习任务：从开发人员的角度来看，ML 任务包括脚本（例如 Python 中的代码）、资源（例如数据、模型和依赖库）和配置（例如主要用于指定何时何地触发 ML 的触发条件）任务）。 ML 任务的整个工作流程可以分为三个阶段或子任务：预处理、模型执行和后处理。在预处理阶段，来自多个来源的原始数据被清理、整合和处理以提取特征和生成样本，然后将其输入模型。在模型执行阶段，加载模型进行训练或推理。在后处理阶段，对模型推理的结果进行处理（例如，通过应用一些排名策略或业务规则）以最终为用户服务。
激励工业应用：在阿里巴巴，目前至少有数百个在线ML任务，服务于数十亿业务场景的移动端日活跃用户，其中CV、NLP、推荐任务大致占比30%、10%、60%每天的总任务数和运行次数分别为 billion、1000 亿和 10 亿次。具体而言，（1）典型的CV类应用场景包括直播、视觉图像搜索、短视频分析、增强现实、安检等，主要任务包括关键帧检测、图像分割与分类、物品识别、人脸识别等。识别和效果、人体关键点和姿势检测以及色情检测； （2）典型的NLP类应用场景包括直播和语音导航，主要任务包括自动语音识别、文本转语音、文本分析和文本生成； (3)典型的推荐类应用场景包括商品重排、智能刷新、消息弹出、页面重排等，其中关键任务包括点击率预测、点击转化率预测、用户状态识别等。用户意图检测。
需要端云协同系统：这些应用程序对 ML 任务提出了严格的延迟要求。一般来说，（1）CV任务需要在30ms内处理每张图像； (2) NLP 任务要求在 500ms 内处理一个 5s 长的音频片段或处理延迟小于 100ms 的音频流； (3) 推荐任务需要在 300 毫秒内生成输出。此外，来自海量用户输入到 ML 任务的原始数据是巨大的。例如，（1）对于CV任务，一个60s长、1080p、8Mbps的视频大小大约为60MB； (2) 对于NLP任务，60s长的WAV/PCM音频大小在10MB左右； (3) 对于推荐任务，一个用户通常每天产生数千条原始数据，每条数据大小为 KB。此外，原始用户数据或多或少是敏感的，引发了安全和隐私问题。
上述实际需求使得主流的基于云的 ML 范例不可行，并促使我们采用端云协作 ML。关键原则是 ML 任务不仅可以在云端执行，还可以在移动设备上执行，而不是纯粹在云端执行。在机器学习任务的执行过程中，移动设备可以充当云端的中继，反之亦然。选择哪一方执行哪个阶段是灵活的，应结合 ML 任务的实际需要以及云和移动设备的特点。例如，选择哪一侧进行预处理应考虑该侧是否靠近数据源。进一步观察支持多样化 ML 任务和海量设备的工业需求，我们有动力构建一个端到端的通用系统，可以将设备-云协作 ML 投入大规模生产。
2.2 实际挑战
设备-云协作 ML 系统面临一些实际挑战，这些挑战跨越 ML 任务的执行、输入准备和部署阶段，如下所示。
执行挑战： (1) 迭代周期长：手机APP常见的更新周期包括新功能的开发、测试、集成（如我们上下文中提到的ML任务），以及APP商店的审核和发布分批到海量移动设备。因此，大多数APP每周更新一次，而一些超级APP（如手淘，阿里巴巴旗下的3亿日活跃用户的购物APP）每月更新一次。然而，ML 任务需要在现实中进行频繁的实验/部署，以便快速验证不同 ML 算法和模型的有效性，并确定最佳特征组合和超参数；
(2) 异构后端：云服务器和移动设备在硬件（例如 CPU、GPU、NPU、指令集架构 (ISA) 和内存）和操作系统（例如 Android、iOS、Windows 和 Linux）上存在显着差异)。在移动设备中，生态系统更加分散；
(3) 多样化的 ML 任务：工业应用涉及多种 ML 任务，需要多样化的模型结构（例如，卷积神经网络（CNN）、递归神经网络（RNN）、transformer、生成对抗网络（GAN）、和深度兴趣网络（DIN））。同时，预处理和后处理也涉及到大量的图像、文本和数值处理方法；
(4) 设备资源有限：每个手机APP只有一个进程。手机淘宝最大RAM只有200MB，包裹大小不能超过300MB。
输入准备挑战： (1) 非典型的用户行为数据：对于CV和NLP任务，大部分原始数据（如图像、视频、文本和音频）都是标准格式，标准库可以支持预处理。另一个不能直接支持预处理的主要数据源是每个用户在与移动应用程序交互时在时间和页面序列上的不同行为，这对许多 ML（尤其是推荐）任务至关重要。传统上，用户的行为数据全部上传到云端，远离源头，用Flink进行流式处理。然而，为了在源头启用预处理，不存在设备上的流处理框架；
(2) 触发条件多样：ML 任务往往需要很多特征。每个特征对应一个流处理任务及其触发条件。如何有效地管理并发任务触发的多个触发条件并非易事。
部署挑战：（1）海量任务部署需求：在阿里巴巴，活跃的ML任务规模至少在数百个，覆盖的移动设备可达亿级规模。每个ML任务的发布也需要结合APP版本、设备端和用户端的差异化； (2) 间歇性设备可用性：移动设备无线连接不稳定，前台只允许运行一个应用程序，而用户往往会频繁切换应用程序。因此，从某个APP的角度来看，每个设备的可用性是动态的。传统的push（如基于长连接）或pull（如基于轮询）部署方式不能保证时效性，云上负载高； (3)潜在的任务失败：移动APP作为一个进程运行。任何一个任务失败都会导致整个APP崩溃，严重影响用户体验。此外，由于大量的任务部署要求，在所有相关类型的真实设备上测试每个预发布任务是不切实际的。
2.3 系统要求
鉴于上述挑战，端云协同机器学习系统的设计应满足一些要求。
ML任务执行环境需要满足： （1）快速任务迭代：ML任务可以在手机APP上每日迭代，摆脱对APP原有更新周期的依赖； (2) 跨平台：应该屏蔽操作系统级别和硬件级别的异构性； (3) 高性能：优化需要针对移动设备和云服务器的异构硬件后端； (4) 普遍性：应支持多样化的 CV、NLP 和推荐任务。应以端到端的方式支持每个 ML 任务的预处理、模型执行和后处理阶段； (5) 重量轻：整个封装尺寸需要小，特别是对于移动设备。
ML 任务输入准备管道需要首先引入一个新的设备上流处理框架，具有并发任务触发能力，以便能够在源头处理用户行为数据。为了使云能够在远离源的地方以低延迟使用生成的特征（例如，用于特征融合或模型推理），还需要在移动设备和云之间建立实时通道。
ML任务部署平台应保证：（1）多粒度：任务发布需要支持统一的、设备级的分组、用户级的分组，甚至是极端设备特定的策略； (2) 时效性：可在短时间内覆盖大量移动设备； (3)健壮性：任务部署必须把稳定性放在首位。
3、Walle：架构和设计原理
在系统需求的指导下，我们构建了 Walle。我们首先介绍整个架构，然后是设计原理。
3.1 架构概述
如图2所示，Walle中的计算容器包括：（1）底层的跨平台高性能张量计算引擎； (2) 基于张量计算引擎的数据处理和模型执行库； (3) 一个Python线程级VM； (4) 顶部的标准 API。数据管道引入：（1）设备上的流处理框架； (2) 实时端云隧道。 Walle中的部署平台包括：（1）任务管理模块； (2) 任务发布部署模块
3.2 设计原理
计算容器的基本原理：如图 3 所示，在顶部，我们选择 Python 作为脚本语言，因为 Python 广泛用于开发 ML 算法，也是一种动态类型和解释的语言。为了支持在不同平台上执行ML任务的Python脚本，特别是在资源受限的移动设备上，我们通过改进CPython实现了Python VM，并针对移动APP的实际需求进行了裁剪。进一步考虑到 ML 任务执行的特点，包括多个任务的并发触发、不同任务之间的独立性以及每个单独 ML 任务中不同阶段的顺序执行，我们在 Python VM 中放弃了 GIL，通过首先将每个 ML 任务与线程绑定然后进行线程隔离来支持任务级多线程。这种基于 Python VM 的设计赋予了计算容器动态任务交付的能力，将每日 ML 任务迭代与每月/每周移动 APP 更新解耦。
在底层，我们用 C/C++ 实现了一个张量计算引擎，用于跨平台和高性能的考虑。核心是几何计算和半自动搜索的新机制，如图 5 所示。特别地，几何计算通过利用坐标变换的性质以及元素坐标与其内存地址之间的线性映射，从变换算子中提取出一个新的原子算子。这样一来，大约占所有算子49%的变换算子和复合算子都可以分解为原子算子，减少了人工实现和优化16种后端124个算子的算法、ISA、内存和汇编工作量的46% 。然后，为了快速识别移动设备或云服务器上可用的后端以最小成本执行具有一系列算子的计算图，我们在walle运行时应用半自动搜索以找到对于每个可用后端上的每个操作符具有最佳参数的最佳实现算法。通过结合后端的硬件属性和实施算法输入的大小，将参数搜索转换为解决约束优化问题。基于张量计算引擎，我们实现了科学计算、图像处理、模型推理和模型训练的库，并将它们作为标准 API 提供给 Python VM，支持标准数据输入的各种 ML 任务的全周期。
数据管道的基本原理：该体系结构如图 4 所示。首先，用户的行为自然地记录为时间级事件序列，在此基础上，可以通过聚合同一页面中的事件来创建页面级事件序列。然后，流处理任务的触发条件可以由事件/页面 id 序列指定。为了支持并发触发，我们将多个触发条件与事件序列的匹配问题建模为具有多个通配符模式的字符串匹配问题，并建议使用 trie 来组织触发条件，这样如果有新事件到来，所有触发的任务都可以被挑出来执行。鉴于流处理任务可以在连续产生的事件序列上被频繁触发，而一次性输出的大小很小，我们设计了一种集体存储机制来减少写入频率。最后，为了以低延迟上传设备流处理的输出，我们利用持久连接来实现实时隧道，在 500 毫秒内传输多达 30KB 的数据。
部署平台的基本原理：我们首先使用git管理任务实体，根据有多少设备可以共用这些文件，将与任务相关的文件分为共享文件和独占文件。文件分类进一步方便了任务部署策略的统一化和定制化。为了保证任务部署的及时性，我们提出了一种新的基于瞬时连接的推拉方法，其中推功能重用现有的客户端http请求用于业务服务，而拉功能通过内容分发网络（CDN） 和阿里云企业网络 (CEN)。为了任务部署的健壮性，我们在发布前引入云端计算容器的任务模拟测试，并强制分步发布任务，同时允许在任务失败的情况下回滚。
接下来，我们将在第 4 节介绍计算容器的设计和实现细节，在第 5 节介绍数据管道，在第 6 节介绍部署平台。
4、Walle 中的计算容器
我们以自下而上的方式介绍了计算容器：MNN，一个张量计算引擎以及数据处理和模型执行库； Python 线程级虚拟机；和 MNN 的标准 API。
4.1 张量计算引擎
张量计算可以看作是数据处理和机器学习的基础，底层张量计算的算子可以分为四类：
(1) 原子算子，作为后端优化的基本单元，如一些常见的一元算子（例如，取平方）和二元算子（例如，加法、减法、乘法和除法）；
(2) 变换算子，改变元素的形状和/或重新排序，例如转置、切片、连接和排列；
(3)复合算子，可分解为原子和变换算子，如3D卷积和池化、归一化、指数线性单元、长短期记忆单元等；
(4) 控制流算子，包括 if 和 while。
几何计算：目前，MNN 可以支持 Naop = 61 个原子算子、Ntop = 45 个变换算子、Ncop = 16 个复合算子和 Nfop = 2 个控制流算子。在 MNN 中为所有 Nba = 16 个后端实施和优化算子的工作量为 O((Naop + Ntop +Ncop)×Nba +Nfop = 1954)。进一步考虑到涉及原子和控制流算子的工作量是不可避免的，我们转向减少涉及转换和复合算子的工作量，这大约占整个负载的一半，并且在未来会增长（例如，随着更多的复合算子需要支持更多种类的深度神经网络 (DNN)）。我们的关键思想是从变换算子中提取一个新的原子算子，称为“光栅”。然后，变换算子和复合算子都可以分解为光栅算子和原子算子。由于每个后端只需要优化原子和光栅算子，整个工作量变为 O((Naop +1)×Nba +Ntop +Ncop +Nf op = 1055)，大约减少了 46% 的工作量。现在，问题变成了什么是光栅算子以及如何实现它。我们提出如下的几何计算机制。
本质上，变换算子的基本功能是将一个元素从一个内存地址移动到另一个内存地址，或者从几何中，将元素的坐标变换到另一个坐标。此外，内存地址是坐标的确定性线性函数。而且，给定一定的变换算子，可以确定坐标变换的公式。因此，根据元素在输入或输出张量中的坐标，通常是元素在输入或输出张量中的索引，也可以确定原始内存地址和移动后的内存地址。引入光栅算子，根据内存地址和遍历坐标，在输入张量和输出张量之间移动元素。我们以切片为例。A 是一个 2×4 矩阵，放置在具有唯一标识符/指针的连续内存地址中。通过仅保留第二行对 A 进行切片表示为 B，它是一个 1×4 矩阵。对于B中行索引为i，列索引为j（即B中的坐标(i,j))，其内存标识符相对于B的唯一标识符为i×4+j，与坐标呈线性关系，其中系数(4,1)称为步幅。根据切片的定义/规则（即 Bi, j = Ai+1, j），对应元素Ai+1,j在A中的坐标为（i+1,j），相对内存标识为(i+1)×4+ j = 4i+ j +4，其中系数(4,1)为步幅，截距4称为偏移量。光栅算子可以通过迭代坐标{(i,j)|0≤i<1,0≤j<4,i,j∈Z}，使用它们的内存地址将每个Ai+1,j移动到Bi，j实现切片的功能。
在光栅算子的实际实现中，我们引入了一个支持概念，称为“区域”，它包含一个输入张量，坐标范围，以及输入和存储中元素坐标与其内存地址之间的线性映射。输出张量，称为“视图”，可以由步幅和偏移量指定。另外，算子分解后，可以合并一些光栅操作进行优化。一种策略称为垂直合并，主要处理两个连续的光栅操作，跳过间接引用，对原始张量进行操作；另一种策略称为水平合并，它处理同一区域的两个并行栅格操作，只保留一个光栅操作。
原子算子优化：具体到原子算子，包括光栅算子，我们结合硬件异构，从算法、ISA、内存、汇编等角度优化实现。 (1) 算法级优化特定于一些计算密集型算子，通常是卷积和矩阵乘法。我们采用更高效的算法，包括 Winograd 和 Strassen 算法，以大幅减少乘法运算的次数； (2) ISA 级优化利用单指令多数据 (SIMD)，例如 ARM Neon 和 x86 AVX512 来加速。为了充分利用 SIMD 中的数据级并行性，我们仔细设计了数据布局和数据打包。具体来说，我们采用新的 NC/4HW4 布局 [35] 和用于卷积的通道主要封装； (3)内存层面的优化主要集中在减少读写次数以及提高内存分配的连续性。特别是，对于矩阵乘法，我们应用平铺和内存重新排序； (4) 基于汇编的优化可以实现指令级加速。我们使用手写汇编代码实现核心算子，并仔细应用一些优化，例如循环展开、软件流水线和指令重新排序。
半自动搜索：数据处理和模型执行通常涉及一系列算子（即分解后的原子算子、光栅算子和控制流算子）。同时，不同的后端对于算子有不同的实现和优化，移动设备或云服务器往往有多个后端可用。半自动搜索的全局目标是以最小的成本确定后端。每个后端的成本是所有具有最佳实现的算子的总和。为了在某个后端确定某个算子的最优实现算法，需要找到每个可能算法的最优参数。这被转换为可以快速解决的约束优化问题，其中目标是计算或内存成本，并且约束包含后端的硬件约束和算法输入的大小。我们制定了半自动搜索的整个过程，并详细介绍如下
我们让 BA 表示所有可用后端的集合，让 op1 → op2 → ... → opn 表示要执行的 一系列n 个算子。后端 ba ∈ BA 的成本定义为
其中 Copi,ba 表示在后端 ba 上具有最佳实现的算子 opi 的成本。半自动搜索的目标是找到成本最小的后端，可以表示为
然后，问题是如何计算每个 Copi,ba。对于每个算子opi 和后端 ba，我们让 algs(opi,ba) 表示具有最佳参数的所有可行的实现算法。那么，Copi,ba 被定义为
其中 (1) Qalg 表示算法 alg 中基本计算的次数，可以在给定（此处为“最佳”）参数和输入大小的情况下获得； (2) Pba代表后端Ba的性能。在MNN中，对于CPU类型的后端，如果后端ba支持ARMv8.2FP16，Pba凭经验取16倍频率；否则，Pba 取 8 倍的频率。对于 GPU 类型的后端，Pba 通过手动测试根据经验设置为每秒浮点运算数 (FLOPS)； (3) Salg,ba 表示算法 alg 在后端 ba 上的调度成本。
在 MNN 中，对于 CPU 类型的后端，Salg,ba 设置为 0；对于 GPU 类型的后端，Salg,ba 是凭经验设置的，主要考虑数据传输的时间。现在，剩下的问题是算子 opi ，后端 ba ，实现算法 alg ，以及输入的大小，如何确定算法的最优参数。在实践中，我们将其转化为一个约束优化问题，其目标是最小化计算或内存成本，约束主要包括SIMD单元的宽度、寄存器数量、线程数量和输入的数量。此外，我们主要关注优化以下参数：SIMD 中的打包大小、矩阵乘法中的tile大小、Winograd 算法中的块单元以及使用 Strassen 算法减少初等计算。我们以矩阵乘法中tile大小的优化为例。我们让 A 表示一个 a×e 矩阵，让 B 表示一个 e×b 矩阵，让 te 表示沿轴具有相同大小的瓦片大小，让 tb 表示沿 B 列的轴的瓦片大小，并让 Nr 表示寄存器的数量。优化目标是最小化内存读写次数。优化问题的公式如下：
这可以在运行时有效地解决。
与手动搜索针对每个算子使用一些通用参数逐个优化实现算法相比，半自动搜索不仅可以大大减少工作量，而且可以以更高的概率找到最优参数。 关于TVM为什么不采用auto-tuning，没有利用算子优化的人工经验，某个后端在算子和图层面的搜索空间大，静态编译耗时长，不支持runtime优化。最重要的是，考虑到 iOS 设备上可执行文件和即时 (JIT) 编译的安全性限制 [4]，TVM 生成的编译模型必须链接到移动应用程序，每月/每周更新，不能如预期的每天迭代。因此，TVM 在涉及大量异构设备或需要频繁/快速任务迭代（例如，更新部署的 ML 模型）的工业应用中是不可行的。相比之下，我们的张量计算引擎设计本质上是利用异构后端的手动算子级优化来缩小半自动搜索的空间，从而支持将模型部署为常规资源文件，并进一步促进运行时优化和日常 ML 任务Python VM 中的迭代。另一个好处是，对于越来越多的 ML 任务，从长远来看，移动 APP 的包大小不会增加。
4.2 数据和模型相关库
通过张量计算引擎，我们为机器学习任务的前处理和后处理阶段实现了科学计算和图像处理的库，以及模型推理和模型训练的库。特别是，科学计算和图像处理库可以看作是 NumPy [21] 和 OpenCV [28] 在轻量级和高性能方面的优化实现。轻量级意味着无需手动裁剪即可减小库的大小。 NumPy 1.9.3 和 OpenCV 3.4.3 的原始大小为 2.1MB 和 1.2MB，在 MNN 中分别减少到 51KB 和 129KB。高性能意味着底层张量计算引擎的性能优化可以继承到库中，避免额外的工作量。我们介绍库的实现如下。
科学计算与图像处理：我们使用原子、光栅和控制流算子来支持科学计算库中的数组创建和操作例程、二元运算、线性代数、逻辑函数、填充数组、随机抽样、数学函数等；在图像处理库中支持图像过滤、几何和杂项图像变换、绘图函数、色彩空间转换等。
模型推理和模型训练：我们目前在 MNN 中提供两种模式的模型推理，称为会话和模块。模块模式可以支持 transformer、动态 RNN 等所需的控制流算子，而会话模式则不能。基于会话的模型推理分为四个步骤：（1）加载模型，创建会话，将计算图中的所有算子按照拓扑顺序排列，申请所有算子需要的张量; (2) 给定每个输入张量的形状和每个算子的定义，计算所有张量的形状； (3)进行几何计算，具体来说，首先将变换算子和复合算子分解为原子算子和光栅算子，然后对光栅算子进行纵横合并； (4)半自动搜索识别最优后端，为每个算子申请内存并依次执行，返回推理结果。在第二步中，控制流算子需要中间结果来决定后面的执行顺序，会话模式不支持。为了解决这个问题，在第一步加载模型时，模块模式根据控制流算子的位置迭代地将计算图拆分为模块（即子图）。然后，各个模块的执行就和session一样了。
我们通过添加两个常见的优化器来实现模型训练：随机梯度下降（SGD）和自适应矩估计（ADAM）。在底部，我们添加了所有原子算子的梯度算子和一个光栅算子。
4.3 Python线程级虚拟机
大多数 ML 任务都是用 Python 实现的，并且需要 Python VM 来执行 Python 脚本。我们选择官方和最广泛使用的 Python 编译器和解释器，称为 CPython [43]。但是，CPython 的移植过程中存在两个关键问题，特别是对于资源受限的移动设备。第一个问题是包的体积很大。例如，CPython 2.7.15 包含 500 多个 C 脚本和 1,600 多个库，包括许多针对移动应用程序的冗余功能。第二个问题是CPython不能支持多线程来提高效率。 CPython本来就不能支持并发编程，引入了GIL来做多处理。GIL 只允许在一个进程中一次处理一个线程。但是每个手机APP只有一个进程，不允许多进程。如何在Python VM中支持tasklevel多线程成为一个问题。
为了减少包的大小，我们根据手机淘宝的实际需要对功能、库和模块进行了裁剪。(1) 功能裁剪：CPython首先将Python代码编译成文件后缀为“.pyc”的字节码，然后解释字节码执行。通过将编译阶段留在云端，只将字节码发送到移动设备执行，我们可以删除所有编译模块，将 17 个脚本保存在 C 中。 (2) 库和模块裁剪：我们保留了 36 个必要的库（例如 abc 、type、re 和 func 工具）和 32 个模块（例如 zipimport、sys、exceptions 和 gc）。经过包裁剪，我们实现了一个轻量级的移动端Python解释器，在业界属首创。例如，在基于 ARM64 的 iOS 上，包大小从 10MB+ 减少到只有 1.3MB。
在多线程方面，我们摒弃了GIL，进一步设计实现了业界第一个Python线程级解释器，支持多任务并发执行。如图 6 所示，每个任务被调度到某个线程，该线程创建一个独立的 VM，并包含 VM 运行时和任务相关数据。对于线程安全，关键是要进行线程级的VM隔离和数据隔离，将一个VM绑定到它的线程上，进而将VM运行时的上下文绑定到线程上。 (1) VM 隔离：原始Python VM的生命周期是固定在进程上的，每个进程有一个VM。我们需要修改 VM 实例的创建，以便一个进程可以容纳多个线程级 VM，每个 VM 都有其独立的生命周期。在 CPython 中，VM 被定义为 C 中的一个结构体，称为 PyInterpreterState。当 CPython 启动时，一个 PyInterpreterState 实例将被初始化。我们修改了 CPython 的初始化，特别是为每个线程创建和初始化一个 PyInterpreterState 实例。 (2)数据隔离：除了VM本身，VM运行时的上下文（如类型系统、模块、任务相关数据）也应该在线程层面进行隔离，避免多线程的并发问题GIL的保护。我们采用线程专有数据（TSD）技术进行数据隔离，每个线程都有自己的数据空间，不同线程不能同时访问同一个数据。我们主要将 TSD 应用于类型系统、缓冲池、对象分配和垃圾收集。
4.4 标准APIs
我们通过 Python VM 公开数据处理和模型执行的跨平台库以支持 ML 任务。对于前处理和后处理，科学计算和图像处理API与NumPy和OpenCV的原始API保持一致，对开发者友好，例如matmul、swapaxes、concatenate、split、resize、warpAffine、warpPerspective、cvtColor、 GaussianBlur等。针对推理和模型训练中的模型，暴露了常见的模型级和数据级操作的API，例如数据加载、模型加载和保存、会话创建和执行、优化器、超参数设置、损失计算等。
5、Walle 中的数据管道
我们详细介绍了设备上的流处理框架和数据管道中的实时设备-云通道。
5.1 设备端流处理框架
关键设计目标是支持在单个设备上对无限数据流进行状态计算。移动应用程序中的用户行为数据通过准确的时间戳形成流进行跟踪。用户行为数据的处理是有状态的，中间结果缓存在内存中或存储在本地以备后用。单个设备的资源是有限的，这意味着许多流处理任务的触发条件应该得到很好的管理。我们从事件序列创建、触发器管理、任务触发、任务执行和集体存储介绍了设备上的流处理。工作流程如图 7 所示。
事件序列创建：当用户与移动应用程序交互时，用户的行为将作为事件进行跟踪。基本事件有五种主要类型：页面进入、页面滚动、曝光、点击和页面退出。每种事件都记录有唯一的事件 ID、页面 ID、时间戳和事件内容（例如，曝光类型事件的项目 ID 和点击类型事件的图形小部件 ID）。由于用户的行为自然具有时间序列，因此可以直接创建时间级别的事件序列。为了进一步有利于处理特定页面或跨页面内的事件，通过聚合同一页面的进入和退出事件之间的事件来创建页面级事件序列。
触发器管理：一个基于事件序列的流处理任务包含脚本和配置，其中脚本实现数据处理算法，配置主要包括触发条件。特别地，触发条件可以由一系列触发器ID指定，其中触发器ID可以是事件ID或页面ID。
对于某个移动设备，需要高效地维护多个预处理任务，为不同的机器学习任务生成不同的特征，以便在事件到来时立即触发所有相关任务。关键是组织触发条件，快速匹配。将触发条件存储在列表中的简单方法效率低下，因为每次都需要遍历整个列表。事实上，多个触发器 ID 序列与事件序列（具有事件 ID 和页面 ID）的匹配可以建模为具有多个通配符模式的字符串匹配问题。因此，我们利用称为 trie 的前缀树数据结构来进行高效的触发器管理。更具体地说，特里树具有三种节点：开始节点、中间节点和叶子节点。特里树的根是唯一的起始节点。触发器 ID 是中间节点。存储流处理任务的端节点是树的叶子节点，反之亦然。当有新的流处理任务到来时，触发器id序列将被提取为中间节点序列，并在节点序列的第一和最后位置分别添加一对开始和结束节点。然后，从根开始对当前 trie 执行深度优先搜索。如果一条路径与节点序列完全匹配，则将流处理任务添加到叶节点；否则，不匹配的节点将作为新的子树添加到 trie 中，其根是深度优先搜索过程中最后匹配的节点。我们注意到，trie 的每条路径对应一个唯一的触发条件，叶子节点存储具有相同触发条件的流处理任务。如果两个触发器 id序列有共同的前缀，那么它们会被放在同一个子树中，从trie根到子树根的路径中的中间节点对应共同的触发器id。
任务触发：当新事件（带有事件 ID 和页面 ID）到来时，将返回触发任务集。首先引入两个trie节点列表记录多个触发条件的并发匹配状态，避免被通配符模式匹配阻塞。静态挂起列表存储了trie根的所有子节点，它们对应所有触发条件中的第一层触发器 ids，并始终保持活跃以进行匹配。动态待决列表存储了正在进行的匹配中期望的触发条件的下一个节点。对于流中的事件，如果其事件/页面 ID 与静态或动态列表中任何节点的触发器 ID 匹配，则将检查该节点的每个子节点是否为叶子节点。如果子节点是叶子节点，则返回端节点中的流处理任务；否则，孩子作为一个新的期望的下一个节点，将被添加到动态列表的缓冲区中。在任务触发事件结束时，动态列表将被缓冲区替换，并刷新缓冲区。
任务执行：当任务被触发时，脚本将在计算容器中运行以处理相关事件。除了计算容器的标准数据处理和模式执行API，为了方便从事件序列中提取相关事件和事件内容的处理，流处理框架还提供了一些基本功能，如下所示： (1) KeyBy，返回与给定键匹配的事件； (2)TimeWindow，返回给定时间窗口内的事件； (3) Filter，返回按定义规则过滤的事件； (4) Map，用定义的函数处理事件内容。
集体存储：对于每个流处理任务，其输出（通常是特征）使用 SQLite 保存为一个表。考虑到一个流处理任务可以被多次触发，而一次性输出的规模较小，在SQLite之上封装了一个集合数据存储API，减少写入次数，从而提高性能。具体来说，会在内存中创建一个缓冲表，流处理任务的输出首先写入缓冲表。如果写入次数达到一定阈值或调用读取操作，缓冲表将被写入数据库一次。
5.2 实时端云通道
除了供本地使用外，设备端流处理的输出还可以上传到云端供实时使用。我们实现了基于持久连接的端云隧道。安全套接字层 (SSL) 协议经过优化以减少连接建立、加密和解密的时间。数据在传输前压缩，传输后解压缩。为了应对高吞吐量，在云端构建了一个完全异步的服务框架。
6、部署平台
我们介绍ML任务管理、发布和部署的细节。整个工作流程如图 8 所示。
任务管理：采用 Git [41] 实现不同任务的隔离和特定任务的版本控制，同时支持具有访问控制的协同开发。特别是，整个任务管理被视为一个git组；每个业务场景对应一个git repo（仓库）；业务场景中的每个任务对应一个分支；任务的每个版本对应一个标签。
除了任务实体的管理外，任务相关的文件，尤其是资源（如数据和模型）可能会很大，也被细粒度地管理，以支持统一和定制化的部署。文件分为两类：一类是共享文件，可供大量移动设备使用（例如，具有特定版本APP的设备）；另一种是独占文件，只能供少数设备甚至特定设备使用。可以分别通过 CDN 和 CEN 高效地请求共享和独占文件。
任务发布和部署：可以采取统一或定制的策略在目标设备上部署任务。统一策略支持按APP版本分组发布任务，而自定义策略可以进一步支持按设备侧信息（如OS及其版本或设备性能）和用户侧信息（如年龄或习惯）。根据组内设备的数量，粗粒度的统一部署一般只涉及共享文件，而细粒度的自定义任务部署既可以涉及共享文件，也可以涉及独占文件。在极其个性化的场景中，定制策略支持部署某种任务，但将用户特定/独占的文件部署到每个单独的设备。
关于任务发布，我们采用了一种新颖的先推再拉的方法。我们复用已有的客户端业务请求来实现推送，通过将移动设备本地的任务配置文件添加到http头中，让云端与最新的任务配置文件进行比较。如果需要发布新任务，采用统一部署策略，则云端响应共享任务文件的CDN地址。如果新任务采用自定义部署策略，云端首先通过规则匹配判断移动设备属于哪个组，然后响应共享文件的CDN地址或独占文件的CEN地址。移动设备收到云端的响应后，可以使用CDN或CEN地址从最近的节点拉取任务文件。考虑到客户端业务请求频繁，而CDN和CEN在实践中速度较快，可以保证任务部署的时效性。
为保证任务发布和部署的稳定性，可以利用云端的计算容器创建不同操作系统的不同版本的手机APP模拟器，对预发布任务进行广泛的测试。通过模拟测试后，将进行测试版发布，仅在少数目标设备上部署任务。内测通过后，灰度发布强制分步进行，逐步覆盖所有目标设备。部署平台还配备了异常处理模块，可以实时监控任务的失败率，如果失败率超过一定阈值，可以立即回滚。
7、Walle的实验
我们在阿里巴巴的两大应用场景中对Walle 进行了评价。我们还对 MNN、Python 线程级 VM 和实时通道进行了广泛的基准测试。我们最终报告了部署平台的统计信息。
7.1 电子商务场景中的性能
计算容器在直播中的表现：电商直播为亿级用户带来了全新的网络购物方式。 2020年，手淘直播GMV超过4000亿元。该场景中的一个关键 ML 任务是亮点识别，即定位主播在介绍有关项目的有吸引力信息的时间点。
在传统的基于云的 ML 范式下，视频流从每个主播的移动设备上传到云端进行亮点识别，主要包括项目的检测和识别以及主播的面部检测和语音检测。由于在线主播数量多，视频流长度长，高亮识别对时延要求苛刻，云端负载过重，只能分析部分视频流和少量采样帧，这成为实践中的关键瓶颈。
借助 Walle，我们可以将轻量级模型的高光识别任务卸载到主播的移动设备上，并实现端云协同工作流，如图 9 所示。如果设备端模型可以识别视频中的高光高置信度的流，然后这些亮点可以在后期处理后直接显示给用户。只有那些在移动设备上被低置信度识别并且在实践中大约占 12% 的亮点需要由云端大模型处理。通过云端识别后，识别率在15%左右，会把精彩片段传送到移动端。
通过端云协同，亮点识别覆盖的主播和视频流数量大幅增加，同时云端的负载也得到大幅缓解。特别是，业务统计显示，与基于云的范式相比，新的端云协同工作流程使具有亮点识别的主播数量增加了123%；每次高亮识别云计算负载降低87%；并将每单位云成本的每日识别亮点的大小增加 74%。我们还评估了 Walle 计算容器在华为 P50 Pro 和 iPhone 11 上支持高光识别时的性能。总延迟分别为 130.97 毫秒和 90.42 毫秒。具体而言，表 1 列出了所采用模型的网络架构、参数大小和推理延迟。以上结果证明了我们的计算容器的高性能和端云协作的实际有效性。
推荐中的数据管道：在阿里巴巴的云端和设备端推荐模型中，item page-view（IPV）特性，记录了用户在商品详情页的行为（如收藏、加入购物车、购买），是显着的重要性。为了生成 IPV 特征，在传统的基于云的范式下，所有用户的原始事件数据都被上传到云端进行流处理，并与用户 ID 混合以进行显式识别。来自每个移动设备的时间级事件序列被分成多个同类序列，一个序列包含某种事件。云端为了获取每个用户的IPV特征，对所有用户的事件进行以user id和page id为key的联合操作，耗时耗资源且容易出错。
通过数据管道中的设备端流处理框架，每个移动设备只需要处理一小部分对应用户的本地事件，效率更高，更自然。实际上，IPV 特性调用了页面级事件序列的生成过程。输入是时间级事件序列。触发条件是页面退出事件。触发流处理任务是聚合所有事件（即，将同类事件聚类并统计页面的进入事件和退出事件）。由于每个事件中的原始内容包含冗余字段（例如，设备状态），因此对事件内容应用过滤。进一步考虑到 IPV 特征首先在推荐模型中编码（例如，通过 RNN）这一事实，通过使用计算容器的模型推理 API，编码过程也可以卸载到移动设备。
我们首先展示了从原始事件数据到 IPV 特征和 IPV 编码的大小缩减。平均而言，一个 IPV 特征的大小约为 1.3KB，涉及 19.3 个原始事件，大小为 21.2KB，而一个 IPV 编码只有 128 字节。
这表明，与将原始事件数据传输到云端进行流处理的传统范式相比，我们新的 IPV 数据管道可以节省 90% 以上的通信成本。除了通信效率，我们还比较了设备上和基于云的流处理的延迟。通过分析超过 10,000 个将原始事件处理为 IPV 特征的实际案例（从 200 万在线移动客户端的案例池中随机抽取），平均设备延迟仅为 44.16ms。相比之下，使用阿里巴巴内部版本的 Flink，称为 Blink，生成一个 IPV 特征的平均延迟为 33.73 秒。特别是基于云端的流处理超过200万个在线用户的原始事件，消耗253.25个计算单元（CU），其中1个CU表示1个CPU Core加4GB内存； IPV特征生成错误率为0.7%；平均延迟是在 10,000 个随机抽样的正常情况下分析的。这些结果表明，与主流的基于云端的数据管道相比，Walle 的新数据管道确实可以降低端云通信成本和云端负载，同时提高特征的时效性和有效性。
7.2 基准测试
我们首先在 Android 和 iOS 设备以及 Linux 服务器上将 MNN 与 TensorFlow（精简版）和 PyTorch（移动版）进行比较。设备端测试，我们使用华为P50 Pro和iPhone 11，后端覆盖单线程ARMv7、ARMv8、ARMv8.2以及OpenCL和Metal。对于服务器端测试，我们使用 AMD Ryzen 9 3900X (x86)、阿里云的 ecs.g6e.4xlarge（Intel Xeon (Cascade Lake) Platinum 8269CY、16 vCPU、64GiB 内存）和 NVIDIA GeForce RTX 2080 Ti，覆盖后端分别具有 4 个线程和 CUDA 的 AVX256 和 AVX512。我们将 ResNet 18 [22]、ResNet 50 [22]、MobileNet V2 [38]、SqueezeNet V1.1 [27]、ShuffleNet V2 [33]、BERT-SQuAD 10 [10] 和 DIN [46] 作为测试模型，常用于 CV、NLP 和推荐应用程序。 CV模型的输入大小设置为1×3×224×224，BERT SQuAD 10的输入大小设置为(1×256,1×256,1×256,1)，而DIN的输入大小设置为 1×100×32。我们在图 10 的左侧显示了 CV 和 NLP 模型的推理时间，并省略了非常低的 DIN 结果（例如，在使用 MNN 的 iPhone 11 上小于 0.2ms）。我们可以观察到 MNN 在几乎所有测试用例中都明显优于 TensorFlow（精简版）和 PyTorch（移动版）。除了更高的性能，MNN 在移动设备端的功能也更全面，因为 MNN 可以支持每个设备端后端的所有模型，而 TensorFlow Lite 和 PyTorch Mobile 无法支持某些后端和/或模型。
我们继续将 MNN 与 TVM 进行比较。我们以 Mac Book Pro 2019 和 NVIDIA GeForce RTX 2080 Ti 作为 TVM 的主机，分别对移动设备和 GPU 服务器进行自动调优和编译。 TVM auto-tuning 中的试验次数设置为 30。由于 BERT-SQuAD 10 在两个移动设备上的 TVM auto-tuning 在 curs timeout crash 中，我们采用默认参数设置进行模型推理。从图 10 右侧所示的评估结果来看，一个关键的观察结果是 TVM 的自动调整和编译大约花费了数千秒。相比之下，用于运行时优化的 MNN 半自动搜索大约花费数百毫秒。进一步结合4.1节的对比分析，我们可以得出MNN可以支持涉及大量异构设备并且需要频繁快速任务迭代的工业场景，而TVM则不能。第二个关键观察结果是，对于每个后端的每个模型，MNN 的推理时间都低于 TVM，尤其是在 GPU 服务器上。这种优势主要归功于 MNN 中手动操作员级别、后端级别的优化。
接下来，我们使用大约 3000 万个在线 ML 任务执行将 Walle 的 Python 线程级 VM 与原始 Python VM（即带有 GIL 的 CPython）进行比较。我们将性能定义为任务执行时间的倒数，并在图 11 中显示了平均性能提升。对于轻量级、中量级和重量级任务，Python 线程级 VM 分别提高了 52.11%、144.36% 和 25.70性能改进的百分比，分别。我们可以得出，没有 GIL 的任务级多线程是性能提升的关键。
我们最终评估了大约 3.64 亿次上传的实时隧道的延迟。图 12 显示了不同数据大小的延迟和上传次数。我们可以观察到超过 90% 的上传小于 3KB，平均小于 250 毫秒。即使 0.1% 的上传大小增长到 30KB，平均延迟也仅增加到 450 毫秒左右。
7.3 部署平台统计
沃乐部署平台自2017年底以来已支持手机淘宝、速卖通、闲鱼、优酷、菜鸟果果等30+手机APP，运行时间约1500天。总共部署了 1000+ 种 ML 任务，平均每个任务有 7.2 个版本。目前，部署平台正在维护和监控超过3亿台移动设备上的348种活动任务。为了演示任务部署的及时性，我们随机选择一个 ML 任务，监控其发布过程，并在图 13 中描述了覆盖设备数量如何随着时间的增长而变化。曲线的第一段为灰色发布阶段，需要 7 分钟才能覆盖所有 600 万台在线设备。特别是，在最后一分钟内增量覆盖了大约 400 万台设备。然后，随着越来越多的移动设备联网，覆盖设备的数量也会增加。直到 19 分钟后，已经覆盖了近 2200 万台设备。数据显示了 Walle 部署平台的可扩展性和及时性。
8、相关工作
在本节中，我们简要回顾了学术界和工业界的一些相关工作。
基于云的机器学习系统：许多公司在云上构建了他们的 ML 系统，这些系统由他们的云计算平台支持，例如 Amazon Web Services、Microsoft Azure、阿里云和谷歌云。架构清晰，包括数据存储（例如 HBase [14] 和 HDFS [13]）、批处理和流处理（例如 Storm [42]、Spark [45] 和 Flink [7]）的标准模块， ML 引擎（例如 TensorFlow [1]、PyTorch [36] 和 MXNet [8]）、虚拟化和容器化（例如 KVM [37] 和 docker [26]）以及弹性编排（例如 Kubernetes [15]） .
设备上的 ML 系统：一些模块是开源的，在轻量级、必要的功能和高性能之间取得了良好的平衡，包括设备上的推理引擎（例如，TensorFlow Lite [16]、PyTorch Mobile [12]、Core ML [3] ], 和 NCNN [39]);和 SQLite [24]，这是一个小型且独立的 SQL 数据库引擎。但是整个架构还是一头雾水，缺少几个核心能力，比如支持快速开发并发执行多个ML任务的on-device执行环境，以及轻量级的数据处理和模型训练库适用于各种 CV、NLP 和推荐任务。
设备-云协作 ML：这个概念可以追溯到边缘/移动计算，但侧重于云和移动设备在执行复杂 ML 任务时的协作，而不是将简单的数据分析任务从云卸载到边缘服务器或移动设备。以前的工作集中在算法框架或解决方案上，通常特定于某种应用程序。与之相对应的是，Walle 的目标是通用和大规模生产系统支持。我们回顾了一些有代表性的工作如下。
最初的范例是将模型训练保持在云端，但将模型推理（例如，面部识别、照片美化和问答）卸载到移动设备，以验证在减少延迟和保护隐私方面的设备优势。这种范式扩散的关键是模型压缩算法的进步，以减少模型大小和优化模型结构，例如量化 [19]、修剪和稀疏化 [20]、知识蒸馏 [23] 和神经架构搜索 [47]。后来，Mistify [18] 考虑到异构移动设备的定制需求，自动化了云到设备模型的移植过程，而一些工作设计了更合理的任务拆分策略，而不是卸载完整的推理任务。例如，Neurosurgeon [29] 被提议以 DNN 层的粒度在移动设备和云之间自动划分 DNN 计算。
除了推理，流行的跨设备联邦学习（FL）框架[34]优雅地概括了传统的参数服务器框架[30]，并使多个移动设备能够在云服务器的协调下协同训练全局模型。 FL的宗旨是将用户数据保存在本地设备上，从而保护数据安全和隐私。 FL中的端云协作纯粹是通过交换模型和定期更新。任务拆分策略是移动设备进行模型训练，云端聚合模型更新。谷歌已经在其名为 Gboard 的 Android 键盘上实验性地部署了 FL，以完善语言模型 [5]。
最后，在端云协同的原则下，提出了许多针对具体应用的解决方案。 FilterFor ward [6] 和 Reducto [31] 考虑了如何使用 ML 技术有效且高效地进行相机端帧过滤，以促进云端视频分析。 DDS [11] 采用交互式工作流程，其中摄像机首先上传低质量视频流，然后根据云端的反馈重新发送质量较高的几个关键区域，以提高推理准确性。 COLLA [32] 用 RNN 研究了用户行为预测任务，并利用知识蒸馏在设备端小模型和云端大模型之间相互持续地传递知识，从而减轻数据异构性和数据随时间的漂移。 DDCL [44] 和 CoDA [17] 专注于推荐。 DDCL 依靠补丁学习进行端侧模型个性化，并通过模型蒸馏将移动设备上的补丁集成到云端全局模型中。相反，CoDA 被提议从云的全局池中检索相似的样本，以增强每个移动设备的本地数据集，以训练个性化推荐模型。背靠Walle，CoDA入驻手机淘宝。
9、结论
在这项工作中，我们构建了第一个端到端的、通用的、大规模的生产系统，称为 Walle，用于设备云协作 ML。 Walle以ML任务的生命周期为导向，由一个跨平台、高性能、快速迭代的计算容器组成；更合理高效的数据管道；以及可扩展、及时且强大的部署平台。在实际电子商务场景和广泛的微基准测试中对 Walle 的评估证明了端云协作的必要性以及每种成分的优越性。 Walle 已经部署在阿里巴巴大规模生产使用，每天为十亿规模的移动设备用户提供服务。
205
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
