做过中文语音转写的朋友大概都经历过：第一反应装 Whisper，跑完一看，会议录音错得让人想砸键盘。这篇文章把我这两年折腾中文 ASR 的选型思路摊开讲，结论先放这儿： 中文生产环境，别把 Whisper 当默认选项。

很多团队做中文语音识别，第一反应就是 Whisper。它名气大、文档全、英文确实能打，这个印象没毛病。但把 Whisper 直接搬进中文生产环境，大概率是要踩坑的。一个直观的对照：在公开评测集 WenetSpeech 的会议场景里，Whisper-large-v3 的字错误率（CER）是 18.87%，而专注中文的模型能压到 5% 以内，差了快 4 倍。这不是谁算法差，是训练数据的语言分布根本不一样。中文常用字就三千多、同音字密、方言口音杂、中英混说又是常态，通用多语种模型在这些地方会全面失准。

下面这份选型，是我把市面上主要的中文 ASR 方案、私有化部署路径和真实成本都摊开之后给出的判断。先交代结论：中文场景，我更推荐 FunASR 这套生态；但如果你的精度要求变态高、显存管够，今年有了新选择。

一、先把结论摆在这：中文场景，Whisper 不是默认答案

衡量中文 ASR，业内看的是字错误率 CER，越低越好。下面这张表来自各模型官方公布的数据，测试集是 AISHELL-1、AISHELL-2 和 WenetSpeech 的 Network、Meeting 四个公开场景的平均值（WenetSpeech 是 WeNet 团队 2021 年发布的中文评测集，一万多小时，覆盖网络音频和真实会议，目前国内基本都拿它当标尺）：

模型	参数量	平均 CER	一句话点评
FireRedASR-LLM（小红书）	8.3B	3.05%	2025 年的中文精度天花板
FireRedASR-AED（小红书）	1.1B	3.18%	精度高，但单条音频限 60 秒
Seed-ASR（字节）	12B+	3.33%	闭源，只有火山引擎 API
SenseVoice-Large（阿里）	1.6B	4.47%	FunASR 家族，CPU 能跑
Paraformer-Large（阿里）	0.2B	4.56%	最轻量，带字级时间戳
Whisper-large-v3（OpenAI）	1.6B	9.86%	中文平均接近 10%，会议场景 18.87%

数据摆在这，结论不难下：同样是开源模型，专注中文的比 Whisper 平均能低 5 到 6 个点，会议这种难场景差距更大。Whisper 不是不能用，是用错了地方，它是"100 多种语言都能凑合"的瑞士军刀，不是"中文要转得准"的专项工具。这个差距不是口头说说的，公开测试集和模型权重都在那儿，谁都可以拿同一批音频自己复测一遍。也是从这开始，我后面所有判断都建立在一个前提下：先搞清楚你的语音长什么样，再谈选哪个模型。

二、2026 年的牌桌上，中文 ASR 到底有谁

这半年中文 ASR 变化特别快，光开源这边就有好几张新牌。我把主流选手过一遍，每个后面都附上我的真实看法：哪些我会拿来用，哪些我只看看热闹，说明白话。

FunASR 家族（阿里达摩院/通义实验室）：工具链 + 模型全家桶，MIT 等宽松协议开源，是目前生态最完整的。主力模型三个：Fun-ASR-Nano（800M，SenseVoice 编码器接 Qwen3-0.6B 解码器，中英日 + 7 种方言 + 26 种口音，官方给的中文 CER 8.06%，vLLM 加速下约 340 倍实时）；SenseVoice（234M，非自回归，一遍前向同时给出转写、语种、情感、音频事件标签，GPU 上约 170 倍实时、CPU 上约 17 倍，q8 量化后 250MB 左右）；Paraformer（220M，最轻，字级时间戳 + 热词定制）。2026 年 6 月官方还放出了 llama.cpp/GGUF 运行时，CPU 和边缘设备上跑成单个可执行文件，基本等于给 Whisper.cpp 的中文替代。这家我基本当"默认基建"用：中文为主的场景从这套起步，几乎不会选错。倒不是它每一项都最强，而是你后面要接的 VAD、标点、说话人分离它都给你备好了，不用自己东拼西凑。

