从github来这里， tf内存溢出那个bug我前两天实测了2.2.0也没有修复， 我自己的解决方案是把hanlp写好的pipeline做成docker服务， 然后调取服务；docker oom了的话就重启container。 我自己经验不是很足， 做的服务端就是flask gunicorn那一套， 但是我在想hanlp以后是不是可以参考tf_serving 的那种方式把hanlp做成docker的形式用来提供服务， 然后client端提供一些接口就行了。这个想法是受到bert-as-service的启发， 不知是否可行。
才疏学浅， 但是如果需要帮助开发的话我会尽力ORZ
tf内存泄露这件事的确很尴尬，在这个bug没有修复之前，HanLP就不可能直接依赖tf做生产环境，除非用户跳过tf的dataset自己写data loader。所以，beta版会发布PyTorch的backend。
感谢你的贡献，你在web方面肯定比我强，所以服务端的实现我想交给包括你在内的开源社区去自由实现，我提供简约的API约定（传什么参返回什么json）。毕竟我只想专注算法的开发，没有足够的人力分配在服务运维上。而且服务这块设计的技术栈特别多，Flask、Django、wsgi、容器、安全性等等，肯定不是一两个人能搞定的。即使这一两个人搞定了，也未必符合大部分用户的需求。比如，有的企业可能更偏好另一种框架，有的企业会加入权限控制等等。HanLP的服务比bert-as-service复杂很多，服务端可能不适合官方做，而是协调整个开源社区自由做。
我设想的方式是这样的：
process接口，非常简单。客户端官方提供Python和Java的实现，基本就是request一下服务器的process接口。pipeline(text)等。至于GPU服务器，费用非常高，可能不太会有很多公益服务器，但一定会有相当多的企业内部服务器运行我们的服务端。我个人有一台GPU服务器，未来会拿出来做公益服务。总之，各方面的设想还算可行，欢迎你和任何有志人士反馈意见、参与开源。
完全没有完全没有， 弱鸡一枚。
我之前看到您开的issue上有这个提供python和java restful接口的计划， 那就等这个branch开放过后看看接口长什么样， 再看看能不能帮助贡献吧！
再次感谢何老师提供hanlp。
现在2.1版已经发布了客户端和文档，服务端按照上面的讨论，交给开源社区自由实现。只要按照下列文档约定的格式，即可实现与官方客户端兼容的服务端：
这份文档约定了很多细节，有些功能（多语种，预先分词，预先分句）开源社区未必需要，可以不实现。但parse(text)这个最简单的接口，则建议所有人都实现。
秦失其鹿，天下共逐之。如果任何服务商的API不稳定，社区可以自行实现服务端，开源的火炬也不会熄灭。
想自己搭建HanLP的服务端，而不仅仅是直接采用本地API调用使用HanLP，请问如何实现？