Sklearn StackingClassifier运行缓慢且CPU利用率异常问题咨询

原因分析与解决方案 #

1. 嵌套并行引发资源竞争 #

Sklearn的cross_val_score的n_jobs与基学习器/最终学习器的n_jobs形成嵌套并行，导致线程/进程竞争、切换开销剧增，反而降低效率：

• 外层cross_val_score设置n_jobs=4，同时基学习器LightGBM设n_jobs=4，多层并行会导致CPU资源被过度拆分，无法高效利用。

解决办法：
选择单一维度并行，避免嵌套：

# 方案1：外层cross_val_score禁用并行，保留基学习器的并行设置
scores = cross_val_score(clf, X, y, scoring='accuracy', cv=cv, n_jobs=1, error_score='raise')

# 方案2：基学习器禁用并行，保留外层cross_val_score的并行设置
lgbm = ltb.LGBMClassifier(n_jobs=1)
rf = RandomForestClassifier(n_jobs=1)

2. 代码笔误修正 #

estimators列表中第二个元素的键为'lgbm,'（多了一个逗号），虽不直接影响速度，但可能引发潜在问题，建议修正为：

estimators = [
     ('rf', rf),
     ('lgbm', lgbm)
     ]

3. Stacking实际计算量远超预期 #

你的预期耗时严重低估了Stacking的计算逻辑：

• 每个基学习器需要在内层K折交叉验证中训练K次，生成元特征（这部分是基学习器单独训练的K倍耗时）
• 最终学习器需要用元特征（+原始特征，因passthrough=True）训练一次
• 外层的cross_val_score又会对整个Stacking模型做10折交叉验证，相当于整个流程重复10次

实际计算量公式为：
10（外层CV） × [ (10（内层CV）× (RF训练耗时 + LGBM训练耗时)) + LGBM最终训练耗时 ]

这才是耗时剧增的核心原因。

4. CPU利用率波动的根源 #

嵌套并行导致进程/线程频繁切换、资源竞争，使得CPU无法持续满负载；同时Stacking内部不同阶段的计算量不均衡（生成元特征与最终训练阶段），也会引发利用率波动。

优化建议 #

• 控制并行层级：仅在单一维度（外层CV或基学习器）开启并行，避免嵌套竞争
• 调整CV折数：平衡精度与速度，比如将内层或外层CV折数从10降至5
• 关闭冗余特征传递：若原始特征与元特征无互补价值，设置passthrough=False减少最终学习器的训练维度
• 手动实现Stacking：预计算基学习器的元特征，再训练最终学习器，更灵活地控制并行与计算流程，规避Sklearn Stacking的嵌套开销

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