Swift 包 AnySpeechRecognizer 支持本地跑 Qwen3-ASR

语言模型能做很多事。 它们能写作、总结、翻译和调用工具。 但它们只是机器学习能力的一小部分。

假设有客户打来你的支持热线。 首先，你想知道他们说了什么（语音识别）。 然后，你想决定把他们转接到哪里（决策）。 你可以把这两件事都交给语言模型， 但有一些专为各自任务构建的模型， 更好、更快、也更便宜。

在我们的AnyLanguageModel 1.0 回顾中， 我们回顾了 Swift 中一年来的本地和托管模型。 随着 AnyLanguageModel 和 swift-huggingface 现已发布 1.x 版本， 我们正把同样的方法扩展到语音和决策： 熟悉的 Swift API，加上可选的模型。

今天我们宣布两个软件包：

• AnySpeechRecognizer实现了 Apple 新的语音转文本 API，并可选识别引擎， 包括在 Core ML 上本地运行的 NVIDIA Parakeet 和阿里巴巴 Qwen3-ASR， 并新增说话人分离，以追踪谁在何时说话。
• AnyDecisionModel回答是/否、多项选择和评分量表问题， 返回带类型的结果和概率。 它从模型的概率推导出每个答案， 而不是生成文本， 使用你设备上通过 MLX、Core AI 或 llama.cpp 运行的模型， 或来自 Jev 或 Ollama 的决策模型。

两个软件包都能从 HF Mirror Hub 下载开源模型 并在设备上运行。

AnySpeechRecognizer

计算机转写语音已有数十年， 而在过去几年里，它们在这方面变得非常出色。 Apple 平台已经有对应的 API。 macOS 26 和 iOS 26 引入了SpeechAnalyzer， Apple 新的语音转文本 API。 你向分析器添加诸如SpeechTranscriber和SpeechDetector之类的模块， 给它一个文件或音频缓冲区流， 并从异步序列中读取陆续到达的结果。AssetInventory负责安装模型， 因此由你的应用决定下载何时发生。

这是一个设计良好的 API， 但它背后唯一的引擎是 Apple 的。 AnySpeechRecognizer 保留该 API，并让你选择引擎：

- import Speech
+ import AnySpeechRecognizer

该软件包镜像了SpeechAnalyzer，SpeechTranscriber，DictationTranscriber，SpeechDetector，以及AssetInventory， 以 Apple 的 Speech 框架作为默认引擎。 如果你的代码使用那套共享 API，只需更改 import 即可。 要改用 Parakeet， 只需更改创建转写器的方式：

let transcriber = SpeechTranscriber(
    model: ParakeetSpeechModel(variant: .v3),
    transcriptionOptions: [],
    reportingOptions: [.volatileResults],
    attributeOptions: [.audioTimeRange]
)

安装资源、运行分析器和读取结果的步骤保持不变。README有一个完整的示例并列出了差异与 Apple 框架的不同之处。

认识这些模型

Parakeet v3是 NVIDIA 的Parakeet TDT 0.6B v3。它是一个多语言模型：它能识别 25 种欧洲语言，并判断出听到的是哪一种，因此你无需传入区域设置。

Parakeet Ultra是 Moondream 的对 v3 进行后训练得到的版本。在我们的大多数测量中，它都更准确。

Parakeet Unified是 NVIDIA 的仅支持英语的 Parakeet。

三个 Parakeet 模型都运行在该包自有的 Core ML 运行时上，它支持文件和实时输入、易变结果、词级时间戳以及词级置信度。

Qwen3-ASR是阿里巴巴的语音模型，0.6B和1.7B两种规模。它可识别 30 种语言和 22 种中文方言，包括普通话、粤语、日语和韩语，这些是 Parakeet 不支持的。它会自动检测语言，你也可以手动指定一种：

let transcriber = SpeechTranscriber(
    model: QwenSpeechModel(variant: .large, language: Locale.Language(identifier: "yue")),
    transcriptionOptions: [],
    reportingOptions: [],
    attributeOptions: []
)

