从Transformer到Conformer：语音识别模型实战选型与调优

做语音识别项目的时候，很长一段时间我都在Transformer和CNN之间来回摇摆。当时我们组里主用的Transformer识别模型，长句效果说得过去，但一到口语化短句就露怯：标点处漏字、语气词被吞、多音字反复错。后来我完整读了一遍 Conformer（Convolution-augmented Transformer for Speech Recognition）这篇工作，又把源码和实验记录重新捋了一圈，才意识到问题不在Transformer本身，而是它缺了处理局部语音模式的那只手。这篇文章不讲论文复读，只讲我理解的Conformer内部机制、从零搭建这套识别系统时遇到的坑，以及它到底值不值得你把手里的基线换掉。适合正在选ASR模型结构、或者想优化现有语音识别效果的算法工程师参考。

1. 为什么我把识别基线从Transformer换成了Conformer

1.1 纯Transformer在语音输入上的两个软肋

语音信号和文本有一个本质区别：文本是离散符号，语音是连续流式信号。一个音素从出现到消失，中间会有共振峰过渡、辅音爆破、清浊切换这些细微的局部变化，而这些变化恰恰是区分“相似读音”的关键线索。Transformer的自注意力机制擅长捕捉长距离依赖，但在这种局部模式上缺少归纳偏置，相当于让一个擅长看全局的人去盯显微镜，能做，但效率很低。

另一个更实际的问题是计算量。自注意力复杂度和序列长度是平方关系，而语音帧序列动辄上千帧。哪怕一份三秒的音频，提取80维fbank特征后也有近300帧；到了十秒以上的长句，注意力矩阵会迅速膨胀，显存压力很大。再加上语音识别还需要处理说话速度变化、口音差异、背景噪声，如果模型本身对局部特征不敏感，那就只能靠堆数据和调增强来硬撑。

1.2 CNN的局部建模优势是怎么被浪费的

传统CNN在语音任务里其实立过不少功劳。比如TDNN用逐步扩大的感受野来建模音素上下文，在早期语音识别系统里表现非常好；一维卷积也能通过滑动窗口提取局部特征，而且并行度高、参数效率好。但CNN的问题在于感受野受限：你叠了十几层卷积，能看到的上下文也就是有限窗口，很难覆盖整句话的语义依赖。

语音识别本质上是一个“既要局部又要全局”的任务。识别一个音素依赖它前后几百毫秒的声学变化，判断一个词则需要结合整句的语义。于是很长一段时间里，大家要么用CNN做前端特征提取、Transformer做后端建模，要么在Transformer层之间间隔插入卷积层。这些方案有效，但总觉得是“拼接”而不是“融合”。局部信息和全局信息分在两个模块里，梯度在两者之间流转时总有些损耗。

1.3 Conformer的核心思路：在同一个Block里让卷积和注意力共事

Conformer没有把卷积放在Transformer前面当特征提取器，也没有用两个独立分支分别建模再融合，而是把卷积模块直接插进每一个Transformer Block内部。每个Block里同时存在多头自注意力、前馈网络和卷积模块，模型在每一层都能同时感受局部语音模式和全局上下文。

这个设计给我的感觉是：它终于承认了语音识别不是一个可以拆解的流水线问题，而是一个需要不同粒度信息协同作用的整体任务。后续我在自己的项目里验证时发现，同样的参数量、同样的训练数据，Conformer在中文短句上的效果明显更稳，长句上的表现也不输纯Transformer。这就是我把基线换掉的最直接原因。

2. Conformer Block拆解：卷积与注意力在一个残差壳里如何共存

2.1 Macaron式残差：为什么前馈网络要拆成两个“半份”

Conformer Block沿用了类似马卡龙的残差结构。传统Transformer里通常是一个完整的前馈网络加残差、再接自注意力；Conformer则把前馈网络拆成两个部分，分别放在注意力模块的前后，而且每个部分只贡献一半的残差增量。数据流大致是这样的：

x = x + 1/2 * FFN(x) x = x + MHSA(x) x = x + ConvModule(x) x = x + 1/2 * FFN(x) x = LayerNorm(x)

