Tensorflow的启动比pytorch慢十倍

from timeit import default_timer as timer
import os

print('import pytorch')
start = timer()
import torch

end = timer()
print('Elapsed time: ' + str(end - start))

print('import tensorflow')
start = timer()
import tensorflow

end = timer()
print('Elapsed time: ' + str(end - start))

输出

import pytorch
Elapsed time: 0.46338812075555325
import tensorflow
Elapsed time: 4.396180961281061

回想起HanLP1.x时代为了加速模型加载连毫秒都要优化,现在我觉得非常失望。

刚给tf提了个issue,不知道官方有无改进的可能。

1 Like

官方回复内部正在优化。比较影响调试体验,希望能早日用上。

2 Likes

老师还是用pytorch重写把,哈哈

哈哈,如果HanLP是一个纯研究性的项目我会毫不犹豫地用PyTorch的。然而人在江湖,总有身不由己的地方。GitHub上也有类似的讨论,但还需要探索一段时间,甚至一个过渡期。

从github来这里, tf内存溢出那个bug我前两天实测了2.2.0也没有修复, 我自己的解决方案是把hanlp写好的pipeline做成docker服务, 然后调取服务;docker oom了的话就重启container。 我自己经验不是很足, 做的服务端就是flask gunicorn那一套, 但是我在想hanlp以后是不是可以参考tf_serving 的那种方式把hanlp做成docker的形式用来提供服务, 然后client端提供一些接口就行了。这个想法是受到bert-as-service的启发, 不知是否可行。

才疏学浅, 但是如果需要帮助开发的话我会尽力ORZ

1 Like

tf内存泄露这件事的确很尴尬,在这个bug没有修复之前,HanLP就不可能直接依赖tf做生产环境,除非用户跳过tf的dataset自己写data loader。所以,beta版会发布PyTorch的backend。

感谢你的贡献,你在web方面肯定比我强,所以服务端的实现我想交给包括你在内的开源社区去自由实现,我提供简约的API约定(传什么参返回什么json)。毕竟我只想专注算法的开发,没有足够的人力分配在服务运维上。而且服务这块设计的技术栈特别多,Flask、Django、wsgi、容器、安全性等等,肯定不是一两个人能搞定的。即使这一两个人搞定了,也未必符合大部分用户的需求。比如,有的企业可能更偏好另一种框架,有的企业会加入权限控制等等。HanLP的服务比bert-as-service复杂很多,服务端可能不适合官方做,而是协调整个开源社区自由做。

我设想的方式是这样的:

  1. 我出一套客户端的API约定,包括接口命名、参数返回值定义等,大概率就只有一个process接口,非常简单。客户端官方提供Python和Java的实现,基本就是request一下服务器的process接口。
  2. 开源社区按照这个简单的约定,挑选自己喜欢的技术栈,实现这一接口。可能大概率是套用pipeline(text)等。
  3. 服务器地址以参数的形式传入客户端的构造函数。这样用户可以用同一套客户端适配不同的服务器,无论服务器是公共的还是私有的,比较灵活。

至于GPU服务器,费用非常高,可能不太会有很多公益服务器,但一定会有相当多的企业内部服务器运行我们的服务端。我个人有一台GPU服务器,未来会拿出来做公益服务。总之,各方面的设想还算可行,欢迎你和任何有志人士反馈意见、参与开源。

1 Like

完全没有完全没有, 弱鸡一枚。

我之前看到您开的issue上有这个提供python和java restful接口的计划, 那就等这个branch开放过后看看接口长什么样, 再看看能不能帮助贡献吧!

再次感谢何老师提供hanlp。

1 Like