那天我在技术社区刷到一条帖子标题很扎眼某开源大模型的新版本V4-Flash用了mHC架构四条残差流被砍成两条效果反而更好。紧接着某头部技术企业实验室放出了相关论文核心观点直接指向大模型架构存在隐形天花板。我第一反应是标题党可顺着论文里的实验日志、消融数据和训练曲线看下来发现这件事比砍两条流本身严重得多——它动摇了我们过去几年默认的架构设计前提。这篇文章我会把mHC的四条残差流到底怎么分工讲清楚说明论文作者为什么敢说只用两条再分享我复现诊断流程时踩过的坑最后聊一聊残差流合并的实操方案。如果你是做大模型预训练、微调、或者在做架构选型时对Scaling Law失效感到困惑的工程师和研究者这篇应该能提供一些新的参照系。1. 一个让我反复看了三遍的结论砍掉两条残差流反而更好1.1 mHC是什么四条残差流为什么被设计出来mHCmulti-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 results2.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 四类架构横向对比哪些部分容易冗余我把当前主流大模型架构放在一起做了个粗略横向对比方便大家对照自己的模型架构类型典型残差流形态冗余高风险区剪枝难度典型瓶颈表现标准Transformer单条残差流贯穿全层相邻层之间的表示坍缩中低深层次层激活相似度升高MoE单条共享残差流 多专家路由路由坍缩专家利用率不均高稀疏专家并不稀疏Hybrid AttentionSSM双流并行SSM流与注意力低频分量重叠中加了SSM分支但长程任务不涨点mHC多路径级联多条显式残差流中深层的低粒度流冗余中并行流之间互信息飙升这张表不是让大家看完就去砍自己模型的模块而是提供一个诊断思路任何架构的瓶颈都可以从信息通道是否真的在传递独立信息这个角度去检查。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(flayers.{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层开始贴地平移非常典型。判定标准我给三个该流在超过60%的层区间内消融后loss变化小于0.2%。该流与某条主流的互信息在层索引上呈显著上升趋势。同时删掉该流和另一条疑似冗余流性能下降不超过单独删掉主流导致的下降。三个条件都满足就可以把这条流标记为可合并冗余流。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模型上走完三阶段花了一周时间。如果项目周期紧还是优先考虑方案一或二。合并训练的超参数我整理了一个参考表超参数加权合并低秩投影合并渐进裁剪学习率原始LR的20%原始LR的10%原始LR的30%训练步数300-500步500-1000步三阶段共1500步冻结策略全量放开先冻结主干只训练投影层分阶段放开预期收益吞吐提升15%左右吞吐质量双提升最稳定但耗时5.4 我的实操心得合并后还要做两件事合并完成不是终点有两个细节直接影响最终效果。第一件事是合并后重新校准LayerNorm。残差流的方差在合并之后一定会变化如果不重新估计LayerNorm的均值和方差中深层激活会出现数值漂移表现为少量样本上突然生成乱码。我习惯合并后用几百条干净数据重新跑一遍前向统计各层激活的均值和方差然后替换掉旧的LayerNorm统计量。第二件事是给下游任务微调留更多余地。合并后的主流空间虽然信息更紧凑但任务相关的可塑性反而更高了。微调时把LoRA的rank从32提到48在代码生成和指令遵循上分别有0.3%和0.2%左右的额外提升。原因推测是去掉了冗余流之后模型的部分容量被释放微调时能把更多信息压进低秩空间。在我的实际项目里这套诊断加合并流程带来的收益是推理显存下降约18%训练吞吐提升约16%通用任务评估掉点控制在0.2%以内。在长文本摘要上还有0.5%左右的提升。另外说一个不能忽略的前提——训练早期不要急着合并。我在一个只训练了30%的模型上尝试过早合并结果主流的损失反向传播信号不足以支撑模型重新组织表示导致收敛速度明显变慢。残差流冗余普遍出现在训练中后期也就是模型已经形成了稳定的表示层级之后。判断时间点的方法很简单连续五个checkpoint的验证loss不再明显下降再开始做诊断和合并。最后分享一个小技巧。做残差流诊断的时候不要只盯着去掉某条流后loss涨了多少这一个数字。把每层的贡献度曲线、流与流之间的互信息曲线、任务维度的差异张数据都保存下来。模型下次版本迭代时这些数据能直接指导哪里该加容量、哪里该减结构。我现在每个架构项目都会预留这份诊断报告省掉了大量重复排查时间。