在这个环节中，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中的可视化展现，其中有关于这次测试的更详细数据信息。地址：

【完】

一则通知

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

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

招聘

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

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