企业官网建设流程全解析

最近身边好几个项目都在上语音输入，会议纪要自动转写、短视频字幕生成、语音对话助手，随便哪个都绕不开ASR模型。我也是在近半年的几个真实落地项目里，把OpenAI Whisper、faster-whisper、阿里的FunASR（Paraformer）、SenseVoice，以及讯飞的云端语音识别API挨个试了一遍，顺手做了一次系统的横向评测，才敢说对“哪个模型最好用”这件事稍微有点发言权。坦率讲，网上那些跑分排行榜只能当参考，真到实际场景里，模型好不好用取决于你的音频质量、业务术语、部署环境和后处理管道设计。这篇文章就当作我自己的选型复盘，把评测方法、实测数据、参数调优和踩过的坑都写出来，给正在做语音输入选型的同行当一个参照。

1. 选模型前先想清楚的四件事

1.1 先分清是“听写”还是“转写”

语音输入听起来是一个需求，但“听写”和“转写”根本是两种产品形态。听写是边说边出字，用户正在说话，系统要实时返回识别结果，还要支持打断、重说、热词纠错，比如手机输入法里的语音输入；转写则是拿到一整段音频后离线处理，比如会议录音整理、播客字幕，用户不盯着屏幕，延迟不是问题，准确率和格式才是核心。这两种形态对ASR模型的要求完全不同：听写更看重首字时延和实时吞吐，转写更看重识别精度和长音频稳定性。

我一开始图省事，直接用非流式Whisper做语音输入，用户体验非常糟糕，一句话必须说完才出结果，中间还不能打断。后来改成“按键结束+整句识别”的伪实时方案，才勉强能看。如果你要做的是语音笔记、语音助手这类强交互产品，建议直接考察流式ASR是否有低延迟方案；如果是批量转写，Whisper这类大模型才是值得投入的方向。先把这个定位搞清楚，后面所有选型才不会跑偏。

1.2 中文、多语言、中英混合是三条完全不同的赛道

评价ASR模型，先看你的音频语种构成。纯中文场景里，中文专精模型通常比通用的多语言模型更稳；多语言场景里，Whisper有天然优势；而最麻烦的是中英混读，业务会议里经常出现“把issue同步到Jira上”“这个bug assign给老王”“我们周四开个workshop”，模型一旦把英文单词吞掉或音译成中文，用户立刻就会觉得“这玩意儿不行”。我在评测里专门加了一批中英混读样本，结果差距非常明显，后面会详细说。

另一个容易踩坑的点是方言。粤语、四川话、带地方口音的普通话，在标准普通话语料上训练出来的模型往往表现一般，除非你的业务明确覆盖方言人群，否则别指望一个模型通吃所有口音。选型前先花一天时间把你的真实业务音频听一遍，判断语种构成和口音复杂度，这个步骤比研究模型榜单重要得多。

1.3 准确率、速度、资源占用不可兼得

做语音输入，实时性通常是硬指标。ASR领域用RTF（实时率）衡量速度，RTF等于处理音频耗时除以音频时长，小于1说明比说话更快，小于0.5在听写场景中才会比较跟手。大模型的准确率通常更高，但推理开销也大：Whisper large-v3在纯CPU环境下的RTF经常大于2，也就是1秒音频要处理2秒以上，根本没法做实时语音输入；上GPU之后RTF能降到0.1左右的水平，但又引入了显存成本和并发瓶颈。

小模型比如SenseVoice，速度极快，但在某些复杂中文句子上的准确率不如大模型。挑模型本质是在“准确率、速度、资源”三者之间做权衡，没有绝对最优解，只有适合你当前场景的解。我见过不少团队为了追求最高精度而上了大模型，结果显卡成本翻了几倍，处理长音频时还频繁超时，最后不得不退回去用小模型，这就是一开始没把约束条件想清楚。

1.4 本地部署开源自建，还是直接用云API

这个决策直接影响成本和可控性。云厂商的语音识别API（讯飞、阿里云、腾讯云等）胜在省事，并发扩容不需要你操心，通常还内置了热词、方言优化，但按量付费在持续高并发场景下很贵，而且音频数据要送到云端处理，很多企业客户对数据落库和合规有要求，这个坎过不去项目就直接别想。

