导读 本文将介绍阿里巴巴手机淘宝 Meta 技术团队历经四年研发的端到端、通用型、规模化产业应用的端云协同机器学习系统 Walle。Walle 的名字来源于电影《机器人总动员》。电影中 Walle 作为地球上最后一个机器人，负责对地球上的垃圾进行清理、变废为宝。我们的系统设计也秉持着相似的初衷，希望所设计和搭建的端云协同系统能够有效地利用数以十亿计移动端设备上的数据，充分释放其被忽略的价值，为用户提供更好、更便捷的智能化服务。

文章将包含以下几大部分：

1. Background & Motivation
2. Overall Goal & Architecture
3. Walle – Compute Container
4. Walle – Data Pipeline
5. Walle – Deployment Platform
6. Evaluation Results
7. Summary
8. Q&A

分享嘉宾｜牛超越博士 阿里巴巴 学术合作实习生
编辑整理｜晏世千
出品社区｜DataFun

---

01 Background & Motivation

首先介绍一下设计和搭建 Walle 系统的背景和动机。

随着移动端设备软硬件能力的进步，以及机器学习和深度学习技术的发展， 如今用户已经可以在其手机、平板等终端设备上享用多种多样的智能化服务 ，例如语音识别、推荐等等。

为了保证用户在实时交互中的良好体验，通常要求视觉、语音和推荐的延时在几百毫秒甚至几十毫秒的量级。同时这些应用需要处理来自大规模移动端用户的海量数据。

用户原始数据还会设计到很多敏感隐私信息，可能会引起用户的安全隐私顾虑 。例如在视觉应用场景中，通常会涉及人脸、人体姿势、观看历史等敏感信息；在语音导航场景中会涉及用户运动轨迹；在推荐场景中会用到用户个人信息，以及商品的点击、收藏、购买等行为数据。针对数据安全隐私问题，国内外出台了很多相关法律法规。我国于 2021 年开始实施数据保护法，互联网公司需要严格保护用户隐私。

阿里有 30+ 个 APP, 日活用户达到亿级，在客户端有300多种机器学习任务，CV、NLP 和推荐的占比分别为 30%、10% 和 60%，每日运行次数分别为 10 亿次、10 亿次和千亿次左右。

目前为移动端用户提供智能服务的框架是基于云服务端的。在用户端基于云服务端的数据发出请求，包含用户的原始数据，云服务器在经过数据预处理、模型执行的操作以后，返回结果，可以看出云服务器几乎承担了所有的计算负载，而移动端仅作为用户交互的界面，在云端计算完成后，返回结果。在实际应用中，基于云端的机器学习任务也面临着延迟高、机器学习成本和负载高以及隐私安全风险高等瓶颈。具体而言:

1.高延迟主要由端云交互以及在云上处理，数以百万计数以亿计的实时请求。

2.高成本和高负载，是由于传输、存储以及利用机器学习算法处理海量数据造成的通讯存储和计算开销。

3.隐私风险主要体现在上传敏感隐私的原始用户数据，并在云上存储和处理数据。

存在上述瓶颈的根源在于，忽视了移动端设备经过近 10 年的发展，目前已经能执行适量的数据处理和模型执行任务。

为了打破基于云机器学习框架的瓶颈，学术界和产业界开始探索端云协同的新范式。核心的理念是，做机器学习不仅可以在云上执行，也可以在移动端设备上执行，而非单纯的依靠云服务器。换句话来说，一个机器学习的部分阶段，可以从云上卸载到机器学习设备上。

端和云协同完成该机器学习任务，在机器学习任务执行过程中，移动端设备可以作为云服务器的一个计算中继，同时云服务器也可以作为移动端设备的一个计算中继。具体选择云还是端来执行机器学习任务的哪一个阶段，是相对灵活的。重点需要考虑该机器学习的实际需求，例如实时性，任务的复杂性等一些需求，以及云和端各自的一个优势。例如，数据的前处理阶段，选择端或者云，本质上是看谁更接近数据源。端云协同的新范式可以充分利用移动端靠近用户数据源的天然优势，从而降低延时，削减开销，降低云上负载。同时支持用户原始数据，始终不离开设备本地，实现隐私保护。

