Gunicorn Worker无法并行利用GPU的问题排查与咨询

瓶颈原因 #

• 单GPU任务调度特性限制：CUDA默认调度机制下，多进程发起的GPU计算任务会进入同一任务队列串行执行。你的T4 GPU虽具备并行计算能力，但单请求的model.forward已占据大部分GPU计算资源，多请求只能排队等待，导致总耗时随请求数线性增长，无法实现并行加速。
• Gunicorn多进程模型适配问题：每个Gunicorn worker是独立进程，若每个worker都加载了一份模型到GPU显存（即使显存充足），多进程同时向GPU提交推理任务时，GPU无法并行处理这些独立任务，反而会因上下文切换增加额外开销。
• 未利用GPU批处理能力：单请求推理时GPU利用率通常不高，但当前架构未将并发请求合并为批次处理，GPU每次仅处理一个请求，无法发挥其批量计算的核心优势。

针对GPU依赖型服务的推荐方案 #

1. 调整Worker类型与数量 #

• 优先使用异步Worker：替换Gunicorn默认的sync worker为gevent或eventlet异步Worker，单个进程内即可高效处理多个CPU侧任务（如数据预处理、请求接收/响应），避免多进程抢占GPU资源。配置示例：

  gunicorn main.app:app -b 0.0.0.0:8000 --workers 4 --worker-class gevent --worker-connections 1000
  

• 单GPU场景下，Worker数量建议设置为CPU核心数（4），避免过多进程导致GPU任务队列拥堵。

2. 启用GPU批处理优化 #

• 修改推理逻辑，维护小型请求队列，积累一定数量的请求后合并为批次，一次性提交给GPU执行model.forward，处理完成后再分别返回结果。
• 利用PyTorch的torch.utils.data.DataLoader或自定义批处理逻辑，自动合并输入张量，最大化GPU利用率。

3. 模型推理优化 #

• 将PyTorch模型转换为TensorRT引擎或使用ONNX Runtime加速推理，这类框架支持动态批处理与GPU算子优化，能显著提升多请求并行处理效率。
• 启用PyTorch的torch.cuda.Stream，将GPU推理任务放入独立流中，与CPU侧的预处理/后处理任务重叠执行，隐藏部分GPU等待时间。

4. 任务队列架构拆分 #

• 引入任务队列（如Celery+Redis）分离CPU与GPU任务：
  • 前端Worker（Gunicorn异步进程）负责接收请求、预处理数据，将任务发送至队列。
  • 专用GPU Worker进程（数量1-2，匹配单GPU资源）从队列获取任务，批量执行推理后将结果返回前端。
    该架构可集中调度GPU资源，避免多进程抢占，同时充分利用CPU并行处理能力。

内容的提问来源于stack exchange，提问作者Vibhas Singh