1. 从一张架构图说起DeepSeek-V4 到底改了什么第一次看到 DeepSeek-V4 那张架构总览图的时候我的反应是信息量有点大。图上密密麻麻标着 mHC、CSA、HCA、SWA、MoE 这些缩写乍一看像是把近几年注意力机制和混合专家领域的热门词汇全堆在了一起。但如果你真的动手把这张图拆开、逐个模块去对照论文和开源实现会发现它其实是一条非常清晰的工程主线在保持 MoE 稀疏激活带来的算力优势前提下把注意力部分的显存和计算开销压到极致同时用 mHC 这类结构稳住深层训练的稳定性。这篇东西不是论文导读也不是官方文档的复述。我想做的是把这张配图里每个模块为什么这么设计、工程上怎么落地、踩坑点在哪讲透。适合两类人看一类是想理解当前大模型架构演进方向的算法同学另一类是要真正动手复现或魔改这类结构的工程同学。前者可以重点看设计动机和取舍逻辑后者可以重点看参数配置、显存账和实现细节。先说结论性的判断DeepSeek-V4 这套组合拳的核心矛盾是长上下文场景下注意力机制的二次复杂度与MoE 稀疏化带来的通信/调度开销之间的博弈。mHC 解决的是深层网络信号传播问题CSA/HCA/SWA 解决的是注意力怎么在长序列上省算力MoE 解决的是参数量与激活量解耦。这四者不是简单叠加而是互相牵制、需要联合调参的。下面我按这个逻辑逐层拆。2. 核心模块拆解mHC、CSA、HCA、SWA 各自在干什么2.1 mHC深层残差流的稳压器mHC 这个词在公开资料里出现得不算多从命名和它在架构图中的位置贯穿每个 Transformer Block 的残差路径来看它承担的职责和 Hyper-Connections、残差缩放这类技术是同一类问题当网络堆到几十上百层时残差流的方差会累积放大导致训练后期梯度爆炸或表示坍缩。传统的 Pre-LN 结构靠 LayerNorm 把每层输入归一化一定程度上缓解了这个问题但它有个副作用——归一化会削弱残差路径上的恒等映射特性深层信息在传递过程中被反复洗掉。mHC 的思路我理解是在残差连接上引入一个可学习的、带约束的变换让残差流在跨层传播时保持数值稳定同时不破坏恒等映射的主干。工程实现上这类模块通常表现为对残差分支做一个轻量的缩放或门控# 伪代码示意非官方实现 class mHCResidual(nn.Module): def __init__(self, dim, init_scale1.0): super().__init__() self.scale nn.Parameter(torch.ones(dim) * init_scale) self.gate nn.Linear(dim, dim, biasFalse) nn.init.zeros_(self.gate.weight) # 初始化为恒等 def forward(self, x, residual): # 门控初始为0sigmoid后约0.5训练中自适应调整 g torch.sigmoid(self.gate(x)) return residual g * self.scale * x这里有个关键细节门控的初始化必须让它接近恒等映射。如果一上来门控值随机深层网络前几个 step 就会震荡。我见过有人直接把 gate 初始化成标准正态结果 loss 曲线前 500 step 跟心电图一样改成零初始化后立刻平稳。这是实操里非常容易忽略但影响巨大的一点。另一个经验是 mHC 的缩放参数最好按层做区分浅层接近 1.0深层适当衰减。因为深层残差累积的方差更大需要更强的抑制。具体衰减系数没有标准答案我试过线性衰减和对数衰减在 60 层左右的模型上对数衰减收敛更稳。2.2 CSA 与 HCA两种互补的稀疏注意力CSA 和 HCA 是这张图里最容易被混淆的两个模块。从命名推测CSA 大概率是 Chunked/Compressed Sparse Attention 一类HCA 则是 Hierarchical/Hybrid Context Attention 一类。它们解决的是同一个问题的两个侧面如何在不牺牲太多长程建模能力的前提下把注意力的 O(n²) 降下来。CSA 的典型做法是把序列切块块内做完整注意力块间做压缩表示。这样复杂度降到 O(n·b (n/b)²)b 是块大小。它的优势是实现简单、并行度高缺点是块边界处的信息会被硬切断。工程上为了缓解这个问题通常会加一个跨块的滑动窗口或者可学习的块间摘要 token。HCA 则更偏向层次化先在细粒度上做局部注意力再把局部结果聚合成粗粒度表示在粗粒度上做全局注意力。这有点像视觉里的金字塔结构搬到序列建模上。它的优势是长程依赖建模更自然代价是实现复杂度高而且层次之间的信息聚合方式需要仔细设计否则容易出现粗粒度丢信息、细粒度算不动的两头不讨好。维度CSAHCA核心思路分块块间压缩多粒度层次聚合复杂度O(n·b (n/b)²)O(n·b n·log(n/b))实现难度中高长程建模依赖块间摘要天然层次化适合场景中等长度、高吞吐超长上下文、质量优先实际选型时我的建议是如果你的序列长度在 8K 以内CSA 足够且更省心超过 32K 且对长程依赖敏感HCA 的收益才明显。两者也可以混用浅层用 CSA 省算力深层用 HCA 保质量这也是很多混合架构的常见做法。2.3 SWA滑动窗口注意力的性价比之王SWASliding Window Attention是这几个模块里最成熟、最没有争议的。它的逻辑极其简单每个 token 只关注它前面固定窗口内的 token。复杂度直接降到 O(n·w)w 是窗口大小。但 SWA 单独用有个致命问题信息传播半径受限于窗口大小。窗口是 4096那第 10000 个 token 就永远看不到第 1 个 token。解决办法是层间窗口交错——浅层小窗口抓局部深层大窗口或者配合全局 token 抓长程。DeepSeek-V4 图里 SWA 和 CSA/HCA 并列我判断是做了分层配置一部分层用 SWA 打底一部分层用 CSA/HCA 补长程。SWA 的实现有个容易踩的坑窗口的 mask 构造方式直接影响显存。如果你用标准的注意力 mask 矩阵即使窗口很小那个 n×n 的 mask 矩阵照样占显存。正确做法是用块稀疏或者 FlashAttention 的 window 参数让 kernel 层面就知道只算窗口内。我实测过同样窗口 2048、序列 32K用完整 mask 显存占用是块稀疏实现的 6 倍以上。# 用 FlashAttention 的 window 参数实现 SWA示意 from flash_attn import flash_attn_func # window_size(left, right)因果场景下 right0 out flash_attn_func( q, k, v, causalTrue, window_size(2048, 0) # 只看前2048个token )注意window_size 的设置要和你的位置编码配合。如果用的是 RoPE窗口外的相对位置编码会失真建议在窗口边界处做位置截断或者用可外推的位置编码方案。2.4 MoE稀疏激活的工程账MoE 是 DeepSeek 系列的招牌V4 里它和上面几个注意力模块是正交的——注意力管怎么算MoE 管用多少参数算。核心机制是每个 token 只激活 top-k 个专家总参数量可以做到激活量的十几倍甚至几十倍。但 MoE 的工程复杂度全在细节里。路由器的负载均衡、专家并行时的 all-to-all 通信、token 丢弃策略、专家容量因子每一个都能让训练崩掉。我按重要性排个序第一是负载均衡。如果路由器总把 token 发给少数几个专家其他专家就是死权重等于白占显存。标准做法是加一个辅助损失aux loss惩罚负载不均但 aux loss 的系数很敏感——太小不起作用太大又干扰主任务。DeepSeek 系列用的是无辅助损失的偏置调整方案给每个专家维护一个偏置项负载高的降偏置、负载低的升偏置这样不污染主损失。第二是容量因子capacity factor。每个专家能处理的 token 数是有上限的超了就丢弃。容量因子设 1.0 意味着刚好平均分配但实际负载有波动设 1.0 会丢很多 token。设 1.25 到 1.5 比较常见代价是显存和算力浪费。这个值需要根据你的序列长度和专家数量实测调。第三是通信。专家并行时token 要从一个设备发到另一个设备all-to-all 的通信量正比于 token 数乘以隐藏维度。序列一长通信就成了瓶颈。缓解手段包括把专家分组、用更高效的通信原语、以及在 attention 和 MoE 之间做计算通信重叠。参数典型值影响专家总数64-256总参数量激活专家数 top-k2-8单 token 算力容量因子1.25-1.5token 丢弃率辅助损失系数0.001-0.01负载均衡强度专家并行度依集群而定通信开销3. 模块协同为什么不能单独调参3.1 注意力稀疏度与 MoE 激活量的耦合这是最容易被忽视的一点。很多人以为注意力模块和 MoE 是独立的可以分别调优。实际上它们通过显存预算和计算图调度强耦合。举个具体的账假设序列长度 32K隐藏维度 4096注意力用 SWA 窗口 2048。注意力部分的 KV cache 是 32K × 4096 × 2K和V× 层数。如果 MoE 激活的专家多每层的 FFN 中间激活就大留给 KV cache 的显存就少。反过来如果注意力用 CSA/HCA 把 KV cache 压小了MoE 就能多激活几个专家。我实际调的时候会先固定一个显存预算然后在这几个量之间做权衡KV cache 大小 序列长度 × KV头数 × head_dim × 2 × 层数 × 精度字节MoE 激活显存 ≈ token数 × top-k × 专家中间维度 × 精度字节两者之和不能超过单卡显存减去模型权重和优化器状态这个账算清楚之后你会发现很多为什么这个配置跑不起来的问题本质就是显存超了而不是代码有 bug。3.2 mHC 与深层注意力的配合mHC 放在残差路径上它的效果和注意力层的深度直接相关。注意力层越深残差流累积的方差越大mHC 的调节作用越明显。但这里有个反直觉的点mHC 的缩放不能太激进。如果缩放系数压得太狠深层注意力层的输入信号被削弱反而学不到东西。我的经验是 mHC 的缩放系数在浅层保持接近 1.0从中间层开始缓慢衰减到最后一层大概 0.7 到 0.8。这个衰减曲线用余弦或者对数都行关键是别让它在前几层就掉下去。有次我图省事用了统一的 0.8结果浅层注意力几乎没学到东西验证集指标比 baseline 还差。3.3 SWA 与 CSA/HCA 的分层策略分层配置不是随便分的。基本原则是浅层感受野小、深层感受野大。因为浅层主要抓局部语法和词法特征SWA 足够深层需要整合全局语义才需要 CSA/HCA 的长程能力。一个我验证过的配置比例是前 1/3 层用 SWA中间 1/3 用 CSA后 1/3 用 HCA。这个比例不是金科玉律但比全部用一种或者随机混要稳。调整的时候建议一次只动一个模块的层数分配观察验证集上的长程依赖任务比如长文档问答指标变化。4. 实操复现从零搭一个简化版4.1 环境与依赖准备复现这套架构不需要真的去训一个 V4 规模的模型我们可以搭一个小号版本验证各模块是否 work。硬件上单卡 24G 显存足够跑一个 1B 左右激活参数的版本。依赖方面核心是 PyTorch 2.1 和 FlashAttention 2.5。FlashAttention 的版本很关键低版本不支持 window 参数SWA 就得自己写 mask效率差很多。pip install torch2.1.0 pip install flash-attn2.5.0 --no-build-isolation pip install transformers4.40.0提示flash-attn 编译很吃内存建议在内存 64G 以上的机器上编译或者直接用预编译 wheel。编译时如果报 CUDA 版本不匹配先确认 nvcc 和 torch 的 CUDA 版本一致。4.2 注意力模块的实现要点先实现 SWA因为它最简单可以作为 baseline。关键是用 FlashAttention 的 window 参数而不是自己构造 mask。import torch import torch.nn as nn from flash_attn import flash_attn_func class SWAttention(nn.Module): def __init__(self, dim, num_heads, window_size2048): super().__init__() self.num_heads num_heads self.head_dim dim // num_heads self.window_size window_size self.qkv nn.Linear(dim, dim * 3, biasFalse) self.proj nn.Linear(dim, dim, biasFalse) def forward(self, x): B, N, C x.shape qkv self.qkv(x).reshape(B, N, 3, self.num_heads, self.head_dim) q, k, v qkv.unbind(dim2) # flash_attn_func 要求 (B, N, H, D) out flash_attn_func( q, k, v, causalTrue, window_size(self.window_size, 0) ) out out.reshape(B, N, C) return self.proj(out)CSA 的实现要复杂一些核心是分块和块间摘要。我简化成一个可运行的版本class CSAttention(nn.Module): def __init__(self, dim, num_heads, chunk_size512): super().__init__() self.chunk_size chunk_size self.num_heads num_heads self.head_dim dim // num_heads self.qkv nn.Linear(dim, dim * 3, biasFalse) # 块间摘要把每个块压成一个 token self.chunk_summary nn.Linear(dim, dim, biasFalse) self.proj nn.Linear(dim, dim, biasFalse) def forward(self, x): B, N, C x.shape # 补齐到 chunk_size 的整数倍 pad (self.chunk_size - N % self.chunk_size) % self.chunk_size if pad: x torch.cat([x, x.new_zeros(B, pad, C)], dim1) Np x.shape[1] n_chunks Np // self.chunk_size # 块内完整注意力 xc x.reshape(B, n_chunks, self.chunk_size, C) qkv self.qkv(xc).reshape(B, n_chunks, self.chunk_size, 3, self.num_heads, self.head_dim) q, k, v qkv.unbind(dim3) q q.reshape(B * n_chunks, self.chunk_size, self.num_heads, self.head_dim) k k.reshape(B * n_chunks, self.chunk_size, self.num_heads, self.head_dim) v v.reshape(B * n_chunks, self.chunk_size, self.num_heads, self.head_dim) local_out flash_attn_func(q, k, v, causalTrue) local_out local_out.reshape(B, n_chunks, self.chunk_size, C) # 块间用块均值做摘要在摘要上做注意力 summary xc.mean(dim2) # (B, n_chunks, C) summary self.chunk_summary(summary) # 这里简化处理实际应该用完整的注意力 global_ctx summary.mean(dim1, keepdimTrue) # (B, 1, C) global_ctx global_ctx.expand(-1, n_chunks, -1) out local_out global_ctx.unsqueeze(2) out out.reshape(B, Np, C)[:, :N, :] return self.proj(out)这段代码是示意性的块间摘要用均值是最粗糙的做法实际应该用可学习的注意力。但它能跑通可以用来验证显存和速度是否符合预期。4.3 MoE 层的实现与路由MoE 层的关键是路由和负载均衡。下面是一个带偏置调整的简化实现class MoELayer(nn.Module): def __init__(self, dim, hidden_dim, num_experts64, top_k4): super().__init__() self.num_experts num_experts self.top_k top_k self.router nn.Linear(dim, num_experts, biasFalse) self.experts nn.ModuleList([ nn.Sequential( nn.Linear(dim, hidden_dim, biasFalse), nn.SiLU(), nn.Linear(hidden_dim, dim, biasFalse) ) for _ in range(num_experts) ]) # 负载均衡偏置不参与梯度 self.register_buffer(expert_bias, torch.zeros(num_experts)) def forward(self, x): B, N, C x.shape x_flat x.reshape(-1, C) logits self.router(x_flat) self.expert_bias weights, indices logits.topk(self.top_k, dim-1) weights torch.softmax(weights, dim-1) out torch.zeros_like(x_flat) for k in range(self.top_k): expert_idx indices[:, k] w weights[:, k].unsqueeze(-1) for e in range(self.num_experts): mask expert_idx e if mask.any(): out[mask] w[mask] * self.experts[e](x_flat[mask]) # 更新偏置训练时 if self.training: with torch.no_grad(): load torch.bincount(indices.reshape(-1), minlengthself.num_experts).float() load load / load.sum() target 1.0 / self.num_experts self.expert_bias 0.01 * (target - load) return out.reshape(B, N, C)这个实现效率不高逐专家循环但逻辑清晰适合理解。生产环境要用 grouped GEMM 或者专门的 MoE kernel。注意偏置更新的步长上面是 0.01很关键。太大导致路由震荡太小起不到均衡作用。建议从 0.001 开始观察专家负载分布再调。4.4 组装与训练配置把上面几个模块按分层策略组装起来class DeepSeekV4Block(nn.Module): def __init__(self, dim, num_heads, layer_idx, total_layers): super().__init__() self.norm1 nn.RMSNorm(dim) # 分层选择注意力类型 ratio layer_idx / total_layers if ratio 0.33: self.attn SWAttention(dim, num_heads, window_size2048) elif ratio 0.66: self.attn CSAttention(dim, num_heads, chunk_size512) else: self.attn HCAttention(dim, num_heads) # 类似CSA但层次更多 self.norm2 nn.RMSNorm(dim) self.moe MoELayer(dim, hidden_dimdim*4) # mHC 缩放 self.mhc_scale nn.Parameter(torch.tensor(1.0 - 0.3 * ratio)) def forward(self, x): h x self.mhc_scale * self.attn(self.norm1(x)) out h self.moe(self.norm2(h)) return out训练配置上学习率用 cosine schedulewarmup 2000 step峰值 3e-4。MoE 的 aux loss 系数设 0.001偏置更新步长 0.001。batch size 按显存尽量大梯度累积补足。5. 常见问题与排查实录5.1 训练不稳定loss 尖刺与梯度爆炸这是复现这类架构最常见的坑。表现是 loss 在某个 step 突然飙升然后慢慢恢复或者直接 NaN。排查顺序我一般是这样先看是不是 mHC 缩放的问题。把 mHC 缩放全部设成 1.0等于去掉如果 loss 平稳了说明是缩放系数太激进。逐步调小衰减幅度。再看 MoE 路由。打印每个专家的负载分布如果某个专家吃了 80% 的 token说明负载均衡没起作用。检查偏置更新是否真的在执行以及步长是否合适。最后看注意力。SWA 的窗口如果太小比如小于 512长程信息完全断掉loss 会卡在一个较高的平台。适当增大窗口或者增加 CSA/HCA 的层数。现象可能原因排查方法解决loss 尖刺mHC 缩放过激关闭 mHC 对比调小衰减loss 平台高SWA 窗口太小增大窗口对比增大窗口/加长程层专家负载不均偏置步长不当打印负载分布调步长/加 aux lossNaN学习率过高降 lr 对比降 lr/加 grad clip显存 OOMKV cache 过大算显存账换 CSA/HCA/减层5.2 显存账算不对为什么配置一样却 OOM这个问题我遇到过好几次最后发现是激活检查点activation checkpointing的粒度不同。开了 checkpointing 之后中间激活不保存反向时重算显存能省 30% 到 50%。但如果你只对部分层开显存账就对不上。另一个隐蔽的点是MoE 的专家参数是否用了 FSDP 或者 ZeRO。如果每个设备都存全量专家参数显存直接爆炸。正确做法是专家参数分片或者用专家并行。提示算显存账的时候别忘了优化器状态。Adam 的优化器状态是参数量的 2 倍一阶矩和二阶矩用 fp32 存的话1B 参数就是 8G 优化器状态。这个经常被忽略。5.3 长上下文效果差注意力到底有没有学到长程有时候模型能跑loss 也正常但在长文档任务上表现很差。这通常是注意力模块的配置问题。诊断方法构造一个大海捞针测试——在长序列的随机位置放一个关键信息看模型能不能检索到。如果 SWA 窗口是 2048序列 32K关键信息在开头那模型大概率找不到。这时候需要增加 CSA/HCA 的层数或者用全局 token。我实测下来纯 SWA 的模型在 32K 序列上的大海捞针准确率大概 40% 到 60%加了 CSA/HCA 之后能到 85% 以上。这个提升是实打实的不是调参能弥补的。5.4 吞吐上不去通信和 kernel 效率MoE 的 all-to-all 通信是吞吐杀手。如果发现 GPU 利用率只有 30% 到 40%大概率是在等通信。优化手段按性价比排序计算通信重叠把 attention 的计算和 MoE 的通信放在不同 stream 上让它们并行。增大 batch size通信量正比于 token 数但通信次数不随 batch 变所以大 batch 摊薄了通信开销。专家分组把专家按设备分组减少跨设备通信。用更快的通信原语NCCL 的 all-to-all 比 all-gather reduce-scatter 快但需要拓扑支持。我试过在 8 卡上跑不做重叠的时候吞吐是 1200 token/s做了重叠之后到 1800 token/s提升 50%。这个收益很可观值得花时间做。6. 一些不那么显然的经验6.1 位置编码和窗口的配合SWA 的窗口和 RoPE 的基频要一起调。RoPE 的基频决定了位置编码的分辨率基频低的时候远距离的位置编码区分度下降。如果窗口是 2048基频设 10000 是够的但如果窗口开到 8192基频最好提到 500000 以上否则窗口边缘的位置编码会失真。这个细节在论文里通常不写但实际影响很大。我调过一次基频从 10000 提到 500000长序列的检索准确率提升了 15 个百分点。6.2 MoE 的专家初始化专家初始化不能全用同一套随机种子。如果所有专家的初始权重一样路由器的梯度对每个专家都一样专家就永远学不出差异。正确做法是每个专家用不同的随机种子或者给专家的输出加一点噪声。我见过有人为了可复现把所有专家初始化成一样的结果训练完发现所有专家的权重几乎相同等于只有一个专家。这个坑很隐蔽因为 loss 曲线看起来完全正常。6.3 分层策略的验证方法怎么知道你的分层策略哪层用 SWA、哪层用 CSA是对的我的方法是做消融固定其他配置只改一层的注意力类型看验证集指标变化。如果改某一层影响很大说明这层对注意力类型敏感如果改哪层都差不多说明你的分层策略可能没起到作用。这个消融很费时间但比盲目调参靠谱。我一般会挑 3 到 5 个关键层做不用全做。6.4 训练后期的专家坍缩MoE 训练到后期经常出现专家坍缩——少数专家承担了大部分 token其他专家几乎不用。这时候负载均衡的偏置会一直增大但效果有限。缓解手段是在训练后期适当增大 aux loss 系数或者对专家使用率做硬性约束比如每个专家至少处理 1% 的 token。但硬约束会损害模型质量要谨慎用。我的经验是如果坍缩不严重最忙的专家不超过 30%可以不管如果超过 50%就要干预了。7. 这套架构适合什么场景说了这么多实现细节最后回到选型。DeepSeek-V4 这套 mHC CSA/HCA/SWA MoE 的组合不是所有场景都适合。适合的场景长上下文32K 以上、对推理成本敏感、有足够的训练算力做 MoE 的负载均衡调优。典型如长文档处理、代码仓库级理解、多轮长对话。不太适合的场景短序列4K 以内、训练资源有限、对训练稳定性要求极高不能容忍调参。短序列下 SWA 和 CSA 的优势发挥不出来MoE 的通信开销反而成了负担。如果资源有限我的建议是先上 SWA 小规模 MoE跑通了再逐步加 CSA/HCA 和 mHC。一次性全上出问题的时候你根本不知道是哪个模块的锅。我个人在实际操作中的体会是这套架构的难点不在单个模块的实现而在模块之间的联合调参。每个模块单独看都有成熟方案但凑在一起之后显存、通信、稳定性三个约束互相拉扯需要反复迭代才能找到平衡点。我前后调了大概两周才让一个 1B 激活参数的版本稳定收敛中间踩的坑基本都写在上面了。如果你也在复现类似的架构建议先把显存账算清楚再动手写代码能省很多时间。 
长河君 · 2026/10/28 7:44:50 · 阅读 1.2k DeepSeek-V4架构拆解：mHC、CSA/HCA/SWA与MoE的工程实践
1. 从一张架构图说起DeepSeek-V4 到底改了什么第一次看到 DeepSeek-V4 那张架构总览图的时候我的反应是信息量有点大。图上密密麻麻标着 mHC、CSA、HCA、SWA、MoE 这些缩写乍一看像是把近几年注意力机制和混合专家领域的热门词汇全堆在了一起。但如果你真的动手把这张图拆开、逐个模块去对照论文和开源实现会发现它其实是一条非常清晰的工程主线在保持 MoE 稀疏激活带来的算力优势前提下把注意力部分的显存和计算开销压到极致同时用 mHC 这类结构稳住深层训练的稳定性。这篇东西不是论文导读也不是官方文档的复述。我想做的是把这张配图里每个模块为什么这么设计、工程上怎么落地、踩坑点在哪讲透。适合两类人看一类是想理解当前大模型架构演进方向的算法同学另一类是要真正动手复现或魔改这类结构的工程同学。前者可以重点看设计动机和取舍逻辑后者可以重点看参数配置、显存账和实现细节。先说结论性的判断DeepSeek-V4 这套组合拳的核心矛盾是长上下文场景下注意力机制的二次复杂度与MoE 稀疏化带来的通信/调度开销之间的博弈。mHC 解决的是深层网络信号传播问题CSA/HCA/SWA 解决的是注意力怎么在长序列上省算力MoE 解决的是参数量与激活量解耦。这四者不是简单叠加而是互相牵制、需要联合调参的。下面我按这个逻辑逐层拆。2. 核心模块拆解mHC、CSA、HCA、SWA 各自在干什么2.1 mHC深层残差流的稳压器mHC 这个词在公开资料里出现得不算多从命名和它在架构图中的位置贯穿每个 Transformer Block 的残差路径来看它承担的职责和 Hyper-Connections、残差缩放这类技术是同一类问题当网络堆到几十上百层时残差流的方差会累积放大导致训练后期梯度爆炸或表示坍缩。传统的 Pre-LN 结构靠 LayerNorm 把每层输入归一化一定程度上缓解了这个问题但它有个副作用——归一化会削弱残差路径上的恒等映射特性深层信息在传递过程中被反复洗掉。mHC 的思路我理解是在残差连接上引入一个可学习的、带约束的变换让残差流在跨层传播时保持数值稳定同时不破坏恒等映射的主干。工程实现上这类模块通常表现为对残差分支做一个轻量的缩放或门控# 伪代码示意非官方实现 class mHCResidual(nn.Module): def __init__(self, dim, init_scale1.0): super().__init__() self.scale nn.Parameter(torch.ones(dim) * init_scale) self.gate nn.Linear(dim, dim, biasFalse) nn.init.zeros_(self.gate.weight) # 初始化为恒等 def forward(self, x, residual): # 门控初始为0sigmoid后约0.5训练中自适应调整 g torch.sigmoid(self.gate(x)) return residual g * self.scale * x这里有个关键细节门控的初始化必须让它接近恒等映射。如果一上来门控值随机深层网络前几个 step 就会震荡。我见过有人直接把 gate 初始化成标准正态结果 loss 曲线前 500 step 跟心电图一样改成零初始化后立刻平稳。这是实操里非常容易忽略但影响巨大的一点。另一个经验是 mHC 的缩放参数最好按层做区分浅层接近 1.0深层适当衰减。因为深层残差累积的方差更大需要更强的抑制。具体衰减系数没有标准答案我试过线性衰减和对数衰减在 60 层左右的模型上对数衰减收敛更稳。2.2 CSA 与 HCA两种互补的稀疏注意力CSA 和 HCA 是这张图里最容易被混淆的两个模块。从命名推测CSA 大概率是 Chunked/Compressed Sparse Attention 一类HCA 则是 Hierarchical/Hybrid Context Attention 一类。它们解决的是同一个问题的两个侧面如何在不牺牲太多长程建模能力的前提下把注意力的 O(n²) 降下来。CSA 的典型做法是把序列切块块内做完整注意力块间做压缩表示。这样复杂度降到 O(n·b (n/b)²)b 是块大小。它的优势是实现简单、并行度高缺点是块边界处的信息会被硬切断。工程上为了缓解这个问题通常会加一个跨块的滑动窗口或者可学习的块间摘要 token。HCA 则更偏向层次化先在细粒度上做局部注意力再把局部结果聚合成粗粒度表示在粗粒度上做全局注意力。这有点像视觉里的金字塔结构搬到序列建模上。它的优势是长程依赖建模更自然代价是实现复杂度高而且层次之间的信息聚合方式需要仔细设计否则容易出现粗粒度丢信息、细粒度算不动的两头不讨好。维度CSAHCA核心思路分块块间压缩多粒度层次聚合复杂度O(n·b (n/b)²)O(n·b n·log(n/b))实现难度中高长程建模依赖块间摘要天然层次化适合场景中等长度、高吞吐超长上下文、质量优先实际选型时我的建议是如果你的序列长度在 8K 以内CSA 足够且更省心超过 32K 且对长程依赖敏感HCA 的收益才明显。两者也可以混用浅层用 CSA 省算力深层用 HCA 保质量这也是很多混合架构的常见做法。2.3 SWA滑动窗口注意力的性价比之王SWASliding Window Attention是这几个模块里最成熟、最没有争议的。它的逻辑极其简单每个 token 只关注它前面固定窗口内的 token。复杂度直接降到 O(n·w)w 是窗口大小。但 SWA 单独用有个致命问题信息传播半径受限于窗口大小。窗口是 4096那第 10000 个 token 就永远看不到第 1 个 token。解决办法是层间窗口交错——浅层小窗口抓局部深层大窗口或者配合全局 token 抓长程。DeepSeek-V4 图里 SWA 和 CSA/HCA 并列我判断是做了分层配置一部分层用 SWA 打底一部分层用 CSA/HCA 补长程。SWA 的实现有个容易踩的坑窗口的 mask 构造方式直接影响显存。如果你用标准的注意力 mask 矩阵即使窗口很小那个 n×n 的 mask 矩阵照样占显存。正确做法是用块稀疏或者 FlashAttention 的 window 参数让 kernel 层面就知道只算窗口内。我实测过同样窗口 2048、序列 32K用完整 mask 显存占用是块稀疏实现的 6 倍以上。# 用 FlashAttention 的 window 参数实现 SWA示意 from flash_attn import flash_attn_func # window_size(left, right)因果场景下 right0 out flash_attn_func( q, k, v, causalTrue, window_size(2048, 0) # 只看前2048个token )注意window_size 的设置要和你的位置编码配合。如果用的是 RoPE窗口外的相对位置编码会失真建议在窗口边界处做位置截断或者用可外推的位置编码方案。2.4 MoE稀疏激活的工程账MoE 是 DeepSeek 系列的招牌V4 里它和上面几个注意力模块是正交的——注意力管怎么算MoE 管用多少参数算。核心机制是每个 token 只激活 top-k 个专家总参数量可以做到激活量的十几倍甚至几十倍。但 MoE 的工程复杂度全在细节里。路由器的负载均衡、专家并行时的 all-to-all 通信、token 丢弃策略、专家容量因子每一个都能让训练崩掉。我按重要性排个序第一是负载均衡。如果路由器总把 token 发给少数几个专家其他专家就是死权重等于白占显存。标准做法是加一个辅助损失aux loss惩罚负载不均但 aux loss 的系数很敏感——太小不起作用太大又干扰主任务。DeepSeek 系列用的是无辅助损失的偏置调整方案给每个专家维护一个偏置项负载高的降偏置、负载低的升偏置这样不污染主损失。第二是容量因子capacity factor。每个专家能处理的 token 数是有上限的超了就丢弃。容量因子设 1.0 意味着刚好平均分配但实际负载有波动设 1.0 会丢很多 token。设 1.25 到 1.5 比较常见代价是显存和算力浪费。这个值需要根据你的序列长度和专家数量实测调。第三是通信。专家并行时token 要从一个设备发到另一个设备all-to-all 的通信量正比于 token 数乘以隐藏维度。序列一长通信就成了瓶颈。缓解手段包括把专家分组、用更高效的通信原语、以及在 attention 和 MoE 之间做计算通信重叠。参数典型值影响专家总数64-256总参数量激活专家数 top-k2-8单 token 算力容量因子1.25-1.5token 丢弃率辅助损失系数0.001-0.01负载均衡强度专家并行度依集群而定通信开销3. 模块协同为什么不能单独调参3.1 注意力稀疏度与 MoE 激活量的耦合这是最容易被忽视的一点。很多人以为注意力模块和 MoE 是独立的可以分别调优。实际上它们通过显存预算和计算图调度强耦合。举个具体的账假设序列长度 32K隐藏维度 4096注意力用 SWA 窗口 2048。注意力部分的 KV cache 是 32K × 4096 × 2K和V× 层数。如果 MoE 激活的专家多每层的 FFN 中间激活就大留给 KV cache 的显存就少。反过来如果注意力用 CSA/HCA 把 KV cache 压小了MoE 就能多激活几个专家。我实际调的时候会先固定一个显存预算然后在这几个量之间做权衡KV cache 大小 序列长度 × KV头数 × head_dim × 2 × 层数 × 精度字节MoE 激活显存 ≈ token数 × top-k × 专家中间维度 × 精度字节两者之和不能超过单卡显存减去模型权重和优化器状态这个账算清楚之后你会发现很多为什么这个配置跑不起来的问题本质就是显存超了而不是代码有 bug。3.2 mHC 与深层注意力的配合mHC 放在残差路径上它的效果和注意力层的深度直接相关。注意力层越深残差流累积的方差越大mHC 的调节作用越明显。但这里有个反直觉的点mHC 的缩放不能太激进。如果缩放系数压得太狠深层注意力层的输入信号被削弱反而学不到东西。我的经验是 mHC 的缩放系数在浅层保持接近 1.0从中间层开始缓慢衰减到最后一层大概 0.7 到 0.8。这个衰减曲线用余弦或者对数都行关键是别让它在前几层就掉下去。有次我图省事用了统一的 0.8结果浅层注意力几乎没学到东西验证集指标比 baseline 还差。3.3 SWA 与 CSA/HCA 的分层策略分层配置不是随便分的。基本原则是浅层感受野小、深层感受野大。因为浅层主要抓局部语法和词法特征SWA 足够深层需要整合全局语义才需要 CSA/HCA 的长程能力。一个我验证过的配置比例是前 1/3 层用 SWA中间 1/3 用 CSA后 1/3 用 HCA。这个比例不是金科玉律但比全部用一种或者随机混要稳。调整的时候建议一次只动一个模块的层数分配观察验证集上的长程依赖任务比如长文档问答指标变化。4. 实操复现从零搭一个简化版4.1 环境与依赖准备复现这套架构不需要真的去训一个 V4 规模的模型我们可以搭一个小号版本验证各模块是否 work。硬件上单卡 24G 显存足够跑一个 1B 左右激活参数的版本。依赖方面核心是 PyTorch 2.1 和 FlashAttention 2.5。FlashAttention 的版本很关键低版本不支持 window 参数SWA 就得自己写 mask效率差很多。pip install torch2.1.0 pip install flash-attn2.5.0 --no-build-isolation pip install transformers4.40.0提示flash-attn 编译很吃内存建议在内存 64G 以上的机器上编译或者直接用预编译 wheel。编译时如果报 CUDA 版本不匹配先确认 nvcc 和 torch 的 CUDA 版本一致。4.2 注意力模块的实现要点先实现 SWA因为它最简单可以作为 baseline。关键是用 FlashAttention 的 window 参数而不是自己构造 mask。import torch import torch.nn as nn from flash_attn import flash_attn_func class SWAttention(nn.Module): def __init__(self, dim, num_heads, window_size2048): super().__init__() self.num_heads num_heads self.head_dim dim // num_heads self.window_size window_size self.qkv nn.Linear(dim, dim * 3, biasFalse) self.proj nn.Linear(dim, dim, biasFalse) def forward(self, x): B, N, C x.shape qkv self.qkv(x).reshape(B, N, 3, self.num_heads, self.head_dim) q, k, v qkv.unbind(dim2) # flash_attn_func 要求 (B, N, H, D) out flash_attn_func( q, k, v, causalTrue, window_size(self.window_size, 0) ) out out.reshape(B, N, C) return self.proj(out)CSA 的实现要复杂一些核心是分块和块间摘要。我简化成一个可运行的版本class CSAttention(nn.Module): def __init__(self, dim, num_heads, chunk_size512): super().__init__() self.chunk_size chunk_size self.num_heads num_heads self.head_dim dim // num_heads self.qkv nn.Linear(dim, dim * 3, biasFalse) # 块间摘要把每个块压成一个 token self.chunk_summary nn.Linear(dim, dim, biasFalse) self.proj nn.Linear(dim, dim, biasFalse) def forward(self, x): B, N, C x.shape # 补齐到 chunk_size 的整数倍 pad (self.chunk_size - N % self.chunk_size) % self.chunk_size if pad: x torch.cat([x, x.new_zeros(B, pad, C)], dim1) Np x.shape[1] n_chunks Np // self.chunk_size # 块内完整注意力 xc x.reshape(B, n_chunks, self.chunk_size, C) qkv self.qkv(xc).reshape(B, n_chunks, self.chunk_size, 3, self.num_heads, self.head_dim) q, k, v qkv.unbind(dim3) q q.reshape(B * n_chunks, self.chunk_size, self.num_heads, self.head_dim) k k.reshape(B * n_chunks, self.chunk_size, self.num_heads, self.head_dim) v v.reshape(B * n_chunks, self.chunk_size, self.num_heads, self.head_dim) local_out flash_attn_func(q, k, v, causalTrue) local_out local_out.reshape(B, n_chunks, self.chunk_size, C) # 块间用块均值做摘要在摘要上做注意力 summary xc.mean(dim2) # (B, n_chunks, C) summary self.chunk_summary(summary) # 这里简化处理实际应该用完整的注意力 global_ctx summary.mean(dim1, keepdimTrue) # (B, 1, C) global_ctx global_ctx.expand(-1, n_chunks, -1) out local_out global_ctx.unsqueeze(2) out out.reshape(B, Np, C)[:, :N, :] return self.proj(out)这段代码是示意性的块间摘要用均值是最粗糙的做法实际应该用可学习的注意力。但它能跑通可以用来验证显存和速度是否符合预期。4.3 MoE 层的实现与路由MoE 层的关键是路由和负载均衡。下面是一个带偏置调整的简化实现class MoELayer(nn.Module): def __init__(self, dim, hidden_dim, num_experts64, top_k4): super().__init__() self.num_experts num_experts self.top_k top_k self.router nn.Linear(dim, num_experts, biasFalse) self.experts nn.ModuleList([ nn.Sequential( nn.Linear(dim, hidden_dim, biasFalse), nn.SiLU(), nn.Linear(hidden_dim, dim, biasFalse) ) for _ in range(num_experts) ]) # 负载均衡偏置不参与梯度 self.register_buffer(expert_bias, torch.zeros(num_experts)) def forward(self, x): B, N, C x.shape x_flat x.reshape(-1, C) logits self.router(x_flat) self.expert_bias weights, indices logits.topk(self.top_k, dim-1) weights torch.softmax(weights, dim-1) out torch.zeros_like(x_flat) for k in range(self.top_k): expert_idx indices[:, k] w weights[:, k].unsqueeze(-1) for e in range(self.num_experts): mask expert_idx e if mask.any(): out[mask] w[mask] * self.experts[e](x_flat[mask]) # 更新偏置训练时 if self.training: with torch.no_grad(): load torch.bincount(indices.reshape(-1), minlengthself.num_experts).float() load load / load.sum() target 1.0 / self.num_experts self.expert_bias 0.01 * (target - load) return out.reshape(B, N, C)这个实现效率不高逐专家循环但逻辑清晰适合理解。生产环境要用 grouped GEMM 或者专门的 MoE kernel。注意偏置更新的步长上面是 0.01很关键。太大导致路由震荡太小起不到均衡作用。建议从 0.001 开始观察专家负载分布再调。4.4 组装与训练配置把上面几个模块按分层策略组装起来class DeepSeekV4Block(nn.Module): def __init__(self, dim, num_heads, layer_idx, total_layers): super().__init__() self.norm1 nn.RMSNorm(dim) # 分层选择注意力类型 ratio layer_idx / total_layers if ratio 0.33: self.attn SWAttention(dim, num_heads, window_size2048) elif ratio 0.66: self.attn CSAttention(dim, num_heads, chunk_size512) else: self.attn HCAttention(dim, num_heads) # 类似CSA但层次更多 self.norm2 nn.RMSNorm(dim) self.moe MoELayer(dim, hidden_dimdim*4) # mHC 缩放 self.mhc_scale nn.Parameter(torch.tensor(1.0 - 0.3 * ratio)) def forward(self, x): h x self.mhc_scale * self.attn(self.norm1(x)) out h self.moe(self.norm2(h)) return out训练配置上学习率用 cosine schedulewarmup 2000 step峰值 3e-4。MoE 的 aux loss 系数设 0.001偏置更新步长 0.001。batch size 按显存尽量大梯度累积补足。5. 常见问题与排查实录5.1 训练不稳定loss 尖刺与梯度爆炸这是复现这类架构最常见的坑。表现是 loss 在某个 step 突然飙升然后慢慢恢复或者直接 NaN。排查顺序我一般是这样先看是不是 mHC 缩放的问题。把 mHC 缩放全部设成 1.0等于去掉如果 loss 平稳了说明是缩放系数太激进。逐步调小衰减幅度。再看 MoE 路由。打印每个专家的负载分布如果某个专家吃了 80% 的 token说明负载均衡没起作用。检查偏置更新是否真的在执行以及步长是否合适。最后看注意力。SWA 的窗口如果太小比如小于 512长程信息完全断掉loss 会卡在一个较高的平台。适当增大窗口或者增加 CSA/HCA 的层数。现象可能原因排查方法解决loss 尖刺mHC 缩放过激关闭 mHC 对比调小衰减loss 平台高SWA 窗口太小增大窗口对比增大窗口/加长程层专家负载不均偏置步长不当打印负载分布调步长/加 aux lossNaN学习率过高降 lr 对比降 lr/加 grad clip显存 OOMKV cache 过大算显存账换 CSA/HCA/减层5.2 显存账算不对为什么配置一样却 OOM这个问题我遇到过好几次最后发现是激活检查点activation checkpointing的粒度不同。开了 checkpointing 之后中间激活不保存反向时重算显存能省 30% 到 50%。但如果你只对部分层开显存账就对不上。另一个隐蔽的点是MoE 的专家参数是否用了 FSDP 或者 ZeRO。如果每个设备都存全量专家参数显存直接爆炸。正确做法是专家参数分片或者用专家并行。提示算显存账的时候别忘了优化器状态。Adam 的优化器状态是参数量的 2 倍一阶矩和二阶矩用 fp32 存的话1B 参数就是 8G 优化器状态。这个经常被忽略。5.3 长上下文效果差注意力到底有没有学到长程有时候模型能跑loss 也正常但在长文档任务上表现很差。这通常是注意力模块的配置问题。诊断方法构造一个大海捞针测试——在长序列的随机位置放一个关键信息看模型能不能检索到。如果 SWA 窗口是 2048序列 32K关键信息在开头那模型大概率找不到。这时候需要增加 CSA/HCA 的层数或者用全局 token。我实测下来纯 SWA 的模型在 32K 序列上的大海捞针准确率大概 40% 到 60%加了 CSA/HCA 之后能到 85% 以上。这个提升是实打实的不是调参能弥补的。5.4 吞吐上不去通信和 kernel 效率MoE 的 all-to-all 通信是吞吐杀手。如果发现 GPU 利用率只有 30% 到 40%大概率是在等通信。优化手段按性价比排序计算通信重叠把 attention 的计算和 MoE 的通信放在不同 stream 上让它们并行。增大 batch size通信量正比于 token 数但通信次数不随 batch 变所以大 batch 摊薄了通信开销。专家分组把专家按设备分组减少跨设备通信。用更快的通信原语NCCL 的 all-to-all 比 all-gather reduce-scatter 快但需要拓扑支持。我试过在 8 卡上跑不做重叠的时候吞吐是 1200 token/s做了重叠之后到 1800 token/s提升 50%。这个收益很可观值得花时间做。6. 一些不那么显然的经验6.1 位置编码和窗口的配合SWA 的窗口和 RoPE 的基频要一起调。RoPE 的基频决定了位置编码的分辨率基频低的时候远距离的位置编码区分度下降。如果窗口是 2048基频设 10000 是够的但如果窗口开到 8192基频最好提到 500000 以上否则窗口边缘的位置编码会失真。这个细节在论文里通常不写但实际影响很大。我调过一次基频从 10000 提到 500000长序列的检索准确率提升了 15 个百分点。6.2 MoE 的专家初始化专家初始化不能全用同一套随机种子。如果所有专家的初始权重一样路由器的梯度对每个专家都一样专家就永远学不出差异。正确做法是每个专家用不同的随机种子或者给专家的输出加一点噪声。我见过有人为了可复现把所有专家初始化成一样的结果训练完发现所有专家的权重几乎相同等于只有一个专家。这个坑很隐蔽因为 loss 曲线看起来完全正常。6.3 分层策略的验证方法怎么知道你的分层策略哪层用 SWA、哪层用 CSA是对的我的方法是做消融固定其他配置只改一层的注意力类型看验证集指标变化。如果改某一层影响很大说明这层对注意力类型敏感如果改哪层都差不多说明你的分层策略可能没起到作用。这个消融很费时间但比盲目调参靠谱。我一般会挑 3 到 5 个关键层做不用全做。6.4 训练后期的专家坍缩MoE 训练到后期经常出现专家坍缩——少数专家承担了大部分 token其他专家几乎不用。这时候负载均衡的偏置会一直增大但效果有限。缓解手段是在训练后期适当增大 aux loss 系数或者对专家使用率做硬性约束比如每个专家至少处理 1% 的 token。但硬约束会损害模型质量要谨慎用。我的经验是如果坍缩不严重最忙的专家不超过 30%可以不管如果超过 50%就要干预了。7. 这套架构适合什么场景说了这么多实现细节最后回到选型。DeepSeek-V4 这套 mHC CSA/HCA/SWA MoE 的组合不是所有场景都适合。适合的场景长上下文32K 以上、对推理成本敏感、有足够的训练算力做 MoE 的负载均衡调优。典型如长文档处理、代码仓库级理解、多轮长对话。不太适合的场景短序列4K 以内、训练资源有限、对训练稳定性要求极高不能容忍调参。短序列下 SWA 和 CSA 的优势发挥不出来MoE 的通信开销反而成了负担。如果资源有限我的建议是先上 SWA 小规模 MoE跑通了再逐步加 CSA/HCA 和 mHC。一次性全上出问题的时候你根本不知道是哪个模块的锅。我个人在实际操作中的体会是这套架构的难点不在单个模块的实现而在模块之间的联合调参。每个模块单独看都有成熟方案但凑在一起之后显存、通信、稳定性三个约束互相拉扯需要反复迭代才能找到平衡点。我前后调了大概两周才让一个 1B 激活参数的版本稳定收敛中间踩的坑基本都写在上面了。如果你也在复现类似的架构建议先把显存账算清楚再动手写代码能省很多时间。