为什么Optuna已生成trial 2全部超参数仍长时间卡住？

算力阿峰

2026-9-26

问题原因分析

Dart booster计算复杂度高：卡住的trial_id=3选择了booster分类中索引为2的dart提升器，相比你前两次试验用的gblinear，dart自带的dropout机制会让训练速度下降3~10倍，搭配7700的高迭代次数、10倍并行树配置，计算量陡增。
嵌套并行导致资源冲突/死锁：代码中同时开启了两层多进程：XGBoost参数设置n_jobs=10，交叉验证cross_val_score又设置n_jobs=-1，两层并行会争抢CPU资源，很容易出现进程死锁，导致程序无响应。
早停机制未生效：你在XGBoost参数中配置的early_stopping_rounds没有对应传入验证集，cross_val_score默认不支持早停逻辑，所以7700棵树会完整训练完成，不会提前终止，进一步拉长训练时间。
交叉验证计算量过大：20折交叉验证本身的计算量是常用5折的4倍，单轮trial需要训练20个完整的XGBoost模型，叠加前面的高复杂度参数，运行时间超过4小时属于合理的性能溢出，并非程序异常。

对应解决方法

修复嵌套并行问题：只保留一层并行即可，两种方案二选一：
1. 把XGBoost的n_jobs设为1，cross_val_score保持n_jobs=-1，并行跑不同折的验证
2. 把cross_val_score的n_jobs设为1，XGBoost的n_jobs设为CPU核心数，并行跑单模型的训练

启用有效早停逻辑：替换默认的cross_val_score，手写交叉验证循环，每折拆分训练/验证子集，传入XGBoost的eval_set参数触发早停，示例核心代码如下：

kf = KFold(n_splits=10, shuffle=True, random_state=16)
mse_list = []
for train_idx, val_idx in kf.split(X_train):
    X_tr, X_val = X_train.iloc[train_idx], X_train.iloc[val_idx]
    y_tr, y_val = log_y_train.iloc[train_idx], log_y_train.iloc[val_idx]
    model = XGBRegressor(**params)
    model.fit(X_tr, y_tr, eval_set=[(X_val, y_val)], verbose=False)
    mse_list.append(mean_squared_error(y_val, model.predict(X_val)))
return np.mean(mse_list)

添加trial超时限制：调用study.optimize时添加timeout参数限制单trial最长运行时间，同时开启gc_after_trial=True清理内存，避免无效卡死，示例配置：
```
study.optimize(objective, n_trials=100, timeout=1800, gc_after_trial=True)
```
上述配置代表单trial最多运行30分钟，超时自动终止标记为失败，不会阻塞后续试验。
降低不必要的计算量：如果数据集规模大于1万条，可将20折交叉验证改为5_{10折，验证结果稳定性不会有明显下降，同时计算量降低2}4倍；也可缩小n_estimators的搜索上限，结合早停基本不需要用到10000的迭代次数。
清理卡住的试验重启任务：先执行SQL命令修改数据库中卡住的trial状态为失败，再重新运行代码即可，不会重复执行已经完成的试验：
```
UPDATE trials SET state = 'FAIL' WHERE trial_id = 3;
```

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