FireRedASR 和它的第二代（小红书）：2025 年 2 月开源的 FireRedASR 是当时开源中文 SOTA，LLM 版（8.3B，基于 Qwen2-7B）和 AED 版（1.1B）。今年 2 月小红书又放出了 FireRedASR2S。这次不是单个模型，是 ASR、VAD、语种识别、标点预测四个模块打包的一整套系统，Apache-2.0 协议，官方口径是在 24 个公开测试集上全面超过豆包、Qwen3-ASR 等对手，普通话平均 CER 2.89%。小红书自己的语音评论、语音搜索就是跑在它上面。我的看法是：精度这块它确实是当前开源中文的第一梯队，但 LLM 版单卡 32GB 起步才稳、AED 版单条音频限 60 秒，这两个门槛直接把大多数团队劝退。我给它的定位是"精度信仰者专用"，正常业务团队先别急着上。

Qwen3-ASR（阿里通义）：2026 年 1 月底开源，1.7B 和 0.6B 两个尺寸。官方口径是支持 30 种语言 + 22 种中文方言/口音（合计 52 个语种与方言），Apache-2.0，流式/离线一套模型全搞定，0.6B 在 128 并发下能做到 2000 倍实时吞吐。方言识别是它的强项，官方给的数据是比豆包方言错误率再降约 20%。方言和中英混说这块是我最看重它的点，真实世界的语音从来不是标准普通话，我选型时只要业务里方言占比高，就会把它拉进候选清单，消费级显卡就能跑这一点也是加分项。

GLM-ASR-Nano（智谱）：2025 年 12 月开源的 1.5B 模型，Apache-2.0。它不是冲着"全面最强"去的，两个点很特别：一是对方言做了专项优化（官方口径支持普通话、英语和 8 种官话方言口音），二是专门训练了低音量语音，开会时离麦远的人、电话录音里声音弱的一方，传统模型直接忽略的音频它能捞回来。低音量这个点我在电话质检场景里特别惦记，录音里声音弱的那一方往往是关键信息。不过它的社区生态还年轻，坑要靠自己趟，这点要有心理准备。

Seed-ASR / 豆包语音（字节）：只有 API，没有开源权重。平均 CER 3.33%（FireRedASR 官方对比表数据），2025 年 12 月出了 2.0 版本，上下文关键词召回提升 20%，还加了多模态视觉输入，支持 13 种海外语种。我的取舍很明确：数据不出内网是硬约束的话，这类 API 直接出局；反过来，只要合规允许、又不想养 GPU，它就是最省事的选项。"抖音剪映飞书同款"这个背书听着唬人，但对技术选型没什么实际参考价值，别被它带偏。

国际牌桌上顺带说一句：NVIDIA 的 Parakeet 系列英文很强（0.6B 就在 OpenASR 上登过顶，速度比 Whisper 快一个量级），但基本不支持中文，我的习惯是中文项目直接跳过；Whisper 生态（faster-whisper、whisper.cpp）胜在文档多、能翻译、语言覆盖广，我留在角落里当多语种兜底；k2-fsa 的 sherpa-onnx 是个纯 ONNX 的部署框架，跨平台、完全离线、体积小，嵌入式场景很实用，这个我后面部署部分还会提。

三、我为什么把 FunASR 放在第一位

说白了，我看中的不是单个分数，而是它把"能不能真正用起来"这件事想得最透。这个判断我保持到今年：论单点精度，FireRedASR2 更狠；论综合落地，FunASR 还是最省心的那套。

旗舰 Fun-ASR-Nano：SenseVoice 编码器接 Qwen3-0.6B 解码器，LLM 解码器带来的是语义理解能力，对专有名词、同音消歧、上下文依赖特别有用。比如"期中考试"和"期终考试"读音一样，纯声学模型经常搞混，LLM 能结合上下文判对。显存占用不大，社区有 3090 上推理时不到 4GB 的实测记录，12GB 的 3060 单路能跑，这个数字我记着当经验值，选卡的时候照着划预算；想并发高一点，4090 起步比较从容。有个坑得提前说：官方说明 Fun-ASR-Nano 的 checkpoint 不提供可靠的原生字级时间戳，要逐字对齐就选 Paraformer，别在 Nano 上硬等。这条官方文档里写得不算显眼，做字幕对齐的朋友选型时建议直接当成硬约束，省得后面返工。

CPU 双子星：没有 GPU 的团队不用慌。SenseVoice 非自回归，一遍前向出所有标签，CPU 上约 17 倍实时，q8 量化才 250MB，树莓派都能跑；Paraformer 更轻，字级时间戳 + 热词定制，做字幕、做逐字对齐就靠它。这两个都是 2026 年官方选型指南里明确写着"CPU 首选"的。