第一次看到这个结构时，我直觉是“这跟一个完整FFN拆两半有什么区别”。实际跑完实验才发现区别不小。把FFN拆成两段夹住注意力和卷积模块后，梯度传播路径更短也更均衡，每个子层对最终表征的贡献被拉平了。如果保留一个完整FFN在最后，前面注意力和卷积学到的局部特征容易被后面的大FFN“冲淡”，表现反而不如拆分方案。

2.2 卷积模块内部的数据流：GLU、Depthwise Conv和Swish各司其职

卷积模块是整个Conformer里最有意思的部分。它不是一个简单的一维卷积层，而是一个由多个算子组成的小管线：

Pointwise Conv -> GLU -> Depthwise Conv -> BatchNorm -> Swish -> Pointwise Conv

第一步Pointwise Conv本质是1x1卷积，先把输入维度映射到更高维空间，为后续特征变换提供更大容量。接着是GLU门控，把上一步的输出沿通道维切成两半，一半经过sigmoid生成门控信号，再与另一半相乘。这样模型能自己决定“当前这个局部位置的信息有多少需要保留”，类似LSTM里门的思路，但实现起来更轻量。

然后是Depthwise Conv，也就是分组卷积中分组数等于通道数的极端情况。每个通道独立做时间维上的卷积，常用卷积核大小是31，相当于在31帧约300毫秒的窗口内提取局部时域模式。这个卷积核大小值得细说：语音中多数音素持续几十到几百毫秒，31帧的窗口刚好能覆盖一个音素加部分过渡区，从而抓住区分相似音素的细节。窗口太小，局部信息不完整；窗口太大，又丧失了局部建模的意义。之后接BatchNorm稳定分布，Swish激活引入平滑非线性，最后再用一个Pointwise Conv把维度压缩回去，加回残差连接。

2.3 相对位置编码为什么在语音任务里如此重要

Conformer使用的是相对位置编码而不是绝对位置编码，这一点在做语音识别时比做文本任务更重要。自注意力本身不分先后顺序，如果不加位置信息，模型只能把输入当词袋看待。绝对位置编码虽然也能区分位置，但在变长语音输入上外推能力差：训练时最多见过500帧，推理时来了800帧，新增部分的位置向量模型根本不认识。

相对位置编码建模的是“两个帧之间隔了多少步”这个相对距离，而不是“这一帧是第几帧”。语音中的音素、声调、韵律变化恰恰更依赖相对时序关系，比如一个音素的持续时间、两个音素之间的间隔长度。这种编码方式让注意力在计算时既能感知局部距离约束，又不会因为序列长度变化而失效。后续做大段语音识别或者流式分块识别时，这个特性也会让工程落地更省心。

3. 上手搭建Conformer识别系统：核心配置与训练细节

3.1 模型超参配置：从轻量到规模的选型参考

我最早搭Conformer时参考过几组公开配置，后来在内部项目里逐渐调出了一套自己比较常用的参数组合。这里给一个可以直接抄作业的参考表，按数据量和算力条件选即可：

轻量方案适合几千小时以内的小数据场景，卷积核我建议缩到7到15，小数据上大卷积核容易把局部噪声也学进去。中等方案是通用选择，绝大多数内部项目从这一档起步就够了，显存和效果比较平衡。大规模方案针对上万小时数据和多卡训练，效果上限更高，但对工程基建要求也高。

模型输入侧我通常用80维fbank特征，25毫秒窗长、10毫秒帧移，做均值方差归一化。输出侧用子词建模，词表大小视数据规模和中文还是英文语料而定，一万到两万之间比较常见。如果做中文识别，很多人习惯直接用字建模，词表更小，也省去分词环节。

3.2 数据准备：语音增广对Conformer的收益格外明显

Conformer因为卷积模块的存在，对输入特征的局部稳定性有一定要求，而语音增广恰好能提升模型对时间和频率变化的鲁棒性。我常用的增广组合有三类：速度扰动、频谱增强和随机拼接。

