给大语言模型装上耳朵之后，才发现内存根本不够用

先说一个可能会让你意外的事实：当研究者们兴致勃勃地想把ChatGPT这类大语言模型改造成语音识别系统时，卡住他们的不是算法不够聪明，也不是数据不够多，而是显存不够用。听起来是不是有点滑稽？堂堂大模型，居然被一个"词表太大"的问题绊倒了。

这事得从头说起。

自动语音识别，简称ASR，说白了就是让机器把你说的话转成文字。这个领域这些年一直在借大语言模型的光，因为这些模型脑子里装着海量的语言知识，能帮着纠正同音字、猜测语境，识别效果往往能上一个台阶。

但问题也随之而来。

主流的做法是让大语言模型像聊天一样，一个字一个字地往外蹦，这叫自回归生成。你说一句话，模型得先"听完"再一个字一个字"想"该怎么写下来，写完一个字才能接着想下一个字。这就跟你让一个人一边听你说话一边同步翻译成文字,还得等前一个字写完才能写后一个字一样,天然就是串行的,快不起来。

于是有人想起了一个老朋友：CTC。

CTC*：全称Connectionist Temporal Classification，连接时序分类，一种能让模型不用逐字对齐语音和文字、直接输出整句识别结果的训练方法，2006年就被提出了，广泛用在传统语音识别系统里。

CTC的好处是它天生支持并行输出，不用等前一个字才能猜下一个字，速度快得多。但当研究者想把CTC用在大语言模型的原生词表上时，麻烦来了。

传统语音识别系统的词表可能就几百到几千个字符，但大语言模型的原生词表动辄十几万甚至更多。CTC在训练时需要把每一帧语音都和整个词表里的每一个词算一遍概率，词表越大，这个计算产生的中间数据就越大，显存直接爆炸。论文里给了个具体数字：词表撑到18万，批次帧数1.6万时，标准CTC光是这一步就要吃掉43个GiB显存，这还没算上模型本身和其他计算,一张顶级的H100显卡（80GB显存）都快装不下了。

这就是这篇论文要解决的核心矛盾：怎么让CTC用得起大语言模型的原生大词表，而不是被内存活活拖死。

一个被忽略的事实：大部分词表都是陪跑的

研究者们注意到一件很朴素但被忽略的事情。

CTC在计算每一句话的识别损失时，虽然理论上要考虑整个词表的每一个词，但实际上，真正会被用到的"有效路径"只涉及这句话里出现过的字，再加一个特殊的"空白"符号。

空白符号（blank）*：CTC框架里专门设计的一个占位符号，用来处理语音里的停顿、重复发音等情况，是CTC对齐机制的核心组件。

打个比方，你正在批改一份100道选择题的试卷，每道题有4个选项。但你其实只需要核对学生填的那个选项对不对，压根不需要把另外3个错误选项的内容都抄一遍。CTC以前的实现方式就是这么笨，它把整个词表的每一列都算了一遍，存了一遍，哪怕这句话里根本没出现的字也要占内存。如果不这么改进会怎样？每次训练一批数据，你都要在显存里凭空养着十几万个"从来没被点到名"的词条，这些词条唯一的作用就是参与最后的归一化计算,占着位置不干实事。

论文提出的方法叫Pruned CTC，剪枝CTC。

Pruned CTC*：本论文提出的核心方法，通过把对齐路径的计算范围收缩到"这批数据里实际出现过的词加空白符"，同时保留完整词表的归一化计算，从而大幅降低CTC训练时的显存占用。

它的思路是把CTC的计算拆成两部分：一部分是"对齐计算"，这部分只需要盯着这批语音数据里实际出现的字，另一部分是"归一化计算"，这部分仍然要考虑整个词表，因为这关系到概率分布的完整性,不能省。

关键的地方在于，研究者用数学证明了这种"瘦身"操作不会改变最终结果。

也就是说，剪枝之后算出来的损失值和梯度，和用完整词表计算出来的结果是完全一样的，不是近似,是精确相等。这不是打折扣的捷径，而是一个数学上等价的重新排列组合。

具体怎么做到的？论文里给了一个巧妙的处理：把词表里没被选中的那些"闲杂词条"打包成一个"其他类"（other class），这个类别专门负责扛住原本该由这些词条承担的归一化任务。这样一来，被选中的核心词条依然拿到了正确的概率值,而闲杂词条的存在感被压缩成了一个数字,不用逐个铺开占内存。

光是砍词表还不够,还要砍路径

除了压缩词表，论文还用了第二招：有限宽度的路径剪枝（finite-beam alignment pruning）。

