早期版本的 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 量化後，在內部評估集上，其詞錯誤率與完整的 fp16 ONNX 版本僅相差 0.3% 以內。Q4_0 的表現明顯較差，因此我們將 Q5_K_M 設為預設值。若使用者追求最高精確度，可從模型管理器下載 fp16 版本。
我們放棄了什麼
llama.cpp 的 ASR 支援比 ONNX Runtime 更新。有些異類模型架構尚未有 GGUF 轉換器。目前這並非問題——Qwen3-ASR 轉換得很乾淨——但若未來我們想嘗試截然不同的 ASR 模型，可能就需要保留 ONNX 路徑作為回退方案。
最終結果：安裝包體積縮小 5 倍，冷啟動速度提升約 10 倍，且只需編譯一個二進位檔案，而非十二個。我們應該從第一天起就這麼做。