大模型残差流冗余诊断与合并优化：从mHC架构看Scaling Law失效的破解思路

那天我在技术社区刷到一条帖子，标题很扎眼：某开源大模型的新版本V4-Flash用了mHC架构，四条残差流被砍成两条，效果反而更好。紧接着某头部技术企业实验室放出了相关论文，核心观点直接指向"大模型架构存在隐形天花板"。我第一反应是标题党，可顺着论文里的实验日志、消融数据和训练曲线看下来，发现这件事比"砍两条流"本身严重得多——它动摇了我们过去几年默认的架构设计前提。

这篇文章我会把mHC的四条残差流到底怎么分工讲清楚，说明论文作者为什么敢说"只用两条"，再分享我复现诊断流程时踩过的坑，最后聊一聊残差流合并的实操方案。如果你是做大模型预训练、微调、或者在做架构选型时对Scaling Law失效感到困惑的工程师和研究者，这篇应该能提供一些新的参照系。

1. 一个让我反复看了三遍的结论：砍掉两条残差流，反而更好

1.1 mHC是什么，四条残差流为什么被设计出来

mHC（multi-path Hybrid Cascade，多路径混合级联）不是什么横空出世的花架子架构，它想解决的是大模型层数加深之后一个很实际的问题：信息在深层网络传播过程中会被逐步稀释。标准Transformer只有一条残差流贯穿所有层，每一层的注意力输出和MLP输出都要往同一条残差流上叠加。层数少的时候还好，层数一旦超过几十层，深层表示就会慢慢"忘记"早期输入里的细粒度信息。

mHC的思路是让多条不同粒度的信息流并行穿过层栈，每条流分别和Attention、MLP交互，最后在输出端融合。论文里明确设计了四条：

• token级高频语义流：负责词级别的局部信息，比如拼写、短距离搭配、当前token的即时状态。
• chunk级短程上下文流：以短语和短窗口为单位，承载相邻token之间的结构性依赖。
• sentence级中程语义流：对应句子级别的语义完整性，处理跨多个短语的依赖。
• task级全局目标信号流：把任务指令、全局目标这类偏"慢变量"的信息单独传递，避免被每层的即时计算冲掉。

这个设计逻辑听起来很自洽。不同粒度的信息确实应该走不同带宽的通道，否则token级的高频变化会把全局任务信号淹没在噪声里。mHC想做的是在架构层面就把这些问题区分开，而不是靠训练损失去隐式调和。

1.2 实验为什么敢说"只用两条"

论文的实验不是靠直觉拍的。作者对四条残差流做了一轮非常系统的消融：先逐条清零，再两两配对保留，最后只保留单条，分别在通用理解任务、长文本摘要、代码生成、多轮对话几个方向各评测一遍。

结果相当反直觉：

• 只保留token级流和chunk级流，通用理解任务（GLUE类数据集）的平均掉点只有0.27%。
• 长文本摘要和代码任务上，砍掉sentence级流和task级流之后不仅没掉点，反而涨了0.6%到0.9%。
• 训练吞吐提升了约18%，显存占用下降约20%。

作者还专门做了"反向验证"：把被砍掉的两条流以低秩投影方式合并回chunk级流，效果几乎不变，说明不是"信息丢了但没有被测试覆盖到"，而是这些信息本来就被chunk级流的主干空间承载了。

我第一次看到这个结论的时候很不服气，觉得可能是评估集太窄，或者模型规模太小。但论文里附了从1B到14B四个不同规模的模型，结论方向一致。这不是偶然。

1.3 为什么这个结果会"炸场"

这个结果让人不舒服的地方在于，它挑战了两个我们长期默认的假设。

第一个假设是"架构越复杂越好"。过去几年，混合架构、多专家机制、多维并行残差流，大家倾向于认为把结构做复杂就能获得更好的信息传递能力。mHC用四流并行换来比传统单流更好的性能，这本身没问题，但砍掉两流之后性能不降反升，这说明当初加那两条流，本质上是在用一个"看似合理的设计"换取了额外的算力和显存开销，而信息论层面的收益非常有限。

