Apple全新Speech框架：SpeechAnalyzer对比SFSpeechRecognizer

iOS 26在现有的SFSpeechRecognizer之外引入了一个全新的语音识别框架。新的API入口是SpeechAnalyzer，配合围绕它组合的模块（SpeechTranscriber、SpeechDetector）¹。Apple官方的定位是：SpeechAnalyzer是现代化路径——全新的设备端模型、长音频支持、自动语言管理、面向实时场景的低延迟，以及支持随时间扩展更多分析类型的模块化架构。SFSpeechRecognizer仍会继续维护并正常运行；对于依赖其自定义词汇功能的应用而言，它依然是合适的工具，因为新框架尚未提供该功能。

本文将新框架与旧框架进行对照梳理。切入点是”何时迁移”，而非”如何使用新的API”，因为每个已有可用SFSpeechRecognizer集成的团队都面临同样的取舍：新框架的现代模型与架构是否值得迁移成本，还是已有的自定义词汇投入足以让团队留在旧框架？

TL;DR

• SpeechAnalyzer（iOS 26+）是Apple现代化的设备端语音识别框架。它协调初始化时配置的分析模块；iOS 26内置三个模块：SpeechTranscriber（长音频）、DictationTranscriber（短语句，对应SFSpeechRecognizer的等价模块）和SpeechDetector（语音活动检测，必须与转录模块搭配使用）²。
• 新框架围绕长音频构建：讲座、会议、多人对话。它完全在设备端运行，自动管理语言，并搭载Apple全新的专有模型，据报道在等价的转录任务上比Whisper Large V3 Turbo快2倍³。
• SFSpeechRecognizer仍会继续维护并正常运行。旧框架保留了自定义词汇功能（注册已知关键词以提升领域术语的识别准确率），新框架尚未提供此功能。

• 迁移按功能逐项进行，并非全有或全无。需要长音频转录、更低延迟或更好远场音频质量的应用迁移到SpeechAnalyzer。已有自定义词汇投入的应用为这些功能保留SFSpeechRecognizer，并为新功能添加SpeechAnalyzer。

• 本系列的Vision框架文章介绍了Apple的另一项设备端感知原语；SpeechAnalyzer将同样的设备端、无云端模式延伸到了音频领域。

架构：分析器+模块

SpeechAnalyzer本身并不是转录器。它是一个协调器，负责管理音频分析会话，并将音频缓冲区分发给一个或多个模块²。模块通过init(modules:)初始化器在初始化时配置，分析则通过start(inputSequence:)传入音频缓冲区的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。 专为长音频（讲座、会议、多人对话）设计的语音转文本模块。返回流式结果，包含每个token的时间信息、置信度分数，以及应用通过for try await消费的results AsyncSequence。每个结果都带有isFinal标志，用于区分易变的部分假设与最终文本。

DictationTranscriber。 旧版SFSpeechRecognizer场景的直接替代品：使用与SFSpeechRecognizer相同的设备端模型进行短语句转录。从SFSpeechRecognizer迁移过来处理短查询的应用应选择DictationTranscriber；为长音频录制采用该框架的应用应选择SpeechTranscriber。这种区分很重要，因为SpeechTranscriber和DictationTranscriber使用不同的语言覆盖范围和不同的模型路径。

SpeechDetector。 语音活动检测。在音频流中检测到语音开始和结束时上报事件。检测器无法独立运行；必须与同一SpeechAnalyzer实例中的某个转录模块搭配使用。应用可用它来控制转录算力（不转录静音段），或驱动UI提示（”现在开始说话”指示器）。

模块化架构是相对于SFSpeechRecognizer的结构性改进。旧API将音频会话管理、语言检测和转录合并到单一对象；新API分离了关注点，应用可按需组合所需模块。

新模型带来了什么

SpeechTranscriber背后的转录模型是Apple专门为该框架开发的全新设备端模型⁴。Apple在WWDC 2025上重点展示的改进包括：

长音频质量。 该模型针对持续数分钟乃至数小时的转录进行训练，而不仅是短查询。讲座、播客、多人会议和听写会话的转录精度可与Whisper级模型相提并论。MacStories的独立测试显示，在等价的转录任务上比MacWhisper的Large V3 Turbo版本快约2.2倍³。