本地部署开源模型（Whisper、FunASR、SenseVoice）需要一次性投入GPU或高性能服务器成本，之后调优、扩容、数据安全都掌控在自己手里，尤其适合音频量大、数据敏感或者完全离线的场景。我的建议很简单：Demo和短期项目先用API快速验证业务，别一上来就自建机房；有长期规划且数据敏感的项目，尽早投入本地部署，否则后面迁移模型、迁移数据都是大工程。

2. 本次横评：候选模型与评测环境

2.1 候选模型清单与选择理由

这次评测我锁定了四个本地开源模型加一个云API，选型逻辑是：既要看行业热度最高的方案，也要看中文场景里真正能落地的方案，不能光盯着一个Whisper打天下。

Paraformer-large和SenseVoice-Small都出自FunASR社区，但定位差异很大。Paraformer是传统中文识别的大模型，稳扎稳打，中文效果扎实；SenseVoice是新一代多语言语音大模型，走的是快和全的路线，两者互补性很强。选它们进评测，可以覆盖“中文精度”和“多语言速度”两个完全不同方向的对比。

2.2 评测环境与测试集构成

硬件环境我统一用一台i9-12900K、32GB内存、RTX 3060 12G显卡的机器；软件方面用Python 3.10，faster-whisper用1.0版本，FunASR和SenseVoice用1.0版本，讯飞API走官方SDK。所有深度参数都记录成脚本，保证每次测评可以复现。

测试集没有用公开比赛那些规整的语音库，而是从真实业务里攒了约2小时的音频，分成五类：室内会议录音（多人普通话）、电话客服录音（带一定底噪）、短视频口播（语速快、口语化）、中英混读访谈、粤语和四川话口音样本。每一类都单独统计结果，不看总分，因为总分最容易掩盖某个场景的巨大差距。评测指标我用三个：CER字符错误率衡量准确率，RTF衡量速度，首字时延衡量流式场景的体验。CER按字算编辑距离，类似打字时错字率；RTF前面解释过；首字时延就是用户开口到屏幕上出现第一个字的时间差。

3. 横评结果：各模型的实际表现

3.1 中文普通话：中文专用模型的稳，大模型的“灵”

在纯中文的会议录音和短视频口播测试里，FunASR/Paraformer-large的表现最稳，字错率最低，尤其对口语化重复、语气词、倒装句能忠实还原原话，适合做会议纪要这种要求“说什么记什么”的场景。Whisper在中文上也很能打，不过它的风格倾向“理解后转写”，会把“然后呢就是说这个事吧”整理成逻辑更顺的表达，摘掉冗余词。这在做内容编辑时是优点，但需要完整留痕的会议纪要里反而可能丢信息。

举一个实测例子，有段演讲原话是“我们当时其实已经跟对方对接过一轮了，然后就是说这个排期吧，可能得往后稍微挪一下”。Whisper给出的是“我们其实已经跟对方对接过一轮了，这个排期可能需要往后挪一下”，干净但不算全记录；Paraformer则基本逐字保留，包括“然后就是说”这种口头衔接。别小看这个差异，产品需求是“逐字速记”还是“自动润色”，直接决定选哪个。

3.2 中英混读与英文：Whisper的底力最强

中英混读是这次评测中差距最大的场景。测试样本里有大量“把issue列表同步到Jira上，assign给老王”“这个API文档要review一下”之类的句子。Whisper对英文单词的还原最完整，能正确保留issue、Jira、assign、review的大小写和原形，基本不会音译；SenseVoice在英文上也不错，多数时候能保留原文，偶尔会吞掉弱读的动词；Paraformer对中文句子里的英文单词处理最弱，有几条样本把assign识别成“爱赛”，把API识别成“诶批诶”。如果你的业务里英文术语多，这个维度一定要实测，光看中文榜单根本看不出来。

单看纯英文识别，Whisper的标点、大小写、连读处理比其他几个都好，SenseVoice胜在速度，Paraformer在英文场景不太值得推荐。如果你做字幕工具或者跨境业务录音，把Whisper作为主力是大概率不会错的选择。

3.3 数字、标点与格式：最容易被忽视的隐性差距

