TensorFlow 真的要被 PyTorch 比下去了吗？
链接：https://www.zhihu.com/question/350445991/answer/882643842
编辑：深度学习与计算机视觉
声明：仅做学术分享，侵删
PyTorch称霸学界，TensorFlow固守业界，ML框架之争将走向何方？
作者：Will Zhang
https://www.zhihu.com/question/350445991/answer/892008154
评价一下Tensorflow，总的来说设计之初为了性能牺牲了一点易用性，但是后面却完全抛弃了性能：
1. 如果说cmake是shit的话，bazel连shit都不如，几乎每个版本的bazel互相都不兼容，巨多的soft link一层包一层的设计导致如果出了编译问题解决起来非常麻烦。
2. 1.x版本追求性能用静态图设计，但实际性能优化做得又不行，败坏了lazy evaluation的名声，上层的API包来包去改得欢，底层的op没人优化，CPU版本的基本功能都支持不全别提性能了，GPU版本的op存在浪费显存浪费计算资源的情况不好好优化，可能内部都用TPU？
3. 分布式版本是业界刚需，然而实现也非常感人，grpc有多烂？Tensorflow不遑多让。全靠horovod续了一把。
4. TF 2.x，用function+compile的设计取代session，是很好的设计，eager和lazy都能用。但是tf.keras这个前缀真是无力吐槽。迁移的问题也很难，业界基于1.x开发的系统想要升2.0基本都要大改。
5. TFLite很现实，用人力堆出了目前移动端最好的部署方案，但是未来应该也会被类似TVM的方案取代。至于TensorRT，我觉得把nvinfer开放出来算了，别整endtoend框架了，手工图优化无穷无尽，虽然性能确实不错，但是接口设计得和cudnn可以一拼了。
我估计的未来：
pytorch会继续巩固在research圈子的统治地位，毕竟research圈子需要高性能的很少，只要pytorch不犯糊涂不甘心于做一个layer+autograd。
业界这块对性能没需求的企业其实也很多，主要是那些获取标注数据非常困难的领域，这些可能也会慢慢转到pytorch。
对性能有高需求同时也是以AI为核心能力的企业，虽然目前来看只有tensorflow生态看似满足需求，但是一旦规模上来，其实tensorflow也满足不了需求，至少开源版本满足不了需求，不管是训练还是部署。所以现在一些公司内部的tensorflow都是二次开发或者干脆自研的。可能未来也会出现一个框架满足这部分需求，但应该不是tensorflow。
所以，tensorflow好像确定会凉了？
作者：知乎用户
https://www.zhihu.com/question/350445991/answer/892008277
说句自己粗浅的理解，其实到了现在，框架比来比去没啥意思，都是有很多可以借鉴的地方，tf 设计理念，我觉得本质上来说是超前torch的，jeff dean 这技术老油条的战略视角可不是盖的。tf 被人诟病最多的，可能只是用户层面，在api的规范性上相比 torch 要差，差的多那种，毕竟 torch 一开始就引导用户用原生的 nn.module 编写程序，大部分 git clone 的项目，你总是可以拿到 module，剩下总是可以自己外挂 hook 去分析很多细节，tf 还要去搞它那个算子拆分极碎的 graph 就十分痛苦。
另外就是模型适配问题，很多小公司不可能有人力和闲情逸致去自己做轮子，大部分还是git clone现成的，然后转换一下到各种云边端上。几年前模型的中间表示没成熟，glue code 坑也多，大家做起来都纷纷躺平思考。至少我看来，改 torch 的 glue code 还没这么烦，而且自带caffe，头铁一下还能输出一套 c艹。tf 有些是要外挂 keras 的，有些是内部算子实现的，改的时候满屏 index 操作，可读性极差，头铁不起来。几年前eager 没出的时候，我们都是 tf.print 去看shape，这种做法，感觉像是通过墙上的一个洞，伸一个棍子进去挑逗里面的狗，然后希望借此把旁边的拖拉机修好一样，十分躺平，早期的风气也不好，大家都是大跃进做模型，开脑洞刷指标，从可复现性，可理解性，易传播等角度来看，tf 相比 pytorch ，确实不占上风，在灌水学术圈的口碑里，日益下滑。
但是后面风向变了，工业届对开脑洞刷点的兴趣越来越低，模型太多可选，好用的也就那几套，工业界也心知肚明，没动力做新的。所以，求稳求快，高可用就成了更现实的诉求。特别是落到中后台部门，框架 API 好不好用反倒是次要的，反正培训班三个月培训调包侠，人力成本不成问题。反而是机器成本太高，调度效率以及资源占用，性能vs成本才是主要的。
比如说，做平台和部署，很多人都推荐去参考 tfx 的理念，也有用核弹厂 trt inference那套开源，如果看进去，就有很多可以学习的地方，比如调度上来说，tf 是如何靠DAG调度的，底层core核心如何定义，trt 如何做自己的cuda stream调度，我们也不断去刨底层学习，这些都是宝藏。虽然目前来说，大家还是比较喜欢虚拟化的部署方案，比如docker一开，量化一下，flask加个jit，就可以邀功了。但是模型多了以后，容器管理和编排，还有资源分配就成了烧钱的选项，毕竟容器开着，几百兆显存就一直占用着，你又不能停服务腾资源。
我们做模型，其实到后期，基本上，能被解决的热点问题，模型几乎通用，大家没啥区别，而犄角旮旯问题，可能商业诉求不太明确，如果自动化程度不高，资源占用太多，又几乎没人乐意去做，变成了难问题做的人太多，构成不了门槛，简单问题没人做，日积月累反而成了门槛。
框架好不好用只是整个生态的一小部分，有趣的，增量最大的，往往在脏乱差，以及不光鲜的地方。
作者：Tux ZZ
https://www.zhihu.com/question/350445991/answer/865965124
Tensorflow现在API越来越乱，缺失的功能还有一堆bug一直就没填上。2.0大幅变更了API，但是原来存在的问题依然存在，原来显式图+session在某些情况下的优势反而消失了。吃枣药丸。
关于BUG特别说一下determinism的问题，只要网络一深，在少epoch的情况下跑两次分数能差~3%-~5%，连NVIDIA家的补丁都救不回来。如果说显卡atomic操作导致问题，pytorch那头明明好好的，误差都在小数点后8-9位，tensorflow就搞不定（当然也或许是我太菜了）。
综上，一直以来糟糕的使用体验和TF团队对Bug和Feature request爱答不理的态度令我叛逃到pytorch。虽然pytorch也有一些问题，但是解决方法好找，代码也好修改，开发团队也理人。
pytorch真香。
作者：知乎用户
https://www.zhihu.com/question/350445991/answer/1056688528
我隐约记得我小时候还有人夸“caffe工业界应用广泛、其他框架恐无法取代”。
然而前几天勃勃的下一任前男友鹿鹿找到我说，某大厂的某组需要优化内存，一个caffe model跑起来要上GB，他必须想办法优化下去（因为要部署到几万台机器，正在考虑部署到内存更小、更便宜的机器上，因此他每省1GB的内存都可能节约几个甚至几十个million）。
这个model几年前训练完以后，就一直躺在那儿，没人懂、没人管、没人过问，就一直耗着那么多内存。鹿鹿头都大了，一直对作者耿耿于怀，甚至连带埋怨起了caffe。我劝他说，在他那个时间点上，caffe是唯一能用的东西，你没必要骂caffe，也没必要骂那个人，caffe后来的feature没有跟上tensorflow和pytorch社区也不能怪社区，社区都是人组成的，大家换到别的社区了，自然愿意给次时代的框架贡献quantization、pruning等等各种feature，caffe的社区自然也就跟不上了——谁都没做错，错在组里没有人持续维护，没有在应该花力气切换的时间去切换。
tensorflow当然好，但是“工业界应用广泛”不能算是优点，因为任何一个在production里广泛部署的老框架老代码，都有可能在未来人类眼里是一坨坨“屎山”——唯一优势就是可以继续逼着未来人类持续吃屎。
作者：骆梁宸
https://www.zhihu.com/question/350445991/answer/890801816
这是个很值得探讨的问题，coding 是研究中不可或缺的环节，不管是研究院还是 SWE 都是蛮值得思考一下的。
但本题目下的大部分答案，不推荐对自己有较高要求的同学观看，大量的回答的高度仅仅只停留在「调包侠」的层面，反而是有误导性的。
除了总结的很好的高赞之外，大部分回答忽略了一个点：TF 有一个降维式的优势在于 TPU. 不方便做太多展开，但各位可以想象一下 TPU 开放之后面对训练效率的绝对碾压时人们会怎么选。
很多人吐嘈了 slim，但 slim 其实不错，而且很多 function 是为了对齐开源实现的「被逼无奈」，有些批评过于无脑了。在喷的同时，读一读源码从源头尝试理解一下 API 设计的初衷和中间可能遇到的各种 trade-off 是对个人提升很大的。
再有一个是很多人提到的，限制 TF 的根本原因不是静态图，而是文档和 API 混乱。TF 的文档 = shit.
TF 有很多出色的 module，比如 Tensorboard，但是 PyTorch 非常机智的对 TF 取其精华去其糟粕，非常值得称赞。
PyTorch 的分布式训练以前真的不行，很多时候 TF 是唯一的方案，但现在迎头赶上了。
暗黑彩蛋：你们知道 tf.torch 嘛？
有了经验之后发现 TF 其实 debug 没有舆论宣传的那么难；很多人觉得难其实是因为他们不会写 Unit Test.
有一个经典的说法是「工业界最终会跟着学术界走」，以前我也这么想，但后来发现 DL community 其实有点特殊，大量的顶尖科研成果其实是工业界产出的。当 Google 内部都有很多人想用 PyTorch 的时候，TF 是真的危险了。
作者：Frank-D
https://www.zhihu.com/question/350445991/answer/1239395409
UPDATE：前两天已经开始把代码转为pytorch了。tf再见了您呐：）
近期在用tf搞事情。
从亲身经历来看。对于研究实验角度，还是pytorch更加友好。因为一些原因开始使用tf，之前觉得这两者并不会有太大差异，现在觉得的确实不如pytorch顺手。这种不顺手两个原因：1. 语法不熟悉（个人原因，总是写着写着就pytorch了） 2. 在训练时，总感觉自己的操作不触及底层，引用一段话：“有时你会觉得你的模型好像躲在一堵墙后面一样，就通过墙上的几个洞洞跟你交流。”就是这种感觉。也有可爱的朋友发出如下感慨：
不过说实话，如果真对着代码扣的话，其实也没有那么夸张。说实话tf1.15也好2.0也好，eager mode挺好的，用tf高阶api也还好。
要是说趋势，如果pytorch和tf都可以，还是pytorch吧。要不是我因为某个轮子用了tf，我肯定不会碰它的。
作者：aluea
https://www.zhihu.com/question/350445991/answer/868489235
pytorch上手比tf简单一点，但真要入这一行，上手难度可以忽略，真正还要看好不好用。
我为什么选择pytorch，如下。
简洁，没有那么多只看名字就摸不着头脑的API，即使某些脏|b不写注释，也能轻易读懂。
运行环境低依赖，cuda is all you need，别人的工作克隆下来+anaconda就能直接跑，高效。
报错简单明了，因为封装结构简单，所以报错也简单。
灵活而不散乱，作为脑洞驱动作业，框架能够实现你所有合理的脑洞是最重要的。实现一个静态的计算图两者都毫无难度，但要实现一个动态的计算图，pytorch只需要在前馈里写一些控制流即可，tf就有点从头搓框架的感觉。
编码可以放开手脚，跑实验并不在乎底层速度效率和资源效率，在超算上那点优化可有可无，pytorch不限制io，你所有的代码空间都可以搬到显存上，爱怎么写就怎么写。tf不大行，不做特殊设置，在io操做上会有制约，写的太肆意了会报一些就算看懂也没用的底层errer。
一般化的比喻，二者就像java和C艹。
☆ END ☆
如果看到这里，说明你喜欢这篇文章，请转发、点赞。微信搜索「uncle_pn」，欢迎添加小编微信「 mthler」，每日朋友圈更新一篇高质量博文。
↓扫描二维码添加小编↓
