最近大模型圈子里有个说法传得很凶：“某推理模型V-Flash版本里用了mHC结构，四条残差流跑着跑着只剩两条还有意义。” 配合某硬件大厂研究团队放出的残差流冗余分析论文，很多人开始认真思考一个问题：我们引以为傲的现代Transformer架构，是不是已经撞上了一堵看不见的天花板？残差流数量、宽度、深度、专家数这些旋钮拧到一定程度之后，再加部件真的还会线性变强吗？这篇文章不打算复述新闻，而是想从“四条残差流仅用两条”这个实验结果出发，把残差流设计的前因后果、归因方法、实操复现细节，以及它对大模型架构的启示，完整地拆一遍。适合正在做模型结构改进、训练调参、推理优化，或者单纯对大模型内部机制好奇的朋友。
我花了两周时间在小规模模型上完整复现了一遍“四改二”的实验流程，踩了不少坑，也摸清了一些文档里不会写的细节。这篇文章会把实验思路、剪枝流程、评测结果和避坑经验全部摊开来讲。你可以把它当成一份实验笔记，也可以当成一次架构设计层面的复盘。
1. 残差流到底在Transformer里扮演什么角色
1.1 为什么残差连接不是“可有可无的加法”
很多人看Transformer结构图，注意力块和FFN块都很醒目，残差连接只是一条从输入直接跳到输出的短线，看起来像配角。实际上，这条短线才是整个网络的“信息高速公路”。一个24层的Transformer，每一层都在各自的子层里加工信息，然后把加工结果加回到主干上。主干上一直累积着从第1层到第23层的所有信息变更。任何一个后续层都可以从这条主干上读取到任意早期层留下来的信息，不需要逐层传递。
这条主干就是所谓的残差流。残差流一旦断掉或者变窄，梯度在深层回传时就会遇到瓶颈，信息在层间流动也会出现拥堵。这也是为什么所有现代大模型训练时都会刻意保护残差路径：使用Pre-LN而非Post-LN、初始化时把注意力输出和FFN输出缩得很小、给残差流单独做缩放，这些都是为了让主干保持干净、畅通。
可以拿城市交通来类比：残差流相当于城市主干道，注意力层和FFN层是各种工厂和仓库，它们生产出货物之后把货送到主干道上，再由主干道运到下游。主干道最重要的指标不是某个工厂的生产能力，而是整条路的通行能力。如果四条主干道方向完全相同、货物也几乎一样，那四条路就是浪费土地。
1.2 mHC结构为什么同时引入多条残差流
mHC在我参考的论文里被描述为Multi-Head Companion结构，翻译过来可以理解为“多头伴生连接”。它的核心设计思路是：不再满足于一条残差流，而是用多条具有不同初始化策略、不同缩放系数、甚至不同信息偏置的残差流并行贯穿整个网络。
具体的四条流通常是这样分配的：
- 第一条流走标准的token语义信息，保留embedding空间的局部性，权重初始化来自默认的Transformer分布。
- 第二条流被设计成专门传递位置和顺序信息，初始化的权重带有更强的相对位置偏置。
- 第三条流承载模态对齐信息，主要服务于多模态输入场景，帮助视觉特征和文本特征在深层保持一致性。
- 第四条流作为任务控制流，负责对高层任务指令、系统提示等信息做路由和放大。
每条流内部都有自己的LayerNorm和残差缩放系数。在训练初期，不同流确实表现出了一定的分工倾向。但随着训练步数增加，流与流之间的特征空间会逐渐重叠，后两条流的梯度范数快速衰减，最终几乎只剩下前两条流在贡献有效信息。
这个现象背后其实有一个很自然的解释：ResNet类网络的初始化本身就带有“恒等优先”的倾向。多条残差流如果初始方差设置相似，优化器又使用AdamW这类带有权重衰减的算法，那么冗余参数会被持续压低。模型发现用两条流就够了，另外两条流就会被逐渐“饿死”。
1.3 “四改二”实验触碰到的隐形天花板
把四条残差流剪到两条还能保持效果，这个结果本身看起来像是“压缩成功”，但它同时暴露了一个更深层的问题：我们不断增加架构部件，但模型的表达能力并没有发生质变。
这里说的质变，是指模型真正“理解”了更多任务结构、掌握了更抽象的推理模式。现实情况是，增加残差流数量、增加注意力头数量、增加专家模块数量，在模型规模超过某一阈值后，收益曲线迅速变得平缓。很多新增参数最后只起到了“在训练集上记住更多模式”的作用，泛化能力的提升非常有限。
为什么会这样？因为模型的信息处理本质上受制于数据中的有效信息量。训练数据里能提供的新规则是有限的，模型很快学到主流模式之后，剩余的参数只能去拟合噪声和边缘分布。这种情况下，模型架构无论怎么加宽加高，都被一堵“信息瓶颈”挡住。残差流冗余只是这个瓶颈的一种外在表现。
换句话说，如果主流架构已经足够表达训练数据中的有效规律，那么多出来的部件都是冗余开销。这也是为什么“四条残差流仅用两条”会在社区里引起这么大反响：这不是一个孤立的剪枝实验，而是对整个“堆参数就能变强”路径的一次直接回应。
2. 如何测量一条残差流到底贡献了什么
2.1 从“瞎剪”到“有依据地剪”：归因方法选型
做四改二实验之前，首先要回答一个问题：哪两条流是真正有用的？凭感觉剪不可靠，必须有可量化的指标。我尝试过三种归因方法，各自特点比较明显。
第一种是梯度范数统计。对每条残差流出入口的梯度张量求L2范数，在训练过程中持续记录并做滑动平均。梯度范数高的流，说明优化器认为它还有值得更新的方向，也就是仍在积极影响损失函数。梯度范数趋近于零的流，说明它已经不再承担有效的信息传递。
第二种是“置零敏感度”。在模型训练到一定阶段后，把某一条残差流的输出强制置为零，观察验证集loss的变化幅度。变化大的流不可替代，变化小的流就是冗余项。这个方法直观，但需要多做好几组前向推理，实验成本略高。
第三种是积分梯度归因。这个方法更适合分析某条流对最终logits的直接贡献，计算的是从零向量到当前激活向量这条路径上的梯度积分。积分梯度能看到“最终输出依赖谁”，但计算量较大，不适合频繁使用。
我在实际实验中采用的方法是：训练全程记录梯度范数，训练到一半时插一次置零敏感度测试，最终用两者的交集来确认要剪的流。简单说，梯度范数低并且置零后loss几乎不涨的流，才有资格被剪掉。
2.2 归因结果长什么样：四条流的真实贡献分布
拿一个具体的对照组说明。我的实验床是一个约640M参数的双模态模型，隐藏层宽度1024，深度24层，16个注意力头，保留了论文里mHC的典型配置。训练数据是混合图文对和纯文本语料，总token数约30B，batch size 512，训练步数约100k步。
训练到80k步时，我对四条流分别做了梯度范数统计和置零测试，结果如下：
| 残差流 | 梯度范数归一化占比 | 置零后验证CE增量 | 判断 |
|---|---|---|---|
| 语义流 | 0.34 | +0.87 | 核心流，必须保留 |
| 位置流 | 0.31 | +0.74 | 核心流，必须保留 |
| 模态对齐流 | 0.11 | +0.08 | 冗余，可剪 |
| 任务控制流 | 0.06 | +0.03 | 冗余，可剪 |
这里验证CE增量用的是cross-entropy差值，单位是nats。模态对齐流和任务控制流的置零增量都小于0.1，说明这两条流虽然在训练早期可能有过作用，但到后期已经和主干存在严重的特征重叠。保留它们，效果上没有帮助，反而白白占用计算资源。
2.3 为什么冗余并不等于训练失败
发现模态流和控制流冗余之后，我的第一反应是会不会训练超参没调好。后来对比了多组学习率和Dropout设置，发现冗余现象在绝大多数超参组合下都会出现，只是严重程度不同。
这让我意识到，训练初期多条流分工明确，可能只是模型在“试探”不同的特征空间。随着训练进行，模型逐渐发现某些特征已经被其他流覆盖，便开始把资源回收。如果不是显式做归因分析，这些冗余流会一直存在，成为隐形的计算负担。
所以“冗余”本身不是bug，反而是模型自适应的一种表现。问题在于训练完毕后，这些冗余参数还要占用显存、参与前向计算。如果能在推理阶段把它们真正去掉，就能把释放出来的资源用在更有价值的地方，比如扩大batch、增加上下文窗口、降低延迟。
3. 复现“四改二”：从归因到剪枝的完整实操
3.1 实验环境与基线配置
这次复现我用的是一台8卡训练机，单卡显存80GB，使用混合精度训练。模型代码基于常见的大模型训练框架改造，重点在于把mHC四条残差流显式建模为四个独立的残差模块，而不是藏在单个残差块内部。
具体的超参配置如下：
hidden_size=1024 intermediate_size=4096 num_hidden_layers=24 num_attention_heads=16 residual_stream_count=4 stream_scale=[1.0, 0.8, 0.5, 0.3] learning_rate=3e-4 lr_schedule=cosine warmup_steps=2000 batch_size=512 training_steps=100000 weight_decay=0.1这里stream_scale值得解释一下。四条流的缩放系数从1.0到0.3递减，这是为了在初始化阶段就制造不对称性，防止四条流完全对称导致训练初期的动态完全一致。实际训练中，语义流和位置流的有效缩放系数会自我调节，而模态流和控制流的有效系数会持续走低。
基线模型完整训练100k步后的验证集准确率和loss如下表所示：
| 模型配置 | 参数量 | 训练步数 | 验证CE | 图文检索Recall@1 |
|---|---|---|---|---|
| 四流完整基线 | 640M | 100k | 2.31 | 71.2% |
| 剪除模态流 | 594M | 100k | 2.34 | 70.8% |
| 剪除全部冗余流 | 548M | 100k | 2.35 | 70.5% |
直接硬剪，不做任何后续处理，CE会有约0.03到0.04的上涨，图文检索指标下降0.7个百分点左右。这个下降幅度不算致命，说明两条冗余流的有效信息量确实很小，但直接粗暴剪掉还是会造成轻微精度损失，需要配合微调来恢复。
3.2 剪枝流程：不是“删代码”而是“冻结 + 收敛”
直接剪掉流的实现方式有两种。一种是把模型结构里的对应分支直接从计算图中移除，这种方式适合推理框架，但训练阶段使用会破坏流水线并行和数据并行的一致性。另一种是“软剪枝”：保留分支代码，但把分支的缩放系数置为零，使其输出恒为零，等价于分支不存在。
我采用的是软剪枝，运作方式非常直接：
class MHCStream(nn.Module): def __init__(self, hidden_size, stream_id): super().__init__() self.stream_id = stream_id self.norm = nn.LayerNorm(hidden_size) self.proj = nn.Linear(hidden_size, hidden_size) self.alpha = nn.Parameter(torch.tensor(1.0)) def forward(self, x): if not self.is_active: return 0.0 return self.alpha * self.proj(self.norm(x))剪枝时只需把对应stream的is_active设为False，或者把alpha冻结为0。这里有一个细节：alpha置零和直接输出零向量不完全等价。直接输出零向量会让该支路的所有参数彻底失去梯度来源，置零alpha则只是让输出缩放为零，参数仍然会被优化器更新。从稳定性的角度来说，置零alpha更平滑，不容易在剪枝瞬间造成loss大幅度震荡。
我最终采用了“alpha归零 + freeze主干归一化统计量”的做法。具体流程分为三步：
- 先用80k步完整训练四流基线，得到每条流的归因数据。
- 从80k步开始，把模态流和任务控制流的alpha冻结为0，同时把剩余两条流的LayerNorm统计量重置为当前batch统计值。
- 将学习率降为原来的十分之一，继续训练20k步，观察验证CE是否回落。
最终验证CE从2.35回落到2.32，图文检索Recall@1恢复到70.9%。也就是说，剪掉两条流并微调20k步之后，模型效果基本回到了四流基线的水平，而参数量减少了约15%，单卡推理峰值吞吐提升了约14%。
3.3 剪完模型变快了吗：计算图层面的真正收益
这里必须提醒一句。如果把模型代码里四条流的计算逻辑都保留，只是把alpha设置为0，那么训练和前向推理时，剪掉的支路其实依然参与了计算，只是乘了零。这带来的是纯浪费，不会带来速度提升。
真正想获得推理加速，必须在编译层面把对应计算图真正删掉。常用的方式包括：
- 使用torch.fx对模型进行符号化跟踪，然后pass掉alpha=0的节点。
- 使用TensorRT、ONNX Runtime等推理引擎时，在导出阶段直接删掉恒为零的分支。
- 在框架内部注册自定义的剪枝pass，把对应stream的proj和norm节点全部断开。
我采用的方式是用torch.fx跟踪后做一次子图替换，把alpha=0的stream节点整体移除。经过这一步之后，单卡前向延迟从四流基线的22.4ms降低到19.3ms，下降了约14%，显存峰值也从约38GB降低到32GB。
3.4 复现中踩过的坑
第一个坑是归因结果容易被梯度噪声误导。梯度范数是逐step波动的，如果只看某一次的数值，很可能误判流的重要性。我最后采用了滑动平均窗口，窗口长度至少覆盖5000个训练步，同时结合置零敏感度做交叉验证，才算稳定。
第二个坑是剪枝后Loss先暴涨后慢慢恢复。原因是被剪两条流的LayerNorm统计量里积累了训练中期的特征分布，直接归零后，残差流的整体幅度变化影响了后续层的归一化。解决办法是重置剩余流的LayerNorm统计量，同时把warmup拉长到3000步，让模型慢慢适应新的信息通路。
第三个坑是训练速度在“软剪枝”阶段几乎没有任何提升。这个前文也提到了，alpha虽为零，计算却仍在发生。如果想要真正节省训练时间，更合理的方案是从一开始就跑两流架构，把节省下来的显存用于加大batch或者增加序列长度。
4. 架构的天花板：为什么堆砌部件开始失效
4.1 收益递减的本质：信息瓶颈而非参数量不足
我们从mHC实验里看到的四改二不只是一个剪枝技巧，它把“收益递减”这个问题放到了聚光灯下。
在模型规模爬升的过程中，很多人默认loss会继续下降，能力会继续上涨。但实际的曲线通常是这样的：模型规模从1B到10B阶段，效果提升非常明显；从10B到30B，提升开始放缓；从30B到100B，提升已经很微弱。有时候这种微弱提升还伴随着训练成本的指数级上升。
原因在于，模型学习的内容大部分来自训练数据中的统计规律。数据里的规律是有限的、稀疏的。当模型容量已经能够覆盖这些规律时，新增的参数量只能用于拟合噪声，或者形成各种冗余的等价表示。残差流四条变两条，正是模型在容量冗余状态下主动丢弃“等价表示”的一个绝佳样本。
如果架构设计不变，只是放大参数量，这堵墙迟早会横在所有团队面前。区别只在于谁先撞到，谁先意识到。
4.2 从“更多部件”到“更好的路由”：动态残差的选择
面对这堵墙，mHC论文里提出的回答之一，是让残差流的使用由输入动态决定。不是训练完就把两条流永久删掉，而是让模型在每一个前向过程中，根据当前输入特点，决定要使用哪几条流、每条流分配多少权重。
这个思路有点类似于动态路由。在推理时，一个简单问题只需要语义流和位置流就足够了，任务控制流和模态对齐流可以完全跳过。遇到复杂多模态输入时，模型又可以让模态流临时介入。这样一来，同样的模型可以承接不同类型的请求，同时保持更低的平均计算成本。
实际工程中，动态残差选择和早期退出（early exit）机制可以结合起来。某些低复杂度请求在深度12层时就已经收敛，不需要继续往前；此时残差流对应的中间层也可以一并跳过。这类动态机制长期来看会比静态剪枝更有工程价值，因为它把“按需计算”真正落到了架构层面。
4.3 推理侧的机会：稀疏化、条件计算与内存释放
从这个实验延伸出去，推理侧的机会比训练侧更明显。训练阶段我们还在意精度恢复，推理阶段可以更大胆。
被剪掉的残差流释放的不仅仅是计算时间，还有内存带宽。Transformer推理时，每一层都要读取权重和激活值，内存带宽往往是真正的瓶颈。如果模型结构里明显存在冗余分支，那么在部署时把这些分支删掉，相当于直接降低每token的内存访问量，这对吞吐的提升效果非常显著。
再进一步，还可以尝试结构化稀疏化：不仅残差流可以剪，注意力头和FFN中间维度都可能存在类似的贡献不均。如果把“归因 + 剪枝 + 微调 + 编译删除”这套流程做成一个自动化管线，就能在部署阶段为每个具体任务和输入分布定制最精简的模型。这和“一次性训练一个大模型，然后在部署时针对场景瘦身”的思路是一脉相承的。
5. 常见问题与排查技巧实录
5.1 剪完掉点严重，如何快速恢复
如果你按我的方法剪完，验证CE上涨超过0.1，那基本可以判定剪掉的不是冗余流，或者剪枝方式太粗暴。我整理了一个排查顺序：
- 检查归因统计的滑动窗口是否太短，梯度范数的波动可能让你误判。
- 检查是否是LayerNorm统计量未重置。这是最常见的问题，重置之后通常能拿回一半的性能损失。
- 检查学习率。剪枝后模型的可优化空间变小，原来3e-4的学习率会导致震荡，改用3e-5甚至1e-5更合适。
- 如果恢复仍然不理想，原路回退，把剪掉的流恢复为alpha=0.01的低权重参与前向，而不是完全删除，然后再逐步衰减。
这四步做完之后，绝大多数情况下模型效果都能回到基线95%以上水平。如果还不行，那大概率是模型本身对特定任务非常依赖某条流的特征，说明它不是真正的冗余。
5.2 为什么我的四条流全都被判成冗余
这个问题我一开始也遇到过。训练一个小模型时，四条流的梯度范数全部都很低，置零任何一条流loss都不涨。起初我还以为实验成功了，结果发现模型其实变成了一条“纯残差主干”在跑：所有流都在忙着传递原始embedding，所有信息加工都发生主干之外的下层子模块中。
这种情况通常出现在模型宽度过大、深度过浅、而训练数据又过于简单的配置下。模型根本不需要依赖残差流做长期信息缓存，直接在浅层就完成了特征提取，于是所有残差流都变成摆设。处理方法是增大深度、增加数据难度、关闭Dropout并调高任务复杂度。如果之后仍然没有一条流的贡献超过0.2的归一化占比，再考虑从架构层面重新设计残差路径，而不是继续盲调超参。
5.3 软剪枝之后显存没降，是因为你还没编译
很多人复制我的软剪枝方式，在PyTorch里把alpha置为零，然后看nvidia-smi发现显存没变化，于是怀疑剪枝无效。这个疑惑我之前也有过。
原因很简单：PyTorch的autograd图仍然包含了这些节点，前向时它们照常运行。真正节省显存和计算量，必须走TorchScript、torch.fx、TensorRT这类编译路径，把计算图静置后再优化。对于训练阶段，软剪枝的价值在于稳定性和恢复能力；对于推理阶段，必须做计算图层面的删除才有意义。
如果你只是想快速看一下剪掉两条流之后模型的推理速度，我建议直接写一个两流版本的模型，加载四流模型剪枝后的权重，进行对比。这个方法虽然麻烦，但结果最真实。
5.4 常见问题速查表
| 现象 | 可能原因 | 解决手段 |
|---|---|---|
| 剪枝后loss暴涨超0.1 | LayerNorm统计量失配 | 重置统计量、降低学习率、拉长warmup |
| 多条流都判冗余 | 模型过宽过浅、数据太简单 | 加深模型、增加任务难度 |
| 显存和延迟没有下降 | 计算图未真正删除 | 使用torch.fx或推理引擎做图优化 |
| 复现结果与论文差距大 | 数据分布、流缩放系数不同 | 对齐初始化缩放和训练分布 |
| 微调后反而更差 | 学习率过高、微调步数过短 | 尝试更小学习率和更长微调周期 |
6. 我的实操体会与后续想法
这套实验做下来，我个人最大的体会是：四改二并不是在否定多流架构的价值，而是在重新定义冗余在模型中的角色。训练初期并行多条流可以看作搭建脚手架，帮助模型快速探索不同特征空间；训练后期移除冗余支路，相当于拆掉脚手架、只保留承重结构。真正的难点在于把握拆除的时机和方法，让模型从“试探模式”平滑切换到“收敛模式”。
另外，我发现把残差流显式建模成多个可单独控制的模块，对分析模型行为特别有用。平时我们只盯着attention map、FFN激活值，很少关注信息在主干网络上如何累积。现在多了一个诊断维度，排查一些奇怪的训练现象时，能直接看到是哪条信息通道出了问题。
后续我打算在这个基础上做两个方向的扩展。一个是把同样的归因剪枝流程应用到注意力头级别，探索“40个头剪到10个头”的合理边界。另一个是尝试动态残差路由，让模型在推理时根据任务复杂程度自动选择启用的流数量，类似给模型装一个“资源管理器”。不管最后效果怎么样，这轮折腾都让我对大模型架构的瓶颈有了更实感的认识：真正的进步可能不在于继续堆料，而在于更聪明地分配已经拥有的计算资源。
