Mac本地语音转文字实测：Whisper与Parakeet跑分对比

在Mac上做本地听写应用，选哪个语音识别引擎当默认，是个必须先解决而不该拍脑袋的问题。开源听写工具Plainsay的作者在Apple Silicon上亲自搭了一套可复现测试台，把OpenAI的Whisper large-v3-turbo与NVIDIA的Parakeet TDT 0.6B v3拉进同一赛道，用同一批音频、同一套评测标准跑了两遍。

为什么值得看这份benchmark

关于语音识别模型谁更快、谁更准，网上说法很多，能被人重新跑一遍的却很少。作者没有直接采信厂商或社区的结论，而是写了一个约240行的Swift命令行工具，把音频、脚本和每次运行的原始结果一并提交到仓库。任何人clone下来，跑一条命令就能得到自己的数字。

他刻意没有去测其他商业听写App。用脚本去驱动别人的闭源软件，本身很难做到公平，也容易变成转述无法验证的第三方数据。这份测试只覆盖他自己在两个引擎上的实现，边界清楚，也方便别人挑刺。

数据集与测试台设计

测试选用LibriSpeech的test-clean（CC BY 4.0），原始集合包含40位说话人、2620条语音。作者从中抽取了一个50条的分层样本：按排序后的说话人列表每隔4位取一个，共10位说话人；每位再取其第一章里的5条语音。最终样本约1002个参考词、356秒音频。这个规模小到可以逐条人工核对识别结果，也覆盖了10种不同音色。

测试台有几个设计细节直接影响结果的可信度。首先它调用的是应用核心模块里的WhisperKitEngine和ParakeetEngine，不是为测试另写一套实现，依赖版本也被固定（WhisperKit 1.1.0、FluidAudio 0.15.6）。其次音频处理路径与麦克风采集一致：FLAC先经AVAudioFile解码，再用AVAudioConverter重采样到16 kHz单声道Float32，所有音频提前读入内存，文件I/O不计入耗时。第三，只对transcribe阶段计时，模型下载和Core ML准备都在计时区之外，且不做隐藏预热——第一次推理的慢调用被如实算进平均延迟。

评分前会做简单归一化：参考文本与识别结果统一小写、去掉撇号以外标点、压缩空白。LibriSpeech参考是不带标点的大写词，Whisper输出则是带大小写和标点的文本，不做这步处理会把格式差异算成识别错误。WER使用基于词的Levenshtein对齐计算。

LibriSpeech test-clean 是语音识别领域最常用的公开基准数据集之一，源自 LibriVox 项目中有声书的朗读录音，全部为英语，采样率 16 kHz。test-clean 子集经过人工校验，剔除了明显噪声或发音不清的样本，因此 WER 普遍偏低，常被用来比较模型在“理想条件”下的上限。它的说话人以英语母语者为主，口音多样性有限，这也是作者强调“只测英语、只有干净朗读语音”的原因：在这个集合上表现接近，并不代表在真实听写场景下同样接近。

WER（词错误率） 是语音识别最核心的评测指标，计算方式为 (替换词数 + 删除词数 + 插入词数) / 参考总词数。它通过基于词的 Levenshtein 对齐，把识别结果与参考文本逐词匹配，统计最少编辑操作数。WER 对文本格式极其敏感：大小写、标点、缩写、拼写变体都会被算作替换错误，因此评测前通常需要归一化。本文中 Whisper 因输出带标点和大小写，若不归一化会产生大量“假错误”，这也是作者强调归一化重要性的直接原因。

实时因子（RTF） 指处理音频所需时间与音频本身时长的比值。RTF 小于 1 表示处理速度快于实时，越小越快。本文中 Parakeet 的 RTF 为 0.014，意味着处理 1 秒音频只需约 14 毫秒；Whisper 为 0.095，约 95 毫秒。RTF 比绝对延迟更能反映模型在不同音频长度下的扩展性，也是评估本地听写能否做到“说完即出”的关键指标。

实测结果：延迟差距明显，准确率差距不明显

在MacBook Air（M4，10核CPU，16 GB）与macOS 26.5.1上运行，得到如下数据：

引擎	WER	平均延迟	实时因子
Parakeet TDT 0.6B v3	2.50%（25/1002）	0.10 s	0.014
Whisper large-v3-turbo	2.89%（29/1002）	0.68 s	0.095

两个引擎都没有在任何一条音频上失败。

