LGBM结合RandomizedSearchCV内存占用高、运行慢的原因及优化方法

• 两层并行嵌套导致内存暴涨：你在RandomizedSearchCV中设置了n_jobs=-1，会调用全部CPU核心并行运行交叉验证任务，而LGBM本身默认开启多线程训练，两层全核心并行叠加后，内存中会同时存在多份模型副本、数据副本，总占用是单模型训练的数倍，16GB内存很容易被占满。
• 超参数搜索范围设置极不合理：你设置的num_leaves上限高达3000、max_depth最高到50甚至开放无限制（-1）、min_data_in_leaf下限为0，这类参数组合会生成结构极其庞大的树模型，单模型内存占用是常规参数下的数十倍；同时搜索范围包含0.0001的极低学习率，配合5000的最大树数量，触发早停前需要训练上千棵树，耗时会成倍增长。
• 验证逻辑额外增加开销：你选用的auc_mu是多分类AUC指标，计算复杂度远高于常规的多分类对数损失；且全局固定eval_set为外部测试集，和3折交叉验证的拆分逻辑冲突，既会引入数据泄露，也会增加不必要的计算和内存占用。
• 并行任务调度无内存限制：默认配置下RandomizedSearchCV会把所有待运行的交叉验证任务数据一次性加载进内存，进一步推高内存占用。

• 解决并行嵌套冲突：二选一调整并行配置即可：要么将RandomizedSearchCV的n_jobs设为2~4（不要开满全部核心），保留LGBM默认的多线程配置；要么将LGBM的n_jobs设为1，再开启RandomizedSearchCV的全核心并行，避免两层并行叠加带来的内存翻倍问题。
• 收窄不合理的超参数搜索区间：
  • num_leaves搜索范围调整为sp_randint(20, 200)，3000的上限完全没有必要，LGBM常规场景下该值设为30~150就可以满足精度需求，过大的值只会带来过拟合和内存浪费。
  • max_depth去掉50和-1的选项，保留3~12的区间即可，过深的树不仅占内存还会严重过拟合。
  • min_data_in_leaf下限调整为20，去掉0的取值，避免生成过细的叶子节点导致树结构爆炸。
  • 首轮随机搜索去掉0.0001的学习率选项，仅保留0.01、0.05、0.1三个档位，等筛选出较优参数区间后，再调低学习率、增加树数量做精调。
• 降低调参过程的计算开销：
  • 在RandomizedSearchCV中增加pre_dispatch=2参数，限制同一时间最多并行运行2个任务，不会把所有任务的数据一次性加载进内存，内存占用可下降50%以上。
  • 首轮调参将评估指标换成multi_logloss，auc_mu计算速度比logloss慢3~5倍，等筛选出最优参数后再换用auc_mu做最终微调即可。
  • 首轮快速筛参可以把CV折数从3暂时改成2，等缩小参数范围后再换回3折做精调，总耗时可以减少三分之一。
  • 修正fit_params的验证集传参逻辑，不要固定传入外部测试集作为早停验证集，避免数据泄露和额外内存开销。
• 针对性做内存优化：
  • 将训练集、测试集的浮点型数据从默认的float64强转为float32，数据内存直接减半，对LGBM的精度几乎没有影响。
  • 调参阶段将RandomizedSearchCV的refit设为False，等拿到最优参数后，再单独用全量训练集训练最终模型，省掉调参阶段自动重训的额外开销。
  • 初始化LGBM模型时可以增加histogram_pool_size=1024参数，限制直方图构建阶段的最大内存占用为1GB，避免内存无限制上涨。
• 更高效率的调参替代：如果调整后速度还是达不到要求，可以替换调参工具，使用Optuna或者LGBM自带的CV接口做超参数搜索，相比sklearn的RandomizedSearchCV内存占用低30%以上，还支持参数剪枝功能，碰到效果差的参数组合可以提前终止，不用跑完所有迭代轮次，速度提升明显。

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