语音输入这件事，从最早只能识别标准普通话、错字连篇，到现在中英混说、带口音、甚至环境嘈杂都能给你准确转出来，中间也就隔了几年时间。但问题也随之而来：市面上的 ASR 模型越来越多，开源的、闭源的、大厂 API、本地部署的小模型，各家都宣称自己"识别率最高""延迟最低""多语种最强"。真到自己要选一个落地的时候，反而不知道该信谁。我最近因为项目需要，把主流的一批 ASR 模型拉出来做了一轮系统评测，从识别准确率、多语种支持、抗噪能力、延迟、部署成本几个维度逐一实测，踩了不少坑，也总结出一些选型上的门道。这篇就把整个评测过程、方法和结论完整分享出来，不管你是要做语音输入法、会议转写、客服质检还是字幕生成，都能从中找到适合自己的那一款。

1. 为什么 ASR 评测不能只看"识别率"这一个数字

1.1 单一指标背后的陷阱

很多人做 ASR 选型，第一反应就是看各家公布的 WER（词错误率）。这个指标确实重要，但它是一个被高度"美化"过的数字。厂商在公布 WER 时，用的往往是 LibriSpeech、AISHELL 这类干净朗读数据集，录音环境安静、发音标准、语速均匀。可你真实业务里的音频是什么样？电话客服带着 8k 采样率的窄带噪声，会议录音有远场混响和多人抢话，短视频字幕里全是网络热词和英文夹杂。拿朗读集的 WER 去预测这些场景的表现，基本等于拿实验室油耗去衡量城市堵车路况。

我在第一轮测试时就吃过这个亏。当时选了一个在公开榜单上 WER 只有 3% 出头的模型，结果拿真实客服录音一跑，错误率直接飙到 20% 以上，专有名词几乎全军覆没。后来才明白，公开榜单的测试集和真实业务数据之间存在巨大的分布差异，这个差异在专业上叫域偏移（Domain Shift）。所以评测的第一原则是：必须用你自己业务场景的真实音频做测试集，哪怕只有几十条，也比跑一百个公开榜单有参考价值。

1.2 我实际采用的评测维度

经过几轮调整，我最终把评测拆成了六个维度，每个维度都有明确的测试方法和权重。这套框架后来在团队内部复用，效果比较稳，直接列出来供参考：

这个权重不是拍脑袋定的，而是根据"语音输入"这个具体场景调的。语音输入的核心诉求是边说边出字、准确、不挑环境，所以真实场景准确率和延迟占了很大比重。如果你的场景是离线批量转写，那延迟权重可以降到 5% 以下，把省下的权重加到准确率上。

1.3 测试集构建的几个关键细节

测试集的质量直接决定评测结论的可信度。我构建测试集时遵循了几个原则，这里展开说一下，因为这是很多人容易忽略的地方。

第一是覆盖发音多样性。我特意找了带南方口音、北方口音、语速快慢不同的说话人，每种至少 3 人。因为 ASR 模型对训练数据里占比高的口音天然更友好，如果你的用户群体口音集中，测试集就必须反映这一点。

第二是标注规范统一。中文标注要明确数字怎么处理（"2024"是标成"二零二四"还是"2024"）、英文单词怎么算（算一个词还是按字母）、标点是否计入。这些规则不统一，算出来的 CER 没有可比性。我一般用字错率 CER作为中文主指标，因为它对分词不敏感，比 WER 更稳定。

第三是样本量。每个场景至少 50 条、总时长不低于 30 分钟，否则统计波动太大。我一开始只用了 20 条，两次跑出来的结果差了 5 个百分点，完全没有参考意义。

2. 参评模型清单与各自的定位差异

2.1 参评模型一览

这一轮我选了 6 个有代表性的模型/服务，覆盖开源本地部署、开源可商用、大厂闭源 API 三种类型。选它们的原因是它们在各自赛道里都有明确的用户群，且定位差异明显，对比起来有信息量。

需要说明的是，这里不点名具体商业品牌，一是避免变成软文，二是不同时期各家版本迭代很快，具体名字意义不大，方法论比结论更重要。你完全可以用这套框架去测你手头能拿到的任何模型。

2.2 开源与闭源的真实取舍

