glm-asr-ctc-bench

glm-asr-ctc-bench · 导出好的 ONNX 权重

这个仓库不是模型本身，是三个 ASR 引擎导出好、量化好的 ONNX，供 bench-asr-ctc 一条命令拉下来做对比：

git clone https://github.com/JazerJu/bench-asr-ctc && cd bench-asr-ctc
pip install -r requirements.txt
python scripts/download_models.py fetch          # 三个引擎全下完
python bench.py --counts 20 --engines glm fun qwen

FETCH_FP16=1 additionally pulls the fp16 variants (DirectML)；FETCH_FP32=1 拉 GLM 的 fp32。下载脚本会把文件放到 models/<engine>/ 下，不需要手动摆放。

目录

三个引擎各一个文件夹，共 3.05 GB。

glm-ctc/ — GLM-ASR-Nano + 我们训练的 CTC 头

qwen-ctc/ — Qwen3-ASR-1.7B + 我们训练的 CTC 头（v1）

fun-asr/ — Fun-ASR-Nano（第三方，镜像）

FunAudioLLM 的模型，int4 转换沿用 CapsWriter-Offline 的打包，镜像在这里只为 一站式复现。

接线时容易踩的三个坑

这些权重不是随便 InferenceSession 一下就能用的，每条弄错都不报错、只是结果是错的：

① Qwen3 的帧率是 13 fps，不是 50。 有效输出帧数是 full*13 + ceil(leave/8)（full, leave = divmod(mel_frames, 100)），不是 T/8。 用 50 fps 的算法会把帧数高估 4 倍，logits 只有 1/4 长，转写被腰斩。 另外特征提取要 padding=False，再自己零填到 3000 帧桶，把真实帧数作为 feature_length 传进去。

② Qwen3 的反词表化必须走字节。 qwen-ctc/tokens.txt 每行是 <原始字节的 base64>\t<紧凑 id>，要拼 bytes 再统一 decode("utf-8")。 紧凑词表里保留了 89 个字节原语，一个汉字可能跨多个 token， 按字符串 "".join() 拼会得到乱码。GLM 那边的 tokens-phase2.txt 则可以直接拼。

③ GLM 的投影器吃的是堆叠后的特征。 编码器输出 1280 维，投影器的输入是 5120 = 1280 × 4，要把 4 个连续帧拼成一个再喂。直接送 1280 维会报 Got: 1280 Expected: 5120。

完整说明见两个导出仓库的 AGENTS.md： GLM-ASR-CTC-GGUF / Qwen3-ASR-CTC-GGUF。

识别率参考

FLEURS 官方 test 全量（7,876 句，11 语种，全部 int4 + CUDA EP），CTC 首遍：

GLM 6 胜 / Fun 3 胜 / Qwen 2 胜。原始数据和更多切分（Buckeye 口语英文、 中英夹杂、口语技术词召回）见 bench 仓库的 results/。

注意 provider 会影响结果：Fun 的 int4 ONNX 不是 provider 不变的 —— ORT CPU 与 CUDA EP 的转写在约 5% 的样本上不同（最多差 1.9pp CER，CPU 更弱）。 做对比时三个引擎必须用同一个 execution provider，并把它记进结果元数据。

来源与许可

我们训练的部分按基础模型的 Apache-2.0 发布。Fun-ASR-Nano 按其上游许可， 这里只是镜像。训练语料各自的许可归各自所有者，本仓库不含任何语料数据。

相关

• 评测代码：https://github.com/JazerJu/bench-asr-ctc
• 训练代码：https://github.com/JazerJu/glm-asr-ctc-train
• 导出管线：GLM · Qwen3