上图是我们对端云协同机器学习的一个粗略的分层，从底向上分别是硬件层、系统层、算法层和应用层 。已有相关工作主要处于算法层和应用层，针对特定的应用场景，例如视频分析、文本处理或推荐，并针对机器学习任务执行的某个阶段，比如模型训练或者推理，涉及一个定制化的算法解决方案。主要考虑算法层面的一些问题，例如端云如何分配任务，端云如何交互，以及端云的一些协同机制，多个端和云还是单个端和云等等。在产业界应用中通常会涉及视觉、语音、推荐等多种类型的任务而非单种任务，并且涉及任务全链路的执行而非单个阶段，要支持上亿个设备，而非少量的移动终端，因此如何将端云协同推向规模化产业应用的通用性系统成为了一个实际需求。

02 Overall Goal & Architecture

基于上述背景，我们设计搭建了 Walle 系统。先来介绍一下 Walle 的整体目标和架构。

Walle 遵循端到端、通用型、可规模化产业应用的设计原则 ，支持在机器学习任意阶段在端侧和云侧交换任意必要的信息，例如交换数据、样本、特征和模型，以及模型更新或者中间计算结果。

Walle 遵从了端到端的架构设计， 从开发者视角，覆盖了机器学习任务的研发期、部署期和运行时，并且支持在端侧和云侧运行时的每个阶段，包括模型的前处理、模型训练、模型推理和模型后处理。

Walle 还遵循了通用型的系统设计 ，而非集成了大量特定应用的定制化方案。因此Walle 可以作为机器学习的基础设施，向开发者透露出统一的标准接口。向下抹平端云设备软硬件的差异性，并保证移动APP的轻量化；向上则支撑多种机器学习任务的大规模产业应用。

Walle 的整体系统架构如上图所示 。一个机器学习任务主要包括脚本（python 机器学习三个阶段的实现），资源文件（数据，模型和依赖库）和配置文件（什么时候触发什么机器学习任务）

Walle 的核心系统模块包括：部署平台，数据管道和计算容器，分别负责机器学习的管理和部署，输入的准备，以及任务的执行。

• 计算容器为具有标准输入的多种机器学习任务提供了跨平台、高性能和轻量化的执行环境，同时支持机器学习算法频繁的实验和部署，从而满足实际任务“天”级迭代的实际需求。
• 数据管道，涉及到机器学习的前处理阶段，为端侧和云侧提供任务输入。Walle 主要关注了用户与移动端 APP 交互过程中产生的用户行为数据，包括时间和页面事件的行为序列。用户行为数据无法被数据管道中的数据库直接处理。
• 部署平台主要是面向亿级的移动端设备，以时效性和鲁棒性强的方式进行发布管理，并部署到大规模的机器学习任务。同时兼顾机器学习的一些需求，设备资源可用性的一些特点，以及任务失败的一些案例。

03 Walle-Computer Container

1. 计算容器的设计挑战和细节

在搭建计算容器的过程中，我们遇到了如下挑战：

第一个挑战：较长的迭代周期 ，大部分 APP 以周为计时方式来更新的软件需要每天迭代机器学习任务。需要频繁的部署，以验证机器学习算法和模型的有效性，找到最优特征组合或者超参设置。

第二个挑战：异构后端 。云服务器和移动端设备在体系架构（CPU，GPU，NPU）、内存等硬件层面以及操作系统（Andriod，IOS，Windows，Linux 等）等软件层面存在较大的差异性。移动端设备内部软硬件碎片化更为严重。

第三个挑战：机器学习任务的多样化 ，涉及视觉、文本、推荐任务，并且用多种神经网络结构（CNN，RNN，Transformer，GAN，VAE，DIN 等），前处理和后处理涉及很多数据的不同处理方法。

第四个挑战：APP 资源限制 ，每一个 APP 通常只有一个进程。对于手淘运行的 APP 最大就 200M，同时包大小不能超过 300M。

2. 计算容器架构的整体框架

在顶层选择了 python 作为机器学习开发语言，python 广泛应用于开发机器学习算法，同时是一种动态型的剪枝语言。为了在不同平台上支持机器学习脚本，如机器学习受限的移动端设备。通过裁剪，虚拟改造，Cpython 实现资源受限的移动端设备，虚拟机。改造分为两方面，首先是任务集，多线程的并发；另外面向 APP 端的实际需求进行了一个裁剪。

• Python Thread-Level VM

这是业界首个基于 python 的虚拟机设置。赋予了容器一个动态任务下发的能力。从而实现一个机器学习任务天级别迭代的需求。并且与 APP 天级别或者月级别迭代解偶。

• Data Processing & Model Execution Libraries

