他的最新文章
他的热门文章
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)linux怎样安装xx-net_百度知道
linux怎样安装xx-net
我有更好的答案
集成GoAgent, 方便新手4.方便易用的细节、细节提示而且支持，省事省力2.内置了公共 appid，傻瓜易用3，项目也关闭了，真是一件忧伤的事情，喜欢GoAgent项目的网友可以考虑使用XX-Net。XX-Net1，人性化交互.Web界面、GoGoTest等扫描IPGoagent在Git上的项目团队已经不再提供更新了：Window（xp & 7 & 8 & 10）、Linux以及Mac以下只介绍如何在ubuntu（14
采纳率：89%
来自团队：
为您推荐：
其他类似问题
您可能关注的内容
换一换
回答问题，赢新手礼包
个人、企业类
违法有害信息,请在下方选择后提交
色情、暴力
我们会通过消息、邮箱等方式尽快将举报结果通知您。MXNet设计笔记之：深度学习的编程模式比较
发表于 08:27|
来源mxnet|
摘要：不同的深度学习库风格各异。那么这些函数库的风格在系统优化和用户体验方面又有哪些优势和缺陷呢？本文旨在于比较它们在编程模式方面的差异，讨论这些模式的基本优劣势，以及可以学到的经验。
【编者按】继xgboost,cxxnet,minerva之后，在9月29日发布了新的Project: ，MXNet是cxxnet的进化，在设计上经过成熟的思考，文档也很清楚。尤为难得的是，MXNet开发团队把设计笔记也做了分享。笔记的思想不局限于MXNet，也不局限于深度学习，无论对深度学习初学入门还是对高阶提升，都具有很好的参考价值。本文是第一篇设计笔记的译文，深入讨论了不同深度学习库的接口对深度学习编程的性能和灵活性产生的影响。市面上流行着各式各样的深度学习库，它们风格各异。那么这些函数库的风格在系统优化和用户体验方面又有哪些优势和缺陷呢？本文旨在于比较它们在编程模式方面的差异，讨论这些模式的基本优劣势，以及我们从中可以学到什么经验。我们主要关注编程模式本身，而不是其具体实现。因此，本文并不是一篇关于深度学习库相互比较的文章。相反，我们根据它们所提供的接口，将这些函数库分为几大类，然后讨论各类形式的接口将会对深度学习编程的性能和灵活性产生什么影响。本文的讨论可能不只针对于深度学习，但我们会采用深度学习的例子来分析和优化。符号式编程&vs&命令式编程在这一节，我们先来比较符号式程序（symbolic&style&programs）和命令式程序（imperative&style&programs）两种形式。如果你是一名Python或者C++程序员，那你应该很熟悉命令式程序了。命令式程序按照我们的命令来执行运算过程。大多数Python代码都属于命令式，例如下面这段numpy的计算。import numpy as np
a = np.ones(10)
b = np.ones(10) * 2
d = c + 1当程序执行到&c&=&b&*&a&这一行时，机器确实做了一次乘法运算。符号式程序略有不同。下面这段代码属于符号式程序，它同样能够计算得到d的值。A = Variable('A')
B = Variable('B')
D = C + Constant(1)
# compiles the function
f = compile(D)
d = f(A=np.ones(10), B=np.ones(10)*2)符号式程序的不同之处在于，当执行&C&=&B&*&A&这一行代码时，程序并没有产生真正的计算，而是生成了一张计算图/符号图（computation&graph/symbolic&graph）来描述整个计算过程。下图就是计算得到D的计算图。大多数符号式程序都会显式地或是隐式地包含编译步骤。这一步将计算图转换为能被调用的函数。在代码的最后一行才真正地进行了运算。符号式程序的最大特点就是清晰地将定义运算图的步骤与编译运算的步骤分割开来。采用命令式编程的深度学习库包括Torch，Chainer，&Minerva。采用符号式编程的库有Theano和CGT。一些使用配置文件的库，例如cxxnet和Caffe，也都被视为是符号式编程。因为配置文件的内容定义了计算图。现在你明白两种编程模型了吧，我们接着来比较它们！命令式程序更加灵活这并不能算是一种严格的表述，只能说大多数情况下命令式程序比符号式程序更灵活。如果你想用Python写一段命令式程序的代码，直接写就是了。但是，你若想写一段符号式程序的代码，则完全不同了。看下面这段命令式程序，想想你会怎样把它转化为符号式程序呢。a = 2
d = np.zeros(10)
for i in range(d):
d += np.zeros(10)你会发现事实上并不容易，因为Python的for循环可能并不被符号式程序的API所支持。你若用Python来写符号式程序的代码，那绝对不是真的Python代码。实际上，你写的是符号式API定义的领域特定语言（DSL）。符号式API是DSL的加强版，能够生成计算图或是神经网络的配置。照此说法，输入配置文件的库都属于符号式的。由于命令式程序比符号式程序更本地化，因此更容易利用语言本身的特性并将它们穿插在计算流程中。例如打印输出计算过程的中间值，或者使用宿主语言的条件判断和循环属性。符号式程序更高效我们在上一节讨论中提到，命令式程序更灵活，对宿主语言的本地化也更好。那为何大部分深度学习函数库反而选择了符号式呢？主要原因还是内存使用和运算时间两方面的效率。我们再来回顾一下本文开头的小例子。import numpy as np
a = np.ones(10)
b = np.ones(10) * 2
...假设数组的每个单元占据8字节。如果我们在Python控制台执行上述程序需要消耗多少内存呢？我们一起来做些算术题，首先需要存放4个包含10个元素的数组，需要4&*&10&*&8&=&320个字节。但是，若是运行计算图，我们可以重复利用C和D的内存，只需要3&*&10&*&8&=&240字节的内存就够了。符号式程序的限制更多。当用户对D进行编译时，用户告诉系统只需要得到D的值。计算的中间结果，也就是C的值，对用户是不可见的。这就允许符号式程序重复利用内存进行同址计算（in-place&computation）。然而，命令式程序属于未雨绸缪的类型。如果上述程序在Python控制台执行，任何一个变量之后都有可能被用到，系统因此就不能对这些变量共享内存区间了。当然，这样断言有些理想化，因为命令式程序在变量超出作用域时会启动垃圾回收机制，内存将得以重新利用。但是，受限于“未雨绸缪”这一特点，我们的优化能力还是有限。常见于梯度计算等例子，我们将在在下一节讨论。符号式程序的另一个优化点是运算折叠。上述代码中，乘法和加法运算可以被折叠为一次运算。如下图所示。这意味着如果使用GPU计算，只需用到一个GPU内核（而不是两个）。这也正是我们在cxxnet和Caffe这些优化库中手工调整运算的过程。这样做能提升计算效率。在命令式程序里我们无法做到。因为中间结果可能在未来某处被引用。这种优化在符号式程序里可行是因为我们得到了完整的计算图，对需要和不需要的变量有一个明确的界线。而命令式程序只做局部运算，没有这条明确的界线。Backprop和AutoDiff的案例分析在这一节，我们将基于自动微分或是反向传播的问题对比两种编程模式。梯度计算几乎是所有深度学习库所要解决的问题。使用命令式程序和符号式程序都能实现梯度计算。我们先看命令式程序。下面这段代码实现自动微分运算，我们之前讨论过这个例子。class array(object) :
"""Simple Array object that support autodiff."""
def __init__(self, value, name=None):
self.value = value
self.grad = lambda g : {name : g}
def __add__(self, other):
assert isinstance(other, int)
ret = array(self.value + other)
ret.grad = lambda g : self.grad(g)
return ret
def __mul__(self, other):
assert isinstance(other, array)
ret = array(self.value * other.value)
def grad(g):
x = self.grad(g * other.value)
x.update(other.grad(g * self.value))
ret.grad = grad
return ret
# some examples
a = array(1, 'a')
b = array(2, 'b')
print d.value
print d.grad(1)
# {'a': 2, 'b': 1}在上述程序里，每个数组对象都含有grad函数（事实上是闭包-closure）。当我们执行d.grad时，它递归地调用grad函数，把梯度值反向传播回来，返回每个输入值的梯度值。看起来似乎有些复杂。让我们思考一下符号式程序的梯度计算过程。下面这段代码是符号式的梯度计算过程。A = Variable('A')
B = Variable('B')
D = C + Constant(1)
# get gradient node.
gA, gB = D.grad(wrt=[A, B])
# compiles the gradient function.
f = compile([gA, gB])
grad_a, grad_b = f(A=np.ones(10), B=np.ones(10)*2)D的grad函数生成一幅反向计算图，并且返回梯度节点gA和gB。它们对应于下图的红点。命令式程序做的事和符号式的完全一致。它隐式地在grad闭包里存储了一张反向计算图。当执行d.grad时，我们从d(D)开始计算，按照图回溯计算梯度并存储结果。因此我们发现无论符号式还是命令式程序，它们计算梯度的模式都一致。那么两者的差异又在何处？再回忆一下命令式程序“未雨绸缪”的要求。如果我们准备一个支持自动微分的数组库，需要保存计算过程中的grad闭包。这就意味着所有历史变量不能被垃圾回收，因为它们通过函数闭包被变量d所引用。那么，若我们只想计算d的值，而不想要梯度值该怎么办呢？在符号式程序中，我们声明f=compiled([D&)来替换。它也声明了计算的边界，告诉系统我只想计算正向通路的结果。那么，系统就能释放之前结果的存储空间，并且共享输入和输出的内存。假设现在我们运行的不是简单的示例，而是一个n层的深度神经网络。如果我们只计算正向通路，而不用反向（梯度）通路，我们只需分配两份临时空间存放中间层的结果，而不是n份。由于命令式程序需要为今后可能用到的梯度值做准备，中间结果不得不保存，就需要用到n份临时空间。正如我们所见，优化的程度取决于对用户行为的约束。符号式程序的思路就是让用户通过编译明确地指定计算的边界。而命令式程序为之后所有情况做准备。符号式程序更充分地了解用户需要什么和不想要什么，这是它的天然优势。当然，我们也能对命令式程序施加约束条件。例如，上述问题的解决方案之一是引入一个上下文变量。我们可以引入一个没有梯度的上下文变量，来避免梯度值的计算。这给命令式程序带来了更多的约束条件，以换取性能上的改善。with context.NoGradient():
a = array(1, 'a')
b = array(2, 'b')
d = c + 1然而，上述的例子还是有许多可能的未来，也就是说不能在正向通路中做同址计算来重复利用内存（一种减少GPU内存的普遍方法）。这一节介绍的技术产生了显式的反向通路。在Caffe和cxxnet等工具包里，反向传播是在同一幅计算图内隐式完成的。这一节的讨论同样也适用于这些例子。大多数基于函数库（如cxxnet和caffe）的配置文件，都是为了一两个通用需求而设计的。计算每一层的激活函数，或是计算所有权重的梯度。这些库也面临同样的问题，若一个库能支持的通用计算操作越多，我们能做的优化（内存共享）就越少，假设都是基于相同的数据结构。因此经常能看到一些例子在约束性和灵活性之间取舍。模型检查点模型存储和重新加载的能力对大多数用户来说都很重要。有很多不同的方式来保存当前工作。通常保存一个神经网络，需要存储两样东西，神经网络结构的配置和各节点的权重值。支持对配置文件设置检查点是符号式程序的加分项。因为符号式的模型构建阶段并不包含计算步骤，我们可以直接序列化计算图，之后再重新加载它，无需引入附加层就解决了保存配置文件的问题。A = Variable('A')
B = Variable('B')
D = C + Constant(1)
D.save('mygraph')
D2 = load('mygraph')
f = compile([D2])
# more operations
...因为命令式程序逐行执行计算。我们不得不把整块代码当做配置文件来存储，或是在命令式语言的顶部再添加额外的配置层。参数更新大多数符号式编程属于数据流（计算）图。数据流图能方便地描述计算过程。然而，它对参数更新的描述并不方便，因为参数的更新会引起变异（mutation），这不属于数据流的概念。大多数符号式编程的做法是引入一个特殊的更新语句来更新程序的某些持续状态。用命令式风格写参数更新往往容易的多，尤其是当需要相互关联地更新时。对于符号式编程，更新语句也是被我们调用并执行。在某种意义上来讲，目前大部分符号式深度学习库也是退回命令式方法进行更新操作，用符号式方法计算梯度。没有严格的边界我们已经比较了两种编程风格。之前的一些说法未必完全准确，两种编程风格之间也没有明显的边界。例如，我们可以用Python的（JIT）编译器来编译命令式程序，使我们获得一些符号式编程对全局信息掌握的优势。但是，之前讨论中大部分说法还是正确的，并且当我们开发深度学习库时这些约束同样适用。大操作&vs&小操作我们穿越了符号式程序和命令式程序激烈交锋的战场。接下去来谈谈深度学习库所支持的一些操作。各种深度学习库通常都支持两类操作。&大的层操作，如FullyConnected和BatchNormalize&小的操作，如逐元素的加法、乘法。cxxnet和Caffe等库支持层级别的操作，而Theano和Minerva等库支持细粒度操作。更小的操作更灵活显而易见，因为我们总是可以组合细粒度的操作来实现更大的操作。例如，sigmoid函数可以简单地拆分为除法和指数运算。sigmoid(x)=1.0/(1.0+exp(-x))如果我们用小运算作为模块，那就能表示大多数的问题了。对于更熟悉cxxnet和Caffe的读者来说，这些运算和层级别的运算别无二致，只是它们粒度更细而已。SigmoidLayer(x) = EWiseDivisionLayer(1.0, AddScalarLayer(ExpLayer(-x), 1.0))因此上述表达式变为三个层的组合，每层定义了它们的前向和反向（梯度）函数。这给我们搭建新的层提供了便利，因为我们只需把这些东西拼起来即可。大操作更高效如你所见，直接实现sigmoid层意味着需要用三个层级别的操作，而非一个。SigmoidLayer(x)=EWiseDivisionLayer(1.0,AddScalarLayer(ExpLayer(-x),1.0))这会增加计算和内存的开销（能够被优化）。因此cxxnet和Caffe等库使用了另一种方法。为了直接支持更粗粒度的运算，如BatchNormalization和SigmoidLayer，在每一层内人为设置计算内核，只启动一个或少数几个CUDA内核。这使得实现效率更高。编译和优化小操作能被优化吗？当然可以。这会涉及到编译引擎的系统优化部分。计算图有两种优化形式内存分配优化，重复利用中间结果的内存。计算融合，检测图中是否包含sigmoid之类的模式，将其融合为更大的计算核。内存分配优化事实上也不止局限于小运算操作，也能用于更大的计算图。然而，这些优化对于cxxnet和Caffe之类的大运算库显得无所谓。因为你从未察觉到它们内部的编译步骤。事实上这些库都包含一个编译的步骤，把各层转化为固定的前向、后向执行计划，逐个执行。对于包含小操作的计算图，这些优化是至关重要的。因为每次操作都很小，很多子图模式能被匹配。而且，因为最终生成的操作可能无法完全枚举，需要内核显式地重新编译，与大操作库固定的预编译核正好相反。这就是符号式库支持小操作的开销原因。编译优化的需求也会增加只支持小操作库的工程开销。正如符号式与命令式的例子，大操作库要求用户提供约束条件（对公共层）来“作弊”，因此用户才是真正完成子图匹配的人。这样人脑就把编译时的附加开销给省了，通常也不算太糟糕。表达式模板和静态类型语言我们经常需要写几个小操作，然后把它们合在一起。Caffe等库使用人工设置的内核来组装这些更大模块，否则用户不得不在Python端完成这些组装了。实际上我们还有第三种选择，而且很好用。它被称为表达式模板。基本思想就是在编译时用模板编程从表达式树（expression&tree）生成通用内核。更多的细节请移步表达式模板教程。cxxnet是一个广泛使用表达式模板的库，它使得代码更简洁、更易读，性能和人工设置的内核不相上下。表达式模板与Python内核生成的区别在于表达式模板是在c++编译时完成，有现成的类型，所以没有运行期的额外开销。理论上其它支持模板的静态类型语言都有该属性，然而目前为止我们只在C++中见到过。表达式模板库在Python操作和人工设置内核之间开辟了一块中间地带，使得C++用户可以组合小操作成为一个高效的大操作。这是一个值得考虑的优化选项。混合各种风格我们已经比较了各种编程模型，接下去的问题就是该如何选择。在讨论之前，我们必须强调本文所做的比较结果可能并不会对你面临的问题有多少影响，主要还是取决于你的问题。记得吗，你若是花费时间来优化无关紧要的部分，整体性能是不可能有大幅度提升的。我们发现通常在效率、灵活性和工程复杂度之间有一个取舍关系。往往不同的编程模式适用于问题的不同部分。例如，命令式程序对参数更新更合适，符号式编程则是梯度计算。本文提倡的是混合多种风格。回想Amdahl定律，有时候我们希望灵活的这部分对性能要求可能并不高，那么简陋一些以支持更灵活的接口也未尝不可。在机器学习中，集成多个模型的效果往往好于单个模型。如果各个编程模型能以正确的方式被混合，我们取得的效果也很好于单个模型。我们在此列一些可能的讨论。符号式和命令式程序有两种方法可以混合符号式和命令式的程序。把命令式程序作为符号式程序调用的一部分。把符号式程序作为命令式程序的一部分。我们观察到通常以命令式的方法写参数更新更方便，而梯度计算使用符号式程序更有效率。目前的符号式库里也能发现混合模式的程序，因为Python自身是命令式的。例如，下面这段代码把符号式程序融入到numpy（命令式的）中。A = Variable('A')
B = Variable('B')
D = C + Constant(1)
# compiles the function
f = compile(D)
d = f(A=np.ones(10), B=np.ones(10)*2)
d = d + 1.0它的思想是将符号式图编译为一个可以命令式执行的函数，内部对用户而言是个黑盒。这就像我们常做的，写一段c++程序并将其嵌入Python之中。然而，把numpy当做命令式部分使用并不理想，因为参数的内存是放在GPU里。更好的方式是用支持GPU的命令式库和编译过的符号式函数交互，或是在符号式程序中加入一小部分代码帮助实现参数更新功能。小操作和大操作组合小操作和大操作也能实现，而且我们有一个很好的理由支持这样做。设想这样一个应用，如更换损失函数或是在现有结构中加入用户自定义的层，我们通常的做法是用大操作组合现有的部件，用小操作添加新的部分。回想Amdahl定律，通常这些新部件不太会是计算瓶颈。由于性能的关键部分我们在大操作中已经做了优化，这些新的小操作一点不做优化也能接受，或是做一些内存的优化，而不是进行操作融合的优化。选择你自己的风格我们已经比较了深度学习编程的几种风格。本文的目的在于罗列这些选择并比较他们的优劣势。并没有一劳永逸的方法，这并不妨碍保持你自己的风格，或是组合你喜欢的几种风格，创造更多有趣的、智慧的深度学习库。参与笔记制作这个笔记是我们深度学习库的的一部分。很欢迎大家提交申请，一起为这份笔记做贡献。原文链接：（译者/赵屹华&审校/刘帝伟、朱正贵、李子健）感谢李沐大神（微博：）对本译文的最终确认。延伸阅读&中文博文解析：mxnet是cxxnet的下一代，目前实现了cxxnet所有功能，但借鉴了minerva/torch7/theano，加入更多新的功能。ndarray编程接口，类似matlab/numpy.ndarray/torch.tensor。独有优势在于通过背后的engine可以在性能上和内存使用上更优。symbolic接口。这个可以使得快速构建一个神经网络，和自动求导。更多binding 目前支持比较好的是python，马上会有julia和R。更加方便的多卡和多机运行。性能上更优。目前mxnet比cxxnet快40%，而且gpu内存使用少了一半。目前mxnet还在快速发展中。这个月的主要方向有三，更多的binding，更好的文档，和更多的应用（language model、语音，机器翻译，视频）。地址在&&欢迎使用。（责编/周建丁）
推荐阅读相关主题：
CSDN官方微信
扫描二维码,向CSDN吐槽
微信号：CSDNnews
相关热门文章MXNet API入门 — 第6篇机器学习 深度学习 神经网络 MXNet AWS摘要：Apache MXNet是一种功能全面、可以灵活编程并且扩展能力超强的深度学习框架，支持包括卷积神经网络(CNN)与长短期记忆网络(LSTM)在内的顶尖深度模型。这一系列文章介绍了MXNet的基本概念和使用方法。本篇主要介绍不同模型的对比结果。正文：在文章中，我们使用三种预训练模型进行物体检测，并通过一些图片对他们的效果进行了对比。在这一过程中发现这些模型有着截然不同的内存需求，最“节省”的Inception v3“只”需要43MB内存。那这就提出了另一个问题：“能否在某些非常小型的设备，例如树莓派上运行这些模型？”嗯，一起试试吧！在树莓派上构建MXNet目前已经有了，但我发现其中缺少一些关键步骤，因此我也写了一版。该教程在运行最新版Raspbian的Raspberry Pi 3上可以完美运行。$ uname -aLinux raspberrypi 4.4.50-v7+ #970 SMP Mon Feb 20 19:18:29 GMT 2017 armv7l GNU/Linux首先需要添加所有必要的依赖项。$ sudo apt-get update$ sudo apt-get -y install git cmake build-essential g++-4.8 c++-4.8 liblapack* libblas* libopencv* python-opencv libssl-dev screen随后需要克隆**MXNet代码库并签出**最新的稳定版本。最后一步不能省略，因为我发现大部分时候HEAD都是损坏的（日更新：MXNet开发团队联系了我，他们说持续集成现已就位，我也确认了HEAD已经可以成功构建。做的好！）。$ git clone https://github.com/dmlc/mxnet.git --recursive$ cd mxnet# List tags: v0.9.3a is the latest at the time of writing$ git tag -l$ git checkout tags/v0.9.3aMXNet可以通过S3加载和存储数据，因此有必要启用该功能，这样后面的操作可以更简单些。MXNet还支持HDFS，但需要在本地安装Hadoop，所以还是算了吧…… :)这样就可以直接运行make了，但考虑到树莓派有限的处理能力，构建过程会需要很长时间：你肯定不希望由于SSH会话超时打断构建过程！可以使用解决这个问题。为了尽可能加快速度，我们可以用（总共四个内核中的）两个内核并行运行一个make。不建议使用更多内核，我自己这样尝试时树莓派停止响应了。$ export USE_S3=1$ screen make -j2整个过程需要大约一小时。最后一步需要安装库文件及其Python绑定。$ cd python$ sudo python setup.py install$ pythonPython 2.7.9 (default, Sep 17 2016, 20:26:04)[GCC 4.9.2] on linux2Type "help", "copyright", "credits" or "license" for more information.&&& import mxnet as mx&&& mx.__version__'0.9.3a'加载模型将模型文件复制到树莓派之后，还需要确保可以实际加载这些模型。此时可以使用文章中用到的代码。另外需要提醒的是，CLI模式下的树莓派有大约580MB可用内存，所有数据可存储在一张32GB的SD卡中。试试看加载VGG16。&&& vgg16,categories = init("vgg16")terminate called after throwing an instance of 'std::bad_alloc'
std::bad_alloc糟糕！VGG16**太大**，内存装不下。那就试试ResNet-152。&&& resnet152,categories = init("resnet-152")Loaded in 11056.10 microseconds&& print predict("kreator.jpg",resnet152,categories,5)Predicted in 7.98 microseconds[(0., 'n stage'), (0., 'n microphone, mike'), (0., 'n electric guitar'), (0., 'n spotlight, spot'), (0., 'n acoustic guitar')]ResNet-152只用了大约10秒就成功加载，预测工作可在不到10微秒内完成。接着再试试Inception v3。&&& inceptionv3,categories = init("Inception-BN")Loaded in 2137.62 microseconds&& print predict("kreator.jpg",resnet152,categories,5)Predicted in 2.35 microseconds[(0.4685601, 'n stage'), (0., 'n electric guitar'), (0., 'n torch'), (0., 'n drumstick'), (0., 'n acoustic guitar')]在树莓派这种资源有限的设备上，模型之间的差异就更明显了！Inception v3加载速度快很多，可在不到1毫秒内完成预测。就算成功加载该模型之后，树莓派依然有大量可用内存可用于运行其他程序，因此它非常适合某些嵌入式应用。我们接着继续 :)使用树莓派的摄像头拍摄图片我们可以给树莓派添加各种外设，其中最有趣的可能就是。用法也很简单！&&& inceptionv3,categories = init("Inception-BN")&&& import picamera&&& camera = picamera.PiCamera()&&& filename = '/home/pi/cap.jpg'&&& print predict(filename, inceptionv3, categories, 5)这里有个例子。Predicted in 12.90 microseconds[(0., 'n remote control, remote'), (0., 'n switch, electric switch, electrical switch'), (0., 'n joystick'), (0., 'n projector'), (0., 'n modem')]很酷吧！增加各类Amazon AI服务，反正完全可行！我还试着通过之前写的Python脚本（，）使用对同一张图片进行了识别。$ ./rekognitionDetect.py jsimon-public cap.jpg copyLabel Remote Control, confidence: 94.Rekognition的效果也不错。接下来，如果能让树莓派用声音告诉我们图片的内容，是不是感觉更酷了！几步简单操作即可将加入我们的环境（）。
Amazon Rekognition和Amazon Polly都是基于深度学习技术的托管服务。用户无需自行考虑模型或基础架构本身，只需要调用API即可。
下面这个视频演示了我通过树莓派用MXNet中运行的Inception v3模型进行实时物体检测，并通过Amazon Polly描述识别结果的过程。Youtube介绍视频： 这一系列6篇文章，我们真是取得了不错的进展，我们已经了解了如何：
使用NDArray管理数据，
使用Symbol定义模型，
使用Module运行预测，
加载并对比用于物体检测的预训练模型，
在树莓派上实时运行预训练模型。
这一系列文章主要侧重于通过卷积神经网络进行的物体识别，其实MXNet的能力远不止于此，以后有机会再说吧。本系列内容全部完结。希望你喜欢并能有所收获。作者：，阅读英文原文：
添加新批注
在作者公开此批注前，只有你和作者可见。
查看更早的 5 条回复