CNN+Transformer+Mamba融合：分工、消融与工程复现

很多人第一次看到 CNN+Transformer+Mamba 这个组合，反应都是“三个都要吗，会不会太堆了”。但真正跑过几轮实验之后会发现，这三者的关系不是替代，而是分工：CNN 管局部纹理和边缘，Transformer 管全局依赖和长程关系，Mamba 管长序列下的线性复杂度建模。把它们放在一起，解决的是单一结构在分辨率、序列长度和感受野之间难以兼顾的问题。这篇内容适合正在做视觉主干、时序建模、医学图像分割、遥感解译或视频理解方向，想找一个可验证增量的人看。最值得关注的一点是：融合本身不难，难的是证明每一块都不可替代，并且能在普通显卡上稳定复现。

1. 先把 CNN、Transformer、Mamba 的分工说清楚，再谈融合

1.1 三种结构各自解决什么问题

CNN 的优势在于归纳偏置强。卷积核自带局部性、平移等变性，浅层就能把边缘、角点、纹理抓出来，参数量也比较可控。做图像任务时，哪怕数据量不大，一个设计正常的卷积主干也能给出不差的基线。这也是为什么很多融合架构仍然保留卷积 stem，而不是一上来就把图片切成 patch 直接送进注意力模块。

Transformer 的优势是全局建模。自注意力让任意两个位置直接建立联系，长程依赖不依赖层层堆叠的感受野扩张。但代价也明显：标准注意力的计算量随序列长度平方增长，高分辨率输入下显存压力很快上来。图像里把特征图展平成序列之后， token 数量一多，训练成本就不太友好。

Mamba 走的是另一条路。它基于选择性状态空间模型，用输入相关的参数控制状态如何更新，序列建模的复杂度是线性的。和注意力相比，它在长序列上的显存和计算增长更平缓；和卷积相比，它又能保留一定的长程信息传递能力。视觉任务里常见的做法是把特征图按扫描顺序展开成序列，再送入状态空间模块，同时用双向扫描或者多方向扫描弥补单向建模的局限。

三者的能力边界大致可以这样理解：

这张表不是要给三者排名，而是提醒一件事：融合设计要先明确每个模块负责哪一段信息流，否则很容易变成“加了模块、涨了点、但说不清为什么”。

1.2 融合的价值来自互补，不是参数堆叠

很多融合实验失败，不是结构不对，而是目标不清。比如在一个本来只有 224×224 输入的分类任务上硬塞 Mamba，序列长度并不长，线性复杂度的优势体现不出来，反而多了一堆参数和工程依赖。反过来，在高分辨率遥感分割或者长视频理解里，纯 Transformer 的显存开销很早就顶到上限，这时候引入状态空间模块才有实际意义。

我一般会先问三个问题再决定要不要融：

1. 当前基线的瓶颈是局部细节丢失，还是全局关系建模不足，还是长序列跑不动？
2. 新增模块解决的是哪一类瓶颈，能不能用消融实验单独验证？
3. 引入之后的参数量、显存、单步耗时增加多少，是否在可接受范围内？

这三个问题回答不清楚，融合就容易变成“为了结构而结构”。审稿人看这类工作，最关心的往往不是模块名字新不新，而是增量是否清晰、对比是否公平、消融是否到位。

还有一个容易被忽略的点：融合位置比融合数量更重要。把 CNN 放在浅层做特征提取、Transformer 放在中层做语义聚合、Mamba 放在高层或者长序列分支，是一种思路；三个模块并联后门控加权，是另一种思路；用 Mamba 替换注意力、再保留卷积前馈，又是另一种。不同接法对应的计算图和感受野完全不同，不能只看最终指标。

先明确瓶颈，再选结构。顺序反了，后面所有实验都是在给一个没必要的模块找理由。

2. 融合拓扑怎么选：串联、并联、门控和分层替换

2.1 四种常见接法及适用场景

串联式是最直观的：CNN stem 提浅层特征，中间接若干 Transformer block，末端接 Mamba 或者反过来。这种接法的好处是信息流单向、调试简单，每一段输出都可以单独打印形状和统计量。适合刚起步做原型验证，也适合把已有主干逐步替换。缺点是层间耦合紧，某一层出问题不容易定位，而且串联之后感受野变化是累积的，分析起来要更小心。