MNN 语言主要基于天级别来实现设计的（详见 https://github.com/alibaba/MNN or https://www.mnn.zone/）

整体来说 MNN 采用了端云一体的方式来设计。覆盖了矩阵运算，图像处理，模型训练，模型推理等功能模块。与已有的（Numpy, OpenCV, PyTorch, Tensorflow, TensorflowLight）框架不同，MNN 通过全新的一体化设计，能够将底层计算引擎的极致性能优化透出给上面不同的库，从而缩减针对异构后端每个库定制优化的工作量，同时保证包的轻量化。进一步，我们将 MNN 的功能透出到 python 虚拟机中，形成标准的接口，支持了标准机器学习的整条链路。

3. 机器学习容器关键模块的设计

• Tensor Compute Engine

从形变算子中提取了一个形变原算子，叫做 raster 算子，因此所有算子都可以拆解为原子算子，并且只有原子算子需要对硬件后端进行手工优化，包括算法实现、SIMD 向量化、内存优化以及汇编等层面。

在数据处理和模型计算图层面，主要引入了半自动搜索机制，运行时能最快的找到搜索方案。相比于手动搜索（即给每一个算子实现算法的常用参数，做了一个 case by case 的优化），半自动搜索不仅能大幅削减工作量，还能够提升找到最优参数的可能性。至于不使用 TVM 全自动搜索机制的原因是，TVM 在算子优化方面会利用人工优化经验，算子优化会存在一个较大的优化空间，较长的编译优化时间。从而支持模型以普通文件下发，因此 TVM 的算子必须链接进 APP，导致更新的实际时间为周级别或者月级别，从而不能实现天级别的快速迭代。TVM 在快速迭代的产业级的场景中是不可行的，例如需要更新部署的深度学习模型。

异构后端算子的手工优化，大幅缩减半自动搜索的空间，从而支持模型以普通文件形式动态下发。并进一步支持运行时的优化，以及在 Python 虚拟机中以天级快速的迭代。

另一个优势，长期看来，随着越来越多的机器学习的部署，移动端的包大小，并不会随着张量而增加。

4. 几何计算或者半自动计算的优化流程

首先计算图中的形变算子和复合算子会被拆解为原子算子和 raster 算子。拆解后的一些 raster 算子可以合并，以提升性能。然后应用半自动搜索机制，找到计算图在移动端设备或者云服务器上开销最低的可用后端。

5. 形变算子的基本原理

从几何构图的角度，一个元素由起点坐标转化到另一个起点坐标。

从数据拷贝的角度，一个起点的内存地址穿到另一个终点的内存地址。内存地址和坐标存在线性的映射关系，也称为 view，由 Stride 和 offset 来指定。进一步的给定一个形变算子以后，公式将会给定，有了输入和输出，通常会给定一个坐标（该元素的一个 Index），起点内存地址和终点内存地址也可以被确定。Raster 算子是根据起点的内存地址在输入和输出的 tensor 之间，通过遍历坐标范围，实现形变算子的一个功能。

在具体的 raster 算子实现的过程中引入了“区域”（region）的概念。包括起始的 views 元素坐标与信息地址之间的参数，搬运过程中的地址的一个遍历范围，也称为 size,以及输入 tensor。

6. 通过转置算子来进行一个简单的介绍

A 中的某个元素，记为行索引和列索引。该元素在转置后的坐标记为 R_b 和 C_b。

所以，(r_A,c_A)=(c_B,r_B)，此外给定这个内存相对坐标和地址，遍历 A 的坐标范围的话，raster 算子从起点矩阵 A 中搬运到终点矩阵 B 中。

更为便利的是遍历终点 B 矩阵的坐标范围。

在算子拆解之后，一些 raster 算子可以被合并优化。一种策略是垂直合并，主要处理连续的 raster 算子；另一种策略是水平合并，主要合并两个具有相同 region 的平行的 raster 算子。

半自动搜索的设计，全局目标是找到开销最小的可用后端，每个后端的开销由每个算子在最优实现下的开销累加得到。为了找到某个后端的最优实现，需要找到每个算子实现算法的最优参数设置。

该优化问题可以被快速的求解。

python 的虚拟机 cpython，是 python 官方应用最广泛的编译器和解释器。

