HanLP2.x服务端开发计划

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

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

2 Likes

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服务器,未来会拿出来做公益服务。总之,各方面的设想还算可行,欢迎你和任何有志人士反馈意见、参与开源。

2 Likes

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

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

再次感谢何老师提供hanlp。

1 Like

现在2.1版已经发布了客户端和文档,服务端按照上面的讨论,交给开源社区自由实现。只要按照下列文档约定的格式,即可实现与官方客户端兼容的服务端:

这份文档约定了很多细节,有些功能(多语种,预先分词,预先分句)开源社区未必需要,可以不实现。但parse(text)这个最简单的接口,则建议所有人都实现。

秦失其鹿,天下共逐之。如果任何服务商的API不稳定,社区可以自行实现服务端,开源的火炬也不会熄灭。

1 Like