速度扰动是把音频用0.9倍、1.0倍、1.1倍三种速度重新采样，相当于把说话快慢的变化注入训练数据。这个操作对最终模型效果的影响往往比很多复杂结构改动都明显，而且实现成本极低。频谱增强也就是常说的SpecAugment，在频谱图上随机遮蔽一部分频率带和时间段，强制模型从上下文推断被遮住的信息。对于Conformer这种强上下文建模的结构，它能更好地发挥注意力的优势。

随机拼接是指从训练集里挑两条短音频，拼接成一条长音频再送进模型训练，这能顺带解决长句效果差的问题，也让模型更适应变长输入。做这类增广时注意，拼接带来的不适感可以通过在拼接处补一个很短的静音段来缓解。另外，语速极快的音频会让卷积核覆盖的有效帧数变少，训练时如果发现这类样本损失异常，可以考虑单独采样或做归一化。

3.3 训练策略：优化器、学习率调度与多任务目标

训练Conformer我一般用Adam优化器，beta设为(0.9, 0.98)，配合Noam风格的学习率调度。所谓Noam调度就是学习率先线性升到一个峰值，再按步数的平方根缓慢下降，峰值学习率通常在0.0005到0.001之间，warmup步数设置在25000左右比较稳妥。峰值太高容易在早期震荡，太高又会让收敛变慢，这个平衡需要根据batch大小微调。

一个值得注意的细节是：语音识别训练通常使用注意力损失和CTC损失的加权和作为最终目标。CTC分支可以看成是给模型一棵“怎么对齐音频和文本”的脚手架，注意力损失则负责更精细的序列预测。Conformer的卷积模块对CTC任务的帮助尤其大，因为CTC本身依赖局部声学特征来判断当前帧对应哪个音素，卷积恰好增强了这块能力。损失权重我习惯设成0.3到0.7之间，CTC权重偏低一些，具体需要做小范围网格搜索。

训练时的batch策略也要特别注意。语音样本长度差异极大，如果按固定帧数做batch，长样本会严重拖慢训练速度。我常用的做法是把样本按时长分成若干个桶，每个桶内部做动态batch，让同一批内样本长度尽量接近，这样GPU显存利用率能提升不少。加上梯度累积后，batch_size 32在单卡上也能稳定训练中等规模的Conformer模型。

4. 训练阶段踩过的三个坑：完整排查过程

4.1 混合精度训练下WER悄悄退化，问题出在BatchNorm

我们当时为了加速训练，开启了混合精度训练，loss曲线看起来很正常，收敛速度确实快了，但验证集上的字错误率比纯FP32训练高出了近0.8%。0.8%在语音识别里不是小数目，比如原本98%的句准确率，可能直接掉到97%，属于肉眼可见的劣化。

我花了大半天排查这个问题。先怀疑是数据增广随机性导致，固定随机种子重新训练，没有解决。又怀疑是学习率调度和AMP配合问题，调低峰值学习率，效果不明显。最后我做了逐模块实验：把卷积模块里的BatchNorm替换成LayerNorm，再开AMP训练，WER恢复到正常水平。定位到根因了——BatchNorm在FP16下统计量估计不稳定。卷积模块的输入进Depthwise Conv之前，通道数多且数值分布波动大，FP16表示范围有限，导致BN的均值和方差漂移。

这个问题的解法有几个：一是把BN层的计算保持在FP32，这对训练速度影响不大；二是干脆换成LayerNorm，训练更稳定，但推理时显存占用略高；三是保证batch足够大，让BN统计更加稳定。如果你要用AMP训练Conformer，我建议至少做第一种方案，简单有效。

4.2 长音频OOM：不是显存不够，是batch策略不够聪明

训练初期我们经常在某个固定步数触发OOM，仔细一看，每次都是在batch里混进了特别长的样本时崩的。自注意力复杂度随序列长度平方增长，一条60秒的音频，帧数可能接近6000，单个样本占用的显存就抵得上几十条短音频。这时候如果batch里长样本和短样本混在一起，显存上限完全由最长的那个样本决定，短样本再多也没有意义。

