你竟然是这样的端智能?

很久以前，我还是个保洁员，直到有一天上帝说不了解端智能的保洁员不是好保洁员，于是我向隔壁小哥偷学了端智能这项技术，写下了这篇文章，如有错误，请找隔壁小哥~

本文将谈谈端智能以及端智能在西瓜视频的发展。你可能已经听说过端智能，这犹抱琵琶半遮面的样子真是令人心痒，今天咱就扯下它的面纱看看。

从云智能到端智能

可能有很多人纳闷不是要聊端智能么？怎么还牵扯到边缘计算了，莫不是为了凑字数？实际上从云智能到端智能的延伸实际上也是云计算到边缘计算的扩展。我们知道云计算自身有着许多的优点，比如庞大的计算能力，海量的数据存储能力等等。现在很多对外提供服务的 APP 本质上都是依赖各种各样的云计算，比如直播平台、电商等等。但新型用户体验追求更加及时，稳定性的服务，这就促使我们想要将服务尽可能的部署在物理设备所在位置，最终推动了边缘计算的发展。

从云智能到端智能，本质也是如此。以无人驾驶为例，总不能在驾驶过程由于网络波动导致汽车停止对路况的计算吧，或者说在万分之一秒内还不确定是要刹车还是加速吧？

那究竟什么是边缘计算呢？边缘计算与所谓的端智能又有什么联系？继续往下看~

边缘计算

边缘计算是一种致力于使计算尽可能靠近数据源，以减少延迟和带宽使用的网络概念。通常来说边缘计算意味着在云端运行更少的进程，将更多的进程移动到本地设备，比如用户的手机，IOT 设备或者一些边缘服务器等。这样做的好处就是，将计算放到网络边缘可以最大程度减少客户端和服务器之间的通信量及保持服务稳定性。

不难发现，边缘计算本质是一种服务，类似于我们现在的云计算服务，但这种服务非常靠近用户，能够给用户提供更快速的响应，简单点说就是干啥啥快。

需要注意的是，边缘计算并非用来取代云计算的，如果说云计算更注重把控全局，那边缘计算则聚焦于局部，本质上边缘计算是对云计算的一种补充和优化，可以帮我们从数据源头近乎实时地解决问题，凡是在需要减少时延或追求实时目标的业务场景下，都有它的用武之地，比如：计算密集型工作，人工智能等场景。这里的人工智能的场景就涉及到我们下面要说的端智能了。

端智能的本质

对于人工智能，想必我们已经见怪不怪了，尤其是以头条/抖音/快手为代表的应用，都是将机器学习用到极致的产品，此外像扫地机器，无人车等硬件设备也是人工智能落地的最佳示例。那我们要说的端智能又是什么角色呢？

和从云计算到边缘计算的发展类似，人工智能的发展也经历从云到端的过程，我们常说的端智能实际上就是把机器学习放在端侧去做。这里的端侧是想相对于云端而言的，除了我们常见的智能手机外，端侧设备也包括各种 IOT 设备，嵌入式设备等，如语言翻译器、监控摄像头等，当然无人车也属于该领域。

从 2006 年开始，人工智能进入第三次发展阶段，并以 AlphaGo 先后战胜李世石和柯洁宣告新时代的到来，这背后得益于：

• 大数据的发展及硬件算力提升，CPU、GPU 及专用计算单元；

• 深度学习算法及框架不断演进，从 Torch、Caffe 到 TensorFlow、PyTorch 等。

与此同时，端侧设备同样在算力，算法及框架有了突飞猛进的发展：

• 算力：CPU、GPU 性能提升，手机算力不断增长，以及专门用于 AI 的神经网络处理芯片逐渐成为标配，已经能够不同程度上支持算法模型的运行；

• 框架：面向移动端的机器学习框架的诞生让我们能更轻松的在端侧应用机器学习。在手机侧，Apple 的 Core ML，Google 的 NNAPI 提供了系统级别的支持，除此之外业内也有很多优秀的端侧框架：TensorFlow Mobile/Lite、Caffe2、NCNN、TNN、MACE、Paddle&Paddle Lite、MNN 及 Tengine 等；

• 算法：模型压缩技术不断发展，其中量化已经非常成熟，基本能够实现在不降低精度的情况下将模型缩小为原来的 1/4~1/3；此外，针对端侧的算法模型在不断的优化过后，架构设计变得越来越成熟，对于端侧设备的兼容性也愈加友好。

