Inscribe 12天前 · 2026-07-14 07:59:06 · 0 阅读

Apple 新版 SpeechAnalyzer 语音识别 API 实测：碾压自家前代，完胜 Whisper 全系

先说结论

Apple 在 iOS 26 和 macOS 26 里推出的新版 SpeechAnalyzer，是目前最强的端侧语音识别引擎。实测在 LibriSpeech 数据集的干净语音和带噪语音两部分，它都跑赢了 Whisper 全系，包括最大的 Whisper Small，速度还比 Small 快三倍左右。而它要取代的 SFSpeechRecognizer 老 API，在干净语音测试里直接垫底——比只有 40MB 的 Whisper Tiny 还差。

| 引擎 | test-clean WER | test-other WER | 模型大小 |
|---|---|---|---|
| Apple SpeechAnalyzer (iOS/macOS 26) | 2.12% | 4.56% | 系统内置 |
| Whisper Small (WhisperKit CoreML) | 3.74% | 7.95% | ~460MB |
| Whisper Base | 5.42% | 12.51% | ~140MB |
| Whisper Tiny | 7.88% | 17.04% | ~40MB |
| Apple SFSpeechRecognizer (老版) | 9.02% | 16.25% | 系统内置 |

WER（Word Error Rate）越低越好，代表识别替换、漏掉或凭空造词的占比。test-clean 是 2620 条干净朗读语音，test-other 是 2939 条难度更高、噪声更大的语音。所有引擎都在 M2 Pro（32GB，macOS 26.5.1）上纯端侧运行。

为什么要做这个测试

iOS 26 和 macOS 26 上，Apple 用新 API SpeechAnalyzer 和 SpeechTranscriber 替换掉了 SFSpeechRecognizer，但官方没公布任何准确率数据。要不要迁移、Apple 自家识别和 Whisper 到底谁强，开发者全靠猜。

Inscribe 是一个完全本地运行的 AI 工作空间，同时集成了 Apple 两代识别引擎和三个 Whisper 模型，这给了一个不常见的机会：可以用完全相同的生产代码路径、同一台机器、同一段音频，把五个引擎跑一遍。所以他们真就这么干了。

该不该从 SFSpeechRecognizer 迁走？

该迁，而且理由非常明确。新 API 把词错误率砍掉了 3.5 到 4 倍：干净语音从 9.02% 降到 2.12%，带噪语音从 16.25% 降到 4.56%。没有任何准确率代价——所有测试维度新 API 都赢，而且输出自带标点和大小写，老 API 的输出就粗糙得多。

换个说法：一小时的会议录音，用老 API 转写出来的错词大约是新 API 的四倍。如果你的 App 还在用 SFSpeechRecognizer 处理任何超过语音指令长度的内容，光凭准确率提升这一条，迁移就值了。

SpeechAnalyzer vs Whisper

更让人意外的是，Apple 新引擎连 Whisper Small（这次测试里最大的模型）都明显跑赢了——两个数据集上都赢，每秒音频的算力消耗只有 Small 的三分之一。在 Apple 硬件上做英语转写，目前能测到的最强端侧选项已经是系统自带的了。

Whisper 还有两个真实优势：支持的语言多得多（SpeechTranscriber 大约支持 30 种语言环境），而且不挑平台，不一定非得 Apple 系统 26。在这些之外，对当前 iPhone 或 Mac 上的英语转写，Whisper 当默认最强选项的日子已经结束了。

Inscribe 也根据这个结论改了自家产品的默认行为：Auto 引擎在 SpeechAnalyzer 支持的语言里优先用它，其他语言才走 Whisper。自己发了基准测试却不在产品默认里兑现，那是另一种奇怪的不诚实。

速度

五个引擎都跑得比实时快很多——M2 Pro 上大约 12x 到 40x 之间，一小时音频在端侧 1.5 到 5 分钟就能转完。SpeechAnalyzer 每秒音频的处理速度大约是 Whisper Small 的 3 倍，准确率还更高。这里暂时不放每个引擎的精确耗时表：准确率测试期间机器上有开发负载在跑，WER 不受影响，但会污染计时。后续会用空闲跑分补一份更干净的计时数据。

测试方法，以及为什么你可以验证

卖引擎的公司自己发的基准，多少都该打点问号。这份测试有两个属性是冲着这个怀疑来的。