第二个假设是"残差流越多，信息传递越充分"。信息传递是否充分，取决于每条流是否真的在传递不同的信息。如果两条流到中后期已经在反复改写彼此的内容，那它们就不是"并行通道"，而是"同一通道的冗余副本"。这句话放到任何大模型架构上都成立，这也是"隐形天花板"的第一个信号。

2. 冗余到底藏在哪里：逐层量化残差流贡献度后的三个发现

2.1 量化方法：互信息、边际loss贡献与层间消融

要判断一条残差流是不是冗余，不能只靠"去掉它看效果"。我需要更精细的量化手段。复现过程中我先后用了三种方法，各有侧重。

第一种是互信息估计。在每一层给残差流激活加一个线性探针，分别去预测token级标签、chunk级标签、sentence级标签和task级标签，看每条流对哪一类信息的互信息最高。这个方法的优点是判断"信息是否被承载"很直接，缺点是探针本身有上限，只能说明"能够被读取"，不能说明"模型真的在依赖它"。

第二种是边际loss贡献。把某条流清零之后重新跑前向，记录验证集loss的上升幅度。上升大说明重要，上升小说明可替代。这个指标比探针更贴近真实依赖关系。

第三种是层间消融。不整条删掉，而是只屏蔽某一段区间（比如第10层到第20层）的某条残差流，观察性能曲线的变化。这个方法能定位出冗余是从哪一层开始出现的，对后续合并策略的制定最有帮助。

# 伪代码：逐层残差流消融框架 import torch def residual_stream_ablation(model, stream_names, layer_range): """ 对指定残差流、指定层区间做屏蔽消融。 stream_names: 各残差流名称，如 ['token', 'chunk', 'sentence', 'task'] layer_range: 需要屏蔽的层区间，如 (10, 20) """ results = {} for stream in stream_names: losses = [] for batch in val_dataloader: # 前向时对目标区间清零残差流 with torch.no_grad(): logits, loss = model(batch, zero_streams={stream: layer_range}) losses.append(loss.item()) results[stream] = {"avg_loss": sum(losses)/len(losses), "delta": sum(losses)/len(losses) - baseline_loss} return results

2.2 发现一：sentence级流和task级流在浅层就饱和了

第一轮互信息实验跑完，数据已经很说明问题。token级流和chunk级流在整个层栈里始终维持着较高的活跃互信息，尤其是chunk级流，从第8层开始稳步上升，到第30层左右才趋于平缓。

sentence级流不一样。它在前10层确实承载了比较多的句子级语义信息，但从第15层开始，它与chunk级流的互信息开始急剧上升，与句子级标签的互信息反而不再增长。这说明它不是没有用，而是它的"作用窗口"很窄，只在浅层有独立价值。

task级流的情况更极端。它在最开始的几层对任务指令类标签有很高的可读性，但进入中层之后，相关信息似乎已经通过注意力机制被"拷贝"到了每一层的上下文里，独立流的存在变得多余。用互信息的术语说，给定chunk级流激活的条件下，task级流的信息熵条件减少量趋近于零——它只是在重复其他流已经表达过的内容。

2.3 发现二：冗余流与主流的互信息随层数飙升

第二个发现解释了为什么"合并"能够成功。

我计算了四条流两两之间的互信息随层数的变化。token级流和chunk级流之间的互信息全程保持在一个中等偏低水平，两条流确实在传递不同粒度的信息。但sentence级流和task级流与chunk级流的互信息，从中层开始一路走高，到深层几乎完全重叠。

这个现象用大白话说就是：到模型深处，sentence级流和task级流在做的事情，基本等于"用另一种方式把chunk级流的内容重新表述一遍"。如果只是重新表述，那它们在信息论上是完全冗余的。这不是bug，而是训练动态的自然结果——模型在中后期学会了把更多信息集中在主流的表示空间里，因为那个空间的信噪比更高。额外的流并没有创造出新的信息维度，只是让部分梯度流向了更宽的参数空间。

这也解释了为什么砍掉它们不仅不掉点，甚至可能涨点：冗余流的存在会让模型花一部分容量去维护"多份一致表示"，去掉之后，这部分容量被释放，注意力模块和MLP可以更专注地利用主流空间做更高层的抽象。

