企业官网建设流程全解析

1. 项目概述：为什么 PyTorch + Optuna 是当前超参调优的“黄金组合”

在实际跑模型时，我见过太多人把时间花在改网络结构、换数据增强上，结果发现模型性能卡在某个瓶颈动弹不得——最后排查一圈，问题出在学习率设成了0.01，而最优值其实是0.0037；或者 batch size 硬扛32导致显存溢出，其实16配合适当梯度累积反而收敛更快。这些不是玄学，是超参数（hyperparameter）没调好。PyTorch 本身不提供系统化的超参搜索能力，torch.optim只管优化模型权重，不管学习率、weight decay、dropout 概率这些“控制优化过程的参数”。这时候，Optuna 就成了最务实的选择：它不是另一个深度学习框架，而是一个专为“实验性搜索”设计的自动化调优引擎，和 PyTorch 的耦合方式干净得像插拔U盘——你完全不用动训练主循环逻辑，只需在训练函数里加几行定义空间、返回指标的代码，剩下的交给 Optuna 的采样策略和剪枝机制。关键词PyTorch、Optuna、hyperparameter optimization、neural network tuning、automated ML在这个场景下不是空泛标签，而是真实工作流中的技术锚点。它适合三类人：刚从Keras转过来、对model.fit()式封装有依赖但又想深入控制训练细节的工程师；需要在有限GPU资源下快速验证多个模型变体效果的研究者；还有带学生做课程项目的高校教师——因为Optuna的study对象可序列化保存，学生交作业时能直接附上.pkl文件证明调优过程，而不是只交一个“调好了”的checkpoint。它解决的不是“能不能训”，而是“在同样算力下，能不能训得更稳、更快、更准”。这不是锦上添花，是模型落地前绕不开的临门一脚。

2. 整体设计思路与方案选型逻辑

2.1 为什么不是 GridSearch 或 RandomSearch？

很多人第一反应是用 scikit-learn 风格的GridSearchCV，但直接套在 PyTorch 上会踩三个坑：第一，GridSearchCV要求模型实现fit()/predict()接口，而 PyTorch 的nn.Module是纯计算图，没有内置的训练流程封装；第二，它默认按全量数据交叉验证，对图像或NLP大模型来说，一次5折CV就是5倍训练时间，显存和IO压力陡增；第三，网格搜索穷举所有组合，在4个参数各取5个值时就产生625次试验，其中大量组合（比如 learning_rate=1e-6 + weight_decay=0.9）根本无法收敛，纯属浪费。RandomSearch 好一点，但仍是无状态的随机采样，不会根据前期试验结果动态调整后续采样方向。我去年帮一个医疗影像团队调ResNet50分割模型，他们先用RandomSearch跑了80次试验，AUC提升仅0.008；换成Optuna后，同样80次试验内AUC提升了0.023，关键在于Optuna的TPE（Tree-structured Parzen Estimator）算法能从失败试验中学习：“learning_rate < 1e-4 且 dropout > 0.5 的组合全部发散”，于是后续采样自动避开这片“死亡区域”。

2.2 为什么不是 Ray Tune 或 Katib？

Ray Tune 和 Kubernetes 原生的 Katib 确实支持分布式超参搜索，但它们的部署成本和学习曲线是另一回事。Ray Tune 要求启动Ray集群，配置ray.init()，处理actor间通信；Katib 则需先部署Kubeflow，写YAML定义实验模板，再通过API提交。而Optuna的核心优势在于“单机优先，扩展透明”：你在笔记本上写的study.optimize(objective, n_trials=100)，只要加一行storage="sqlite:///db.sqlite3"，就能无缝切换到多进程模式（n_jobs=-1），甚至对接PostgreSQL做团队共享存储。我们实验室有台8卡A100服务器，之前用Ray Tune调度任务，经常因worker进程OOM被Killed；换成Optuna的RDBStorage后，用psutil监控发现内存占用稳定在1.2GB，因为Optuna本身不加载模型，只管理试验元数据（参数、指标、状态），真正的训练进程由用户代码完全掌控。这种“控制权在我，调度权在它”的分工，让调试变得极其直观——某次试验崩溃，直接看对应trial_id的日志文件就行，不用在Ray dashboard里翻半天traceback。

2.3 为什么不是 Hyperopt？

