从 Whisper 到 Faster-Whisper：构建一个支持 100+ 语言的 MP3 转文字系统

近两年，Speech-to-Text（语音识别）模型的发展速度非常快。

以前要实现一套可用的语音转文字系统，通常需要购买商业 API，例如 Google Speech、Azure Speech 或 Amazon Transcribe。而现在，随着 Whisper、Faster-Whisper、SenseVoice 等模型的发展，本地部署已经成为越来越多团队的选择。

最近我们也搭建了一套完整的 MP3 转文字服务，在这个过程中踩了不少坑，这里分享一些实际经验。

---

为什么没有直接调用商业 API？

商业 API 的优点非常明显：

• 开箱即用
• 稳定
• 无需维护 GPU
• 支持实时识别

但对于长音频来说，成本会快速上升。

另外还有几个问题：

• 上传速度受网络影响
• 部分数据涉及隐私
• 可定制能力有限
• 很难针对特定场景优化

因此最终还是选择了自部署方案。

---

为什么选择 Faster-Whisper？

Whisper 官方模型识别效果很好，但推理速度并不理想。

后来切换到了 Faster-Whisper，主要原因包括：

• 基于 CTranslate2
• GPU 利用率更高
• 内存占用更低
• 支持 INT8、FP16 等量化
• 长音频速度提升明显

对于 SaaS 产品来说，这一点尤为重要。

同样一块 GPU，可以处理更多任务。

---

长音频不能一次全部送进模型

很多人在第一次接触 Whisper 时，会直接把几个小时的音频全部送进去。

实际上这样做有很多问题：

• GPU 显存压力大
• 推理时间过长
• 出错后需要重新开始
• 无法实时反馈进度

因此通常都会采用 Chunk 的方式。

例如：

• 每段 30 秒
• 或者 60 秒
• 根据静音位置自动切分

这样既能提高稳定性，也方便并行处理。

---

VAD 比固定切片更重要

如果直接每 30 秒切一刀，很容易把一句话切成两半。

因此一般都会增加 VAD（Voice Activity Detection）。

流程大概如下：

 

Audio

↓

VAD

↓

Speech Segment

↓

Whisper

↓

Merge

 

这样模型拿到的基本都是完整句子。

识别准确率也会更高。

---

Speaker Diarization 让结果更容易阅读

对于采访、会议、播客来说，仅仅生成文字是不够的。

更好的做法是增加 Speaker Diarization（说话人分离）。

最终输出类似：

 

Speaker A

今天讨论一下产品规划。

Speaker B

好的，我们先看一下数据。

Speaker A

......

 

这样阅读体验会提升很多。

---

时间轴十分重要

很多开发者只输出文本。

实际上，时间戳才是真正有价值的数据。

例如：

 

00:01

Hello everyone.

00:05

Welcome to today's meeting.

00:10

......

 

时间轴可以直接用于：

• 字幕
• 视频剪辑
• 搜索定位
• 播放同步
• AI 摘要

所以建议保留每一句的开始时间和结束时间。

---

导出格式最好不要只有 TXT

实际项目中常见的导出格式包括：

• TXT
• DOCX
• PDF
• SRT
• VTT
• JSON

不同用户的需求差异很大。

例如：

视频创作者通常需要字幕；

开发者更喜欢 JSON；

普通用户可能更习惯 Word 或 PDF。

---

GPU 并不是最大的瓶颈

很多人认为 GPU 决定了整体速度。

实际上部署之后发现：

真正耗时往往来自：

• 文件上传
• 音频解码
• 队列等待
• FFmpeg 处理
• 下载结果

模型推理只是其中的一部分。

如果想提高整体体验，更应该优化整个处理流水线，而不是只关注模型本身。

---

总结

现在开源 Speech-to-Text 技术已经非常成熟。

对于大多数 SaaS 产品来说，一套完整的方案通常包括：

• Faster-Whisper 负责语音识别
• VAD 负责切分语音
• Speaker Diarization 负责说话人识别
• FFmpeg 负责音频处理
• 多格式导出满足不同场景
• 队列系统负责并发调度

真正决定用户体验的，并不是某一个模型，而是整个工程化流程。

为了方便测试和验证这些能力，我们将这套流程封装成了一个在线工具，支持上传 MP3、WAV、M4A 等常见音频格式，并生成带时间轴的转录结果，有兴趣的话可以体验一下：

MP3转文本