企业官网建设流程全解析

写 Decoder Layer 的时候，我见过太多人把它当成一个黑盒：输入张量进去，出来还是同样形状的张量，中间发生了什么，全靠背八股。实际上 Decoder Layer 就是一台状态更新机——Attention、MLP、PLE 三个组件分别承担了“跨位置通信”“位置内加工”“跨任务门控选择”三种不同的状态更新职责。这篇文章从状态更新的角度把三者拆开讲清楚，配合可直接复用的 PyTorch 实现和调参经验，不管是想手写 seq2seq 模型、做多任务学习，还是排查训练不收敛的问题，都能直接对照着用。

1. 理解 Decoder Layer 的本质：一切皆状态更新

1.1 什么是 Decoder Layer 的“状态”

咱们先建立一个统一视角。无论你用的是经典的 Transformer Decoder、GPT 系列的堆叠结构，还是带多任务建模能力的定制化 Decoder，输入的 tensor 永远是同一类东西：

一个形状为[batch_size, seq_len, d_model]的激活矩阵。

这个矩阵的每个位置，可以理解为一个“信息货车”，车厢宽度就是d_model。整个 Decoder Layer 做的所有事情，本质上就是对这个信息货车阵列进行一次加工：让每个位置跟其他位置交换信息，再让每个位置内部做一次特征变换，最终输出一组更新后的状态。

我从这个视角出发之后，很多东西都变得透明了。比如为什么d_model不能太小，因为货车太窄装不下足够的语义信息；为什么隐藏层维度一般是4 * d_model，因为内部加工需要更大的临时工作台；为什么残差连接必不可少，因为状态更新的核心逻辑就是“在原有基础上叠加增量”，而不是直接推倒重来。

1.2 把 Attention、MLP、PLE 看成三种状态更新器

如果你把 Decoder Layer 看作流水线，这条流水线上的三个核心工位各有明确分工：

• Attention（注意力层）：跨位置通信器。让序列中每个 token 的状态参考其他 token 的状态进行更新，解决的是“我该关注谁”的问题。
• MLP（多层感知机）：位置内加工器。对每个 token 的状态独立进行非线性变换，解决的是“我学到了什么模式”的问题。
• PLE（Progressive Layered Extraction）：跨任务/跨模块门控选择器。通过多个专家子网络和门控路由，决定哪些状态更新共享底层、哪些状态更新走独立通道，解决的是“状态该交给谁处理”的问题。

用生活化的例子来类比就是：Attention 是开小组讨论会，每个人根据别人的发言调整自己的观点；MLP 是散会后的个人复盘，把讨论结果消化成自己的知识；PLE 则是跨部门的资源调度，不同任务线共享一部分资源，同时保留各自的专属通道，避免互相干扰。

这里有个非常重要的细节：这三个更新器都是通过残差结构接入主链路的。也就是说，每个组件的输出不是直接覆盖输入状态，而是作为增量叠加到原状态上。这种做法让每一层都能专心学“变化量”，而不是强行重构“全量信息”，也是深层网络能训练起来的核心原因。

2. Attention 层如何更新状态

2.1 从“查字典”理解注意力机制的状态更新逻辑

Attention 层干的事情，本质上是在一张动态生成的“关联表”里查信息。每个 token 生成三个不同的投影向量：Query（查询）、Key（索引）、Value（内容）。

• Query 就像是你在图书馆检索时用的关键词；
• Key 是所有图书的编号标签；
• Value 是图书真正的内容。

注意力分数的计算就是拿 Query 去匹配所有 Key，然后根据匹配程度把 Value 加权求和。匹配度高的位置，它的状态就能更多地流进当前位置的新状态里。

在 Decoder 场景下，这个查字典过程还有一个关键约束：causal mask。因为解码是自回归的，当前位置在生成时只能看到自己之前的 token，不能偷看未来的内容。所以因果掩码会把[i, j]区域中 j > i 的位置全部屏蔽，具体做法是在 softmax 之前把那些位置的分数设为很大的负数（通常是-inf或-65504对应的 dtype 极小值）。我见过不少新手直接把 mask 和注意力分数相乘，结果发现分数被乘出了非对称的分布，训练出来的注意力矩阵常常是歪的——正确做法是把 mask 当作“加法偏置”处理，不是乘法。