2.4 发现三：消融动态与任务差异——不能一刀切

不过要说清楚，这四条残差流并不是在所有任务上都表现出同样的冗余程度。

我做了逐任务细拆。在代码评测上，去掉sentence级流收益最大，掉点几乎为零，涨点最明显。代码任务的语法边界非常清晰，chunk级信息足够覆盖大多数依赖，sentence级流反而引入了不必要的全局平滑。在长文本摘要上，去掉task级流有正面效果，但去掉sentence级流会带来轻微的连贯性下降。这说明sentence级流里的信息，有一部分是真正跟"跨句语义"相关的，只是在通用理解任务里，我们现有的评估方法很难把这类收益显式观测出来。

这类任务差异给出一个重要提醒：残差流冗余度不是一个定值，它依赖数据分布和评估维度。诊断时至少要在三类任务上分别做消融，只看通用榜单很容易得出"可以随便砍"的激进结论。

3. 大模型架构撞上的"隐形天花板"：不止mHC一家

3.1 三个现象已经在暗示天花板的存在

我在前两年做大模型评估的时候就注意到，很多模型跑着跑着会遇到一些难以解释的停滞：

• 现象一：增加参数量，训练loss不再按预期曲线下降。同样数据量下，14B模型的loss只比7B低一点点，远低于理论收益。
• 现象二：中间层激活的相似度持续升高。把第20层和第40层的激活做CKA相似度，发现越大的模型相似度越高，说明深层表示越来越"挤"在一起。
• 现象三：模型长大后，指令跟随能力提升进入平台期。能力没有变差，但也没有随参数量线性增长。

这三个现象放在过去会被归因于"数据不够""超参没调好"。mHC这篇论文的价值，是把它们统一解释成"架构信息带宽的瓶颈"：当残差流的有效信息维度被占满之后，继续堆参数只是在同一个信息空间里做重复拟合。

3.2 MoE和混合架构的特殊脆弱性

mHC是四条显式残差流，比较容易观察到冗余。但MoE这类隐式多路架构，冗余问题其实更隐蔽。

MoE模型通常共享单条残差流，但每条token要被路由到若干个专家上。一个常见问题是路由坍缩：训练到中后期，路由模块倾向于把绝大多数token送到同一组专家，其他专家沦为摆设。表面看是"多个专家并行"，实际有效的参数通道可能只有两三个。这和mHC的发现是同一个底层逻辑——架构提供多条路径，但训练动力学不会理所当然地去利用每一条路径。

混合架构（Attention + SSM并行）也存在类似问题。注意力流擅长长程信息，SSM流擅长压缩历史，理论上应该互补。但不少实测显示，SSM流在中后期的输出与注意力流的低频分量高度相关。要不是做逐流消融，很难发现这类重叠。

3.3 四类架构横向对比：哪些部分容易冗余

我把当前主流大模型架构放在一起做了个粗略横向对比，方便大家对照自己的模型：

这张表不是让大家看完就去砍自己模型的模块，而是提供一个诊断思路：任何架构的瓶颈，都可以从"信息通道是否真的在传递独立信息"这个角度去检查。mHC的论文只是把这个检查方法做得最系统化的一次。

4. 想自己验证？一套可复用的残差流冗余诊断流程

4.1 准备阶段：不需要复刻满血模型

很多人觉得验证这种结论得先复现一个大模型，其实不需要。我在自己的项目里用了一个1.5B左右的模型做诊断，配了64张加速卡跑了两天，就得到了和论文方向一致的结果。对绝大多数团队来说，用一个中等规模模型验证"冗余是否存在于自己的架构里"，完全够用。

你需要准备的东西：

• 一个已完成预训练（或至少完成了50%以上训练计划）的模型，规模1B-3B均可。
• 至少两类差异明显的评测数据集：一类偏局部依赖（如代码补全、命名实体识别），一类偏长程依赖（如长文本摘要、多跳问答）。
• 稳定的评估管线，保证每次消融结果在同一个随机种子下的标准差小于0.3%。

提示：千万不要用训练没收敛的模型做残差流消融，未收敛状态下所有流看起来都"重要"，因为模型还在用所有通道拟合基础分布。这个误判会浪费你一整轮实验周期。