并联式是把同一个输入分别送进卷积分支、注意力分支和状态空间分支，最后做相加或者拼接。它的优势是每个分支可以独立训练、独立消融，写论文时对比实验好组织。缺点是三份计算同时发生，显存峰值高；如果融合方式只是简单相加，模块之间缺少交互，容易出现“某个分支几乎没学到东西”的情况。

门控融合是在并联基础上加一个可学习的权重。常见做法是把各分支输出拼接后过一层线性映射和 sigmoid，得到逐通道或者逐位置的权重，再加权求和。门控的好处是让网络自己决定不同层级更依赖哪种结构，也让消融更有说服力：可以把门控权重可视化出来，看不同 stage 的偏好。要注意的是门控本身也带参数，初始化不当会让训练早期偏向某一个分支，建议初始化为接近均分。

分层替换不是新增分支，而是把主干里的一部分注意力层换成状态空间层，保留其余结构。这种改法参数量增加少，工程改动小，适合在已有基线上快速试水。缺点是替换比例需要试，换多了语义建模能力下降，换少了效果不明显。

下面是一个并联加门控的示例结构，只表达连接关系，不代表最优配置：

python复制import torch
import torch.nn as nn
from mamba_ssm import Mamba


class FusionBlock(nn.Module):
    def __init__(self, dim, num_heads=8, d_state=16):
        super().__init__()
        # 局部分支：深度可分离卷积，控制参数量
        self.local = nn.Sequential(
            nn.Conv2d(dim, dim, 3, padding=1, groups=dim),
            nn.GELU(),
            nn.Conv2d(dim, dim, 1),
        )
        # 全局分支：标准自注意力
        self.global_attn = nn.TransformerEncoderLayer(
            d_model=dim,
            nhead=num_heads,
            dim_feedforward=dim * 4,
            batch_first=True,
            norm_first=True,
        )
        # 长序列分支：状态空间模块
        self.ssm = Mamba(d_model=dim, d_state=d_state, d_conv=4, expand=2)
        # 门控：逐通道加权
        self.gate = nn.Sequential(
            nn.Linear(dim * 3, dim),
            nn.Sigmoid(),
        )
        self.proj = nn.Linear(dim, dim)

    def forward(self, x):
        # x: (B, C, H, W)
        b, c, h, w = x.shape
        local = self.local(x).flatten(2).transpose(1, 2)      # (B, N, C)
        token = x.flatten(2).transpose(1, 2)
        glob = self.global_attn(token)
        seq = self.ssm(token)
        fused = torch.cat([local, glob, seq], dim=-1)
        g = self.gate(fused)                                   # (B, N, C)
        out = g * local + (1 - g) * glob + g * seq
        out = self.proj(out)
        return out.transpose(1, 2).reshape(b, c, h, w)

这段代码有几个地方需要按实际任务调整：注意力层的 nhead 要能被 dim 整除；Mamba 的输入默认是 (B, L, D)，如果你用的是双向扫描实现，接口会不一样；门控里的三路加权只是示例，实际可以做成 softmax 归一化，保证权重和为 1。

2.2 参数量、显存和吞吐的取舍标准

融合结构选完之后，必须做一次成本核算。不要只看训练能不能跑起来，还要看单步耗时、显存峰值和推理吞吐。我一般会记录四个数：参数量、FLOPs、单卡 batch 下的显存峰值、验证集上的单张推理延迟。这四个数放在一起，才能判断一个融合方案是“有效增量”还是“用三倍成本换零点几个点”。

这里有个实际经验：并联结构的显存峰值往往比串联高不少，因为三个分支的中间激活要同时保留。如果显卡不够，优先考虑串联或者分层替换，而不是硬把 batch size 降到 1。batch 太小会让 BatchNorm 类层不稳定，梯度噪声也大，最后指标波动可能盖过结构本身带来的差异。

另一个判断标准是“增量是否可归因”。如果加了 Mamba 之后指标涨了，但同时换了学习率、换了数据增强、换了训练轮数，这个涨点就说不清来源。稳妥的做法是固定除结构以外的所有变量，先做单模块替换，再做组合，最后再调超参。

3. 从零跑通一个最小实验环境

3.1 硬件、依赖和数据目录准备

这类融合模型对环境比较敏感，尤其是状态空间模块通常依赖自定义 CUDA 算子。开始之前先把环境确认清楚，比后面花时间排查报错划算得多。

