苹果 SpeechAnalyzer 实测：速度碾压 Whisper，准确率还差一口气

iOS 26 和 macOS 26 出来一段时间了，SpeechAnalyzer 这个新 API 也在开发者社区里被反复拿出来遛。这几天陆续有几家做转录工具的团队放出了正儿八经的横评数据，苹果的语音识别第一次被放在跟 Whisper 同一把尺子下量——结论不是一边倒的。

先说最抓眼球的那个数字：Yap 这款基于 SpeechAnalyzer 的 macOS 应用，处理一段 34 分钟、7GB 的 4K 视频，转录耗时 45 秒。对照组 MacWhisper（跑 OpenAI Whisper 开源模型）在同样硬件上是分钟级。这不是小幅领先，是一个数量级的差距。

但速度快不等于活好。Inscribe 团队做的那份基准测试更能说明问题：Whisper Large-v3 的词错率（WER）依然是三家里最低的，苹果 SpeechAnalyzer 排第二，落后大约 2-3 个百分点，把老的 SFSpeechRecognizer 甩得远远的。NVIDIA Parakeet 在英文短音频上很能打，但一遇到长音频和多说话人场景就掉链子。

SpeechAnalyzer 到底是什么

很多人第一反应是「苹果不是早就有 SFSpeechRecognizer 了吗」。是有，但那套东西从 iOS 10 用到现在，架构上是给短语音输入设计的——想想 Siri 听你说一句话、备忘录里录一段口述——超过一分钟的音频它就开始各种翻车。而且早期还是网络服务，后来才逐步下放到端侧。

SpeechAnalyzer 是重写。它围绕 Swift 的 AsyncSequence 组织，核心思路是把整个语音处理拆成模块化的 pipeline：

• SpeechAnalyzer：调度中枢，接受一组 SpeechModule
• SpeechTranscriber：负责语音转文本
• SpeechDetector：负责端点检测、静音判断
• 后续还能挂载翻译、说话人分离等模块

let transcriber = SpeechTranscriber(locale: .current)
let analyzer = SpeechAnalyzer(modules: [transcriber])
try await analyzer.prepareToAnalyze(in: audioFormat)

for try await result in transcriber.results {
    print(result.text)
}

try await analyzer.analyzeSequence(from: audioFile)

这套 API 表面看是 Swift 语法糖，本质是把「一次性喂进去等结果」的老范式，改成了「流式喂、流式吐」。对开发者来说最直接的好处是——你可以在录音还没结束的时候就开始拿到中间结果，做实时字幕、实时会议记录这种场景几乎是零延迟。

那份基准测试到底测了什么

Inscribe 的评测选了几类有代表性的音频：

1. 技术播客：讲话规范、专有名词多
2. 多说话人会议：交叉对话、背景噪音
3. 口音英语：印度、澳洲、苏格兰口音
4. 医疗术语访谈：低频专业词汇

用 Whisper Large-v3、Parakeet TDT-0.6B、Apple SpeechAnalyzer（本地模式）、老的 SFSpeechRecognizer 各跑一遍，算 WER 和实时因子（RTF，即处理时长/音频时长）。

关键数据几点：

• 英文清晰音频：Whisper WER 约 4.2%，SpeechAnalyzer 约 6.8%，Parakeet 5.1%，老 SFSpeechRecognizer 11%+
• 多说话人场景：Whisper 依然最稳，SpeechAnalyzer 差距缩小到 1.5 个百分点内
• 重口音：Whisper 优势明显，SpeechAnalyzer 掉到 12% 附近，Parakeet 更是崩到 20%
• 速度：SpeechAnalyzer 在 M 系列芯片上 RTF 普遍在 0.02-0.05，Whisper Large-v3 在同硬件 RTF 约 0.15-0.3，差距 5-10 倍

重点是资源占用。SpeechAnalyzer 在 M2 MacBook Air 上跑长音频，内存峰值 800MB 左右；Whisper Large-v3 直接飙到 4-5GB，风扇也会转起来。这个差距很大程度上决定了它们的适用场景。

苹果的算盘

如果单看 WER，SpeechAnalyzer 这一仗算不上赢——它没打过 Whisper。但苹果显然不是奔着「最准」这个目标去的。

它要的是端侧、低延迟、低功耗。这三个词凑在一起，意思是：你可以在 iPhone 上做实时会议转录不发烫、可以在 Mac 上开着转录后台不影响写代码、可以在 Vision Pro 上做实时字幕不掉帧。