准确率不是ASR的全部，输出格式往往决定能不能直接进下游。数字场景最典型：做客服质检的人关心“三零零一”该转成3001还是“三零零一”，财务场景关心“三万五”要不要变成35000，时间场景关心“七点半”是“7:30”还是“七点半”。Whisper默认会输出阿拉伯数字和英文标点，SenseVoice可以通过ITN（反向文本正则化）把口语数字转换为书面格式，FunASR的标点通常要搭配单独的标点恢复模型使用，不然结果是一串完全没有逗号句号的文字流。

我的建议是，数字和格式要求高的业务不要在ASR层硬磕，先看模型输出能不能接后处理，比如统一做一轮数字正则替换；同时用initial_prompt或热词机制，把高频专有名词、单位写法喂给模型，效果往往立竿见影。不少团队把准确率从95%压到96%花了大力气，结果因为数字格式不对导致下游系统无法入库，这种问题其实用提示词就能缓解大半。

3.4 速度与资源占用：SenseVoice是CPU场景的无冕之王

把速度数据放到一起看，差异非常直观。表格里是实测得到的近似区间，具体数值会受音频长度、线程数、GPU型号影响，但相对关系是稳定的。

云API的RTF不固定，受网络和并发影响，实测首字时延一般落在200-500毫秒之间，不能直接和本地RTF对比。这些数据说明一个很现实的问题：如果你的服务器只有CPU没有GPU，想上Whisper做实时语音输入基本不现实，SenseVoice和Paraformer才是靠谱选择。我自己在CPU服务器上用SenseVoice做批量转写，2小时的音频大概15分钟跑完，体感非常好。

3.5 流式场景：实时语音输入优先考虑专用流式方案

语音输入里，如果用户是“边说边看”的，流式识别能力就很关键。Whisper本身不支持真正的流式识别，虽然可以通过滑动窗口把音频切成一小段一小段模拟，但会出现句首丢字、重复识别、跨句拼接不连贯的毛病，工程上非常难处理。真做实时交互，要么用FunASR的流式版本，要么直接接云厂商流式API。

再说一个不算考察点但很实用的经验：如果你受限于架构不得不拿Whisper做实时方案，可以用VAD检测句子边界，把上一句末尾的几个字作为下一句的prefix传进去，这样可以明显减少断句处丢字。这个技巧本质上就是“滑动窗口+上下文拼接”，实现不复杂，但能救不少场景。实测下来，配合VAD的滑动窗口方案虽然比不上原生流式模型，但已经能让用户感受“说完一句马上出结果”的基本可用体验。

4. 工程化落地：参数、管道与Java调用

4.1 Whisper参数调优的关键点

Whisper在开源模型里效果最好，但默认参数很多时候不是最优解。第一个关键是language参数。Whisper会自动检测语言，这个检测本身会消耗时间，还可能在短音频上判断错误。中文场景明确传language="zh"，能显著提速，也能减少语言误判。

第二个关键是initial_prompt提示词。它可以告诉模型输出风格，比如“以下是普通话会议记录，其中的英文专有名词请保留英文原文，数字使用阿拉伯数字”。设好提示词，识别风格会立刻不一样。第二个关键是beam_size，一般设在5到8就够，再大收益有限，速度却会掉很多。condition_on_previous_text在长音频下容易造成前后文重复，建议在处理长段音频时关掉它，或者配合VAD分好段再做识别。VAD过滤静音则是速度和质量双重收益的关键，faster-whisper直接集成了Silero VAD，开启后空白语音不再强行解码，速度能提升不少。

4.2 faster-whisper加速配置

给自己的基础配置一个示例，直接可用：

from faster_whisper import WhisperModel model = WhisperModel( "large-v3", device="cuda", compute_type="int8_float16", ) segments, info = model.transcribe( "demo.wav", language="zh", beam_size=5, vad_filter=True, vad_parameters={"min_silence_duration_ms": 500}, ) for segment in segments: print(segment.text)

compute_type是加速的关键。GPU上用int8_float16能把显存占用砍掉明显一部分，精度损失很小；纯CPU上用int8，速度比fp32快好几倍。vad_parameters里的min_silence_duration_ms控制切分粒度，数值太小会导致句子被切碎，太大又迟迟不切段，具体值需要根据你音频里的语速微调，我一般从300-500毫秒起步。动手调这些参数时有个心得：不要同时调多个变量，一次只改一个，用同一段音频对比效果，否则你根本不知道是哪个参数带来的变化。

