Раните верзии на Voice Pro користеа ONNX Runtime со официјалните Qwen ASR ONNX извози. Работеше, но испораката беше мачна. Еве со што се соочивме и зошто апликацијата сега работи на llama.cpp со GGUF-квантизирани модели.
Проблем 1: големина на инсталацијата
Верзија на Voice Pro за Windows со ONNX Runtime + DirectML провајдерот + CUDA провајдерот + тежините на моделот изнесуваа 430 MB. Linux беше сличен. Тоа е многу да се побара од некој да преземе за алатка за диктирање што сè уште не ја пробал.
GGUF-изградбата е 83 MB на Windows. Компилираниот бинарен фајл на llama.cpp е минимален, квантизираниот базен модел е ~60 MB (сп. ~200 MB како fp16 ONNX), и не испорачуваме посебни execution-provider DLL-и за CPU, CUDA, DirectML и Vulkan — llama.cpp ги обработува сите четири со еден бинарен фајл.
Проблем 2: ладно стартување
ONNX Runtime со DirectML на свежа Windows инсталација одземаше 3–5 секунди за иницијализација на сесијата за заклучување. Секој пат кога корисникот прв пат по рестартирање ќе ја притиснеше кратенката, ќе наидеше на тоа доцнење. Неприфатливо за алатка за диктирање каде што целата поента е „зборувај веднаш“.
llama.cpp го вчитува GGUF моделот за ~400 ms на ист хардвер. Тежините се мапираат во меморија, нема чекор на компилирање на граф, нема wheel за runtime за иницијализација.
Проблем 3: пакувачки пекол
ONNX Runtime се испорачува како Python wheel, што значи различни wheels за секоја верзија на Python, оперативен систем и CPU архитектура. Додадете GPU забрзување и множителот зависи од верзијата на CUDA и верзијата на DirectML. Nuitka (нашиот пакувач) постојано ги вклучуваше погрешните варијанти. Имавме скрипти за градење со шест условни гранки.
llama.cpp е една C++ бинарна датотека. Го компилираме еднаш по платформа (Windows x64, Linux x64) и го испорачуваме како нативен извршен фајл кој Voice Pro го повикува. Нема зависност од Python runtime за инференција воопшто – Python е само лепило.
Проблем 4: квалитет при мали големини
Загриженоста кај квантизацијата е губење на точноста. Во пракса, квантизираниот Qwen3-ASR 0.6B (наш базен модел) има WER во рамките на 0,3% во споредба со целата fp16 ONNX верзија на нашиот интерен сет за евалуација. Q4_0 е значително полош, затоа испорачуваме Q5_K_M како стандард. Корисниците кои сакаат максимална точност можат да ја преземат fp16 верзијата од менаџерот на модели.
Што жртвувавме
Поддршката за ASR во llama.cpp е понова од онаа во ONNX Runtime. Некои егзотични архитектури на модели сè уште немаат конвертори за GGUF. Засега тоа не е важно – Qwen3-ASR конвертира чисто – но ако сакаме да пробаме радикално различен ASR модел во иднина, можеби ќе мора да ја задржиме опцијата ONNX како fallback.
Конечен исход: инсталација 5 пати помала, ~10 пати побрзо ладно стартување, еден бинарен фајл за градење наместо дванаесет. Требаше да го направиме ова од првиот ден.