Vroege builds van Voice Pro gebruikten ONNX Runtime met de officiële Qwen ASR ONNX-exporten. Het werkte, maar het uitbrengen ervan was pijnlijk. Dit is waar we tegenaan liepen en waarom de app nu draait op llama.cpp met GGUF-gekwantiseerde modellen.
Probleem 1: installatiegrootte
Een Windows-build van Voice Pro met ONNX Runtime + de DirectML-provider + de CUDA-provider + de modelgewichten kwam uit op 430 MB. Linux was vergelijkbaar. Dat is veel gevraagd van iemand om te downloaden voor een dictaathulpmiddel dat ze nog niet hebben uitgeprobeerd.
De GGUF-build is 83 MB op Windows. De gecompileerde llama.cpp-binary is klein, het gekwantiseerde basismodel is ~60 MB (vs ~200 MB als fp16 ONNX), en we leveren geen aparte execution-provider-DLL's voor CPU, CUDA, DirectML en Vulkan — llama.cpp behandelt alle vier met één binary.
Probleem 2: cold-start
ONNX Runtime met DirectML op een koude Windows-installatie duurde 3–5 seconden om de inferentiesessie te initialiseren. Elke keer dat de gebruiker na een herstart voor het eerst op de sneltoets drukte, ondervond hij die vertraging. Onacceptabel voor een dicteerhulpmiddel waarbij het hele punt is: "spreek onmiddellijk".
llama.cpp laadt het GGUF-model in ~400 ms cold op dezelfde hardware. Memory-mapped-gewichten, geen grafiekcompilatiestap, geen runtime-wheel om te initialiseren.
Probleem 3: verpakkingshel
ONNX Runtime wordt geleverd als een Python-wheel, wat betekent dat verschillende wheels per Python-versie, OS en CPU-architectuur. Voeg GPU-versnelling toe en je vermenigvuldigt met CUDA-versie en DirectML-versie. Nuitka (onze packager) bleef de verkeerde variant bundelen. We hadden buildscripts met zes conditionele takken.
llama.cpp is een enkele C++-binary. We compileren het één keer per platform (Windows x64, Linux x64) en leveren het als een native executable die Voice Pro aanroept. Geen Python-runtime-afhankelijkheid voor inferentie — Python is alleen de lijm.
Probleem 4: kwaliteit bij kleine maten
De zorg bij kwantisering is verlies aan nauwkeurigheid. In de praktijk scoort het gekwantiseerde Qwen3-ASR 0.6B (ons basismodel) met Q5_K_M binnen 0,3% WER van de volledige fp16 ONNX-versie op onze interne evaluatieset. Q4_0 is merkbaar slechter, dus we leveren Q5_K_M als standaard. Gebruikers die maximale nauwkeurigheid willen, kunnen de fp16-tier downloaden via de modelbeheerder.
Wat we hebben opgegeven
llama.cpp's ASR-ondersteuning is nieuwer dan die van ONNX Runtime. Sommige exotische modelarchitecturen hebben nog geen GGUF-converters. Voor nu maakt dat niet uit — Qwen3-ASR converteert schoon — maar als we in de toekomst een radicaal ander ASR-model willen proberen, moeten we misschien het ONNX-pad als fallback houden.
Eindresultaat: een 5× kleinere installatie, ~10× snellere cold start, één binary om te bouwen in plaats van twaalf. We hadden dit vanaf dag één moeten doen.