我做的第一件事是按时长分桶加动态batch，但长样本本身还是会偶尔超限。第二件事是在数据管线里对超过一定时长的音频做切段训练，比如对30秒以上的音频随机裁剪成若干个固定长度片段。这样做训练时模型看到的仍然是完整的上下文窗口，长句泛化能力也没有损失。第三件事是开了梯度检查点，用重计算换显存，代价是训练速度慢大概20%到30%。三管齐下之后OOM基本消失。

4.3 消融实验意外发现：卷积核不是越大越好

做实验时我自然想验证卷积模块带来的收益，于是做了一个对照：在同一个数据集上分别训练完整Conformer、去掉卷积模块的纯Transformer版本，以及卷积核分别取7和31的版本。去掉卷积模块后的WER比完整版本差了1.1个百分点，这符合预期；但卷积核从31降到7时，小数据场景下的WER反而更低，这让我有点意外。

后来看了训练分布才明白原因：小数据集里样本覆盖的语音模式有限，大卷积核会把训练集中某些局部特征当作通用模式死记，在验证集上反而过拟合。数据量上来之后，kernel 31的优势才开始体现。所以卷积核大小不是拍脑袋定的，而是和数据规模强相关的超参。做消融实验还有一个收获：把注意力模块关掉，只保留卷积和FFN，WER退步比去掉卷积更明显。这说明全局上下文仍然是语音识别的底座，卷积是锦上添花，不是雪中送炭。

注意：以上是我在内部中文测试集上跑出的相对结果，不同数据分布下数字可能完全不同，重点看趋势而不是绝对值。

5. Conformer的实际收益与后续沉淀

5.1 相比基线Transformer，效果提升了多少

在我负责的中文短语音识别场景里，从纯Transformer基线切到Conformer之后，验证集CER从7.5%降到6.3%左右，相对下降约16%。在口语化、带语气词的样本上，原本经常被吞掉的“嗯”“啊”“就是”这类词，恢复得尤其明显。分析下来，卷积模块对语气词末尾的声学细节更敏感，注意力模块又能结合整句语义判断这里确实需要一个语气词，两者一配合，问题自然缓解了。

自研结构更方便的情况是直接做流式改造。把注意力改成基于chunk的局部注意力、卷积改成因果卷积后，Conformer在流式场景里的效果下降幅度比纯Transformer更小。这让我比较意外，后来想想也合理：卷积天然支持只看历史窗口，不需要像注意力那样做复杂掩码，流式化改造的工程成本更低。

5.2 推理部署阶段需要注意的细节

模型训练完，下一步通常是转成推理引擎。Conformer里最需要留意的是Depthwise卷积算子在推理框架里的支持情况。很多部署框架对普通卷积优化得很到位，但对Depthwise卷积的算子实现效率参差不齐。我踩过的坑是：模型在GPU上测试时延正常，转到CPU推理引擎后，Depthwise卷积反而变成瓶颈，整个模型慢了一倍。

解决思路有两个：一是把Depthwise卷积的手工实现替换成框架里原生支持良好的等价算子组合；二是在精度损失可控的前提下，把卷积核大小从31降到一个算子效率更高的值，比如15或7，配合训练时的轻微精度回退，换取部署性能的大幅提升。导出模型时还要记得把BatchNorm折叠进前面的卷积层，这一步能减少不少推理计算量。

5.3 Conformer之后，我沉淀下来的选型经验

如果把这段经历总结成一条判断准则，大概是：语音识别模型结构选择，先看数据规模和算力，再看是否流式，最后才是结构本身。数据量小，老老实实用小卷积核、轻量配置；算力充足且追求指标，把规模拉满，卷积核给足31；要做流式，优先考虑对分块友好的结构，Conformer依然是目前性价比最稳的选择之一。

我还试过不少在Conformer基础上的后续变体，比如把卷积模块再拆成多分支、或者在块之间共享部分参数，效果都算锦上添花，但收益远不如把训练数据和增广做扎实来得大。在一次内部技术分享里我说过一句话，现在仍然这么觉得：模型结构决定的是效果上限的下限，数据和训练策略才是那个真正的上限。这句话听起来像绕口令，但只有亲手从Transformer切到Conformer、把每一环都调过一遍的人，才会真正明白它的分量。