Apple的新语音API和Whisper：首个真实基准测试

2026-07-14 0

Apple 发布了 SpeechAnalyzer，但未提供准确率数据。我们在 5,559 条标准测试语音上对其与被替代的 API 以及 Whisper 进行了对比测量，并公开了每一条转录结果。

Apple的新语音API与Whisper：首个真实基准测试

Apple 新语音 API 与 Whisper 基准测试

结果，先说结论

Apple 的新 SpeechAnalyzer 是我们测试过的最准确的端侧语音引擎。它在 LibriSpeech 的干净和嘈杂两部分测试中都击败了我们提供的所有 Whisper 模型，包括 Whisper Small，同时运行速度大约是 Small 的三倍。而它所替代的 API，SFSpeechRecognizer，在干净语音测试中排名最后：甚至落后于仅 40MB 的 Whisper Tiny 模型。

越低越好：WER 是词错误率，即引擎替换、遗漏或编造的词所占的百分比。LibriSpeech test-clean 是 2,620 条干净朗读语音；test-other 是 2,939 条更难、更嘈杂的语音。所有引擎均在 Apple M2 Pro（32GB，macOS 26.5.1）上完全端侧运行。

我们为何进行此测试

随着 iOS 26 和 macOS 26 的发布，Apple 用新 API SpeechAnalyzer 和 SpeechTranscriber 替代了 SFSpeechRecognizer。但 Apple 并未公布这两个新 API 的准确率数据。因此，每个考虑是否迁移的开发者，以及每个将 Apple 内置识别与 Whisper 进行比较的人，都只能靠猜测。

我们在 Inscribe（一个私有的端侧 AI 工作区）中并行提供 Apple 的两个引擎和三个 Whisper 模型，这使我们处于一个特殊位置：我们可以在同一台机器、同一段音频上通过完全相同的生产代码路径运行所有五个引擎。所以我们这么做了。

是否应该从 SFSpeechRecognizer 迁移？

是的。这是数据中最明确的结果。新 API 在相同音频上的词错误率降低了 3.5 到 4 倍：在干净语音中从 9.02% 降至 2.12%，在嘈杂语音中从 16.25% 降至 4.56%。没有准确率权衡可言；新 API 在我们测量的所有方面都胜出，并且输出带标点、大小写正确的文本，而旧引擎的输出则较为粗糙。

换句话说：使用旧 API 转录一小时的会议，其错误词数大约是使用 SpeechAnalyzer 转录同一会议的四倍。如果你的应用仍在对超过语音命令长度的内容使用 SFSpeechRecognizer，仅从准确率角度考虑，迁移就是值得的。

SpeechAnalyzer 与 Whisper 对比

更令人惊讶的结果是：Apple 的新引擎还在两个测试集中都明显优于我们提供的最大模型 Whisper Small，且每秒音频的计算时间仅为 Whisper Small 的约三分之一。对于英语，在 Apple 硬件上，内置引擎现在是我们能测量到的最强端侧选项。

Whisper 仍保持两个实际优势。它支持的语言远多于 SpeechTranscriber（后者支持约 30 种语言），并且可在任何平台运行，而不仅限于搭载 OS 26 的 Apple 平台。但对于当前 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 的一致。确实如此，在全部六项测量中都一致：

小而一致的正向偏移（更严格的文本归一化加上 CoreML 量化）正是诚实复现的表现；随机误差会在两个方向上分散。由于相同的语料库、归一化器和评分器生成了 Apple 列数据，那些其他人无法验证的数字继承了可验证数字的验证性。

原始转录公开

两个 Apple 引擎的每条语音假设结果均可在下方下载，旁边是参考文本和每条语音的 WER。不同意我们的归一化方式？你可以自己重新评分。

summary.json - 全部十项测量结果，机器可读（3KB）
raw-transcripts-apple.json.gz - SpeechAnalyzer，全部 5,559 条语音（620KB）
raw-transcripts-legacy.json.gz - SFSpeechRecognizer，全部 5,559 条语音（620KB）

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

相同的生产代码路径。每个引擎都通过 Inscribe 用户实际使用的代码运行，而不是实验室中不同缓冲或设置的测试框架。
文本归一化。LibriSpeech 参考文本为大写、无标点、数字拼写形式；现代引擎输出标点和数字。两边都通过相同的归一化器（大小写、标点、数字转单词、缩写），与 OpenAI 的英语归一化器一致。对原始文本评分会惩罚格式良好而非听错的引擎。
语料库 WER，而非平均 WER。总错误数除以总参考词数，因此短语音不会被过度加权。
完全端侧，已验证。SFSpeechRecognizer 默认会将音频发送到 Apple 服务器。我们强制使用端侧识别，并使测试框架在无法端侧运行时拒绝运行而非静默回退到云端，因为云端结果会使比较无效，且我们不会从隐私产品中上传 5,559 条语音。
失败计入，不隐藏。引擎返回空值时，该语音的 WER 计为 100%。在 27,795 次转录中发生了一次（legacy，test-other）。

构建此测试让我们对自己的应用有了哪些认识

基准测试发现了 Inscribe 中一个已发布的 bug。我们的 Apple 引擎文件导入将音频提供给 SpeechAnalyzer 并关闭输入流，但从未调用 finalizeAndFinishThroughEndOfInput()。没有该调用，分析器永远不会交付最终结果，导入会永远挂起。此前未被发现是因为我们的 Auto 设置优先使用 Whisper。修复已于当天发布，这也是我们发布测试框架细节的原因之一：仔细测量自己的产品往往会发现你未曾寻找的问题。

限制

仅限英语。LibriSpeech 是英语朗读语音。这些数字对 SpeechTranscriber 不支持但 Whisper 支持的 100 多种语言没有任何说明。
朗读有声书语音，非会议语音。LibriSpeech 是标准、可比较的语料库，因此我们以此开始。带口音、远场、多人会议语音是明显的后续测试方向。
一台机器。M2 Pro，macOS 26.5.1。准确率应在 Apple Silicon 间转移；速度因芯片而异。
Whisper 通过 WhisperKit CoreML。端侧量化转换，与 Inscribe 发布的构建相同。参考 GPU 实现可能略有不同，验证表对此进行了量化。

如果你只想要好的转录结果，这意味着什么

如果你使用当前的 iPhone 或 Mac，最好的端侧英语转录引擎已经内置在操作系统中，且私有选项不再是妥协选择。Inscribe 正是使用此处测量的引擎：在语言支持范围内使用 SpeechAnalyzer，不支持时使用 Whisper，全部端侧运行，无任何上传。基准测试不是与产品分离的；它正是我们决定产品功能的方式。