GridSearchCV 默认不支持多卡，n_jobs仅实现CPU多进程并行；真正多卡需用torch.distributed/deepspeed自建分布式训练或optuna+ray跨卡调度，XGBoost/LightGBM的GPU设置与n_jobs冲突，应设n_jobs=1。
GridSearchCV 默认不支持多卡，n_jobs 只能用多进程跑 CPU
很多人一看到 GridSearchCV 的 n_jobs 参数，就以为设成 -1 就能自动上 GPU 多卡。其实完全不是——sklearn 本身是纯 CPU 框架，n_jobs 调用的是 joblib 的多进程，只并行在 CPU 上训练模型，哪怕你用的是 XGBoost 或 LightGBM 的 GPU 版本，也仅限单卡（除非模型内部自己实现了多卡通信）。所以“多卡加速 GridSearchCV”本质是绕过 sklearn 的调度，自己控制训练流程。
真正可行的多卡方案：用 torch.distributed 或 deepspeed 自建分布式训练循环
如果你的模型是 PyTorch 写的（比如自定义的 MLP、Transformer），想用多张 GPU 并行评估不同超参组合，就得放弃 GridSearchCV，改用手动分片 + 分布式启动：
- 把参数网格拆成若干子集（例如每张卡分 4 组），用
torch.distributed.launch或torchrun启动多个进程 - 每个进程加载一个子集，在本地 GPU 上独立训练/验证，结果写入共享文件（如 JSON）或数据库
- 主进程汇总所有结果，模拟
cv_results_结构
注意：不能直接在 fit() 里塞 model.cuda(1) 这类硬编码设备号——得用 torch.cuda.set_device(local_rank) 配合 DDP，否则会抢显存或报 device mismatch 错误。
轻量替代方案：用 optuna + ray 实现跨卡任务调度
如果不想重写训练逻辑，optuna 搭配 ray 是更现实的选择——它不依赖模型是否支持 DDP，而是把每次 trial 当作一个独立任务提交给 ray cluster：
立即学习“Python免费学习笔记（深入）”；
- 先用
ray.init(address="auto")连接已启动的多节点 ray 集群（每张 GPU 对应一个ray start --resources='{"gpu":1}'节点） - 定义一个
@ray.remote(num_gpus=1)的训练函数，里面封装你的模型 fit 和 score 流程 -
optuna.study.Study调用optimize()时，底层由 ray 分发到空闲 GPU 节点执行
缺点是无法复用 GridSearchCV 的 CV 折叠逻辑和 scoring 接口，你需要手动实现 k 折验证；另外 ray 的序列化开销对小模型可能反而变慢。
别踩坑：XGBoost/LightGBM 的 GPU 设置和 n_jobs 冲突
有人试过给 XGBRegressor(tree_method="gpu_hist", n_gpus=2) 加 n_jobs=2，结果报错或卡死。这是因为：
-
tree_method="gpu_hist"本身已启用单卡多线程，n_gpus=2在 XGBoost 1.7+ 才支持真正的多卡（需 CUDA 11.2+ 且两张卡在同一个 PCIe Root Complex 下） -
n_jobs控制的是 sklearn 层面的并行度，和 XGBoost 内部 GPU 调度无关；两者混用会导致线程竞争显存，常见错误是CUDA_ERROR_OUT_OF_MEMORY或thrust::system::system_error - 正确做法是：固定
n_jobs=1，专注调n_estimators、max_depth等参数，让 XGBoost 自己管 GPU
多卡加速这件事，核心不在“怎么包装 GridSearchCV”，而在于“谁来负责调度 GPU 资源”——sklearn 不管，得你自己选 runtime（ray / torch.distributed / horovod）并暴露参数接口。不然光改 n_jobs，永远只在 CPU 上打转。
