Faster-Whisper 实测：同一个 Whisper，为什么它的语音转录能快 4 倍？

Faster-Whisper 实测：同一个 Whisper，为什么它的语音转录能快 4 倍？

【免费下载链接】faster-whisperFaster Whisper transcription with CTranslate2项目地址: https://gitcode.com/GitHub_Trending/fa/faster-whisper

刚录完一场三小时的播客，文件躺在桌面上，你需要把它转写成文字稿。用 OpenAI 原版 Whisper 在显卡上跑，13 分钟的音频要 2 分 23 秒——这个速度对长音频基本没法忍。Faster-Whisper 就是干这事的：它基于 CTranslate2 推理引擎重新实现了 Whisper 模型，用更少的内存、最高快 4 倍的速度完成同样的语音转录任务。

它到底是什么

简单说：SYSTRAN 团队维护的一个开源库，把原版 Whisper 的 PyTorch 推理引擎整个换成了 CTranslate2——一个专门为 Transformer 模型推理加速的 C++ 引擎。模型权重没变，还是你熟悉的那套 Whisper（large-v3、distil-large-v3 都能直接加载），变的只是"跑推理的那台发动机"。附带一个很省心的细节：不用单独装 FFmpeg，音频解码靠它捆绑的 PyAV 库直接搞定。

为什么这么快 ⚡

三个关键点，每个都比原版快在明处：

1. 引擎替换。原版 Whisper 用 PyTorch 跑推理，算子调用、内存布局都有不少开销；CTranslate2 针对 Transformer 做了算子融合和显存排布优化，单段解码本身就更快。

2. 8 位量化。原版权重全精度存储；它一行参数就能切到 int8，内存占用近乎减半，速度还涨，基准测试里精度基本不掉。

3. 批量推理。这是拉开差距的大头。Whisper 本来就是按 30 秒一段切片处理音频的，batch_size参数让 GPU 同时解多段。同样的 large-v2 模型，从 1 分 03 秒压到 17 秒，靠的就是这个。

from faster_whisper import WhisperModel # GPU：FP16 是默认选择；INT8 更省显存 model = WhisperModel("large-v3", device="cuda", compute_type="float16") # CPU：INT8 量化，内存和速度兼顾 # model = WhisperModel("large-v3", device="cpu", compute_type="int8")

这段就是全部的核心配置：换device和compute_type两个参数，GPU 和 CPU 的部署就都覆盖了。

上手只需几分钟

先安装，一条命令，PyPI 直接装：

pip install faster-whisper

然后是完整的最小可跑路径：

import faster_whisper model = faster_whisper.WhisperModel("base", device="cpu", compute_type="int8") # 最小模型 + INT8，先试跑 segments, info = model.transcribe("audio.mp3") # 返回的是生成器，还没开始转 print("检测到语言:", info.language, round(info.language_probability, 2)) # 自动检测语种 for seg in segments: # 开始迭代，转录此刻才真正执行 print(f"[{seg.start:.1f}s -> {seg.end:.1f}s] {seg.text}")

GPU 用户把device="cuda"、compute_type="float16"换上去就行，其他代码一字不改；CPU 用户保持int8，再视情况加cpu_threads指定物理核心数。

实测数据说话

以下数据全部引自仓库 README.md 的 Benchmark 章节：GPU 在 NVIDIA RTX 3070 Ti（CUDA 12.4）上测，CPU 在 i7-12700K 8 线程上测，音频均为 13 分钟。

GPU 组（large-v2 模型）：

CPU 组（small 模型）：

最值得看的数字是 GPU 组的 16 秒：13 分钟音频 16 秒跑完，约 49 倍实时，显存 4500MB 意味着 8GB 卡能稳稳跑 large 级别模型。不开批处理的话，int8 的 2926MB 也比原版少了近 40% 显存——对小显存显卡来说这是"能不能跑"的差别。

真实场景怎么用

给 3 小时会议录像加字幕。痛点：字幕工具只认句子级时间戳，做不了逐词高亮。配置：model.transcribe("meeting.mp4", word_timestamps=True, vad_filter=True)。效果：每个词都带 start/end 时间，VAD 先把静音段切掉再转录，省算力还不容易在静音处幻听。

批量转写整个目录的 MP3。痛点：几十集播客一个个跑太慢。配置：套个文件循环调用transcribe，GPU 上换用BatchedInferencePipeline并把batch_size调到 16。效果：批量推理是吞吐最大的跑法，这条流水线默认开启 VAD 过滤。

提升专业术语识别率。痛点：Whisper 爱把 "CTranslate2" 写成 "C translate two"。配置：加一个hotwords="CTranslate2, Whisper, VAD"参数（参数说明见 transcribe.py 里的 docstring）。效果：模型会倾向输出你给的词，后期改稿量明显下降。

踩坑与调优

调了 transcribe 却没反应、不输出→segments是生成器，不迭代就不跑 → 先list(segments)或者直接在 for 循环里消费。

GPU 报找不到 cuBLAS / cuDNN 库→ 新版 ctranslate2 只支持 CUDA 12 + cuDNN 9 → 按 README 装对应版本；用 CUDA 11 的老卡就降级ctranslate2==3.24.0。

INT8 加批量推理 OOM→ 大概率是batch_size设太大 → 从 16 降到 4 或 8 试试，实在不行退回float16。

VAD 把句子首尾咬字切掉了→speech_pad_ms太保守 → 在vad_parameters里设speech_pad_ms=200，再调小min_silence_duration_ms，默认参数说明在 vad.py。

CPU 上速度没提上来→ 线程没配 → 给cpu_threads设物理核心数，或运行时设OMP_NUM_THREADS，两者取一致。

值不值得用

如果你在跑 Whisper 但嫌慢、嫌吃内存，或者要批量处理字幕转写，它基本没有理由不换成这个：接口几乎一致，迁移成本很低。不适合的场景是流式实时转录——它本质是离线模型，实时需求得去看社区方案（Whisper-Streaming 这类项目都以它做后端）。想深入调参，WhisperModel 的全部参数 和 VAD 实现 是两站必读。建议的下一步很具体：先用base模型加 int8 转一段一分钟的音频，把速度手感找出来，再决定上大模型。

【免费下载链接】faster-whisperFaster Whisper transcription with CTranslate2项目地址: https://gitcode.com/GitHub_Trending/fa/faster-whisper