【深度】TensorFlow or TensorSlow，谷歌基准测试为何不给力？（附Google内部员工测试代码下载）

11月9日Google发布了第二代深度学习引擎TensorFlow，引起业内广泛关注。发布后业内人士热议的一个话题是：这个引擎能否成为Google所说的平台级产品，它的基准测试究竟怎么样？

Soumith 在 Github 做基准测试，在 Google TensorFlow 发布后，Soumith 很快发布了关于 TensorFlow 的基准测试报告。

【Soumith】GoogleTensorFlow的benchmark列在了这里。

我在Imagenet Winners上运行了benchmark测试程序。

当我看到结果的数字，内存等等，我给贾扬清@Yangqing发了一封邮件，他确认了我看到的情况的确就是预期的样子。

在免责声明的基础上，这里有一些关于TensorFlow的事情你需要了解（这是我今天安装的pip版本的一些信息）：

• 原地修正线性单元（in-place ReLU）似乎在实际操作中并不存在
• 贾扬清说：“目前，TensorFlow中几乎没有原地操作，我们非常依赖于调度器和内存池来分配和释放内存。”
• 支持CuDNN R2，目前还不支持CuDNN R3，贾扬清说TensorFlow会支持的下一个CuDNN版本可能是R4。

然后是benchmark：

• Googlenet在批尺寸为128时会内存不足。我能使用的最大的批尺寸是16（试过了16，32，64，128）。
• VGG在批尺寸为64时会内存不足。我能适用的最大的批尺寸是32（试过了32，64）。
• 我也计算了Torch7+CuDNN-R2下使用这些批尺寸时得到的基准线。

要注意的是，在 batchsize 为16 时，使用 CuDNN-R2+Torch 的 Googlenet 可能会有调度的额外开销（dispatching overhead）问题，所以这是一个吸引人的比较，但在实际层面上并不十分有趣或者说值得期待。

以上是 Soumith 在 Github 上的文章。

作为 Google 宣称的第二代深度学习引擎，TensorFlow 的基准测试并不理想。

不理想表现的背后，究竟是怎么回事？新智元采访和收集了一些业内人士的观点。

1、CMU Petuum 团队

在 Soumith 做测试之前，新智元就采访了 CMU 的 Petuum 团队，在11月10日的文章中提出了 Google TensorFlow 可能会出现的问题。

《【深度解析】Google第二代深度学习引擎TensorFlow开源（CMU邢波独家点评、白皮书全文、视频翻译）》

Petuum团队谈到，TensorFlow 大概仅对应于 Spark 里面的 MLlib库，或者对应于Petuum里面的深度学习框架。

展开来说：

第一，从深度学习的角度来分析，TensorFlow目前尚缺乏很多系统方面对deep learning的设计和优化（比如在训练深度卷积神经网络时，可以利用CNN的结构特性以及算法特性在系统方面，给出对应的优化，降低内存使用，减少通信负载等），所以TensorFlow还不能称为一个specialized 的DL库。

第二，Google在白皮书上展望了TensorFlow是一个分布式系统上的机器学习框架。但是从目前Tensor Flow的release来看，他们只支持单机多卡，不支持多机的分布式环境。就深度学习这个具体方向上，目前public available的不支持分布式的DL库已经有10个以上，Google当前发布TF作为一个general-purpose的产品，定位有待进一步观察；

第三，一个专业的技术产品在发布之前最好服从专业标准，在专业dataset上进行性能测试，并与其它类似框架进行比较；TensorFlow缺乏公开的评测数据，具体性能如何有待进一步探讨。

第四，业界会继续关注的是Google此前收购的在公司内部具有特殊地位的DL公司Deepmind仍在使用Torch和Caffe，未来他们是否会近水楼台使用TensorFlow或Distbelief，大家拭目以待。

在采访的时候提到，TensorFlow并没有发布测试数据。而一个平台级的产品，必须发布严格的比较数据来证实一项技术取得了超越性的进展。

这次 Soumith 在 Github 做第三方基准测试，也反映了 TensorFlow 在性能指标上的问题。

2、Github 用户怎么说？

Github user：scott-gray

没有原地操作是一件相当让人意外的事。一旦你有了完整的DAG，通过活性算法（liveness algorithm）来优化张量分配就应该会变得相当简单。

