Arm技術者、ExecuTorchでPixel 11上のNemotron 3.5ストリーミング音声認識を計測

Arm技術者、ExecuTorchでスマートフォン上のストリーミング音声認識を詳しく計測

PyTorchブログは10月26日、Armの技術者2人による事例研究を公開した。二人は多言語ストリーミング音声モデルNemotron 3.5をPyTorchからExecuTorchへ書き出し、Google Pixel 11で詳しく計測した。著者はArmに所属しており、試験対象の命令セット拡張もArmの製品だ。したがって以下の数字はすべてベンダー側の測定である。研究が問うのは、数値の精度と音声の区切りの大きさが正確さをどう変えるか、一つのスレッドで音声を処理するのにどれだけ時間がかかるか、実際にどの計算カーネルが動くか、の三点だ。冒頭で、録音全体では最も正確なモデルも、話すそばから文字を出さなければならない場面ではずっと悪くなりうると警告している。

正確さは区切りの大きさで変わる

ストリーミング認識は音声を塊に分けて処理する。記事の説明では、モデルは音声を10ミリ秒ごとに一つの特徴ベクトルにし、エンコーダーがそれを80ミリ秒ごとに一つの位置へまとめる。試した塊の大きさは80、320、560、1,120ミリ秒だ。著者らはホスト機上でExecuTorchのXNNPACKバックエンドを使い、単語誤り率(WER)、つまり置換・削除・挿入の誤り数の合計を参照語の総数で割った値を測った。データは公開コーパス4種の14,019発話である。80ミリ秒から1,120ミリ秒まで、16ビット浮動小数点(FP16)ではWERが15.2%から11.5%に、8ビット整数の重み(QC8Wと呼ぶ)では15.5%から11.7%に下がる。FP16は32ビット浮動小数点との差がどの大きさでも0.03ポイント未満で、QC8Wは0.21から0.31ポイント上乗せされる。塊が長いほど正確さは上がるが、最初の文字が出るのが遅くなる。

端末での測定が示すもの

速度については、Pixel 11で24.9秒の録音を1,120ミリ秒の塊で処理した。推論スレッドは一つで、中位性能のCPUコアに固定した。ExecuTorch 1.3.1を、ArmのSME2行列命令を有効にしたものと無効にしたものの二通りでビルドし、各設定で2回の予備実行と1回の計測トレースを行った。SME2を有効にすると、FP16の処理時間は9.79秒から4.61秒になり2.12倍速くなった。QC8Wは5.20秒から3.24秒で1.61倍だ。著者はこれをリアルタイム係数、つまり処理時間を音声の長さで割った値で示し、FP16は0.19、QC8Wは0.13だった。この余裕があっても音声が届くのを待つ時間はなくならないと強調している。向上の大部分は行列積によるもので、FP16では8.2秒から3.1秒に減った。一方、データ移動は二つのビルドでほぼ同じ時間を要し、全体に占める割合は大きくなった。

どのカーネルが動いたか

演算子ごとの時間では、どの低レベルのルーチンが実行されたかは分からない。そこで著者らはArmのプロファイラーでネイティブの呼び出し経路もサンプリングした。行列ハードウェアが採取時間の中で割り当てられていた割合は、FP16で38.4%、QC8Wで53.7%と報告されている。これはピーク演算性能に対する割合ではないと明記している。サンプルから、どちらの場合もSME2向けに書かれたカーネルが動いたことが確認できたが、ほかのカーネルも並んで動いていた。FP16の一部の演算は従来のNEONベクトル経路を使い、QC8Wの一部の演算は32ビット浮動小数点で動いた。記事によると、今回使ったETDumpとStreamlineの二つではモデルの層と実行されたカーネルの視点を直接つなげられない。著者らは層ごとの対応付けを今後の課題としている。

結果の使い方

この研究が示すのは結論というより方法である。区切りの大きさと精度を一緒に選び、対象の端末で正確さと遅延の両方を測るということだ。限界ははっきりしている。正確さの試験は端末ではなくホスト機で行われた。端末での時間測定は、1本の録音、1スレッド、設定ごとに1回の計測にとどまる。結果は1台の端末で、Arm自身の最適化とともに得られたものだ。製品を計画するチームは、自分たちの音声、言語、放熱の条件で試験をやり直すべきである。