苹果全新 Speech 框架：SpeechAnalyzer 与 SFSpeechRecognizer 之比较

iOS 26 在现有的 SFSpeechRecognizer 之外，引入了一套全新的语音识别框架。新的 API 主体是 SpeechAnalyzer，再加上围绕它组合起来的模块（SpeechTranscriber、SpeechDetector）¹。苹果自己的定位是：SpeechAnalyzer 才是面向未来的路径。它带来全新的端侧模型、长音频支持、自动语言管理、可满足实时场景的低延迟，以及一套便于日后增加更多分析类型的模块化架构。SFSpeechRecognizer 仍在随系统提供，也仍然可用；继续留在旧框架的理由只剩下两点：对旧系统版本的支持，以及一处更窄的空缺——新框架长音频 SpeechTranscriber 模型上的自定义词汇，因为短语音的 DictationTranscriber 路径是可以接受 contextual strings 的。

本文把新框架与旧框架放在一起对照。切入点是”何时迁移”，而不是”如何使用新 API”，因为凡是已有一套可用 SFSpeechRecognizer 集成的团队，面对的都是同一道取舍题：新框架的现代模型与架构，是否值得付出迁移成本？还是说既有的自定义词汇投入足以让人按兵不动？

要点速览

• SpeechAnalyzer（iOS 26+）是苹果面向当下的端侧语音识别框架。它负责统筹在初始化时配置好的分析模块；iOS 26 随附三个模块：SpeechTranscriber（长音频）、DictationTranscriber（短语音，对应原先的 SFSpeechRecognizer 场景）和 SpeechDetector（语音活动检测，必须与某个转录模块搭配使用）²。
• 新框架是围绕长音频构建的：讲座、会议、多人对话。它完全在设备端运行，自动处理各语言区域的模型资源，并搭载苹果自研的新模型；据报道，在同等转录任务上，该模型比 Whisper Large V3 Turbo 快 2 倍³。
• SFSpeechRecognizer 仍在提供且可用——但自定义词汇已不再是它的专利。新框架的 AnalysisContext.contextualStrings（通过 SpeechAnalyzer.setContext(_:) 设置）可以为 DictationTranscriber 路径注册最多 100 条领域专有短语⁶。剩下的空缺是长音频的 SpeechTranscriber 模型，它不接受 contextual strings。
• 迁移是按功能推进的，不是非此即彼。需要长音频转录、更低延迟或更好远场音质的应用，应迁移到 SpeechAnalyzer。在自定义词汇上有投入的应用，也可以用 DictationTranscriber 加 contextual strings 迁移短语音听写；只有”长音频转录 + 自定义词汇”这一组合，才仍然构成保留旧 API 的理由。
• 本系列的 Vision 框架一文介绍了苹果另一项端侧感知基元；SpeechAnalyzer 则把同样的端侧、不上云的模式延伸到了音频。

架构：分析器 + 模块

SpeechAnalyzer 本身并不做转录。它是一个协调者，负责管理一次音频分析会话，并把音频缓冲区分发给一个或多个模块²。模块通过 init(modules:) 初始化方法在创建时配置好，分析则从 start(inputSequence:) 送入一串 AnalyzerInput 值的 AsyncSequence 开始——每个值包裹着一段音频缓冲区：

import Speech

let transcriber = SpeechTranscriber(
    locale: .current,
    transcriptionOptions: [],
    reportingOptions: [.volatileResults],
    attributeOptions: []
)
let analyzer = SpeechAnalyzer(modules: [transcriber])

try await analyzer.start(inputSequence: audioInputSequence)

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

iOS 26 随附三个模块：

SpeechTranscriber。 面向长音频（讲座、会议、多人对话）设计的语音转文字模块。它返回流式结果，包含逐词时间信息、置信度分数，以及一个供应用通过 for try await 消费的 results AsyncSequence。每条结果都带有 isFinal 标志，用来区分尚不稳定的中间假设与已定稿的文本。

DictationTranscriber。 针对旧有 SFSpeechRecognizer 场景的对位替代：短语音转录，使用与 SFSpeechRecognizer 相同的端侧模型。为短查询而从 SFSpeechRecognizer 迁移的应用应选 DictationTranscriber；为长音频录制而采用新框架的应用则选 SpeechTranscriber。这一区分很关键，因为 SpeechTranscriber 与 DictationTranscriber 的语言覆盖范围不同，走的模型路径也不同。