很多人纠结开源还是闭源，我的经验是看三个条件：数据敏感度、调用量、定制需求。

如果音频涉及用户隐私或商业机密，不能出内网，那基本只能选开源本地部署。闭源 API 再准，数据要传到别人服务器上，合规这关就过不了。反过来，如果只是做个 demo 或者调用量很小，自己搭一套推理服务的运维成本远高于直接调 API，那就别折腾开源自部署。

调用量是个关键分水岭。我算过一笔账：一个中等规模的语音输入应用，日调用 10 万次、每次 10 秒音频，用云 API 按量付费，一个月下来费用不低；而自部署一台带 GPU 的服务器，虽然前期投入大，但边际成本几乎为零，跑满一年就回本了。所以高频场景自部署更划算，低频场景调 API 更省心。

定制需求则决定了开源的必要性。比如你要做垂直领域的语音输入，满屏都是行业术语，通用模型识别不了，这时候就需要热词增强或者微调。闭源 API 一般提供热词表功能，但微调基本不开放；开源模型则可以拿自己的数据做微调，效果提升空间大得多。

2.3 一个容易被忽略的选型维度：许可证

开源模型的许可证差异很大，有的允许商用，有的仅限研究，有的对商用有附加条件。我见过团队辛苦调优了几个月，最后发现模型许可证不允许商用，只能推倒重来。所以选开源模型前，第一件事是看 LICENSE 文件，确认商用条款、是否需要保留版权声明、是否有用户规模限制。这个坑踩一次就够了。

3. 实测过程：从环境搭建到逐项打分

3.1 测试环境与统一变量控制

为了保证公平，所有本地模型都在同一台机器上跑，配置是单卡 24G 显存、32 核 CPU、64G 内存。云 API 则在同一网络环境下调用，避免网络波动影响延迟测试。测试音频统一转成 16kHz、16bit、单声道的 WAV 格式，因为这是绝大多数 ASR 模型的标准输入格式，采样率不对会直接影响识别效果。

这里有个细节值得强调：重采样质量会影响结果。我一开始用了一个简单的线性插值重采样，结果高频信息损失严重，识别率比预期低了一截。后来换成带抗混叠滤波的重采样（比如用 sox 或 ffmpeg 的高质量模式），同一批音频的识别率提升了 2 到 3 个百分点。所以预处理这一步千万别图省事。

# 用 ffmpeg 做高质量重采样到 16k 单声道 ffmpeg -i input.mp3 -ar 16000 -ac 1 -sample_fmt s16 output.wav

3.2 准确率测试：CER 计算与人工复核

准确率测试我用了两套数据：一套是干净朗读音频作为基线，一套是真实业务音频作为主战场。计算 CER 的公式是：

CER = (替换字数 + 删除字数 + 插入字数) / 标注总字数

我用 Python 的jiwer库做批量计算，但机器算完必须人工抽检。因为有些"错误"其实是标注规范不一致导致的，比如模型输出"AI"而标注写的是"人工智能"，机器判为错误，实际语义完全正确。我一般抽检 20% 的样本，把这类"假错误"剔除后再统计，结果才靠谱。

实测下来有个反直觉的发现：在干净朗读音频上，几个模型的差距很小，基本都在 3% 到 6% 之间；但一到真实场景，差距瞬间拉开到 10% 以上。这说明公开榜单的高分参考价值有限，真正决定体验的是模型在脏数据上的鲁棒性。那些在训练时用了大量增强数据（加噪、加混响、变速）的模型，真实场景表现明显更稳。

3.3 多语种与中英混说的实测表现

中英混说是中文语音输入的高频场景，比如"帮我打开这个 app 的设置页面""这个 bug 什么时候 fix"。测试时我专门准备了一批中英混说样本，观察模型的语种切换能力。

结果差异非常明显。有的模型会把英文单词强行识别成发音相近的中文，比如把"app"识别成"阿婆"，把"bug"识别成"巴格"，这种错误在语义上完全跑偏。而支持 code-switching 的模型能正确输出英文单词，甚至能根据上下文判断该用哪种语言。

小语种方面，我测了粤语和日语。粤语对大部分普通话模型来说是灾难，除非专门训练过。日语则要看模型的多语种覆盖，Whisper 这类多语种模型表现较好，但中文专用模型基本不支持。所以如果你的场景涉及方言或小语种，选型时一定要确认模型的语言覆盖列表，别想当然。