延迟差距是这次测试里最清晰的结论。从逐条数据看，Parakeet中位数为0.088秒，最慢0.19秒；Whisper中位数0.64秒，最慢1.04秒。准备完成后的第一次推理，Parakeet用了0.13秒，Whisper用了0.93秒，冷启动对Whisper的影响要大得多。对于按键说话式听写，Parakeet的结果几乎是即时的，Whisper则会有一个可感知的短暂停顿。

而准确率的差距并不明确，把错误逐条读一遍就能明白原因。

逐条读错误之后：0.39个百分点可能是噪声

作者把每条的识别文本都提交了仓库，所以能看到每个被计为错误的词到底是什么。其中有相当一部分并不是识别失误：

• 英式与美式拼写差异，两个方向都有。参考里写HONOUR、ENQUIRE，两个引擎都输出honor、inquire；参考写COLOR、CHECK，Parakeet则输出colour、cheque。每次都被计成一个完整词错误。
• 缩写。Whisper把SAINT FRANCIS写成"St. Francis"，把MISTER WATSON写成"Mr Watson"。
• 引号。有两条音频里Whisper产生了嵌套引号，而归一化保留了撇号以免把don't拆开，导致'we和him'无法匹配参考。仅这一条就占了Whisper 29个错误中的4个，引号相关问题总共让它损失6个。
• 生僻专有名词。Margolotte变成Margolot，Donnithorne在Whisper里变成donnythorne、在Parakeet里变成Donny Thorne（算两个错误），Silvia在两个引擎里都变成Sylvia。

当然也有真实的错误。两个引擎都把BOOKKEEPER听成了"bit keeper"，Whisper还把法语词BADAUDERIE变成了"Bad-Dot-Grey"。

结论是：在干净的朗读语音上，两个引擎之间0.39个百分点的WER差距，与归一化带来的噪声处于同一量级。作者提到更早一次提交的运行（8月17日）里，同一批音频下Parakeet只有23个错误而非25个。在得出"某个模型更准"的结论前，先看清楚错误是什么。一个更完整的归一化器（覆盖拼写变体、缩写、边缘撇号，类似Whisper官方的英文文本归一化）应当能把两个数字都压下去，但作者还没提交这版，所以不引用重算后的结果。

文本归一化 在语音识别评测中并非可选项，而是决定结论是否成立的前提。Whisper 官方在其英文评测中使用了较为复杂的归一化器，覆盖数字、货币、缩写、拼写变体、边缘撇号等规则，目的是让“识别正确但格式不同”的输出不被误判为错误。本文作者只做了小写、去标点、压缩空白三步，因此英式与美式拼写（HONOUR vs honor）、缩写（SAINT vs St.）、嵌套引号（'we、him'）都被计入 WER。这解释了为什么 0.39 个百分点的差距不宜直接解读为模型优劣：它很可能只是归一化器覆盖范围不同带来的系统性偏差，而非识别能力差异。

这份测试没有覆盖什么

作者主动列出了benchmark的边界，这部分比结果本身更有参考价值：

• 只测英语。 LibriSpeech test-clean对波兰语、德语等无从说明，Parakeet v3的多语言能力和Whisper的语言广度是另外的、未被测量的论断。
• 只有干净的朗读语音。 真实听写要面对笔记本麦克风、房间噪声、犹豫和改口，两个引擎的WER都会更高。
• 跳过了采集链路。 音频从文件解码，麦克风行为和语音活动检测都没有被测试。
• 只有一台机器。 M4 MacBook Air，更老的M1会更慢，Whisper尤其明显。
• 只是快照。 应用随后升级到了FluidAudio 0.15.8，修复了某些长录音结尾被丢弃的问题；而长听写根本不在这个样本里，因为LibriSpeech的片段都很短。

为什么Parakeet成了推荐默认

对于英语按键说话的听写场景，延迟在很大程度上决定体验：几秒长的音频上，0.1秒对0.68秒的差距是能感觉到的。而在这一小样本上，准确率差距落在噪声范围内，分不出胜负。Whisper仍然保留，用于它在某些语言和口音上表现更好的场合，也因为它那套标点风格有一批偏好者。

作者也邀请其他人在不同Mac上跑这套测试，特别希望看到M1/M2机器的数字，并欢迎提交更好的归一化器或更嘈杂测试集的PR。

自己跑一遍

git clone https://github.com/conrader/plainsay
cd plainsay
git checkout 2bc1552b19a5ae4094bd81714461baf4ebaa7202
swift build --product BenchmarkCLI
.build/debug/BenchmarkCLI Benchmark/data/librispeech-test-clean-manifest.json

运行后会打印逐条进度，随后给出每个引擎的WER、延迟和实时因子，并在manifest旁写入results.json。完整方法记录在BENCHMARK.md，提交的结果位于Benchmark/data/。