Hyperopt 也是基于TPE的老牌库，但它和PyTorch的集成存在两个硬伤：第一，fmin()函数要求目标函数返回标量损失，而PyTorch训练常需监控验证集准确率、F1、Dice系数等正向指标，Hyperopt默认最小化，要绕弯子写return -val_acc；第二，它的搜索空间定义语法（hp.uniform('lr', 1e-5, 1e-2)）不如Optuna的trial.suggest_float('lr', 1e-5, 1e-2, log=True)语义清晰，尤其对离散参数如'optimizer': ['adam', 'sgd']，Optuna用suggest_categorical直接返回字符串，Hyperopt却要映射索引再查表。更重要的是，Optuna原生支持Pruning（剪枝）：当某次试验的验证损失连续3个epoch没改善，就主动中止，把GPU资源让给更有希望的试验。我们在训练一个BERT微调任务时，启用MedianPruner(n_startup_trials=5, n_warmup_steps=3)后，平均每次试验耗时从22分钟降到14分钟，因为约35%的劣质组合在第4个epoch就被kill了，这部分时间直接省下来喂给优质组合。

2.4 整体架构设计：解耦训练与搜索

Optuna 的核心哲学是“Objective Function First”。整个方案被拆成三个物理隔离层：

• 底层训练模块（train.py）：纯PyTorch代码，包含train_epoch()、validate()、save_checkpoint()等函数，完全不感知Optuna存在；
• 目标函数层（objective.py）：唯一引入optuna的文件，定义def objective(trial):，负责从trial对象采样参数、初始化模型/优化器、调用底层训练函数、返回验证指标；
• 调度管理层（run_study.py）：创建Study对象，设置存储后端、采样器、剪枝器，调用optimize()。

这种设计带来三个实际好处：第一，train.py可独立单元测试，比如用mock数据验证loss计算是否正确；第二，目标函数可复用于其他搜索库（如转换为Ax的@metric装饰器）；第三，当需要人工干预时（比如发现某组参数特别好），直接在objective.py里加print(f"Best params: {trial.params}")，比在Ray Tune的tune.report()里找日志方便十倍。我坚持不用任何“全自动封装库”（如optuna.integration.PyTorchLightningPruningCallback），因为隐藏的抽象层会在debug时制造黑箱——曾经有同事调一个Transformer模型，pruning总不生效，最后发现是callback里默认监控'val_loss'，而他的LightningModule里log的是'val/loss'，路径不匹配导致剪枝逻辑被跳过。自己写if val_loss > best_loss * 1.05: raise optuna.TrialPruned()，虽然多敲5行，但每一行都在掌控之中。

3. 核心细节解析与实操要点

3.1 搜索空间设计：不是“越多越好”，而是“精准打击”

搜索空间定义是调优效果的天花板。新手常犯的错误是把所有能想到的参数都扔进去：学习率、weight decay、dropout、batch size、optimizer类型、scheduler类型、warmup步数……结果试验爆炸式增长，且多数组合无效。我的经验是遵循“3+1原则”：3个高敏感度参数必调，1个低敏感度参数选调。高敏感度参数指那些对loss曲面形状影响剧烈的，比如学习率（决定优化步长）、weight decay（控制过拟合强度）、dropout率（调节模型容量）。以图像分类为例，我通常固定batch_size=32（显存允许前提下），只调lr、wd、dropout_p。具体范围设定必须结合领域知识：

• lr：CNN常用1e-4到1e-2，但用AdamW时，1e-3常是安全起点；若用SGD with momentum，1e-2更常见。不能简单设[1e-5, 1e-1]，因为1e-1大概率导致梯度爆炸，1e-5则收敛极慢。我习惯用log=True让采样在对数尺度均匀分布，这样1e-4、3e-4、1e-3被采样概率相同；
• wd：L2正则强度，经典范围1e-4到1e-2，但现代模型（如Vision Transformer）常用0.05，所以我会设[1e-4, 0.1]并log=True；
• dropout_p：全连接层丢弃率，0.1到0.5足够，0.7以上模型基本不学，所以设[0.1, 0.5]线性采样。

对于离散参数，如optimizer，不要写['adam', 'adamw', 'sgd']然后suggest_categorical，因为adam和adamw本质相似，应合并为“自适应优化器”和“动量优化器”两类，再细分：

optimizer_name = trial.suggest_categorical("optimizer", ["adamw", "sgd"]) if optimizer_name == "adamw": lr = trial.suggest_float("lr", 1e-5, 1e-2, log=True) weight_decay = trial.suggest_float("weight_decay", 1e-4, 0.1, log=True) else: # sgd lr = trial.suggest_float("lr", 1e-3, 1e-1, log=True) # SGD需要更大lr momentum = trial.suggest_float("momentum", 0.8, 0.99)