cpython 的移植过程中，主要考虑资源受限的移动端设备，考虑两个问题，一个是包大小的问题，对于移动 APP 冗余的功能和模块。第二个问题是 cpython 无法支持任务级的多线程并发。cpython 本身是不能支持并发编程的，并通过引入了 GIL 锁来引入多进程。但是 GIL 只允许一个进程单次处理单个进程， 每个移动 APP 是单进程进行的，不支持多进程。进一步考虑到机器学习任务执行的实际特点，即同时会触发多个学习任务，并且任务之间通常是相互独立的，以及单个任务中不同阶段是顺序执行的。如何构建 python 虚拟机成为一个实际需求。为了削减包大小，我们进行了一个功能性的裁剪：

首先将 python 代码编译成字节码，然后解释字节码执行，通过将编译阶段放在云上，字节码放在端上执行。可以删除所有的编译模块。另一方面，出于对 APP 的实际考虑，对库和模块进行一个裁剪，最后实现了首个端侧的 python 解释器。例如在 ARM64 架构上的 10MB+ 的内存削减为 1.3MB。

为了支持任务级多线程执行，我们舍弃了全局解释器锁 GIL，并将每个机器学习任务与一个线程绑定，最后进行了线程隔离。

上表中列出了 MNN 中一些跨平台的数据和模型运行库。

对于前处理和后处理，矩阵运算的 API 和图像处理的 API 是和 NumPy 与 OpenCV 的保持一致的，从而便利开发者。对于模型推理和训练，主要透露了一些采样接口。包括数据加载模型，加载和保存。设限了加载和执行，超参设计和损失函数计算。

04 Walle - Data Pipeline

接下来介绍 Walle 中的数据管道。

传统的数据管道模式下，所有数据都会被上传到远离数据源的云上，并利用 flink 流处理框架进行处理。然而端云之间需要传输大量冗余的数据，以及云上需要计算和存储，数以百万或者数以亿计的聚合数据，传统的数据管道存在冗余高，资源消耗大，隐私风险高等瓶颈。

在 Walle 全新的数据管道中搭建了一个全新的端侧数据流处理框架，使得用户行为数据可以在近数据源处被高效处理。框架的关键是如何高效地组织和管理面向多个特征生成任务的触发条件。为了将端侧新产生的特征低延时地传输到云上进行消费，我们还搭建了实时通道，在 500 毫秒内传输 30KB 的数据。在实现上，实时通道主要是基于长链接通讯，通过优化 SSL 协议，以削减链接建立，加解密的一个耗时。数据在传输前进行压缩，并在接收后进行解压缩。为了应付高吞吐，云上采用了全异步的一个框架，并采用了多地部署的部署方案，使得每个移动端可以连接最近的节点，从而降低延时。

端侧流处理框架的设计，关键的设计原则和目标是，在单台资源受限的设备支持针对无线数据流的有状态的计算。 一个用户在移动端 APP 被记录的带有准确时间戳的一个行为数据，会构成数据流，用户的行为数据处理是有状态的。中间的处理结果会被缓存到内存中或被存储在本地，以便后续使用。单台移动端设备的资源是受限的，也意味着多个用户的流处理数据流条件，需要被高效的组织和管理。

在具体的流程方面 ，一个用户的数据首先被记录在具有时间维度的时间序列，并聚合同一页面上的事件形成在页面维度的事件序列。此外一个端侧流处理的触发条件可以用事件标识或者页面标识的序列来指定。为了支持多个相关流处理事件的批量触发，在事件序列上匹配多个触发条件，建模成一个存在多个通配符，规则的字符串匹配的问题，并提出了字典树管理触发条件的设计，使得当端侧一个新事件产生的时候，所有被触发的任务都被挑选出来进行执行。当一个任务被触发时，该任务的脚本将在计算容器中执行处理相关事件，除了计算容器透出的标准数据处理和模型之间的一些接口，为了支持从事件序列中提取出一些相关的事件，以及处理事件的一些内容，我们还实现了一些常用流处理的算子，包括 KeyBy, TimeWindow, Filter, Map 等等。考虑一个流处理任务在面对源源不断的事件序列时可能被频繁的触发，同时单次输出的量是比较少的。因此封装了批量存储的接口，以削减写的频率。

05 Walle - Deployment Platform

下面介绍 Walle 的部署平台。

首先，频繁的实验部署，要支持天级别的任务迭代，对部署平台的实时性提出了要求。其次是大规模多粒度的部署要求。在阿里，端侧活跃的机器学习任务有几百个，需要覆盖的移动端设备最多会达到亿级别。此外，每个任务的发布需要考虑移动 APP 的版本，设备和用户的分组。面对这些需求，我们遇到了一些挑战：

