Voice Pro 的早期构建版本使用 ONNX Runtime 配合官方的 Qwen ASR ONNX 导出模型。它可行，但发布它很痛苦。以下是我们遇到的情况，以及为何现在应用运行在 llama.cpp 使用 GGUF 量化模型。
问题 1：安装大小
带有ONNX Runtime、DirectML提供程序、CUDA提供程序及模型权重的Voice Pro Windows版本已发布，其大小为 430 MB. Linux 也是如此。要求某人下载一个他们尚未试用过的听写工具，这要求实在太高了。
GGUF 构建版本是 Windows下占用83 MB. 编译后的 llama.cpp 二进制文件体积极小，量化后的基础模型约为 60 MB（相比之下，fp16 ONNX 格式约为 200 MB），我们不会为 CPU、CUDA、DirectML 和 Vulkan 分别提供独立的执行提供程序 DLL——llama.cpp 通过一个二进制文件即可处理所有四种平台。
问题 2：冷启动
在冷启动的 Windows 安装上，使用 DirectML 的 ONNX Runtime 需要 3–5 秒才能初始化推理会话。每次用户重启后首次按下快捷键时，都会遇到这种延迟。对于主打“即说即录”的听写工具而言，这是不可接受的。
在相同的硬件上，llama.cpp冷启动加载GGUF模型仅需约400毫秒。内存映射权重，无图编译步骤，无需初始化运行时wheel。
问题 3：打包地狱
ONNX Runtime 以 Python wheel 形式提供，这意味着 针对不同Python版本、操作系统和CPU架构提供不同的wheel包。. 加入 GPU 加速后，还需考虑 CUDA 版本和 DirectML 版本的差异。Nuitka（我们的打包工具）一直捆绑了错误的变体。我们曾编写过包含六个条件分支的构建脚本。
llama.cpp是一个单一的C++二进制文件。我们为每个平台（Windows x64、Linux x64）编译一次，并将其作为Voice Pro调用的原生可执行文件发布。推理完全不需要Python运行时依赖——Python仅作为胶水层。
问题 4：小尺寸下的质量问题
量化的担忧在于精度损失。在实际测试中，对我们的基础模型 Qwen3-ASR 0.6B 进行 Q5_K_M 量化后，在内部评估集上的 WER 值与完整的 fp16 ONNX 版本相比仅相差 0.3% 左右。而 Q4_0 的精度明显更差，因此我们默认提供 Q5_K_M 版本。那些需要最高精度的用户可以从模型管理器中下载 fp16 版本的模型。
我们放弃的内容
llama.cpp的ASR支持比ONNX Runtime更新。某些异类模型架构尚无GGUF转换器。目前这并不重要——Qwen3-ASR转换干净——但如果我们将来想尝试截然不同的ASR模型，我们可能需要保留ONNX路径作为回退方案。
最终结果：安装体积缩小 5 倍，冷启动速度提升约 10 倍，只需构建一个二进制文件而非十二个。我们本应从第一天起就这么做。