Arm-Ingenieure vermessen Nemotron-3.5-Streaming-Spracherkennung auf einem Pixel 11 mit ExecuTorch
Eine Fallstudie von Arm-Ingenieuren im PyTorch-Blog berichtet, dass längere Audioblöcke die Wortfehlerrate bei FP16 von 15,2 % auf 11,5 % senken (80 bis 1.120 ms) und SME2-Matrixbefehle die Verarbeitung einer ganzen Aufnahme mit FP16 auf einem Pixel 11 um den Faktor 2,12 beschleunigten. Alle Zahlen sind Messungen des Anbieters.
Arm-Ingenieure analysieren Streaming-Spracherkennung auf einem Smartphone mit ExecuTorch
Am 26. Oktober veröffentlichte der PyTorch-Blog eine Fallstudie von zwei Arm-Ingenieuren. Sie nahmen das mehrsprachige Streaming-Sprachmodell Nemotron 3.5, exportierten es von PyTorch nach ExecuTorch und vermaßen es auf einem Google Pixel 11. Die Autoren arbeiten für Arm, das die getestete Befehlssatzerweiterung vertreibt, daher ist jede Zahl unten eine Messung auf Anbieterseite. Die Studie fragt, wie numerische Genauigkeit und Größe der Audioblöcke die Treffsicherheit verändern, wie viel Rechenzeit das Audio auf einem einzelnen Thread braucht und welche Rechenkerne tatsächlich laufen. Sie beginnt mit einer Warnung: Ein Modell, das auf ganzen Aufnahmen am genauesten ist, kann deutlich schlechter abschneiden, wenn es Text schon während des Sprechens liefern muss.
Die Genauigkeit hängt von der Blockgröße ab
Streaming-Erkennung verarbeitet Audio in Blöcken. Nach der Beschreibung im Beitrag macht das Modell aus dem Audio alle 10 ms einen Merkmalsvektor, und sein Encoder reduziert das auf eine Position alle 80 ms. Getestet wurden Blockgrößen von 80, 320, 560 und 1.120 ms. Die Autoren maßen die Wortfehlerrate (WER), also die Summe aus Ersetzungen, Auslassungen und Einfügungen geteilt durch die Gesamtzahl der Referenzwörter, auf einem Host-Rechner mit dem XNNPACK-Backend von ExecuTorch. Sie nutzten 14.019 Äußerungen aus vier öffentlichen Korpora. Von 80 ms bis 1.120 ms sinkt die WER mit 16-Bit-Gleitkomma (FP16) von 15,2 % auf 11,5 % und mit 8-Bit-Ganzzahlgewichten (QC8W genannt) von 15,5 % auf 11,7 %. FP16 weicht bei jeder Größe um weniger als 0,03 Prozentpunkte von 32-Bit-Gleitkomma ab, QC8W fügt 0,21 bis 0,31 Punkte hinzu. Längere Blöcke helfen der Genauigkeit, lassen den ersten Text aber später erscheinen.
Was die Messungen auf dem Telefon zeigen
Für die Geschwindigkeit verarbeitete das Team eine 24,9 Sekunden lange Aufnahme auf einem Pixel 11 mit 1.120-ms-Blöcken und einem einzelnen Inferenz-Thread, der an einen CPU-Kern mittlerer Leistung gebunden war. Es baute ExecuTorch 1.3.1 zweimal, mit und ohne die Matrixbefehle SME2 von Arm, und jede Einstellung erhielt zwei Aufwärmläufe und einen gemessenen Trace. Mit SME2 sank die FP16-Verarbeitung von 9,79 auf 4,61 Sekunden, ein Faktor 2,12, und QC8W von 5,20 auf 3,24 Sekunden, ein Faktor 1,61. Die Autoren geben dies als Echtzeitfaktor an, Verarbeitungszeit geteilt durch Audiolänge: 0,19 für FP16 und 0,13 für QC8W. Sie betonen, dass dieser Spielraum das Warten auf das Eintreffen des Audios nicht beseitigt. Den größten Teil des Gewinns brachte die Matrixmultiplikation, die bei FP16 von 8,2 auf 3,1 Sekunden fiel, während die Datenbewegung in beiden Builds etwa gleich lange dauerte und einen größeren Anteil am Ganzen einnahm.
Welche Rechenkerne liefen
Zeiten pro Operator verraten nicht, welche Routinen auf niedriger Ebene liefen, daher tasteten die Autoren mit einem Profiler von Arm auch native Aufrufpfade ab. Sie berichten, dass die Matrix-Hardware bei FP16 in 38,4 % und bei QC8W in 53,7 % der Aufzeichnung belegt war, und stellen klar, dass dies kein Anteil am maximalen Rechendurchsatz ist. Die Stichproben bestätigten, dass in beiden Fällen für SME2 geschriebene Kerne liefen, neben anderen Kernen: Einige FP16-Operationen nutzten weiter den älteren NEON-Vektorpfad, und einige QC8W-Operationen liefen weiter in 32-Bit-Gleitkomma. Der Beitrag sagt, dass die hier verwendeten Werkzeuge ETDump und Streamline die Sicht auf Modellschichten und ausgeführte Kerne nicht direkt verbinden; die Autoren nennen eine Zuordnung pro Schicht als künftige Arbeit.
Wie sich die Ergebnisse nutzen lassen
Die Studie zeigt eher eine Methode als ein Urteil: Blockgröße und Genauigkeit gemeinsam wählen und sowohl Treffsicherheit als auch Latenz auf dem Zielgerät messen. Ihre Grenzen sind klar. Die Genauigkeitstests liefen auf einem Host, nicht auf dem Telefon. Die Zeitmessung auf dem Telefon stützt sich auf eine Aufnahme, einen Thread und einen gemessenen Lauf je Einstellung. Die Ergebnisse stammen von einem einzigen Gerät und enthalten Arms eigene Optimierungen. Ein Team, das ein Produkt plant, sollte die Tests mit eigenem Audio, eigenen Sprachen und eigenen thermischen Grenzen wiederholen.
Sources
FAQ
Warum ist die Blockgröße bei Streaming-Spracherkennung wichtig?
Streaming-Modelle müssen Text ausgeben, bevor die ganze Aufnahme vorliegt. Die Studie berichtet, dass der Wechsel von 80-ms- auf 1.120-ms-Blöcke die Wortfehlerrate bei FP16 von 15,2 % auf 11,5 % senkt, der erste Text aber später erscheint. Die Genauigkeit muss daher bei der im Einsatz verwendeten Blockgröße gemessen werden.
Was hat SME2 auf dem Telefon verändert?
Auf einem Pixel 11 mit einem Inferenz-Thread dauerte eine 24,9 Sekunden lange Aufnahme mit FP16 ohne SME2 9,79 Sekunden und mit SME2 4,61 Sekunden, ein Faktor 2,12. Die 8-Bit-Variante QC8W sank von 5,20 auf 3,24 Sekunden, Faktor 1,61. Die Autoren arbeiten für Arm, das diesen Befehlssatz entwickelt.
Wie weit lassen sich die Ergebnisse verallgemeinern?
Nicht weit. Die Genauigkeit wurde auf einem Host-Rechner gemessen, und die Zeitmessung auf dem Telefon stützt sich auf ein Gerät, eine Aufnahme, einen Thread und einen gemessenen Lauf je Einstellung. Teams sollten die Tests mit eigenem Audio, eigenen Sprachen und eigenen thermischen Grenzen wiederholen.