本地 Whisper 引擎选型
背景
我本地一直装着 Whisper 做音频转文字（会议录音、课程音频、口语练习这些）。最近看到 faster-whisper，就拿去问了 AI 哪个更适合我。这个话题前后和两个 AI 讨论了三轮，加上自己实测又翻案一次，过程比结论本身更值得记录。
第一轮，AI 建议我直接换 faster-whisper，理由是它”非常适合 MacBook Air M2”。第二轮交叉验证时被指出硬伤：faster-whisper 底层的 CTranslate2 只支持 CUDA 和 CPU，不支持 Apple Silicon 的 Metal/Core ML，在 M2 上根本调不动 GPU。第一个 AI 承认了错误，马上给出新排序，还顺手设计了一套”双引擎 + 抽象层”的架构。
到这一步我发现一个更根本的问题：这些分析看起来都很严谨，但没有一个有数据。我的判断是，性能结论不靠实测，就是 AI 互相客气。现在回看，这个判断是整件事里最对的一步。
第一轮实测
我造了一段 4.8 分钟的测试音频：用 macOS TTS 合成一段中英混合的技术会议对话，好处是真值文本已知，可以量化准确率。统一 large-v3 模型，在 M2 Air（24GB）上跑：
| 引擎 | 运行模式 | 转写耗时 | 峰值内存 | 准确率（与真值相似度） |
|---|---|---|---|---|
| whisper.cpp large-v3 | Metal | 69 秒 | 4.2 GB | 73.5% |
| faster-whisper large-v3 | 纯 CPU int8 | 926 秒 | 3.2 GB | 83.0% |
| whisper.cpp large-v3-turbo | Metal | 21 秒 | 2.0 GB | 10.2% |
当时得出的结论是：换 whisper.cpp，速度是 faster-whisper 的 13 倍，准确率损失能接受。我还顺手把这个结论固化成了 skill。
几个数据之外的发现：
- faster-whisper 转 1 小时音频要约 3 个小时，批量流水线直接不可用。
- turbo 模型在中英混合场景直接翻车：重复循环、整段丢失。
- 最意外的坑：
-l auto自动识别语言会把整段判成英语，中文内容全丢。中英混合必须显式-l zh，内嵌的英文术语照样能转对。
第二次翻案
准备把 whisper.cpp 接进课程转写流水线时，我翻了下现有代码，发现流水线早就在用 mlx-whisper（Apple 原生框架）+ turbo，根本不是官方 Whisper。那我之前测的”谁是 Mac 最快”就漏了一个重要选手，只能补测。
补测结果（同一段中英混合音频）：
| 引擎 | 耗时 | 峰值内存 | 准确率 |
|---|---|---|---|
| mlx-whisper turbo | 105 秒 | 0.73 GB | 80.1% |
| whisper.cpp large-v3 | 69 秒 | 4.2 GB | 73.5% |
纯英文课程音频上再测一轮，mlx turbo 准确率依然更高（whisper.cpp 有整句丢失），速度接近，内存只有 1/6。
也就是说，我上一轮”换 whisper.cpp”的结论只成立了一天。mlx-whisper turbo 准确率更高、内存六分之一，代价只是慢一点。而且之前” turbo 模型中英混合翻车”的判断也要修正：同一个 turbo，在 whisper.cpp（ggml 运行时）上翻车，在 MLX 上完全正常——翻车的是 ggml，不是模型。
最终结论
- Mac 本地日常转写：mlx-whisper + large-v3-turbo，显式指定语言。之前写的 skill 已经把默认引擎改成它，whisper.cpp 降级成”追极限速度”的备选。
- 课程流水线：维持现状，不用改。现有选择恰好就是实测最优。
- faster-whisper 在这台机器上没有位置：纯 CPU 跑 large-v3 慢到不可用。
日常转写一条命令：
mlx_whisper meeting.m4a --language zh --model mlx-community/whisper-large-v3-turbo经验教训
- AI 给的硬件性能建议，默认是理论推测。它可以帮你列方案、找坑，但”哪个快”这种问题，跑一次的证据效力大于三轮分析。AI 之间互相认错改口的时候都很流畅，不看数据根本分不清哪轮是对的。
- 我自己的实测结论也一样会翻案。第一轮漏测了 mlx-whisper，结论就歪了。benchmark 的覆盖面决定了结论的保质期。
- 测出来的坑要尽快固化。
-l zh这种规则，不靠 skill 记下来，下次大概率还会踩一遍。