SpeechDetector。 语音活动检测。它会在音频流中语音开始和结束时上报事件。该检测器不能单独运行，必须与同一个 SpeechAnalyzer 实例中的某个转录模块搭配使用。应用可以借此约束转录的算力开销（不去转录静音段），或驱动界面提示（比如”请开始说话”的指示）。

模块化架构正是相较 SFSpeechRecognizer 的结构性改进。旧 API 把配置、缓冲区处理和结果投递都塞进 recognizer 与 request 这一对对象里，还依赖用户在”设置”中启用语言；新 API 则把会话协调者与分析模块拆开，应用需要什么就组合什么。

新模型带来了什么

SpeechTranscriber 背后的转录模型，是苹果专为这套框架开发的全新端侧模型⁴。苹果在 WWDC 2025 上强调的改进包括：

长音频质量。 该模型面向数分钟乃至数小时的持续转录训练，而不只是短查询。讲座、播客、多人会议和听写场景的转录精度，被苹果拿来与 Whisper 级别的模型相提并论。MacStories 的独立测试测得，在同等转录任务上它比 MacWhisper 的 Large V3 Turbo 版本快约 2.2 倍³。

远场音频处理。 摆在房间另一头的麦克风、多人围坐的会议桌音频、夹杂环境噪声的音频。新模型正是针对这些条件训练的；SFSpeechRecognizer 的旧模型处理起来则要吃力得多。

实时低延迟运行。 SpeechTranscriber 的流式结果，比旧框架 SFSpeechRecognitionRequest.shouldReportPartialResults 的回调到得更快。凡是要在界面上呈现实时转录的应用（字幕、语音驱动的界面、听写），都能获得更顺滑的更新。

自动语言管理。 苹果在这里的说法（这是我的转述，并非他们的原词）指的是模型与资源管理，而不是流中途切换语言。系统会通过 AssetInventory 下载并安装某个语言区域所需的模型资源，应用不必再手动打理各语言的模型可用性。一个转录器实例每次仍然只处理一个语言区域——这一点与旧框架相同——但过去让多语言支持变得麻烦的资源管道，如今归系统负责。

不增加应用体积。 模型随系统提供，而不是随应用打包。采用 SpeechAnalyzer 的应用无需再捆绑额外的模型权重。与把 Whisper 级模型塞进应用包相比，差别相当可观：一套有竞争力的端侧转录能力，占用的包体积为零字节。

旧框架仍然具备的优势

SFSpeechRecognizer 在 iOS 26 中仍在提供且可用。应用继续使用它的理由有三条：

长音频上的自定义词汇。 SFSpeechRecognitionRequest.contextualStrings 允许应用注册一份已知关键词清单（专有名词、专业术语、产品名称），让模型更有可能把它们识别准确。这个能力能显著提升领域专用应用的准确率（含药品名的医疗听写、含判例引用的法律应用、含零件编号的工程应用）。新框架针对听写路径也有自己的对应机制：AnalysisContext.contextualStrings 最多接受 100 条按标签分组的短语，通过 SpeechAnalyzer.setContext(_:) 设置到分析器上；在那里注册的短语，即便不在系统词汇表中也能被识别出来⁶。此外，DictationTranscriber 还可通过 ContentHint.customizedLanguage(modelConfiguration:) 这一内容提示接受自定义语言模型配置⁷。目前尚无对应物的，是长音频 SpeechTranscriber 模型上的 contextual strings——因此，如果一款应用需要在长音频转录上使用自定义词汇，迁移这条路径反而会造成功能退化。

旧系统版本支持。 SFSpeechRecognizer 从 iOS 10 起可用；SpeechAnalyzer 则要求 iOS 26 及以上。以 iOS 18 及更早版本为目标的应用，仍然需要旧框架。

已经跑得好好的集成。 若应用中的 SFSpeechRecognizer 集成稳定、经过审计、性能达标，就没有迫切的迁移理由。新框架的改进主要在新场景上见效（长音频转录、远场音频、多人对话）；那些通过旧 API 处理简短语音查询的应用，收益未必抵得上迁移成本。

何时迁移

有三个迁移信号值得点明。

应用要处理长音频。 会议录音工具、讲座转录应用、播客转文字工具。新模型在持续音频上的训练正好对路；旧模型则会随会话拉长而退化。这类场景应优先迁移。

应用需要处理远场或嘈杂的音频。 会议室转录、只用一支远处麦克风的访谈录音、在有环境噪声的场所采集的音频。这些条件下，新模型的表现明显更好。

应用要呈现实时转录界面。 字幕浮层、听写界面、语音驱动的无障碍界面。SpeechTranscriber 流式结果的低延迟，会让界面显得更跟手。