另外要区分两种 Attention 在状态更新上的差异。Self-Attention 是序列内部互相参考，Q、K、V 都来自同一份状态；Cross-Attention 是 Decoder 状态去查询 Encoder 的输出状态，Q 来自解码端，K、V 来自编码端。后者在带 Encoder-Decoder 结构的 seq2seq 模型里非常关键，它解决了“当前翻译到哪一步了，应该参考源语言的哪些信息”的问题。

2.2 可复用的通用 Attention 模块实现

先给一个我一直在用的通用实现，这个模块我后来在不同项目里复用了几十次，换成 seq2seq、GPT 类模型都只需要改 mask 的生成方式即可：

import torch import torch.nn as nn import math class GenericAttention(nn.Module): def __init__(self, d_model, n_heads, dropout=0.0, use_flash=False): super().__init__() assert d_model % n_heads == 0, "d_model必须能被n_heads整除" self.d_model = d_model self.n_heads = n_heads self.head_dim = d_model // n_heads self.use_flash = use_flash self.wq = nn.Linear(d_model, d_model, bias=False) self.wk = nn.Linear(d_model, d_model, bias=False) self.wv = nn.Linear(d_model, d_model, bias=False) self.out_proj = nn.Linear(d_model, d_model, bias=False) self.dropout = nn.Dropout(dropout) def forward(self, x, encoder_out=None, mask=None): # x: [batch, seq_len, d_model] # encoder_out: 跨注意力时传入，self-attention时为None src = x if encoder_out is None else encoder_out B, T, _ = x.shape S = src.shape[1] q = self.wq(x).view(B, T, self.n_heads, self.head_dim).transpose(1, 2) k = self.wk(src).view(B, S, self.n_heads, self.head_dim).transpose(1, 2) v = self.wv(src).view(B, S, self.n_heads, self.head_dim).transpose(1, 2) if self.use_flash and hasattr(torch.nn.functional, "scaled_dot_product_attention"): # PyTorch 2.0+ 原生FlashAttention路径 attn_out = torch.nn.functional.scaled_dot_product_attention( q, k, v, attn_mask=mask, dropout_p=self.dropout.p if self.training else 0.0 ) else: scale = 1.0 / math.sqrt(self.head_dim) scores = torch.matmul(q, k.transpose(-2, -1)) * scale if mask is not None: # mask为布尔矩阵，True的位置被屏蔽 scores = scores.masked_fill(mask[:, None, :, :], float("-inf")) attn_weights = torch.softmax(scores, dim=-1) attn_weights = self.dropout(attn_weights) attn_out = torch.matmul(attn_weights, v) attn_out = attn_out.transpose(1, 2).contiguous().view(B, T, self.d_model) return self.out_proj(attn_out)

这里有几个参数解释一下。bias=False的原因：多头注意力在后续会拼接多头的输出再经过out_proj，Q/K/V 投影本身加了 bias 并不会提升表达能力，反而容易造成某些头学习到相同的角度偏移；我实际对比过开 bias 和关 bias 的收敛曲线，前者在某些随机种子上会出现早期 loss 抖动更明显的情况。scale = 1 / sqrt(head_dim)是必须的，head_dim 越大，QK^T 的点积方差越大，如果不缩放，softmax 输入区间会快速进入饱和区，梯度会趋近于零。head_dim 为 64 时，点积方差接近 64，softmax 的输入动辄几十上百，除以 8 之后才能让分布保持敏感。

2.3 FlashAttention 对状态更新的实际影响

Attention 的状态更新看起来只是一次加权求和，但在长序列场景下，这个操作的显存和算力开销非常夸张。完整计算需要显式保留[batch, n_heads, seq_len, seq_len]的注意力分数矩阵，序列长度是 4096 时，这个矩阵在单 batch、8 头、FP16 下就要占用 256MB 显存，序列翻倍则显存翻四倍。

