语音输入这件事从最早只能识别标准普通话、错字连篇到现在中英混说、方言夹杂、专业术语满天飞也能给你准确转出来中间也就隔了几年时间。但问题也随之而来市面上的 ASR 模型越来越多开源的、闭源的、大厂 API、本地部署的小模型每个都说自己识别率高、延迟低、支持多语种可真到用的时候你会发现同一个音频文件A 模型转出来像模像样B 模型直接给你整出一堆同音错别字C 模型倒是准但延迟高得让人想砸键盘。我最近因为项目需要集中测了一批 ASR 模型从云端 API 到本地部署的 Whisper 系列、Paraformer、SenseVoice 等等踩了不少坑也积累了一些选型上的经验。这篇文章就把整个评测过程、参数选择、实操步骤和常见问题都摊开来讲不管你是刚接触语音识别的新手还是正在做模型选型的老手应该都能从中找到有用的东西。1. 评测背景与整体设计思路1.1 为什么要做这次 ASR 评测先说清楚动机。我手上有一个语音转写的需求场景比较杂一部分是会议录音多人说话、有重叠、有远场拾音一部分是短视频字幕生成要求低延迟、标点准确还有一部分是客服通话质检需要区分说话人、识别专业术语。这三个场景对 ASR 的要求其实完全不一样会议录音看重准确率和说话人分离短视频字幕看重响应速度和标点恢复客服质检看重领域适配和热词定制。如果只用一个模型打天下必然会在某个场景上翻车。所以这次评测的核心目标不是找出一个“最强模型”而是搞清楚每个模型适合什么场景、在什么条件下表现最好、边界在哪里。这个思路很重要因为 ASR 评测最容易犯的错误就是拿一个通用测试集跑一遍 WER词错误率然后按数字排名。但实际使用中WER 低不代表你的场景就好用可能它在你的领域词汇上错得一塌糊涂也可能它延迟高到根本没法做实时字幕。1.2 评测维度的选择与权重分配我最终确定了六个评测维度每个维度的权重根据实际使用场景来定评测维度权重说明识别准确率30%包括通用场景和领域场景的 WER/CER推理延迟20%首字延迟和整体转写耗时多语种支持15%中英混说、方言、小语种的识别效果标点与格式化15%标点恢复、数字规范化、大小写处理部署与资源占用10%本地部署的显存占用、CPU 推理速度定制化能力10%热词、说话人分离、领域微调支持这个权重不是拍脑袋定的。识别准确率给 30% 是因为它始终是 ASR 的核心指标但为什么不是 50%因为在实际工程中准确率到了一定的阈值之后比如 95% 以上再提升 1% 带来的收益远不如延迟降低 100ms 来得明显。推理延迟给 20% 是因为实时场景下这是硬指标首字延迟超过 500ms 基本就没法做交互式应用了。多语种和标点各 15%是因为现在的内容很少是纯中文或纯英文中英混说太常见了标点不对读起来也难受。1.3 测试数据集的构建测试数据这块我花了很大功夫。公开测试集比如 AISHELL、LibriSpeech 这些当然要跑但它们太“干净”了录音棚环境、标准发音、没有背景噪声跟真实场景差距太大。所以我额外构建了一个“野生测试集”包含以下几类会议录音8 段每段 15-30 分钟多人对话有重叠有远场拾音包含少量方言口音短视频音频20 段每段 15-60 秒语速快有背景音乐中英混说频繁客服通话10 段每段 3-5 分钟包含大量专业术语和产品名称朗读音频5 段标准普通话朗读作为基线对照噪声环境5 段包含键盘声、空调声、街道噪声等每段音频都做了人工精标作为 ground truth。标注规范参考了通用转写标准但针对中文场景做了一些调整比如数字统一转成阿拉伯数字、英文单词保持原样、语气词根据是否影响语义决定是否保留。提示构建测试集时一定要注意标注一致性。我一开始没注意两个人标同一段音频一个把“嗯”标进去了一个没标导致 WER 计算出来偏差很大。后来统一了规范才解决。2. 核心模型拆解与技术原理2.1 Whisper 系列开源界的标杆Whisper 是 OpenAI 开源的 ASR 模型目前有 tiny、base、small、medium、large 几个版本large 又分 v1、v2、v3。它的核心架构是 Encoder-Decoder 的 Transformer输入是 80 维的 log-Mel 频谱图输出是文本 token。Whisper 最大的优势是多语种能力强训练数据有 68 万小时覆盖 99 种语言而且中英混说的识别效果在开源模型里算是第一梯队。但 Whisper 的问题也很明显。首先是幻觉问题在静音段或者噪声段它有时候会“编”出一些原文没有的内容比如突然冒出一句“谢谢观看”或者“请订阅频道”这是因为训练数据里包含大量 YouTube 字幕模型学到了这些模式。其次是延迟large 模型在 GPU 上跑首字延迟大概在 300-500ms如果做流式识别需要配合 VAD语音活动检测做分段否则延迟会更高。另外 Whisper 不支持原生的流式推理要做实时字幕得自己搭一套 chunk-based 的推理框架。我实测下来Whisper large-v3 在会议录音上的 WER 大概是 8%-12%短视频音频上 10%-15%客服通话上因为专业术语多WER 会到 15%-20%。这个成绩不算差但也不算惊艳。2.2 Paraformer阿里系的工业级方案Paraformer 是达摩院开源的 ASR 模型主打非自回归架构推理速度比 Whisper 快很多。它的核心创新是 Predictor 模块可以并行预测所有输出 token而不是像自回归模型那样一个一个吐。这使得 Paraformer 在 CPU 上也能跑到接近实时的速度GPU 上更是快得飞起。Paraformer 的中文识别准确率很高在 AISHELL 测试集上 CER 可以到 2% 以下。但它对英文的支持相对弱一些中英混说场景下英文单词的识别错误率明显高于 Whisper。另外 Paraformer 的热词定制功能很实用你可以传入一个热词列表模型会提升这些词的识别优先级这对客服质检、医疗转写这类场景非常友好。部署方面Paraformer 有 ONNX 版本可以在没有 GPU 的机器上跑显存占用也低large 模型大概 2-3GB 显存就够了。如果你要做本地部署且预算有限Paraformer 是很务实的选择。2.3 SenseVoice多语种与情感识别SenseVoice 是 FunAudioLLM 体系下的 ASR 模型特点是多语种识别 情感识别 音频事件检测三合一。它支持中文、英文、粤语、日语、韩语等而且在情感识别上做了专门优化可以判断说话人的情绪状态中性、开心、生气、悲伤等。这个功能在客服质检场景下很有价值你可以直接拿到每通电话的情绪曲线。SenseVoice 的推理速度也很快非自回归架构延迟低。但它的中文识别准确率相比 Paraformer 稍逊一筹尤其是在专业术语上。不过它的多语种切换很自然中英混说不需要额外配置模型会自动处理。2.4 云端 API大厂方案的优劣除了开源模型我也测了几家云厂商的 ASR API。云端方案的优势是开箱即用、维护成本低、准确率通常更高因为大厂有更多的数据和算力做优化。但劣势也很明显按量计费成本高、数据隐私问题、延迟受网络影响、定制化能力有限。实测下来云端 API 在通用场景的准确率确实比开源模型高 2-5 个百分点尤其是在噪声环境和远场拾音上。但如果你有大量音频要转写成本会迅速上升。另外云端 API 通常不支持本地部署如果你的数据不能出内网那就只能选开源方案。2.5 模型选型决策树基于以上分析我整理了一个简单的选型决策树数据能否出内网不能 → 必须本地部署 → 跳到第 2 步能 → 跳到第 4 步有没有 GPU有 → Whisper large 或 Paraformer没有 → Paraformer ONNX 或 SenseVoice主要场景是什么中文为主 → Paraformer多语种 → SenseVoice 或 Whisper需要情感识别 → SenseVoice预算是多少充足 → 云端 API有限 → 开源自部署需要定制热词吗需要 → Paraformer 或云端 API不需要 → Whisper 也可以这个决策树不是绝对的但可以帮你快速缩小选择范围。3. 实操过程与核心环节实现3.1 环境准备与依赖安装先说我用的测试环境Ubuntu 22.04GPU 是 RTX 409024GB 显存CPU 是 Intel i9-13900K内存 64GB。这个配置不算低但也不是顶配有一定的参考价值。Whisper 的安装比较简单用 pip 就行pip install openai-whisper但如果你要用 faster-whisper基于 CTranslate2 的加速版本安装方式略有不同pip install faster-whisperfaster-whisper 的推理速度比原版 Whisper 快 4 倍左右显存占用也更低强烈推荐。实测 large-v3 在 faster-whisper 下RTX 4090 上转写 1 小时音频大概需要 2-3 分钟而原版 Whisper 需要 8-10 分钟。Paraformer 的安装通过 FunASR 框架pip install funasrSenseVoice 同样通过 FunASRpip install funasr pip install modelscope模型下载可以用 modelscope 的命令行工具也可以直接在代码里指定模型名称自动下载。3.2 测试脚本的编写为了公平对比我写了一个统一的测试脚本输入是音频文件路径和模型名称输出是转写文本、耗时、显存占用等指标。核心逻辑如下import time import torch from faster_whisper import WhisperModel def test_whisper(audio_path, model_sizelarge-v3): start time.time() model WhisperModel(model_size, devicecuda, compute_typefloat16) segments, info model.transcribe(audio_path, languagezh, beam_size5) text .join([seg.text for seg in segments]) elapsed time.time() - start return text, elapsedParaformer 的测试脚本from funasr import AutoModel def test_paraformer(audio_path): model AutoModel(modelparaformer-zh, model_revisionv2.0.4) start time.time() res model.generate(inputaudio_path, batch_size_s300) elapsed time.time() - start return res[0][text], elapsedSenseVoice 的测试脚本from funasr import AutoModel def test_sensevoice(audio_path): model AutoModel(modeliic/SenseVoiceSmall, trust_remote_codeTrue) start time.time() res model.generate(inputaudio_path, languageauto, use_itnTrue) elapsed time.time() - start return res[0][text], elapsed注意测试时一定要先做 warm-up也就是先跑一段短音频让模型加载到显存然后再测正式音频。否则第一次推理的时间会包含模型加载时间导致数据不准。3.3 关键参数的选择与计算ASR 模型有几个关键参数会显著影响识别效果和速度我逐个说明。Beam SizeWhisper 的 beam search 参数默认是 5。增大 beam size 会提升准确率但推理时间线性增加。我实测 beam_size5 和 beam_size10 的 WER 差距大概在 0.5%-1%但推理时间翻倍。所以除非对准确率有极致要求否则 beam_size5 就够了。VAD 阈值做流式识别时VAD 用来判断语音段的开始和结束。阈值设得太高会漏掉一些轻声细语设得太低会把噪声当成语音。我一般用 silero-vad阈值设在 0.5 左右配合 min_speech_duration250ms 和 min_silence_duration100ms效果比较平衡。Chunk Size流式识别时每次处理的音频长度。chunk 太小上下文不足准确率下降chunk 太大延迟增加。我实测下来chunk_size1s 配合 0.5s 的 overlap 是一个不错的平衡点首字延迟可以控制在 300ms 以内。热词权重Paraformer 支持热词定制可以给每个热词设置权重。权重太高会导致误召回太低又没效果。我一般设在 10-20 之间具体根据热词的重要程度调整。3.4 实测数据记录与分析以下是部分实测数据测试音频为 10 分钟会议录音包含 4 人对话有少量重叠模型WER首字延迟总耗时显存占用Whisper large-v39.2%420ms28s10GBfaster-whisper large-v39.5%380ms7s6GBParaformer-zh8.1%150ms5s3GBSenseVoiceSmall10.3%120ms4s2GB云端 API A7.5%200ms6s-从数据可以看出Paraformer 在中文会议场景下表现最好WER 最低且延迟低、显存占用小。Whisper 的准确率稍逊但 faster-whisper 的加速效果非常明显。SenseVoice 虽然 WER 稍高但延迟最低适合对实时性要求极高的场景。短视频场景的数据又不一样模型WER标点准确率中英混说准确率Whisper large-v311.5%92%88%Paraformer-zh13.2%85%76%SenseVoiceSmall12.8%88%82%云端 API A10.2%94%90%短视频场景下Whisper 和云端 API 的中英混说优势就体现出来了Paraformer 的英文识别明显拖了后腿。4. 常见问题与排查技巧实录4.1 识别结果出现重复或幻觉这是 Whisper 最常见的问题尤其是在静音段或噪声段。表现是模型反复输出同一句话或者编造出原文没有的内容。解决方法有几个开启 VAD 预处理把静音段切掉减少模型“自由发挥”的空间设置condition_on_previous_textFalse避免模型被前文带偏调整compression_ratio_threshold和logprob_threshold过滤掉低质量的输出如果还是不行换 faster-whisper它的幻觉问题比原版轻一些4.2 中英混说识别错误率高中英混说是 ASR 的老大难问题。Whisper 相对好一些但也不是完美。提升方法在 prompt 里加入中英混说的示例引导模型进入正确的模式使用支持多语种的模型比如 SenseVoice 或云端 API对英文单词做后处理用词典匹配修正明显的错误4.3 专业术语识别不准客服质检、医疗转写这类场景专业术语识别不准是致命的。解决方法使用支持热词定制的模型比如 Paraformer把术语列表传进去对识别结果做后处理用编辑距离匹配术语词典自动纠正如果数据量够可以做领域微调但成本较高4.4 延迟过高无法做实时字幕实时字幕对延迟要求很高首字延迟最好在 300ms 以内。如果延迟过高换更小的模型比如 Whisper small 或 SenseVoiceSmall使用非自回归模型比如 Paraformer优化推理框架用 ONNX Runtime 或 TensorRT 加速调整 chunk size 和 overlap找到延迟和准确率的平衡点4.5 显存不足无法加载模型如果 GPU 显存不够可以使用量化版本比如 int8 量化显存占用可以减少一半使用 CPU 推理Paraformer 的 ONNX 版本在 CPU 上也能跑换更小的模型比如 Whisper base 或 small使用模型卸载策略不用的层放到内存里提示量化会带来一定的准确率损失int8 量化大概损失 1%-2% 的 WER需要根据场景权衡。4.6 常见问题速查表问题可能原因解决方法识别结果重复幻觉开 VAD、调阈值、换 faster-whisper中英混说错误多模型多语种能力弱换 SenseVoice 或云端 API专业术语不准缺乏领域适配热词定制、后处理纠正延迟过高模型太大或框架未优化换小模型、用 ONNX/TensorRT显存不足模型太大量化、CPU 推理、换小模型标点缺失模型不支持标点恢复换支持标点的模型或后处理加标点5. 不同场景下的选型建议与实操心得5.1 会议录音转写准确率优先会议录音的特点是时长长、多人说话、有重叠、有远场拾音。这种场景下准确率是第一位的延迟可以放宽。我的建议是首选 Paraformer-zh中文准确率最高显存占用低支持热词定制如果需要说话人分离配合 pyannote-audio 做 diarization如果中英混说多考虑 Whisper large-v3 或云端 API后处理一定要做包括标点恢复、数字规范化、术语纠正实操心得会议录音一定要做 VAD 分段否则 Whisper 很容易在静音段产生幻觉。另外如果会议有明确的议程和术语提前准备热词列表识别准确率能提升 3-5 个百分点。5.2 短视频字幕延迟优先短视频字幕要求快速生成通常几分钟内就要出结果。这种场景下延迟比准确率更重要。我的建议是首选 SenseVoiceSmall延迟最低多语种支持好如果对准确率要求高用 faster-whisper large-v3标点恢复一定要开否则字幕读起来很累可以接受一定的错误率因为字幕有上下文观众能理解实操心得短视频字幕不要追求 100% 准确95% 就够了。关键是标点要对断句要合理。我一般会用 LLM 做后处理把 ASR 的输出丢给 LLM让它加标点、修正明显的错别字效果很好。5.3 客服质检领域适配优先客服质检需要识别专业术语、区分说话人、分析情绪。这种场景下领域适配能力最重要。我的建议是首选 Paraformer 热词定制把产品名称、术语都加进去如果需要情绪分析用 SenseVoice它自带情感识别说话人分离用 pyannote-audio 或云端 API 自带的 diarization后处理要做术语纠正和敏感词检测实操心得客服质检的热词列表要持续维护每周根据新的错误案例更新。我一般会统计识别错误的词频把高频错误词加入热词列表迭代几轮之后准确率会明显提升。5.4 本地部署 vs 云端 API 的取舍这个取舍的核心是数据隐私、成本、维护能力三个因素。如果数据不能出内网那只能本地部署。本地部署的初始成本高需要 GPU但长期成本低没有按量计费。维护方面本地部署需要自己处理模型更新、故障排查、性能优化有一定技术门槛。如果数据可以出内网且预算充足云端 API 是更省心的选择。准确率通常更高维护成本低弹性扩容方便。但要注意数据隐私条款以及长期使用的成本累积。我的建议是核心业务用本地部署非核心业务用云端 API。这样既能保证核心数据的安全又能享受云端 API 的便利。5.5 模型迭代与持续优化ASR 模型不是部署完就一劳永逸的。随着业务变化新的术语、新的口音、新的场景会不断出现模型需要持续优化。我的做法是建立错误案例库定期分析识别错误的模式根据错误模式更新热词列表、调整后处理规则每季度重新评测一次看是否有新的模型或版本值得升级如果数据量够考虑领域微调但要做好数据标注和验证这个内容后续还可以这样扩展把 ASR 和 LLM 结合起来做端到端的语音理解不只是转写文字而是直接输出结构化的会议纪要、客服质检报告。这个方向目前已经很成熟了我下个项目就打算这么干。 
长河君 · 2026/10/31 15:59:41 · 阅读 1.2k ASR模型选型评测：Whisper、Paraformer、SenseVoice与云端API对比
语音输入这件事从最早只能识别标准普通话、错字连篇到现在中英混说、方言夹杂、专业术语满天飞也能给你准确转出来中间也就隔了几年时间。但问题也随之而来市面上的 ASR 模型越来越多开源的、闭源的、大厂 API、本地部署的小模型每个都说自己识别率高、延迟低、支持多语种可真到用的时候你会发现同一个音频文件A 模型转出来像模像样B 模型直接给你整出一堆同音错别字C 模型倒是准但延迟高得让人想砸键盘。我最近因为项目需要集中测了一批 ASR 模型从云端 API 到本地部署的 Whisper 系列、Paraformer、SenseVoice 等等踩了不少坑也积累了一些选型上的经验。这篇文章就把整个评测过程、参数选择、实操步骤和常见问题都摊开来讲不管你是刚接触语音识别的新手还是正在做模型选型的老手应该都能从中找到有用的东西。1. 评测背景与整体设计思路1.1 为什么要做这次 ASR 评测先说清楚动机。我手上有一个语音转写的需求场景比较杂一部分是会议录音多人说话、有重叠、有远场拾音一部分是短视频字幕生成要求低延迟、标点准确还有一部分是客服通话质检需要区分说话人、识别专业术语。这三个场景对 ASR 的要求其实完全不一样会议录音看重准确率和说话人分离短视频字幕看重响应速度和标点恢复客服质检看重领域适配和热词定制。如果只用一个模型打天下必然会在某个场景上翻车。所以这次评测的核心目标不是找出一个“最强模型”而是搞清楚每个模型适合什么场景、在什么条件下表现最好、边界在哪里。这个思路很重要因为 ASR 评测最容易犯的错误就是拿一个通用测试集跑一遍 WER词错误率然后按数字排名。但实际使用中WER 低不代表你的场景就好用可能它在你的领域词汇上错得一塌糊涂也可能它延迟高到根本没法做实时字幕。1.2 评测维度的选择与权重分配我最终确定了六个评测维度每个维度的权重根据实际使用场景来定评测维度权重说明识别准确率30%包括通用场景和领域场景的 WER/CER推理延迟20%首字延迟和整体转写耗时多语种支持15%中英混说、方言、小语种的识别效果标点与格式化15%标点恢复、数字规范化、大小写处理部署与资源占用10%本地部署的显存占用、CPU 推理速度定制化能力10%热词、说话人分离、领域微调支持这个权重不是拍脑袋定的。识别准确率给 30% 是因为它始终是 ASR 的核心指标但为什么不是 50%因为在实际工程中准确率到了一定的阈值之后比如 95% 以上再提升 1% 带来的收益远不如延迟降低 100ms 来得明显。推理延迟给 20% 是因为实时场景下这是硬指标首字延迟超过 500ms 基本就没法做交互式应用了。多语种和标点各 15%是因为现在的内容很少是纯中文或纯英文中英混说太常见了标点不对读起来也难受。1.3 测试数据集的构建测试数据这块我花了很大功夫。公开测试集比如 AISHELL、LibriSpeech 这些当然要跑但它们太“干净”了录音棚环境、标准发音、没有背景噪声跟真实场景差距太大。所以我额外构建了一个“野生测试集”包含以下几类会议录音8 段每段 15-30 分钟多人对话有重叠有远场拾音包含少量方言口音短视频音频20 段每段 15-60 秒语速快有背景音乐中英混说频繁客服通话10 段每段 3-5 分钟包含大量专业术语和产品名称朗读音频5 段标准普通话朗读作为基线对照噪声环境5 段包含键盘声、空调声、街道噪声等每段音频都做了人工精标作为 ground truth。标注规范参考了通用转写标准但针对中文场景做了一些调整比如数字统一转成阿拉伯数字、英文单词保持原样、语气词根据是否影响语义决定是否保留。提示构建测试集时一定要注意标注一致性。我一开始没注意两个人标同一段音频一个把“嗯”标进去了一个没标导致 WER 计算出来偏差很大。后来统一了规范才解决。2. 核心模型拆解与技术原理2.1 Whisper 系列开源界的标杆Whisper 是 OpenAI 开源的 ASR 模型目前有 tiny、base、small、medium、large 几个版本large 又分 v1、v2、v3。它的核心架构是 Encoder-Decoder 的 Transformer输入是 80 维的 log-Mel 频谱图输出是文本 token。Whisper 最大的优势是多语种能力强训练数据有 68 万小时覆盖 99 种语言而且中英混说的识别效果在开源模型里算是第一梯队。但 Whisper 的问题也很明显。首先是幻觉问题在静音段或者噪声段它有时候会“编”出一些原文没有的内容比如突然冒出一句“谢谢观看”或者“请订阅频道”这是因为训练数据里包含大量 YouTube 字幕模型学到了这些模式。其次是延迟large 模型在 GPU 上跑首字延迟大概在 300-500ms如果做流式识别需要配合 VAD语音活动检测做分段否则延迟会更高。另外 Whisper 不支持原生的流式推理要做实时字幕得自己搭一套 chunk-based 的推理框架。我实测下来Whisper large-v3 在会议录音上的 WER 大概是 8%-12%短视频音频上 10%-15%客服通话上因为专业术语多WER 会到 15%-20%。这个成绩不算差但也不算惊艳。2.2 Paraformer阿里系的工业级方案Paraformer 是达摩院开源的 ASR 模型主打非自回归架构推理速度比 Whisper 快很多。它的核心创新是 Predictor 模块可以并行预测所有输出 token而不是像自回归模型那样一个一个吐。这使得 Paraformer 在 CPU 上也能跑到接近实时的速度GPU 上更是快得飞起。Paraformer 的中文识别准确率很高在 AISHELL 测试集上 CER 可以到 2% 以下。但它对英文的支持相对弱一些中英混说场景下英文单词的识别错误率明显高于 Whisper。另外 Paraformer 的热词定制功能很实用你可以传入一个热词列表模型会提升这些词的识别优先级这对客服质检、医疗转写这类场景非常友好。部署方面Paraformer 有 ONNX 版本可以在没有 GPU 的机器上跑显存占用也低large 模型大概 2-3GB 显存就够了。如果你要做本地部署且预算有限Paraformer 是很务实的选择。2.3 SenseVoice多语种与情感识别SenseVoice 是 FunAudioLLM 体系下的 ASR 模型特点是多语种识别 情感识别 音频事件检测三合一。它支持中文、英文、粤语、日语、韩语等而且在情感识别上做了专门优化可以判断说话人的情绪状态中性、开心、生气、悲伤等。这个功能在客服质检场景下很有价值你可以直接拿到每通电话的情绪曲线。SenseVoice 的推理速度也很快非自回归架构延迟低。但它的中文识别准确率相比 Paraformer 稍逊一筹尤其是在专业术语上。不过它的多语种切换很自然中英混说不需要额外配置模型会自动处理。2.4 云端 API大厂方案的优劣除了开源模型我也测了几家云厂商的 ASR API。云端方案的优势是开箱即用、维护成本低、准确率通常更高因为大厂有更多的数据和算力做优化。但劣势也很明显按量计费成本高、数据隐私问题、延迟受网络影响、定制化能力有限。实测下来云端 API 在通用场景的准确率确实比开源模型高 2-5 个百分点尤其是在噪声环境和远场拾音上。但如果你有大量音频要转写成本会迅速上升。另外云端 API 通常不支持本地部署如果你的数据不能出内网那就只能选开源方案。2.5 模型选型决策树基于以上分析我整理了一个简单的选型决策树数据能否出内网不能 → 必须本地部署 → 跳到第 2 步能 → 跳到第 4 步有没有 GPU有 → Whisper large 或 Paraformer没有 → Paraformer ONNX 或 SenseVoice主要场景是什么中文为主 → Paraformer多语种 → SenseVoice 或 Whisper需要情感识别 → SenseVoice预算是多少充足 → 云端 API有限 → 开源自部署需要定制热词吗需要 → Paraformer 或云端 API不需要 → Whisper 也可以这个决策树不是绝对的但可以帮你快速缩小选择范围。3. 实操过程与核心环节实现3.1 环境准备与依赖安装先说我用的测试环境Ubuntu 22.04GPU 是 RTX 409024GB 显存CPU 是 Intel i9-13900K内存 64GB。这个配置不算低但也不是顶配有一定的参考价值。Whisper 的安装比较简单用 pip 就行pip install openai-whisper但如果你要用 faster-whisper基于 CTranslate2 的加速版本安装方式略有不同pip install faster-whisperfaster-whisper 的推理速度比原版 Whisper 快 4 倍左右显存占用也更低强烈推荐。实测 large-v3 在 faster-whisper 下RTX 4090 上转写 1 小时音频大概需要 2-3 分钟而原版 Whisper 需要 8-10 分钟。Paraformer 的安装通过 FunASR 框架pip install funasrSenseVoice 同样通过 FunASRpip install funasr pip install modelscope模型下载可以用 modelscope 的命令行工具也可以直接在代码里指定模型名称自动下载。3.2 测试脚本的编写为了公平对比我写了一个统一的测试脚本输入是音频文件路径和模型名称输出是转写文本、耗时、显存占用等指标。核心逻辑如下import time import torch from faster_whisper import WhisperModel def test_whisper(audio_path, model_sizelarge-v3): start time.time() model WhisperModel(model_size, devicecuda, compute_typefloat16) segments, info model.transcribe(audio_path, languagezh, beam_size5) text .join([seg.text for seg in segments]) elapsed time.time() - start return text, elapsedParaformer 的测试脚本from funasr import AutoModel def test_paraformer(audio_path): model AutoModel(modelparaformer-zh, model_revisionv2.0.4) start time.time() res model.generate(inputaudio_path, batch_size_s300) elapsed time.time() - start return res[0][text], elapsedSenseVoice 的测试脚本from funasr import AutoModel def test_sensevoice(audio_path): model AutoModel(modeliic/SenseVoiceSmall, trust_remote_codeTrue) start time.time() res model.generate(inputaudio_path, languageauto, use_itnTrue) elapsed time.time() - start return res[0][text], elapsed注意测试时一定要先做 warm-up也就是先跑一段短音频让模型加载到显存然后再测正式音频。否则第一次推理的时间会包含模型加载时间导致数据不准。3.3 关键参数的选择与计算ASR 模型有几个关键参数会显著影响识别效果和速度我逐个说明。Beam SizeWhisper 的 beam search 参数默认是 5。增大 beam size 会提升准确率但推理时间线性增加。我实测 beam_size5 和 beam_size10 的 WER 差距大概在 0.5%-1%但推理时间翻倍。所以除非对准确率有极致要求否则 beam_size5 就够了。VAD 阈值做流式识别时VAD 用来判断语音段的开始和结束。阈值设得太高会漏掉一些轻声细语设得太低会把噪声当成语音。我一般用 silero-vad阈值设在 0.5 左右配合 min_speech_duration250ms 和 min_silence_duration100ms效果比较平衡。Chunk Size流式识别时每次处理的音频长度。chunk 太小上下文不足准确率下降chunk 太大延迟增加。我实测下来chunk_size1s 配合 0.5s 的 overlap 是一个不错的平衡点首字延迟可以控制在 300ms 以内。热词权重Paraformer 支持热词定制可以给每个热词设置权重。权重太高会导致误召回太低又没效果。我一般设在 10-20 之间具体根据热词的重要程度调整。3.4 实测数据记录与分析以下是部分实测数据测试音频为 10 分钟会议录音包含 4 人对话有少量重叠模型WER首字延迟总耗时显存占用Whisper large-v39.2%420ms28s10GBfaster-whisper large-v39.5%380ms7s6GBParaformer-zh8.1%150ms5s3GBSenseVoiceSmall10.3%120ms4s2GB云端 API A7.5%200ms6s-从数据可以看出Paraformer 在中文会议场景下表现最好WER 最低且延迟低、显存占用小。Whisper 的准确率稍逊但 faster-whisper 的加速效果非常明显。SenseVoice 虽然 WER 稍高但延迟最低适合对实时性要求极高的场景。短视频场景的数据又不一样模型WER标点准确率中英混说准确率Whisper large-v311.5%92%88%Paraformer-zh13.2%85%76%SenseVoiceSmall12.8%88%82%云端 API A10.2%94%90%短视频场景下Whisper 和云端 API 的中英混说优势就体现出来了Paraformer 的英文识别明显拖了后腿。4. 常见问题与排查技巧实录4.1 识别结果出现重复或幻觉这是 Whisper 最常见的问题尤其是在静音段或噪声段。表现是模型反复输出同一句话或者编造出原文没有的内容。解决方法有几个开启 VAD 预处理把静音段切掉减少模型“自由发挥”的空间设置condition_on_previous_textFalse避免模型被前文带偏调整compression_ratio_threshold和logprob_threshold过滤掉低质量的输出如果还是不行换 faster-whisper它的幻觉问题比原版轻一些4.2 中英混说识别错误率高中英混说是 ASR 的老大难问题。Whisper 相对好一些但也不是完美。提升方法在 prompt 里加入中英混说的示例引导模型进入正确的模式使用支持多语种的模型比如 SenseVoice 或云端 API对英文单词做后处理用词典匹配修正明显的错误4.3 专业术语识别不准客服质检、医疗转写这类场景专业术语识别不准是致命的。解决方法使用支持热词定制的模型比如 Paraformer把术语列表传进去对识别结果做后处理用编辑距离匹配术语词典自动纠正如果数据量够可以做领域微调但成本较高4.4 延迟过高无法做实时字幕实时字幕对延迟要求很高首字延迟最好在 300ms 以内。如果延迟过高换更小的模型比如 Whisper small 或 SenseVoiceSmall使用非自回归模型比如 Paraformer优化推理框架用 ONNX Runtime 或 TensorRT 加速调整 chunk size 和 overlap找到延迟和准确率的平衡点4.5 显存不足无法加载模型如果 GPU 显存不够可以使用量化版本比如 int8 量化显存占用可以减少一半使用 CPU 推理Paraformer 的 ONNX 版本在 CPU 上也能跑换更小的模型比如 Whisper base 或 small使用模型卸载策略不用的层放到内存里提示量化会带来一定的准确率损失int8 量化大概损失 1%-2% 的 WER需要根据场景权衡。4.6 常见问题速查表问题可能原因解决方法识别结果重复幻觉开 VAD、调阈值、换 faster-whisper中英混说错误多模型多语种能力弱换 SenseVoice 或云端 API专业术语不准缺乏领域适配热词定制、后处理纠正延迟过高模型太大或框架未优化换小模型、用 ONNX/TensorRT显存不足模型太大量化、CPU 推理、换小模型标点缺失模型不支持标点恢复换支持标点的模型或后处理加标点5. 不同场景下的选型建议与实操心得5.1 会议录音转写准确率优先会议录音的特点是时长长、多人说话、有重叠、有远场拾音。这种场景下准确率是第一位的延迟可以放宽。我的建议是首选 Paraformer-zh中文准确率最高显存占用低支持热词定制如果需要说话人分离配合 pyannote-audio 做 diarization如果中英混说多考虑 Whisper large-v3 或云端 API后处理一定要做包括标点恢复、数字规范化、术语纠正实操心得会议录音一定要做 VAD 分段否则 Whisper 很容易在静音段产生幻觉。另外如果会议有明确的议程和术语提前准备热词列表识别准确率能提升 3-5 个百分点。5.2 短视频字幕延迟优先短视频字幕要求快速生成通常几分钟内就要出结果。这种场景下延迟比准确率更重要。我的建议是首选 SenseVoiceSmall延迟最低多语种支持好如果对准确率要求高用 faster-whisper large-v3标点恢复一定要开否则字幕读起来很累可以接受一定的错误率因为字幕有上下文观众能理解实操心得短视频字幕不要追求 100% 准确95% 就够了。关键是标点要对断句要合理。我一般会用 LLM 做后处理把 ASR 的输出丢给 LLM让它加标点、修正明显的错别字效果很好。5.3 客服质检领域适配优先客服质检需要识别专业术语、区分说话人、分析情绪。这种场景下领域适配能力最重要。我的建议是首选 Paraformer 热词定制把产品名称、术语都加进去如果需要情绪分析用 SenseVoice它自带情感识别说话人分离用 pyannote-audio 或云端 API 自带的 diarization后处理要做术语纠正和敏感词检测实操心得客服质检的热词列表要持续维护每周根据新的错误案例更新。我一般会统计识别错误的词频把高频错误词加入热词列表迭代几轮之后准确率会明显提升。5.4 本地部署 vs 云端 API 的取舍这个取舍的核心是数据隐私、成本、维护能力三个因素。如果数据不能出内网那只能本地部署。本地部署的初始成本高需要 GPU但长期成本低没有按量计费。维护方面本地部署需要自己处理模型更新、故障排查、性能优化有一定技术门槛。如果数据可以出内网且预算充足云端 API 是更省心的选择。准确率通常更高维护成本低弹性扩容方便。但要注意数据隐私条款以及长期使用的成本累积。我的建议是核心业务用本地部署非核心业务用云端 API。这样既能保证核心数据的安全又能享受云端 API 的便利。5.5 模型迭代与持续优化ASR 模型不是部署完就一劳永逸的。随着业务变化新的术语、新的口音、新的场景会不断出现模型需要持续优化。我的做法是建立错误案例库定期分析识别错误的模式根据错误模式更新热词列表、调整后处理规则每季度重新评测一次看是否有新的模型或版本值得升级如果数据量够考虑领域微调但要做好数据标注和验证这个内容后续还可以这样扩展把 ASR 和 LLM 结合起来做端到端的语音理解不只是转写文字而是直接输出结构化的会议纪要、客服质检报告。这个方向目前已经很成熟了我下个项目就打算这么干。