也有一些情况未必值得迁移：

• 依赖自定义词汇的长音频转录（比如必须准确捕捉药品名或判例引用的会议录音工具）。长音频 SpeechTranscriber 模型不接受 contextual strings，因此在苹果补上这处空缺之前，这一组合应继续留在 SFSpeechRecognizer 上。带自定义词汇的简短语音查询则可以干净利落地迁移——DictationTranscriber 加 AnalysisContext.contextualStrings 足以覆盖⁶。
• 需要支持 iOS 18 及更早版本的应用。SpeechAnalyzer 仅限 iOS 26；无论如何，代码库都得为旧目标保留旧框架。

并行共存模式

如果一款应用既要兼顾旧系统版本，又想在 iOS 26+ 上用到新框架的质量，那么并行共存是正确的做法：

import Speech

if #available(iOS 26.0, *) {
    let transcriber = DictationTranscriber(locale: .current, preset: .shortDictation)
    let analyzer = SpeechAnalyzer(modules: [transcriber])
    try await analyzer.start(inputSequence: audioInputSequence)
    for try await result in transcriber.results {
        if result.isFinal {
            handleTranscription(result.text)
        }
    }
} else {
    let recognizer = SFSpeechRecognizer(locale: .current)!
    let request = SFSpeechAudioBufferRecognitionRequest()
    request.shouldReportPartialResults = true
    request.requiresOnDeviceRecognition = true
    let task = recognizer.recognitionTask(with: request) { result, error in
        guard let result else { return }
        handleTranscription(result.bestTranscription.formattedString)
    }
}

在 iOS 26+ 这一分支里选 DictationTranscriber 是对的，因为迁移目标正是 SFSpeechRecognizer 的使用场景（用同一套听写模型处理短查询）。面向长音频的应用，只需在 iOS 26 分支中把 DictationTranscriber 换成 SpeechTranscriber。

两套框架可以共存；运行时判断会依据可用性挑选合适的一方。彼此互不阻塞，应用的转录管线自会随之适配。

隐私与语音授权面

两套框架在授权层面存在差异。SFSpeechRecognizer 保留了它专属的语音识别授权：Info.plist 中的 NSSpeechRecognitionUsageDescription，加上 SFSpeechRecognizer.requestAuthorization(_:) 弹出的授权提示⁵。SpeechAnalyzer 不走这条路——用它转录实时音频的应用需要麦克风权限（NSMicrophoneUsageDescription），而转录应用已经持有的音频则不再需要别的权限。隐私方面二者都是端侧：SpeechAnalyzer 在设计上就仅限端侧；SFSpeechRecognizer 则要在 SFSpeechRecognitionRequest 本身把 requiresOnDeviceRecognition 标志设为 true 时才在端侧运行——这是必须显式指定的，并非默认值，否则它可能走服务端路径。

这对并行共存模式的含义是：同时运行两套框架的应用会背上两套权限面——SpeechAnalyzer 分支的麦克风提示，以及旧分支的语音识别授权——App Store 的隐私”营养标签”也应把两者都体现出来。

对于把麦克风音频流送入分析器的应用，标准的 AVAudioSession 配置照常适用。本系列的 Privacy Manifest 一文介绍了使用 Speech 的应用需要填写的清单条目；就隐私声明而言，两套框架适用同一套规则。

与智能体工作流的联系

SpeechAnalyzer 的端侧模型与结构化输出，能与本系列的两种模式严丝合缝地衔接：

用 Foundation Models 做应用内推理。 先用 SpeechTranscriber 转录音频，再用端侧大模型（见 Foundation Models 端侧 LLM）总结转录文本，整条管线完全跑在设备上。网络请求总数：零。第三方数据暴露总量：零。

用 App Intents 驱动语音操作。 一个以转录文本为输入的 AppIntent，可以通过语音快捷指令（见作为平台能力的无障碍）或 Apple Intelligence 的操作入口来调用。该 intent 的 perform 方法运行 SpeechAnalyzer 转录输入，然后交给应用自身的逻辑处理。整个流程既私密又本地。

归结起来就是：新的 Speech 框架补齐了端侧感知的三角（Vision 管图像、Foundation Models 管语言推理、Speech 管音频），让完全本地化的 AI 功能在 iOS 应用中真正可行。

这一模式对 iOS 26+ 应用意味着什么

三点结论。

1. 新代码默认选用 SpeechAnalyzer。 现代模型、模块化架构，以及在长音频、远场与实时场景下更好的表现，让它成为合适的起点。旧框架则是备选项，用于需要支持旧系统版本、或需要在长音频转录上使用自定义词汇的场合。