当然，我们都知道最终驱动云智能和端智能发展的根本动力是实实在在的产品需求。从端智能的角度来看，由需求驱动的 AI 场景应用已经在软硬件多方面成为产品的主要卖点，比如手机摄像能力的提升，除了摄像头等硬件的发展外，各种图片处理算法的发展也功不可没；再像抖音、快手等应用的各种模型特效，在简化创作的同时也极大改善了产品的形态。

为什么要做端智能?

要知道为什么做端智能本质就是需要搞清楚当前云智能面临什么样的问题。正如之前所说，云智能的发展建立在现代需求之上，它主要的优势是：

• 面向海量数据，这意味我们能通过不断的累积数据，寻求问题的最优解；

• 设备资源充足，算力强大；

• 算法规模庞大，空间不受限制；

但这种依赖云端的架构方式也有着相应的缺陷：

• 响应速度：依赖于网络传输，稳定性和响应速度无法得到保障，对于实时性要求高的情况而言，该问题近乎于无解；

• 非实时性，脱离即时 Context，用户敏感度差；

而端智能的优势恰好能作为云智能劣势的补充：

• 响应速度快：在端侧直接获取数据进行处理，不依赖网络传输，稳定性和响应度 OK；

• 实时性高：端侧设备实时触达用户，不存在中间商赚差价，能够实时感应用户状态；

除此之外，由于数据和生产和消费都是在端侧完成，对于敏感数据可以保证隐私性，规避法律风险；另外我们可以进行更精细化策略，有可能实现真正的实现千人千面。

端智能的局限

前文我们说了端侧智能能够补充云智能的几个缺点，但它也有着自己的问题：

1. 和云侧硬件设备相比，端侧资源 &算力相对有限，无法进行大规模持续计算，模型不宜过于复杂；

2. 端侧往往只是单用户数据，数据规模小，全局最优解难寻。此外由于端侧应用生命周期不可控，数据周期往往较短。

在这两个条件的制约下，端智能往往意味着是只做推理，即云端训练模型下发到本地后做推理。

当然随着技术的演进，现在我们也开始探索联邦学习，它本质上是一种分布式机器学习技术，主要希望在保证数据隐私安全及合法合规的情况下，可以有效解决数据孤岛问题，让参与方在不共享数据基础上实现联合建模，提升模型的效果。在这里，端上能做的就不仅仅是推理了还有学习过程。

5G 与端智能

之前有同学提到过既然 5G 又快又好，那完全没必要搞端智能啊。这里简单谈谈我自己的理解。(如有不对之处，请找隔壁小哥)

5G 的高速连接和超低时延，目的在于帮助规模化实现分布式智能，也就是云-端智能一体化。来具体解释下：5G 给端和云之间的连接提供了更稳定，更无缝的的支撑，此时网络就不再是端云互通的瓶颈了，但伴随万物互联时代的到来，数据规模将会进一步暴增，进入超大数据规模的时代，此时服务端的算力就会成为瓶颈，那么此时在端侧对于数据的预处理和理解也就更加重要，这就需要端智能的介入。

举个安防领域的例子，现在很多家庭摄像头都支持云存储，如果我们希望只在有人活动的时候才会将视频保存到云端，该怎么做呢？最好的方式是先在端侧借助 AI 进行图像识别，然后将包含人的视频片段上传到云端，而不是先将所有视频上传到云端再进行图像处理（裁剪掉无用的视频片段），前者既可以节省流量带宽，又可以节省云侧算力，这里端侧对视频的处理也就是我们刚才说的对数据的预处理和理解。

对于 AR 来说，端智能为 AR 提供交互能力，5G 则能满足 AR 需要的网络传输能力，在这两者的加持下，具备互动性，高品质的 AR 技术会促进真实世界与虚拟环境的融合。

西瓜为什么做端智能?

上述内容纯粹就是简单介绍下端智能的前世今生，口水内容，简单看一分钟也就行。光说不练假把式，下面就简单介绍下西瓜在端智能上的探索及落地，很多同学知道我们在搞，但不知道搞了个啥，今天咱就揭开这道神秘的面纱。首先来看我们西瓜为啥要做端智能。

在后文展开之前必须得先回答一个问题：西瓜为什么要做端智能？或者说，西瓜对于端智能的定位是如何的？