Whisper 列可以对照 OpenAI 自己的数据复现

用 LibriSpeech 是因为 OpenAI 自己就在这上面发了 Whisper 的 WER。如果测试框架对 Whisper 的测量没问题，那结果应该落在官方数字上。六个测量点全部对得上：

| 引擎 / 数据集 | 本次测试 | OpenAI 官方 | 差值 |
|---|---|---|---|
| Whisper Tiny, test-clean | 7.88% | 7.6% | +0.28 |
| Whisper Base, test-clean | 5.42% | 5.0% | +0.42 |
| Whisper Small, test-clean | 3.74% | 3.4% | +0.34 |
| Whisper Tiny, test-other | 17.04% | 16.9% | +0.14 |
| Whisper Base, test-other | 12.51% | 12.4% | +0.11 |
| Whisper Small, test-other | 7.95% | 7.6% | +0.35 |

整体小幅、方向一致的正偏移（归一化器稍微严一点，加上 CoreML 量化），这才是诚实的复现该有的样子；随机误差应该是两边都有散点。既然同样的数据集、归一化器、评分器也跑出了 Apple 那几列，那些别人没法直接核对的数字，就继承了别人能核对的那部分验证。

原始转写文本公开

两个 Apple 引擎每条句子的假设转写文本都可以从下面下载，附带参考文本和单句 WER。觉得归一化有问题？自己重跑评分。

summary.json - 十个测量值，机器可读（3KB）
raw-transcripts-apple.json.gz - SpeechAnalyzer，全部 5559 条（620KB）
raw-transcripts-legacy.json.gz - SFSpeechRecognizer，全部 5559 条（620KB）

决定 WER 数字是否有意义的细节

同一条生产代码路径。每个引擎都跑在 Inscribe 用户实际用的代码上，不是实验室里另外搭一套缓冲和参数的框架。
文本归一化。LibriSpeech 参考文本全大写、无标点、数字拼成单词；现代引擎输出带标点和数字。两边都过同一套归一化器（大小写、标点、数字转单词、缩写），对齐 OpenAI 的英语归一化器。直接比原文只会惩罚那些输出格式更整齐的引擎，测的不是"听错没"。
语料级 WER，不是平均 WER。用总错误数除以总参考词数，短句不会被过度加权。
全程端侧，已验证。SFSpeechRecognizer 默认会上传音频到 Apple 服务器。测试强制走端侧识别，框架拒绝悄悄 fallback 到云端——一方面云端结果会破坏对比，另一方面这个产品主打隐私，不可能上传 5559 条音频。
失败也算，不藏着。引擎返回空就按该句 100% WER 计。27795 次转写里出现了一次（老引擎，test-other 数据集）。

顺手挖到了自家产品的一个 bug

做基准测试的过程还意外发现了 Inscribe 里的一个线上 bug。Apple 引擎的文件导入路径会把音频喂给 SpeechAnalyzer 然后关掉输入流，但漏调了 finalizeAndFinishThroughEndOfInput()。没这一步，分析器永远不会吐出最终结果，导入就卡死。这个 bug 一直没被发现，是因为 Auto 模式默认走 Whisper。修复当天就发布了，这也是为什么把测试框架细节公开：认真测自己的产品，总会撞见本来没想找的东西。

局限性

只测了英语。LibriSpeech 是英语朗读。这些数字对 Whisper 支持但 SpeechTranscriber 不支持的那 100 多种语言一概不适用。
朗读的有声书语音，不是会议。LibriSpeech 是标准可比的语料，所以先从它开始；带口音、远场、多说话人的会议音频是下一步要测的。
单台机器。M2 Pro，macOS 26.5.1。准确率应该能跨 Apple Silicon 迁移；速度会因芯片不同而变。
Whisper 走的是 WhisperKit CoreML。端侧量化转换版本，和 Inscribe 发布出去的是同一份。参考 GPU 实现可能有细微差异，验证表里已经量化了这个差异。

如果只想要好用的转写

当前 iPhone 或 Mac 上，英语端侧转写最强的引擎已经在系统里，私有化方案不再是妥协方案。Inscribe 用的就是这次测的这些引擎：SpeechAnalyzer 支持的语言用 SpeechAnalyzer，不支持的语言用 Whisper，全部端侧运行，什么都不上传。这份基准不是产品的附属品，它直接决定了产品的行为。