我有点好奇有没有对于将操作自动复合的支持或者在内核上内置一些复合（比如gemm的alpha/beta params）。我已经差不多在我的benchmark网络上把复合量最大化了。并且因为我用的内核都是我自己编写的，我可以进一步做一些其他闭源库（比如CuDNN）中实现不了的复合。比如，我现在可以毫无代价地计算conv和gemm里的PQN维度均值。这把fprop的batch norm需求带宽降低了三分之一。

虽然在整体上我觉得TensorFlow看上去是一个很棒的平台，我得说有很大可能我自己的内核（winograd）会在不久以后就比TensorFlow性能更好。

Github user：tqchen

在内存优化方面，我们发现的是，如果分配器聪明到可以在运行graph之前就完成静态分配（与依赖于动态分配器相对比），那么原地优化就并不是那么重要。

基本的想法是，不仅对相同形状的内存做共享（也就是原地），也对不同形状和大小的内存做共享。

Github user：rajatmonga

我们的目标是先放出一个初期的版本，让用户们可以开始玩起来，然后把他们在意的情况反馈给我们。我们承诺会做到TensorFlow的速度变得更快，并且我们正积极地针对这里提到的情况在做改进。

Github user：gujunli

既然是用CuDNN v2，那我就不能理解为什么TensorFlow会结果那么慢？你有什么想法吗？我会猜TensorFlow在卷积/池化等几层也调用了cuDNN v2这个库。

Github user：scott-gray

如果用的的确是cuDNNv2那么速度那么慢只有一个可能，记录下来的运行时间里有不应该算进去的间隔。

Github user：Yangqing（贾扬清）

@gujunli @scott-gray 从历史角度来看这个问题：这大部分是因为历史遗留。Google Brain一直在使用NHWC存储顺序以及一种稍有不同的填充格式（"SAME/VALID”，而不是更明显的填充数字）。CuDNN，和Caffe一样，使用的是NCHW顺序。要注意的是，CuDNN支持NHWC，但一些底层路径不会生效，例如NHWC后向卷积。

因此，当调用CuDNN时，有一些代码用来产生中间填充（intermediate padded）和交换了顺序的中间张量。这些代码是用Eigen写的，与nvcc的交互不是很好，导致了不少额外开销（你可以通过在nvvp运行benchmark来观察到这一点，像之前Scott建议的那样）。

我们有一些人手正在研究这个问题，TensorFlow的性能表现应该要被提升到CuDNN的水平。

Github user：Yangqing（贾扬清）

@soumith 关于内存问题，我们发现如果你开启了最合适的GPU分配器，你将能够以64的批尺寸来运行VGG。我在源代码上做了一个小修改，你可以试一下。

git clone https://github.com/Yangqing/tensorflow.git

cd tensorflow

git checkout bfc

@vrv将会提交更多修改，让它变得更简单。

Github user：hjk41

动态GPU内存分配对性能有很大影响。一个简单的内存分配器可以大大降低额外开销。一个最适并且可以重复使用模块的更聪明的分配器则几乎可以彻底消除额外开销的问题。

3、Reddit 用户怎么说？

楼主（Reddit user：ml_lover）

TensorFlow的糟糕表现意味着他们内部不像我们那样使用。

对于一家如此重视性能的公司谷歌来说，我无法相信他们没有看到现有的大部分开源软件完胜他们的TensorFlow。原因很有可能是下面几个：

1. 谷歌的GPU数量多的让他们不在乎TensorFlow在单个GPU上的表现；

2. 谷歌内部不使用TensorFlow

3. 谷歌使用AMD GPU或者其他的GPU或FPGA。

4. 谷歌有另外一些让TensorFlow性能很好的程序，但没有将他们开源。

对于我来说，这些原因都很有可能。

以下是跟帖部分：

Reddit user：siblbombs：

1. 他们有很多钱，我认为他们有很多GPU。

2. 明显这是不对的

3. 可能使用FPGA，但只对于研究来说，没人用AMD。

4. 他们有多个机器形式的代码（正在准备发布中），他们过去用CPU来训练，所以我认为对于他们来说可能使用很多CPU来说更容易一点

Reddit user：davmre