Qwen3-ASR 对每段最长 40 秒的音频给出一个最终结果，不提供易变结果、词级时间戳或置信度。它运行在 GPU 上，比 Parakeet 慢，因此更适合转写文件而非实时输入。

要添加另一个引擎，请实现SpeechRecognitionModel用于其配置SpeechRecognitionExecutor用于单个模块的会话。小型提供方，它会报告占位文本，帮助你上手。

Hub 上的 Core ML 模型

要在应用中使用这些模型，我们将它们转换为 Core ML 并发布在 Hub 上：

每个仓库都记录其源检查点 以及每个文件的校验和， 并且包将其固定到某个固定修订版本。 Parakeet 仓库新增了一个用于实时输入的 8 秒编码器， 这使实时分析时间缩短约三分之一， 代价是词错误率略有升高。 该仓库还包含转换工作流， 其中大部分遵循 FluidInference 的mobius脚本， 并针对原始模型校验每次转换。

仅当你的应用请求时才会下载： 每个 Parakeet 约 600 MB，实时编码器另需约 590 MB， Qwen3-ASR 为 0.9 至 2.4 GB，Sortformer 约 250 MB。 文件存放在标准的 HF Mirror 缓存中， 因此沙盒之外的 Mac 应用可与 Python 及其他 HF Mirror 工具共享它们。

说话人分离

转写对话时， 你常常想知道哪句话是谁说的。 这就是说话人分离， 而 Apple 的 Speech 框架没有相应模块， 因此 AnySpeechRecognizer 补充了一个。SpeakerDiarizer在 Core ML 上 运行 NVIDIA 的Streaming Sortformer与 Apple 或 Parakeet 转写器并行， 处于同一时间线上：

let diarizer = SpeakerDiarizer(model: SortformerDiarizationModel())
if let request = try await AssetInventory.assetInstallationRequest(
    supporting: [transcriber, diarizer]
) {
    try await request.downloadAndInstall()
}
let analyzer = SpeechAnalyzer(modules: [transcriber, diarizer])

该分离器最多跟踪四位说话人， 即使他们互相抢话。 一个SpeakerTimeline收集其结果， 并将每个带时间戳的词归属到某位说话人， 因此你可以按说话人轮次打印转写文本。 与 AnyLanguageModel 中的图像支持一样， 这超出了 Apple API 目前提供的能力。

分离器默认使用 Sortformer v2。 你也可以选择v2.1， NVIDIA 用更多会议数据对其进行了训练， 在我们的测量中，它在会议场景下也更准确。

效果如何？

我们用该包自带的hear命令行工具

Parakeet 从文件转写一小时音频约需 20 到 40 秒，实时转写约需 1.5 到 2.5 分钟，Core ML 编译模型后内存占用约 100 MB。Qwen3-ASR 慢得多，且需要数 GB 内存。会议场景对所有人来说都很难：在 AMI 录音中，人们会互相抢话，我们测试的每个引擎的词错误率都高于 23%。

这些数字来自一台机器和少数几个数据集，所以请用你自己的硬件和音频进行测量。hear evaluate可处理你自己的文件，并且该仓库的natural-speech-eval.py工具可复现这些测量结果。到目前为止，我们只在 macOS 27 上测试过，尚未在 iPhone 上测试。

接下来，我们希望加入更多引擎，包括 macOS 27 和 iOS 27 上的 Core AI。

AnyDecisionModel

AnyDecisionModel 则是另一回事。没有可映射的 Apple 框架，而且决策模型严格来说也不算新事物。

只有来自法国 Décision 地区的才算决策模型；否则，它只是起泡的零样本分类。

新的是这个名字、大量炒作，以及一批被训练来做决策的模型。我们认为这就是未来的方向，所以我们想要一个为它们准备好的 Swift API。