FlashAttention 的思路是不生成完整的注意力矩阵，而是把 Q、K、V 切成小块，在 SRAM 里逐块算 softmax，最后再合并输出。它用分块加权的方式来保证数学结果一致，但内存占用从 O(n^2) 降到了 O(n)。PyTorch 2.0 之后scaled_dot_product_attention原生支持 FlashAttention，代码里只要走这个分支即可。我实测下来，训练 batch 里带 2048 长度的序列时，开启 Flash 后显存下降了接近一半，速度提升了 1.5 到 2 倍。要注意的是，FlashAttention 对 mask 的处理方式有差异，非 padding 类的布尔 mask 在 flash 路径下直接透传即可，但如果你用的是自定义 float mask，则要转换成attn_mask的格式，否则会走 fallback 路径，提速效果直接消失。

还有个和 Attention 状态更新直接相关的东西是 KV Cache。推理阶段生成每个 token 时，其实 Q、K、V 都在更新，但前面已经生成过的 token 对应的 K、V 不会再变化，所以完全可以缓存下来，下一轮推理只需要计算新 token 的 Q，并拿新 Q 去和缓存的 K 做匹配。这个机制让 Decoder 推理复杂度从 O(n^3) 降到了 O(n^2)，代价是显存换速度。我后面会专门说 KV Cache 在长上下文推理里容易踩的坑。

3. MLP 层如何更新状态

3.1 为什么 Attention 之后还必须有一层 MLP

很多人问过同一个问题：Attention 已经让 token 之间交换了信息，为什么还要再过一层 MLP？答案很简单：Attention 本质上是一个“带权求和”的线性操作，哪怕叠加了多头，它的表达能力也局限于线性组合的范畴。如果没有 MLP，整个 Transformer 堆多少层都等效于一个浅层线性模型，学不到复杂的非线性映射。

换个角度看，MLP 是对每个 token 的“私人订制”加工：参与完小组讨论之后，每个 token 需要独立消化自己接收到的信息，在自己的状态空间里做非线性变换。Attention 负责“从别人那里拿信息”，MLP 负责“把这些信息变成自己的知识”。这两个操作交替进行，才构成了完整的特征提取循环。

3.2 标准 FFN 结构与主流变体

最经典的 MLP 结构是全连接网络（Feed-Forward Network）的形式：

class MLP(nn.Module): def __init__(self, d_model, expansion_ratio=4, activation=nn.GELU): super().__init__() hidden_dim = int(d_model * expansion_ratio) self.fc1 = nn.Linear(d_model, hidden_dim) self.act = activation() self.fc2 = nn.Linear(hidden_dim, d_model) def forward(self, x): return self.fc2(self.act(self.fc1(x)))

中间隐藏层的维度一般是d_model的 4 倍。为什么是 4 倍？这是原始 Transformer 论文里经过实验选出来的一个“甜点值”，它让模型有足够的容量去记忆训练集中出现的模式，又不至于让参数量爆炸。d_model=512时中间层是 2048，d_model=768时中间层是 3072，d_model=1024时中间层是 4096。我试过把 expansion ratio 从 4 降到 2，效果是参数省了一截，但相同参数量下的表征能力反而不如标准配置，收敛速度也慢一些。

现在更主流的是门控类变体，最典型的是 SwiGLU：

class SwiGLU(nn.Module): def __init__(self, d_model, expansion_ratio=4 / 3 * 2): super().__init__() hidden_dim = int(d_model * expansion_ratio) self.fc1 = nn.Linear(d_model, hidden_dim) self.fc2 = nn.Linear(d_model, hidden_dim) self.fc3 = nn.Linear(hidden_dim, d_model) def forward(self, x): x1 = self.fc1(x) gate = torch.silu(self.fc2(x)) return self.fc3(x1 * gate)