真正值钱的是那层辅助模型：光有识别模型不够。FSMN-VAD 负责把语音精准切分，CT-PUNC 给无标点文本补标点（中英双语，流式场景延迟也低），再叠上说话人分离（CAM++）和 ITN 文本规整，才是一条能用的完整管线。FunASR 把这些打包好了，部署通道从 Python SDK、vLLM、Docker、llama.cpp/GGUF、ONNX Runtime 一直到 OpenAI 兼容 API 全都有。这种"开箱即用的整套方案"，是它区别于单个开源模型的根本。

四、选完模型才是开始：生产环境那点事

选模型只是第一步，落地才是分水岭。这半年我自己在部署和跟社区反馈的过程中，有三件事最值得说。

第一件：离线批处理和实时流式，是两套路子。 录音文件转写（会议纪要就是典型）走离线批处理，吞吐优先；实时字幕、客服对话要在几百毫秒内出结果，得走流式。FunASR 的流式常用"双引擎"打法：先用 paraformer-online 每 600ms 推一次实时结果撑住体验，VAD 检测到尾点后再用离线模型加标点模型做精修终稿。首字延迟控制在几百毫秒量级，这个体验对实时场景是决定性的。Qwen3-ASR 和 FireRedASR2S 的流式则是单模型搞定，官方都宣称流式/离线一体化，选型时可以按这个能力点去对比。

第二件：量化与加速，决定成本和并发。 生产环境我建议优先上 vLLM 或 Triton 做动态批处理，再把 FP16 打开，比 INT8 省心，精度损失极小。模型导出 ONNX 后用 ONNX Runtime，纯 CPU 也能跑得很稳。量化能把显存压下一大截，代价只是零点几个点的 CER，对绝大多数业务完全可接受。一个能说明问题的官方基准：SenseVoice-Small 在 GPU 上约 170 倍实时、CPU 上约 17 倍；Paraformer-Large 约 120 倍 / 15 倍；Whisper-large-v3 在 GPU 上才 13 倍。也就是说，FunASR 在 CPU 上的速度，比 Whisper 在 GPU 上还快。我第一次看到也觉得夸张，照着官方基准复刻一遍，基本成立。

工程上还有几件能直接抄的作业：音频统一重采样到 16kHz，能省掉不少无效计算；Triton 配动态批处理再加首条请求预热（喂几个空音频块），能把冷启动从秒级压到 300ms 内；生产环境务必挂队列监控和弹性扩缩，否则高并发下实时率会塌。这些细节里，冷启动是我觉得最容易被忽略的一个，很多人上线前压测才发现秒级延迟全耗在这，预热一加立刻改观。单个细节都看不起眼，叠起来决定你这套服务是稳还是天天救火。

第三件：离线部署有两个真坑。 一个是社区反复反馈过的：FunASR/SenseVoice 内嵌了 ModelScope SDK，即使模型已经缓存到本地，启动时仍会尝试连 modelscope.cn 做校验，纯内网环境会卡住。绕法是显式传本地路径并关掉 update 检查，或者干脆用 sherpa-onnx / llama.cpp GGUF 这类不带网络请求的运行时。2026 年 6 月官方出的 llama.cpp 运行时就是干这个的，单二进制、内置 VAD、无 Python 依赖，q8 量化模型体积减半精度基本不掉。另一个坑是长音频输入上限：FireRedASR-AED 限 60 秒，FireRedASR2-LLM 限 30 秒，GLM-ASR 对超长音频也建议先 VAD 切分，这类模型不能直接喂一小时的会议录音，必须先切。

最后说一个很多人栽过的跟头：怎么判断一个模型适不适合你的业务。 官方公布的 CER 是在 AISHELL、WenetSpeech 这类通用集上测的，跟你的真实音频大概率不是一回事。我自己做选型时的做法是三步：先拿业务里最典型的几十条音频建一个私有评测集，噪声大的、方言重的、专有名词多的都要有；再固定跑分脚本，把 CER、实时率、首字延迟一次性打出来；最后同一批音频在候选模型间 A/B，谁好谁上。这套流程花不了半天，但能避免上线三个月才发现模型扛不住自己场景的尴尬。我见过的翻车案例，多数不是模型选错了，是根本没建评测集就上线了。

五、几个真实场景过一遍，坑都不一样

模型选定了，落地方式还是千差万别。场景不同，坑到底差在哪？先说我自己的排序逻辑：第一问数据能不能出内网，这直接决定 API 还是自建；第二问实时性要求，这决定流式还是离线；最后才轮到精度。顺序反了，后面全是返工。下面这几个是我观察到的常见样子：

