Le prime build di Voice Pro utilizzavano ONNX Runtime con le esportazioni ONNX ufficiali di Qwen ASR. Funzionava, ma il rilascio era doloroso. Ecco cosa abbiamo riscontrato e perché ora l'app funziona su llama.cpp con modelli quantizzati GGUF.
Problema 1: dimensione di installazione
Una build di Voice Pro per Windows con ONNX Runtime + il provider DirectML + il provider CUDA + i pesi del modello è arrivata a 430 MB. Anche Linux presentava una situazione simile. Si chiede molto a un utente di scaricare uno strumento di dettatura che non ha ancora provato.
La build GGUF è 83 MB su Windows. Il file binario compilato di llama.cpp è minuscolo, il modello base quantizzato è di ~60 MB (contro ~200 MB come ONNX fp16), e non spediamo DLL di execution-provider separate per CPU, CUDA, DirectML e Vulkan: llama.cpp gestisce tutti e quattro con un unico binario.
Problema 2: avvio a freddo
ONNX Runtime con DirectML su un’installazione di Windows a freddo richiedeva da 3 a 5 secondi per inizializzare la sessione di inferenza. Ogni volta che l’utente premeva il tasto di scelta rapida per la prima volta dopo un riavvio, subiva quel ritardo. Inaccettabile per uno strumento di dettatura, dove l’obiettivo principale è “parlare immediatamente”.
llama.cpp carica il modello GGUF in ~400 ms a freddo sullo stesso hardware. Pesi mappati in memoria, nessuna fase di compilazione del grafo, nessun wheel runtime da inizializzare.
Problema 3: incubo del packaging
ONNX Runtime viene fornito come wheel Python, il che significa wheel diversi per versione di Python, OS e architettura CPU. Aggiungere l'accelerazione GPU e si moltiplica per versione CUDA e versione DirectML. Nuitka (il nostro packager) continuava a includere la variante sbagliata. Avevamo script di build con sei rami condizionali.
llama.cpp è un singolo binario C++. Lo compiliamo una volta per piattaforma (Windows x64, Linux x64) e lo forniamo come eseguibile nativo che Voice Pro chiama. Nessuna dipendenza dal runtime Python per l'inferenza: Python è solo il collante.
Problema 4: qualità a dimensioni ridotte
La preoccupazione riguardo alla quantizzazione è la perdita di accuratezza. In pratica, Qwen3-ASR 0.6B (il nostro modello base) quantizzato Q5_K_M misura un WER entro lo 0,3% rispetto alla versione ONNX fp16 completa sul nostro set di valutazione interno. Q4_0 è notevolmente peggio, quindi spediamo Q5_K_M come predefinito. Gli utenti che vogliono la massima accuratezza possono scaricare il livello fp16 dal gestore modelli.
A cosa abbiamo rinunciato
Il supporto ASR di llama.cpp è più recente di quello di ONNX Runtime. Alcune architetture di modelli esotiche non hanno ancora convertitori GGUF. Per ora non è un problema: Qwen3-ASR converte in modo pulito, ma se in futuro volessimo provare un modello ASR radicalmente diverso potremmo aver bisogno di mantenere il percorso ONNX come fallback.
Risultato netto: un’installazione 5 volte più piccola, avvio a freddo ~10 volte più veloce, un unico binario da compilare invece di dodici. Avremmo dovuto farlo fin dal primo giorno.