Des ingénieurs d'Arm analysent la reconnaissance vocale en continu Nemotron 3.5 sur Pixel 11 avec ExecuTorch
Une étude de cas d'ingénieurs d'Arm sur le blog de PyTorch indique que des blocs audio plus longs font passer le taux d'erreur sur les mots en FP16 de 15,2 % à 11,5 % (de 80 à 1 120 ms), et que les instructions matricielles SME2 ont accéléré de 2,12 fois le traitement d'un enregistrement entier en FP16 sur un Pixel 11. Tous les chiffres sont des mesures du fournisseur.
Des ingénieurs d'Arm analysent la reconnaissance vocale en continu sur un téléphone avec ExecuTorch
Le 26 octobre, le blog de PyTorch a publié une étude de cas de deux ingénieurs d'Arm. Ils ont pris le modèle vocal multilingue en flux Nemotron 3.5, l'ont exporté de PyTorch vers ExecuTorch et l'ont analysé sur un téléphone Google Pixel 11. Les auteurs travaillent pour Arm, qui commercialise l'extension du jeu d'instructions testée ; chaque chiffre ci-dessous est donc une mesure du côté du fournisseur. L'étude cherche à savoir comment la précision numérique et la taille des blocs audio modifient l'exactitude, combien de temps de calcul l'audio demande sur un seul fil d'exécution, et quels noyaux de calcul s'exécutent réellement. Elle part d'un avertissement : un modèle très exact sur des enregistrements entiers peut faire bien moins bien lorsqu'il doit produire du texte au fil de la parole.
L'exactitude dépend de la taille des blocs
La reconnaissance en continu traite l'audio par blocs. D'après l'article, le modèle transforme l'audio en un vecteur de caractéristiques toutes les 10 ms, et son encodeur réduit cela à une position toutes les 80 ms. Les tailles de bloc testées sont de 80, 320, 560 et 1 120 ms. Les auteurs ont mesuré le taux d'erreur sur les mots (WER), soit le total des substitutions, suppressions et insertions divisé par le nombre total de mots de référence, sur un ordinateur hôte avec le moteur XNNPACK d'ExecuTorch. Ils ont utilisé 14 019 énoncés issus de quatre corpus publics. De 80 ms à 1 120 ms, le WER passe de 15,2 % à 11,5 % en virgule flottante sur 16 bits (FP16), et de 15,5 % à 11,7 % avec des poids entiers sur 8 bits (appelés QC8W). Le FP16 diffère de la virgule flottante sur 32 bits de moins de 0,03 point de pourcentage à chaque taille, tandis que QC8W ajoute de 0,21 à 0,31 point. Des blocs plus longs améliorent l'exactitude, mais font apparaître le premier texte plus tard.
Ce que montrent les mesures sur le téléphone
Pour la vitesse, l'équipe a traité un enregistrement de 24,9 secondes sur un Pixel 11 avec des blocs de 1 120 ms et un seul fil d'inférence fixé sur un cœur de processeur de puissance intermédiaire. Elle a compilé ExecuTorch 1.3.1 deux fois, avec et sans les instructions matricielles SME2 d'Arm ; chaque réglage a comporté deux passages de préchauffage et une trace mesurée. Avec SME2, le traitement en FP16 est passé de 9,79 à 4,61 secondes, soit 2,12 fois plus vite, et celui en QC8W de 5,20 à 3,24 secondes, soit 1,61 fois. Les auteurs l'expriment par un facteur temps réel, le temps de traitement divisé par la durée de l'audio : 0,19 en FP16 et 0,13 en QC8W. Ils soulignent que cette marge ne supprime pas l'attente de l'arrivée de l'audio. La multiplication matricielle explique l'essentiel du gain, passant de 8,2 à 3,1 secondes en FP16, tandis que les déplacements de données prenaient à peu près le même temps dans les deux versions et pesaient donc davantage dans le total.
Quels noyaux se sont exécutés
Les temps par opérateur ne disent pas quelles routines de bas niveau ont tourné ; les auteurs ont donc aussi échantillonné les chemins d'appel natifs avec un profileur d'Arm. Ils indiquent que le matériel matriciel a été alloué pendant 38,4 % de la capture en FP16 et 53,7 % en QC8W, et précisent qu'il ne s'agit pas d'une part du débit de calcul maximal. Les échantillons ont confirmé que des noyaux écrits pour SME2 s'exécutaient dans les deux cas, à côté d'autres noyaux : certaines opérations FP16 utilisaient encore l'ancien chemin vectoriel NEON, et certaines opérations QC8W tournaient toujours en virgule flottante sur 32 bits. L'article précise que les deux outils employés ici, ETDump et Streamline, ne relient pas directement les vues des couches du modèle et des noyaux exécutés ; les auteurs réservent la correspondance couche par couche à des travaux futurs.
Comment exploiter ces résultats
L'étude montre une méthode plus qu'un verdict : choisir ensemble la taille des blocs et la précision, et mesurer l'exactitude comme la latence sur l'appareil visé. Ses limites sont nettes. Les tests d'exactitude ont tourné sur un hôte, pas sur le téléphone. Le chronométrage sur le téléphone repose sur un enregistrement, un fil d'exécution et une mesure par réglage. Les résultats viennent d'un seul appareil et des optimisations d'Arm elles-mêmes. Une équipe qui prépare un produit devrait refaire les tests avec ses propres enregistrements, ses langues et ses contraintes thermiques.
Sources
FAQ
Pourquoi la taille des blocs compte-t-elle en reconnaissance vocale en continu ?
Un modèle en continu doit produire du texte avant de disposer de l'enregistrement entier. L'étude indique que passer de blocs de 80 ms à 1 120 ms fait baisser le taux d'erreur sur les mots de 15,2 % à 11,5 % en FP16, mais le premier texte apparaît plus tard. L'exactitude doit donc être mesurée à la taille de bloc utilisée en production.
Qu'est-ce que SME2 a changé sur le téléphone ?
Sur un Pixel 11 avec un seul fil d'inférence, un enregistrement de 24,9 secondes a pris 9,79 secondes sans SME2 et 4,61 secondes avec en FP16, soit 2,12 fois plus vite. La version QC8W sur 8 bits est passée de 5,20 à 3,24 secondes, soit 1,61 fois. Les auteurs travaillent pour Arm, qui conçoit ce jeu d'instructions.
Jusqu'où peut-on généraliser ces résultats ?
Pas très loin. L'exactitude a été mesurée sur un ordinateur hôte, et le chronométrage sur téléphone repose sur un seul appareil, un enregistrement, un fil d'exécution et une mesure par réglage. Les équipes devraient refaire les tests avec leurs propres enregistrements, leurs langues et leurs contraintes thermiques.