苹果新语音API与Whisper首个真实基准测试详细报告

时间：2026-07-23 08:06

Apple新语音APISpeechAnalyzer在LibriSpeech测试中准确率超越WhisperSmall，速度约为其三倍，词错误率较旧API降低3 5至4倍。旧API在干净语音测试中垫底。所有引擎完全端侧运行，原始转录结果公开。该成果展示了端侧语音识别的显著进步。

Apple 最近发布了 SpeechAnalyzer 和 SpeechTranscriber，但并未公布这两个新 API 的准确率数据。我们使用 5,559 条标准测试语音，对这俩新 API、它们即将取代的旧 API，以及 Whisper 模型进行了全面对比测试，并且每条转录结果均已公开。用数据说话，结果真实可靠。

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

Apple 新语音 API 与 Whisper 基准测试对比

先说结论：结果概览

Apple 的 SpeechAnalyzer 是我们测试过的所有端侧语音引擎中识别精度最高的。在 LibriSpeech 的干净测试集和嘈杂测试集上，它均击败了我们能够获取的所有 Whisper 模型，包括 Whisper Small。与此同时，它的运行速度约为 Whisper Small 的三倍。而它将要取代的旧 API——SFSpeechRecognizer，在干净语音测试中表现垫底，甚至不如仅有 40MB 大小的 Whisper Tiny 模型。

理解这一结果的关键在于 WER（词错误率），该数值越低越好。WER 代表引擎替换、遗漏或编造的词所占的比例。LibriSpeech 的 test-clean 包含 2,620 条清晰朗读语音，test-other 则包含 2,939 条更嘈杂、难度更高的语音。所有引擎均在 Apple M2 Pro（32GB，macOS 26.5.1）上纯端侧运行，未连接网络。

为什么要做这个测试？

随着 iOS 26 和 macOS 26 的发布，Apple 用 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 上大约在 12 倍到 40 倍之间，这意味着一个小时的音频，在端侧转录仅需约 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，全部端侧运行，没有任何数据上传。基准测试和产品不是分离的；它正是我们决定产品功能的方式。