Whisper 那套架构决定了它就不是干这个的。Whisper 是典型的 encoder-decoder Transformer，输入必须切成 30 秒的固定 chunk，然后一整块进模型出结果。你想做低延迟流式？可以，但要各种 trick——滑窗、beam search 提前截断、chunk 之间拼接去重——精度会掉，工程复杂度也上去了。市面上做实时 Whisper 转录的产品，比如 whisper.cpp 的 stream 模式，实际用起来延迟在 1-2 秒是常态。

SpeechAnalyzer 从 API 设计上就是流式原生。AsyncSequence 那套东西，音频进来就吐结果，中间还能修正之前的猜测（rewind and correct）。这个 API 语义对写产品的人来说，比 WER 差 2 个百分点重要得多。

开源社区的反应

Reddit 上苹果那帖子下面有个高赞回复挺一针见血：「Whisper 还是最准的，但苹果这个是我第一次觉得可以拿来做正经产品的端侧方案。」

做本地 AI 的开发者对这套东西评价普遍偏正面。之前想在 iOS 上做转录只有两条路——要么用 SFSpeechRecognizer 忍受它的短板，要么自己塞一个 CoreML 版本的 Whisper 进 App 包里（包体积直接 +500MB 起）。现在有第三条路，而且是系统 API，模型不占用户存储，还能享受 Neural Engine 的硬件加速。

不过也有开发者吐槽：

• 语言支持有限：目前 SpeechAnalyzer 支持的语言数少于 Whisper 的 99 种
• 模型不可换：苹果没开放让你换自定义 ASR 模型的口子，只能用它自己的
• 中文表现：几个中文测试者反馈准确率还行但不如 Whisper Large-v3，尤其是中英夹杂场景
• 无法调整：没有温度、beam width 这些推理参数可调

一个不能忽略的信号

往回退一步看：苹果这次在 WWDC 一口气推了 SpeechAnalyzer 和 Foundation Models framework，前者管语音，后者管 LLM。两套东西的共同点是——都是端侧、都是 Swift 原生 API、都免费用。

这个组合拳的意图很清楚：让 iOS/macOS 开发者不用付 API 费、不用担心用户隐私、不用打包大模型，就能给应用加上 AI 能力。对独立开发者是天大的好事，对 API 厂商是长期挤压。

但云端 API 也不会因为端侧模型崛起就消失。原因很直接：端侧模型再快也追不上云端最新旗舰的能力上限。SpeechAnalyzer 打不过 Whisper Large-v3，端侧 LLM 更打不过 GPT 或 Claude 的最新版本。真正需要高准确率、高质量输出的场景——法务转录、医疗记录、跨语言会议——还是得靠云端。

所以现在的实际做法是分层：轻量、实时、隐私敏感的用端侧，重度、需要顶级质量的用云端 API。做多模型接入的开发者，可能一个 App 里同时接了 SpeechAnalyzer（本地转录）+ 某个云端 LLM（后处理、纠错、摘要）。这种混合架构下，把云端多家模型统一到一个 Key 里管理是刚需——OpenAI Hub 这类聚合平台也是做这个事的，兼容 OpenAI 格式，一个 Key 调 GPT、Claude、Gemini、DeepSeek 全家桶，对做端云协同的开发者省事不少。

给开发者的实际建议

如果你现在在评估要不要迁移到 SpeechAnalyzer，几个判断维度：

1. 场景是不是实时优先——是就迁，准确率略降换到的流式体验值
2. 是不是英文为主——SpeechAnalyzer 英文表现最好，小语种要谨慎
3. 能不能容忍 iOS 26+ 的最低版本要求——不能就还得留一份 fallback
4. 对推理参数有没有强需求——如果你需要自定义 vocabulary、bias 词表、beam search，SpeechAnalyzer 目前给的口子不够

结论：SpeechAnalyzer 不是 Whisper killer，但它把「端侧实时 ASR」这个曾经很尴尬的赛道拉到了可用水平。对绝大多数 App 场景，它够用而且比之前的方案好太多。对追求极致准确率的场景，Whisper 还是那个 Whisper。

技术圈这两年一直有个感觉：真正影响开发者日常的往往不是发布会上那个最大的模型，而是这种把「够用」的东西塞进系统 API 里的动作。SpeechAnalyzer 属于后者。