3.4 抗噪与远场：真实环境才是试金石

抗噪测试我用了三种方式：加白噪声、加人声背景音、模拟远场混响。加噪用ffmpeg的anoisesrc滤镜，混响用afir滤镜加载脉冲响应。

# 给音频叠加白噪声，信噪比约 10dB ffmpeg -i clean.wav -f lavfi -i "anoisesrc=d=10:c=pink:a=0.05" \ -filter_complex "[0:a][1:a]amix=inputs=2:duration=first" noisy.wav

实测结论是：近场加噪，各模型都还能扛；远场混响，差距就出来了。远场录音的特点是声音经过墙壁反射，频谱被严重改变，加上距离衰减，信噪比很低。这种情况下，那些在训练时做过 RIR（房间脉冲响应）增强的模型优势明显，错误率能比没做增强的低一半以上。

这里分享一个实操心得：如果你的场景是远场（比如会议室、车载），麦克风阵列和降噪前端比换模型更有效。我试过在同样的远场音频上，先过一遍降噪再做识别，效果提升比换一个更强的模型还明显。所以别把所有希望都寄托在 ASR 模型本身，前端信号处理同样关键。

3.5 延迟测试：RTF 与首字延迟的区别

延迟这块要区分两个指标：RTF（Real Time Factor）和首字延迟。RTF 是处理时长除以音频时长，RTF 小于 1 表示比实时快；首字延迟是从音频输入到吐出第一个字的时间，直接决定"边说边出字"的体验。

对于语音输入场景，首字延迟比 RTF 更重要。我用流式接口测试时发现，有的模型 RTF 很低（整体处理快），但首字延迟高（要等一大段才出字），用起来就很别扭。理想的语音输入体验是首字延迟控制在 300ms 以内，之后持续稳定输出。

影响延迟的因素很多：模型大小、是否流式、批处理策略、硬件。我实测下来，流式模型的首字延迟普遍比非流式低一个数量级，因为非流式要等整段音频结束才开始处理。所以做实时语音输入，一定要选支持流式的模型或接口。

4. 各模型实测结果与场景化推荐

4.1 综合得分对比

把六个维度的得分加权汇总后，结果如下（分数为相对值，满分 100）：

这张表只是我这次测试的一个快照，不同版本、不同硬件下结果会变，重点看趋势和取舍逻辑，别把具体数字当圣旨。

4.2 不同场景该怎么选

实时语音输入（输入法、语音助手）：首选 Paraformer 这类中文优化、支持流式的模型，首字延迟低、中文准确率高。如果要在移动端离线跑，轻量端侧模型虽然准确率低一些，但胜在完全离线、功耗低、隐私好。

会议转写与字幕：Whisper 系列的多语种和鲁棒性优势明显，尤其是涉及中英混说或外语内容时。如果会议是纯中文且对准确率要求极高，大厂 API B 的中文优化和热词功能更合适。

客服质检：这类场景音频质量差（电话窄带）、有大量专有名词，建议用支持热词增强的模型，并且一定要用真实客服录音做验证。我实测发现，热词功能对专有名词的识别提升非常显著，能把相关错误率降低一半以上。

离线批量转写：延迟不重要，准确率和成本是核心。开源自部署 + 大模型组合，配合批处理，性价比最高。

4.3 一个被低估的优化手段：热词与上下文

不管选哪个模型，热词表都是性价比最高的优化手段。把业务里的专有名词、人名、产品名整理成热词表喂给模型，识别率提升立竿见影。我做过对比，加了 200 个热词后，相关专有名词的识别准确率从 60% 提升到 90% 以上。

更进一步的是上下文注入。有些模型支持在识别时传入上下文文本，让模型知道当前在聊什么话题，从而更准确地选择同音词。比如聊"苹果"时，是水果还是品牌，上下文能帮模型判断。这个功能在会议、客服场景特别有用。

5. 评测中踩过的坑与避坑经验

5.1 采样率与位深不匹配导致结果失真

