我完全理解你卡在这个问题上的挫败感——首轮训练正常，之后指标突然崩盘，这种情况确实让人摸不着头脑。咱们结合你的模型、训练设置和现象，一步步拆解可能的原因，再给出针对性的修复方案。

首先，明确你的核心问题与配置 #

现象：

• 第1个epoch：训练acc达20%、验证acc达6%，loss正常下降
• 第1轮后：训练/验证acc停滞或下降，双向loss均上涨

关键配置：

• 模型：1D-CNN，每块由1x1+3x3卷积分支concat后池化，最终通过1x1卷积转8705类+GAP输出
• 训练：SGD（lr=0.01，momentum=0.9，wd=5e-5）、StepLR（step=10000，gamma=0.01）、CrossEntropyLoss、梯度裁剪（max_norm=1）
• 数据：8705类，训练集每类3600样本（80/20拆分），验证集描述为「8705 in validation」（疑似笔误，需确认规模）

核心问题拆解与修复方案 #

按优先级从高到低排序：

1. 致命错误：最后一层的激活函数破坏了Logits分布

你在模型的forward函数中，最后一层的处理犯了一个关键错误：

x = self.final_conv(x)
x = self.final_bn(x)
x = self.act_fn(x)  # 这里的LeakyReLU是核心问题！
x = self.gap(x)
x = x.squeeze(-1)
return x

CrossEntropyLoss要求输入是未经过激活的Logits（未归一化的概率对数），它会内部自动执行softmax计算。而你添加的LeakyReLU会压缩Logits的数值范围（负半轴为0.05x，正数保持原值），直接干扰Loss的梯度计算逻辑，导致训练后期参数更新完全失控，最终表现为Loss上涨、Acc崩盘。

修复：
立即移除最后一层的LeakyReLU，修改后的代码片段：

x = self.final_conv(x)
x = self.final_bn(x)
# 移除这一行：x = self.act_fn(x)
x = self.gap(x)
x = x.squeeze(-1)
return x

2. SGD与学习率调度的严重不匹配

这是你使用SGD时模型崩盘的核心原因：

• 初始LR过高：0.01的学习率对于8705类的超大规模分类任务过于激进。类别数越多，Logits维度越大，CrossEntropyLoss的梯度量级也会更高，SGD的大学习率+0.9动量会导致参数更新幅度过大，首轮后就越过最优值开始发散。
• StepLR调度完全不合理：step_size=10000意味着要跑完10000个batch才会降低学习率。假设你的batch size为64，单轮训练的batch数约为(8705*3600*0.8)/64 ≈ 486k，10000个batch仅占单轮的2%左右——也就是说，模型在首轮的绝大多数时间里都在用过高的LR训练，直接引发参数震荡发散。

修复方案：

• 降低初始LR：将SGD的初始LR从0.01调整为0.001，如果还是不稳定，再降到0.0005。
• 替换LR调度器：放弃StepLR，改用ReduceLROnPlateau（更自适应，根据验证Loss动态调整LR）：

  # 初始化调度器
  from torch.optim.lr_scheduler import ReduceLROnPlateau
  scheduler = ReduceLROnPlateau(
      self.optimizer,
      mode='min',  # 监控验证Loss下降
      factor=0.5,  # 每次LR降为原来的1/2
      patience=3,  # 连续3轮验证Loss不下降就降LR
      verbose=True
  )
  
  # 训练循环中，每轮验证后更新调度器
  train_loss, train_acc = self.train_epoch(epoch, total_epochs)
  val_loss, val_acc = self.validate_epoch(epoch, total_epochs)  # 需实现验证函数
  scheduler.step(val_loss)
  

• 如果坚持用StepLR：将step_size改为单轮batch数的1/5~1/10（比如按batch size64，设为50000），gamma改为0.5（0.01降得太猛，直接砍到1e-4会导致模型停止学习）。

3. 验证集规模与数据预处理的潜在问题

• 验证集规模：你描述的「8705 in validation」如果是指验证集仅8705个样本（每类1个），那验证Acc的参考价值极低——6%的Acc可能是偶然结果，后续的「下降」也只是统计噪声。建议确保验证集每类至少有10~20个样本，这样统计结果才可靠。
• 数据标准化：1D-CNN对输入数据的尺度非常敏感，如果你的输入没有做(x - mean)/std的标准化处理，BatchNorm无法有效归一化特征分布，会导致训练不稳定。务必确认输入数据是否经过标准化。

4. 模型结构的微调建议（非紧急，但可提升性能）

8705类属于超大规模分类任务，当前模型的特征容量可能略显不足：

• 可以在最后2~3个卷积块中，将通道数从32提升到64，增强特征表达能力；
• 也可以在GAP之前加一个1x1卷积将通道数升维到128，再转8705类。不过这一步建议在修复前面的问题后再尝试。

关于AdamW的补充说明 #

你提到AdamW的指标改善明显，这是完全合理的——AdamW自带自适应学习率机制，能自动为不同参数调整更新步长，对初始LR的鲁棒性远高于SGD。这不代表AdamW有「问题」，只是SGD对参数的要求更苛刻，需要更精细的调优。等你修复了最后一层的激活函数，再调整SGD的LR与调度器，应该能得到和AdamW相当甚至泛化性更好的结果。

按这个步骤先修复最致命的激活函数问题，再调整SGD参数，应该就能解决首轮后指标崩盘的问题了！如果还有疑问，随时补充你的验证集细节或训练日志，咱们再进一步分析。