注意 SwiGLU 的参数细节：它在等价参数量下实际需要的 hidden_dim 会调成8/3 * d_model左右，而不是4 * d_model。因为多了一个门控线性层，单个网络的计算路径多了分支，所以同等参数量下模型容量反而更大。我实测下来，SwiGLU 比 GELU 的标准 FFN 在相同训练步数下 loss 能低 3%-5%，代价是推理时多一个矩阵乘。

3.3 MLP 的参数量与状态更新速度的关系

说个可能让新手意外的事实：在 Decoder Layer 里，MLP 占了总参数的大约三分之二。以d_model=1024为例，Attention 的 Q/K/V/out 四个矩阵的参数是4 * 1024 * 1024 ≈ 4M，而 MLP 的 fc1 加 fc2 参数是1024 * 4096 * 2 ≈ 8M，比例非常明显。这意味着 MLP 是模型记忆外部知识的主要载体，Attention 则更多负责信息路由。

这个比例直接关系到训练和推理的性能。MLP 的中间层展开四倍，前向计算时激活值会瞬间膨胀到原来的四倍尺寸，这一块占用的显存相当可观。所以做长序列训练时，如果显存吃紧，第一优先考虑的是激活值检查点（activation checkpointing），把 MLP 中间激活在反向传播时重算，而不是直接存下来。

推理时 MLP 同样是带宽瓶颈。每层 MLP 要读写的数据量是所有子层里最大的，尤其在 batch size 较小、显存带宽受限的场景下，MLP 的耗时往往超过 Attention。这也是为什么模型需要做 weight only 量化时，优先量化 MLP 权重能带来最直观的推理加速效果。

4. PLE 如何参与状态更新

4.1 PLE 是什么：从多任务共享到 Decoder 状态更新

PLE 的全称是 Progressive Layered Extraction（渐进分层提取），最早是腾讯在推荐系统多任务学习中提出的一种结构，解决的问题是：多个任务共享底层表示时，如果只做硬参数共享（Hard Sharing），任务之间容易互相干扰；如果完全做软参数共享但又缺少交互，每个任务学到的底层知识又不够充分。

PLE 的结构里有一组共享专家（Shared Experts）和每个任务专属的专家（Task-specific Experts），外加一个门控网络（Gating Network）。每个任务的输出不是直接选某个专家，而是由门控网络对所有专家输出做加权组合。门控的权重是动态计算的，这意味着不同任务在不同输入上会“借用”不同程度的共享知识，同时又保留自己的私有通路。

放到 Decoder Layer 的语境下，PLE 可以理解为一个进阶版状态更新器：它把状态路由到多个专家子网络里做并行处理，再通过门控汇总回主状态。适合的场景包括多任务解码、多模态融合、以及需要同时建模多种状态的定制化 Decoder。比如一个解码器同时要输出实体标签和情感标签，如果用同一个 Decoder Layer，两个任务的状态更新互相打架；引入 PLE 之后，每个任务有专属专家，共性知识走共享专家，状态更新的冲突大幅减少。

4.2 一个迷你 PLE 模块的实现

下面这个实现我做过简化，但保留了核心结构：一组共享专家、一组任务专属专家、以及一个门控网络。