CTC在计算的时候，要考虑一句话对应到语音帧上的所有可能"排列方式"，这些排列方式叫对齐路径。理论上路径数量可以非常庞大，但绝大多数路径的概率低到可以忽略不计。

于是论文引入了一个叫alignment beam（对齐搜索宽度）的参数，只保留那些分数跟最优路径差距不算太大的路径，把明显不靠谱的路径直接砍掉。

这就像你在导航软件里搜路线，系统不会把地球上所有可能到达目的地的走法都列出来，它只给你展示排名靠前的几条,那些绕远路绕到国外去的选项从一开始就不会进入候选池。如果不做这个筛选会怎样？系统得存下所有荒谬路径的信息，运算量和内存都会被这些没用的路径拖累。

论文对这个剪枝做了严谨的误差评估。他们测试发现，把搜索宽度设成100时，被丢弃的路径概率总和，在编码器和大语言模型两种场景下，都不超过10的负11次方,这个数字小到基本可以忽略。换句话说，剪枝几乎不损失任何精度，纯粹是在扔掉不会被用到的计算量。

效果如何：内存降了,速度稳了

光讲原理有点空，来看几个实打实的数字。

论文用了一个叫Zipformer-M的语音编码器，在词表撑到18万、批次帧数1.6万的设置下测试，Pruned CTC把训练全流程的内存占用从51.7 GiB砍到了10.1 GiB，缩减了5.1倍，而运行时间只多了17%。

这个对比有多夸张？相当于原来需要租一台顶配服务器才能跑起来的训练任务，现在用一台入门级设备就能搞定，而多花的时间不过是泡杯茶的功夫。

在大语言模型场景下，效果同样明显。论文测试了8B和14B参数规模的模型（分别对应80亿和140亿参数），仅头部计算和损失函数这一环节，内存分别缩减了25.7倍和24.8倍。算上整个训练步骤的所有开销后，总体内存分别减少了38.2%和27.3%，而每步耗时只多了7.5%和5.6%。

更重要的是，精度没有打折扣。论文在LibriSpeech、GigaSpeech、AISHELL-1三个中英文数据集上做了对比测试，Pruned CTC和标准CTC的词错误率（WER）几乎完全一致，差距都在0.02个百分点以内,这个差距小到可以归为测量误差。

从省内存到重新设计识别系统:LLM-CTC登场

省下内存只是第一步，真正有意思的是接下来的事。

因为Pruned CTC让大词表的CTC训练变得可行了，研究者顺势提出了一个更大胆的想法：能不能直接用预训练好的大语言模型来做非自回归的语音识别？

这就是LLM-CTC。

LLM-CTC*：本论文提出的方法，利用Pruned CTC让预训练大语言模型直接进行非自回归语音识别，同时保留模型原本的因果注意力机制和原生词表，不需要额外训练一套语音专用词表。

这里有个技术细节值得展开讲讲：因果注意力（causal attention）。

因果注意力*：一种注意力机制，规定模型在处理某个位置时，只能"看到"它之前的信息，看不到后面的内容，这是大语言模型能够逐字生成文本的基础机制。

保留因果注意力这件事，说起来简单，其实是个精心权衡过的决定。为什么不干脆换成双向注意力，让模型可以同时看前后文，理论上信息更充分？论文的解释是，因果结构能让模型未来无缝切换到流式识别，也就是边听边转文字，而不需要等你说完整句话才开始工作。如果一开始就抛弃因果结构去追求更高精度，那么后续想做实时语音转写时，就得从头重新设计架构，之前的训练成果全部作废。

为了让大语言模型的内部状态能对接上CTC的输出要求，论文设计了两种"读出"方式：语音读出和查询读出。

语音读出就是直接把语音对应的那部分隐藏状态拿来做CTC预测，查询读出则是额外插入一组可学习的"查询"向量，让这些查询去关注整段语音，再从查询的输出里提取CTC需要的信息。

论文做了细致的对比实验，发现在因果注意力的设定下，查询读出的效果更好。这背后的道理其实挺直观：语音读出只能看到"到当前为止"的语音片段，就像你只根据前半句话去猜完整句子的意思，而查询读出可以纵览全局，相当于先把整句话听完再回过头逐字核对，自然更准。

6个模型尺寸,一路验证到320亿参数

这篇论文的实验规模相当扎实，测试了从6亿参数到320亿参数一共六档Qwen3模型的表现。