这是我最开始踩的坑。测试音频有的是 44.1kHz，有的是 8kHz，我图省事直接喂给模型，结果 8kHz 的音频识别率奇低。后来才意识到，模型训练时的采样率是固定的，输入采样率不匹配会导致频谱错位。正确做法是统一重采样到模型要求的采样率，并且用高质量重采样算法。这个坑很隐蔽，因为音频听起来没问题，但识别结果就是差。

5.2 用错评测指标：CER 和 WER 别混用

中文场景我强烈建议用 CER（字错率），因为中文分词本身就有歧义，用 WER 会因为分词差异产生大量"假错误"。我一开始用 WER，两个语义完全正确的句子因为分词不同被判为错误，导致结论完全失真。换成 CER 后结果稳定多了。英文场景则相反，用 WER 更合适。

5.3 忽略标点与大小写的影响

有些模型输出带标点，有些不带；有些英文全大写，有些正常大小写。如果评测时不统一处理，这些差异会污染 CER 计算。我的做法是评测前统一去除标点、英文统一转小写，只比较核心文字内容。当然，如果你的业务需要标点，那标点准确率要单独作为一个指标来测。

5.4 延迟测试受硬件和并发影响大

延迟测试一定要在目标硬件上做，并且模拟真实并发。我在开发机上测出来的延迟很漂亮，一上生产环境、并发一上来，延迟直接翻倍。因为 GPU 推理是共享资源，并发高时排队严重。所以延迟测试要压测，测 P99 而不是平均值，平均值会掩盖长尾问题。

5.5 盲目追求大模型

大模型确实准确率高，但推理成本也高。我见过团队为了追求几个百分点的准确率提升，上了最大的模型，结果显存不够、并发上不去、成本爆炸。选型要在准确率和成本之间找平衡点，很多时候中等模型 + 热词 + 前端降噪的组合，效果比单纯堆大模型更好，成本还低得多。

6. 把评测做成可持续的工程能力

6.1 建立回归测试集

一次评测的结论会过时，因为模型在迭代、业务在变化。我的做法是维护一个固定的回归测试集，每次模型更新或业务调整后重跑一遍，看指标有没有退化。这个测试集不用很大，但要覆盖核心场景，并且标注质量要高。有了它，模型升级就不再是"凭感觉"，而是有数据支撑的决策。

6.2 自动化评测流水线

手工评测太累且不可复现。我后来搭了一套简单的自动化流水线：音频预处理、批量推理、CER 计算、结果汇总全部脚本化，一条命令跑完。核心就是用 Python 把各个环节串起来，输出一份带对比的评测报告。

import jiwer def compute_cer(refs, hyps): # 中文 CER：按字符比较 return jiwer.cer(refs, hyps) # 批量评测 results = {} for name, model in models.items(): hyps = [model.transcribe(a) for a in audios] results[name] = compute_cer(refs, hyps)

这套流水线搭好后，评测从"几天"缩短到"几小时"，而且结果可复现、可追溯。

6.3 持续关注线上真实数据

评测集再全，也代表不了全部线上情况。我习惯在线上埋点，收集识别置信度低的样本，定期人工复核，把确认有问题的样本补充进回归测试集。这样测试集越来越贴近真实分布，评测结论也越来越准。评测不是一次性任务，而是一个持续迭代的闭环。

7. 关于语音输入选型，我个人的几点体会

折腾完这一轮，我最大的感受是：没有"最好"的 ASR 模型，只有"最适合你场景"的模型。公开榜单的高分只能作为初筛，真正的决策必须基于你自己的数据、自己的硬件、自己的成本约束。

如果非要给个优先级建议，我会说：先明确场景（实时还是离线、近场还是远场、单语还是多语），再确定部署方式（云端还是本地），最后才是在候选模型里比准确率。顺序反了，很容易在错误的方向上优化。

另外，别忽视工程侧的优化空间。热词、前端降噪、上下文注入、流式策略，这些"外围"手段带来的提升，有时候比换模型还大。我见过太多团队把精力全花在选模型上，却忽略了这些更容易见效的地方。

最后分享一个小技巧：做选型对比时，一定要让最终用户参与评测。因为 CER 低不代表体验好，用户对某些错误的容忍度是不一样的。比如把"的"识别成"地"，用户根本不在意；但把人名识别错，用户会很恼火。让真实用户听几段识别结果，他们的反馈往往比任何指标都直接。