A Voice Pro korai buildjei az ONNX Runtime-ot használták a hivatalos Qwen ASR ONNX exportokkal. Működött, de a szállítás fájdalmas volt. Íme, mibe futottunk bele, és miért fut most az alkalmazás llama.cpp GGUF-kvantált modellekkel.
1. probléma: telepítési méret
A Voice Pro Windows-os buildje az ONNX Runtime-tal, a DirectML providerrel, a CUDA providerrel és a modellsúlyokkal együtt 430 MB. A Linux hasonló volt. Ez sokat kérne el egy olyan diktálóeszköz letöltéséért, amelyet még ki sem próbáltak.
A GGUF build 83 MB Windowson. A lefordított llama.cpp bináris kicsi, a kvantált alapmodell körülbelül 60 MB (az fp16 ONNX-szal szemben ~200 MB), és nem szállítunk külön végrehajtó-kiszolgáltató DLL-eket CPU, CUDA, DirectML és Vulkan számára – a llama.cpp egyetlen bináris fájllal kezeli mind a négyet.
2. probléma: hidegindítás
Az ONNX Runtime DirectML-lel egy tiszta Windows-telepítésen 3–5 másodpercet vett igénybe az inferencia-munkamenet inicializálása. Minden alkalommal, amikor a felhasználó újraindítás után először megnyomta a gyorsbillentyűt, ezzel a késleltetéssel találkozott. Ez elfogadhatatlan egy diktálóeszköznél, ahol a lényeg a „azonnali beszéd”.
A llama.cpp ~400 ms alatt tölti be a GGUF-modellt hidegindításkor ugyanazon a hardveren. Memórialeképezett súlyok, nincs gráf-kompilációs lépés, nincs inicializálandó futásidejű wheel.
3. probléma: csomagolási káosz
Az ONNX Runtime Python wheelként érkezik, ami azt jelenti, hogy külön wheels Python-verziónként, operációs rendszerenként és CPU-architektúránként. Ha hozzáadja a GPU-gyorsítást, akkor a CUDA- és a DirectML-verziók szorzata jelenik meg. A Nuitka (a csomagolónk) folyamatosan a rossz változatot csomagolta. Hat feltételes ágat tartalmazó build-szkriptjeink voltak.
A llama.cpp egyetlen C++ bináris. Platformonként egyszer fordítjuk le (Windows x64, Linux x64), és natív futtatható állományként szállítjuk, amelyet a Voice Pro hív meg. Az inferenciához egyáltalán nincs szükség Python-futtatókörnyezetre – a Python csak a ragasztó.
4. probléma: minőség kis méreteknél
A kvantálás aggálya a pontosságvesztés. A gyakorlatban a Q5_K_M kvantálású Qwen3-ASR 0.6B (bázismodellünk) az internális tesztadaton a teljes fp16 ONNX verzióhoz képest 0,3%-os WER-en belül marad. A Q4_0 jelentősen rosszabb, ezért a Q5_K_M az alapértelmezett. A maximális pontosságot kereső felhasználók letölthetik az fp16 csomagot a modellkezelőből.
Miről mondtunk le
A llama.cpp ASR-támogatása újabb, mint az ONNX Runtime-é. Néhány egzotikus modellarchitektúrához még nincs GGUF-konverter. Ez egyelőre nem számít – a Qwen3-ASR tisztán konvertál –, de ha a jövőben egy radikálisan eltérő ASR-modellt szeretnénk kipróbálni, előfordulhat, hogy az ONNX-utat tartalékként meg kell tartanunk.
Végeredmény: 5× kisebb telepítés, ~10× gyorsabb hidegindítás, egyetlen bináris, amit fel kell építeni, nem tizenkettő. Ezt már az első naptól így kellett volna csinálni.