Django中Celery执行Scikit-Learn任务时n_jobs配置失效无法调用多核

你遇到的单核运行、并行警告问题，本质是两套多进程机制的检测冲突：

• Celery 5.0.5 默认采用prefork作为任务执行池，每个任务都会被托管在独立的billiard子进程中运行
• scikit-learn 0.24.0 配套的joblib 1.0.0，默认使用loky作为并行计算后端，该后端会对运行环境做嵌套多进程检测，一旦识别到当前环境不是Python原始主进程，就会强制将n_jobs置为1，避免嵌套多进程引发的资源死锁
• 之前修改线程名的方案失效，是因为joblib的检测逻辑并非仅通过线程名识别环境，而是基于进程PID、父进程关系等元数据做判断，仅修改线程名无法绕开检测。

方案1：最小改动方案——显式指定joblib并行后端 #

仅需修改tasks.py的任务代码，在GridSearchCV执行阶段用joblib的线程后端做并行，完全绕开loky的嵌套进程检测，不需要调整Celery的核心配置：

from celery import shared_task
from joblib import parallel_backend
from sklearn.svm import SVC
from sklearn.model_selection import GridSearchCV

@shared_task
def Pipeline(taskId):
  # ... 保留原有读文件、预处理、数据集拆分逻辑
  
  # 用线程后端执行GridSearch并行计算，绕开loky的进程检测
  with parallel_backend('threading', n_jobs=-1):
    clf = GridSearchCV(
        SVC(), paramGrid, cv=5, n_jobs=-1
    )
    clf.fit(XTrain, yTrain)
  
  # ... 保留原有指标计算、数据库更新逻辑

补充说明：SVC的底层计算为C语言实现的线性代数运算，执行阶段会释放Python GIL，使用线程后端的并行效率与loky后端基本一致，且不会触发嵌套进程检测警告。

方案2：单任务极致性能方案——调整Celery执行池为solo模式 #

如果当前场景下一次只需要跑一个大计算量任务，不需要多任务并发，可以直接将Celery的任务执行池改为solo模式，从根源上消除外层多进程环境，让joblib正常识别为主进程环境，自动启用多核心并行。
改动仅需在Django的settings.py中追加Celery配置：

# Django settings 中追加配置
CELERY_WORKER_POOL = 'solo'

该配置下不需要修改任务代码，原有n_jobs=-1的设置就能正常生效。注意：solo模式下Celery同一时间只能处理一个任务，适合单任务计算量远大于并发任务数的场景。

方案3：兼顾并发的调整方案——指定joblib启动规则 #

如果既需要Celery多worker并发处理多个任务，又需要单任务内的多核心并行，可以在Celery worker启动前设置对应的环境变量，修改joblib的启动检测规则：
启动Celery worker的命令调整为：

export JOBLIB_WORKER_NESTED=1
celery -A backend worker -l info

该配置可以让joblib允许在嵌套进程环境中启动并行循环，不需要修改原有任务代码。

配置完成后启动Celery worker执行任务，检查两个验证点即可确认问题解决：

• 任务运行时日志不再出现Loky-backed parallel loops cannot be called in a multiprocessing, setting n_jobs=1的警告
• 系统监控中可以看到计算阶段的CPU利用率接近核心总数的满载水平

内容的提问来源于stack exchange，提问作者mahieyin-rahmun