硬件方面，建议至少一张显存 16GB 以上的显卡做原型验证。如果输入分辨率高、序列长，24GB 会更从容。CPU 内存建议不低于 32GB，数据加载的 num_workers 才有调整空间。磁盘方面，图像分割和视频任务的数据集体积不小，预留几百 GB 比较稳妥。

软件方面，核心依赖是 PyTorch 和 CUDA 版本匹配。状态空间模块的安装通常要求本机 CUDA 编译工具链可用，nvcc 版本要和 PyTorch 编译时使用的 CUDA 版本对齐。这一步最容易出问题：nvcc -V 看到的版本和 torch.version.cuda 不一致，编译出来的算子可能在运行时报符号错误。

bash复制# 先确认基础环境，不要急着装融合模块
python -c "import torch; print(torch.__version__, torch.version.cuda, torch.cuda.is_available())"
nvcc -V

确认之后再安装依赖。具体版本以你使用的 PyTorch 和显卡驱动为准，不建议直接照抄别人的版本号。

bash复制# 示例流程，版本按实际环境调整
pip install torch torchvision --index-url <与你的 CUDA 匹配的源>
pip install causal-conv1d
pip install mamba-ssm

目录结构建议提前分好，后面做消融会省很多事：

text复制project/
├── configs/
│   ├── baseline.yaml
│   ├── cnn_transformer.yaml
│   └── fusion_full.yaml
├── data/
│   ├── train/
│   ├── val/
│   └── test/
├── models/
│   ├── backbone.py
│   └── fusion.py
├── train.py
├── evaluate.py
└── outputs/
    ├── logs/
    ├── ckpt/
    └── figures/

配置文件分开管理是有原因的。做消融时最怕的就是“改完代码忘了改回默认值”，最后两组实验其实用的不是同一套参数。把结构开关、学习率、batch size、输入尺寸都写进 yaml，跑实验时只改配置文件名，复现成本会低很多。

3.2 先跑单模块基线，再接入融合模块

我不建议一上来就把三个模块全部接上。正确顺序是先跑通单模块基线，确认数据管道、损失函数、评估脚本都没问题，再逐个加模块。

第一步，用纯 CNN 或者纯 Transformer 主干跑一个短周期训练，比如 10 到 20 个 epoch，确认 loss 在下降、验证指标在动、 checkpoint 能正常保存和加载。这一步的意义不是拿最终结果，而是验证整条链路。

第二步，单独替换一个模块。比如把某个 stage 的注意力换成状态空间层，其他都不动，再跑一次。对比两次的参数量、显存和指标，看变化是否符合预期。

第三步，再做组合。组合之后如果指标反而下降，先不要怀疑结构设计，优先检查三件事：学习率是否还适合、归一化层的位置是否合理、残差连接是否被破坏。

这里有个常见坑：融合模块的输出尺度和原分支不一致，直接相加会让训练早期不稳定。解决办法是在每个分支输出后加 LayerNorm 或者可学习的缩放系数，初始化时让缩放接近 0，相当于从恒等映射开始学。

单模块基线跑不稳，融合之后的问题只会更难定位。先把最简单的跑通，再往上叠。

3.3 训练脚本和关键参数

训练脚本不需要写得很复杂，但几个关键点要处理好：混合精度、梯度累积、学习率调度、日志记录。

python复制import torch
from torch.amp import autocast, GradScaler

scaler = GradScaler()
for epoch in range(epochs):
    model.train()
    for step, (images, targets) in enumerate(loader):
        images = images.cuda(non_blocking=True)
        targets = targets.cuda(non_blocking=True)
        optimizer.zero_grad(set_to_none=True)
        with autocast(device_type="cuda", dtype=torch.float16):
            logits = model(images)
            loss = criterion(logits, targets) / accum_steps
        scaler.scale(loss).backward()
        if (step + 1) % accum_steps == 0:
            scaler.step(optimizer)
            scaler.update()
            scheduler.step()

关键参数的建议范围，仅作为起点：

混合精度不是万能的。状态空间模块里有些算子对半精度敏感，如果出现 loss 变成 NaN，先把这一部分强制回 float32，再逐步放开。梯度裁剪也建议加上，长序列任务里梯度范数偶尔会突然变大。