应用经常让语言模型做决策。这条消息紧急吗？ 这个工单应该由哪个团队处理？ 这位客户有多沮丧？通常的做法是给语言模型一个提示，然后解析它生成的文本。这样你能得到一个答案，但看不到它给各个备选项分配的概率。

在 Swift 中，一个决策看起来是这样的：

import AnyDecisionModel

enum Department: String, Choosable {
    case billing, technical, sales
}

let ticket = "我的订单被扣了两次款，现在我想申请退款时，应用却把我登出了。"

let model = MLXDecisionModel(modelID: "mlx-community/Qwen3-4B-Instruct-2507-4bit")
let session = DecisionSession(model: model, state: .text(ticket))

let urgent = try await session.probability(of: "这是否表达了紧急？")
let team = try await session.choice("哪个团队？", from: Department.self)
let anger = try await session.score(
    "有多沮丧？",
    levels: ["平静", "沮丧", "非常愤怒"]
)

urgent是一个Double。team是一个Choice<Department>，包含所选 case、每个选项的概率以及一个置信度值。anger是一个Score，包含预期级别、每个级别的概率以及一个置信度值。因为Department符合Choosable，team.value是一个Department，你可以在穷尽的switch中使用它。

如果你用过 Foundation Models 或 AnyLanguageModel，这种模型加会话的模式会看起来很熟悉。ADecisionSession持有一个单一状态，可以是文本或 JSON，每个问题都是关于该状态的。问题之间相互独立：一个答案永远不会成为后续问题的输入。要一次提出多个问题，请将它们作为一批传给decide(_:)。

对于每个问题，MLX 后端会构建一个提示，为每个允许的答案分配一个单 token 标签，然后从一次前向传播中读取每个标签的概率。

试一试：Emoji Magnet

Emoji Magnet 是一个 macOS 应用，在一个包含 343 个 emoji 的堆叠上方有一个文本输入框。输入一个短语，例如 "things you wear"，匹配的 emoji 就会从堆叠中升起。将其细化为 "things you wear in winter"，不再匹配的 emoji 就会落回。

该应用没有内置的关键词规则；一切由模型在推理时决定。当你暂停输入时，它会针对每个 emoji 向模型提出一个是/否问题，例如：

Statement: a heavy winter coat fits the description "things you wear". Is this statement true?

会话的状态保存该短语。上面的演示使用托管的 Jev 后端，它在一次请求中回答全部 343 个问题，因此每个短语的 emoji 大约在半秒内稳定下来。如果没有TYPESAFE_AI_API_KEY，该应用会在你的 Mac 上使用 MLX 后端运行 Qwen3 4B。该后端使用前缀缓存来对状态求值一次，然后在每次前向传播中回答 16 个问题。在 M4 Max 上，模型加载后一组 16 个问题大约需要 0.45 秒。对全部 343 个 emoji 的完整遍历大约需要 10 秒，每组结果一到达就会立即显示。

Emoji Magnet 位于AnyDecisionModel-Examples仓库中。

决策头与 Clef

读取下一 token 概率适用于通用语言模型，但这些模型并未经过训练来做出决策。Cloudflare 的Clef模型Clef-Flash是 9B 变体。

AnyDecisionModel 在 Mac 上使用 MLX 运行 Clef-Flash：

let model = MLXHeadDecisionModel(
    modelID: "mlx-community/clef-flash-4bit",
    head: .jointSchema
)

你使用相同的会话和问题，但MLXHeadDecisionModel从 Clef 训练好的决策头读取每个决策，而不是从下一 token 概率中读取。4-bit 模型是一个 6.2 GB 的下载文件，其模型卡建议使用至少 16 GB 内存的 Mac。Clef 可以读取图像和视频，但此后端只接受文本和 JSON 状态。

校准和检查概率

语言模型给出的原始概率往往过度自信。本地后端接受一个Calibration，它对每个答案应用温度，并对是/否答案应用偏置。使用单独的数据集来拟合校准并评估结果。