• 首先是移动设备和 APP 的间断可用性。移动设备通常采用无线连接，并且只允许前台运行一个 APP，而用户会喜欢频繁的切换不同的 APP，因此从 APP 角度看，每台移动端设备的可用性是动态的。这也意味着传统的基于推拉的部署方式无法保证良好的时效性，并会在云上产生较高的负载。
• 其次是潜在的任务失败。一个移动 APP 是以单进程来运行的，一个任务的失败会影响整个 APP 的运行，严重影响用户体验。由于大规模机器学习部署需求，在所有机型测试每一个预发任务是不现实不可行的。

在部署平台的细节方面，对于机器学习任务的管理主要通过 GIT 实现的多个任务的隔离，以及对每个任务的版本控制。同时支持多人的协作开发和权限管理。每一个任务管理作为一个给 Git Group，每个场景对应一个 GIT 仓库，场景中每个机器学习任务对应一个分支，而任务的每个版本对应一个 Tag。

任务相关的文件也被机器化管理。主要分为两类，一类是可共享的文件，该类型的文件可被大量移动端设备共享，例如使用特定 APP 版本的集合；另一种是独占型设备，只能被少量移动端设备，甚至单个设备所使用。这些文件可以通过 CDN 或者 CEN 被请求。

任务文件的分类进一步支持统一和个性化的部署策略：

统一策略 ：支持通过 APP 版本对设备进行分组，进行任务发布。

个性化部署策略 ：支持通过移动端设备信息，如操作系统及其版本、设备性能，以及用户侧信息，例如年龄、喜好进行分组发布。根据组中设备数量，粗粒度的统一的任务部署通常只涉及到共享文件，而细粒度的个性优化任务，还会涉及到独占文件。

在极致个性化的场景中，还支持特定的用户定制化，独占性的机器学习任务，部署到某台移动端机器学习任务上。为了保证机器学习部署的时效性，我们提出了基于短连接，先推后拉的部署方案。其中推的功能主要复用了端侧业务 HTTP 请求，而拉的功能主要通过 CDN 和 CEN 来实现。此外为了提升任务部署的鲁棒性，在任务发布前我们基于云测计算容器，引入了任务模拟测试环节。在任务发布中强制分步发布，并在任务失败时，支持任务的回滚。

06 Evaluation Results

接下来介绍一些实验结果。

1. Practical Performance in E-Commerce Scenarios

首先，介绍 Walle 系统模块在阿里电商场景的实际性能。

上图展示了在智能看点任务中的性能。淘宝直播场景中，智能看点任务是指通过机器学习方法，自动定位出主播讲解商品的看点的一个时间点，从未提升用户体验。在传统基于云服务的链路下，云上的负载非常高，以致于只能分析部分的直播视频流以及视频流中采样出的部分帧。为了突破上述瓶颈，我们将轻量化的小模型部署到每个直播组的移动端设备上，如果端侧模型能够以较高的置信度识别出直播视频流中的看点，那么这些看点在后处理以后，会展示给用户。只有识别置信度比较低的一些视频流，约占视频流的 20% 左右，才需要上传到云上，利用大模型进行处理。相比以前的纯云的链路，引入 Walle 之后的新链路，将云侧负载降低了 87%，将覆盖的视频流数量提升了 123%，并将单位云算力产出的看点增加了 74%，并且在部分真机测试中开销小于 150ms。

上述结果凸显了端云协同的学习框架的实用性，以及 Walle 的高性能。

上图是电商推荐的数据管道。

商品页面浏览特征，记录了用户在某些特定商品详情页面的具体行为。该特征对于推荐模型起到了特别重要的作用。云侧原有的 IPV 生产链路，需要将所有的用户原始数据上传。生产每一个特征的时间在 30 秒左右，并且需要消耗大量计算、通信、存储资源，并且存在 0.7% 的错误率。相比之下，Walle 新的数据管道，可以在端侧完成 IPV 特征的生产，整个流程上图左侧所示。平均每条 IPV 生产的端侧延时仅为 44.16 毫秒，同时缩减了超过 90% 的数据量，并且保证了特征的准确率。这些结果表明，相比主流基于云的数据管道，Walle 端云协同的数据管道大幅提升了特征生产和消费的时效性和正确性。