日志要记录到文件，不要只看终端输出。至少保存每个 epoch 的训练 loss、验证指标、学习率、显存峰值和耗时。做消融时，这些日志就是写论文表格的原始素材。

4. 实验设计：消融、指标和可写进论文的证据

4.1 消融实验怎么排才有说服力

融合类工作最容易被质疑的地方就是消融不完整。审稿人常问：三个模块是不是缺一不可，融合方式是不是随便选的，涨点是不是来自参数变多。

我一般会按这个顺序排消融：

1. 单模块对比：CNN、Transformer、Mamba 各自单独作为主干或者分支，固定其他条件。
2. 两两组合：CNN+Transformer、CNN+Mamba、Transformer+Mamba，看哪一对互补性最强。
3. 三模块组合：完整结构，和上面所有组对比。
4. 融合方式对比：相加、拼接、门控、交叉注意力，固定模块不变。
5. 位置对比：融合放在浅层、中层、高层，或者多个 stage 都放。
6. 规模对比：不同宽度和深度下，融合收益是否稳定。

这六组做完，基本能回答“为什么是这三个”“为什么这么接”。如果某一组做不了，要在文中说明原因，不要跳过。

还有一个细节：消融实验的训练轮数要一致。有些人给完整模型训 300 epoch，给消融模型训 100 epoch，最后对比出来的差距没有意义。计算资源不够时，可以统一缩短轮数，但要保证所有组别公平。

4.2 指标之外还要记录什么

分类任务看 Top-1、Top-5，分割任务看 mIoU、Dice、HD95，检测任务看 mAP，这些是常规指标。但融合结构的工作，最好再补几类证据：

• 效率指标：参数量、FLOPs、推理延迟、显存峰值。
• 收敛曲线：训练 loss 和验证指标的曲线，能说明融合结构是收敛更快还是最终更高。
• 可视化：注意力图、门控权重、特征图响应区域。门控权重的可视化尤其有用，能直观看到不同 stage 更偏向哪个分支。
• 稳定性：换几个随机种子跑，报告均值和方差。只报最好一次的结果，说服力有限。

可视化不要为了好看而挑样本。选成功和失败的案例各几个，说明模型在什么情况下表现好，什么情况下会失效。这种分析比单纯堆指标更能体现工作深度。

4.3 结果表格和图表怎么组织

主表放主要对比方法，列不要太多，控制在六到八列：方法、参数量、FLOPs、主要指标、推理延迟。消融表单独放，按模块组合分组。效率对比可以画成散点图，横轴是计算量，纵轴是指标，能直观看出性价比。

写作时注意表述分寸。不要说“显著优于所有方法”，除非统计检验支持；更稳妥的写法是“在相同训练配置下，相比基线有一致提升”。涉及具体数值时，确保表格和正文一致，不要出现正文写 82.3、表格写 82.1 这种低级问题。

实验记录从第一天就要规范。等到写论文再回头找某组实验的学习率，基本只能重跑。

5. 训练不收敛、显存爆掉、速度慢的排查顺序

5.1 先分清是环境问题还是模型问题

报错先看类型。如果是导入失败、算子找不到、CUDA 版本不匹配，这是环境问题，改模型没用。如果是 loss 不降、指标不动、输出全零，才往模型和训练配置上找。

一个实用的判断方法：把融合模块全部关掉，只留基础主干，用同一套数据和训练脚本跑几十步。如果基线正常，说明环境和数据管道没问题，问题出在融合模块；如果基线也异常，先修环境和数据。

环境排查顺序：

1. torch.cuda.is_available() 是否为 True。
2. torch.version.cuda 和 nvcc -V 是否一致。
3. 自定义算子能否单独 import 并跑一个最小张量。
4. 数据加载是否正常，能不能拿到一个 batch 并打印形状。
5. 单卡单 batch 前向是否能跑通，再加反向。

这个顺序看着笨，但能省很多时间。我见过不少情况是数据里混进了损坏文件，报错信息却指向模型层，最后查了半天才发现是读取阶段的问题。

5.2 loss 异常和梯度问题的排查

loss 变成 NaN，常见原因有几类：学习率过大、混合精度溢出、归一化层输入方差过小、长序列里注意力或者状态转移数值不稳定。排查时先把学习率降一个数量级，再关掉混合精度，逐步定位。