远场音频处理。 房间另一端的麦克风、有多位发言者的会议桌音频、带环境噪声的音频。该模型针对这些场景进行了训练；SFSpeechRecognizer的旧模型处理这些情况时表现欠佳。

实时低延迟运行。 SpeechTranscriber的流式结果比旧框架的SFSpeechRecognitionTask.shouldReportPartialResults回调到达得更快。需要呈现实时转录的应用（字幕、语音驱动UI、听写）可获得更流畅的更新。

自动语言管理。 SpeechTranscriber(locale:)接受一个起始locale，但模型能适应流中途的语言切换。旧框架则要求开发者为每种语言实例化对应的识别器，并在它们之间切换。

无应用体积成本。 该模型随系统下发，而非随应用下发。采用SpeechAnalyzer的应用无需打包额外的模型权重。与在应用包内打包Whisper级模型相比，差异显著：一套有竞争力的设备端转录栈付出的包体字节数为零。

旧框架仍能提供什么

SFSpeechRecognizer在iOS 26中仍会继续维护并正常运行。应用可能继续使用它的三个理由：

自定义词汇。 SFSpeechRecognitionRequest.contextualStrings允许应用注册一系列已知关键词（专有名词、技术术语、产品名称），让模型更可能准确识别它们。该功能可大幅提升领域专用应用的准确率（带药品名的医疗听写、带案例引用的法律应用、带零件编号的工程应用）。SpeechAnalyzer尚未提供自定义词汇；对依赖该功能的应用而言，迁移意味着精度回退。

支持更老的系统版本。 SFSpeechRecognizer从iOS 10起可用；SpeechAnalyzer要求iOS 26+。面向iOS 18及更早版本的应用需要旧框架。

已有可用集成。 拥有稳定、经过审计、性能良好的SFSpeechRecognizer集成的应用没有迫切的迁移理由。新框架的改进对新场景（长音频转录、远场音频、多人对话）最为关键；通过旧API处理短语音查询的应用可能收益不足以证明迁移的合理性。

何时迁移

值得说明的三个迁移触发场景：

应用处理长音频。 会议录音器、讲座转录应用、播客转文本工具。新模型对持续音频的训练正合适；旧模型在长会话中会出现质量衰减。优先迁移。

应用需要远场或嘈杂音频。 会议室转录、单只远距麦克风的访谈录音、在有环境噪声的环境中采集的音频。新模型在这些场景下的表现明显更好。

应用展示实时转录UI。 字幕叠加、听写界面、语音驱动的辅助UI。SpeechTranscriber流式结果的更低延迟让UI感觉更响应迅捷。

不一定值得迁移的场景：

• 带自定义词汇的短语音查询（处方听写、法律术语）。保留SFSpeechRecognizer以使用词汇功能；如果Apple在未来版本中添加词汇支持，再考虑SpeechAnalyzer。
• 需要支持iOS 18及更早版本的应用。SpeechAnalyzer仅限iOS 26；无论如何，代码库都需要旧框架来支持更老的目标版本。

并行使用模式

对于既要支持旧系统版本，又希望在iOS 26+上获得新框架质量的应用，并行使用是合适的方式：

import Speech

if #available(iOS 26.0, *) {
    let transcriber = DictationTranscriber(locale: .current)
    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)
    }
}

DictationTranscriber是iOS 26+分支的合适选择，因为迁移目标正是SFSpeechRecognizer的使用场景（带相同听写模型的短查询）。面向长音频的应用应在iOS 26分支中将DictationTranscriber替换为SpeechTranscriber。

两个框架可以共存；运行时检查会根据可用性选择合适的那一个。彼此互不阻塞；应用的转录管线据此自适应。

隐私与Speech授权入口

两个框架共享相同的Speech框架权限（Info.plist中的NSSpeechRecognitionUsageDescription）和相同的用户授权流程⁵。隐私机制是一致的：两个框架的语音转录都在设备端进行。SpeechAnalyzer从设计上就是仅设备端的；SFSpeechRecognizer在SFSpeechRecognitionRequest本身的requiresOnDeviceRecognition标志被设为true时默认使用设备端，否则可能回退到服务端路径。

由此带来的影响是：使用SpeechAnalyzer的应用仍需正确处理Speech授权。用户提示、设置项、App Store隐私营养标签都使用同一套授权机制。

对于将麦克风音频流传给分析器的应用，标准的AVAudioSession配置同样适用。本系列的隐私清单文章介绍了使用Speech的应用所需的清单条目；两个框架都受同一隐私声明的约束。