4.2 步骤一：挂载hook采集各残差流激活

第一步是采集残差流激活。做法是在模型的forward函数里、每条残差流经过每个Transformer层block之后，把激活值存下来。

activations = {} def hook_fn(name): def fn(module, input, output): # 保存残差流激活的平均向量，用于后续互信息分析 activations[name].append(output.detach().float()) return fn hooks = [] for layer_idx in range(model.config.num_hidden_layers): # 假设模型实现了mHC的四流结构，分别挂上hook for stream in ['token', 'chunk', 'sentence', 'task']: target_module = model.get_submodule(f'layers.{layer_idx}.streams.{stream}.out') hooks.append(target_module.register_forward_hook(hook_fn(f'{layer_idx}-{stream}'))) model.eval() with torch.no_grad(): for batch in val_dataloader: model(batch)

这一步本身不复杂，真正的坑在显存。如果每个层每条流都存全量激活，1.5B模型一次前向就可能吃掉几十GB显存。建议只存池化后的表示，比如每个token序列做均值池化，或者隔两层采一次样，对判断互信息趋势没有本质影响。

4.3 步骤二：做"再训练式"消融，而不是硬清零

这是我最想强调的一点。直接清零残差流做前向推理，得到的结果会系统性高估残差流的重要性。原因很简单：模型所有的层都在训练时适应了这条流的存在，前向时突然把它归零，下游层会进入一种它们从未见过的激活分布，损失自然飙升。但这个飙升不代表这条流承载了不可替代的信息，只代表下游层"以为"它会来。

正确的做法是"再训练式消融"：删掉某条流之后，用很小的学习率（原训练学习率的5%到10%）继续训练500到1000步，让模型适应没有这条流的环境，然后再评估。

我在自己的模型上跑了一遍对比：硬清零时，sentence级流看起来贡献了超过12%的性能；但再训练式消融后，它的实际贡献只有不到1.5%。差距大到可以在论文里当反面案例。

4.4 步骤三：画贡献度曲线，找冗余区间

把每层、每条流的再训练消融结果画成曲线，会有非常直观的发现。

正常的流应该是"重要度随层数增加而维持或上升"的曲线；冗余流则是"浅层有少量贡献、中深层贡献趋近于零甚至出现负贡献"的曲线。我在自己的模型上看到的sentence级流贡献度曲线，在第8层之前往下掉，从第10层开始贴地平移，非常典型。

判定标准我给三个：

1. 该流在超过60%的层区间内，消融后loss变化小于0.2%。
2. 该流与某条主流的互信息在层索引上呈显著上升趋势。
3. 同时删掉该流和另一条疑似冗余流，性能下降不超过单独删掉主流导致的下降。

三个条件都满足，就可以把这条流标记为"可合并冗余流"。

4.5 踩坑记录：三个容易误判的细节

诊断流程简单，但实际执行时有三个坑我花了不少时间才趟过去。

第一个是随机种子敏感性。残差流贡献度曲线在前几百步波动很大，如果只跑一个种子，很容易把某些层的随机波动当成真实信号。建议至少三个种子取均值，或者用中位数。

第二个是评估集过窄。只在一类任务上做消融，结论容易偏乐观或偏悲观。我在代码任务上消融task级流，掉点几乎为零，但换到需要严格遵循指令的对话任务上，掉了0.8%。原因是对话任务对全局目标编码的依赖更高。所以诊断时至少需要三类不同性质的任务。

第三个是warmup阶段的影响。如果消融后再训练只跑300步，学习率还在warmup区间，模型根本来不及适应新结构，loss看起来就很差。我后来把步数加到1000步，把warmup步数控制在100步内，曲线的噪声才小到可以下结论。

5. 从四条到两条：残差流合并的三套方案与实战坑位

5.1 方案一：可学习加权合并，最简单但上限有限

如果你只是想快速验证"合并是否可行"，第一套方案就够了。做法是给被合并的残差流一个可学习的缩放系数，让模型自己决定保留多少权重。

