我以前的直觉是，系统 API 胜在省事，但准确率和可控性通常不如开源模型；Whisper 胜在跨平台、可复现、生态成熟，只是体积和推理成本更麻烦。这个判断在 2026 年可能要改一半。

原因是 Inscribe 在 Hacker News 上发了一组很有意思的测试：Apple’s New Speech API vs Whisper: The First Real Benchmark。他们把 Apple 新的 SpeechAnalyzer、旧的 SFSpeechRecognizer，以及 Whisper Tiny/Base/Small 放在同一台 Apple M2 Pro 上，用 LibriSpeech 的 test-clean 和 test-other 一共 5,559 条 utterance 做了对比，还公开了 summary.json 和部分原始转写文件。HN 也记录了这个帖子的热度和发布时间：Algolia HN item。

结果挺反直觉：SpeechAnalyzer 在这组测试里不是“小幅追上”，而是明显超过了 Whisper Small。test-clean 的 WER 是 2.12%，Whisper Small 是 3.74%；test-other 的 WER 是 4.56%，Whisper Small 是 7.95%。旧的 SFSpeechRecognizer 则分别是 9.02% 和 16.25%。

WER 是 word error rate，简单说就是模型把词听错、漏掉、乱加的比例。人话翻译：同样一小时录音，WER 从 9% 掉到 2% 不是“看起来更准一点”，而是后处理、人工校对、摘要生成都会少吃很多脏数据。

但我不建议看到这个表就立刻把 Whisper 从产品里删掉。工程选型从来不是榜单第一就赢。

这个 benchmark 真正说明了什么

先把数据说清楚。Inscribe 的测试环境是 Apple M2 Pro、32GB RAM、macOS 26.5.1；数据集是 LibriSpeech test-clean 2,620 条和 test-other 2,939 条。SpeechAnalyzer、SFSpeechRecognizer 和 WhisperKit CoreML 版本的 Whisper Tiny/Base/Small 都跑在本地，不走云端。

从结果看，三个结论比较稳：

第一，新的 SpeechAnalyzer 相比旧 API 是一次实质升级。旧 SFSpeechRecognizer 在 clean 上 9.02%，在 other 上 16.25%；SpeechAnalyzer 分别降到 2.12% 和 4.56%。如果你的 App 还在用旧 API，而且目标平台允许迁移，继续拖着不动很难解释。

第二，在 Apple 设备上，“系统级本地模型”已经不只是省包体的妥协方案。它可以同时做到无需随 App 分发 40MB/140MB/460MB 模型文件，又在这组英文读音数据上超过 Whisper Small。对移动端产品来说，这个组合很有杀伤力：下载更轻、权限更清晰、耗电和调度交给系统，用户也更容易理解“音频留在设备上”。

第三，Whisper 的优势没有消失，只是优势从“默认更准”转向了“可控和可迁移”。OpenAI Whisper 仍然是非常成熟的开源语音识别基线，GitHub 仓库超过 10 万 stars，最近仍有维护记录。你可以固定模型版本，可以在 Linux 服务器、Windows 客户端、Android 设备上跑，可以换 faster-whisper、Whisper.cpp、WhisperKit，也可以根据语言、领域词表和硬件约束做自己的优化。

说白了，SpeechAnalyzer 更像一个很强的“平台能力”；Whisper 更像一个可搬走、可审计、可替换的“工程组件”。

这两者解决的不是同一个问题。

为什么“准确率更高”还不足以决定选型

我最关心的不是 2.12% 和 3.74% 之间的差距，而是这个差距能不能迁移到你的真实场景。

LibriSpeech 是常用数据集，但它不是你的业务录音。会议室远场、多说话人打断、电话窄带音频、中文夹英文、行业术语、口音、儿童声音、嘈杂车载环境，这些都会改变结论。Inscribe 自己在 summary 里也提醒，速度数据是在带有并发开发负载的机器上测的，发布速度 claim 前需要 idle 环境重测。这个态度是对的：WER 数字能给方向，但不能替你做验收。

我会把语音转写系统拆成五个判断维度：准确率、延迟与功耗、平台覆盖、可控性、合规边界。

准确率上，SpeechAnalyzer 在 Apple 英文场景下看起来非常强，尤其是和旧 SFSpeechRecognizer 的差距足够大。延迟与功耗上，系统 API 理论上也占便宜，因为它可以利用 Apple 自己的模型分发、硬件调度和系统级优化；应用不需要自己管理 CoreML 模型、量化版本和下载缓存。