import torch import torch.nn as nn import torch.nn.functional as F class Expert(nn.Module): def __init__(self, d_model, hidden_dim=None): super().__init__() hidden_dim = hidden_dim or d_model * 2 self.net = nn.Sequential( nn.Linear(d_model, hidden_dim), nn.GELU(), nn.Linear(hidden_dim, d_model), ) def forward(self, x): return self.net(x) class PLEModule(nn.Module): def __init__(self, d_model, num_tasks, num_shared_experts=2, experts_per_task=2): super().__init__() self.num_tasks = num_tasks self.shared_experts = nn.ModuleList( [Expert(d_model) for _ in range(num_shared_experts)] ) self.task_experts = nn.ModuleList( [nn.ModuleList([Expert(d_model) for _ in range(experts_per_task)]) for _ in range(num_tasks)] ) # 每个任务一个门控：输入 -> 所有专家的权重 self.gates = nn.ModuleList([ nn.Linear(d_model, num_shared_experts + experts_per_task) for _ in range(num_tasks) ]) def forward(self, x, task_ids): """ x: [batch, seq_len, d_model] task_ids: [batch] 每个样本对应的任务id，0 ~ num_tasks-1 """ outputs = [] for i in range(self.num_tasks): task_mask = (task_ids == i).unsqueeze(-1).unsqueeze(-1) # [batch,1,1] if task_mask.sum() == 0: continue shared_out = torch.stack([e(x) for e in self.shared_experts], dim=-1) task_out = torch.stack([e(x) for e in self.task_experts[i]], dim=-1) all_out = torch.cat([shared_out, task_out], dim=-1) # [B,S,d_model,num_exp] gate_logits = self.gates[i](x) gate_weights = F.softmax(gate_logits, dim=-1).unsqueeze(-2) # [B,S,1,num_exp] weighted = (gate_weights * all_out).sum(dim=-1) outputs.append(weighted * task_mask) return torch.stack(outputs).sum(0) if len(outputs) > 0 else x

这个模块的使用要点有三个：

• 门控输入用x而不直接用手工设计的特征，这样门控能根据当前 token 的实际状态动态决定专家的组合权重，而不是固定地选某个专家。
• 任务专属专家要保证每个任务至少 2 个。只放 1 个专家时，这个专家很容易变成“全能选手”而被门控始终选中，失去专属隔离的意义。
• 门控输出要做 softmax，这样所有专家的权重加起来等于 1，相当于在状态更新时做了一个“软选择”，既保留了共享知识，又避免了梯度互相抵消。

PLE 更新状态的核心思想是：状态不再经过单一路径加工，而是被复制到多个专家路径中分别处理，然后再按门控权重合并回来。这样更新后的状态既吸收了共享知识，又保留任务特异的特征，比单纯堆叠 MLP 更容易处理多目标冲突。

4.3 PLE 的推理与“PLE 表”

最近常看到有人搜“ple 表 推理”，这其实指的是把多任务门控的中间计算结果提前算好、缓存成表，推理时直接查表，省掉在线动态计算门控权重的成本。因为门控网络本身是个线性层加 softmax，如果在固定特征分布的条件下，门控输出变化不大，就可以离线把每个典型输入对应的专家权重存成向量表，推理时对输入做最近邻查表或者哈希映射，拿到权重再做加权和。

我在实际项目里用过类似思路。当时 Decoder 需要处理四五个子任务，每个 token 都走一次完整 PLE 门控太重。我做了两层优化：第一层把输入状态按 norm 的取值粗分桶，每个桶离线算好平均门控权重；第二层只对桶边界附近的 token 才做在线 full gate，其余直接查表。最终在线推理整体延迟降了约 30%，任务指标基本持平。这个方向的做法很依赖具体业务分布，不能无脑套用，但如果你的状态分布相对稳定，值得尝试。

5. 三者协同与实战调参

5.1 状态更新的标准时序与顺序的影响

把三个更新器组装起来，Decoder Layer 的完整流程一般是这样：

输入 x ↓ LayerNorm(x) → Self-Attention（或 Cross-Attention） → 残差叠加 ↓ LayerNorm(输出) → MLP → 残差叠加 ↓ （可选）LayerNorm → PLE/门控 → 残差叠加 ↓ 输出更新后的状态

顺序不是随便定的。Attention 放在 MLP 之前的原因在于：先跨位置通信，把全局信息汇聚到每个 token 上，再做局部加工，这样 MLP 处理的信息是经过上下文增强的，加工效率更高。反过来如果先 MLP 再 Attention，每个 token 一开始只能利用自身信息，局部加工完再做全局混合，模型深度增加时信息流通效率会明显下降。