2. 依赖词汇的应用按音频长度分流。 带自定义词汇的短语音听写可以迁移：DictationTranscriber 加 AnalysisContext.contextualStrings 就能承载这些领域术语⁶。带自定义词汇的长音频转录则继续留在 SFSpeechRecognizer 上，直到 SpeechTranscriber 模型开始接受 contextual strings 为止。两套框架可以共存；按功能混用才是正确的模式。

3. 端侧隐私的故事从 Vision 延伸到了 Speech。 那些围绕 Vision 端侧计算机视觉构建起来的应用，如今在音频上也有了对等能力。再配合负责推理的 Foundation Models，从感知到语言的完整管线都能在本地运行，无需向第三方暴露数据。

完整的 Apple Ecosystem 系列：类型化的 App Intents；MCP 服务器；路由之问；Foundation Models；运行时 LLM 与工具链 LLM 的区分；三个界面；单一数据源模式；两台 MCP 服务器；面向苹果开发的 hooks；Live Activities；watchOS 运行时；SwiftUI 的内部构造；RealityKit 的空间心智模型；SwiftData 的 schema 纪律；Liquid Glass 模式；多平台交付；平台矩阵；Vision 框架；Symbol Effects；Core ML 推理；Writing Tools API 的采用；Swift Testing；Privacy Manifest；作为平台能力的无障碍；SF Pro 字体系统；visionOS 空间模式；我拒绝写的那些题目。总目录在 Apple Ecosystem 系列。想了解 iOS 与 AI 智能体结合的更广背景，可参阅 iOS 智能体开发指南。

常见问题

SFSpeechRecognizer 被废弃了吗？

苹果并未正式废弃 SFSpeechRecognizer。它在 iOS 26 中仍随系统提供，也仍受支持。WWDC 2025 的说法是：对新代码而言，SpeechAnalyzer 是现代且推荐的路径；旧框架则适用于特定场景（长音频转录上的自定义词汇、旧系统版本支持）。

我能用 SpeechAnalyzer 处理预先录好的音频文件吗？

可以。SpeechAnalyzer.start(inputSequence:) 接受一串 AnalyzerInput 值的 AsyncSequence，每个值包裹一段音频缓冲区。应用可以把任意音频来源（通过 AVAudioEngine 采集的麦克风、录音文件 URL、AVAsset 实例）包装成 AsyncSequence 适配器再送给分析器。无论输入来自何处，转录流的消费方式都是同一句 for try await result in transcriber.results。

如果迁移，自定义词汇会怎么样？

这取决于迁移落到哪个转录模块上。听写路径是支持的：通过 AnalysisContext.contextualStrings 注册最多 100 条短语，用 SpeechAnalyzer.setContext(_:) 设置上下文，DictationTranscriber 便会使用它们⁶。长音频的 SpeechTranscriber 模型不接受 contextual strings，因此对词汇敏感的长音频转录，应继续留在配合 contextualStrings 的 SFSpeechRecognizer 上，直到苹果补上这处空缺。混合方案（通用转录用新框架、对词汇敏感的长音频路径用旧 API）在 iOS 26 上同样行得通。

我能在服务端运行 SpeechAnalyzer 吗？

不能。SpeechAnalyzer 是仅限端侧的框架，没有服务端路径。若要在服务端做转录，合适的工具是云 API（OpenAI Whisper API、Google Cloud Speech-to-Text、AWS Transcribe）或自托管模型。苹果这套框架的价值，恰恰在于端侧隐私与单次调用零成本。

语言检测是怎么工作的？

SpeechTranscriber(locale:) 为每个转录器实例接受一个语言区域，并且不支持流中途切换语言。iOS 26 自动化的是资源那一侧：AssetInventory 会下载并管理各语言区域的模型资源，因此支持多种语言不再意味着要手动打理模型可用性。对于语言事先已知的应用（比如已本地化应用中的听写功能），直接明确指定即可。对于多语言场景（比如说话者可能中途换语言的会议转录），先检测语言或让用户选择，再为该语言区域创建转录器。

这篇文章与本系列其他端侧机器学习的文章如何衔接？

SpeechAnalyzer 是端侧感知栈的第三根支柱：Vision（见 Vision 框架）负责图像，Speech 负责音频，而 Core ML（见 Core ML 端侧推理）是二者底层的引擎。语言推理则由 Foundation Models（见 Foundation Models 端侧 LLM）承担。它们合在一起，构成一条无需网络请求的完整端侧 AI 管线。

参考资料