如果 loss 不降但也不报错，先看三件事：标签对不对、模型输出是否退化成常数、梯度是否几乎为零。打印几个 batch 的预测分布和梯度范数，比盯着 loss 曲线有用。

融合结构还有一个特有问题：分支之间存在尺度竞争。某个分支输出幅值明显大于其他分支，融合之后其他分支的梯度就会被压制。解决办法包括分支后加归一化、给每个分支单独的缩放系数、门控初始化偏向均分。

python复制# 快速检查梯度和输出分布
for name, p in model.named_parameters():
    if p.grad is not None:
        print(name, p.grad.norm().item())

如果某一层梯度长期接近零，先确认它是否在计算图里，再确认初始化是否合理。残差结构里把新模块的最后一层初始化为接近零，是一种比较稳妥的做法。

5.3 Mamba 相关依赖和算子问题

状态空间模块的工程问题相对集中，常见的有这几类：

序列长度是重点。状态空间模块虽然复杂度线性，但序列特别长时中间状态占用的显存仍然可观。做高分辨率任务时，可以先降采样再送进长序列分支，或者把特征图分块处理，块之间用重叠区域减少边界效应。

多卡场景下，建议先在单卡把结构和超参调稳，再上分布式。融合结构里如果有自定义算子，分布式下的行为可能和单卡不同，早早上多卡只会把问题叠在一起。

6. 哪些场景适合硬融，哪些场景应该换思路

6.1 适合融合的任务特征

有几类任务天生适合这种组合。第一类是高分辨率密集预测，比如遥感影像分割、医学图像分割、大幅面缺陷检测。这类任务既需要局部细节，又需要跨区域上下文，序列还长，三个模块各有用武之地。

第二类是长序列或者多帧输入，比如视频理解、时序信号建模、长文档图像处理。Transformer 在长序列上的成本是硬约束，状态空间模块的线性复杂度在这里优势明显，卷积则负责短时局部变化。

第三类是多尺度特征明显的任务。浅层用卷积抓细节，中层用注意力聚合语义，高层或者长序列分支用状态空间模块控制成本，这种分层思路比较自然。

判断标准可以简化成一句：如果你的基线在“细节”和“全局”之间反复权衡，而且长序列下的显存或速度已经影响实验迭代，那融合值得试。如果输入尺寸固定且不大，基线已经跑得又快又好，硬加模块的收益通常有限。

6.2 不适合的情况和替代方案

输入分辨率低、序列短的任务，比如 32×32 或者 64×64 的分类，融合的收益往往被参数增加抵消。这时候更值得做的是数据增强、正则化、蒸馏或者更好的训练策略。

数据量很小的任务也要谨慎。三个模块加起来参数量不小，小数据上容易过拟合。如果一定要用，优先考虑预训练权重、冻结部分层、强增强，或者只做分层替换，不要全量并联。

工程条件受限时，比如只有一张显存不大的卡，并联三支路可能连 batch size 都开不上去。替代方案是串联或者只替换一部分层，先拿到可复现的结果，再考虑扩展。

还有一种情况是任务本身对延迟极其敏感。三支路并联的推理延迟通常高于单支路，如果部署端有硬性时间预算，要在结构设计阶段就把延迟纳入约束，而不是训练完再压缩。

6.3 长期做这个方向要提前整理的东西

如果打算在这个方向持续做，建议从第一个实验开始就整理三样东西：配置、日志和结论。

配置按实验编号存，每个配置对应一个输出目录，目录里放 checkpoint、日志、指标曲线和可视化图。日志至少记录环境信息、随机种子、训练时长和显存峰值。结论不用写长，一句话说明这组实验验证了什么、和上一组差在哪。

代码层面，把融合模块做成可配置的开关，而不是复制多份模型文件。这样消融时只改 yaml，不用改代码，减少人为出错。评估脚本也要独立，保证所有模型用同一套评估流程。

最后提醒一点：这个方向的热度不代表每个任务都适合。真正能站住的工作，通常是问题定义清楚、基线公平、消融完整、效率可接受。结构可以复杂，但论证要简单。先把单模块基线跑稳，再谈融合；先把一组消融做干净，再谈扩展。踩过几次之后会发现，决定结果好坏的往往不是模块名字，而是数据管道、训练配置和实验记录这些看起来不性感的部分。