如何使用Python multiprocessing Pool运行Bert模型且不关闭进程池

问题1：现有实现是否是最优方案 #

现有方案在Linux默认fork启动模式下可正常运行，但不属于最优方案，存在多个可优化点：

• 潜在问题
  1. 标准库multiprocessing.Pool对PyTorch模型、张量的序列化支持较差，大模型场景下容易出现不可预期的传输报错。
  2. 若运行在Windows/macOS的spawn启动模式下，将主进程预加载的模型作为initargs传入进程池的操作，会触发模型的全量序列化/反序列化流程，额外占用内存和时间，和直接在子进程内加载模型的开销没有差异。
  3. 未利用PyTorch的GIL释放特性：CPU推理场景下PyTorch默认释放GIL，用多线程就能跑满多核性能，完全不需要引入多进程的通信开销。
• 优化建议
  1. 优先替换为torch.multiprocessing.Pool，专门适配PyTorch对象的跨进程传输，支持张量共享内存，减少不必要的拷贝开销。
  2. 若使用spawn启动模式，直接在pool_init函数内加载Bert模型和分词器，不要从主进程传递，避免序列化开销，主进程也不需要预加载模型。
  3. GPU推理场景不建议用多进程，单进程处理批量输入、或者用vLLM等专用推理框架的吞吐量远高于自行维护多进程实例。

问题2：进程池的close/join调用时机以及场景适配 #

• 首先纠正认知误区：pool.map()是同步阻塞方法，调用后会等待所有worker进程处理完所有任务、将结果全部返回之后才会继续执行后续代码，也就是说你拿到answers变量的时候所有子进程的任务已经执行完毕，完全不需要在check_condition之前手动调用join()，现有循环逻辑可以直接正常运行。
• close()和join()的调用时机：只有当你确定后续不会再向进程池提交任何任务的时候才需要调用，完全符合你的预期，直接在对象的__del__方法中按先close()再join()的顺序调用即可，用来释放进程池占用的系统资源。
• multiprocessing Pool完全适配你的场景，不需要自行管理进程数组：自己维护进程数组需要额外实现任务队列、结果回收、异常处理等逻辑，开发成本高且容易出现资源泄漏问题，直接用现成的进程池即可满足需求。

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