谷歌云TensorFlow性价比测试：CPU比GPU表现更好

问耕 编译整理
量子位 出品 | 公众号 QbitAI

作者Max Woolf毕业于卡内基梅隆大学，曾是苹果公司的软件工程师

我一直在用Keras和TensorFlow搞一些深度学习的个人项目。然而用亚马逊和谷歌的云服务可不是免费的，从成本方面考虑，我尝试使用更便宜的CPU实例，而不是GPU实例来节省资金。没有想到的是，这只让我的模型训练只慢了一点点。

于是我决定进一步研究一番。

Google Compute Engine（GCE）上GPU实例的价格为0.745美元/小时（0.7美元/小时的GPU+0.045美元/小时的n1-standard-1实例）。几个月前，谷歌推出基于英特尔Skylake架构、最高有64个vCPU（虚拟CPU）的CPU实例。

更重要的是，这些可以应用在Preemptible CPU实例（一种更便宜、更经济的经济虚拟机服务）中，这种服务最多可以在GCE上存在24小时，而且可以随时终止服务，费用只有标准实例的20%。具有64个vCPU和57.6GB RAM的preemptible n1-highcpu-64实例，价格为0.509美元/小时，约为GPU实例价格的三分之二。

如果使用64个vCPU的模型训练，与使用GPU训练速度相当（哪怕略慢），那么使用CPU显然从成本考虑更加划算。不过这个结论是基于深度学习软件和GCE平台硬件运行效率达到100%，如果效率没这么高，可以通过减少vCPU的数量来降低成本。

所以，使用CPU而不是GPU来进行深度学习训练，到底可不可行？

设置

我之前就有真实情况下深度学习的性能测试脚本、Docker容器环境以及TensorFlow vs. CNTK对比测试的结论。只需要一些小调整，就可以通过设置CLI参数，让脚本用于CPU和GPU实例。我还重建了Docker容器，以支持最新的TensorFlow 1.2.1；还创建了一个CPU版本的容器，以安装适用于CPU的TensorFlow库。

使用CPU时，如果使用pip安装并且在TensorFlow里训练模型，你会在控制台中看到这样的警告：

为了解决这些警告，并对SSE4.2/AVX/FMA进行优化，我们从源代码编译了TensorFlow，并创建了第三个Docker容器。在新容器中训练模型时，大多数警告都不再出现，而且确实提高了训练速度。

这样，我们就可以使用Google Cloud Engine开始测试三大案例：

• 一个Tesla K80 GPU实例

• 一个64 Skylake vCPU实例，其中TensorFlow通过pip安装，以及8/16/32个vCPU的测试

• 一个65 Skylake vCPU实例，其中TensorFlow使用CPU指令编译（cmp），以及8/16/32个vCPU的测试

结论

对于每个模型架构和软/硬件配置，下面的结论都使用GPU实例训练时间作为基准进行对比换算，因为在所有的情况下，GPU应该是训练速度最快的方案。

让我们从 MNIST手写数字数据集+通用的多层感知器（MLP）架构 开始，使用密集的全连接层。训练时间越少越好。水平虚线是GPU的成绩，虚线以上代表比GPU表现更差。

在这个环节的测试中，GPU是所有平台配置中最快的。除此之外我发现，32个vCPU和64个vCPU之间的性能非常相似，编译的TensorFlow库确实能大幅提高训练速度，但只变现在8和16个vCPU的情况下。也许vCPU之间协调沟通的开销，抵消了更多vCPU的性能优势；也许是这些开销与编译TensorFlow的CPU指令不同。

由于不同vCPU数量的训练速度之间差异很小，因此可以肯定缩减数量能带来成本优势。因为GCE实例的成本是按照比例分摊的（这与亚马逊EC2不同），所以可以更简单的计算成本。

如上图所示，降低CPU数量对这个问题来说成本效益更高。

接着，我们使用相同的数据集，用 卷积神经网络（CNN） 进行数字分类：

在CNN中，GPU的速度是CPU的两倍以上，而且从成本效率上看，64个vCPU甚至高于GPU，而且64个vCPU的训练时间比32个vCPU还长。

继续，我们在CNN方向上更深一步，基于CIFAR-10图像分类数据集，使用一个使用 深度covnet+多层感知器 构建图像分类器模型（类似于VGG-16架构）。

与简单CNN测试的情况类似，不过在这种情况下，所有使用已编译TensorFlow库的CPU都表现更好。

接下来是fasttext算法，用来在IMDb的评论数据库中分辨评论是正面还是负面，在文本分类领域比其他方法都快。

在这个环节中，GPU比CPU快得多。数量较少的CPU配置，没带来太大的优势，要知道正式的fasttext实现视为大量使用CPU设计的，并且能够很好的进行并行处理。

双向长短期记忆（LSTM）架构 对于处理诸如IMDb评论之类的文本数据非常有用，但是在我之前的测试文章里，有Hacker News的评论指出，TensorFlow在GPU上使用了LSTM的低效实现，所以也许差异将会更加显著。

等等，什么？双向LSTM的GPU训练比任何CPU配置都慢两倍以上？哇哦（公平地说，基准测试使用Keras LSTM默认的implementation=0，这对CPU更好；而在GPU上使用implementation=2更好，但不应该导致这么大的差异）

最后， LSTM文本生成 尼采的著作与其他测试类似，但没有对GPU造成严重打击。

结论

事实证明，使用64个vCPU不利于深度学习，因为当前的软/硬件架构无法充分利用这么多处理器，通常效果与32个vCPU性能相同（甚至更差）。

综合训练速度和成本两方面考虑，用16个vCPU+编译的TensorFlow训练模型似乎是赢家。编译过的TensorFlow库能带来30%-40%的性能提升。考虑到这种差异，谷歌不提供具有这些CPU加速功能的预编译版本TensorFlow还是令人吃惊的。

这里所说成本优势，只有在使用谷歌云Preemptible实例的情况下才有意义，Google Compute Engine上的高CPU实例要贵5倍，完全可以消弭成本优势。规模经济万岁！

使用云CPU训练的一个主要前提是，你没那么迫切的需要一个训练好的模型。在专业案例中，时间可能是最昂贵的成本；而对于个人用户而言，让模型兀自训练一整晚也没什么，而且是一个从成本效益方面非常非常好的选择。

这次测试的所有脚本，都可以在GitHub里找到，地址：

https://github.com/minimaxir/deep-learning-cpu-gpu-benchmark

另外还可以查看用于处理日志的R/ggplot2代码，以及在R Notebook中的可视化展现，其中有关于这次测试的更详细数据信息。地址：

http://minimaxir.com/notebooks/deep-learning-cpu-gpu/

【完】

一则通知

量子位读者5群开放申请，对人工智能感兴趣的朋友，可以添加量子位小助手的微信qbitbot2，申请入群，一起研讨人工智能。

另外，量子位大咖云集的自动驾驶技术群，仅接纳研究自动驾驶相关领域的在校学生或一线工程师。申请方式：添加qbitbot2为好友，备注“自动驾驶”申请加入~

招聘

量子位正在招募编辑/记者等岗位，工作地点在北京中关村。相关细节，请在公众号对话界面，回复：“招聘”。

△ 扫码强行关注『量子位』

追踪人工智能领域最劲内容