Celery worker启用autoscale时的内存管理与模型实例加载问题

结论先行 #

两个问题的答案都是是。

• 每个动态拉起的worker子进程，都会加载独立的predict_language_model实例
• 当autoscale扩容到最大并发8、同时处理8个任务时，内存中会同时存在8份该模型实例

原因说明 #

你用的--autoscale是Celery基于prefork进程池实现的动态并发能力，池内的每个worker都是完全独立的操作系统进程，拥有独立的内存空间，默认不会和其他进程共享内存里的对象。

你现在的模型加载逻辑写在proj.ml.models模块的顶层：

predict_language_model = model.load("/path-to-model")

这段代码会在模块被导入时执行。而每个prefork子进程启动时，都会独立加载所有依赖的业务模块，包括你存放模型的proj.ml.models，以及定义任务的proj.apps.pipleine.tasks模块，所以每个子进程都会单独跑一次模型加载逻辑，生成自己进程内独有的模型实例，和其他进程的实例完全隔离。哪怕prefork本身有写时复制机制，Python访问对象时会修改引用计数的特性也会快速打破内存共享，最终每个进程还是会持有独立的模型副本。

按照你写的启动命令：

celery -A proj worker -Q pipeline -I proj.apps.pipleine.tasks --autoscale=8,2

worker刚启动时会初始化2个常驻子进程，此时内存里已经有2份模型副本；后续负载升高、autoscale逐步扩容到8个进程时，每新增一个子进程就会多加载一份模型，最终达到8份。

可选优化方向 #

如果单份模型的内存占用很高，这种多副本的模式会吃掉大量内存，可以根据实际场景选优化方案：

• 把模型推理能力拆成独立的单进程常驻服务，所有worker进程通过本地接口调用该服务完成推理，整台机器只保留1份模型
• 换用gevent/eventlet这类线程模式的worker池，多线程同属一个进程，可以共享同一份模型实例，但要提前确认你的模型推理逻辑是线程安全的，避免并发调用时出问题

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