# 伪代码：可学习加权合并残差流 merged_weight = torch.nn.Parameter(torch.tensor(0.5)) # 每次前向时，主流输出 = 原主流 + 合并权重 * 冗余流输出 main_stream_out = chunk_stream_out + merged_weight * sentence_stream_out

这个方案的优点是改动极小，几乎不影响模型原始结构，训练稳定。缺点是它本质上只做了一次"加权求和"，没有改变信息空间的维度和结构。对于sentence级流这种与chunk级流重叠度极高的流，加权合并足够了；但如果两条流的重叠度不是那么高，加权合并会把独立信息也一起抹掉，导致性能损失。我的建议是，先用这个方案跑一轮，确认收益方向，再决定要不要上更复杂的方案。

5.2 方案二：低秩投影并入主流，性能上限最高

第二套方案是把冗余流先做一个低秩投影，再注入主流。这样做的好处是：冗余流中真正独立的那一小部分信息，可以通过投影矩阵保留下来；绝大部分与主流重叠的信息，在投影过程中自然被丢弃。

具体做法是：在sentence级流和chunk级流之间插入一个可学习的线性投影层，投影维度设为chunk级流维度的一半左右。训练时先冻结其他所有参数，只训练这个投影层，等loss稳定后再解冻全量训练。

我复现结果显示，低秩投影合并方案比简单加权合并的最终性能高0.15%到0.3%，尤其在长文本摘要这类对中程语义有真实需求的任务上，低秩投影能兜住那部分独立信息。代价是需要多几轮训练，整体代码复杂度也要高一些。

5.3 方案三：分阶段渐进裁剪，最稳但耗时

如果模型正在训练中，还没到收敛阶段，又想合并残差流，我推荐渐进裁剪。

第一阶段：把sentence级流的学习率降为主流的十分之一，让它的更新幅度变小。 第二阶段：把sentence级流的输出从"直接累加"改成"乘以一个线性衰减系数"，从1逐步衰减到0.1，持续训练一段时间。 第三阶段：系数衰减到0，彻底移除该流，再微调几百步。

这个方案的好处是训练过程平滑，不容易出现loss突然飙升；坏处是周期长。我在1.5B模型上走完三阶段花了一周时间。如果项目周期紧，还是优先考虑方案一或二。

合并训练的超参数我整理了一个参考表：

5.4 我的实操心得：合并后还要做两件事

合并完成不是终点，有两个细节直接影响最终效果。

第一件事是合并后重新校准LayerNorm。残差流的方差在合并之后一定会变化，如果不重新估计LayerNorm的均值和方差，中深层激活会出现数值漂移，表现为少量样本上突然生成乱码。我习惯合并后用几百条干净数据重新跑一遍前向，统计各层激活的均值和方差，然后替换掉旧的LayerNorm统计量。

第二件事是给下游任务微调留更多余地。合并后的主流空间虽然信息更紧凑，但任务相关的可塑性反而更高了。微调时把LoRA的rank从32提到48，在代码生成和指令遵循上分别有0.3%和0.2%左右的额外提升。原因推测是去掉了冗余流之后，模型的部分容量被释放，微调时能把更多信息压进低秩空间。

在我的实际项目里，这套诊断加合并流程带来的收益是：推理显存下降约18%，训练吞吐提升约16%，通用任务评估掉点控制在0.2%以内。在长文本摘要上还有0.5%左右的提升。

另外说一个不能忽略的前提——训练早期不要急着合并。我在一个只训练了30%的模型上尝试过早合并，结果主流的损失反向传播信号不足以支撑模型重新组织表示，导致收敛速度明显变慢。残差流冗余普遍出现在训练中后期，也就是模型已经形成了稳定的表示层级之后。判断时间点的方法很简单：连续五个checkpoint的验证loss不再明显下降，再开始做诊断和合并。

最后分享一个小技巧。做残差流诊断的时候，不要只盯着"去掉某条流后loss涨了多少"这一个数字。把每层的贡献度曲线、流与流之间的互信息曲线、任务维度的差异张数据都保存下来。模型下次版本迭代时，这些数据能直接指导"哪里该加容量、哪里该减结构"。我现在每个架构项目都会预留这份诊断报告，省掉了大量重复排查时间。