机器之心分析师网络
作者：仵冀颖
编辑：H4O
本文中，作者基于WWW’19论文提供的线索，详细解读了在浏览器中实现深度学习的可能性、可行性和性能现状。具体而言，作者重点分析了7个最近出现的基于JavaScript的DL框架，并对比了具体框架支持哪些DL任务。
深度学习（DeepLearning，DL）是一类利用多层非线性处理单元（称为神经元）进行特征提取和转换的机器学习算法。每个连续层使用前一层的输出作为输入。近十年来，深度学习技术的进步极大地促进了人工智能的发展。大量的人工智能应用，如图像处理、目标跟踪、语音识别和自然语言处理，都对采用DL提出了迫切的要求。因此，各种DL框架（Frameworks）和库（Libraries），如TensorFlow、Caffe、CNTK等，被提出并应用于实践。目前，这些应用程序可以在诸如Windows、Linux、MacOS/iOS和Android等异构开发环境上运行，此外，可以使用各种命令式编程语言开发，例如Windows上的C/C++、iOS和MacOS上的Objective-C，以及Android上的Java。不过，受限于DL框架和库的特点，例如训练数据量大、网络结构复杂、网络层级多、参数多等，通过本机程序调用运行DL的AI算法或模型的运算量非常大。
最近，关于DL的一种应用趋势是应用程序直接在客户端中执行DL任务，以实现更好的隐私保护和获得及时的响应。其中，在Web浏览器中实现DL，成为了人工智能社区关于客户端DL支持的重要研究目标。浏览器中的DL是用JavaScript实现的，依靠浏览器引擎来执行。基于DL的Web应用程序可以部署在所有平台的浏览器中，而不管底层硬件设备类型（PC、智能手机和可穿戴设备）和操作系统（Windows、Mac、iOS和Android）。这就使得在浏览器中实现DL具有非常良好的适配性能和普适性能，不会对客户端的选择有诸多限制。另外，HTML5、CSS3，特别是JavaScript语言的进步，使得支持创建DL驱动的Web应用程序具有良好的性能。得益于WebGL的发展，目前主流浏览器如GoogleChrome、MozillaFireFox、Safari等，都可以更好地利用显卡来加速DL任务。
不过，是不是我们现在就可以随心所欲的在浏览器中运行DL的模型或算法了？我们已经成功迈入在浏览器中实现深度学习的时代了么？尽管上面介绍的内容似乎意味着使在浏览器中运行DL任务成为可能，但是目前对于可以执行哪些DL任务以及DL在浏览器中的工作效果却缺少深入的研究和分析。更重要的是，考虑到Web应用程序与本机应用程序性能的长期争论，开发基于DL的Web应用程序时也存在同样的问题。在这篇文章中，我们以北京大学研究人员发表在WWW’19（TheWorldWideWebConference）中的文章《MovingDeepLearningintoWebBrowser:HowFarCanWeGo?》[1]作为参考主线，具体分析和探讨在浏览器中实现深度学习的问题。
1、浏览器中支持的深度学习功能
在这一章节中，我们以文献[1]为参考主线，重点探讨现有的框架提供了哪些特性来支持在浏览器中实现各种DL任务。我们首先介绍了进行分析的几个框架，然后从两个方面比较了这些框架的特性：提供的功能和开发人员的支持。对于所提供的功能，主要检查每个框架是否支持DL应用程序开发中常用的一些基本功能。而对于开发人员支持，主要讨论一些可能影响开发和部署DL应用程序效率的因素。
1.1选择的框架
为了选择最新的浏览器支持的DL框架，作者在GitHub上搜索关键字“deeplearningframework”，并用JavaScript语言过滤结果。然后选择了GitHub上星数超过的前7个框架[1]。对每个框架的具体介绍如下：
TensorFlow.js[2]：年3月由Google发布，是一个inbrowser机器学习库，支持使用JavaScript在浏览器中定义、训练和运行模型。TensorFlow.js由WebGL提供支持，并提供用于定义模型的高级API。TensorFlow.js支持所有Keras层（包括Dense、CNN、LSTM等）。因此，很容易将原生TensorFlow和Keras预先训练的模型导入到浏览器中并使用Tensorflow.js。
ConvNetJS[3]：是一个Javascript库，最初由斯坦福大学的AndrejKarpathy编写。ConvNetJS目前支持用于分类和回归的常用神经网络模型和代价函数。此外，它还支持卷积网络和强化学习。然而遗憾的是，尽管ConvNetJS可能是在TensorFlow.js之前最著名的框架，但其在年11月后已经不再维护了。
Keras.js[4]：抽象出许多框架作为后端支撑，包括TensorFlow、CNTK等。它支持导入Keras预先训练的模型进行推理。在GPU模式下，Keras.js的计算由WebGL执行。然而，这个项目也已经不再活跃。
WebDNN[5]：由东京大学发布的WebDNN号称是浏览器中最快的DNN执行框架。它只支持推理（训练）任务。该框架支持4个执行后端：WebGPU、WebGL、WebAssembly和FallbackpureJavaScript实现。WebDNN通过压缩模型数据来优化DNN模型，以加快执行速度。
brain.js[6]：是一个用于神经网络的JavaScript库，它取代了不推荐使用的“brain”库。它为训练任务提供DNN、RNN、LSTM和GRU。该库支持将训练好的DL模型的状态用JSON序列化和加载。
synaptic[7]：这是一个不依赖于JavaScript架构的神经网络库，基本上支持任何类型的一阶甚至二阶RNN。该库还包括一些内置的DL架构，包括多层感知器、LSTM、液态机（Liquidstatemachines）和Hopfield网络。
Mind[8]：这是一个灵活的神经网络库。核心框架只有行代码，它使用矩阵实现来处理训练数据。它支持自定义网络拓扑和插件，以导入mind社区创建的预训练模型。然而，这个项目也已经不再活跃。
1.2所提供的功能
训练支持
大多数框架都支持在浏览器中完成训练和推理任务。然而，Keras.js和WebDNN不支持在浏览器中训练DL模型，它们只支持加载预训练的模型来执行推理任务。
支持的网络类型
有些框架并不是针对通用DL任务的，所以它们支持的网络类型有所不同。具体来说，TensorFlow.js、Keras.js和WebDNN支持三种网络类型：DNN、CNN和RNN。但ConvNetJS主要支持CNN任务，不支持RNN。brain.js和synaptic主要支持RNN任务，不支持CNN网络中使用的卷积和池化操作。Mind只支持基本的DNN。
支持的层类型
所有框架都支持以层（Layer）为单位构建神经网络。TensorFlow.js的层API支持49种不同的层，包括密集层、卷积层、池化层、RNN、归一化等。其他框架支持的层类型较少，这也与它们所支持的网络类型有关。需要注意的是，TensorFlow.js的核心API是以类似于原生TensorFlow的方式实现的，它结合了各种操作来构建计算图。synaptic是一个架构无关的框架，支持构建任何类型的一阶甚至二阶RNN网络。
支持的激活/优化类型
TensorFlow.js为开发者提供了关于激活/优化器的最多种类的选择。对于激活函数，其他框架只支持基本的sigmoid或ReLU。对于优化器，其他框架主要支持基本的随机梯度下降（SGD）。
支持GPU加速
TensorFlow.js是唯一支持GPU加速训练任务的框架。TensorFlow.js、Keras.js和WebDNN支持使用GPU来加速推理任务。WebDNN还支持更先进的技术—WebGPU，但WebGPU只被Safari的技术预览版所支持。
1.3开发者支持
文档。TensorFlow.js、ConvNetJS、WebDNN和synaptic提供的文档已经完成。Keras.js的文档并不完整，brain.js只有几篇教程。
演示。所有的框架都为开发者提供了入门的demo。TensorFlow.js提供了最丰富的demo，涵盖了广泛的用例。
从其他框架导入模型。TensorFlow.js、Keras.js和WebDNN支持在Python中从原生DL框架中导入模型，并且它们都提供了用于转换模型的Python脚本。TensorFlow.js支持由TensorFlow和Keras训练的模型。Keras.js支持Keras模型。WebDNN支持从TensorFlow、Keras、Caffe和Pytorch导入模型。在支持使用其他DL框架的预训练模型的情况下，可以大大减少开发工作量。
API保存/加载模型。所有支持浏览器中训练任务的框架都有保存模型的API。所有框架都有用于加载模型的API。
支持服务器端（Node.js）。所有框架都支持Node.js。这样的功能使得浏览器内部的计算可以卸载到远程服务器上。
库大小。表1中列出了需要加载到浏览器中的库文件的大小。ConvNetJS是最小的，只有33KB。TensorFlow.js和brain.js的文件大小非常大，分别为KB和KB。小型库更适合在浏览器中加载应用，因为所有的文件都要按需下载。
表1.基于JavaScript的框架在浏览器中支持深度学习的情况
2、浏览器中深度学习框架的性能
本节重点讨论现有框架的复杂度和后端处理器（CPU或GPU）对浏览器运行训练和推理任务时性能的影响。
2.1实验准备
如前所述，不同框架支持的网络类型是不一样的。在实验中采用最基本的全连接神经网络作为模型。对于运行DL任务的数据集，使用经典的MNIST手写数字识别数据库。待训练的模型有个输入节点和10个输出节点。为了研究模型复杂度对性能的影响，对模型进行了不同的配置设置。参数包括：1）神经网络的隐藏层数（深度），范围在[1，2，4，8]；2）每个隐藏层的神经元数（宽度），范围在[64，，]。深度和宽度的范围是基于“客户端DL模型应该是小尺寸，以便能够在客户端上运行”的假设而设定的。在训练过程中，批处理大小始终设置为64。
为了研究CPU和GPU的性能差异，使用一台HaseeT97E笔记本电脑，它的独立显卡是NvidiaMax-Q（配备8GBGPU内存）。CPU为Inteli7-H，其中包含IntelHDGraphics，使得实验中也能够使用集成显卡来验证性能。在下文中，用nGPU和iGPU分别表示独立Nvidia显卡和集成Intel显卡的GPU。所有的实验都在Ubuntu18.04.01LTS（64位）上的Chrome浏览器（版本：71.0..10dev64位）上运行，且使用各个框架最新发布的版本。
对于每个DL任务，实验中构建了一个网页，可以通过URL中的参数来改变DL模型的配置。作者在Chrome浏览器上运行每个DL任务，并记录完成任务的时间。由于每个实验通常需要运行不同配置下的几十个任务，作者开发了一个Chrome浏览器扩展版本：可以迭代运行所有页面，并在一个任务完成之后更改配置。该扩展版本的浏览器还能够监控网页的系统资源使用情况。
2.2训练性能
作者选取了支持在浏览器中进行训练的brain.js、ConvNetJS、synaptic和TensorFlow.js四个JavaScript框架进行实验，比较它们完成训练任务的性能。除了Tensor-Flow.js能通过WebGL使用GPU外，其他框架都是基于CPU训练模型的。作者使用每个框架对定义的模型进行训练，获得训练一批模型的平均时间。图1给出了不同模型复杂度的结果。由于synaptic的训练时间大约是其他框架的几十倍到几百倍，为了更好的展示，作者在图中省略了synaptic的结果，但实际上它的结果与其他框架是相似的。
一般来说，训练时间会随着网络规模的增大而增加，因为对于较大的网络，需要更多的计算量来完成训练过程。比较不同框架在CPU后台的训练时间，我们可以看到ConvNetJS是所有框架中所有网络配置下速度最快的。作者分析，可能的原因是ConvNetJS的设计比较简单，这也可以从它的库文件大小反映出来。在速度方面Brain.js紧随其后，与ConvNetJS的性能差距约为2倍，而Tensorflow.js与ConvNetJS的性能差距约为两到三倍。在对比ConvNetJS与TensorFlow.js的训练时间时，作者发现当深度和宽度增加时，性能差距会逐渐缩小，这说明与ConvNetJS相比Tensor-Flow.js的计算之外的开销相对较大。此外，随着网络宽度的增加而导致的性能差距要比随着网络深度增加而导致的性能差距要大，这意味着TensorFlow.js比ConvNetJS更适合于处理大规模矩阵计算。
CPU后端的训练时间随着网络规模的增大而变长，但GPU（iGPU和nGPU）后端的训练结果却不尽相同。对于计算能力较弱的iGPU和能够满足较大规模矩阵计算的nGPU，训练时间并没有显著增加。但在从4个隐层、每层个神经元到8个隐层、每层个神经元的过程中，iGPU的训练时间明显增加。作者分析，其原因可能是在本实验设定的网络规模下，训练过程没有达到GPU的能力瓶颈。虽然nGPU的矩阵计算能力优于iGPU，但nGPU的训练时间比iGPU长。作者分析这种结果可能是由于调用WebGL访问GPU的时间开销过大造成的，实际上单纯GPU的实时计算时间要短得多。
图1.在不同模型复杂度下，一个批次的平均训练时间（ms），Y轴为对数刻度。
表2中给出了在训练过程中每个框架的CPU利用率的统计数据。%是CPU利用率的上限。由于JavaScript引擎是单线程的，因此不能使用多核处理器的功能，它只能最大限度地提高单核的使用率。之所以CPU利用率超过%，是因为其他内核和用户空间组件偶尔会在其他线程中同时运行。在CPU后端，TensorFlow.js有时无法最大化单个核心的利用率，其平均CPU利用率仅为82.1%。同时，作者发现在GPU（iGPU和nGPU）后端运行训练任务时，由于大部分计算都在GPU上，所以CPU的利用率并不高。iGPU上的训练比nGPU上训练的CPU利用率要高5-7%左右。
表2.训练过程的CPU利用率（%）
2.3推理性能
作者选择了6个JavaScript框架来比较它们运行推理任务的性能。TensorFlow.js、Keras.js和WebDNN支持使用GPU进行加速，但brain.js、ConvNetJS和synaptic只支持使用CPU进行推理。在模型使用方面，brain.js、ConvNetJS、synaptic和TensorFlow.js支持保存自己训练的模型，而Keras.js和WebDNN只支持从其他深度学习框架导入预训练的模型。因此，对于brain.js、ConvNetJS、synaptic和TensorFlow.js直接使用框架本身保存的模型。对于Keras.js和WebDNN，则需要使用Keras训练的模型，然后将模型转换为相应的格式。理论上，训练得到的DL模型的参数值应该是不同的，但绝对值不会影响推理时间。所以只需要给不同框架的所有模型分配相同的参数值即可。推理任务包括加载一个预先训练好的模型，然后给定一个样本输入，模型输出结果。此外，在GPU后端，有一个预热过程，推理的第一个样本通常用于激活GPU处理器。因此，作者将推理过程分解为模型加载、预热和推理三个阶段，并研究性能细节。
由于篇幅所限，作者在下面的分析中省略了模型深度为8的结果，因为随着深度的增加，趋势是相似的。另外，由于synaptic的模型加载时间和推理时间仍然比其他框架长很多，为了更好的展示，作者没有在图中给出synaptic的结果。
首先研究不同框架使用的模型文件的大小。由于通常需要从远程服务器下载用于推理的模型，模型文件的大小越小意味着下载时间越短。表3给出了所有推理实验中使用的模型文件的大小。ConvNetJS和brain.js使用类似的JSON编码，所以它们的模型文件大小几乎相同。synaptic的模型文件也使用JSON编码，但其大小是所有框架中最大的。由于TensorFlow.js、Keras.js和WebDNN使用的模型文件都是由Keras模型转换而来，所以它们的模型文件大小是一样的，作者只在表3中显示TensorFlow.js。由于从Keras转换而来的模型被压缩后保存为二进制文件，所以大小可以大大缩小，只有JSON中模型文件的1/7左右。
然后，我们比较加载不同框架的模型所花费的时间，如图2所示。对于CPU后端，同一框架的不同模型的加载时间与表3中描述的模型文件的大小成正比。但是，不同框架的模型加载时间有显著差异。ConvNetJS是最快的。Brain.js、TensorFlow.js和Keras.js的模型加载时间在幅度上是一致的。有趣的是，当宽度增加时，ConvNetJS、brain.js和synaptic的加载时间增加特别明显。这个结果是由它们选择使用JSON来编码模型所造成的。在所有框架中，synaptic的模型加载时间最慢，比ConvNetJS长多倍到多倍。无论模型大小，TensorFlow.js的模型加载时间几乎没有变化。
在不同的模型复杂度下，GPU（iGPU和nGPU）后端的加载时间变化不大。但是，不同框架之间的差异还是很大的。TensorFlow.js是最快的。与在CPU后端加载模型相比，Keras.js加载大型模型的速度较快，但WebDNN的加载时间较长。此外，可以看到iGPU和nGPU的模型加载时间没有区别。
表3.模型文件的大小（MB）
接下来，我们检查GPU（iGPU和nGPU）后端预热时间的差异。如图3所示，Keras.js还是遥遥领先，可以在3毫秒内完成所有任务的预热。Tensorflow.js第二，WebDNN最差。整体而言，iGPU后端的预热时间比nGPU要短。
图3.不同模型复杂度下GPU上的模型预热时间（ms），y轴为对数刻度。
图4给出了对一个样本进行推理的平均时间。几乎所有的推理任务都能在1.5ms内完成（除了synaptic，其中时间最短的为6.68ms）。在作者设定的模型大小范围内，GPU强大的计算能力并没有造成任何影响。在所有的模型大小中，ConvNetJS占据了所有的第一位，其次是CPU后台的WebDNN。
图4.在不同的模型复杂度下，一个样本的平均推理时间(ms)。
WebDNN在GPU（nGPU和iGPU）后端的推理时间比CPU后端的推理时间长。至于TensorFlow.js，在CPU后端运行对于较小模型的推理速度更快，而GPU后端对于较大模型的推理速度更快。Keras.js在CPU和GPU后端的推理时间基本一致。我们可以观察到，对于CPU后端的所有框架，当模型变得复杂时，推理时间会增加。特别是当宽度增加时，时间会急剧增加（随着模型宽度增加一倍，时间增加约2倍）。训练任务情况类似。这样的结果也反映出这些框架在CPU后端的前向传播过程中没有对大规模矩阵运算进行优化。GPU后端的TensorFlow.js和WebDNN并没有出现这个问题，但后端为GPU的Keras.js仍然存在这个问题。
2.4其它收获
根据以上结果我们可以看到，在浏览器能够胜任的小规模全连接神经网络中，ConvNetJS在训练和推理方面的表现都是最好的。不过，由于ConvNetJS已经不再维护，功能较少，开发者可能还是需要寻找替代品。Tensorflow.js是唯一可以利用GPU（nGPU和iGPU）加速训练过程的框架。它功能丰富，性能与ConvNetJS相当。所以TensorFlow.js对于训练和推理都是一个不错的选择。作者不建议在小规模的模型上使用GPU作为后端，因为GPU计算能力的优势并没有得到充分利用。
最后，为什么ConvNetJS在这些框架中的所有任务都有最好的性能。对于流程逻辑相同的同一模型，性能差异很可能由不同的实现细节来解释。为此，作者在完成相同训练任务时比较了ConvNetJS和TensorFlow.js的函数调用堆栈（FunctionCallStack）。令人惊讶的是，ConvNetJS的调用堆栈深度只有3，而TensorFlow.js是48。这样的结果表明，不同框架之间性能差异的一个可能原因是深度调用堆栈，这会消耗大量的计算资源。
3、浏览器DL框架与原生DL框架的比较
我们在上文已经分析了目前主要的浏览器DL框架结构、特点，也通过实验证明了不同框架的效果。那么，在浏览器中运行DL和原生平台上运行DL的性能差距有多大？作者比较了TensorFlow.js和Python中的原生TensorFlow的性能，两者都是由Google发布和维护的，并且有类似的API，因此所比较的结果是足够公平的。
3.1基于预训练模型的推理
作者使用Keras官方提供的预训练模型来衡量TensorFlow.js和原生TensorFlow在这些经典模型上完成推理任务时的性能。
3.1.1TensorFlow.js的局限性和浏览器约束
Keras官方提供了11个预训练模型。虽然在原生TensorFlow上运行这些模型时是一切正常的，但当作者在浏览器中使用TensorFlow.js运行它们时却遇到了一系列错误。作者认为，这些错误是由于TensorFlow.js本身的限制以及浏览器施加的限制所造成的。例如，对于NasNetLarge模型，浏览器会抛出以下错误信息“truncatedNormalisnotavalidDistribution。对于ResNetV3模型，浏览器会抛出错误信息Unknownlayer:Lambda。出现这两个错误的原因是TensorFlow.js仍在开发中，到目前为止只提供了对有限的转换模型的支持。许多用户定义的操作算子TensorFlow.js是不支持的，例如，TensorFlow.js不支持使用RNN中控制流操作算子的模型。当尝试使用VGG16或VGG19时，浏览器会抛出GLOUTOFMEMORY的错误信息，这意味着GPU内存溢出。VGG16模式适用于超过1GB的GPU内存，不过实验中使用笔记本的GPU内存是8GB（NvidiaMax-Q），所以应该不是由内存所导致的问题。作者分析，这样的错误是由于浏览器的限制造成的。
表4.部分Keras预训练模型
3.1.2结论
图5给出了每个模型的推理时间。可以看出，TensorFlow.js在nGPU上的推理时间与原生TensorFlow的相当（慢1倍-2倍）。iGPU后端的TensorFlow.js的性能比CPU后端的原生TensorFlow还要好。作者分析，考虑到集成显卡和CPU的计算能力，这一结果并不奇怪。然而，由于原生DL框架不支持集成显卡加速，通过浏览器执行的DL框架可以在集成显卡的应用中获益良多，毕竟，现在的设备中集成显卡已经是非常常见的了。
在客户端DL的实时性要求下，如果用户想要达到10FPS（每秒帧数）的体验，就需要考虑使用更强大的独立显卡。而通过iGPU加速的移动网络模型也能满足要求。如果要求是达到1FPS，iGPU也完全可以满足。但如果只能使用CPU，那么在浏览器中运行这些很常见的模型看起来就太过于沉重了。
图5.预训练的Keras模型的推理时间，y轴为对数刻度。
3.2决策树分析
最后，为了深入探索不同因素是如何影响DL在浏览器和原生框架上的性能差距的，作者建立了一个基于决策树的预测模型，具体研究各种因素的重要性。
3.2.1实验设置
作者考虑4个影响DL在浏览器和原生平台上性能差距的因素，如表5所示，包括后端（CPU或GPU）、任务类型（训练或推理）以及模型的深度和宽度。在DNN和RNN模型中，宽度是指每层神经元的数目。在CNN模型中，宽度是指卷积层中使用的核数。对于DNN、CNN和RNN，作者从Tensorflow.js官方样本示例中选取模型。DNN和CNN模型用于识别MNIST数据集上的手写数字，RNN模型用于从尼采的著作中生成文本。根据Tensorflow.js官方样本的数值集合确定深度和宽度的范围。
表5.造成性能差距的主要因素
在本文实验中，作者使用不同配置的TensorFlow.js和原生TensorFlow运行DNN、CNN和RNN模型。作者将每个配置的执行时间衡量为两个平台上训练任务的每批平均时间和推理任务的每个样本平均时间。作者使用TensorFlow.js上的执行时间与原生TensorFlow上的执行时间之比来量化性能差距。
3.2.2方法
使用sklearn运行决策树算法来预测TensorFlow.js和原生TensorFlow之间的执行时间比。使用决策树描述贡献因素的相对重要性。直观地讲，靠近决策树根部的因素比靠近叶子的因素对时间比的影响更大，这是因为决策树是根据熵-信息增益标准（theEntropy-InformationGaincriterion）选择对节点进行分割的。
作者首先为所有因素生成一棵完全生长的、未经修剪的决策树。这样一来，每个叶子只包含一个配置。然后，将树的深度设置为因子的数量，以防止在一条路径上多次使用一个因子。图6显示了DNN、CNN和RNN的决策树。
图6.使用决策树来分析TensorFlow.js与原生TensorFlow在DNN、CNN和RNN模型上的时间比。
3.2.3结果
作者使用决策树算法来预测的总的结论是：在几乎所有的配置中，TensorFlow.js的执行时间都比原生TensorFlow长。
首先，后端是造成不同的模型、平台性能差距的最重要因素。由图6中的实验结果可以看出，总的来说CPU后端的执行时间比GPU后端要长得多。例如，当深度超过3、宽度超过的DNN模型运行在GPU后端而不是CPU后端时，训练任务的比率从44.7下降到4.4。最极端的例子发生在CNN上，在CPU后端，比率范围从低于5到超过（当深度小于7.5，宽度超过时）。但是，当在GPU后端执行深度超过12、宽度超过的推理任务时，TensorFlow.js执行速度与原生TensorFlow一样快。这是因为当模型足够大时，CNN能够有效利用GPU强大的计算能力。
第二个重要因素是三个模型的任务类型。执行训练任务的比率较高，而推理任务的表现差距较小。例如，对于CPU后端的DNN模型，训练任务TensorFlow.js平均比原生TensorFlow慢33.9倍，推理任务TensorFlow.js执行速度比原生TensorFlow平均慢5.8倍。
最后，DNN和RNN的决策树都表明，深度和宽度的重要性取决于任务在哪个后端执行。在CPU后端，宽度的重要性大于深度的重要性，而深度在GPU后端扮演更重要的角色。然而，在CNN的情况下，对于训练任务来说，宽度比深度对性能差距的影响更大。表6总结了上述实验的研究结果。
表6.浏览器中DL的主要影响因素
4.示例
4.1TensorFlow.js[2]
TensorFlow.js是一个使用JavaScript进行机器学习开发的库，TensorFlow.js的中文教程网址如下：