一个作为研究检查点发布的语音识别模型，通常就是一个装着 PyTorch 权重的文件夹、一份训练脚本，以及一条说明它是在哪块 GPU 上训练的备注。这足以复现一个基准分数，却不足以把它装进一台树莓派、一部手机，或一台没有网络连接的笔记本电脑。从前者走到后者，是转换工作，而这项工作在很大程度上决定了一个开放语音模型能否真正抵达一台真实设备。
我们靠做这项转换工作为生：把开放的 ASR（自动语音识别，即语音转文本）和 TTS（文本转语音）模型，转变成能够离线运行的文件——运行在普通 CPU 或设备端加速器上，运行时无需任何 Python 训练技术栈。大多数成果都发布在 Hugging Face 上的 OpenVoiceOS 组织名下，而非我们自己的账号——这个选择是刻意的，原因见下文。
为什么检查点不等于可部署
一个 PyTorch 或 NeMo 检查点期待一个特定的 Python 环境：正确的库版本、通常还要一块 GPU，以及仅仅为了跑推理就需要的整个训练框架本身。这套技术栈庞大、变化不断，也不是你想塞进一个必须在一块小板子上启动的语音助手里的东西。
模型导出解决的正是这个问题：把训练好的网络转换成一种专为推理而生的格式——没有训练代码，没有自动求导，也不锁定在某个框架上。我们瞄准三种这样的格式，各自对应不同的部署形态：
- ONNX（开放神经网络交换格式）是一种可移植的计算图格式，广泛的运行时都能执行它，无论是在 CPU 还是 GPU 上，无论是 Linux、Windows、macOS 还是嵌入式板卡。这是我们的默认目标，因为凡是
onnxruntime能跑的地方它都能跑——那几乎是无处不在。 - CoreML 是苹果的设备端推理格式。一个 CoreML 包运行在 Mac 或 iPhone 的神经网络引擎或 GPU 上，而非 CPU，这对苹果硬件上的实时语音识别很重要。
- GGUF 是
llama.cpp及其生态所用的格式，为需要以极小内存占用运行的量化、类 LLM 模型而生。我们把它用于较新的、基于 transformer 的语音模型——这些模型在架构上更接近语言模型，而非经典的声学模型。
选对目标格式并非表面功夫。一个基于 conformer 的 ASR 模型（多数现代语音识别器背后的架构，结合了卷积和自注意力）可以干净地转换为 ONNX 或 CoreML。而一个基于 Qwen3 的语音模型，其底层其实是一个语言模型，因此它自然更适合走 GGUF/llama.cpp 流水线。
量化的代价与收益
量化，是指用更少的比特位来存储模型的权重数值——用 16 位、8 位或 4 位，取代训练时所用的 32 位浮点数。更小的数值意味着更小的文件；在合适的硬件上，也意味着更快的推理，因为要搬运的数据更少，运算也更便宜。
我们可以为一个真实模型给出确切的换算数字。nvidia/parakeet-tdt-0.6b-v3 是一个 6 亿参数的 ASR 模型。它的 CoreML mel 编码器组件在全精度下是 1132.5 MB；调色板量化（palettize）到 4 位后变为 284.2 MB——缩小了 3.99 倍，在其三个子组件（编码器、解码器、联合决策网络）之间几乎完全一致地匹配。整个软件包算下来，未量化的 CoreML 导出版本约为 1.14 GB；4 位版本约为 293 MB。这就是一个模型能否舒适地装进一部手机、还是勉强才能塞下之间的差距。
代价是准确率：每个权重的比特位越少，精度就越低，一旦超过某个临界点，就会表现为更多的识别错误。衡量 ASR 这一点的标准方式是 WER（词错误率——模型识别错误的词语相对于正确转录文本的百分比）。这就是为什么我们会把同一个模型的多个量化级别——4 位、6 位、8 位（int8）和 fp16——并排发布出来，而不是只挑一个然后寄望它对所有设备都够用。手机和台式机能承受的曲线上的位置是不同的。
验证问题
一次悄无声息地产出更差输出的转换，比压根没做转换更危险，因为它看起来一点也不像坏了——它能加载、能运行，只是识别语音的效果稍差一点，或者，在一门你自己不会说、无法靠耳朵抽查的语言上，效果差了很多。发现这一点的唯一办法，是在发布之前，针对每一种语言、每一个量化级别，用真实音频把导出模型的输出与原始参考实现进行比较。
这是我们发布的任何转换都必须满足的基本要求：把同一段音频分别喂给源模型和转换后的模型，确认两者一致。这不是什么光鲜的步骤，但跳过它，正是一门”受支持的语言”悄悄停止工作的方式。
为什么这些模型归属于 OpenVoiceOS，而非我们自己
模型导出是一项公司能力：给我们一个检查点和一个目标设备，我们就能让它离线运行起来，经过验证，量化级别匹配你的硬件。但我们从开放的、非委托的检查点产出的转换模型，会发布到 OpenVoiceOS——这些模型本就是为在其上运行而构建的开放语音助手平台——而不是发布到我们自己的命名空间下。
理由很直接：OpenVoiceOS 才是这些模型被实际使用的地方。一个躺在公司账号里的转换模型只是一件不错的成果物。而同一个模型发布在 ovos-stt-plugin-onnx-asr、ovos-stt-plugin-coreml 或 ovos-stt-plugin-rover 能按名字找到它的地方，就变成了一门一个真实助手现在能说、能听懂的语言。发布在平台自己的组织名下，正是把一次转换变成受支持的功能、而非一件研究奇珍的关键，也是我们确保这项工作做一次就能让每一个 OpenVoiceOS 安装受益、而不只是提出请求的那位客户受益的方式。
关于署名，我们想说清楚：我们并不从零训练这些声学模型，也从不这样声称。背后的研究——英伟达的 Parakeet 和 Conformer 模型、AI4Bharat 面向印度诸语言的 IndicConformer 模型、大学与公共机构的模型，例如加利西亚的 Proxecto Nós 或巴斯克 HiTZ 中心的 Conformer 模型，以及为非洲和少数族群语言转换模型的独立努力——都归功于训练它们的团队。我们所增添的，是转换、量化、对照原始模型的正确性校验，以及让一个助手能按名字加载结果的插件接线工作。
这项转换工作的规模，直接从已发布的内容统计而来：超过九十个 Parakeet ASR 变体（跨尺寸、语言和量化级别）导出为 ONNX 和 CoreML；三十多个英伟达 Conformer 模型；二十二个覆盖低资源印度诸语言的 AI4Bharat IndicConformer 模型；二十二个 wav2vec2 模型，覆盖瑞典语、冰岛语、法罗语、芬兰语，以及两种书面形式的挪威语；九个面向巴斯克语和加利西亚语的 Conformer 模型；以及独立转换的 Whisper 和 wav2vec2 模型，覆盖修纳语、祖鲁语、科萨语、马达加斯加语、海地克里奥尔语和卡拜尔语等非洲及克里奥尔语言。仅按不同语言代码统计已确认的 ASR 转换，如今至少有 74 种不同语言拥有可用的离线量化语音识别器——这还不包括为巴斯克语、阿拉贡语、阿斯图里亚斯语、加利西亚语、奥克语和阿拉伯语等语言单独导出的 TTS 语音目录。
如果你的语言或你的设备今天还没有任何离线方案
大多数语言从未获得过一个商业化的离线语音方案，因为仅凭那一门语言的市场，还不足以让某家供应商专门为它构建一个。上文的模式——拿一个现有的开放检查点，把它转换成能在你实际拥有的硬件上运行的格式，量化到合适的大小，对照原始模型加以验证，再接入一个插件——并不依赖市场规模。它依赖的是有一个开放检查点作为起点，而这正日益成为常态。
如果你有一个只能在训练用 GPU 上运行的语音模型，或者一台目前在其语言上完全没有离线语音支持的设备，联系我们，或者到我们的服务页面看看这项工作从头到尾是什么样子。