与Agent工作流的连接

SpeechAnalyzer的设备端模型与结构化输出与本系列两个模式天然契合：

用Foundation Models进行应用内推理。 用SpeechTranscriber转录音频，再用设备端LLM（详见Foundation Models设备端LLM）总结转录文本的管线，可完全在设备端运行。网络调用总数：零。第三方数据暴露总量：零。

用App Intents驱动语音操作。 接受转录文本作为输入的AppIntent可通过Vocal Shortcuts（详见无障碍即平台）或Apple Intelligence的操作入口被调用。intent的perform方法运行SpeechAnalyzer转录输入，然后分发到应用逻辑。整个流程是私密且本地的。

模式如下：新的Speech框架补全了设备端感知三角（Vision处理图像、Foundation Models进行语言推理、Speech处理音频），让完全本地化的AI功能在iOS应用中真正可行。

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

三点要义。

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

2. 依赖词汇功能的应用保留SFSpeechRecognizer。 在Apple为新框架添加自定义词汇之前，依赖contextualStrings提升领域术语精度的应用应保留旧API。两个框架可以共存；按功能混用是合适的模式。

3. 设备端隐私机制从Vision延伸到Speech。 围绕Vision设备端CV构建的应用如今对音频也有了等价能力。结合Foundation Models进行推理，从感知到语言的完整管线可在本地运行，无需暴露任何第三方数据。

完整的Apple Ecosystem系列：类型化App Intents；MCP服务器；路由问题；Foundation Models；运行时与工具链LLM之分；三种入口；单一事实来源模式；两个MCP服务器；面向Apple开发的hooks；Live Activities；watchOS运行时；SwiftUI内部机制；RealityKit的空间心智模型；SwiftData模式纪律；Liquid Glass模式；多平台发布；平台矩阵；Vision框架；Symbol Effects；Core ML推理；Writing Tools API；Swift Testing；隐私清单；无障碍即平台；SF Pro字体系统；visionOS空间模式；我拒绝写什么。系列首页位于Apple Ecosystem Series。如需更宏观的iOS与AI agent结合的背景，请参阅iOS Agent开发指南。

FAQ

SFSpeechRecognizer是否已被弃用？

Apple尚未正式弃用SFSpeechRecognizer。它在iOS 26中继续维护并仍受支持。WWDC 2025的定位是：SpeechAnalyzer是新代码现代化的推荐路径；旧框架适用于特定场景（自定义词汇、支持更老的系统版本）。

我可以用SpeechAnalyzer处理预录音频文件吗？

可以。SpeechAnalyzer.start(inputSequence:)接受音频缓冲区的AsyncSequence。应用可将任意音频源（通过AVAudioEngine的麦克风、预录文件URL、AVAsset实例）封装为AsyncSequence适配器，并送入分析器。无论输入来源是什么，转录流都通过相同的for try await result in transcriber.results方式消费。

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

SpeechAnalyzer / SpeechTranscriber目前不支持自定义词汇。依赖该功能获取领域专用精度的应用在Apple添加该功能之前不应迁移这条路径。混合方案（用SpeechAnalyzer进行通用转录，用带contextualStrings的SFSpeechRecognizer处理对词汇敏感的转录）在iOS 26下可行。

我可以在服务端运行SpeechAnalyzer吗？

不行。SpeechAnalyzer是一个仅设备端的框架。它没有服务端路径。服务端转录的合适工具是云端API（OpenAI Whisper API、Google Cloud Speech-to-Text、AWS Transcribe）或自托管模型。Apple框架的价值正是设备端隐私和零次调用成本。

语言检测是如何工作的？

SpeechTranscriber(locale:)接受一个初始locale。模型能自动适应流中途的语言切换。对于事先已知语言的应用（已本地化应用的听写功能），明确指定即可。对于多语言场景（发言者可能切换语言的会议转录器），自动管理是合适的行为。

这与本系列其他设备端ML文章如何结合？

SpeechAnalyzer是设备端感知栈的第三根支柱：Vision（详见Vision框架）处理图像，Speech处理音频，Core ML（详见Core ML设备端推理）是两者底层的引擎。Foundation Models（详见Foundation Models设备端LLM）处理语言推理。它们共同构成完整的设备端AI管线，无需任何网络调用。

参考资料