或者，他们认为相比于在标准的卷积模型中提高其性能，自动微分和基于Theano的模型的灵活性是他们研究更注重的。当然，理想情况下，你可以拥有两者，但有可能他们还没研究到这一步。

值得注意的是GPU在运行系统中还是一个很新的领域（例如Facebook显然只用了CPU），所以对于其优化还有点早。

ml_lover回复：微软已经使用了FPGA。

davmre回复：当然，而且百度也在使用GPU了。我只是想说早期TensorFlow的发展可能更注重替代DistBelief，因为产品已经在cpu设施上运行了。

Reddit user：dwf

我认为你犯了一个错误。在文章中，GPU只是用来训练而CPU负责产出。

在你训练模型后，从一个观点来看，这只是一堆字节，因此你能够很容易的将其序列化，输入到内存，然后做你想做的事情。原因？我的猜想是在网络中CPU和GPU之间的数据传输很慢，但是产出并没有训练那样消耗计算。

至于楼主的问题，如果你去读读TensorFlow的白皮书，很容易知道这个系统被创造出来的目的就是为了分布式处理，因为这就是白皮书说的。单机表现恐怕不是谷歌关心的。

Reddit user：herir

谷歌从未说tensorflow是市场上最快的系统。然而它对于他们的产品、服务器和处理团队等来说只是一个库而已。回答楼主的几个问题：

1. 我的想法是谷歌有很多有GPU的服务器，所以他们让tensorflow有效率的分布到那些服务器上。

2. 谷歌过去使用DistBelief，但他们将逐渐转移到TensorFlow上。

3. 可能性不大。

Reddit user：suki907

看白皮书：相对于我们以往的distbelif的对模型的实现，最终结果是这些努力导致了在训练时间上速度提升了6倍，而且这种速度被证明在新的大型图像识别模型中是不可或缺的。小部分机器集群的表现也会相应增加。

对于在单机上的表现，并没有1千或1万的机器的表现那么重要。

看看distbelief的白皮书，第一个展示性能的图表，它显示了128个机器比单机快了12倍。

也许每个机器只计算了总时间的10%，等待其他机器的输入占了90%。

如果你想要让工程师减少时间，注意力应该集中在将等待时间减半而不是计算时间。

这些是在单机上无法看到的。

4、Hacker News 用户怎么说？

我认为以下几点更有道理：

a） 这是谷歌公司，他们可以用强大的硬件资源来暴力解决像内存不够这样的问题

b） Tensorflow让实现方法变得更加容易，这相较于性能上的损失是值得的。

c） 现在还早，图模型有很好的前景，而且相比于其他框架来说，能够以更加灵活的方式被优化。

当我致力于研究编程的方法时，我更担心代码是否没有bug或者易于理解，因此tensorflow给出了正确的结果。通常来说，我并不担心性能除非我无法运行它。特别是在研发时，你花了很多时间在调试上。如果新的方式能够实现代码出现较少的bug，那么这就是一种胜利。

IanCal补充b）观点：Tensorflow让实现方法变得更加容易，这相较于性能上的损失是值得的。

确实如此，如果使用了tensorflow，我能够在1天内实现编程然后2天用来训练数据（共3天），而不是3天编程1天训练（共4天），那么我能够用多出的那一天来喝鸡尾酒、读书，而且仍然更早完成。根据教程来看，我似乎能够很快的完成翻译流水线，而且事实上我认为我会尝试那种实现方法。如果它训练要花费一周或者两周时间，我不在乎，因为我还有其他事情要做。

总结：

1. GPU应用于训练上的领域起步不久，优化有待跟进

2. Tensorflow开发的目的注重于自动微分和基于Theano的模型的灵活性，而不在于性能

3. GPU和CPU之间数据传输慢，比较耗时，tensorflow用于分布式系统

4. 个人觉得f/g强烈推荐！

5、Google 内部员工测试

Google 内部员工在 Google Git 上对AlexNet做了TensorFlow 的基准测试，测试结果似乎要比Soumith好一些。

代码已公开，请在【新智元】后台回复1112下载代码。

新智元倡议

新智元欢迎转载和摘编相关资料，但必须经过正式授权，邮箱为：simonwangx@163.com

我们倡议以公正、透明和积极的方式促进行业发展，如有出现匿名攻击、人身骚扰或其他不正当竞争手段，我方会采取相应的法律措施。