LayerNorm 位置有两种主流风格：Post-LN（原始 Transformer）和 Pre-LN（GPT 系列）。Post-LN 是“子层输出之后再归一化”，梯度容易在深层衰减；Pre-LN 是“子层输入之前归一化”，每个残差分支的输入都是归一化后的，梯度流动更稳定，所以现在几乎所有大模型都用 Pre-LN。自己从零搭 Decoder 时直接用 Pre-LN 加残差的组合，少踩很多坑。

5.2 初始化、学习率和 Norm 参数的细节

状态更新器能不能正常工作，很大程度上取决于初始化。这里分享几个我反复踩坑后验证有效的经验：

• 残差分支的末尾线性层建议用零初始化。MLP 的fc2或 Attention 的out_proj如果保持默认的随机初始化，前向早期的增量就带有随机方向上的跳跃，深层叠加后状态容易漂移。把它们初始化为零，可以让每个子层一开始只做“透传”，模型从头学习增量路径，收敛稳定性好很多。实际做法是nn.init.zeros_(fc2.weight)和fc2.bias。
• embedding 层的标准差要控制。常见是把 token embedding 初始化在N(0, 0.02)左右。如果当成普通 Linear 用kaiming_uniform初始化，初始状态的方差被放大，Attention 的 QK^T 点积就容易溢出。
• 学习率配合 warmup。Decoder 在训练初期，Attention 注意力分布还没成型，过大的学习率很容易让门控和注意力权重在早期落入一个不好的“对齐模式”里，后面很难拉回来。我一般用前 5% 到 10% 的步数做线性 warmup，峰值学习率再根据 batch size 和模型大小调整，比如d_model=512时常用3e-4左右，d_model=1024时降到1.5e-4左右。

5.3 混合精度与显存优化的几个真实建议

训练大模型基本离不开混合精度。BF16 是我现在更推荐的选择，因为它的指数范围大，不需要额外的 loss scaling 逻辑，在 A100/H100 上训练收敛曲线比 FP16 更稳。FP16 的问题是表示范围小，梯度容易下溢或上溢，需要动态 loss scaling 兜底。

FlashAttention 和混合精度配合要注意一个细节：attention softmax 的输入是 QK^T 乘以 scale，在 FP16 下如果某个位置的注意力分数特别大，softmax 结果会偏向它，梯度更新时其他位置几乎得不到信息。所以现在很多模型会在 Attention 内部对 Q 做 RMSNorm 或者对 attention logits 做额外的 clipping，把 logits 限制在[-max_logit, max_logit]范围内。

KV Cache 显存优化的大头：假设batch=1, seq_len=4096, n_heads=32, head_dim=128, dtype=BF16，单层 KV Cache 大小是2 * 4096 * 32 * 128 * 2 bytes = 64MB，层数一多，几百 MB 很快就没了。推理时如果要做长上下文，通用的方案是 KV Cache 用更低的精度保存（比如 INT8），或者做 PagedAttention 式的分页管理，让内存按需分配，而不是一次性预留最大长度。我实际用下来，INT8 KV Cache 在大多数任务里只掉了不到 1% 的准确率，但内存直接减半。

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

6.1 训练不收敛或 loss 反复震荡

这个问题的头号嫌疑是 Attention 矩阵异常。先看 QK^T 的取值分布，如果发现 scale 之后的 logits 经常出现几百上千的绝对值，说明初始化或者 Norm 有问题。排查步骤我一般按顺序进行：

• 第一步：打印每个子层的输出 norm 值，检查是否在合理范围（通常是 1 到 10 之间）。
• 第二步：检查 attention 权重的熵，如果大部分权重都集中在对角线附近，说明模型没有学到跨位置的信息交换。
• 第三步：检查 MLP 中间的激活值是否大量为负数或饱和，如果是 GELU，检查是否有大量处于饱和区间的值。

我遇到过一次诡异的情况：loss 前几千步正常下降，到了某个点突然快速上升，然后一直震荡。最后查到原因是某个 batch 里 sequence padding 部分没有做 mask，导致 Attention 把所有 padding 位置的 K、V 也都算进去了，padding 向量本身是随机初始化的，相当于在学习无意义的噪声。把 padding mask 加进 Attention 之后，问题立刻消失。