• 西瓜视频作为一款服务于广大中长视频消费用户的产品，为了满足不同细分群体的需求必然要进行更精细化的产品运营策略，但之前我们的的策略往往局限于服务端策略或者实验场景下得出的策略池，整个过程中客户端更多的作为策略的接受者，被动响应且实时性不够；

• 随着西瓜视频品质化专项的不断推进，在很多场景下也取得了显著的收益，伴随而来问题就是简单易行的策略已经不再能满足我们的胃口，要想再取得收益需要更细致灵活的策略手段。

• 西瓜视频一直在致力于为用户提供更优价值的内容，而播放作为西瓜核心功能，致力于为用户打造更加智能化的播放器，创造更好的视听环境，这无疑对我们客户端播放策略上提出了更高的要求。

• 对于视频类产品而言，带宽成本不容小视，我们希望在不影响播放体验的同时，能尽量的减少无用带宽的浪费。

介于上述几个因素，我们在用传统客户端技术解决问题的同时也对端侧 AI 能力有了兴趣，并于 20 年 8 月份开始调研，最终我们确立下两大目标：策略精细化和开源节流。

在这两个目标的指导下，进一步结合西瓜的需求，我们主要聚焦在下述两个领域：

• 业务领域：充分发掘相关消费侧(播放器)和创作侧可优化决策点，降低业务成本，打造更智能化的决策体系；个别场景借助端侧 AI 能力打造更好的产品功能；

• 技术领域：尝试端侧 AI 能力和稳定性/编译优化结合，自动分析并追踪相关异常链；尝试建立端侧特征库，实现热点功能/插件调度决策。

西瓜端智能

关于西瓜为什么下手端智能，大概是说明白了。但总体该怎么下手落地呢?从表面上看无非就是将原有服务端的体系搬到客户端来做，变化的只是前后端而已，但实际上从云到端的迁移，不但涉及端云技术链路的变化，而且更加强调不同领域工程师的合作：从客户端角度出发，我们关注工程架构及交互，但从算法角度来看，更加关注的数据和模型，这两者关注点的不同就决定了在端智能落地过程会存在比较大的困难。

基本流程

首先来简单了解下端智能从云到端的几个阶段：从云到端，主要涉及算法、模型训练、模型优化、模型部署以及端侧推理预测。按照参与方来看主要涉及算法工程师和客户端工程师，按照环境则可以分为云端工程和客户端工程，如下所示：

简单概括一下流程就是：首先算法工程师针对特定场景设计算法并训练模型，然后对该模型进行优化，在降低模型体积的同时提高算法 &模型执行效率，接下来在模型部署阶段将优化过的模型转换为端侧推理引擎支持的格式并部署到移动设备上，客户端工程师针对该场景做算法移植及业务改造，并在合适的时机通过推理引擎加载模型并执行推理预测。

三座大山

上述我们用一句话概括了端智能落地的流程，但实际过程中要远比上图提到的更复杂：

如上图所示，不难发现端智能落地链路总体比较长，任何一个节点出现问题都会涉及比较长的排查路线；需要算法工程师和客户端工程师的高度协作，但由于算法和客户端两侧的技术栈差异比较大，知识领域也存在比较大的差异，因此协作成本其实蛮大：

• 客户端工程师对机器学习的算法和原理相对较少，这就意味着在很多时候客户端把这块当做黑盒，无法针对端侧设备的情况和业务逻辑给出一定的参考意见，也无法有效发现模型推理异常问题，对总体的运行结果不可预期；而如果涉及到算法移植这块，问题就更多了，鸡同鸭讲的情况也不是不存在；

• 算法工程师缺少对端侧设备的了解，端侧设备环境不如服务端环境单一，设备环境复杂度，如何针对端上设计出更高效的模型，避免侧推理影响到端侧性能指标是重中之重；算法移植到端侧是否符合预期也有待考量。

除此之外，端侧推理引擎如何兼容复杂的端侧设备，保证高可用性，实现一体化监控和模型部署等等也是端智能在落地过程要重点解决的问题。

端云一体部署

前文我们提到端智能在落地过程中的三个问题：链路长，协作成本高，推理部署复杂。来具体分析看下问题及相应的解决策略：

• 对于算法设计到模型训练，公司内的 MLX 平台提供了模型训练到服务端部署的能力，但并不支持云上模型训练到部署端上的链路，我们需要将端上和 MLX 平台进行打通能够实现模型部署及模型格式转换；

