Tidiga versioner av Voice Pro använde ONNX Runtime med de officiella Qwen ASR ONNX-exporterna. Det fungerade, men att leverera den var smärtsamt. Här är vad vi stötte på och varför appen nu körs på llama.cpp med GGUF-kvantiserade modeller.
Problem 1: installationsstorlek
En Windows-version av Voice Pro med ONNX Runtime + DirectML-provider + CUDA-provider + modellviktorna landade på 430 MB. Linux var liknande. Det är mycket att be någon att ladda ner för ett dikteringsverktyg de ännu inte har provat.
GGUF-bygget är 83 MB på Windows. Den kompilerade llama.cpp-binären är liten, den kvantiserade basmodellen är cirka 60 MB (jämfört med cirka 200 MB som fp16 ONNX), och vi levererar inga separata exekveringsleverantörs-DLL:er för CPU, CUDA, DirectML och Vulkan – llama.cpp hanterar alla fyra med en enda binär.
Problem 2: kallstart
ONNX Runtime med DirectML på en kall Windows-installation tog 3–5 sekunder att initialisera inferenssessionen. Varje gång användaren tryckte på snabbtangenten för första gången efter en omstart drabbades de av denna fördröjning. Oacceptabelt för ett dikteringsverktyg där hela poängen är att ”tala omedelbart”.
llama.cpp laddar GGUF-modellen på ca 400 ms kallstart på samma hårdvara. Minnesmappade vikter, inget grafkompileringsskede, inget wheel att initialisera vid körning.
Problem 3: förpackningshelvete
ONNX Runtime levereras som ett Python-wheel, vilket innebär olika wheels för varje Python-version, OS och CPU-arkitektur. Lägg till GPU-acceleration och du multiplicerar med CUDA-version och DirectML-version. Nuitka (vårt paketeringsverktyg) fortsatte att paketera fel variant. Vi hade byggskript med sex villkorsgrenar.
llama.cpp är en enda C++-binär. Vi kompilerar den en gång per plattform (Windows x64, Linux x64) och levererar den som en native exekverbar fil som Voice Pro anropar. Inga Python-runtime-beroenden för inferens alls – Python är bara limmet.
Problem 4: kvalitet vid låga storlekar
Oron vid kvantisering är noggrannhetsförlust. I praktiken mätte den Q5_K_M-kvantiserade versionen av Qwen3-ASR 0.6B (vår basmodell) en WER på 0,3 % jämfört med den fullständiga fp16-ONNX-versionen på vårt interna utvärderingsunderlag. Q4_0 är märkbart sämre, så vi levererar Q5_K_M som standard. Användare som vill ha maximal noggrannhet kan ladda ner fp16-nivån från modellhanteraren.
Vad vi offrade
llama.cpp:s ASR-stöd är nyare än ONNX Runtime:s. Vissa exotiska modellarkitekturer har fortfarande inga GGUF-omvandlare. För nu spelar det ingen roll – Qwen3-ASR konverterar smidigt – men om vi vill prova en radikalt annorlunda ASR-modell i framtiden kan vi behöva behålla ONNX-vägen som fallback.
Nettoeffekt: en 5× mindre installation, ~10× snabbare kallstart, en binärfil att bygga istället för tolv. Vi borde ha gjort detta från dag ett.