6.2 推理速度慢，瓶颈到底在哪

推理慢的时候不要盲目调模型结构，先定位瓶颈。比较快的办法是用 PyTorch Profiler 跑一两个 step，看各层耗时占比。

• 如果 Attention 耗时占比特别高，优先检查是否没有启用 FlashAttention，或者 mask 导致走了 fallback 路径。常见的是torch.compile之后的 graph break。
• 如果 MLP 耗时最高，优先考虑 weight 量化或 batch 合并优化。
• 如果解码时生成速度随着上下文长度明显下降，大概率是 Attention 在重复计算历史 token 的 Q、K、V，检查 KV Cache 是否开启，以及 Cache 的实现是否按 batch、seq 维度同步更新。

我踩过的锅是：自己手写 KV Cache 的时候忘了把past_key和past_value在第一维（batch）上做广播复制，batch 大于 1 时缓存形状对不上，导致部分 batch 的结果错位，生成出来的内容不连贯。排查了半天才发现是缓存拼接时把新旧 batch 顺序搞混了。

6.3 多任务状态冲突与 PLE 训练不稳定

用 PLE 做多任务状态更新时，最常见的现象是某个专家被所有任务抢着用，其他专家几乎不更新。这本质上是门控网络的收敛问题。三个有效对策：

• 门控初始化时往共享专家方向偏移，让共享专家一开始拥有更高的权重，后续再逐步让门控自己调整。这样前期的状态更新以共享知识为主，任务需要时再切走。实现上可以对门控的共享专家部分的 bias 做一个正初始值。
• 任务专属专家容量不够时，加专家数或者加 hidden_dim 比单纯加训练步数更有效。因为状态冲突时，专属专家需要足够的容量来建模任务特异的模式，容量不足时门控只能大量依赖共享专家，冲突加剧。
• 不同任务的 loss 收敛速度不一致时，动态调整各任务 loss 权重。我在项目里用了一种简单的策略：每个任务按照各自 loss 的滑动平均值做归一化，再乘一个全局系数，结果比固定权重稳定许多。

这类问题排查时要善用可视化工具：把门控权重按任务、按 token 位置画出来，一眼就能看出专家是否失衡。下面是常见问题速查表：

6.4 一些小但实用的避坑技巧

最后分享几个不太常被人提到的细节：

• 自定义 Attention 模块里如果用了masked_fill填-inf，要注意能转成boolmask 的尽量转 bool。直接用float("-inf")填写，在 fp16 下会遇到一个隐藏问题：-inf加上一个有限值还是-inf，但如果是用极大负数填充，比如-65504，和另一个正数相加就可能变成有限值，导致被屏蔽位置漏出微小非零概率。所以别省这一步。
• LayerNorm 的eps默认是1e-5或者1e-6，但在混合精度训练时，如果d_model大且状态数值偏小，eps太小会让方差开根后除出来的值不稳定。我一般建议用1e-5以上，并确认 dtype 在 fp16 下不会因为eps过小而出现除零。
• 每次调整模型结构后，先跑一个单 batch 的 overfit 训练：只拿一条样本训几百步，看 loss 能不能降到接近零。这一步能快速暴露 shape 错误、mask 错误、初始化错误。很多问题在完整训练跑起来之前，用这个方式 5 分钟就能定位，比等几轮大训练再发现省太多了。

我对 Decoder Layer 里三个状态更新器的理解，说到底是一句话：Attention 负责让信息流动起来，MLP 负责让信息沉淀下去，PLE 负责让不同目的的信息各走各路。三者配合不好，最常见的表现就是训练慢、状态冲突、推理速度上不去。如果你正在搭自己的 Decoder，建议先把 Attention 和 MLP 的基础组合调到稳定，再考虑引入 PLE 这类更复杂的门控结构。每一个组件都加得明明白白，状态更新的每一步都能量化监控，这时候模型的性能就只是时间问题了。