• 电话客服 / 呼叫中心：核心是实时流式加高并发。重点看首字延迟和单节点并发路数，配合 VAD 切断静音段省成本，热词注入把"工单""退订"这类业务词命中率拉起来。需要情绪标注的，SenseVoice 自带情感标签，或者叠一层云厂商的情绪识别增值。低音量录音识别差的，GLM-ASR 这类专项优化的模型值得测。
• 会议转写：离线批处理为主，但真正的难点是说话人分离和结构化。谁说了什么、待办归谁，比单纯转准几个字价值高得多。FunASR 用 VAD + CAM++ 做说话人分离，sherpa-onnx 生态里还有 3D-Speaker、ECAPA-TDNN 这类声纹方案可以接。转完再让 LLM 做一轮摘要和待办抽取，是现在会议产品的主流做法。
• 医疗 / 法律这类垂直领域：术语错一个字都可能出事，必须上热词和领域词表；而且数据不出内网是硬性要求，私有化部署基本没得商量。这一档优先考虑 FunASR 全家桶或 FireRedASR2S 这类可本地跑的整套系统。
• 车载 / 嵌入式：通常没 GPU，只能跑 CPU 或端侧。SenseVoice q8（250MB）、llama.cpp GGUF 单二进制、sherpa-onnx 的 ONNX 模型都行，后者还支持 RK NPU、昇腾、高通 QNN 这类移动端加速，实时性和功耗是首要约束。
• 字幕 / 直播：要字级时间戳和对齐，Paraformer 的时间戳能力在这用得上；FireRedASR2-AED 也带字级时间戳加置信度。注意流式终稿的对齐稳定性，别让字幕块错位；导出 SRT/VTT 现在 FunASR 命令行直接支持。
• 音视频平台 / 媒资库：量大、非实时，走容器化批量离线最合适。队列 + 动态批处理 + 弹性扩缩，把吞吐顶上去，单机实时率跑个几十上百倍很正常，成本摊下来很低。

场景过完，还有四件上生产前必须做扎实的事，这里一并说了。

一是热词与自学习。 业务专名（品牌、产品、人名）不进词表，再好的基线也会栽在术语上。FunASR 的 Paraformer 原生支持热词定制，Fun-ASR-Nano 引入 RAG 机制后热词上限能到一万条量级；云厂商侧，火山和腾讯都有热词 API，阿里百炼也有自学习平台，把高频误识词喂进去，几天内能明显改善。

二是监控三件套。 实时率（RTF）、首字延迟、CER 漂移这三个指标必须长期盯着。RTF 掉过 1 说明处理不过来，首字延迟决定实时场景体验，CER 漂移要定期拿固定回测集跑一遍，防止模型更新或数据分布变化后悄悄劣化。我自己维护服务的习惯是给这三项各挂一个告警，超过阈值自动通知。

三是高可用与容灾。 ASR 服务挂了业务直接停摆，多副本、健康检查、自动拉起是底线；大厂一般还做双机房切换，中小团队至少做到进程崩溃自动重启、切流有预案。模型文件也要有版本管理，回滚是常态动作不是应急动作。

四是微调的边界。 Fun-ASR-Nano 和 FireRedASR2 都支持 LoRA 微调，但我的建议是先用热词和评测把问题定位清楚，确认是模型能力问题再动微调。微调需要数据标注和训练流水线，成本不低，多数团队其实走不到那一步。这句话我在不同场合反复说：先热词，再评测，最后才微调。

六、成本账：API 还是自建，边界在哪

语音识别的成本，往往不在模型本身，在推理资源和计费陷阱。我按各厂商官方定价页（2026 年 7、8 月口径）拉了一张表，价格波动快，签合同前以官网为准：

方案	形态	参考价	备注
阿里百炼 Paraformer	API 按量	0.288 元/小时	批量转写的地板价
阿里百炼 Qwen3-ASR-Flash	API 按量	约 1.1 元/小时	实时流式、方言
火山豆包录音文件识别	API 资源包	约 1 元/小时	新客特惠更低
火山豆包流式识别	API 资源包	约 2 元/小时	实时场景
腾讯云录音文件识别（大模型版）	API 资源包	约 0.8 元/小时	标准版 1.0~1.5 元
讯飞语音转写	API 套餐	4.9~9.9 元/小时	长文本转写偏贵
AWS Transcribe	API 按量	约 10 元/小时	$0.024/分钟，英文为主

同一条音频，最便宜和最贵的能差出三四十倍。流式普遍比批量贵，但阿里百炼的 Paraformer 批量和流式同价，这点对成本敏感的业务很友好。另外每家都有免费额度可薅：腾讯云录音文件识别每月送 10 小时，阿里新用户也有，测试期基本不花钱。