• 传统上端智能在端侧依赖算法和模型两部分数据，之前算法需要在云测设计完成后移植到端侧，存在一定的移植成本，且缺乏快速部署、更新的能力；同时算法和模型属于分离状态，在算法和模型多次迭代后，版本管理相对复杂，兼容性难以保障，如果算法和模型能够绑定动态下发，在减少协作成本的同时也可以简化链路；

• 端侧环境复杂(尤其是 Android 设备，各种配置不一，硬件环境也更为复杂)， 推理引擎至关重要。在开始落地之前，我们调研了 TensorFlow Lite、TNN、MNN 及 Paddle-Lite 以及公司内部的 ByteNN，最终我们选择 ByteNN。

为什么是 ByteNN?

1. ByteNN 作为抖音、TikTok 的统一 AI 基础引擎库，已经在很多产品接入了，不需要额外增加体积；

2. 针对 ARM 处理，Adreno/Mali GPU，Apple GPU 进行定向性能调优，支持多核并行加速，性能 OK；

3. 终端兼容性广，覆盖了全部 Android 设备及 iOS，可用性较高；

4. 支持 GPU、GPU、NPU、DSP 等处理器，有厂商加持，通用性不成问题。

阻碍在面前的三座大山已然明了，要做的事情也很清晰。对于端智能，我们和平台 Client Ai 团队的想法不谋而合，开始共同推动端智能在字节业务策略上的探索及落地。

借助 Pitaya 方案，我们可以将更多的精力放在算法设计和业务场景挖掘中。Pitaya 是啥呢？简单来说，它是将云上 MLX 环境和端侧环境打通，将算法和模型统一以算法包的形式部署到端上，并对端侧特征工程予以支持；同时端侧内部集成运行容器，并驱动推理引擎(ByteDT、ByteNN)工作的一整套方案，其基本架构大概如下：

现在整体链路简化了不少，我们可以更聚焦于业务场景的算法设计了，同时借助于高效的运行容器，可以实现算法包的快速部署，提高整体的迭代效率，端云之间的联动性更强：

西瓜视频智能预加载

西瓜视频横屏内流在交互上可以理解为是一个横屏版的抖音，是西瓜的核心消费场景，如下图所示：

作为西瓜视频的核心场景，其播放体验至关重要。为了实现较好的视频起播效果，该场景上了视频预加载策略：在当前视频起播后，预加载当前视频后的 3 个视频，每个 800K。

800K 是实验值，旨在不影响卡顿的情况下尽可能的降低成本，众所周知，预加载在显著提高播放体验的同时也会带来带宽成本上的提升。对于 800K 大家可能没有直观感受，以 720P 视频为例，假设平均码率是 1.725Mbps，那么 800K 的视频大小也就是 4 秒左右。

方便起见，我们通过一个图来展示 3*800 的流程：

不难发现，只有在首个视频的情况下才会一次性预加载三个视频，再往后就变成了增量预加载 1 个视频的操作，端上始终保留 3 个视频的预加载。

为什么是端智能的方案?

上述方案足够粗暴简单，但也存在不少局限，即带宽和播放体验平衡不够：

• 某些情况下用户不会看完 800K 的缓存视频，简单浏览标题或前几秒内容后就划到下一个，造成带宽浪费；

• 或者当用户想要认真观看视频时，有可能因为没有足够的缓存，容易导致起播失败或者卡顿，进而影响用户体验。

此外上线预加载方案的时候，我们的数据分析师也提到：减少预加载大小虽然可以降低成本，但是卡顿劣化严重，短期采用 3*800K 的固定方案，长期推动动态调整预加载大小方案上线。

除了传统对预加载任务管理机制的优化外，我们开始重新思考如何衡量预加载的有效任务率？

最理想的情况是预加载的大小和播放大小一致，这样视频预加载的效率就是 100%。如果我们预加载了 1000K，但用户只看了 500K，那预加载的效率就是 50%，这浪费的 500K 可都是金灿灿的 💰；最糟糕的情况是我们预加载 1000K，但用户压根没看，不好意思，此时预加载的效率就是鸭蛋了，我们白白浪费了大把的钞票。现在我们来具体定义下用来评估预加载效率的公式：