4.3 FunASR的VAD+Punc组合流程

FunASR的价值不只在Paraformer模型本身，而在于它把VAD、ASR、标点恢复做成了可组合的完整链路。实际处理长音频时，建议同时加载三个子模型：

from funasr import AutoModel model = AutoModel( model="paraformer-zh", vad_model="fsmn-vad", punc_model="ct-punc", ) res = model.generate( input="demo.wav", batch_size_s=60, ) for line in res: print(line["text"])

batch_size_s表示按音频时长分批送给模型，防止长音频一次吃太多显存。VAD先找出说话片段，让识别模型只处理有效语音；标点模型单独做格式恢复，避免识别任务和标点任务互相干扰。这种三段式设计很适合生产管道，哪个环节出问题就单独换哪个。比如你觉得标点恢复太慢，可以把punc_model换成轻量的小模型；如果你发现某个样本VAD切得太碎，就单独调VAD阈值，完全不影响识别模型。

4.4 SenseVoice的快速使用与能力边界

SenseVoice的调用比Whisper还简单，官方FunASR里直接支持：

from funasr import AutoModel model = AutoModel(model="iic/SenseVoiceSmall") res = model.generate( input="demo.wav", language="zh", use_itn=True, ) print(res[0]["text"])

use_itn=True会自动把口语化的数字转成书面格式，这个开关对很多场景是刚需。SenseVoice还自带情感标签和音频事件检测，能标出笑声、掌声、音乐这些背景事件，做视频内容分析会很好用。它的边界也很清楚：目前不适合流式场景，长音频需要配合VAD切段使用；中文方言的覆盖不如中文专用模型精细，遇到强烈口音时还是Whisper或Paraformer更稳。所以SenseVoice最适合的场景是CPU资源受限下的批量转写，而不是所有场景通吃。

4.5 SpringBoot调用ASR模型：封装REST接口的完整思路

不少后端团队是Java技术栈，这里给出一套可以直接抄的标准做法。核心思路是：本地模型用Python起一个推理服务，统一走HTTP暴露，Java那边把音频文件POST过去拿文本结果。模型常驻内存，避免每个请求重复加载。

Python侧用FastAPI包一层：

from fastapi import FastAPI, UploadFile from faster_whisper import WhisperModel app = FastAPI() model = WhisperModel("large-v3", device="cuda", compute_type="int8_float16") @app.post("/asr") async def asr(file: UploadFile, language: str = "zh"): tmp_path = f"/tmp/{file.filename}" with open(tmp_path, "wb") as f: f.write(await file.read()) segments, _ = model.transcribe(tmp_path, language=language, vad_filter=True) text = "".join(s.text for s in segments) return {"text": text}

Java侧用RestTemplate做文件上传：

HttpHeaders headers = new HttpHeaders(); headers.setContentType(MediaType.MULTIPART_FORM_DATA); LinkedMultiValueMap<String, Object> body = new LinkedMultiValueMap<>(); body.add("file", new FileSystemResource("/path/test.wav")); HttpEntity<LinkedMultiValueMap<String, Object>> request = new HttpEntity<>(body, headers); String json = restTemplate.postForObject("http://127.0.0.1:8000/asr", request, String.class);

工程上几个坑提醒一下：音频格式最好统一转成16kHz单声道WAV或PCM，避免模型对采样率敏感导致效果下降；Java客户端要给HTTP请求设置合理的读取超时，长音频识别可能耗时几十秒；如果要支持实时语音输入，建议升级为WebSocket或gRPC流式传输，HTTP传文件只适合短音频。一个额外的小技巧：用OpenAI兼容的/audio/transcriptions接口格式来封装自己的服务，好处是以后换别的Whisper兼容服务，Java代码可以一行都不用改。

5. 常见问题与排查实录

5.1 中文识别结果全是繁体或带英文

Whisper在中文场景默认常常输出繁体字，或者夹杂英文单词。原因有两方面：一是自动语言检测在短音频和带噪音频上容易误判，二是模型的默认输出风格未必符合简体中文场景。解决办法是显式传language="zh"，并在initial_prompt里写清楚“请使用简体中文输出，专有名词保留英文原文”。如果生产环境有存量文本需要批量修正，可以在后端加一遍简繁转换，比如用OpenCC库，逐条规则替换效率很低，不推荐。