这种条件采样（conditional sampling）让搜索空间更紧凑，避免sgd配1e-5这种无效组合。

3.2 目标函数编写：如何让Optuna“看懂”你的训练

目标函数是Optuna和PyTorch的唯一接口，必须满足三个硬性要求：可重复、可中断、可度量。

• 可重复：每次调用objective(trial)必须产生确定性结果。这意味着不能在函数内初始化全局随机种子（如torch.manual_seed(42)），因为Optuna可能并发运行多个trial，种子冲突会导致结果混乱。正确做法是在objective开头生成trial专属种子：

  def objective(trial): # 为本次trial生成唯一seed seed = trial.number * 1000 + 42 torch.manual_seed(seed) np.random.seed(seed) random.seed(seed) # 后续所有随机操作（数据打乱、augmentation）都基于此seed

  这样每个trial的随机性独立，且可通过trial.number追溯。
• 可中断：训练中途崩溃不能让整个study失效。Optuna要求目标函数抛出Exception时，自动标记该trial为FAIL并继续下一个。但PyTorch的CUDA out of memory错误是RuntimeError，会被Optuna捕获为失败，这没问题；真正危险的是静默失败，比如数据加载器死锁。我在objective里强制加入超时保护：

  from contextlib import contextmanager import signal @contextmanager def timeout(seconds): def timeout_handler(signum, frame): raise TimeoutError(f"Trial {trial.number} timed out after {seconds}s") signal.signal(signal.SIGALRM, timeout_handler) signal.alarm(seconds) try: yield finally: signal.alarm(0) try: with timeout(3600): # 1小时超时 final_val_acc = train_and_evaluate(model, dataloaders, config) return final_val_acc except (TimeoutError, RuntimeError, KeyboardInterrupt) as e: print(f"Trial {trial.number} failed: {e}") raise optuna.TrialPruned() # 主动剪枝，而非FAIL

