2025–2026 ASR 深度调研与选型报告
批量处理 71 集中英双语播客 · 硬件 RTX 3090Ti · 覆盖中文/英文/中英混发三大场景
2025–2026 ASR 深度调研与选型报告
批量处理 71 集中英双语播客 · 硬件 RTX 3090Ti · 覆盖中文/英文/中英混发三大场景
出品:*JINSTUDIO · 小靳后期工作室*
*13 年全栈后期 · PCEA 理事会成员 · R&D 驱动 · jinstudio.com*
目录
- 一、报告摘要
- 二、ASR 行业格局与技术演进趋势
- 三、中文 ASR 核心系统深度对比
- 四、英文与中英混发 ASR 评测
- 五、ASR 管线组件选型(VAD / 标点 / 说话人分离 / 对齐)
- 六、流式架构与部署
- 七、云服务市场与定价
- 八、自建 vs 云端经济学
- 九、典型失败模式与系统局限性
- 十、扩展应用——双语转录知识库的向量检索
- 十一、场景化选型与落地建议(5 种场景)
- 十二、结论
- 附录(A. CLI · B. 基准数据 · C. 参考文献)
一、报告摘要
三条核心判断贯穿本报告:
第一,LLM 架构已全面主导 ASR 精度,传统非自回归模型退居"高性价比"二线。 2025–2026 年间所有刷新 SOTA 的模型——FireRedASR2-LLM、Qwen3-ASR、Fun-ASR (7.7B)、NVIDIA Canary-Qwen——均采用 Conformer 编码器 + LLM 解码器架构。纯声学模型如 Paraformer-Large (220M) 仍在效率维度不可替代(RTF 0.008,1–2GB VRAM),但在 AISHELL-1 上精度差距已扩大至约 3×(1.68% vs 0.57%)。
第二,中英两个生态已完全分化。 中文场景下,Whisper 的 CER 是专用模型的 2–10 倍(AISHELL-1: 5.14% vs FireRedASR2-AED 0.57%),已不适用于任何严肃的中文 ASR 工作负载。英文场景下,云端 API(ElevenLabs 2.3% WER、AssemblyAI 3.3%)体验极佳且功能完备,但开源方案(NVIDIA Canary 4.4%、Whisper large-v3-turbo 4.8%)正快速逼近,本地部署的经济优势在批量场景下碾压云端——3090Ti 处理 71 小时音频的电费不到 1 美元。
第三,不再有"一招鲜"的模型。 最优解严格取决于业务场景的四个维度:离线 vs 流式、纯中文 vs 中英混发、端侧 vs 云端、精度优先 vs 成本优先。本报告为五种典型场景各给出具体的管线配置和成本估算。
二、ASR 行业格局与技术演进趋势
2025–2026 年间,语音识别行业经历了五个结构性转变,重新定义了技术选型的基本假设。
2.1 架构范式转移:从组件堆叠到端到端大模型
传统 ASR 管线是"声学模型 + 语言模型 + VAD + 标点 + 说话人分离"的多组件堆叠。2025 年开始,主流模型向 Encoder + LLM Decoder 端到端架构演进。FireRedASR2-LLM 使用 Qwen2-7B 作为解码器骨干,Fun-ASR API 背后是 7.7B 参数的 Qwen3 底座模型(训练数据达千万小时级别),Qwen3-ASR-1.7B 将语言 ID、标点、流式识别统一到单一模型中,NVIDIA Canary-Qwen 则用 Qwen3-1.7B 作为解码器实现了 4.4% 的英文 AA-WER。
这一转变的实质是:语言模型的世界知识被注入到了语音识别中。LLM 解码器天然理解上下文、专有名词和领域术语,使得转录结果不再是纯粹的声学映射,而是语义感知的文本生成。代价是模型体积和计算需求显著上升——从 Paraformer 的 220M/1–2GB 跃升到 FireRedASR2-LLM 的 8B+/32GB。
2.2 中文 ASR 的寒武纪大爆发
14 个月内,AISHELL-1 基准上的最佳 CER 从 Paraformer-Large 的 1.68% 暴降至 FireRedASR2-AED 的 0.57%——66% 的改善。密集刷榜的竞争者包括:
- FireRedASR(小红书, 2025.01):首个 sub-1% CER 开源模型
- FireRedASR2/2S(小红书, 2026.02–03):集成 VAD/LID/标点的完整管线
- Qwen3-ASR(阿里 Qwen, 2026.01):52 语言 + 22 中国方言,统一流式/离线
- Fun-ASR-Nano(阿里通义, 2025.12):千万小时训练,0.8B 参数下实现 1.96% CER
- GLM-ASR-Nano(智谱):4.10% 多场景 CER
训练数据规模跃升是这轮爆发的根因。Fun-ASR-Nano 使用了"千万小时级"真实语音数据,Qwen3.5-Omni 据报超过 1 亿小时。与之对比,2024 年之前的标杆 Paraformer-Large 仅使用了约 6 万小时标注数据——数量级差距直接转化为精度差距。
2.3 Whisper 的停滞与生态位收缩
OpenAI 未发布 Whisper v4。最新模型仍是 2024 年 10 月的 large-v3-turbo。OpenAI 的战略重心转向 API-only 的 GPT-4o-transcribe(2025.03),将语音识别纳入通用多模态模型而非独立 ASR 产品。
Whisper 的中文 CER 现已 5–10× 落后于最佳开源替代方案。在 WenetSpeech Meeting(高噪会议场景)上,Whisper large-v3 的 CER 高达 18.87%,而 FireRedASR2-LLM 仅 4.32%——一个已不可忽视的代际差距。Fun-ASR 技术报告进一步警告:在独立行业测试集上,Whisper 的 CER 膨胀至 16–32%,而中文优化模型维持在 5–11%。
Whisper 在英文场景仍是合理选择(large-v3-turbo 4.8% WER),且其工具生态(faster-whisper、WhisperX、stable-ts、whisper.cpp)无出其右。但在中文场景下,Whisper 已从"默认首选"降级为"多语言后备"。
2.4 边缘 ASR 的实用化
百兆级参数模型在端侧 CPU 上的可用性是 2025–2026 年的关键进展:
- SenseVoice-Small (234M):<1GB VRAM,Raspberry Pi 可运行,内置标点+情绪+音频事件检测,CER 2.96%(仍优于 Whisper large-v3 的 5.14%)
- Moonshine-tiny-zh (27M):2025 年 9 月发布的中文特化版,精度匹配 Whisper Medium,模型仅 27M 参数
- Paraformer-v2 (220M):CTC 架构改进噪声鲁棒性,CPU RTF 0.05–0.1(i7 处理 92 秒音频约需 9 秒)
- Sherpa-ONNX:唯一覆盖 Android/iOS/HarmonyOS/Raspberry Pi/RISC-V/NPU 的框架,12 种编程语言绑定,CPU-only ONNX 推理
2.5 一体化模型取代组件堆叠
"Paraformer + FSMN-VAD + CT-Punc"三组件模式曾是 2024 年中文 ASR 的金标准。2026 年,这一模式正被单一模型取代:
- FireRedASR2:集成 FireRedVAD + FireRedLID(语言识别)+ FireRedPunc,标点 F1 78.90%(vs FunASR-Punc 62.77%)
- SenseVoice:单模型输出标点 + ITN + 情绪标签 + 音频事件标签
- Qwen3-ASR:单模型处理语言 ID + 标点 + 流式/离线统一推理
一体化的好处不仅是部署简化,更在于端到端优化消除了组件间的级联误差。当 VAD 错误切割了一个语音片段,下游 ASR 和标点模型都会受损;一体化模型从根本上规避了这类问题。
三、中文 ASR 核心系统深度对比
3.1 基准测试与真实世界表现差异
干净语音与真实场景的鸿沟
中文 ASR 基准测试存在一个结构性问题:干净朗读语音与真实场景音频之间的性能差距可达 3–4 倍。以 Whisper large-v3 为例,其在 AISHELL-1(标准朗读数据集)上的 CER 为 5.14%,而在 WenetSpeech Meeting(真实会议录音)上飙升至 18.87%,劣化 3.7 倍。即便是当前精度天花板 FireRedASR2-LLM,在 AISHELL-1 上仅 0.64% CER,到 WenetSpeech Meeting 也升至 4.32%,劣化 6.75 倍。
| 模型 | AISHELL-1 CER | WenetSpeech Meeting CER | 劣化倍数 |
| FireRedASR2-LLM | 0.64% | 4.32% | 6.75x |
| FireRedASR2-AED | 0.57% | 4.53% | 7.95x |
| Doubao-ASR API | 1.52% | 4.74% | 3.12x |
| Qwen3-ASR-1.7B | 1.48% | 5.88% | 3.97x |
| Fun-ASR API (7.7B) | 1.64% | 5.78% | 3.52x |
| Whisper large-v3 | 5.14% | 18.87% | 3.67x |
这意味着仅凭 AISHELL-1 排名选型可能严重误导决策。一个模型在干净数据集上领先 0.1 个百分点的优势,在真实噪声场景中完全可能被逆转。
"论文与 API"的精度差距
商业 API 的生产性能与论文报告数据之间存在系统性偏差。两个典型案例:
Seed-ASR / Doubao-ASR:2024 年 7 月的 Seed-ASR 论文(arXiv:2407.04675)报告 AISHELL-1 CER 为 0.68%,但 2026 年 2 月实测商用 API 的 CER 为 1.52%——生产系统显著劣于论文数据。LibriSpeech-other 上差距更大:论文 2.84%,API 实测 5.69%,差 2.0 倍。这一差距很可能源自商用服务为满足延迟和吞吐量要求所做的工程妥协(量化、蒸馏、流式截断等)。
Fun-ASR / 百炼 API:阿里的 Fun-ASR 技术报告声称其 API 在内部真实评测集上优于开源模型,但在 FireRedASR2S 的公开基准测试中(24 组数据集),Fun-ASR API 的四基准均值 CER 为 4.16%,排名低于 FireRedASR2-LLM(2.89%)、FireRedASR2-AED(3.05%)、Doubao-ASR(3.69%)和 Qwen3-ASR(3.76%)。
方言识别:当前最大技术痛点
方言是中文 ASR 尚未攻克的堡垒。FireRedASR2S 技术报告(arXiv:2603.10420, 2026 年 3 月)在 19 组方言基准上的测试结果显示,即便是最好的系统 CER 均值也在 11% 以上:
| 系统 | 方言 19 组均值 CER |
| FireRedASR2-LLM | 11.55% |
| FireRedASR2-AED | 11.67% |
| Qwen3-ASR-1.7B | 11.85% |
| Fun-ASR API (7.7B) | 12.76% |
| Fun-ASR-Nano (0.8B) | 15.07% |
| Doubao-ASR API | 15.39% |
具体方言的 CER 范围差异极大。上海话会话数据 CER 从 27%(FireRedASR2-AED)到 45%(Doubao-ASR),四川话较难样本 CER 全系统在 20%–25% 区间,粤语短片段 CER 在 5%–10.5% 之间浮动。值得注意的是,Doubao-ASR 方言均值 15.39% 为四大系统中最差,比 FireRedASR2-LLM 的 11.55% 高出 33%——这一差距从纯普通话基准中完全不可见。
基准排名与用户体感的脱节
V2EX 社区用户的反馈与基准排名形成了颇具启发性的反差。一位使用 Doubao 六个月的用户报告"语音识别体感上几乎没有任何错误";另一位直言"剪映(火山引擎后端)是最准确的,Whisper 和 Paraformer 准确性都差很多"。然而在公开基准排名中,Doubao-ASR 仅列第三或第四。
这一脱节的根源在于:CER 衡量的是逐字符准确率,但用户体感受上下文感知解码、生产级标点/ITN 后处理、热词表支持等系统级因素影响更大。Seed-ASR 2.0 引入的 PPO 强化学习和多模态视觉消歧,正是针对"体感"而非"CER"的优化方向。
数据泄漏风险
Fun-ASR 技术报告明确警告:公开测试集的性能"可能不反映真实能力",原因是数据泄漏——训练集与测试集之间可能存在重叠。实测数据佐证了这一担忧:在独立行业测试集上,Whisper 的 CER 从基准的 5–10% 飙升至 16–32%,而中文专用模型维持在 5–11%。
3.2 四大顶尖中文系统详细剖析
以下数据来自 FireRedASR2S 技术报告(arXiv:2603.10420, 2026 年 3 月)的 24 组测试集统一评测。四系统完整对比表:
| 基准 | FireRedASR2-LLM (8B+) | FireRedASR2-AED (1B+) | Doubao-ASR API | Qwen3-ASR-1.7B | Fun-ASR API (7.7B) |
| AISHELL-1 | 0.64 | 0.57 | 1.52 | 1.48 | 1.64 |
| AISHELL-2 | 2.15 | 2.51 | 2.77 | 2.71 | 2.38 |
| WenetSpeech test_net | 4.44 | 4.57 | 5.73 | 4.97 | 6.85 |
| WenetSpeech test_meeting | 4.32 | 4.53 | 4.74 | 5.88 | 5.78 |
| 普通话四基准均值 | 2.89 | 3.05 | 3.69 | 3.76 | 4.16 |
| 方言 19 组均值 | 11.55 | 11.67 | 15.39 | 11.85 | 12.76 |
| 24 组总均值 | 9.67 | 9.80 | 12.98 | 10.12 | 10.92 |
| 歌曲 (opencpop) | 1.12 | 1.17 | 4.36 | 2.57 | 3.05 |
FireRedASR2(小红书)
技术架构:小红书(RedNote)于 2025 年 1 月发布 FireRedASR v1(arXiv:2501.14350),2026 年 2 月发布 v2(FireRedASR2S,arXiv:2603.10420)。提供两个变体:AED(Attention-based Encoder-Decoder,1.1B 参数)和 LLM(8.3B 参数,Qwen2-7B 作为解码器骨干)。v2 版本集成了 FireRedVAD、FireRedLID(语言识别)和 FireRedPunc(标点恢复),构成完整的一体化管线。开源许可为 Apache 2.0。
核心优势:
- 当前开源中文 ASR 精度天花板。AED 变体在 AISHELL-1 上达到 0.57% CER,为 Papers with Code 上的当前 SOTA
- LLM 变体四基准均值 2.89% CER,为当前开源最低
- 歌曲识别能力突出,opencpop CER 仅 1.12%,比 Doubao-ASR 的 4.36% 低 74%
- 方言覆盖 20+ 种中国方言,方言均值 11.55%,与 Qwen3-ASR(11.85%)几乎持平
- v2 集成的 FireRedPunc 标点恢复模块达到 78.90% F1,显著优于 FunASR-Punc 的 62.77%
具体数据:AISHELL-1 CER 0.57%(AED)/ 0.64%(LLM),AISHELL-2 CER 2.15%(LLM 最优),WenetSpeech Meeting 4.32%(LLM),歌曲 1.12%(LLM)。AED 变体通过 CTC 分支提供词级时间戳(v2 新增),LLM 变体无时间戳。AED 需 4–6GB VRAM,LLM 需 ≥32GB VRAM(A100/A800 推荐),磁盘占用约 21GB(LLM)。GPU RTF 约 0.02(AED),TensorRT 可实现 12.7 倍加速。
已知局限:
- AED 变体存在 60 秒最大输入长度限制,超过 200 秒会因位置编码错误而崩溃产生幻觉
- LLM 变体需 32GB 以上 GPU VRAM(推荐 A100/A800),部署门槛高
- v1 版本缺乏标点恢复能力,知乎评论"这玩意儿拿来学习不错,想拿来做产品不行",v2 虽显著改善但 60 秒限制仍在
- v2 的 FireRedVAD 管线在一定程度上缓解了长音频问题,但需要精心设计分块策略
Doubao-ASR / Seed-ASR(字节跳动 / 火山引擎)
技术架构:产品确认即 Seed-ASR——商品名为"Doubao-Seed-ASR-2.0",内部 API resource ID 包含"seedasr"字串。Seed-ASR 论文(arXiv:2407.04675, 2024 年 7 月)描述了基于 LLM 的端到端架构,使用 2B 参数 Conformer 编码器,训练数据超过 2000 万小时语音。v2.0 版本(2025 年 12 月)新增 PPO 强化学习优化上下文推理、多模态视觉消歧以及 13 种外语支持。闭源,仅通过火山引擎 API 提供。
核心优势:
- 上下文感知能力是四系统中最强的——利用对话历史和领域上下文消解歧义,这是纯 CER 指标无法捕捉的能力
- 生产级后处理最完善:内置标点、ITN(逆文本正则化)、热词表(最多 200 token)、替换词规则
- 主观体验最佳——V2EX 用户长期使用反馈"体感几乎无错误"
- 同一技术栈驱动抖音、飞书、Pico VR 等亿级用户产品,生产验证最充分
已知局限:
- 闭源 API-only,无自部署选项,不可控性是最大风险
- 注册需中国大陆手机号和实名认证,国际开发者存在准入壁垒
- API 精度显著低于论文:AISHELL-1 从论文的 0.68% 降至 API 的 1.52%,LibriSpeech-other 从 2.84% 降至 5.69%
- 方言表现四系统最差:19 组均值 15.39%,比 FireRedASR2-LLM 高 33%
Qwen3-ASR(阿里通义)
技术架构:2026 年 1 月发布,1.7B 参数,Conformer 编码器 + Qwen LLM 解码器架构。支持 52 种语言(含 22 种中国方言),通过动态 FlashAttention 实现统一的流式/离线推理模式(2 秒分块)。Apache 2.0 开源许可。
核心优势:
- 多语言和方言覆盖面最广:52 语言 + 22 种中国方言,远超其他系统
- 流式与离线统一架构,92ms Time-to-First-Token,GPU 上并发 128 时可达 2000 倍实时吞吐
- 中英 code-switching 表现优秀——使用 40,000+ 英文关键词合成训练数据,覆盖科技、教育、金融、体育等领域
- 方言 19 组均值 11.85%,仅略逊于 FireRedASR2,远好于 Doubao-ASR 的 15.39%
- 噪声鲁棒性突出:极端噪声下 WER 为 16.17%,而 Whisper large-v3 为 63.17%
已知局限:
- 存在无限 token 重复缺陷(GitHub issue #129),模型会陷入重复短语数千次的死循环
- 流式模式为"伪流式"——每个分块从头重新处理,无跨段上下文,导致边界处出现重复转录和格式泄漏
- 截至 2026 年 4 月约 148 个 open GitHub issues,成熟度存疑
- 在较新的 Transformers 库版本(v5.3/5.4)上精度退化
- 官方论文未报告 AISHELL-1 CER——这对中文 ASR 最标准的基准而言是一个显著的缺位
- 无内置 ITN(逆文本正则化),需依赖社区工具
FunASR / 百炼 API(阿里)
技术架构——关键发现:商用 Fun-ASR 与开源 Paraformer 是完全不同的系统。这是选型中最容易踩的坑。商用 Fun-ASR API(百炼平台,2025 年底上线)运行一个 7.7B 参数的 LLM 架构系统(Qwen3 底座),训练数据达数千万小时。开源 Paraformer-Large 则是 220M 参数的非自回归模型,训练数据约 60,000 小时。两者共享品牌名称,但架构完全无关——参数量差 35 倍,训练数据差数百倍。
核心优势:
- 生态最成熟:Docker 部署、2-pass 流式、热词定制、WebSocket 服务端,生产部署经验最丰富
- 开源 Paraformer-Large(220M 参数)仍是 sub-300M 模型中性价比最高的选择:1–2GB VRAM,GPU RTF 0.008,CPU RTF 0.05–0.1
- FunASR 2-pass 流式模式经阿里巴巴和中国工业界大规模生产验证,4vCPU/8GB RAM 支持 16 路并发流,64vCPU/128GB RAM 支持 100+ 路
- 商用 Fun-ASR API 在真实世界行业数据上 WER 为 7.60%,相对 Paraformer-Large 的约 11% 有 30%+ 改善
已知局限:
- 开源 Paraformer 精度已显著落后 SOTA:AISHELL-1 CER 1.68% 对比 FireRedASR-AED 的 0.55%,差距 3 倍
- FunASR Python 包导入耗时超过 1 分钟(依赖加载问题)
- 商用 Fun-ASR LLM 模型继承了 LLM 固有的幻觉风险——可能生成音频中不存在的文本
- 开源工具包存在持续性 bug:WebSocket 服务端热词参数被静默忽略、ONNX 标点模型加载失败、时间戳数组不匹配
- 开源 ITN 存在已知 bug:如"十一点"被错误转换为"10一点"
- SenseVoice 即将下线,使用该模型的用户面临迁移需求
3.3 其他中文 ASR 方案
SenseVoice-Small / Large
阿里达摩院推出的多任务 ASR 模型,独特之处在于将情绪检测、音频事件标注和标点恢复集成在识别输出中。SenseVoice-Small 仅 234M 参数(0.23B),GPU VRAM 不足 1GB,甚至可在树莓派上运行,AISHELL-1 CER 为 2.96%——仍优于 Whisper large-v3 的 5.14%,且模型体积仅为后者的 1/6。SenseVoice-Large(1.6B 参数)CER 更低:AISHELL-1 2.09%,AISHELL-2 3.04%,WenetSpeech Meeting 6.73%。两者均支持 5 种语言的 code-switching。
但关键限制是:SenseVoice 在百炼平台已标记为"即将下线"(文档原文),用户被引导向 Fun-ASR 或 Paraformer-v2 迁移。此外,SenseVoice 无原生流式支持,sherpa-onnx 通过 VAD + 分块离线推理模拟流式,但非真正的流式方案。作为边缘部署或资源受限场景的轻量选择,SenseVoice-Small 在下线前仍有价值。
Fun-ASR-Nano (0.8B)
2025 年 12 月发布(Fun-ASR-Nano-2512),0.8B 参数,训练数据达数千万小时真实语音,VRAM 需求 2–4GB。AISHELL-1 CER 1.76%,AISHELL-2 CER 2.80%(素材 2 报告值)/ 3.02%(FireRedASR2S 统一评测值)。支持 31 种语言、流式模式和原生标点输出。定位为精度与效率的平衡点——参数量仅为 Fun-ASR API(7.7B)的 1/10,但四基准均值 4.55% 与 Paraformer-Large 的 4.56% 几乎持平,方言均值 15.07% 则与 Doubao-ASR 的 15.39% 同处一档。
Moonshine-tiny-zh (27M)
2025 年 9 月 Moonshine "Flavors" 系列发布的极致边缘模型,仅 27M 参数(0.027B),声称精度匹配 Whisper Medium。这是目前已知最小的中文 ASR 模型。支持通过 sherpa-onnx 在 CPU 上部署,适用于 Android、iOS、树莓派等终端设备。不支持 code-switching,无原生标点输出。当 VRAM 和算力极度受限时,Moonshine-tiny-zh 提供了一个"有总比没有好"的选项。
WeNet U2++
约 100M 参数(0.1B),清华大学开源项目,提供原生流式支持(unified two-pass 架构)。AISHELL-1 CER 4.63%,精度在当前竞争中已不突出,但其架构设计在学术界有深厚影响。code-switching 支持有限,无原生标点输出。作为学习和研究参考有价值,但生产选型已不推荐。
MiniMax / Moonshot / 智谱的 ASR 现状
MiniMax:尽管国际网站(minimax.io)列出"语音识别 API",但官方开发者文档(platform.minimaxi.com)未暴露任何 ASR endpoint。MiniMax 自己的同声传译 GitHub demo 使用 Whisper 作为 ASR 组件。第三方分析显示其 STT 功能为 Whisper Large 的封装。MiniMax 在 TTS 领域确实领先(Artificial Analysis Speech Arena 和 HuggingFace TTS Arena 双第一),但不具备自研 ASR 能力。
Moonshot / Kimi:无商用 ASR API。但其开源的 Kimi-Audio-7B 在 AISHELL-1 上达到 0.60% WER——这一数字极其出色,接近 FireRedASR2-AED 的 0.57% CER 水平。然而该模型仅以开源形式存在,无云端 API 服务,且为 WER 非 CER 指标,跨系统直接比较需谨慎。
智谱 AI (Zhipu):是新锐 AI 公司中唯一提供正式 ASR 产品的。GLM-ASR 和 GLM-ASR-2512 云端 API 支持流式识别、8 种中国方言、OpenAI 兼容 SDK 集成。GLM-ASR-Nano(1.5B 参数)多场景均值 CER 为 4.10%。在四大顶尖系统的光芒下不够突出,但作为完整商用 ASR API 确实可用。
3.4 CapCut / 剪映的技术底层
火山语音团队 RNN-T + Conformer 架构
CapCut / 剪映使用的是字节跳动自研的 ASR 技术,由火山语音(Volcano Speech)团队构建,通过火山引擎(Volcengine)云平台交付。不是 FunASR,不是 Paraformer——那是阿里的技术栈,完全不同的公司和代码库。
核心架构为基于 RNN-T (Recurrent Neural Network Transducer) + Conformer 编码器的端到端流式系统,将 ASR、端点检测、标点恢复、逆文本正则化(ITN)和智能分句集成在统一管线中。2023 年 1 月,该系统在中国 AI 国家检测中心的特定认证测试条件下达到 99% 识别准确率。同一引擎驱动抖音(TikTok 中国版)、飞书(Lark)和 Pico VR。
与 Seed-ASR 的关系
Seed-ASR 是字节跳动的下一代 ASR 系统,训练数据超过 2000 万小时语音,基于 LLM 架构。Seed-ASR 相对 Whisper 实现了 10–40% 的错误率降低,目前正逐步整合进 Doubao 平台。CapCut / 剪映的 ASR 后端即为火山引擎 ASR 服务,与 Doubao-ASR / Seed-ASR 属同一技术族谱,但具体部署版本可能与 Seed-ASR 2.0 论文描述的研究模型存在生产化差异。
AsrTools 开源逆向
AsrTools(GitHub 2.6k stars)是一个开源项目,逆向工程了 CapCut / 剪映、Bilibili 和快手的云端 ASR API。使用者无需 GPU,直接通过网络调用这些平台的后端服务获取字节跳动级别的 ASR 质量。对于不想自建基础设施但又希望获得高质量中文 ASR 的用户,AsrTools 提供了一条零成本的捷径——代价是依赖逆向接口的稳定性,且处于法律灰色地带。
四、英文与中英混发 ASR 评测
英文 ASR 市场在 2025–2026 年经历了显著的格局重塑:多家云端 API 在精度上超越了 Whisper,开源方案则由 NVIDIA 领衔快速追赶。与中文市场以国产模型一骑绝尘不同,英文赛道呈现出云端 API 高度成熟、开源方案实用化、LLM 转录新范式涌现的三重并行态势。
4.1 英文商业 API 梯队(AA-WER v2.0 基准)
当前最可靠的独立英文 ASR 基准是 Artificial Analysis 发布的 AA-WER v2.0,该基准在三个真实世界数据集(AgentTalk、VoxPopuli、Earnings-22)上测试了 41 个模型,覆盖对话、议会演讲与财报电话会议三类场景。
第一梯队:极限精度
ElevenLabs Scribe v2 以 2.3% WER 位居所有专用 ASR API 之首,2025 年 2 月发布 v2 更新。价格 $0.40/小时处于中位水平。核心特性包括:词级时间戳、最多 32 说话人分离、独有的音频事件标注(笑声、掌声等),流式延迟约 150ms。主要局限是相对较新且仅支持云端部署。
紧随其后的是 Gemini 3 Pro(2.9% WER,$4.80/1000 min)与 Gemini 3 Flash(3.1% WER,$1.92/1000 min)。值得注意的是,Google 的 LLM 转录模型表现优异,但其传统 STT 产品 Chirp 却令人震惊地录得 31.3% WER——同一家公司两套产品的精度差距超过 10 倍。
第二梯队:All-in-one 生产力
AssemblyAI Universal-3 Pro 录得 3.3% WER,定价 $0.21/小时,是顶级 API 中精度-成本比最优的选项。AssemblyAI 刻意优化"可用输出"而非原始 WER:Universal-2 相比前代在专有名词准确率上提升 24%,字母数字处理提升 21%,人类偏好评价高出 73%。其 Speech Understanding API 将转录、摘要、情感分析和主题检测整合为单次调用。
Gladia Solaria-1 以 4.2% WER 和 $0.50/小时固定价格(无加价项)提供最完整的单 API 功能集:转录、说话人分离、时间戳、标点、语义分章(chapterization)、摘要、命名实体识别、情感分析与 99 语言翻译。其中语义分章能力在 ASR API 中极为罕见,code-switching(中途自动语言检测)是其特色优势。
Speechmatics Enhanced (Ursa 2) 录得 4.3% WER,$0.40/小时,功能全面。
第三梯队:极致性价比与速度
Deepgram Nova-3 以 5.4% WER 换取不可匹敌的速度(130–473 倍实时)和最低定价 $0.26/小时(批量)。词时间戳、说话人分离、标点、关键词提示、PII 脱敏全部包含在单次 API 调用中,无加价项。其前代 Nova-2 在部分测试中以 5.6% WER 表现,且速度可达 473 倍实时——所有 API 中最快。
Gemini 2.0 Flash Lite 以 4.0% WER 和仅 $0.19/1000 min 的价格成为成本极致之选,但属于 LLM 转录路线,后处理灵活性有限。
第四梯队:LLM 转录新势力
OpenAI GPT-4o Transcribe 录得 4.1% WER,幻觉相比 Whisper v2 减少约 90%(2025 年 12 月数据)。但存在关键局限:不提供词级时间戳(仅遗留 Whisper-1 模型支持),说话人分离需要调用单独的 gpt-4o-transcribe-diarize 模型且仅提供句段级时间戳,最大分块限制 23 分钟。定价 $0.36/小时。
Microsoft MAI-Transcribe-1(2026 年 4 月)声称在 25 种语言上达到商用模型最低 WER,$0.36/小时,但独立验证尚待完成。
避坑指南
Google Cloud Speech-to-Text (Chirp) 在相同基准上录得 31.3% WER——考虑到 Google 自家 Gemini 模型可达 4.0%,这一数字令人难以置信地差。Azure Native STT 同样落后,WER 在 10–14% 区间。两家巨头的传统 STT 产品已严重脱离第一阵营,但均可通过各自平台接入 OpenAI 模型作为替代。
Amazon Transcribe 以 4.3% WER 保持可用精度,但 $1.44/小时的定价在同级中最贵。
英文商业 API 全景表
| 厂商 | 模型 | AA-WER v2.0 | 价格/小时 | 词时间戳 | 说话人分离 | 流式 |
| ElevenLabs | Scribe v2 | 2.3% | $0.40 | ✅ | ✅ (32人) | ✅ (~150ms) |
| AssemblyAI | Universal-3 Pro | 3.3% | $0.21 | ✅ | ✅ | ✅ |
| AssemblyAI | Universal-2 | 4.0% | $0.15 | ✅ | ✅ (+$0.02) | ✅ |
| OpenAI | GPT-4o Transcribe | 4.1% | $0.36 | ❌ | 独立模型 | ✅ |
| Gladia | Solaria-1 | 4.2% | $0.50 | ✅ | ✅ | ✅ |
| Amazon | Transcribe | 4.3% | $1.44 | ✅ | ✅ | ✅ |
| Speechmatics | Enhanced (Ursa 2) | 4.3% | $0.40 | ✅ | ✅ | ✅ |
| Deepgram | Nova-3 | 5.4% | $0.26 | ✅ | ✅ | ✅ (<300ms) |
| Azure | Native STT | ~10–14% | $0.36 | ✅ | ✅ | ✅ |
| Chirp | 31.3% | $0.96 | ✅ | ✅ | ✅ |
4.2 Seed-ASR 英文表现
字节跳动的 Seed-ASR 论文(arXiv:2407.04675,2024 年 7 月)报告了其多语言模型(Seed-ASR ML)在英文上的竞争力数据。该模型基于 20 亿参数 Conformer 编码器,使用约 125K 小时英文监督数据训练。
在标准基准上,Seed-ASR 声称:
- LibriSpeech test-clean:1.58% WER(略优于 AssemblyAI Universal-1 的 1.6%)
- LibriSpeech test-other:2.84% WER(优于 Universal-1 的 3.1%)
- Switchboard:11.59% WER(优于 Whisper v2 的 13.8%)
- CallHome:12.24% WER(优于 Whisper v2 的 17.6%)
- 内部多域英文测试:5.34% WER,相比 Google USM 的 9.33% 实现 42% 相对降低
然而,必须附加关键警示。没有任何独立第三方验证过这些数字。Seed-ASR 不开源,未出现在任何公共排行榜上,仅通过火山引擎商业 API 可用。论文中的基线对比使用其他论文的数据,而非受控的头对头评测。
尤其值得注意的是,生产 API 与论文数字存在显著差距。以 Doubao-ASR API 实测为例:AISHELL-1 CER 为 1.52%(论文 0.68%),LibriSpeech-other WER 为 5.69%(论文 2.84%)。这种 API-vs-paper gap 在商用部署中普遍存在,源于延迟/吞吐优化对精度的折衷。
4.3 英文开源方案
开源英文 ASR 在 2025–2026 年由 NVIDIA 领衔实现了质的飞跃,正在快速缩小与商业 API 的差距。
NVIDIA Canary-Qwen-2.5B
采用 Conformer 编码器 + Qwen3-1.7B 解码器架构,在 AA-WER v2.0 上录得 4.4% WER,处理速度达 418 倍实时——是开源英文模型中精度最高的选项。作为完全免费的自托管方案,其精度已与 GPT-4o Transcribe(4.1%)和 Amazon Transcribe(4.3%)处于同一区间,且幻觉风险低。但 2.5B 参数量意味着 GPU 依赖。
NVIDIA Parakeet-TDT-0.6B
另一条极端路线:仅 0.6B 参数的非自回归 CTC/TDT 解码器,以 6.8% WER 换取 超过 2000 倍实时的极致吞吐。其非自回归架构在结构上天然免疫幻觉——不存在自回归解码器循环注意力发散的风险。适合对吞吐量要求极高、可容忍少许精度损失的场景。
Whisper large-v3-turbo
尽管 OpenAI 未发布 Whisper v4(转向 API-only GPT-4o-transcribe),Whisper large-v3-turbo 仍是英文自托管的务实之选。4.8% WER 具备竞争力,运行仅需 5–6GB VRAM,且生态系统无可匹敌:faster-whisper(CTranslate2 加速)、WhisperX(wav2vec2 强制对齐 + Silero VAD)、stable-ts(稳定时间戳)、whisper.cpp(CPU 推理)形成了完整的工具链。
| 模型 | 参数 | AA-WER / WER | 实时倍速 | VRAM | 幻觉风险 |
| Canary-Qwen-2.5B | 2.5B | 4.4% | 418x | — | 低 |
| Parakeet-TDT-0.6B | 0.6B | 6.8% | >2000x | — | 零 |
| Whisper large-v3 | 1.55B | 4.3% | 91–154x | ~10GB | 高 |
| Whisper large-v3-turbo | — | 4.8% | — | 5–6GB | 高 |
4.4 中英混发 Code-Switching 专项
为什么传统模型难以处理中英混发
Code-switching(语码转换)指说话人在同一句或同一段话中交替使用两种或多种语言的现象,如"我们用 transformer 做的这个 API 有三个 endpoint"。传统 ASR 模型在此场景下面临三重困难:
- 训练数据偏差:绝大多数 ASR 训练集以单语为主,中英混合的标注数据极度稀缺。模型的声学模型和语言模型均假设单一语言分布,面对语种切换点时概率分布急剧失真。
- 声学-语言双重不确定性:切换点处,声学特征从一种语言的音素空间突变为另一种,而语言模型的 n-gram/上下文概率同时失效。自回归解码器在此处尤其脆弱——前序中文 token 生成的上下文无法为后续英文 token 提供有效条件概率。
- 词汇表与分词冲突:中文基于字符/词的分词与英文基于 subword(BPE/SentencePiece)的分词在混合文本中产生边界冲突,导致 token 化效率下降和 OOV(未登录词)激增。
各系统 Code-Switching 策略
Qwen3-ASR-1.7B 采用最系统化的 code-switching 训练方案。团队合成了 40,000+ 英文关键词覆盖科技、教育、金融和体育四大高频混发领域,将其注入中文训练语料生成大量中英混合训练样本。配合 52 语言原生多语言训练和 22 种中国方言支持,Qwen3-ASR 在 code-switching 上具备最广的语言覆盖面。但其已知问题——无限 token 重复(GitHub issue #129)和伪流式边界重复——在混发场景下可能被放大。
Seed-ASR / Doubao-ASR 在 v2.0 中引入了 Function Call 策略专项优化 code-switching。Seed-ASR 的核心优势在于上下文感知能力——利用对话历史和领域上下文消解歧义。然而,Doubao-ASR 的方言 CER 在四系统中最差(15.39% 平均),意味着当 code-switching 叠加方言时性能可能急剧恶化。
Gladia Solaria-1 提供全自动中途语言检测,支持 99 种语言的 code-switching,无需用户预设语言。这种"零配置"方案对于不确定音频语言构成的场景极具吸引力。4.2% AA-WER 的精度基础也足够扎实。其固定 $0.50/小时定价包含 code-switching 能力,无额外加价。
FireRedASR2 支持 code-switching 但并非其核心卖点。该系统的优势集中在纯中文精度(AISHELL-1 CER 0.57%)、20+ 方言覆盖和歌曲识别(opencpop CER 1.12%)。在中英混发场景下可作为备选,但不如前述三者有针对性。
Fun-ASR 的 code-switching 依赖用户显式配置语言 hint,自动检测能力有限。开源版的流式中英识别受限于 streaming-paraformer-bilingual-zh-en 模型,不如 Qwen3-ASR 的原生多语言流式。商用 Fun-ASR API(7.7B LLM 架构)在 code-switching 上表现更好,但具体提升幅度缺乏公开基准支撑。
4.5 "全功能一站式" API 对标
| 功能 | Deepgram Nova-3 | AssemblyAI | Gladia Solaria-1 | ElevenLabs Scribe v2 |
| 词级时间戳 | ✅ | ✅ | ✅ | ✅ |
| 说话人分离 | ✅ (40x 快于竞品) | ✅ | ✅ | ✅ (32人) |
| 标点恢复 | ✅ | ✅ | ✅ | ✅ |
| 语义分章 | ❌ | ✅ (主题检测) | ✅ (chapterization) | ❌ |
| 摘要生成 | ❌ | ✅ | ✅ | ❌ |
| 情感分析 | ❌ | ✅ | ✅ | ❌ |
| NER/实体检测 | ❌ | ✅ | ✅ | ❌ |
| PII 脱敏 | ✅ | ✅ | ❌ | ❌ |
| 翻译 | ❌ | ❌ | ✅ (99 语言) | ❌ |
| 音频事件标注 | ❌ | ❌ | ❌ | ✅ (独有) |
| Code-switching | ❌ | ❌ | ✅ | ❌ |
| 定价/小时 | $0.26 | $0.15–0.75 | $0.50 固定 | $0.40 |
Deepgram Nova-3 最接近"全功能单次调用":词时间戳、说话人分离、智能格式化、PII 脱敏和填充词检测全部通过参数激活,无加价项。唯一缺失是语义分章。
Gladia Solaria-1 是功能最完整的单一 API,且以 $0.50/小时固定价包含所有功能。语义分章(chapterization)、跨 99 语言翻译和 code-switching 是其独特差异点。对于需要"设置后遗忘"且功能需求全面的场景,Gladia 的综合性价比最高。
ElevenLabs Scribe v2 在精度上独占鳌头(2.3% WER),音频事件标注(笑声、掌声等)是独有特性,但缺乏语义分章和 AI 分析能力。适合对精度要求极致、不需要深度语义处理的场景。
4.6 社区共识与基准局限
基准的系统性失真
发布基准的可靠性正受到越来越多质疑。厂商在公开数据集上训练已是公开的秘密——一个模型在基准上显示 5% WER,在有挑战性的生产音频上可能实际交出 15–20% WER。Fun-ASR 技术报告自身明确警告:公开测试集结果可能因数据泄漏而无法反映真实能力。Reddit 和 HN 社区的共识是:永远在自己的数据上测试,不要信任发布的数字。
LLM-based ASR 趋势
GPT-4o Transcribe、Gemini、Mistral Voxtral 等 LLM 转录模型正在重塑预期。这类模型在上下文理解、专有名词和格式化上优于传统 encoder-decoder ASR,但普遍更慢且更贵。长期趋势明确:LLM 架构将主导精度前沿,传统 ASR 退居高吞吐/低成本生态位。这与中文市场的演进路径完全一致——LLM-integrated 架构已全面接管精度排行榜。
五、ASR 管线组件选型
针对传统或非 All-in-one 模型的管线设计。2026 年一体化模型正在取代组件堆叠范式,但组件化管线仍是低资源部署、定制化场景和使用非一体化模型(如 Paraformer、WeNet、Whisper)时的主流方案。
5.1 VAD——语音活动检测
VAD(Voice Activity Detection)是 ASR 管线的第一道防线:将音频流中的有效语音段从静音、噪声和非语音事件中分离出来。VAD 的质量直接影响下游 ASR 的精度——尤其对 Whisper 类自回归模型而言,VAD 预处理是抑制幻觉的单一最有效手段。
FSMN-VAD
FunASR 生态内置的中文工业级 VAD,基于前馈序列记忆网络(FSMN),使用 5,000+ 小时工业级普通话语料训练,含抗噪数据增强。以 ONNX 格式推理速度极快,与 FunASR 管线深度集成——过滤无效语音段可直接降低下游 CER。定位:纯中文 ASR 管线的首选 VAD。Apache 2.0 许可。
Silero VAD v5
通用场景最佳 VAD,MIT 许可,模型仅约 2MB。在标准评测中录得 87.7% TPR at 5% FPR,3 行 Python 即可集成,支持全平台部署。语言无关设计使其在跨语言和 code-switching 场景中比 FSMN-VAD 更灵活。定位:非 FunASR 管线的默认 VAD 选择。WhisperX 和 faster-whisper 均内置 Silero VAD 集成。
pyannote VAD
学术 SOTA 级精度,基于深度学习,GPU 推理效果最佳。核心优势在于与 pyannote.audio 说话人分离管线的无缝衔接——当管线同时需要 VAD 和 diarization 时,pyannote VAD 是自然选择。CC-BY-4.0 许可。定位:需要说话人分离的离线批量管线。
WebRTC VAD
Google 早期发布的轻量级 VAD,BSD 许可。但在相同评测条件下仅 50% TPR at 5% FPR——Silero 的错误率是其四分之一。定位:已过时(effectively obsolete),仅在遗留系统兼容性场景下才有使用理由。
| VAD 模型 | 精度 | 延迟 | 流式 | 中文专项 | 最佳场景 |
| FSMN-VAD | 工业级 (5000+h 中文训练) | 极快 (ONNX) | ✅ | ★★★★★ | 中文 ASR 管线 |
| Silero v5 | 87.7% TPR@5% FPR | <1ms/chunk | ✅ | ★★★ | 通用/跨语言/Whisper 管线 |
| pyannote | 学术 SOTA | 中等 (GPU 最佳) | ✅ | ★★★ | 配合说话人分离 |
| WebRTC | 50% TPR@5% FPR | 可忽略 | ✅ | ★★ | 遗留系统 |
| TEN VAD | 优于 Silero (精确率-召回率) | 低于 Silero | ✅ | 未记录 | Web/WASM 部署 |
5.2 标点恢复与 ITN
CT-Punc (CT-Transformer)
FunASR 生态中独立最佳的中文标点恢复模型。处理中文标点(,。!?)和中英混合文本,支持离线与流式两种模式。以 ONNX 在 CPU 上运行,添加的延迟几乎为零。经阿里工业级语音服务大规模验证。定位:使用 Paraformer 或 WeNet 等不内置标点输出的模型时,CT-Punc 是标点恢复的首选。
FireRedPunc
FireRedASR2S(v2,2026 年 2 月)集成的 BERT-based 标点模型,F1 分数达 78.90%——显著优于 FunASR-Punc 的 62.77%(同源基准)。值得注意的是,FireRedASR v1 完全没有标点能力——这曾是用户投诉的主要痛点,知乎评价"拿来学习不错,做产品不行"。v2 的 FireRedPunc 彻底解决了该问题。
原生标点输出趋势
2025–2026 年的重要结构性变化是:最佳 ASR 模型开始原生输出标点,使独立标点模型在许多管线中不再必要:
- SenseVoice:输出标点 + ITN + 情绪标签 + 音频事件标签
- Qwen3-ASR:LLM 解码自然产生标点和语言识别
- FireRedASR2:集成 FireRedPunc 组件
- Whisper:大多数语言输出标点,但中文标点质量不稳定
ITN 陷阱
ITN 看似简单,实则暗藏陷阱。FunASR 开源 ITN 存在已知 bug,例如将"十一点"错误转换为 "10一点"(半中半洋的混合格式)。Qwen3-ASR 没有内置 ITN,需要依赖社区工具。建议:对 ITN 质量要求高的场景,优先选择 Doubao-ASR API(生产级标点/ITN/热词表最完善)或 FireRedASR2(FireRedPunc 含 ITN),避免依赖 FunASR 开源 ITN。
5.3 说话人分离(Diarization)
说话人分离回答"谁在什么时候说了什么",是多说话人场景(会议、访谈、播客)的刚性需求。评估指标为 DER(Diarization Error Rate),越低越好。
| 系统 | DER (AISHELL-4) | DER (AMI) | 中文支持 | 流式 | 最佳场景 |
| pyannote community-1 | 11.7% | 17.0% | ★★★★ | 部分 | 整体最优 (离线) |
| 3D-Speaker + CAM++ | 13.3% | — | ★★★★★ | ❌ | 中文专优 |
| FunASR CAM++ 管线 | 竞争力 | — | ★★★★★ | ✅ | 中文生产集成 |
| NeMo Sortformer v2 | ~13% | ~13% | ★★★ | ✅ | 高效流式 (<=4人) |
pyannote community-1 在 AISHELL-4 上录得 11.7% DER——所有开源方案中最低。使用 WeSpeaker embeddings,相比 3.1 基线有显著提升。CC-BY-4.0 许可。定位:离线批量管线中整体 DER 最优的选择。
3D-Speaker + CAM++ 中文专项说话人分离的最强方案。CAM++ 说话人 embedding 模型仅 7.2M 参数,在 VoxCeleb1-O 上 EER 仅 0.65%。Apache 2.0 许可。
NeMo Sortformer v2 NVIDIA 的说话人分离方案,核心优势在于计算效率:214 倍实时处理速度。局限:最多仅支持 4 位说话人,大规模会议场景受限。CC-BY-NC-4.0 许可(非商用限制需注意)。
5.4 时间戳与词级对齐
Doubao-ASR (Seed-ASR) 提供最完善的时间戳方案:句级时间戳 + 说话人关联,毫秒精度。生产级标点和 ITN 与时间戳深度整合。
FireRedASR2-AED 通过 CTC 分支输出词级时间戳(仅 v2,v1 无此能力)。其 LLM 变体(8B+)不支持时间戳——这是 LLM decoder 架构的通病,因为自回归生成过程中的时间对齐信息被注意力机制分散。
Qwen3-ASR 没有内置时间戳输出。阿里为此发布了独立的 Qwen3-ForcedAligner-0.6B 模型,专门做语音-文本强制对齐。该模型实测平均对齐精度达 36.5ms——优于 WhisperX 和 Montreal Forced Aligner (MFA)。但需要额外的推理步骤和 GPU 资源。流式模式下完全没有时间戳支持。
WhisperX 是当前英文词级时间戳最成熟的方案。其核心思路是:先用 Whisper(或 faster-whisper)做转录,再用 wav2vec2 强制音素对齐将转录文本与音频精确对齐到词级。配合 Silero VAD 分段和 condition_on_prev_text=False 设置,WhisperX 同时解决了时间戳精度和幻觉两个问题。在 3090Ti 上,WhisperX 以 batched 推理处理 71 小时英文音频仅需 ~2.5–3.5 小时(<8GB VRAM)。
| 模型/系统 | 时间戳类型 | 精度 | 备注 |
| Doubao-ASR API | 句级+说话人 | 毫秒级 | 最完善 |
| FireRedASR2-AED | 词级 (CTC) | 良好 | 仅 v2 AED,LLM 无时间戳 |
| Qwen3-ASR | 无内置 | — | Qwen3-ForcedAligner (36.5ms) |
| Bailian API | 词级+句级 | 有 bug 报告 | 需校验对齐质量 |
| Paraformer-Large | 字符级 (CIF) | 良好 | v2 CTC 改善噪声鲁棒性 |
| Whisper + WhisperX | 词级 (wav2vec2) | 高 | 英文最成熟方案 |
| SenseVoice | 不支持 | — | 无时间戳能力 |
六、流式架构与部署
流式 ASR 是实时交互(同声传译、语音输入、会议纪要)的刚性需求。然而,并非所有模型都具备真正的流式能力。
6.1 流式方案对比
FunASR 2-pass:生产级中文流式标杆
FunASR 的 2-pass 架构是当前最成熟的中文流式 ASR 方案,已在阿里及中国工业界大规模部署。其核心设计为双阶段流水线:第一阶段(流式 Paraformer)低延迟初始输出,声学延迟 480–600ms;第二阶段(离线 Paraformer-Large)在句边界触发全句校正,将精度拉回离线水平。
| 硬件配置 | 并发流数 |
| 4 vCPU / 8GB RAM | 16 路 |
| 64 vCPU / 128GB RAM | 100+ 路 |
Sherpa-ONNX:最广部署面的跨平台方案
Sherpa-ONNX 的核心价值不在精度,而在部署覆盖面。它是唯一一个从服务器机架到微控制器全覆盖的 ASR 框架:12 种编程语言绑定(C/C++/Python/Java/C#/Go/Kotlin/Swift/JS/Dart/Rust/Ruby),支持 Android / iOS / HarmonyOS / Raspberry Pi / RISC-V / Ascend NPU,纯 CPU + ONNX Runtime,无 GPU 依赖。双语模型提供真正的中英双语流式识别。
Qwen3-ASR:最高精度流式,但存在"伪流式"问题
Qwen3-ASR-1.7B 通过 dynamic FlashAttention 实现流式推理,分块策略为 2 秒 chunk,TTFT 92ms,吞吐量 2000x 实时(concurrency 128)。然而,Qwen3-ASR 的流式实现存在根本性局限:每个 chunk 从头重新处理,无跨段上下文传递。这导致边界处转录重复和格式泄漏两个实际问题。严格来说,这是伪流式(chunked offline)而非真流式(incremental decoding)。
Whisper:无真正流式方案
Whisper 的 Transformer 编码器-解码器架构要求完整的 30 秒音频窗口输入,从设计上排除了真正的流式能力。社区最佳努力 UFAL Whisper-Streaming 延迟约 3.3s(英文),其他语言更高——对实时应用不可接受。OpenAI 已转向 GPT-4o-transcribe 云端 API,事实上放弃了 Whisper 的流式演进。
| 方案 | 真流式 | 延迟 | 并发能力 | Code-Switch | 生产成熟度 |
| FunASR 2-pass | 是 | 480–600ms | 16–100+ 路 | 受限 | 最高(阿里生产级) |
| Sherpa-ONNX | 是 | 中等 | 取决于硬件 | 是(bilingual 模型) | 高(跨平台验证) |
| Qwen3-ASR | 伪流式 | 92ms TTFT | 2000x 实时 | 是(52 语言) | 低(148 open issues) |
| Whisper | 否 | >=3.3s | N/A | 弱 | 不适用 |
| SenseVoice | 否(模拟) | 取决于分段 | N/A | 是(5 语言) | 中等 |
6.2 硬件需求一览
| 管线 | GPU VRAM | CPU-Only 可行性 | RTF (GPU) | RTF (CPU) |
| Paraformer-Large (FunASR, ONNX) | 1–2 GB | 优秀 | 0.008 | 0.05–0.1 |
| SenseVoice-Small (234M) | <1 GB | 可(含 Raspberry Pi) | <<0.01 | <0.1 |
| FireRedASR-AED (1.1B) | 4–6 GB | 慢(可用但不实用) | ~0.02 | >0.3 |
| Qwen3-ASR-1.7B | 6–8 GB | 不可行 | 0.015–0.13 | — |
| Whisper large-v3 (faster-whisper, FP16) | ~4.5 GB | 勉强可用 | 0.05–0.15 | 0.3–0.8 |
| Fun-ASR-Nano (0.8B) | 2–4 GB | 勉强可用 | 近实时 | — |
| FireRedASR2-LLM (8.3B) | >=32 GB (A100/A800 推荐) | 不可行 | — | — |
| Paraformer-v2 (220M, CTC) | — | 优秀 (i7 CPU 92s 音频 ~9s) | 0.009 | — |
关键发现:
- 1–2 GB VRAM 即可运行生产级中文 ASR:Paraformer-Large 和 SenseVoice-Small 在消费级 GPU 甚至 CPU 上即可实时运行,适合资源受限部署。
- 6–8 GB 是 LLM 级精度的入门门槛:Qwen3-ASR-1.7B 和 FireRedASR-AED 需要中端 GPU(如 T4/RTX 3060),但精度显著优于轻量模型。
- 32 GB+ 才能运行顶级模型:FireRedASR2-LLM (8.3B) 和 Fun-ASR API 背后的 7.7B 模型需要 A100/A800 级别 GPU,不适合个人开发者自建。
七、云服务市场与定价
中文 ASR 云服务定价跨度达 40 倍——从阿里百炼的 ¥0.288/小时到 AWS Transcribe 的 ¥10.37/小时。选型时价格、精度和功能三者缺一不可。本章以 ¥7.2/$1 汇率统一换算,数据截至 2026 年 4 月。
7.1 批量/文件识别定价
| 厂商 | 产品 | ¥/小时 | $/小时 | 免费额度 |
| 阿里百炼 | Fun-ASR / Paraformer-v2 | ¥0.288 | $0.04 | 90 天 credits |
| 火山引擎 | 标准录音 (50 万包) | ¥0.40 | $0.06 | 试用额度 |
| 百度 | 文件转写 (50 万包) | ¥0.60 | $0.08 | 200 万次免费 (~8,333 小时) |
| 火山引擎 | Doubao 录音 2.0 (30 万包) | ¥0.67 | $0.09 | 试用额度 |
| 腾讯 | 录音文件 (30 万包) | ¥0.70 | $0.10 | 10 小时/月 |
| 火山引擎 | LLM 录音 (非高峰) | ¥1.00 | $0.14 | 试用额度 |
| AssemblyAI | Universal-2 batch | ¥1.08 | $0.15 | $50 credits |
| OpenAI | GPT-4o Mini Transcribe | ¥1.30 | $0.18 | $5 credits |
| Deepgram | Nova-2 batch | ¥1.86 | $0.26 | $200 credits |
| OpenAI | Whisper-1 / GPT-4o Transcribe | ¥2.59 | $0.36 | $5 credits |
| 讯飞 | 长文本批量 | ¥4.90–9.90 | $0.68–1.38 | 50 小时 |
| AWS Transcribe | Standard (Tier 1) | ¥10.37 | $1.44 | 60 min/月 x 12 月 |
要点:百度的 200 万次免费调用(折合约 8,333 小时短音频)是测试和小规模使用的最佳入口。阿里百炼以 ¥0.288/小时的定价在批量和流式上同时领先,比第二梯队便宜 2–3 倍。
7.2 实时/流式定价
| 厂商 | 产品 | ¥/小时 | $/小时 |
| 阿里百炼 | Fun-ASR Realtime / Paraformer-v2 | ¥0.288 | $0.04 |
| 火山引擎 | Doubao 流式 2.0 (1K 包) | ¥0.90 | $0.13 |
| 腾讯 | 实时标准 (1K 包) | ¥1.80 | $0.25 |
| 百度 | 实时 ASR (按量付费) | ¥3.00 | $0.42 |
| 华为 | 实时 ASR | ¥3.20 | $0.44 |
| Azure | 实时 STT | ¥7.20 | $1.00 |
| 讯飞 | 实时转写 (20h 包) | ¥9.90 | $1.38 |
流式定价普遍高于批量定价,但阿里百炼是例外——批量和流式同价 ¥0.288/小时。火山引擎 Doubao 流式 2.0 以 ¥0.90/小时位居第二,对于需要 Seed-ASR 上下文感知能力的中英混发场景,是性价比最优的流式 API。
7.3 功能矩阵
| 特性 | 最佳厂商 | 备注 |
| Code-switching (中英混合) | 火山 Seed-ASR, 阿里 Fun-ASR, 讯飞, 智谱 GLM-ASR | Seed-ASR 具备上下文感知识别,v2.0 用 Function Call 策略专项优化 |
| 方言覆盖 | 腾讯 (27+ 方言), 讯飞 (20+), 火山 (13+) | 华为仅 3 方言,差距显著 |
| 说话人分离 | 阿里, 讯飞, 腾讯, Azure, 火山 | 百度的说话人分离能力受限 |
| 最大文件时长 | 阿里百炼 (12 小时), 华为/腾讯 (5 小时) | 阿里大幅领先 |
| 歌曲/演唱识别 | 阿里 Fun-ASR (云端 API) | 百炼 API 为商用 API 中唯一提供者 |
| 私有化部署 | 火山, 讯飞 | 数据敏感场景的唯一选项 |
7.4 数据驻留与隐私
大陆本地存储(默认合规):阿里云 / 百度 / 腾讯 / 火山引擎 / 讯飞 / 华为——全部默认将数据存储于中国大陆,符合中国数据保护法规。华为明确声明不留存处理数据,讯飞持有等保三级安全认证。
跨境合规(大陆区域可选):Azure China(21Vianet 运营)和 AWS China(北京/宁夏区域)提供完整的大陆数据驻留,适用于需要国际厂商品牌但数据不能出境的场景。
无中国区域(数据必须出境):Google Cloud / OpenAI / Deepgram / AssemblyAI——数据必须留在境内时,这四家直接排除。除非使用其自托管/开源模型在本地部署。
7.5 百炼"价格屠夫"策略分析
阿里百炼 ¥0.288/小时的定价在中国 ASR 市场中异常突出。批量和流式同价¥0.288/小时,比第二名(火山引擎标准录音 ¥0.40)低 30%,比百度(¥0.60)和腾讯(¥0.70)低约一半。这不是正常的市场竞争定价,而是战略性低价驱动平台采用的典型打法。
可持续性风险:此定价优势可能不持久。百炼作为阿里云大模型平台的入口,ASR 定价承担的是获客成本而非独立盈利指标。一旦市场份额达到目标或平台战略调整,价格存在上调空间。
7.6 百炼 Fun-ASR ≠ 开源 Paraformer:品牌同名,架构无关
| 维度 | 商用 Fun-ASR (百炼 API) | 开源 Paraformer-Large (FunASR 工具包) |
| 参数量 | 7.7B | 220M |
| 架构 | LLM 架构 (Qwen3 底座) | 非自回归 (NAR, CIF-based) |
| 训练数据 | 千万小时级 | ~60,000 小时 |
| AISHELL-1 CER | 1.64% | 1.68% |
| 真实世界 WER | 7.60% (内部工业评测) | ~11% (估算) |
| 方言 | 7 大方言 + 26 地方口音 | 有限 |
| 歌曲识别 | 支持 (opencpop CER 3.05%) | 不支持 |
35 倍参数差距,训练数据相差数个数量级。它们共享品牌名称但在架构上完全无关。当有人说"用 FunASR"时,必须区分是指开源工具包中的 Paraformer 系列,还是百炼平台上的商用 LLM 模型。
7.7 Doubao-ASR = Seed-ASR:产品确认与 v2.0 新特性
火山引擎的 Doubao ASR 产品与字节跳动研究院的 Seed-ASR 模型之间的关系已被三重确认:
- 产品命名:商用 API 名称为 "Doubao-Seed-ASR-2.0"
- 论文声明:Seed-ASR 论文明确指出该模型驱动 Doubao 的商用语音识别
- 内部标识:API resource ID 包含 "seedasr"
Seed-ASR v2.0(2025 年 12 月发布)的关键新特性:
- PPO 强化学习:通过 reinforcement learning 优化推理阶段的上下文推理能力
- 多模态视觉消歧:利用图像信息辅助同音词消歧(如通过屏幕截图区分"期"和"器")
- 外语扩展:新增 13 种外语支持
- 上下文感知识别:使用对话历史改善识别准确率,这是 V2EX 用户反馈中 Doubao "主观最佳"的核心原因
7.8 MiniMax ASR 缺位
MiniMax 在 TTS(文本转语音)领域排名全球第一——同时占据 Artificial Analysis Speech Arena 和 HuggingFace TTS Arena 榜首。但在 ASR 方面:官方开发者文档(platform.minimaxi.com)不暴露任何 ASR endpoint。MiniMax 自家 GitHub 上的同声传译 demo 使用 Whisper 作为 ASR 组件,而非自研模型。第三方调查表明其国际站宣传的"语音识别 API"本质上是 Whisper Large 的包装。
MiniMax 在 ASR 领域的缺位与其 TTS 领域的绝对统治形成鲜明对比。类似地,Moonshot/Kimi 无商用 ASR API,但其开源 Kimi-Audio-7B 在 AISHELL-1 上达到 0.60% WER(接近 SOTA)。新锐 AI 公司中唯一正式提供 ASR 产品的是智谱 AI,其 GLM-ASR / GLM-ASR-2512 云端 API 支持流式、8 种中国方言,并兼容 OpenAI SDK 接口。
八、自建 vs 云端经济学
自建与云端的选择本质上是一道经济学题——以运维成本换取计算成本的折扣率,以精度控制权换取部署便利性。
8.1 TCO 对比表
| 月用量 | Serverless GPU | 专用 T4 ($219/月) | 百炼 API (¥0.288/h) | 火山 Doubao 2.0 (¥0.75/h) | 讯飞 (¥2/h 套餐) |
| 100 小时 | ~$1 + 运维 | $219 (大量闲置) | ~¥29 ($4) | ~¥75 ($10) | ~¥200 ($28) |
| 1,000 小时 | ~$8 + 运维 | $219 | ~¥288 ($40) | ~¥750 ($104) | ~¥2,000 ($278) |
| 10,000 小时 | ~$77 + 运维 | $219 | ~¥2,880 ($400) | ~¥7,500 ($1,042) | ~¥20,000 ($2,778) |
- 100 小时/月:百炼 API 以 $4/月碾压所有方案。Serverless GPU 虽计算成本仅 $1,但加上运维开销远超 API。专用 T4 的 $219/月完全浪费。
- 1,000 小时/月:百炼 API $40/月仍然极具吸引力。Serverless GPU $8 + 运维 $200–500 开始与 API 持平或更贵。专用 T4 $219/月开始体现价值。
- 10,000 小时/月:自建方案碾压。Serverless GPU $77/月 + 运维 $200–500,是百炼的 0.7–1.4 倍但可选更高精度模型。专用 T4 $219/月固定成本,单价降至 $0.02/小时,是百炼的 1/20。
8.2 本地批处理性能估算
以 RTX 3090Ti (24GB VRAM) 处理 71 小时音频为基准,五种方案的预估表现:
| 方案 | 预估处理时间 | GPU VRAM 占用 |
| Vanilla Whisper large-v3 | ~71 小时 | 10 GB |
| faster-whisper large-v3 (FP16) | ~14–18 小时 | 5 GB |
| faster-whisper large-v3-turbo | ~8–12 小时 | 3–5 GB |
| WhisperX batched (large-v3) | ~2.5–3.5 小时 | <8 GB |
| FunASR Paraformer-Large | ~6 小时 | 1–2 GB |
电费估算:350W 功耗 x 3–18 小时 @ $0.15/kWh = $0.20–$1.00。
对应云 API 成本(处理相同 71 小时音频):
| 云服务 | 费用 |
| 阿里百炼 | ~¥20 ($2.84) |
| AssemblyAI | ~$10.65 |
| Deepgram | ~$18–33 |
| Google Cloud | ~$68 |
| AWS Transcribe | ~$102 |
8.3 成本交叉点分析
第一阶梯:<500 小时/月——云端 API 胜出
百炼 API 成本 <¥144 ($20)/月,低于任何自建方案的运维开销底线 ($200/月)。此区间内:用百炼 Fun-ASR API(¥0.288/小时)是最优解。零运维、零硬件投资、即用即走。且商用 Fun-ASR (7.7B) 的精度优于自建 Paraformer-Large (220M)。
第二阶梯:500–1,000 小时/月——转折区间
百炼 API 成本 ¥144–288 ($20–40)/月。Serverless GPU 计算成本 $4–8/月 + 运维 $200–500/月。此区间的决策取决于运维团队成本:如果有专职 DevOps(运维成本为沉没成本),自建开始划算;如果运维需要额外雇人或占用开发者时间,API 仍占优。
第三阶梯:>1,000 小时/月——自建碾压
百炼 API $40+/月且线性增长。专用 T4 $219/月固定成本,处理能力远超 1,000 小时。自建节省 5–18 倍计算成本。且可选择更高精度的开源模型(如 FireRedASR-AED 1.1B,CER 较 Paraformer 降低约 30%)。
混合策略建议:对于中等用量(500–2,000 小时/月),最优方案可能是混合部署:日常用百炼 API 处理流式和低延迟需求(¥0.288/小时),批量任务用自建 FireRedASR-AED(1.1B, 4–6 GB VRAM)处理,中英混发场景补充火山 Doubao 2.0 流式 API(¥0.90/小时),利用 Seed-ASR 的上下文感知能力。
九、典型失败模式与系统局限性
ASR 系统的选型不能只看精度排行榜。任何一个在基准测试上表现优异的模型,一旦投入生产环境,都会暴露出各自独特的失败模式。
9.1 Whisper 的"幻觉"危机
问题规模
"Careless Whisper" 研究(ACM FAccT 2024)对 Whisper 的幻觉问题进行了迄今最系统的量化分析。核心发现:约 1% 的音频片段会产生完全捏造的文本——不是误识别个别词语,而是生成与原始音频毫无关联的完整句子。更令人警惕的是,在这些幻觉输出中,38% 包含有害内容,涵盖暴力引用、种族评论和虚假医学术语。作为对照,该研究在相同音频上测试了 Google、Amazon、AssemblyAI 和 Rev.ai——没有任何一家产生类似的系统性幻觉。
根因分析
Whisper 幻觉的根因在于其自回归解码器架构(autoregressive decoder)。Barański et al.(ICASSP 2025)的研究揭示了两个关键机制:
- 非语音音频的错误转录:当输入为纯噪声、静音或环境音时,Whisper large-v3 会将 55.2% 的非语音片段转录为 "so",而非正确地输出空文本。
- YouTube 训练数据伪影:Whisper 在 680,000 小时的互联网音频(大量来自 YouTube)上训练,导致常见幻觉包括 "thanks for watching"、"subtitles by the Amara.org community" 等字幕模板文本。
Calm-Whisper:精准定位与靶向修复
Calm-Whisper(2025 年 5 月)的研究提供了一个精妙的诊断与修复方案。研究者发现,Whisper 解码器的 20 个注意力头中,仅 3 个头引起了超过 75% 的幻觉。基于此发现,对这 3 个头进行靶向微调,可以实现:幻觉减少 80%,WER 退化 < 0.1%。这是一个极具工程价值的结论——不需要重新训练整个模型,只需精准干预极少量参数即可大幅缓解幻觉问题。
缓解策略清单
| 策略 | 机制 | 有效性 | 实施成本 |
| VAD 预处理 (Silero VAD / pyannote) | 剥离输入中的静音和非语音段,消除幻觉的主要触发条件 | 最高 | 极低,3 行代码集成 |
| WhisperX 默认配置 | 设置 condition_on_prev_text=False,使用 VAD 分段,切断解码链级联 | 高 | 低,切换推理框架 |
| faster-whisper 参数 | hallucination_silence_threshold 参数 + Silero VAD 集成,自动过滤可疑输出 | 高 | 低,调整参数 |
| Calm-Whisper 微调 | 靶向微调 3 个幻觉注意力头 | 高(减 80%) | 中,需微调流程 |
| NAR 模型替代 | FunASR Paraformer、NVIDIA Parakeet 等非自回归模型,架构上天然免疫 | 根治 | 需切换模型 |
关键结论:如果业务场景无法容忍任何幻觉风险(如医疗转录、法律记录),应直接选用非自回归(NAR)架构的模型。VAD 预处理能显著缓解但无法根治自回归解码器的固有问题。对于仍在使用 Whisper 的管线,永远不要将包含大段静音的原始音频直接送入模型。
9.2 四大系统特有 Bug
FireRedASR2:精度天花板下的工程硬伤
FireRedASR2 在 AISHELL-1 上以 0.57% CER(AED 变体)刷新了开源精度纪录,但其工程成熟度与学术精度之间存在显著落差。AED 变体的硬性约束是 60 秒最大输入长度。这不是一个"性能会下降"的软限制,而是会导致两种严重后果:超过 60 秒模型开始产生幻觉,超过 200 秒触发位置编码溢出错误直接崩溃。v2 版本引入了 FireRedVAD 管线来自动切分长音频,但在 VAD 切分不准确的场景下(如连续长对话、背景音乐混合语音),仍有触发限制的风险。
| 变体 | GPU VRAM | 磁盘空间 | 推荐硬件 |
| FireRedASR2-AED (1B+) | 4-6 GB | 适中 | 消费级 GPU |
| FireRedASR2-LLM (8B+) | >=32 GB | ~21 GB | A100 / A800 |
Qwen3-ASR-1.7B:多语言覆盖下的稳定性隐患
无限 Token 重复(GitHub Issue #129):模型在特定音频输入上会陷入无限重复循环,反复生成相同的短语或 token 数千次,直到达到最大序列长度。该问题在 GitHub 上被多个用户独立报告,截至 2026 年 4 月尚无官方修复。Qwen3-ASR 的流式模式为伪流式——每个 2 秒的音频块从零开始独立处理,没有跨段上下文传递,导致边界重复转录和格式泄漏两个实际问题。截至 2026 年 4 月,Qwen3-ASR 在 GitHub 上有约 148 个未关闭的 Issue。
Alibaba Bailian / FunASR:生态成熟度与代码质量的反差
- FunASR 包导入性能问题:FunASR Python 包的首次导入耗时超过 1 分钟,原因是依赖加载链过长。对于需要频繁启动推理进程的场景(如 serverless 函数、CI/CD 管线),这一冷启动时间是不可接受的。
- 热词参数静默忽略:在 FunASR 的 WebSocket 服务端中,通过 API 传入的热词参数会被静默忽略,不产生任何错误提示。这是最危险的 bug 类型之一——开发者认为热词功能在工作,实际上完全没有生效。
- 时间戳数组不匹配:Alibaba Bailian API 的 GitHub 上报告了多个对齐 bug:字符数与时间戳计数不匹配、结尾时间截断(end-time cutoff)。这些 bug 对于需要精准时间戳的应用(如字幕生成、音视频同步编辑)影响尤为严重。
Doubao-ASR:闭源围墙内的精度落差
Doubao-ASR 是四大系统中唯一完全闭源、仅提供 API 的方案,没有自部署选项。注册火山引擎账号需要中国大陆手机号和实名认证(身份证验证),对国际开发者构成了刚性壁垒。
| 基准 | Seed-ASR 论文 | Doubao-ASR API 实测 |
| AISHELL-1 CER | 0.68% | 1.52% |
| LibriSpeech-other WER | 2.84% | 5.69% |
尽管字节跳动拥有海量语音数据(来自抖音、飞书等产品),Doubao-ASR 在方言识别上的表现却出人意料地差:方言平均 CER 15.39%,比最佳系统高出 33%,在上海话对话场景下甚至达到 45% CER。这一短板在需要覆盖方言用户的场景中是一个关键的排除因素。
9.3 失败模式速查矩阵
| 系统 | 最致命 Bug | 触发条件 | 影响程度 | 规避方案 |
| Whisper | 幻觉:捏造完整句子 | 静音/非语音输入 | ~1% 片段,38% 有害 | VAD 预处理 / 切换 NAR 模型 |
| FireRedASR2 | 超时长崩溃 | 输入 > 200 秒 | 进程终止 | FireRedVAD 自动切分 / 控制输入长度 |
| Qwen3-ASR | 无限 token 重复 | 特定音频模式 | 输出完全不可用 | 设置 max_length / 输出长度检测 |
| FunASR | 热词静默失效 | WebSocket 服务端 | 功能不生效但无告警 | HTTP API 替代 / 日志验证 |
| Doubao-ASR | API vs 论文精度落差 | 所有输入 | CER 翻倍 | 以 API 实测数据为准 |
十、扩展应用——双语转录知识库的向量检索
将 ASR 转录的文本转化为可检索的知识库,是语音数据价值变现的关键一步。本章聚焦于 embedding 模型选型、中英混合文本的检索陷阱,以及面向 200 小时转录规模的最佳实践配置。
10.1 Embedding 模型评测逆转
2025-2026 年 embedding 模型领域发生了一次深刻的格局颠覆:开源模型全面超越商业 API,曾经的王者 OpenAI 跌落至中游位置。
| 模型 | 类型 | MTEB/MMTEB 分数 | 维度 | 最大 Token | 价格 (/MTok) |
| Qwen3-Embedding-8B | 开源 | 70.58 (MMTEB) | 32-7,168 | 32K | 免费 |
| Gemini Embedding 001/2 | 云端 API | 68.32 | 3,072 | 2K-32K | $0.15 |
| Voyage voyage-3-large | 云端 API | 66.80 | 2,048 | 32K | $0.18 |
| Cohere embed-v4 | 云端 API | ~65.2 | 1,024 | 128K | $0.12 |
| OpenAI text-embedding-3-large | 云端 API | 64.6 | 3,072 | 8K | $0.13 |
| Qwen3-Embedding-0.6B | 开源 | 64.33 (MMTEB) | 32-1,024 | 32K | 免费 |
| BGE-M3 | 开源 | ~63.0 | 1,024 | 8K | 免费 |
- Qwen3-Embedding-8B(阿里)以 70.58 分登顶 MMTEB 多语言排行榜 #1,同时在 MTEB English v2 上达到 75.22 分
- OpenAI text-embedding-3-large 以 64.6 分跌至约 #9 的位置——18 个月前它还是无可争议的行业标准
- Gemini Embedding 001/2 以 68.32 分位居商业 API 之首,跨语言检索能力 (R@1 0.997) 几乎完美
- BGE-M3 其独特的混合 dense + sparse + multi-vector 检索能力使其在包含专有名词和精确短语的技术文本中具有独特优势
10.2 中英混合文本的检索陷阱
双语转录知识库面临一个根本性挑战:ASR 转录的文本天然包含中英混合内容(code-switching),例如"我们用 transformer 做的这个 API 有三个 endpoint"。如果 embedding 模型无法理解这种混合文本,检索质量将断崖式下跌。
CCKM 基准:二元分裂
CCKM 基准(166 个中英平行对,包含困难负样本)揭示了 embedding 模型世界的一条分水岭——模型要么能处理中英混合,要么完全不能,几乎不存在中间地带:
顶级多语言模型(跨语言 R@1 > 0.93):
| 模型 | 跨语言 R@1 |
| Gemini Embedding 2 | 0.997 |
| Qwen3-Embedding-8B | 0.988 |
| BGE-M3 | 0.940 |
完全失效的纯英文模型(跨语言 R@1 接近零):
| 模型 | 跨语言 R@1 |
| Nomic Embed | 0.12 |
| Stella (English-only) | 接近零 |
| mxbai-embed-large | 0.16 |
这些纯英文模型完全无法处理中文文本,必须在选型阶段直接排除。将它们用于中英混合转录文本的知识库,等同于在检索层引入一个随机数生成器。
Code-Switching 处理原则:对于包含中英混合的转录文本,正确的处理方式是保持原样嵌入,不做语言分离。现代多语言 embedding 模型(Qwen3、Gemini、BGE-M3)在训练时已经处理了大量 code-switching 数据,能够在统一的向量空间中编码混合语言内容。人为分离反而会破坏语义完整性。
10.3 最佳实践配置(200 小时转录)
分块策略
推荐方案:语义/主题分块,目标 256-512 token 每 chunk,30-50 token overlap。
| 分块方式 | 检索准确率 |
| 主题对齐分块(semantic/topic-aligned) | 87% |
| 固定大小分块(fixed-size) | 13% |
87% vs 13% 的差距表明,分块策略对最终检索质量的影响远大于 embedding 模型的选择。
维度:全分辨率,不截断
| 维度配置 | 存储需求 (30K chunks) |
| 1,024 维 (BGE-M3, Cohere) | ~120 MB |
| 3,072 维 (OpenAI, Gemini) | ~360 MB |
| 7,168 维 (Qwen3 最大) | ~840 MB |
即使使用最高维度配置,存储量也不到 1 GB。Matryoshka 维度压缩在此规模下毫无意义——节省几十 MB 存储空间不值得牺牲任何检索精度。结论明确:使用全维度,不做截断。
成本测算
200 小时的密集转录文本约合 500 万 token。
| 服务商 | 模型 | 总成本 |
| OpenAI | text-embedding-3-small | $0.10 |
| Voyage AI | voyage-3.5 | $0.30 |
| Cohere | embed-v4 | $0.60 |
| Gemini Embedding | $0.75-$1.00 | |
| 自建 | Qwen3-Embedding-8B (A100, ~1h) | $1-$3 |
| 自建 | BGE-M3 (CPU, ~2h) | $0 |
成本是一个完全不需要考虑的因素。即使选择最贵的方案,对整个语料库进行一次完整 embedding 的成本也不超过 $3。选型应完全基于检索质量。
10.4 模型选择决策树
路径一:云端简单方案 → 推荐 Gemini Embedding 2
跨语言 R@1:0.997(近乎完美),上下文窗口:32K token,维度:3,072,总成本:< $1。跨语言检索能力最强,无需任何基础设施投入,32K 上下文窗口足以容纳长 chunk。唯一限制是对 Google 生态的依赖。
路径二:自建 GPU 最强方案 → 推荐 Qwen3-Embedding-8B + Qwen3-Reranker-8B
MMTEB 多语言排名:#1(70.58 分),许可证:Apache 2.0,上下文窗口:32K token,维度:32-7,168(Matryoshka 可调),硬件需求:~16 GB VRAM(4-6 GB 量化后)。绝对精度最高,中英文均为阿里的核心优化方向,配合同族 Reranker 实现最优的两阶段检索管线。
路径三:自建 CPU 轻量方案 → 推荐 BGE-M3
参数量:568M,许可证:MIT,部署:CPU 可运行,跨语言 R@1:0.940。独特优势:混合 dense + sparse + multi-vector 检索——sparse 检索补偿 dense 向量在低频精确匹配上的不足,对转录文本中的技术术语、专有名词和精确短语尤其有价值。
路径四:零分块极简方案 → 推荐 Cohere embed-v4
上下文窗口:128K token,维度:1,024。128K 的上下文窗口可以将整段视频转录作为单个文档嵌入,完全跳过分块步骤。适合快速搭建原型或对分块策略没有工程投入意愿的场景。代价是检索粒度较粗——无法定位到具体段落。
十一、场景化选型与落地建议
场景一:纯中文、极高精度的离线批量处理
典型需求:大量中文音视频素材的批量转录,对 CER 要求极致,不要求实时,可接受较长处理时间。
自建首选——FireRedASR2-AED + FireRedVAD + FireRedPunc:这是当前开源精度天花板方案。FireRedASR2-AED 在 AISHELL-1 上达到 0.57% CER,四基准均值 3.05%,较 Paraformer-Large 的 1.68% / 4.56% 实现了 67% / 33% 的 CER 降低。v2 版本集成 VAD + 语言识别 + 标点恢复,一体化管线无需额外组件。硬件需求:4–6GB VRAM(AED 变体),3090Ti 绰绰有余。注意 60 秒输入长度限制,需配合 FireRedVAD 做精细分段。
云端首选——阿里百炼 Fun-ASR API:¥0.288/小时,商用 Fun-ASR (7.7B LLM) 在真实世界评测中达到 7.60% 平均 WER,显著优于开源 Paraformer-Large。零运维、零硬件,<500 小时/月用量下的最优解。支持 12 小时长文件、热词定制、歌曲识别。
资源受限替代——SenseVoice-Small:234M 参数,<1GB VRAM,Raspberry Pi 可运行。AISHELL-1 CER 2.96%——仍优于 Whisper large-v3 的 5.14%,且模型体积仅为后者 1/6。内置标点、情绪和音频事件检测。注意:百炼平台已标记"即将下线"。
最大精度不计成本——FireRedASR2-LLM (8B+):四基准均值 2.89%,当前绝对 SOTA。需 ≥32GB VRAM (A100/A800)。适合研究机构或对精度有极致要求的商业场景。
场景二:中英混发、实时流式识别
典型需求:同声传译、实时会议纪要、语音输入,要求亚秒级延迟,内容包含中英混合。
开源前沿——Qwen3-ASR-1.7B + Silero VAD:52 语言原生流式,2 秒分块,TTFT 92ms。中英 code-switching 表现优秀(40K+ 英文关键词合成训练数据)。6–8GB VRAM。注意伪流式问题(边界重复)和无限重复 Bug (#129),生产部署前需充分测试。
生产级稳定——FunASR 2-pass + FSMN-VAD + CT-Punc:阿里生产级验证,480–600ms 声学延迟,4vCPU/8GB 支持 16 路并发。生态最成熟:Docker 部署、WebSocket 服务端、热词定制。Code-switching 支持受限于离线变体,纯流式中英能力不如 Qwen3-ASR。
云端首选——火山 Doubao 2.0 Streaming:Seed-ASR 上下文感知技术,¥0.90/小时。主观体验四系统最佳(V2EX 用户长期反馈)。v2.0 PPO 强化学习 + 多模态消歧。注意需中国手机号注册。
边缘/嵌入式——Sherpa-ONNX + streaming-zipformer-bilingual-zh-en:CPU-only,12 种语言绑定,Android/iOS/RPi 全平台。精度低于上述方案但部署灵活性无可替代。
场景三:低成本双语播客字幕生成(CLI 批处理)
典型需求:个人开发者或小团队,批量处理中英双语播客生成 SRT 字幕,3090Ti 本地部署,成本极致。
双引擎架构:
- 中文管线:FunASR Paraformer-Large(paraformer-zh + fsmn-vad + ct-punc),单命令处理 VAD + 转录 + 标点 + 时间戳。1–2GB VRAM,12× 实时,71 小时音频约 6 小时处理
- 英文管线:WhisperX(faster-whisper large-v3-turbo + Silero VAD + wav2vec2 对齐),批量推理 60–70× 实时,词级时间戳远优于原生 Whisper。3–5GB VRAM,71 小时音频约 2–4 小时处理
成本:350W × 3–18 小时 @ $0.15/kWh = $0.20–$1.00 电费。同等量云 API:AssemblyAI $10.65、Deepgram $18–33、AWS $102。
场景四:纯英文"开箱即用"生产级方案
典型需求:出海业务、英文内容平台,需要单次 API 调用解决转录全流程。
- 精度王——ElevenLabs Scribe v2:2.3% WER,$0.40/小时。32 说话人分离、词级时间戳、音频事件标注(笑声/掌声)。适合对精度有极致要求的场景。
- All-in-one——AssemblyAI Universal-3 Pro 或 Gladia Solaria-1:AssemblyAI 3.3% WER / $0.21/小时,Speech Understanding API 含转录 + 摘要 + 主题 + 情感,但加价叠加可达 2–5× 基价。Gladia 4.2% WER / $0.50/小时固定价(无加价),含语义分章 + NER + 翻译 + 99 语言 code-switching——功能最完整的单 API。
- 极致性价比——Deepgram Nova-3:5.4% WER / $0.26/小时,130–473× 实时。词时间戳 + 说话人 + 标点 + PII 脱敏全包,无加价。速度和价格双冠。
场景五:超大体量极简降本
典型需求:海量音频处理,成本最敏感,可接受非 SOTA 精度。
- 端侧 CPU——SenseVoice-Small:234M 参数,CPU 直接处理,去管线依赖。内置标点 + 情绪 + 事件,AISHELL-1 CER 2.96%
- CPU-only 部署——Paraformer-v2 (220M):RTF 0.05–0.1 (CPU),i7 处理 92 秒音频约 9 秒。1GB VRAM
- 最大吞吐——Qwen3-ASR-0.6B:2000× 实时(concurrency 128),适合大规模并发处理
嵌入选型速查
| 需求 | 推荐方案 | 理由 |
| 双语嵌入(自建 GPU) | Qwen3-Embedding-8B + Qwen3-Reranker-8B | MMTEB #1,Apache 2.0,中英 R@1 0.988 |
| 双语嵌入(云端) | Gemini Embedding 2 | 跨语言 R@1 0.997,32K 上下文,<$1 总成本 |
| 双语嵌入(CPU 自建) | BGE-M3 | 568M CPU 可跑,MIT,混合检索对专名有优势 |
| 零分块长文本 | Cohere embed-v4 | 128K 上下文,跳过分块步骤 |
十二、结论
五个核心洞察
1. Whisper 的统治地位取决于语言。 英文场景下 Whisper large-v3-turbo (4.8% WER) 仍是合理的本地方案,生态无出其右。但在中文场景下,Whisper 的 CER 是专用模型的 2–10 倍(AISHELL-1 5.14% vs FireRedASR2-AED 0.57%),WenetSpeech Meeting 上的 18.87% 与 FireRedASR2-LLM 的 4.32% 已是代际差距。中文 ASR 不应再以 Whisper 为基线。
2. 幻觉不是脚注,是架构性缺陷。 ACM FAccT 2024 研究证实 ~1% 的音频片段会被 Whisper 转录为完全捏造的文本,38% 含有害内容。这不是个别 bug,而是自回归解码器的固有问题——55.2% 的非语音被转录为 "so"。非自回归模型(Paraformer、Parakeet)从架构上免疫此类幻觉。对转录准确性有刚性要求的场景(医疗、法律、字幕发布)应优先选择 NAR 架构。
3. 本地推理经济学对批量任务碾压云端。 3090Ti 处理 71 小时播客的电费为 $0.20–$1.00,同等量 AWS Transcribe 需 $102——差距超过 100 倍。即便与最便宜的云 API(百炼 ¥0.288/h ≈ $2.84/71h)相比,本地方案仍有 3–14 倍成本优势。月用量超过 1000 小时时,自建节省 5–18× 计算成本。
4. "API 与论文"差距是选型的隐性风险。 Seed-ASR 论文报告 AISHELL-1 CER 0.68%,商用 API 实测 1.52%。百炼 Fun-ASR API (7.7B) 与开源 Paraformer (220M) 共享品牌名但架构完全无关(35× 参数差距)。不能将论文数字等同于生产性能,不能将品牌名等同于技术方案。
5. 开源 Embedding 已超越商业 API。 Qwen3-Embedding-8B 以 70.58 分登顶 MMTEB 多语言排行榜,OpenAI text-embedding-3-large 以 64.6 分跌至 ~#9。200 小时转录的全量嵌入成本 <$1,模型质量成为唯一决策因素。纯英文模型(Nomic 0.12、mxbai 0.16)完全无法处理中文,必须在选型阶段排除。
行动建议
- <500 小时/月:使用阿里百炼 Fun-ASR API(¥0.288/h),零运维即用即走,精度优于自建 Paraformer
- >1000 小时/月:自建 FireRedASR-AED(1.1B, 4–6GB VRAM),CER 较 Paraformer 降低 ~67%
- 中英混发流式:补充火山 Doubao 2.0 Streaming(¥0.90/h)利用 Seed-ASR 上下文感知能力
- 英文批量本地:WhisperX(faster-whisper turbo + wav2vec2 对齐),生态最成熟,3090Ti 处理 71h 仅需 2.5–3.5h
- 双语知识库:Qwen3-Embedding-8B 自建或 Gemini Embedding 2 云端,语义分块 256–512 token,两阶段 retrieve-then-rerank
附录
A. SRT 生成 CLI 工具
| 工具 | 技术栈 | 核心特性 |
| whisply | faster-whisper + WhisperX | 跨平台 CLI,--export srt,字幕长度控制 |
| VideoCaptioner | Whisper + LLM 分句 | 最接近 CapCut 的开源质量,LLM 驱动的智能分句 |
| FunClip(阿里) | Paraformer | 自动 SRT 生成 + 热词支持 |
| AsrTools(2.6k stars) | CapCut/B站/快手逆向 API | 无需 GPU,云端 CapCut 级别质量,法律灰色地带 |
| Subtitle Edit | 7 个 Whisper 引擎 | GUI/CLI,推荐 faster-whisper-XXL + large-v3-turbo |
B. 完整基准数据表(来源:FireRedASR2S arXiv:2603.10420)
| 模型 | 参数 | AISHELL-1 | AISHELL-2 | WNet Net | WNet Meeting | 四基准均值 | 方言均值 | 歌曲 |
| FireRedASR2-LLM | 8B+ | 0.64 | 2.15 | 4.44 | 4.32 | 2.89 | 11.55 | 1.12 |
| FireRedASR2-AED | 1B+ | 0.57 | 2.51 | 4.57 | 4.53 | 3.05 | 11.67 | 1.17 |
| Doubao-ASR API | 闭源 | 1.52 | 2.77 | 5.73 | 4.74 | 3.69 | 15.39 | 4.36 |
| Qwen3-ASR-1.7B | 1.7B | 1.48 | 2.71 | 4.97 | 5.88 | 3.76 | 11.85 | 2.57 |
| Fun-ASR API | 7.7B | 1.64 | 2.38 | 6.85 | 5.78 | 4.16 | 12.76 | 3.05 |
| Fun-ASR-Nano | 0.8B | 1.96 | 3.02 | 6.93 | 6.29 | 4.55 | 15.07 | 2.95 |
| Paraformer-Large | 0.22B | 1.68 | 2.85 | 6.74 | 6.97 | ~4.56 | — | — |
| SenseVoice-Small | 0.23B | 2.96 | 3.80 | 7.84 | 7.44 | — | — | — |
| SenseVoice-Large | 1.6B | 2.09 | 3.04 | 6.01 | 6.73 | — | — | — |
| Whisper large-v3 | 1.55B | 5.14 | 4.96 | 10.48 | 18.87 | ~9.86 | — | — |
C. 参考文献
- FireRedASR2S Technical Report. arXiv:2603.10420, March 2026.
- Seed-ASR: Understanding Diverse Speech and Contexts. arXiv:2407.04675, July 2024.
- Fun-ASR Technical Report. Alibaba Tongyi Lab, September 2025.
- Koenecke, A. et al. "Careless Whisper: Speech-to-Text Hallucination Harms." ACM FAccT 2024.
- Calm-Whisper: Targeted Decoder Head Fine-tuning for Hallucination Reduction. May 2025.
- Barański, K. et al. "Hallucination Patterns in Whisper." ICASSP 2025.
- Artificial Analysis. AA-WER v2.0 Benchmark (41 models, 3 datasets).
- MTEB / MMTEB Embedding Leaderboard. HuggingFace, 2026.
- CCKM Cross-lingual Embedding Benchmark (166 Chinese-English parallel pairs).
- VoiceWriter Independent ASR Comparison (clean/noisy/accented/specialist audio).
关于作者
靳若琦 (Ruoqi Jin),33 岁,13 年影视后期从业经历,交付 100+ 商业项目(华为/麦当劳/阿玛尼/乐高/兰蔻等)。2024 年起自学 Rust、编译器与分布式系统,构建确定性编译器后端约束 LLM 代码生成。
研究方向:形式化架构声明(Forge,arXiv:2604.13108)、神经符号代码生成(Neural-Codegen,Zenodo DOI: 10.5281/zenodo.19372158)、多 Agent 编排系统(MissionD,111K 行 Rust)。PCEA 理事会成员。
论文: arxiv.org/abs/2604.13108
代码: github.com/RuoqiJin
网站: ruoqijin.com
微信: Jinstudio626