结果显示，随着模型变大，LLM-CTC的识别效果持续变好，测试集词错误率从6亿参数时的10.57%一路降到320亿参数时的9.94%。整体来看，LLM-CTC的识别准确率始终保持在传统自回归方式（LLM-CE）的7%相对误差范围之内，但识别速度快了7到10倍。

这个速度差距怎么理解？

想象你让两个人转录同一段10分钟的录音，一个人必须一字一句听完写完才能继续写下一个字（这是自回归），另一个人可以先听完整段录音，然后同时在脑子里"并行"想清楚每个字该怎么写，一次性输出（这是LLM-CTC）。第二种方式显然快得多，因为它不需要等前一个字确定下来才能开始想下一个字。

值得一提的是，4B、8B、14B、32B这几个尺寸的LLM-CTC系统，表现甚至超过了同样用大编码器搭配CTC或RNN-T训练的专用语音识别模型。这说明大语言模型里积累的语言知识，确实能反哺非自回归的语音识别任务，哪怕这个任务本身不需要逐字生成。

流式识别:边听边转,还不用对齐标注

最后一块拼图是流式场景，也就是真正的"边说边转文字"。

这里论文解决了另一个让人头疼的问题：传统的流式语音识别训练，往往需要预先把语音切成一个个小块，再人工标注每个小块对应哪几个字，这叫chunk-level speech-text alignments，也就是块级语音文本对齐。

chunk-level speech-text alignments*：把音频切成固定长度的小段后，逐段标注对应文字内容的做法，是传统流式ASR训练里常见但费力的准备工作。

这个准备工作有多麻烦？相当于你要把一整段采访录音，先按秒切成几百个片段，再给每个片段单独配上文字标签，工作量随着录音变长线性增加。如果跳过这一步直接训练，模型很难学会该在什么时候"吐出"文字。

LLM-CTC的流式扩展绕开了这个麻烦。它依然用整句话的转录文本作为监督信号，而不需要逐块对齐，具体做法是让模型只能"看到"当前处理块之前有限时长的历史信息，这叫bounded-history streaming，有界历史流式处理。

论文在Qwen3-ASR的6亿和17亿参数版本上做了微调实验，测试结果显示，流式模式相比离线模式，词错误率只增加了不到3%的相对误差。而且，把历史窗口从2秒延长到8秒，识别效果几乎没有变化,这说明模型其实并不需要记住特别久远的上下文就能做好流式识别，2秒的窗口已经够用了。

这个结果背后其实藏着一个略微反直觉的发现：更多的历史信息不一定带来更好的效果，模型的"记忆窗口"存在一个边际效应递减的临界点。

写在后面

读完这篇论文，最触动我的其实不是那些内存优化的数字，而是研究者解决问题的方式。他们没有去发明一个全新的算法，而是精确地找到了标准CTC计算里那些"陪跑"的部分，用严谨的数学证明确保剪掉这些冗余不会损失任何精度。这种做法比起追求花哨的新架构,反而更让人信服。

另一个值得琢磨的细节是，论文里提到了一个叫Unpruned Reduced CTC的中间版本,也就是只做词表压缩、不做路径剪枝的版本。测试数据显示，光是这一步压缩就已经拿到了绝大部分的内存节省效果，而路径剪枝带来的额外收益相对有限。这说明真正的瓶颈在于词表维度的计算，而不是路径搜索本身,这个发现对于理解CTC计算的内存结构挺有启发的。

还有一点我觉得挺值得追问：论文里提到了两种"读出"方式的对比实验，查询读出在因果注意力下表现更好，但代价是增加了模型的输入长度和参数量。这种精度换效率的权衡，在实际部署时到底该怎么取舍？如果是对延迟极度敏感的实时场景，这个额外开销是否划算？论文没有给出一个万能答案，这大概也是留给后续工作的空间。

Q&A

Q1：Pruned CTC是什么？

A：Pruned CTC是一种内存高效的CTC训练方法，通过把对齐路径的计算范围限制在批次数据中实际出现的词加空白符上，同时保留完整词表的归一化计算，从而大幅降低训练时的显存占用，且数学证明其结果与标准CTC完全等价。

Q2：LLM-CTC相比传统自回归语音识别有什么优势？

A：LLM-CTC能让大语言模型进行非自回归语音识别，一次性并行输出结果而不用逐字生成，识别速度比自回归方式快7到10倍，同时准确率保持在7%相对误差范围内。

Q3：Pruned CTC能节省多少显存？

A：在词表18万、批次帧数1.6万的设置下，Pruned CTC能把训练全流程内存占用降低5.1倍，运行时间只增加17%，在大语言模型场景下内存也能减少27%到38%。