• 可度量：返回值必须是标量，且Optuna默认最小化。如果监控验证准确率（越大越好），必须返回负值：return -val_acc。但更推荐用direction="maximize"创建study，这样代码更直觉：

  study = optuna.create_study( direction="maximize", # 明确声明最大化准确率 storage="sqlite:///study.db", load_if_exists=True )

  此时objective直接return val_acc，避免负号带来的思维负担。

3.3 Pruning（剪枝）机制：如何让无效试验“优雅退场”

Pruning不是可选项，而是必需项，尤其当单次试验耗时超过10分钟时。Optuna提供多种剪枝器，我最常用的是MedianPruner和SuccessiveHalvingPruner。

• MedianPruner(n_startup_trials=5, n_warmup_steps=3)：前5次试验不剪枝（确保有基准），之后每3个step检查一次。它计算所有已完成trial在当前step的指标中位数，如果当前trial的指标比中位数差20%以上，则剪枝。例如，10个trial在step 100的val_acc中位数是0.85，而trial 12在step 100只有0.68，则触发剪枝。
• SuccessiveHalvingPruner(min_resource=10, reduction_factor=3)：更适合长周期训练。它把资源（如epoch数）分层，第一层所有trial跑10个epoch，淘汰bottom-2/3；剩余trial跑30个epoch（10×3），再淘汰；依此类推。这模拟了“先粗筛再精调”的人类策略。

但剪枝有个致命陷阱：指标波动性。分类任务的val_acc在early epoch常有±5%抖动，如果n_warmup_steps设太小（如1），可能把潜力股误杀。我的实测经验是：

• 对于<50 epoch的训练，n_warmup_steps=5；
• 对于50~200 epoch，n_warmup_steps=10；
• 对于>200 epoch（如预训练），必须用SuccessiveHalvingPruner，min_resource=20。

另外，剪枝判断必须基于平滑后指标。原始val_acc每epoch波动大，我通常用指数移动平均（EMA）：

ema_val_acc = 0.9 * ema_val_acc + 0.1 * current_val_acc if step % 10 == 0: # 每10个step报告一次EMA值 trial.report(ema_val_acc, step) if trial.should_prune(): raise optuna.TrialPruned()

trial.report()是关键，它告诉Optuna“我在step X达到指标Y”，should_prune()据此决策。不调用report，剪枝器永远收不到信号。

3.4 Study存储与可视化：让调优过程“可审计、可复现”

本地开发时用"sqlite:///study.db"足够，但团队协作必须升级。我推荐PostgreSQL，因为：

• 支持并发写入，多台机器同时optimize()不会锁表；
• 可用pg_dump一键备份整个study历史；
• 配合optuna-dashboard，开个网页就能看实时进度。

部署步骤极简：

# 1. 启动PostgreSQL容器（Docker） docker run -d --name optuna-db -e POSTGRES_PASSWORD=optuna -p 5432:5432 -v $(pwd)/pgdata:/var/lib/postgresql/data postgres:13 # 2. 创建study（Python） import optuna study = optuna.create_study( study_name="resnet50_medical", storage="postgresql://postgres:optuna@localhost:5432/optuna", load_if_exists=True, direction="maximize" )

可视化方面，optuna.visualization模块提供10+种图表，但最实用的是：

• plot_optimization_history(study)：看优化曲线是否收敛，如果50次试验后还在爬坡，说明n_trials设小了；
• plot_parallel_coordinate(study)：交互式平行坐标图，拖动轴可筛选参数组合，快速定位“高acc+低lr”区域；
• plot_param_importances(study)：计算每个参数对指标方差的贡献度，比如plot_param_importances显示lr贡献度72%，dropout_p仅8%，说明后续可固定dropout_p=0.3，专注调lr和wd。

提示：plot_param_importances需要至少20次成功trial才能可靠计算，少于这个数会报ValueError。我习惯在run_study.py里加检查：

if len(study.trials_dataframe().query("state == 'COMPLETE'")) < 20: print("Warning: <20 complete trials, param importance plot may be unreliable")

4. 实操过程与核心环节实现

4.1 完整代码实现：从零搭建可运行的调优Pipeline

以下是一个生产级可用的完整实现，已去除所有平台依赖，仅需PyTorch 1.12+和Optuna 3.0+。目录结构清晰：

project/ ├── train.py # 核心训练逻辑 ├── objective.py # Optuna目标函数 ├── run_study.py # 启动调优 └── config.py # 全局配置（数据路径、设备等）

config.py：统一管理硬编码路径，避免在多个文件里散落

import os DATA_ROOT = "/data/imagenet" # 修改为你自己的数据路径 MODEL_SAVE_DIR = "./checkpoints" LOG_DIR = "./logs" os.makedirs(MODEL_SAVE_DIR, exist_ok=True) os.makedirs(LOG_DIR, exist_ok=True)

train.py：纯PyTorch，无Optuna痕迹

import torch import torch.nn as nn import torch.optim as optim from torch.utils.data import DataLoader from torchvision import models, transforms from config import DATA_ROOT, MODEL_SAVE_DIR import logging def get_dataloaders(batch_size=32): """返回train/val dataloader，使用标准ImageNet预处理""" train_transform = transforms.Compose([ transforms.RandomResizedCrop(224), transforms.RandomHorizontalFlip(), transforms.ToTensor(), transforms.Normalize([0.485, 0.456, 0.406], [0.229, 0.224, 0.225]) ]) val_transform = transforms.Compose([ transforms.Resize(256), transforms.CenterCrop(224), transforms.ToTensor(), transforms.Normalize([0.485, 0.456, 0.406], [0.229, 0.224, 0.225]) ]) train_dataset = datasets.ImageFolder(f"{DATA_ROOT}/train", train_transform) val_dataset = datasets.ImageFolder(f"{DATA_ROOT}/val", val_transform) return { "train": DataLoader(train_dataset, batch_size=batch_size, shuffle=True, num_workers=4), "val": DataLoader(val_dataset, batch_size=batch_size, shuffle=False, num_workers=4) } def train_epoch(model, dataloader, criterion, optimizer, device): model.train() total_loss = 0 for inputs, labels in dataloader: inputs, labels = inputs.to(device), labels.to(device) optimizer.zero_grad() outputs = model(inputs) loss = criterion(outputs, labels) loss.backward() optimizer.step() total_loss += loss.item() return total_loss / len(dataloader) def validate(model, dataloader, device): model.eval() correct = 0 total = 0 with torch.no_grad(): for inputs, labels in dataloader: inputs, labels = inputs.to(device), labels.to(device) outputs = model(inputs) _, predicted = torch.max(outputs.data, 1) total += labels.size(0) correct += (predicted == labels).sum().item() return 100 * correct / total def train_and_evaluate(model, dataloaders, config, trial=None): """主训练函数，支持trial传入用于pruning""" device = torch.device("cuda" if torch.cuda.is_available() else "cpu") model = model.to(device) criterion = nn.CrossEntropyLoss() optimizer = getattr(optim, config["optimizer"])( model.parameters(), lr=config["lr"], weight_decay=config["weight_decay"] ) if config["optimizer"] == "sgd": optimizer = optim.SGD( model.parameters(), lr=config["lr"], momentum=config.get("momentum", 0.9), weight_decay=config["weight_decay"] ) best_val_acc = 0.0 ema_val_acc = 0.0 for epoch in range(config["num_epochs"]): train_loss = train_epoch(model, dataloaders["train"], criterion, optimizer, device) val_acc = validate(model, dataloaders["val"], device) ema_val_acc = 0.9 * ema_val_acc + 0.1 * val_acc # Pruning check every 5 epochs if trial is not None and epoch % 5 == 0: trial.report(ema_val_acc, epoch) if trial.should_prune(): raise optuna.TrialPruned() if val_acc > best_val_acc: best_val_acc = val_acc torch.save(model.state_dict(), f"{MODEL_SAVE_DIR}/best_trial_{trial.number}.pth") logging.info(f"Epoch {epoch}: Train Loss={train_loss:.4f}, Val Acc={val_acc:.2f}%") return best_val_acc

objective.py：Optuna的“心脏”

import torch import torch.nn as nn from torchvision import models from train import train_and_evaluate, get_dataloaders from config import LOG_DIR import logging import os def objective(trial): # 1. 设置专属随机种子 seed = trial.number * 1000 + 42 torch.manual_seed(seed) import numpy as np np.random.seed(seed) import random random.seed(seed) # 2. 定义搜索空间 model_name = trial.suggest_categorical("model", ["resnet18", "efficientnet_b0"]) if model_name == "resnet18": model = models.resnet18(pretrained=True) model.fc = nn.Linear(model.fc.in_features, 1000) # ImageNet类别数 else: model = models.efficientnet_b0(pretrained=True) model.classifier[1] = nn.Linear(model.classifier[1].in_features, 1000) # 高敏感参数 lr = trial.suggest_float("lr", 1e-5, 1e-2, log=True) weight_decay = trial.suggest_float("weight_decay", 1e-4, 0.1, log=True) dropout_p = trial.suggest_float("dropout_p", 0.1, 0.5) # 优化器选择（条件采样） optimizer_name = trial.suggest_categorical("optimizer", ["adamw", "sgd"]) if optimizer_name == "adamw": pass # lr, wd已定义 else: # sgd lr = trial.suggest_float("lr_sgd", 1e-3, 1e-1, log=True) momentum = trial.suggest_float("momentum", 0.8, 0.99) # 3. 构建配置字典 config = { "model": model_name, "optimizer": optimizer_name, "lr": lr, "weight_decay": weight_decay, "dropout_p": dropout_p, "num_epochs": 30, "batch_size": 32 } if optimizer_name == "sgd": config["momentum"] = momentum # 4. 加载数据（注意：dataloaders创建放在这里，确保每次trial独立） dataloaders = get_dataloaders(batch_size=config["batch_size"]) # 5. 训练并返回指标 try: val_acc = train_and_evaluate(model, dataloaders, config, trial) return val_acc except Exception as e: logging.error(f"Trial {trial.number} failed: {e}") raise optuna.TrialPruned()

run_study.py：启动入口

import optuna from objective import objective from optuna.pruners import MedianPruner from optuna.samplers import TPESampler if __name__ == "__main__": # 创建study，使用PostgreSQL（若本地用sqlite，改storage即可） study = optuna.create_study( study_name="imagenet_tuning", storage="sqlite:///study.db", # 本地开发用 # storage="postgresql://postgres:optuna@localhost:5432/optuna", # 生产用 load_if_exists=True, direction="maximize", sampler=TPESampler(seed=42), # 固定采样器种子，保证可复现 pruner=MedianPruner( n_startup_trials=10, # 前10次不剪枝 n_warmup_steps=5, # 5个epoch后开始监控 interval_steps=1 # 每1个epoch检查一次 ) ) # 开始优化 study.optimize( objective, n_trials=100, n_jobs=4, # 使用4个进程并行（根据GPU数调整） show_progress_bar=True ) # 输出最佳结果 print("Number of finished trials: ", len(study.trials)) print("Best trial:") print(" Value: ", study.best_value) print(" Params: ") for key, value in study.best_params.items(): print(" {}: {}".format(key, value)) # 保存study供后续分析 joblib.dump(study, "final_study.pkl")

运行命令：

python run_study.py

首次运行会创建study.db，后续load_if_exists=True自动续跑。n_jobs=4表示4个trial并发，如果你有4块GPU，可在objective.py里加device = f"cuda:{trial.number % 4}"实现GPU轮询分配。

4.2 参数重要性分析：用数据驱动下一步调优

当100次试验完成后，study对象包含全部元数据。最关键的洞察来自param_importance：

import optuna study = joblib.load("final_study.pkl") fig = optuna.visualization.plot_param_importances(study) fig.write_html("param_importance.html") # 保存为交互式HTML

假设输出图表显示：

这说明lr是绝对主导因素，weight_decay次之，其余可视为噪声。此时应执行空间收缩（space contraction）：固定dropout_p=0.3、optimizer="adamw"，重新定义搜索空间：

# 新的目标函数片段 def objective_constrained(trial): lr = trial.suggest_float("lr", 1e-4, 5e-3, log=True) # 范围收紧 weight_decay = trial.suggest_float("weight_decay", 5e-4, 0.05, log=True) # dropout_p和optimizer固定 config = { "lr": lr, "weight_decay": weight_decay, "dropout_p": 0.3, "optimizer": "adamw" } # ... rest same

然后用n_trials=50快速精调。我实测过，在ResNet50上，首轮100次宽泛搜索找到lr≈3e-4，第二轮50次聚焦搜索将lr锁定在2.7e-4到3.2e-4，最终val_acc提升0.15%，这0.15%在医疗诊断模型中可能意味着假阴性率下降12%。

4.3 多目标优化：当准确率和速度不可兼得

现实场景常需平衡多个指标，比如“既要高准确率，又要低推理延迟”。Optuna原生支持多目标，但需谨慎使用。假设我们想同时最大化val_acc和最小化inference_time_ms：

def objective_multi(trial): # ... 参数采样同上 val_acc, inf_time = train_and_evaluate_multi(model, dataloaders, config) return val_acc, inf_time # 返回tuple study = optuna.create_study( directions=["maximize", "minimize"], # 明确指定每个目标方向 sampler=NSGAIISampler() # 必须用NSGA-II等多目标采样器 )

但多目标会产生Pareto前沿（非支配解集），比如：

没有单一“最佳”，需业务方拍板。我的建议是：先单目标，再加约束。比如先以val_acc为目标，找到top5组合；再在这些组合中，选inf_time < 10ms的最优者。这样逻辑清晰，避免多目标带来的决策瘫痪。

5. 常见问题与排查技巧实录

5.1 “Trial一直FAIL，日志显示CUDA error: out of memory”

这是最高频问题。表面是显存不足，根因常是batch_size在搜索空间中设得过大。解决方案分三层：

1. 预防层：在objective.py开头加显存检查：

   if torch.cuda.is_available(): free_mem = torch.cuda.mem_get_info()[0] / 1024**3 # GB if free_mem < 8: # 小于8GB则跳过 raise optuna.TrialPruned(f"Insufficient GPU memory: {free_mem:.1f}GB")

2. 动态层：让batch_size随显存自适应。用nvidia-smi命令获取当前GPU显存：

   import subprocess result = subprocess.run(['nvidia-smi', '--query-gpu=memory.free', '--format=csv,noheader,nounits'], capture_output=True, text=True) free_mem_gb = int(result.stdout.strip().split('\n')[0]) / 1024 batch_size = min(64, max(8, int(free_mem_gb * 4))) # 每GB显存配4个样本

3. 兜底层：在train_and_evaluate中捕获CUDA OOM并主动剪枝：

   try: val_acc = train_loop(...) except RuntimeError as e: if "out of memory" in str(e): raise optuna.TrialPruned("CUDA OOM") else: raise e

5.2 “Study进度条卡住，CPU占用100%，但GPU空闲”

这通常是数据加载瓶颈。DataLoader的num_workers设太高（如16），导致子进程创建过多，反拖慢主进程。我的调试流程：

• 先设num_workers=0（主进程加载），如果正常，则确认是worker问题；
• 然后逐步增加num_workers，用htop观察CPU负载，找到拐点（通常4~8）；
• 最终在get_dataloaders中让num_workers也成为搜索参数：

  num_workers = trial.suggest_int("num_workers", 2, 8, step=2)

  Optuna会自动发现num_workers=4时吞吐最高。

5.3 “Pruning不生效，所有trial都跑满epochs”

检查三个地方：

• trial.report()未被调用：确认train_and_evaluate中trial.report(ema_val_acc, epoch)在循环内，且epoch是整数；