为什么研究人员喜欢PyTorch?简单。PyTorch类似于numpy,非常Python化,很容易就能与Python生态系统的其余部分集成。例如,可以在PyTorch模型中任何地方添加pdb断点。而在TensorFlow中,调试模型需要一个活动会话,整个过程非常麻烦。
API。大多数研究人员更喜欢PyTorch的API而不是TensorFlow的API。部分原因是因为PyTorch的设计更好,还有部分是因为TensorFlow切换其API接口过于频繁(比如“layers”-“slim”-“estimators”-“tf.keras”),这阻碍了其自身的发展。
表现。尽管PyTorch的动态图给出的优化机会很少,但许多传闻称PyTorch的速度不比TensorFlow慢多少。目前尚不清楚这是否属实,但至少,TensorFlow在这一方面还没有获得决定性的优势。
TensorFlow未来的研究方向是什么?即使TensorFlow在功能上与PyTorch不相上下,但PyTorch已经覆盖了机器学习社区的大部分。这意味着PyTorch实现将更容易找到,作者将更有动力用PyTorch发布代码,而且你的合作者也很可能会更喜欢PyTorch。因此,任何向TensorFlow 2.0的回迁可能会很慢。
TensorFlow在Google/Deepmind中有一批忠实的用户,但不知道Google最终是否会在这一点上动摇。现在,很多Google想招募的研究人员已经开始喜欢上PyTorch了,我也听到抱怨说Google内部很多研究人员希望使用TensorFlow之外的框架。
此外,PyTorch的统治地位很可能会切断谷歌研究人员与其他研究社区的联系。他们不仅难以在外部研究的基础上进行构建,而且外部研究人员也不太可能在谷歌发布的代码基础上进行构建。
TensorFlow 2.0是否能重新俘获回之前的粉丝还有待观察。尽管eager模式很吸引人,但对于Keras API而言并非如此。
用于产业的PyTorch和TensorFlow虽然PyTorch目前在研究领域占据主导地位,但稍微注意一下就会发现TensorFlow仍然是占据主导地位的框架。
例如,根据2018年到2019年的数据,TensorFlow在招聘的页面上有1541个新工作岗位,而PyTorch有1437个,TensorFlow在Medium上有3230个新文章,而PyTorch有1200篇,TensorFlow在GitHub有13.7K标星,而PyTorch有7.2K。
那为什么PyTorch现在已经如此受研究人员欢迎了,但它在工业上还没有同样的成功呢?
显而易见的第一个答案就是使用习惯。TensorFlow比PyTorch早几年问世,而产业接受新技术的速度要比研究人员慢。
另一个原因就是TensorFlow在产业适应方面优于PyTorch,什么意思呢?要回答这个问题,我们需要知道研究人员和工业界的需求有何不同。
研究人员关心的是他们在研究中迭代的速度有多快,这通常是在相对较小的数据集(可以在一台机器上运行的数据集)上,并在8个GPU上就可以运行。这通常不是出于对性能的考虑,而是更关注可以快速实现自己的想法。
而工业界则认为性能是最优先考虑的。虽然运行时速度提高10%对研究人员来意义不大,但这可以直接为公司节省数百万美元。
另一个区别是部署。研究人员一般在自己的机器上或某个专门用于运行研究工作的服务器集群上进行实验。但是在产业上,部署则有一连串的限制与要求。
没有Python。运行Python对服务器的开销太大了;
移动。你不能在移动终端二进制文件中嵌入Python解释器;
服务。需要包罗万象的功能:不用停机更新的模型,在模型之间无缝切换,批处理在预测时间,等等。
TensorFlow就是特别针对这些需求构建的,并为所有这些问题提供了解决方案:网络图格式和执行引擎本身不需要Python,而TensorFlow Lite和TensorFlow Serving可以分别处理移动终端和服务器需求。
从历史上看,PyTorch在满足这些需求方面做得还不够,因此大多数公司目前在生产中都还是使用TensorFlow。
架构「融合」2018年末,两件大事彻底改变了这一局面:PyTorch引入了JIT编译器和“TorchScript”,从而引入了基于图的特性;TensorFlow宣布他们将在2.0版本中默认转移到Eager模式。
显然,这些举措都是为了解决PyTorch和TensorFlow各自的弱点。那么这些特性到底是什么,它们能提供什么呢?