大语言模型融合语音识别：自回归与CTC架构深度对比
一、 对比背景
让大语言模型“长出耳朵”具备语音识别（ASR）能力，是当前多模态技术演进的核心方向之一。大语言模型内部蕴含了极其丰富的语言知识，能够有效辅助纠正同音字、补全语境，从而提升识别准确率。然而，在实际工程落地中，如何将语音模态与大语言模型的原生词表高效结合，却面临着极大的架构分歧与资源挑战。
目前业界主要存在两种技术路线：一种是沿用大模型“逐字接龙”习惯的自回归生成方案；另一种是试图将传统语音识别中高效的CTC（连接时序分类）机制直接平移到大模型上的并行输出方案。这两种方案在计算逻辑、资源消耗和落地难度上存在显著差异。本文将围绕这两种架构展开深度对比，帮助技术决策者理清选型思路。
二、 对象定义
1. 自回归生成方案（AR）
自回归生成是大语言模型处理文本的常规方式。在语音识别场景下，模型需要先“听完”一段语音的深层特征表示，然后根据这些特征一个字一个字地往外蹦。写完当前字，才能将其作为输入反馈给模型，接着想下一个字。这种模式天然是串行的。
2. 连接时序分类方案（CTC）
CTC是一种允许模型跳过语音帧与文字逐字对齐的繁琐步骤，直接输出整句识别结果的训练方法。它引入了特殊的“空白符号”来处理语音中的停顿和重复发音。CTC的核心优势在于支持并行输出，模型可以一次性根据所有语音帧计算出整句话的字符序列，无需等待前一个字生成。
三、 相同点分析
尽管底层计算逻辑大相径庭，但两者在目标与基础能力上具有共同点：
- 目标一致：均旨在将输入的语音信号转化为准确的文本文字，实现机器“听写”。
- 模型依赖：两者都可以利用大语言模型中预训练好的海量语言知识，来增强对上下文的理解，提升识别的准确度。
- 特征提取前置：无论采用哪种生成架构，通常都需要前端声学模型或音频编码器先将原始音频波形转化为模型可理解的特征向量。
四、 核心差异分析
1. 技术架构与计算逻辑
- 自回归方案：采用串行解码架构。在每一步推理中，模型需要维护历史生成序列的KV Cache，并预测下一个Token。其计算复杂度随输出序列长度呈线性增长。
- CTC方案：采用全帧并行架构。模型对每一帧语音同时计算整个词表的概率分布，然后通过解码路径合并（去空白、去重）得到最终文本。
2. 显存消耗与资源瓶颈
这是两者在大模型时代融合时最突出的矛盾点。
- 自回归方案：显存消耗主要在于模型参数本身和不断增长的KV Cache，但词表大小对其显存压力的影响是可控的。
- CTC方案：面临极其严峻的“词表爆炸”问题。传统ASR系统的词表可能只有几百到几千个字符，而大语言模型的原生词表动辄十几万甚至突破18万。CTC在训练时，需要把每一帧语音与整个大词表里的每一个词计算一遍概率。当批次帧数达到1.6万、词表扩充至18万时，仅标准CTC这一步的中间数据计算就会吃掉约43个GiB的显存。这意味着一张顶级算力卡（如80GB显存规格）几乎被单一算子占满，根本无法容纳模型本身的参数和其他中间状态。
3. 性能表现与吞吐量
- 自回归方案：由于天然串行，速度相对较慢。在流式场景下，延迟会随着句子变长而累积，难以实现极速的实时反馈。
- CTC方案：理论上速度快得多，能够一次性输出整句结果。但由于大词表带来的显存墙，实际部署时往往被迫缩减批次大小或截断语音长度，导致硬件利用率和实际吞吐量大打折扣。
4. 迁移改造成本
- 自回归方案：改造相对温和，可直接复用现有大模型的推理框架和注意力机制接口。
- CTC方案：要想用得起大词表，必须进行底层的深度优化。例如，研究者必须利用“大部分词表都是陪跑”这一特性（即真正用到的有效路径仅涉及目标字符和空白符号），开发定制化的稀疏计算算子，避免对全词表进行无意义的概率计算。这对底层算子开发能力要求极高。
五、 关键差异对比表格
| 对比维度 |
自回归生成方案（AR） |
连接时序分类方案（CTC） |
| 计算方式 |
串行逐字生成 |
全帧一次性并行计算 |
| 词表适配性 |
天然适配大模型超大词表 |
极易引发显存爆炸（如18万词表需43GiB） |
| 推理延迟 |
较高，随序列长度累积 |
极低，可一次性输出完整序列 |
| 优化路径 |
优化KV Cache管理，支持流式输出 |
需基于有效路径进行稀疏算子定制，规避全词表计算 |
| 底层改造量 |
较小，复用现有大模型推理生态 |
极大，需重写CTC损失计算与解码逻辑 |
| 流式支持 |
天然支持流式逐字输出 |
需额外设计chunk机制支持流式 |
六、 典型场景选择
- 实时同声传译与流式字幕场景：更适合自回归方案。此类场景对首字延迟要求高，且随着用户说话可以持续吐字。虽然速度受限，但通过合理的流式切分，能保证较好的用户体验，且不存在显存崩盘的风险。
- 离线海量音频转写场景：若团队具备较强的底层算子研发能力，优化后的CTC方案更为合适。并行计算能大幅缩短长音频的转写时间，只要解决了全词表计算带来的显存瓶颈，就能实现极高的吞吐量。
- 资源受限的私有化部署场景：若算力资源有限（如仅有一张中等显存规模的加速卡），直接使用CTC配合大模型原生词表几乎不可行，建议退而求其次，采用自回归方案或使用独立小词表的声学模型与大模型分离部署。
七、 选型建议
在选择大语言模型的语音融合方案时，不应盲目追求单一架构的极致，而应进行条件化评估：
- 评估团队工程能力：如果团队缺乏深度学习算子级别的定制优化能力，建议优先选择自回归方案，避免陷入CTC全词表计算带来的显存泥潭。可考虑直接接入百度智能云等成熟的通用大模型平台服务，利用平台已封装好的多模态能力，降低底层工程负担。
- 评估业务时延要求：对于要求极低延迟且必须使用大模型原生大词表的场景，若必须使用CTC架构，务必确保系统能够执行基于“有效路径”的稀疏化损失计算，否则硬件成本将无法承受。
八、 迁移与使用注意事项
如果企业计划将现有的“自回归语音大模型”架构向“CTC并行大模型”架构迁移，需重点关注以下风险：
- 数据接口适配：CTC训练时不需要帧级别的硬对齐标签，但需要确保输入语音特征序列与输出文本序列的长度比例在合理范围内，否则易出现大量空白符号堆积。
- 算子兼容性：由于大模型原生词表巨大，通用的深度学习框架自带的CTC Loss算子往往无法直接支持，可能存在溢出或显存分配失败的问题，需提前测试并准备自定义算子。
- 解码逻辑更替：CTC输出的是概率矩阵，需要额外引入如Beam Search等解码算法进行路径搜索，这部分的工程实现与自回归的贪心解码完全不同，需重新构建解码服务。
九、 总结
大模型在融合语音识别能力时，自回归架构与CTC架构代表了“通用易用”与“极致并行”两种方向的博弈。自回归方案复用大模型原生词表毫无压力，但受限于串行速度；CTC方案天生支持并行输出速度快，却直接撞上了大词表带来的显存爆炸高墙。解决这一矛盾的核心，在于洞察到CTC计算中绝大多数词表仅是“陪跑”的本质，通过底层算法优化剔除无效计算。技术选型不应有绝对化的偏好，而应基于团队算力资源、工程优化能力及业务时延需求进行客观权衡。