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 安裝環境下，使用 ONNX Runtime 和 DirectML 初始化推理會話需要 3–5 秒。每次重新啟動後，用戶首次按下熱鍵時都會遇到這種延遲。對於一款核心賣點係「即時說話」嘅聽寫工具嚟講，呢個唔可以接受。
喺同一硬件上，llama.cpp 冷啟動加載 GGUF 模型大約要 400 毫秒。權重用記憶體映射，冇圖編譯步驟，亦冇運行時套件要初始化。
問題 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倍，只需編譯一個二進制檔案，而唔係十二個。我哋應該由第一日就咁做。