不难发现，最理想的预加载策略就是使预加载大小和播放大小尽量的匹配，用户在起播阶段会看多少，我们就预加载多少，这样既能提高播放体验，又能减少带宽浪费。

那如何来做呢？我们希望基于端侧 AI 的能力，对用户操作行为进行实时分析，进而实现调整预加载策略，在提高用户播放体验的同时，避免带宽浪费。

优化方案

如上述公式所示，提高视频预加载效率的关键就是预测用户播放时长，使视频预加载的大小和视频播放大小尽可能的接近。但预估每个视频用户会看多久是一件很难的事情，会有很多个因素，比如用户对视频的感兴趣程度，心理状态等等。

抛开这些复杂的因素和变量，我们来重新思考视频预加载的行为和用户的浏览行为之间的相关性。我们假设存在两种典型行为的用户：

• 快速滑动，短暂浏览: 用户处于蜻蜓点水状态，后续每个视频只会简单瞄一眼，主动切换视频的频率较高；

• 慢速滑动，仔细观看: 用户倾向于观看每个视频，主动切换视频的频率较低。

如果我们在端上能够根据用户的浏览行为，通过模型判断出用户在接下来的浏览中是倾向于那种行为的话，那是不是可帮助我们进一步来优化视频预加载策略了呢？此时预加载的流程就变成了如下所示：

除了通过端智能的方案提高预加载的效率，实现更精准的预加载调度外，在端上也有配套的业务调整和优化方案，比如聚合推理参数，模型触发时机调整，预加载任务管理完善等手段，两者互为补充。其中涉及到端智能的流程如下所示：

特征工程

我们通过线上用户埋点数据，提取横屏内流相关埋点数据进行标记并进行相关性分析，多次迭代后最终筛选出与用户浏览行为的相关特征。此外，借助 Pitaya 端上特征的能力，可以方便的从不同的数据源中获取实时特征，并将其转化成模型输入的数据。

算法选型

机器学习的算法很多，从传统的的决策树、随机森林到深度神经网络，都可以用来实现端侧 AI 的能力。但需要根据端侧设备的情况，在能满足场景效果和需求的前提下，重点考虑模型的体积和性能：模型体积越小越好，性能越高越好。比如在该场景下，用 DT 和 NN 都可以对用户模式进行分类，但要综合评估模型体积，性能和效果，最后决定采用那种算法。

推理预测

首先来看决策的时机，每滑到一个视频并且在该视频(非首刷视频)起播后触发算法包，等待决策结果并调度后续预加载任务。简要流程如下所示：

在触发推理时，主要依赖两部分数据：一种是已经观看过视频的数据，另外则是后续未观看视频的详情数据。前者是 Pitaya 主动通过埋点日志获取，后者则是需要业务方聚合后主动透传。同时端上也需要考虑容错机制，以便在算法包异常和推理失败的情况及时回滚策略。

预加载任务调度

决策结果给出后，我们会根据最近两次推理结果进行调度，主要是实现对预加载任务数量的调整(保留有效任务)及每个预加载视频大小的调整(增量调整)。此处涉及业务细节较多，就不做过多解释了。

端侧性能监控

除了端侧常规的监控外(性能、业务指标)，还涉及模型指标的监控，比如执行成功率、推理耗时、PV/UV，当然也包括 accuracy 等模型的效果指标。

问题 &挑战

西瓜从去年 12 月份开始落地该场景，到明确拿到收益并全量上线，最终大概历 1.5 个双月，加上春节假期得有 2 个双月了，这是为啥呢?从开始的实验大规模负向到正向收益，我们遇到了那些问题？

推理耗时

前期多次实验中(v1.0~v3.0)我们发现智能预加载组比线上策略在首帧耗时等指标上有劣化，比如首帧耗时上升 2ms 等。在通过各种技术手段及数据分析后，我们最终定位出端上聚合推理参数、推理耗时等因素会间接影响大盘指标。为此，我们在端上提出了多种优化手段，如步长推理、异步调度、首推预热、模型优化等方案，最终打平了相关指标，并确定显著收益。

带宽成本

带宽成本核算受多个因素影响，容易存在偏差，尤其是在像西瓜视频这么复杂的业务场景下，如何准确衡量该方案带来的带宽收益非常复杂。我们在播放器及视频架构团队多位同学的支援下，最终明确实验组（95 分位）带宽成本比线上组平均降低 1.11%。

