Ang mga naunang build ng Voice Pro ay gumamit ng ONNX Runtime kasama ang opisyal na mga export ng Qwen ASR sa format na ONNX. Nagana ito, ngunit napakahirap itong i-deploy. Ito ang mga problemang naranasan namin at kung bakit ngayon ay gumagana na ang app sa llama.cpp gamit ang mga modelong na-quantize sa GGUF.
Problema 1: laki ng pag-install
Isang bersyon ng Voice Pro para sa Windows na may ONNX Runtime + ang provider na DirectML + ang provider na CUDA + ang mga timbang ng modelo ang nailabas. 430 MB. Ganoon din ang Linux. Napakalaking hinihingi iyan sa isang tao na mag-download ng isang tool para sa pagdidikta na hindi pa niya nasusubukan.
Ang GGUF build ay 83 MB sa Windows. Ang na-compile na binary ng llama.cpp ay napakaliit; ang quantized na base model nito ay mga 60 MB (kumpara sa mga 200 MB para sa fp16 ONNX). Hindi kami naglalabas ng hiwalay na DLL para sa execution provider para sa CPU, CUDA, DirectML, at Vulkan — kinakaya ng llama.cpp ang lahat ng apat na ito gamit lamang ang isang binary.
Problema 2: cold-start
Ang ONNX Runtime na may DirectML sa isang bagong-install na Windows ay nangangailangan ng 3–5 segundo upang ma-initialize ang inference session. Sa bawat pagpindot ng user sa hotkey sa unang pagkakataon matapos ang reboot, nakararanas sila ng ganitong pagkaantala. Hindi ito katanggap-tanggap para sa isang dictation tool kung saan ang pangunahing layunin ay "makapagsalita agad".
Ang llama.cpp ay naglo-load ng GGUF model sa loob ng ~400 ms cold sa parehong hardware. May memory-mapped weights, walang graph compilation step, at walang runtime wheel na kailangang i-initialize.
Problema 3: impiyerno sa pag-iimpake
Ang ONNX Runtime ay isinama bilang isang Python wheel, na nangangahulugang Iba’t ibang wheels ayon sa bersyon ng Python, OS, at arkitektura ng CPU. Idagdag ang GPU acceleration, at dadami ito ayon sa bersyon ng CUDA at bersyon ng DirectML. Patuloy na isinasama ng Nuitka (ang ating packager) ang maling variant. Mayroon kaming mga build script na may anim na conditional branch.
Ang llama.cpp ay isang solong C++ binary. Ito ay kinokompila namin minsan para sa bawat platform (Windows x64, Linux x64) at ipinapadala bilang isang native executable na tinatawag ng Voice Pro. Walang anumang dependency sa Python runtime para sa inference – ang Python ay ginagamit lamang bilang glue.
Problema 4: kalidad sa maliit na sukat
Ang problema sa quantization ay ang pagkawala ng katumpakan. Sa praktika, ang Q5_K_M na nagquantize sa Qwen3-ASR 0.6B (ang aming base model) ay nagpapakita ng WER na nasa loob ng 0.3% kumpara sa buong fp16 ONNX version sa aming internal eval set. Ang Q4_0 naman ay mas masama ang performance, kaya ginagamit namin ang Q5_K_M bilang default. Ang mga user na nais ng pinakamataas na katumpakan ay maaaring mag-download ng fp16 tier mula sa model manager.
Ano ang aming isinuko
Ang suporta para sa ASR ng llama.cpp ay mas bago kumpara sa ONNX Runtime. May ilang kakaibang model architectures na wala pang GGUF converters. Sa ngayon, hindi ito problema — maayos namang nakakapag-convert ang Qwen3-ASR — ngunit kung gusto nating subukan ang isang lubhang naiibang ASR model sa hinaharap, maaaring kailanganin nating panatilihing fallback ang ONNX path.
Resulta: mas maliit ng 5 beses ang laki ng file na kailangang i-install, mas mabilis nang humigit-kumulang 10 beses ang proseso ng pag-start kapag malamig pa ang sistema, at isang binary lang ang kailangang buuin sa halip na labindalawa. Dapat ay ginawa natin ito simula pa sa unang araw.