为了测试 Walle 部署平台的时效性和规模化，我们随机挑选了一个线上的机器学习任务，并监控了其部署到目标设备上的整个流程。在保证任务稳定性的前提下，Walle 部署平台成功覆盖了 700 万台在线设备，并且只用了 7 分钟；而覆盖全部 2200 万台设备，需要 19 分钟。

2. Extensive Micro-Benchmark Testing Results

除了实际业务应用的性能测试以外，我们还对 MNN python 虚拟机以及实时通道进行了广泛的基准测试。

我们在安卓和 IOS 移动端设备，以及 Linux 服务器主流硬件后端，对 MNN、TensorFlow（Lite）和 PyTorch（Mobile）进行了对比测试。测试采用了自然语言理解在推荐领域常用的七个模型。结果表明，MNN 在几乎所有测试样例中的性能都超过了其它深度学习框架。除了高性能外，MNN 还支持所有移动端、硬件后端，每一个模型的运行，而 TensorFlow（Lite）和 PyTorch 则无法支持某些硬件后端或模型，因此 MNN 在端侧的通用性是更好的。

此外我们还对 MNN 和 TVM 进行了对比测试 。实验表明，一方面 TVM 的自动调优和编译大约需要耗费几千秒，而 MNN 在运行时的半自动搜索只需要几百毫秒。结合 MNN 和 TVM 在设计和实际部署上的区别，可以得出，MNN 能够支持涉及大规模异构硬件后端并需要任务频繁迭代的产业化场景，TVM 则相对是不可行的。另一个方面，在每一个硬件后端上，每个模型的推理时间方面，MNN 也是低于 TVM 的，尤其是在 GPU 服务器上，这主要是 MNN 的手工算子优化的功效。

我们还对 Python 线程级虚拟机和 Cpython 进行了对比测试。通过对 3000 万次的线上执行任务数据进行统计，我们发现在涉及不同计算量的三种任务上，python 线程级虚拟机性能是大幅提升的。主要是由于 python 线程级虚拟机解除了 GIL 的限制，并支持了任务级的多线程并发。最后是关于实时通道的延时。通过对 3.6 亿次数据上传任务的统计，发现超过 90% 的上传量小于 3kb，平均延时低于 250 毫秒，而仅仅有千分之一的上传量达到了 30kb，平均延时也仅 400 多毫秒。

07 Summary

最后，对 Walle 相关工作进行一下简单的总结。

• Walle 是第一个端到端、通用型、规模化产业应用的端云协同系统。
• 计算容器包括 MNN 深度学习框架，它引入几何计算以大幅减人工优化的工作量，以及半自动搜索以确定运行时优化的最佳后端；还包括 Python 虚拟机，它是第一个解除 GIL 限制，并支持任务级多线程的虚拟机，也是第一个移植到移动设备的虚拟机。
• Walle 新的数据管道，通过引入全新的端侧流处理框架，并且通过基于 trie 的任务触发管理机制，实现了端侧多个流处理任务的批量触发。我们还在端云之间建立了实时的传输通道，以支持数据百毫秒级别的上传下载。
• Walle 部署平台支持细粒度、分布式的任务管理，采取推拉结合、多批次任务发布的方式，保证了时效性和稳定性。同时支持统一和定制化的多粒度任务部署策略。
• 通过电商直播和推荐场景的实测，以及广泛的基准测试，证明了 Walle 的优越性。
• Walle 一直在阿里巴巴大规模使用，并且 MNN 已经开源并在社区中具有广泛影响。

08 问答环节

Q1：这套系统对阿里的指标影响有哪些？

A1：推荐的话在端上重排的业务，也是广泛落地的。另一块是直播这一块。

Q2：walle 是基于 MNN 打造的吗？是否开源？

A2：Walle 中的计算容器是基于 MNN2.0 打造的，这一块是开源的，其他部分是不开源的。

Q3：walle 是否属于横向联邦学习的范畴？

A3：在联邦学习中，从任务分配来看，端侧负责训练任务，云侧负责模型聚合任务；从交互机制来看，采用多端对云的架构，单这些都属于算法协同机制的事情。Walle 则面向一般化的端云协同，并且属于系统层面。

Q4：可以讲一下 python 绑定虚拟机的一些方法吗？

A4：看一下论文的一些细节。

Q5：推荐模型更新是怎么做的？

A5：在端上探索基于 finetune 或者增量式学习，保存不同的模型版本。然后在推理的时候做加载。云上的更新周期比较慢一些。

Q6：通过 walle 部署了多少个模型？

A6：通过 walle 累计部署了超过 1000 个，现在统计有 300 个。