峰值模型

很多情况下，用户的习惯是呈现阶段性，为了我们也定向提出峰值模型，用于在用户使用的高/低峰时间段内做出更细致化的决策。（限于业务相关性太大，具体就不做解释了。有想了解的同学可以加入字节一起做同事！）

实验收益

通过一系列的周期实验和策略验证，最终明确了智能预加载的收益:

• 总带宽 -1.11%，预加载带宽 -10%；

• 中视频播放失败率 -3.372%，未起播失败率 -3.892%，卡顿率 -2.031%，百秒卡顿次数 -1.536%，卡顿渗透率 -0.541%。

除此之外，实验组其它指标也有正向收益，但限于不够显著，我们在此就不一一说明了。

现状 &总结

西瓜端智能现状

当前智能预加载在 Android 端已经全量上线，同时 iOS 端也在接入过程中。对于西瓜视频而言，智能预加载只是个起点，我们正在探索更多场景的可能性，为用户提供更智能化的播放体验。

无论是云智能还是端智能，最终带给我们的是解决问题的新思路，坦率的说我也不知道端智能对未来意味着什么，但当下确定的是我们可以更好的将它和业务场景结合在一起，寻求更好业务成果。

端智能也不是银弹：不是说我们用了它就完事大吉，就一定可以拿到很好的结果。要想真正的发挥业务价值，更好的服务用户，需要我们更多的思考，将端智能放在该放的地方。

新思路，新尝试

对于很多客户端工程师而言，可能会存在疑问，我们应该如何面对端智能，或者说它和我们之前解决问题的方式有什么不同？端智能不是一个从 0 到 1 的新生物，它只是云智能发展到现在的自然延伸而已，其背后的体系还是机器学习那一套，对于客户端而言，它提供了一种全新的思考方式：从规则驱动到数据驱动，再到模型。我们可以借助它在适当的业务场景寻求结合点，最终获得更好的成果。

那对于客户端工程师而言，该如何切到这个领域呢，或者说，如果我们想了解端智能可以做点什么?

了解基础

正如我们上面很多次提到的一样，端智能只是云智能发展的自然延伸，其背后仍然基本的机器学习，对于大多数的客户端工程师而言，我们的目标不是成为机器学习领域的专家，可以不去深入研究各种算法模型，但系统的学习下理论只是还是很有必要的：

• 了解人工智能发展的过程，知道为什么当前深度学习成为主流方向；

• 学习曾经流行的一些经典算法及能够解决的问题领域，你会发现之前一些问题的思考方式在当前深度学习中仍然是贯通的；

• 了解常见的神经网络架构，知道不同网络层(比如 CNN 中的卷积层/池化层等)的作用，整体又是怎么组织起来的。

模型移植与实践

系统性的知识基本上可以通过阅读该领域中的经典书籍而获得。除此之外还要多动动手，我们可以先找几个示例，一步一步把训练好的模型通过量化处理后移植到客户端上去跑跑，也可以尝试在开源项目的基础上去修改算法 &模型，比如尝试手写数字识别，进行人脸检测等，当然也可以尝试下量化交易，用自己的做的模型预测股票价格(当然，赔了别找我 😁)。

性能优化

端侧设备，尤其以手机为例更注重交互，且受硬件限制较多，比如电量，存储空间，算力等，这就意味着我们的算法模型必须要具有很高的执行效率，同时模型体积不益过大，对应而来的就是性能优化在端智能领域同样非常重要。

对于大部分客户端工程师而言，除了传统的基于业务场景的优化方案之外，还可能涉及到推理优化和部署。对于推理优化，除涉及到模型、框架外，也有需要根据硬件进行优化的情况，比如 Neon/SSE/AVX 指令集优化、高通(Qualcomm GSP/GPU)、华为(Huawei NPU)等硬件加速技术。

拥抱 AIOT

无论是边缘计算还是端智能，其载体不仅仅是手机，还包含各种各样的嵌入式设备。比如像安防领域的指纹锁、监控摄像头、无人机等等。对于我们而言，可以拿来练手的设备也很多，可以是树莓派，也可以是搭载 TPU 芯片 Coral 开发版以及英特尔 ®Movidius™ 神经计算棒等等，利用他们可以做出很多好玩的东西。

本文转载自：字节跳动技术团队（ID：toutiaotechblog）

原文链接：你竟然是这样的端智能?