自建呢？按云 GPU 租赁的市场价粗算，一张 4090 级别的卡一小时几块钱到十几块钱（按量），按 RTF 折算通常能顶几十路并发的转写量。体量越大自建越划算，但要把运维、模型更新、GPU 故障处理都算进去。我自己算账从来不算单价，算月总账：预计转写时长、并发峰值、GPU 租赁价、运维人力一起丢进表格，两边一对比，答案基本就出来了。单价看着便宜、月总账却吓人的情况，我见过不少。我的判断是：日转写时长在几十小时以内，或者想快速上线，用 API；数据敏感或量大到 API 账单肉疼，再自建。 这里没有标准答案，看你的量和合规要求。

还有两个计费坑得提醒：一是静音段也计费，客户不说话时 ASR 仍在消耗，所以能 VAD 切掉再送识别的，先切；二是"并发通道"分共享和独享，共享通道高峰会呼损，签合同前一定问清楚。AWS Transcribe 还有一个 60 秒最短计费单位，短音频要攒批再送。

七、一张选型清单 + 怎么从 Whisper 平滑迁过来

你的场景	我推荐	关键理由
有 GPU，中文为主	Fun-ASR-Nano	显存占用低，生态最全
只有 CPU	SenseVoice q8	250MB，实时，带情感
字幕/时间轴	Paraformer	字级时间戳+热词
极致精度、显存管够	FireRedASR2S	开源精度第一梯队
多语种/方言	Qwen3-ASR	30 语种+22 方言口音
零运维上线	Seed-ASR / 豆包 API	字节背书，即插即用
端侧/完全离线	sherpa-onnx / GGUF	跨平台，无网络依赖

如果你现在用的就是 Whisper，别急着全换。FunASR 提供 OpenAI 兼容的转写接口（/v1/audio/transcriptions），客户端代码几乎不用动，先用你们最有代表性的音频跑一轮评测再切，风险完全可控。我自己的经验是：切换动作要小，评测要狠：拿最难的那批音频当试金石，而不是拿最干净的。

八、写在最后

FunASR 不是万能的。你要的是极致的那几个点精度、且显存管够，FireRedASR2S 更狠；你要的是马上能用、别管运维，豆包这类 API 更直接；你要的是方言加低音量这种刁钻场景，GLM-ASR 值得单独试。我押 FunASR，是因为它在精度、部署灵活度、生态成熟度和可持续性上最均衡：有 GPU 或纯 CPU、流式或离线、单语种或多语言，都能在同一套基建上找到落点。

顺带说一句我的整体感受：2026 年的中文 ASR，开源生态已经把"能用的门槛"拉到很低了，真正拉开差距的不再是模型本身，而是谁把部署、热词、评测、运维这套脏活干得扎实。模型可以随时换，管线才是你的资产。这句话也适用其他 AI 基础设施：技术会过时，你围绕它建的评测和运维体系不会。

最后说明一句：以上判断基于 2026 年年中的公开资料，ASR 的迭代速度不比大模型慢，半年后再看，牌桌上的名单大概率又有变化。这也是我反复强调把评测和管线做扎实的原因，模型会换，方法不会。

如果你也在做语音识别的落地，欢迎在评论区聊聊你的场景和踩过的坑，我尽量回。

【欢迎访问我的个人博客原文，这里有我的精选文章和每日AI资讯专栏。】

来源原文：中文语音识别选型 2026 FunASR 凭什么排在 Whisper 前面？

本文用到

[1]: FunASR 官方模型选择指南与部署文档. FunASR 模型 — SenseVoice、Paraformer、Fun-ASR-Nano、cam++
[2]: FireRedASR / FireRedASR2S 官方仓库（含 CER 评测表）. GitHub - FireRedTeam/FireRedASR2S: A SOTA Industrial-Grade All-in-One ASR system with ASR, VAD, LID, and Punc modules. FireRedASR2 supports Chinese (Mandarin, 20+ dialects/accents), English, code-switching, and both speech and singing ASR. FireRedVAD supports speech/singing/music in 100+ langs. FireRedLID supports 100+ langs and 20+ zh dialects. FireRedPunc supports zh and en. · GitHub
[3]: Qwen3-ASR 官方仓库. GitHub - QwenLM/Qwen3-ASR: Qwen3-ASR is an open-source series of ASR models developed by the Qwen team at Alibaba Cloud, supporting stable multilingual speech/music/song recognition, language detection and timestamp prediction. · GitHub