语言模型也可能因为某个选项在列表中的位置而偏向它。在 MLX、Core AI 和 llama.cpp 的下一 token 后端上，开启rotationDebiasing以对选项的每种轮换各问一次选择题，并对概率取平均。每次轮换需要一次提示评估。

每个本地选择和评分还包含一个基于其概率熵的置信度值。它衡量的是概率的集中程度，而不是答案是否正确，因此在选择阈值之前，请先在自己的数据上检查错误率。下一 token 后端的诊断信息会报告模型分配给允许答案的概率有多少。数值低意味着它把大部分概率分配到了别处。

后端

AnyDecisionModel 有六个后端：

• MLX在 Apple 芯片上运行一个小型语言模型，使用mlx-swift-lm并从 Hub 下载它。
• MLX 决策头运行带有自己训练好的决策头的模型，例如 Clef。
• Core AI在 macOS 27 和 iOS 27 上使用 Core AI 模型做与 MLX 相同的事。
• llama.cpp通过llama.swift从本地 GGUF 模型读取决策。
• Jev通过System One API调用 TypeSafe 的 Jev，或任何实现了它的服务器，例如Kev。
• Ollama在本地 Ollama 服务器或 Ollama 的云中调用 System One 决策模型。它需要 Ollama 0.35.0 或更高版本，云模型则需要 0.40.5 或更高版本。

下一 token 后端将答案标记为“yes”和“no”、A 到 Z 或 0 到 9，因此一个选择题最多可有 26 个选项，一个评分最多可有 10 个等级。决策头没有这种限制。

与 AnyLanguageModel 一样，该包使用 Swift 包特性（package traits）。不启用特性时，它没有第三方依赖。你会得到核心类型以及 Jev 和 Ollama 后端，它们也能在 Linux 上构建。为本地后端启用MLX、CoreAI或Llama特性。

开始使用

两个包都要求 Swift 6.2 或更高版本，以及 macOS 26 或 iOS 26 或更高版本。Parakeet 和 Sortformer 运行时以及 MLX 后端需要 Apple silicon。AnyDecisionModel 的 MLX 构建任务使用 Xcode 的 Swift 6.4 或更高版本以及 Metal 工具链；Core AI 需要 Xcode 27 和 OS 27 运行时。

将包添加到你的Package.swift：

dependencies: [
    .package(url: "https://github.com/mattt/AnySpeechRecognizer", from: "0.1.0"),
    .package(
        url: "https://github.com/mattt/AnyDecisionModel",
        from: "0.6.0",
        traits: ["MLX"]
    ),
]

目前，AnyDecisionModel 的CoreAItrait 无法与 AnySpeechRecognizer 组合使用，因为 coreai-kit 0.7.3 要求 swift-huggingface 低于 1.0，而 AnySpeechRecognizer 要求 1.x。

每个 README 都有更多示例以及关于要求和后端的详细信息。AnySpeechRecognizer 还包含一个命令行工具，hear，它可以转写本地文件、标注其说话人，并评估结果。hear每个--backend apple命令都需要--backend parakeet、--backend qwen或hear prepare；在分析之前，使用相同的后端和模型选项运行

以安装所需的资源。在你的应用中试用它们，并告诉我们哪些可行、哪些不可行。两个仓库都欢迎提交 issue 和 pull request。

链接

• GitHub 上的 AnySpeechRecognizer
• GitHub 上的 AnyDecisionModel
• GitHub 上的 AnyDecisionModel-Examples
• GitHub 上的 AnyLanguageModel
• GitHub 上的 swift-huggingface

感谢 NVIDIA 提供 Parakeet、Sortformer 和 NeMo，感谢 Moondream 提供 Parakeet Ultra，感谢 FluidInference——其 FluidAudio 和 mobius 项目记录了 Parakeet 运行时和 Core ML 转换所遵循的约定，感谢 Cloudflare 提供 Clef，也感谢所有为 AnyLanguageModel 做出贡献的人，两个包都借鉴了它的模式。