Les premières versions de Voice Pro utilisaient ONNX Runtime avec les exportations ONNX officielles de Qwen ASR. Cela fonctionnait, mais sa mise en production était douloureuse. Voici ce que nous avons rencontré et pourquoi l’application fonctionne désormais sur llama.cpp avec des modèles quantifiés GGUF.
Problème 1 : taille d’installation
Une version Windows de Voice Pro avec ONNX Runtime + le fournisseur DirectML + le fournisseur CUDA + les poids du modèle est sortie pour 430 MB. Linux était similaire. C’est beaucoup demander à quelqu’un de télécharger un outil de dictée qu’il n’a pas encore essayé.
La version GGUF est 83 Mo sous Windows. Le binaire compilé de llama.cpp est minuscule, le modèle de base quantifié fait environ 60 Mo (contre environ 200 Mo en fp16 ONNX), et nous ne livrons pas de DLL séparées pour les fournisseurs d’exécution CPU, CUDA, DirectML et Vulkan — llama.cpp gère les quatre avec un seul binaire.
Problème 2 : démarrage à froid
ONNX Runtime avec DirectML sur une installation Windows à froid mettait 3 à 5 secondes pour initialiser la session d’inférence. Chaque fois que l’utilisateur appuyait sur la touche de raccourci pour la première fois après un redémarrage, il subissait ce délai. Inacceptable pour un outil de dictée dont l’objectif principal est de « parler immédiatement ».
llama.cpp charge le modèle GGUF en ~400 ms à froid sur le même matériel. Poids mappés en mémoire, pas d’étape de compilation de graphe, pas de wheel d’exécution à initialiser.
Problème 3 : enfer de l'emballage
ONNX Runtime est fourni sous forme de wheel Python, ce qui signifie wheels différents par version de Python, OS et architecture CPU. En ajoutant l’accélération GPU, on multiplie par la version CUDA et la version DirectML. Nuitka (notre outil de packaging) continuait d’emballer la mauvaise variante. Nous avions des scripts de compilation avec six branches conditionnelles.
llama.cpp est un binaire C++ unique. Nous le compilons une fois par plateforme (Windows x64, Linux x64) et le livrons en tant qu’exécutable natif que Voice Pro appelle. Aucune dépendance de runtime Python pour l’inférence du tout — Python est juste la colle.
Problème 4 : qualité à faibles tailles
L’inquiétude avec la quantification est la perte de précision. En pratique, Qwen3-ASR 0.6B quantifié en Q5_K_M (notre modèle de base) mesure un WER à moins de 0,3 % de la version ONNX fp16 complète sur notre ensemble d’évaluation interne. Q4_0 est nettement moins bon, c’est pourquoi nous livrons Q5_K_M par défaut. Les utilisateurs qui veulent une précision maximale peuvent télécharger le niveau fp16 depuis le gestionnaire de modèles.
Ce à quoi nous avons renoncé
Le support ASR de llama.cpp est plus récent que celui d’ONNX Runtime. Certaines architectures de modèles exotiques n’ont pas encore de convertisseurs GGUF. Pour l’instant, cela n’a pas d’importance — Qwen3-ASR se convertit proprement — mais si nous voulons essayer un modèle ASR radicalement différent à l’avenir, nous devrons peut-être garder le chemin ONNX comme fallback.
Résultat net : une installation 5 fois plus petite, un démarrage à froid environ 10 fois plus rapide, un seul binaire à compiler au lieu de douze. Nous aurions dû le faire dès le premier jour.