Tidlige builds af Voice Pro brugte ONNX Runtime med de officielle Qwen ASR ONNX-eksporter. Det virkede, men det var besværligt at udgive. Her er, hvad vi stødte på, og hvorfor appen nu kører på llama.cpp med GGUF-kvantiserede modeller.
Problem 1: installationsstørrelse
En Windows-build af Voice Pro med ONNX Runtime + DirectML-provideren + CUDA-provideren + modelvægtene kom ud på 430 MB. Linux var tilsvarende. Det er meget at bede nogen om at downloade for et dikteringsværktøj, de ikke har prøvet endnu.
GGUF-bygget er 83 MB på Windows. Den kompilerede llama.cpp-binær er lille; den kvantiserede basemodel er ca. 60 MB (mod ca. 200 MB som fp16 ONNX), og vi leverer ikke separate execution-provider-DLL'er til CPU, CUDA, DirectML og Vulkan – llama.cpp håndterer alle fire med én binær.
Problem 2: koldstart
ONNX Runtime med DirectML på en frisk Windows-installation tog 3–5 sekunder at initialisere inferencesessionen. Hver gang brugeren trykkede på genvejen for første gang efter en genstart, mødte de denne forsinkelse. Uacceptabelt for et dikteringsværktøj, hvor hele pointen er "tal straks".
llama.cpp indlæser GGUF-modellen på ca. 400 ms koldt på samme hardware. Memory-mapped weights, intet grafkompileringstrin, ingen runtime-wheel til initialisering.
Problem 3: pakkehelvede
ONNX Runtime leveres som en Python wheel, hvilket betyder forskellige wheels per Python-version, OS og CPU-arkitektur. Tilføj GPU-acceleration, og du multiplicerer med CUDA-version og DirectML-version. Nuitka (vores pakkeværktøj) blev ved med at inkludere den forkerte variant. Vi havde byggeskripter med seks betingede grene.
llama.cpp er en enkelt C++-binær fil. Vi kompilerer den én gang per platform (Windows x64, Linux x64) og leverer den som en native eksekverbar fil, som Voice Pro kalder. Der er ingen Python-runtime-afhængighed til inferens overhovedet – Python er blot limen.
Problem 4: kvalitet ved lave størrelser
Bekymringen ved kvantisering er nøjagtighedstab. I praksis måler den Q5_K_M-kvantede Qwen3-ASR 0.6B (vores basemodel) sig til inden for 0,3 % WER af den fulde fp16 ONNX-version på vores interne evalueringsdataset. Q4_0 er markant værre, så vi leverer Q5_K_M som standard. Brugere, der ønsker maksimal nøjagtighed, kan downloade fp16-niveauet fra modelhåndteringen.
Hvad vi gav op
llama.cpp's ASR-support er nyere end ONNX Runtime's. Nogle eksotiske modelarkitekturer har endnu ikke GGUF-konvertere. For nu betyder det ikke noget – Qwen3-ASR konverterer rent – men hvis vi vil prøve en radikalt anderledes ASR-model i fremtiden, kan vi være nødt til at beholde ONNX-stien som fallback.
Nettoresultat: en 5× mindre installation, ~10× hurtigere koldstart, én binær fil at bygge i stedet for tolv. Vi burde have gjort dette fra dag et.