JazerJu/glm-asr-ctc
GLM-ASR-CTC
40.0 M 参数的 CTC 头,接在冻结的 GLM-ASR-Nano-2512 音频编码器后面,做首遍 (first-pass) 转写和强制对齐。编码器不在本仓库,运行时从 `zai-org/GLM-ASR-Nano-2512` 加载。
用途是给"CTC 首遍 + LLM 二遍"这类流水线提供快速首遍:贪心解码 RTF 0.0002 (8 卡批量),并且天然能出帧级时间戳。CTC 和 LLM decoder 共用同一套 tokenizer,所以首遍文本可以直接喂给 decoder 或热词 RAG,中间不用转换。
识别率
五个 held-out 测试集(训练集从没见过,逐条核对过没有污染),CTC 首遍贪心解码、 不含 LLM 二遍:
对照那一列是同一批数据、同一套超参训出来的 Qwen3-ASR 版。GLM 在五个集上 全面领先,按句配对自举 2000 次、八次对比全部 100.0%,没有一个置信区间沾到 0。
「按句配对自举」和「95% CI」是什么 测试集就固定那几千句,万一恰好抽到的这批句子对某个模型友好呢?自举就是 模拟「换一批句子会怎样」:从原测试集里有放回地随机抽同样多的句子,组成一个 「平行世界的测试集」,算一遍错误率,重复 2000 次,看这 2000 个结果的散布。 按句而不是按字 —— 错误在句子内部是聚集的(一句崩了往往连着错十几个字), 按字当独立样本会把有效样本量高估好几倍,置信区间算得过窄。 配对 —— 每次抽出的那批句子,两个模型都在同一批上算。这样「这批句子难不难」 对两边影响相同,做差时抵消掉,剩下的才是模型的真实差异。实测在 aishell1test 上 配对能把 CI 宽度压到非配对的一半(0.263pp vs 0.529pp),同一个真实差值 +0.208pp,配对能下结论、非配对跨 0 判不出方向。 **95% CI**(置信区间)就是这 2000 个差值排序后中间 95% 的范围。**不含 0** 表示 换哪批句子结论都一样,差异是稳的;**跨 0** 表示有些平行世界甲更好、有些乙更好, 方向判不出来,只能当噪声。 实现见 [`scripts/bootstrapcompare.py`](https://github.com/JazerJu/glm-asr-ctc-train)。
差距很可能来自编码器容量:GLM 的 audio tower 是 635.0 M 参数 / 有效宽度 1280, Qwen3 是 317.5 M / 1024 —— Qwen3-ASR-1.7B 把容量放在 LLM 上, 对一个永远看不到 LLM 的 CTC 头恰好是反的。
FLEURS 全量官方 test split(7,876 条,11 语种,int4,CUDA EP)对 Fun-ASR-Nano 是 8 胜 3 负,详见 bench-asr-ctc。
时间戳精度(对 Montreal Forced Aligner 真值实测)
LibriSpeech test-clean/other 的 1,500 句 / 29,621 词,真值来自 `gilkeyio/librispeech-alignments`:
那个 +105 ms 的起始延迟是常数,是 CTC 尖峰式发射的固有性质(概率集中在词的 中间),不是模型缺陷,减掉即可。
顺带一个实测结论:帧率不是时间戳精度的主导误差项。本模型帧移 20 ms、 Qwen3 是 76.9 ms,差 3.85 倍,但去偏置后的中位误差只差约 10 ms —— 主要误差 来自模型对词边界本身的不确定性,不是量化。
训练
用法
pip install torch "transformers>=5.0" safetensors soundfilefrom modeling_ctc import GlmCtcAsr
asr = GlmCtcAsr(".", device="cuda") # 自动拉 zai-org/GLM-ASR-Nano-2512
print(asr.transcribe([waveform_16k_float32]))离线环境把本地编码器目录给 GLM_ASR_ENCODER。完整示例(含 CTC 强制对齐出 字级时间戳)见 example.py:
python example.py audio.wav
# 转写: 甚至出现交易几乎停滞的情况
# 字级时间戳(帧移 20.0 ms):
# '甚至' 0.44 - 0.46 s
# '出现' 0.96 - 0.98 s
# ...⚠️ transformers 必须 ≥ 5.0。 GLM-ASR 的model_type是glmasr, 4.x 不认识它,会报 "does not recognize this architecture"。钉在 4.x 的环境 只能走 ONNX 路径,见下面的导出仓库。
和 Qwen3 那版的接线差异
两个 CTC 头结构同构、超参不同,但编码器的调用约定完全不一样,混用会静默出错:
本仓库这一侧都是常规做法,modeling_ctc.py 里没有需要特别当心的补丁。
文件
相关仓库
- 训练与评测代码:<https://github.com/JazerJu/glm-asr-ctc-train>
- ONNX / GGUF 导出与推理:<https://github.com/JazerJu/GLM-ASR-CTC-GGUF>
- 导出好的 int4 ONNX(可直接跑):<https://huggingface.co/JazerJu/glm-asr-ctc-bench>
- 三方对比评测:<https://github.com/JazerJu/bench-asr-ctc>
许可
CTC 头权重按基础模型 GLM-ASR-Nano-2512 的 Apache-2.0 发布。训练语料各自的许可 归各自所有者,本仓库不含任何语料数据。
