超级会员免费看
本文探讨了在使用gunicorn和flask部署Huggingface BERT模型时遇到的问题，包括GPU进程未被充分利用和模型响应时间显著增加。通过调整gunicorn配置和工作进程数，以及考虑使用nginx进行负载均衡，以解决GPU分配不均和进程无法重启的问题。此外，文章建议增大index的长度以确保更随机的GPU分配，并考虑切换到异步worker_class以优化延迟。
来源：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个进程，只能选择
订阅专栏 解锁全文
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