但平台覆盖是硬伤。只要你的产品不只跑在 iOS/macOS 26 之后的 Apple 设备上，SpeechAnalyzer 就不可能是唯一答案。企业客户常见的录音处理链路可能在浏览器、Windows 桌面端、Linux 批处理服务器、Android 采集设备之间流动。这个时候，Whisper 这类开源模型的价值就回来了：它让你用同一个识别后端覆盖更多环境。

可控性也很关键。系统 API 的坏处不是“闭源”两个字本身，而是你很难回答一些生产问题：模型什么时候更新？更新后 WER 是否变化？某些行业词汇能不能定制？出了回归怎么回滚？在不同地区、系统版本、设备型号上行为是否一致？这些问题在个人工具里可能不重要，在医疗、法律、客服质检、金融合规场景里就很重要。

这也是我对“用系统 API 替代模型”的基本态度：如果它只是用户侧实时体验的一部分，我非常愿意用；如果它是后端数据流水线的唯一事实来源，我会谨慎很多。

更现实的架构：不要二选一

比较好的工程方案往往不是“SpeechAnalyzer vs Whisper”，而是分层使用。

在 Apple 客户端上，可以优先使用 SpeechAnalyzer 做实时草稿转写。用户讲话时立刻看到字幕，隐私解释简单，App 包体也不会膨胀。对于会议纪要这种产品，实时反馈的心理价值很高：用户看到文字滚出来，就知道系统还活着。

随后，如果录音进入更严肃的处理流程，比如生成正式纪要、提取 action items、做搜索索引，可以按场景决定是否再跑一遍可控模型。对英文 Apple-only 产品，也许 SpeechAnalyzer 的结果已经足够；对跨平台企业产品，可以把 Whisper 或其他 ASR 模型作为统一后端基线。

这里有个容易忽略的点：语音识别只是上游。下游往往还有说话人分离、标点修复、术语纠错、摘要、RAG 检索、权限过滤。上游 WER 降低当然会改善后面的一切，但后端链路是否可复现同样重要。之前我写过 本地 LLM 推理如何在 Ollama 与 llama.cpp 之间取舍，那篇讲的是文本模型，但思路类似：本地优先不是口号，它会把模型分发、硬件差异、版本管理这些问题一起带进来。

如果你的转写结果要进入向量库或混合检索，错误词还会放大成召回问题。比如专有名词被听错，后面再好的 reranker 也救不回来。关于检索链路里 bi-encoder 和 cross-encoder 的分工，可以看这篇：Rerank 到底解决什么问题。ASR 的错误本质上是在给检索系统投毒，只是毒性有时候不明显。

我会怎么选

如果是一个只面向 Apple 生态的新产品，我会认真考虑把 SpeechAnalyzer 作为默认 ASR。它的理由很充分：准确率强、用户隐私叙事清楚、不需要自己塞模型、系统集成成本低。尤其是笔记、个人知识库、离线字幕、轻量会议助手这类产品，先用平台能力把体验做顺，比一开始维护多套 ASR 后端更划算。

如果是跨平台产品，我不会让 SpeechAnalyzer 成为唯一链路。它可以作为 Apple 端的加速路径，但后端仍需要一个稳定、可测试、可回归的 ASR 基线。Whisper 未必永远是最佳选择，但“开源、可部署、可版本化”这几个属性在生产里很硬。

如果是强合规场景，我会更保守。不要只问“是否本地运行”，还要问：模型和中间文件是否可审计？日志里有没有音频片段？系统 API 的数据处理边界怎么写进 DPA？不同 OS 版本的输出差异怎么记录？这些问题不性感，但它们决定你能不能把系统卖给真正的大客户。

最后，如果你已经在线上使用 SFSpeechRecognizer，我的建议比较明确：尽快做迁移评估。不是因为旧 API 一定马上不能用，而是这次差距太大了。先选一批真实业务音频，跑旧 API、SpeechAnalyzer、你当前的 Whisper 方案，按自己的语言、设备、噪声和术语统计 WER，再决定灰度策略。

小结

这次 benchmark 对我最大的提醒是：端侧 AI 的竞争正在从“有没有模型”变成“平台默认能力够不够好”。当系统 API 在某些任务上超过开源小模型，开发者的默认架构就会变化。

但生产系统不能只看单点能力。SpeechAnalyzer 很可能是 Apple 生态里新的默认选择；Whisper 仍然是跨平台和可控性的安全垫。真正稳的方案，是把平台能力当成体验加速器，把可复现模型当成工程兜底。

我不确定 SpeechAnalyzer 在中文、多人会议、强噪声和行业术语上的表现能不能同样漂亮。欢迎有真实数据的朋友指正。至少从这组公开结果看，语音转写选型已经不再是“Whisper 默认赢”的时代了。