Introduction
La quantification INT8 est souvent présentée comme une solution miracle pour faire tourner des modèles de reconnaissance automatique de la parole (ASR) sur des appareils à faibles ressources. La réalité est plus nuancée.
Nous avons mesuré les compromis réels — vitesse, précision, consommation mémoire — sur plusieurs architectures et plusieurs cibles matérielles représentatives du terrain africain : téléphones Android d’entrée de gamme, Raspberry Pi 4, et microcontrôleurs STM32.
Protocole expérimental
Nous avons sélectionné trois modèles ouverts couvrant le spectre de taille :
- Whisper Tiny (39 M paramètres, FP32 baseline)
- wav2vec 2.0 Base (95 M paramètres, FP32 baseline)
- MMS-300M (300 M paramètres, FP32 baseline)
Chaque modèle est quantifié via ONNX Runtime avec le provider CPUExecutionProvider, en mode statique (calibration sur 500 énoncés du corpus FLEURS sous-ensemble Wolof).
Résultats
Sur Snapdragon 439 (Redmi 9A)
| Modèle | WER FP32 | WER INT8 | Δ WER | Latence FP32 | Latence INT8 | Facteur |
|---|---|---|---|---|---|---|
| Whisper Tiny | 18,4 % | 19,1 % | +0,7 pt | 2 140 ms | 810 ms | ×2,6 |
| wav2vec2 Base | 14,2 % | 15,8 % | +1,6 pt | 4 870 ms | 1 920 ms | ×2,5 |
| MMS-300M | 11,1 % | 13,4 % | +2,3 pt | — (OOM) | 3 240 ms | — |
Observation clé : MMS-300M ne tient pas en FP32 sur 2 Go de RAM. La quantification INT8 n’est pas une option — c’est la condition nécessaire pour l’exécution.
Sur Raspberry Pi 4 (4 Go)
La dégradation WER est similaire, mais la latence absolue est 3× plus élevée. Le Pi n’embarque pas de NEON SIMD optimisé pour ONNX Runtime dans notre configuration.
Ce que ça coûte vraiment
1. La précision numérique n’est pas le vrai problème.
Un delta de 0,7 à 2,3 points de WER est généralement acceptable pour les applications terrain. Ce n’est pas ici que se situe le risque.
2. La calibration est critique.
Sans calibration sur un corpus représentatif de la langue cible, on observe des dégradations de 5 à 8 points. Les corpus de calibration génériques (LibriSpeech, Common Voice anglophone) produisent des modèles mal calibrés pour les langues africaines à tons.
3. La taille du modèle quantifié n’est que la moitié de l’histoire.
ONNX Runtime alloue des buffers intermédiaires FP32 pendant l’inférence. Sur Whisper Tiny, le pic mémoire en INT8 atteint 340 Mo — contre 160 Mo en théorie pour le modèle seul.
4. Le warmup est coûteux.
La première inférence prend 3 à 4× le temps nominal. Dans un usage conversationnel (push-to-talk), cela se remarque.
Recommandations
Pour les déploiements terrain à faibles ressources :
- Utiliser la quantification dynamique pour les modèles < 100 M paramètres. Légèrement moins efficace que la statique, mais élimine le besoin d’un corpus de calibration.
- Cibler Whisper Tiny ou Small comme baseline. Le rapport WER/latence/mémoire est le meilleur de la gamme.
- Mesurer sur le matériel cible, pas en simulation. Les benchmarks PC ne prédisent pas le comportement sur ARM Cortex-A53.
- Prévoir un corpus de calibration en langue locale dès le début du projet, même petit (100 énoncés suffisent).
Reproduire les expériences
git clone https://github.com/charbossly/int8-asr-benchmark
cd int8-asr-benchmark
pip install -r requirements.txt
make benchmark DEVICE=cpu LANG=woLes résultats complets (CSV) sont dans results/. Le Makefile cible également DEVICE=rpi et DEVICE=android (via ADB).
Conclusion
La quantification INT8 est un outil puissant, mais ce n’est pas un bouton magique. Sur matériel frugal, elle permet de débloquer des modèles autrement inutilisables, au prix d’une dégradation modérée de la qualité. La discipline de mesure — sur le bon matériel, dans la bonne langue — est irremplaçable.