Versiunile timpurii ale Voice Pro utilizau ONNX Runtime cu exporturile oficiale Qwen ASR ONNX. Funcționa, dar distribuirea sa a fost dificilă. Iată ce am întâmpinat și de ce aplicația funcționează acum pe llama.cpp Cu modele cuantizate în GGUF.
Problema 1: dimensiunea de instalare
O versiune pentru Windows a Voice Pro cu ONNX Runtime + providerul DirectML + providerul CUDA + ponderile modelului a fost lansată 430 MB. Linux a fost similar. Este mult ceea ce se cere de la cineva să descarce pentru un instrument de dictare pe care nu l-a încercat încă.
Build-ul GGUF este 83 MB pe Windows. Binariul compilat llama.cpp este mic, modelul de bază cuantizat este de ~60 MB (față de ~200 MB ca fp16 ONNX), și nu livrăm DLL-uri separate de execution-provider pentru CPU, CUDA, DirectML și Vulkan — llama.cpp gestionează toate cele patru cu un singur binar.
Problema 2: pornire la rece
ONNX Runtime cu DirectML pe o instalare Windows la rece avea nevoie de 3–5 secunde pentru a inițializa sesiunea de inferență. De fiecare dată când utilizatorul apăsa scurtătura pentru prima dată după o repornire, întâmpina această întârziere. Inacceptabil pentru un instrument de dictare unde tot scopul este „vorbește imediat“.
llama.cpp încarcă modelul GGUF în ~400 ms cold pe același hardware. Greutățile sunt mapate în memorie, nu există etapă de compilare a graficului, niciun wheel de runtime de inițializat.
Problema 3: coșmarul împachetării
ONNX Runtime este livrat ca un pachet Python wheel, ceea ce înseamnă wheel-uri diferite pentru fiecare versiune de Python, sistem de operare și arhitectură CPU. Adaugi accelerare GPU și înmulțești cu versiunea CUDA și cu versiunea DirectML. Nuitka (pachetizatorul nostru) continua să includă varianta greșită. Aveam scripturi de build cu șase ramificații condiționale.
llama.cpp este un singur binar C++. Îl compilăm o dată per platformă (Windows x64, Linux x64) și îl livrăm ca executabil nativ pe care Voice Pro îl apelează. Nu există nicio dependență de runtime Python pentru inferență deloc — Python este doar lipiciul.
Problema 4: calitate la dimensiuni mici
Problema legată de cuantizare este pierderea de acuratețe. În practică, Qwen3-ASR 0.6B cuantizat în Q5_K_M (modelul nostru de bază) are o eroare de cuvânt (WER) cu doar 0,3% față de versiunea ONNX fp16 completă pe setul nostru intern de evaluare. Q4_0 este semnificativ mai slab, așa că livrăm Q5_K_M ca implicit. Utilizatorii care doresc acuratețe maximă pot descărca nivelul fp16 din managerul de modele.
La ce am renunțat
Suportul ASR al llama.cpp este mai nou decât cel al ONNX Runtime. Unele arhitecturi de modele exotice nu au încă convertizoare GGUF. Pentru moment, asta nu contează — Qwen3-ASR se convertește curat — dar dacă vrem să încercăm un model ASR radical diferit în viitor, poate va trebui să păstrăm calea ONNX ca fallback.
Rezultat net: o instalare de 5 ori mai mică, pornire la rece de aproximativ 10 ori mai rapidă, un singur binar de compilat în loc de doisprezece. Ar fi trebuit să facem asta de la început.