来源：torch模型在线推理采用gunicorn+flask部署API服务

问题简述：torch模型——huggingface bert模型，CPU核数96+4个GPU同时使用，启动worker=80左右(80个并发请求)，前期能够调用GPU，后期发现有些进程重启后就不再被使用了（top下看不到该pid的进程），因此使用GPU的就不再被使用了，只剩下使用CPU的部分worker，请求方描述，只改变了 java中try请求等待时间加长了。测试也发现postman单个请求响应时间为8min，是以前的至少4倍（之前最多2min，基本上在1min内响应）。

当全部只采用GPU训练（随机选择device），采用kill -9杀死pid时，ps下面还有新的进程产生，这是咋回事？经搜索发现无法杀死gunicorn子进程，它会再次拉起新的进程（这种进程都是死的，根本无法执行，当有请求过来时返回500），因此如果想要每个GPU启动4-5个进程，只能选择nginx转发，指定单个GPU 4～5个works，但nginx转发可能存在网关耗时问题（暂不考虑，另外nginx怎么和我之前用的不太一样了啊，yum install nginx安装的，之前是ubuntn结果）

为啥要杀死某个进程？这是因为启动的时候无法选定所有GPU均匀分布，也就是说做不到4个卡每个卡4个进程（采用random随机选择GPU index，只有一个脚本的情况下必然无法指定GPU，而如果采用preload_app=False，结果只会选定某个GPU），因此设定preload_app=True,它会共享某部分数据（内存），而模型的数据（输入输出）并没有共享。如果某个卡进程数（pid个数）较少，某个卡较多，这肯定不太好，不能充分利用GPU效率。

为啥出现GPU不能用的情况？不被利用的情况，在之前启动时用了GPU（杀死了部分不合理的pid，该卡进程较多，所以杀了几个）和全部CPU，而CPU进程占比较多（80%+），如果仅仅是因为阻塞导致重启该进程，那么CPU进程最后还能运行（可能有些CPU进程就是没死，部分CPU进程没有发生阻塞）而GPU却死了不能重启。无解，只能增加GPU数,或者多台机器部署。

在gunicorn的执行config中，设置的worker数应该与random选择的index相适合，比如全部用GPU情况下index=[0,1,2,3],那么worker应设置为4的倍数，比如8，16，20，但index如果仅仅为[0,1,2,3]，可能会出现某个卡分配的进程多，有的分配的少，为了足够随机，index应该设置为更大长度，比如，[0,1,2,3]*20或者[0123]*40 .这种设置会足够随机（random使用）。

目前worker_class仍旧是采用gevent模式，sync未尝试，因为模型推理可能较慢，异步模式好一点吧。

参考文档：flask+gunicorn，flask加载两次？gunicorn启动 ，nginx问题，nginx部署