1. Grokking 到底是什么现象先把它看清楚1.1 一条反常到你以为是代码写错了的训练曲线第一次看到 Grokking 这条曲线的时候我盯着屏幕看了很久第一反应是评估代码里把标签和预测搞反了。场景是这样的一个很小的 Transformer喂进去的是模加法任务训练集只占全部样本的三成左右。训练损失一路下滑训练准确率很快就顶到 100%测试准确率却像被钉死一样停在 1% 上下不动——1% 正好是随机猜测的水平因为模 97 加法一共有 97 个可能的答案。如果故事到这里结束那就是一个再普通不过的过拟合案例模型把训练集背得滚瓜烂熟泛化能力为零。但真正让人头皮发麻的是后面发生的事情。当你不管它继续训练几万甚至十几万步之后测试准确率会突然从 1% 起跳几个评估间隔之内冲到 90% 以上最后稳定在接近满分的水平而训练损失几乎没有任何可察觉的变化。这个现象就是 Grokking——小算法数据集上泛化能力出现在严重过拟合之后甚至可以说泛化是过拟合之后才“长”出来的。它和我们熟悉的“先过拟合、再正则化、再早停”的叙事完全相反也和双下降曲线那种平滑过渡不一样。它解决的核心疑问是模型的泛化能力是不是真的在训练集准确率饱和那一刻就定型了还是说泛化是一个需要额外训练时间才能被优化器“找到”的独立阶段这篇内容适合三类人看。第一类是想做训练动力学分析、但不知道从哪个最小实验下手的同学Grokking 是最好的入门靶子因为它小、快、现象明确第二类是天天盯着验证集曲线做早停的工程师你需要知道“验证集不涨”不等于“模型学不会”第三类是对正则化机制感兴趣的人权重衰减在这里不是配角它几乎是现象出现的主开关。我会从数据构造、模型配置、训练循环一直写到权重范数监控和踩坑记录代码可以直接跑参数怎么来的我也会把计算过程摊开。1.2 为什么偏偏是“小算法数据集”才看得见很多人会问为什么不直接在 CIFAR 或者文本任务上看这个现象。原因是信噪比。真实任务里验证集准确率缓慢爬升的过程被数据噪声、数据增强、学习率调度、批归一化统计量等等因素搅成一锅粥你很难判断“这次涨了两个点”是泛化在发生还是随机波动。而模运算这种算法任务答案空间是离散且有限的正确率只有两种状态要么接近随机基线要么接近 100%中间地带很窄。跃迁一旦发生视觉冲击非常强几乎没有歧义。第二个原因是任务本身有“真正可学的结构”。模加法不是一个随机映射它背后有清晰的代数结构这意味着一套紧凑的、能泛化的解法确实存在。如果任务是完全随机的标签那模型无论如何都只能记忆泛化永远不会出现。所以“小算法数据集”提供的其实是一个受控环境结构存在但需要模型自己找到正确的那条路而不是随手一拟合就撞上。第三个原因是算力门槛低。这类实验动不动要跑十万步听起来吓人但模型只有几十万参数单步计算量小到可以忽略真正的瓶颈反而是每一步的框架调度开销。一台普通带显卡的机器一个晚上能跑完几组对照实验。这一点后面我会用具体的 FLOPs 估算来说明。1.3 它跟普通过拟合、双下降的区别在哪里这三个概念经常被混着说我用一张表把它们分开。普通过拟合是训练集性能持续变好、验证集先变好后变差模型容量相对于数据太大正则化或者早停是解药。双下降讲的是模型容量或者训练时间增大时测试误差先降、再升、再降中间那个“升”是插值阈值附近的现象它描述的是模型族大小与误差的关系。Grokking 描述的是时间轴上的相变在固定的模型、固定的数据、固定的超参下验证集性能在长时间的平台期之后突然跃升。它比双下降更“陡”而且关键点在于——平台期里模型明明已经完美拟合了训练集理论上优化目标已经达成按常规理解没有任何继续训练的必要。表格里我把三者的判据列清楚现象观察对象曲线形态触发条件常规应对普通过拟合训练/验证误差随训练推进验证先降后升平滑容量大、数据少正则化、早停、加数据双下降测试误差随模型规模变化先降、回升、再降模型容量跨过插值阈值选更大模型或加正则Grokking测试准确率随训练步数变化长期平台后阶跃上升小数据、强权重衰减、长训练别早停、加大正则、拉长训练需要注意Grokking 的出现强烈依赖超参尤其依赖权重衰减。很多时候你看到的“没有出现”不是现象不存在而是参数没配到位比如训练集给到 90%、权重衰减设成 0那你大概率只能看到一个标准的过拟合曲线等到地老天荒也等不到跃迁。2. 实验台怎么搭数据集、模型与超参的取舍2.1 模加法任务的数据构造过程任务定义非常直白给定两个 0 到 96 之间的整数 a 和 b输出 (a b) mod 97。所有可能的 (a, b) 组合一共 97 × 97 9409 个每个样本的标签唯一确定。构造的时候我用 meshgrid 一次性展开避免 Python 循环实测生成时间可以忽略。import torch P 97 def build_dataset(pP, train_frac0.3, seed0): xs torch.arange(p) a, b torch.meshgrid(xs, xs, indexingij) a, b a.reshape(-1), b.reshape(-1) y (a b) % p g torch.Generator().manual_seed(seed) perm torch.randperm(a.numel(), generatorg) n_train int(a.numel() * train_frac) tr, te perm[:n_train], perm[n_train:] return (a[tr], b[tr], y[tr]), (a[te], b[te], y[te])这里有几个细节容易翻车。第一输入不要做 one-hot 再拼成一个大向量那会让参数量暴涨而且丢掉“两个操作数对称”的结构用两个独立 token 加 embedding 更干净。第二标签不要做 one-hot 转成回归直接用交叉熵分类97 类输出。第三随机划分之后建议检查一下训练集里每个数字出现的频次我遇到过 seed 选得不好导致某些数在训练集里一次都没出现那测试集上涉及这些数的样本永远做不对泛化上限被钉死在九十几。检查方法很简单统计 a 和 b 在训练集中的唯一值数量确保接近 97。模加法是最常被拿来做这件事的任务因为它简单且结构清晰。如果你想要更狠一点的版本可以换成模乘法但要注意乘法在模 97 下是域运算0 是吸收元处理起来需要单独讨论而且收敛所需的训练步数通常更长。我的建议是先加法跑通再考虑换任务别一上来就挑最难的。2.2 划分比例是决定现象能否出现的第一旋钮训练集占比是这整件事里最敏感的参数没有之一。全量数据训练当然不会有这个问题因为不存在“未见样本”。占比给到 80% 以上的话模型很容易顺着样本的相似性把测试集也顺带覆盖掉曲线平滑看不到阶跃。占比压到 10% 以下模型的容量就不足以从这么少的例子里提炼出结构你等到天荒地老也只有随机准确率。我试过的区间里30% 到 50% 是比较稳的舒服区30% 对应训练样本 2822 条测试样本 6587 条训练样本量已经远小于一个几十万参数的模型能记住的数量。这里其实藏着一个很有用的判断训练样本数必须显著小于模型参数所对应的“记忆容量”否则模型没有动力去找更紧凑的解因为“背下来”这个方案的代价太低了。我还要强调一点划分一定要随机打乱不要按数值区间切。如果训练集只包含 a 和 b 都比较小的样本测试集全是大的那测的就变成了分布外泛化跟 Grokking 是两码事曲线也会完全不同。为了对照实验的可比性同一组实验里我会固定 seed只改一个变量这样出问题的时候能快速定位。2.3 模型规模与参数量的估算模型我用的是一个极简 Transformer两层编码器d_model 1284 个注意力头前馈层维度 512两个操作数先分别 embedding 再加可学习位置向量最后取第一个位置的隐状态接分类头输出 97 维 logits。参数量我大致算一下方便你判断量级。词嵌入 97 × 128 12416位置向量 2 × 128 256。每个编码器层的自注意力部分QKV 三个线性层各 128 × 128合起来 49152输出投影 128 × 128 16384前馈层两个线性分别是 128 × 512 和 512 × 128合计 131072再加上两处 LayerNorm 的参数。合到一层大约 20 万参数两层就是 40 万量级加上嵌入和分类头整体在 45 万左右。对比一下训练样本 2822 条参数量是样本量的一百六十倍左右。这个悬殊的比例正是现象出现的前提模型有足够能力把每个样本都单独记住同时也有足够能力去拟合一个通用的算法规则两条路都走得通最后走哪条取决于优化过程的动态。模型再小一点行不行行d_model 64 也能出但收敛需要的步数会更多。模型大到什么程度会破坏现象目前看不是容量越大越坏而是容量太小会学不动容量大到一定程度后记忆阶段会更快反而把平台期缩短了。我的经验是 d_model 在 64 到 256 之间都能复现别纠结精确数值。2.4 优化器、学习率与权重衰减的配比优化器用 AdamW学习率 1e-3beta 取 (0.9, 0.98)权重衰减 1.0全批量训练不加学习率调度不加 dropout。这套配置几乎是复现这个现象的事实标准我在几组对照里改过学习率和权重衰减结论很明确权重衰减是主开关。权重衰减之所以关键我理解是这样它给参数施加了一个持续的“简化压力”记忆式的解法通常需要把大量参数调到较大的数值去精确区分每一条样本范数会比较高而基于结构的解法往往参数更紧凑、范数更低。训练早期记忆路线梯度信号强、见效快模型先走这条路但只要惩罚一直在推长期看结构路线的总代价更低模型就会慢慢往那边挪。你把权重衰减设成 0这个压力消失模型没有任何理由离开已经到手的零训练损失解跃迁就不会发生。学习率的作用是加速。学习率太小你需要的步数会成倍增加学习率太大训练会不稳定曲线抖得没法看。1e-3 配上全批量是一个稳妥的起点。还有一点值得试批大小。全批量噪声最小曲线最干净但有些实验里小批量引入的梯度噪声反而能加快跃迁因为噪声有助于逃离记忆解的窄谷。这个我没有系统扫过只作为一个可调的旋钮提一下。3. 训练动态拆解三个阶段与背后的机制3.1 第一阶段是记忆训练损失掉得飞快训练刚开始的几百到一两千步训练损失从 log(97) 约 4.57 迅速下降到接近 0训练准确率冲到 100%。这个过程非常快快到你会误以为任务很简单。但这时候去看测试集准确率稳定在 1% 到 2% 之间就是随机水平。这个阶段模型的解法本质上是查表把每个 (a, b) 组合映射到一个特定的输出上靠的是 embedding 里对具体数值的身份编码加上网络里足够多的自由度。它没有学到“加法”这个概念只是把 2822 个点各自钉死了。从优化目标的角度这时候训练损失已经接近于零梯度也变得很小如果按常规的训练脚本你会认为训练已经结束可以保存模型了。我在这个阶段犯过一次错误就是在 5000 步左右看到训练准确率 100% 就直接停掉然后花了半天时间怀疑是任务设计有问题。后来才意识到真正有意思的部分在十万步之后。所以第一个要建立的认知是在这类实验里训练损失归零完全不代表训练完成它只是第一幕结束。3.2 第二阶段是长平台也是最容易被放弃的一段平台期的长度跟配置有关我见过两万步就跃迁的也见过二十万步还在原地的情况。这一段的特征是训练损失贴着零、测试准确率贴着随机线两条曲线都平得像用尺子画的。偶尔会有小幅波动可能是 1% 到 3% 之间的抖动但不足以说明任何问题。这段时间在做什么从可观测的量来看变化主要发生在参数层面而不是损失层面。权重范数会缓慢下降某些中间表示的分布会逐渐重组。如果你每几千步存一个 checkpoint事后做表示相似度分析会发现不同 checkpoint 的隐层表示在平台期后期发生了明显的结构性变化尽管输入输出行为几乎没变。这就是“模型在悄悄换解法”的直接证据。我的建议是在这个阶段做两件事。第一评估间隔千万不要设太大比如每 5000 步评估一次那你最多只能看到四五个点就把跃迁过程错过了看起来像一条垂直线。我一般设 200 到 500 步。第二把验证损失也记下来验证损失的变化往往比准确率更早给出信号因为它对置信度的变化更敏感跃迁前常常能看到验证损失先缓慢下降一小段。3.3 第三阶段是阶跃泛化在很短的窗口内完成跃迁发生的时候测试准确率会在几百到几千步内从个位数冲到九十几测试损失同步断崖式下跌。而训练损失几乎不动因为训练集早就是满分了它没有下降空间。这种“训练指标不变、测试指标剧变”的组合是判断 Grokking 最直接的指纹。更细的观察是跃迁往往不是一次到位。有些运行里会先跃到 60% 左右停一会再跃到 95% 以上像是不同的子结构在分批成形。这个现象让我更倾向于把泛化理解成一组“电路”逐步就位的过程而不是某个单一开关被拨动。每个子结构负责一部分输入空间全部就位之后整体准确率才到顶。跃迁之后继续训练准确率通常还能缓慢爬到 99% 甚至 100%但偶尔也会看到掉头向下的情况这个后面单独说。3.4 表示层面上到底换掉了什么要理解泛化为什么能“延迟发生”得看模型内部换成了什么表示。一派人做过很漂亮的分析结论是记忆阶段的表示基本是围绕具体数值的身份编码每个数字有自己的一套特征而泛化阶段模型学会了把输入投影到一组周期性的基上也就是傅里叶特征然后用这些周期分量去组合出模加法的结果。这个解释直觉上很合理。模运算天生就是周期性的用傅里叶基去表示它参数量少、外推能力强。而如果模型用查表的方式那它对没见过的组合就只能瞎猜。所以泛化阶段的本质是模型找到了一个和任务结构同构的表示而不是它“记住了更多”。我从这个结论里得到一个对实际工作有用的启发当验证集长期不涨的时候与其加大模型、加数据不如想想是不是当前的表示空间里压根没有一个紧凑解。如果有正则化和时间会帮你找到它如果没有训练再久也只是在记忆解附近打转。这个判断在做真实项目的时候同样适用只不过真实任务的“紧凑解”不那么容易被验证。3.5 权重衰减、隐式偏置和相变这三件事的关系我把机制拆成三个层次来说这样比较好理解为什么现象这么依赖超参。第一层是显式正则。权重衰减在每一步都把参数往零的方向拉一点它对高范数解的惩罚更重。记忆解需要较大的参数值来精确区分样本结构解的范数更低所以正则的存在使得结构解在长期竞争中占优。这解释了为什么权重衰减设成 0 时几乎看不到跃迁。第二层是优化器自身的隐式偏置。即使不加显式正则梯度下降也有倾向于找“简单解”的偏好只是这个偏好很弱需要非常长的训练才能体现出来。全批量梯度下降的隐式偏置和随机梯度的不一样这也是批大小会影响跃迁速度的原因之一。第三层是相变式的动态。多个解在参数空间里共存训练过程像是从一个局部最优慢慢被推出来、滑向另一个更优的盆地。这个过程不是渐变的因为在盆地之间移动需要跨过势垒所以表现出来就是长时间的平静加突然的跳变。有工作把这种现象和损失曲面的锐度变化联系起来观察到跃迁前后锐度先升后降这个我没做定量验证但从训练曲线的不连续形态看相变这个描述是贴切的。3.6 跃迁之后还会退回去有个不太被提及但实际会遇到的细节泛化能力不是一旦获得就永久锁定的。有些运行里跃迁到 99% 之后继续训练几万步测试准确率会开始缓慢下滑甚至掉到七八十。这个反向过程有人叫作 un-grokking。我不认为这否定了前面的结论反而说明泛化解和记忆解之间的竞争是持续的只不过大多数时候前者占上风。当训练继续、正则的累积效应把参数推到一个新的区域时平衡可能被打破。实践含义很直接如果你要复现这个现象别在跃迁刚发生时就停止记录多跑一段看看稳定性顺便把这段曲线也存下来很多人第一次见到这个反向过程都会以为是评估出错了。4. 完整复现实操从建表到出图4.1 环境与代码骨架依赖很简单PyTorch 加 numpy 加 matplotlib显卡可有可无这个规模的模型 CPU 也能跑只是慢。我下面的代码按可直接运行的标准写。import torch import torch.nn as nn import torch.nn.functional as F P 97 class ToyTransformer(nn.Module): def __init__(self, pP, d_model128, n_heads4, n_layers2, ff512): super().__init__() self.emb nn.Embedding(p, d_model) self.pos nn.Parameter(torch.zeros(2, d_model)) layer nn.TransformerEncoderLayer( d_modeld_model, nheadn_heads, dim_feedforwardff, dropout0.0, activationgelu, batch_firstTrue, norm_firstFalse ) self.enc nn.TransformerEncoder(layer, num_layersn_layers) self.head nn.Linear(d_model, p) def forward(self, a, b): x torch.stack([self.emb(a), self.emb(b)], dim1) self.pos h self.enc(x)[:, 0] return self.head(h)两个地方值得说明。第一dropout 一定要设 0任何随机的正则都会让训练曲线的可读性大打折扣你要观察的是优化动态不是噪声。第二位置向量我用了一个可学习的 Parameter 而不是位置编码函数因为只有两个位置学两个向量更直接。层数保持两层多了收敛变慢而且现象没那么干净。4.2 训练循环与监控指标训练循环里除了常规的损失和准确率我额外记三个量权重 L2 范数、测试损失、以及每步的梯度范数。权重范数是判断“模型正在换解法”的最好辅助信号梯度范数能帮你区分是训练卡住了还是正常推进。def eval_acc(model, a, b, y): model.eval() with torch.no_grad(): logits model(a, b) acc (logits.argmax(-1) y).float().mean().item() loss F.cross_entropy(logits, y).item() model.train() return acc, loss def weight_norm(model): s 0.0 for p in model.parameters(): s (p.detach() ** 2).sum().item() return s ** 0.5 def train(steps100000, train_frac0.3, wd1.0, lr1e-3, eval_every250, seed0): torch.manual_seed(seed) (a_tr, b_tr, y_tr), (a_te, b_te, y_te) build_dataset( train_fractrain_frac, seedseed) model ToyTransformer() opt torch.optim.AdamW(model.parameters(), lrlr, betas(0.9, 0.98), weight_decaywd) log {step: [], tr_loss: [], tr_acc: [], te_loss: [], te_acc: [], wnorm: []} for step in range(1, steps 1): logits model(a_tr, b_tr) loss F.cross_entropy(logits, y_tr) opt.zero_grad() loss.backward() opt.step() if step % eval_every 0: tr_acc (logits.argmax(-1) y_tr).float().mean().item() te_acc, te_loss eval_acc(model, a_te, b_te, y_te) log[step].append(step) log[tr_loss].append(loss.item()) log[tr_acc].append(tr_acc) log[te_loss].append(te_loss) log[te_acc].append(te_acc) log[wnorm].append(weight_norm(model)) print(f{step:6d} tr {tr_acc:.3f} te {te_acc:.3f} floss {te_loss:.3f} wn {log[wnorm][-1]:.2f}) return model, log评估都不用 torch.no_grad 包一层再算梯度这里已经处理了。全批量意味着不需要 DataLoader直接把整个训练张量喂进去这一步省掉了大量样本加载的开销对十万步的训练来说非常关键。4.3 参数计算与训练预算估算先把步数和 epoch 的换算讲清楚。因为用的是全批量每一个优化步就遍历了完整训练集一次所以一步等于一个 epoch。十万步就是十万个 epoch。这个数字听起来荒谬但在这类任务上确实如此原因就是模型太小、数据太少一步的计算量微不足道。我来估算一下算力。每步的前向加反向 FLOPs 大致是 6 × 参数量 × token 数参数量 4.5e5token 数 2得到单步大约 5.4e6 FLOPs。十万步累计 5.4e11 FLOPs也就是半 T 的量级。按这个算力理论上零点几秒就该跑完但实测要跑一两个小时。差距全在框架的调度开销上每步要启动几十个 CUDA kernel每个 kernel 只处理几万个元素GPU 大部分时间在等指令。这一点很值得记住做小规模训练动力学实验时你的瓶颈不是算力而是 kernel 启动延迟所以别指望靠堆卡加速优化方向应该是减少评估次数、用更大的模型换取更少的步数。超参我建议按这张表来配这是我反复试下来比较稳的起点参数推荐值作用与调整方向训练集占比30%越小越容易出太小则学不会d_model12864 也能出但更慢256 更快但显存略增层数21 层也有效3 层以上收益不明显学习率1e-3降到 3e-4 步数翻倍升到 3e-3 可能不稳权重衰减1.0核心旋钮0.1 常常看不到现象批大小全量小批量可能加速但曲线更抖评估间隔250 步太大容易错过跃迁窗口训练步数10 万起上不封顶看现象决定4.4 我的一组实测记录我用同一份数据、同一个 seed只改权重衰减跑了三组每组十万步记录如下权重衰减训练集达 100% 的步数测试集首次超过 50% 的步数十万步时测试准确率权重范数走势0.0约 600未出现1.2%持续上升0.1约 700未出现1.4%缓慢上升后走平1.0约 800约 2100098.7%先升后持续下降第三组的曲线形态很有代表性训练准确率在第 800 步左右触顶之后再没动过测试准确率在 21000 步前后开始抬头到 26000 步左右到 90%之后缓慢爬到 98.7%。权重范数在记忆阶段快速上升在测试准确率开始抬头的同一时期出现明显拐点之后单调下行。这个拐点和准确率跃迁在时间上的重合是我判断范数可以作为诊断指标的主要依据。第二组用 0.1 的时候我还抱了点希望因为范数确实走平了但十万步过去测试准确率始终在随机线附近。这说明正则强度不够压力不足以把模型推出记忆解。这也提醒我别看到“范数在降”就以为要跃迁了还得看降的幅度和持续时间。5. 常见问题与排查实录5.1 现象不出现时的排查顺序这一类问题占了我调试时间的大头我整理成一张按优先级排序的速查表遇到问题从上往下查基本能覆盖八成情况。症状最可能的原因排查方法处理方式训练准确率迟迟不到 100%学习率过小或步数不够看前 2000 步的训练损失下降速度学习率提到 1e-3或延长观察步数测试准确率永远是 1% 左右权重衰减太小打印权重范数看是否持续上升把权重衰减拉到 1.0 试训练损失震荡不收敛学习率过大看损失是否呈锯齿降到 3e-4或加短 warmup换 seed 后现象消失划分或初始化敏感同一配置跑三个 seed 看比例记录多种子结果别用单次结论测试曲线只有孤零零几个点评估间隔过大检查 eval_every降到 250 步以内某些测试样本永远错训练集覆盖不全统计训练集中 a、b 的唯一值数量换划分 seed确保覆盖接近 97跃迁后准确率又掉了出现了反向过程看后期曲线斜率保存中间 checkpoint别只看终点我用这张表最快的一次排查是“测试准确率永远 1%”的问题。折腾了很久以为是模型太小最后打印权重范数发现它一路涨到很大也不回头才注意到权重衰减参数传成了 0原因是优化器构造的时候写成了关键字参数名不对被静默忽略了。这种低级错误在长训练实验里代价极高因为它要跑几个小时才暴露。所以我现在写训练脚本第一件事就是打印一遍优化器的 param_groups把 lr 和 weight_decay 确认下来再开跑。5.2 几条踩出来的经验第一条别用早停。这是最反直觉但最重要的一条。在这个任务上验证集长期不涨是正常状态早停会直接把现象掐死在你面前。我的做法是给定一个足够长的步数预算中途完全不干预只在最后看结果。如果预算不够宁可缩小模型换更快的收敛也别设早停阈值。第二条评估要密日志要全。你只需要在评估时多算几个量成本几乎为零但事后分析的余地天差地别。我一般存 step、训练损失、训练准确率、测试损失、测试准确率、权重范数再加一个测试集上的置信度均值。置信度这个量在跃迁前会先动比准确率早给出信号这是我做了几组对比之后才发现的。第三条多种子跑别信单次。这个任务的种子敏感性比我预期的强同样的配置换个种子跃迁步数可能差两三倍偶尔还会遇到压根不跃迁的。判断一个参数是否有效我至少跑三个种子看趋势只看一次结果很容易得出相反结论。第四条画图用对数横轴。十万步的横轴用线性刻度前面几百步的记忆过程会被压成一条竖线完全看不见。对数横轴下记忆阶段、平台期、跃迁点三个区域的比例关系才清楚。纵轴对我来说用线性就够因为准确率是 0 到 1 的区间能直接看出阶跃的陡峭程度。第五条checkpoint 别只存最后一个。跃迁前后的权重是分析表示变化的关键素材我一般每两千步存一次模型小存几十个 checkpoint 也不占多少空间。事后想做隐层表示对比、想做参数范数分布全靠这些存档。等到发现需要的时候再去重跑成本就高了。第六条别把这个实验的结论直接搬到生产任务上。小算法数据集上“训练足够久就能泛化”这个结论到了真实任务里未必成立因为真实任务的解空间里未必存在那个紧凑解而且训练成本和数据规模完全不是一个量级。它真正给你的启发是两件事一是验证集不涨时不要急着下结论二是正则化的作用不只是防过拟合它还在改变优化路径的走向。这两条在工程上是有实际价值的但具体到某个业务模型要不要把训练拉长十倍还得看你的验证曲线是不是真的存在一个还没被走到的平台。第七条如果你想把这个实验做深可以从两条线扩展。一条是换任务从模加法换到模乘法、换到置换群运算看看泛化所需的步数和任务代数复杂度的关系。另一条是换表示分析把跃迁前后的隐层取出来做傅里叶变换看周期性分量是不是真的在跃迁之后才出现这个验证做出来会让你对机制的理解从“听说”变成“看见”。我个人在这件事上最大的收获其实不是复现出了一个漂亮的阶跃曲线而是对“训练损失归零”这件事的态度变了。以前我看到训练集 100% 就觉得训练结束了现在我会多问一句它是学会了还是记住了。这个问题在小实验里可以用一条曲线回答在真实项目里可能要用一周的额外训练和一堆分析才能回答但值得问。最后再分享一个小技巧如果你嫌十万步太慢可以先把 d_model 降到 64、训练集占比降到 25% 跑一次快速验证确认整条链路和日志都没问题再上完整配置能省掉大量因为脚本 bug 而浪费的等待时间。