5.2 数字、金额、日期识别错误

ASR模型听到的是语音，不负责语义理解，“三五零”到底应该是350、三五〇还是三五年，模型容易猜。处理这类问题最好双管齐下：一是用支持ITN的模型，SenseVoice的use_itn=True、云API自带的文本格式化，都能把数字转为规范写法；二是定义热词或提示词，把业务里的高频词写进去，例如“金额使用阿拉伯数字”“日期格式YYYY年MM月DD日”。后处理层建议再加一道数字正则替换，把常见的“千”“万”“点”等口语表达做一轮兜底转换。我在财务语音录入场景里就是这样三层防护，错误率才能压到业务可接受的范围。

5.3 长音频导致显存溢出、速度越来越慢

这个问题基本出现在Whisper系模型处理超过一小时的音频时。我建议的流程是：先做VAD把整段音频切成人耳可断句的小片段，分段送进模型识别，再按时间戳顺序拼接。faster-whisper的vad_filter就是干这个的，但VAD参数要调：min_silence_duration_ms设置过大会把两句话黏在一起，过小则会把一句话拦腰截断。如果显存还是不够，先把音频降采样到16k，再把compute_type降到int8，能省不少显存；实在不行就换medium尺寸，用部分精度换取稳定运行。

5.4 环境嘈杂，识别率骤降

ASR不是降噪器，前端音频质量决定了识别率天花板。嘈杂环境下，模型在推理层面再强也很难完全弥补。工程上可以采用这几种手段：采集端用WebRTC的降噪算法做预处理，实测能改善不少；麦克风阵列的波束成形可以在硬件层把目标声源方向的声音放大；对电话录音这类固定噪声场景，可以在测试集里混合环境噪声做充分测试。我在测试电话客服录音时发现，即使模型相同，前置降噪的开关会让CER差好几个点。所以遇到识别率骤降，先查音频链路，别急着换大模型。

5.5 GPU服务并发低、请求排队

语音识别是计算密集型推理，单个GPU通常无法同时处理大量请求，并发高了之后延迟会迅速恶化。方案无非几条：模型常驻进程，用队列削峰，禁止每个请求重新加载模型；多卡或者多副本部署，前面加负载均衡；小模型部署多实例比大模型单实例更容易扩展，这也是SenseVoice在生产上受欢迎的原因之一。如果高峰流量只在特定时段出现，用容器弹性伸缩也能省钱。核心是要提前压测出单实例的吞吐上限，别上线之后才发现扛不住，这样的翻车教训我看到太多了。

6. 不同场景的选型建议

6.1 场景速查表与选型顺序

用我实测的结果整理一个速查表，方便直接对照：

选型顺序我建议这样走：先明确核心场景是听写还是转写，再确认语种构成和数据合规边界，然后做一轮候选模型的小规模盲测，最后按速度和成本约束倒推部署方案。评测数据只能作为起点，真正交付前一定要拿业务音频做回归测试，防止模型在你没注意到的细分类别上翻车。

6.2 我个人的选型心得

踩过几次坑之后，我现在的习惯是：不管评测数据多好看，一定先把自己业务里最有代表性的十段音频拿出来，让候选模型逐个跑一遍，肉眼看转写结果。跑分只能筛掉明显不行的，真正决定成败的是那些“看起来还行但细节不对”的样本，比如英文专有名词丢了、口语语气词被删掉、数字格式完全不能入库。这些细节问题，只有贴近业务的评测才能暴露。

另一个心得是不要把所有期望都压在ASR模型本身上。语音输入的用户体验是采集端、端点检测、ASR模型、后处理脚本共同决定的，ASR只是中间一环。把前端的降噪和端点检测做好，哪怕模型不是跑分最高的那个，用户体感也能好一大截。我见过不少项目团队一上来就追求大模型高精度，忽略了WebRTC降噪和静音检测，结果用户反馈识别不稳，最后问题其实出在音频采集端。ASR选型很重要，但它只是整个管道中的一节，把整条链路做扎实，才是语音输入产品好用的根本。