ホームサーバーは1日にどれくらいの音声を文字起こしできる？

ホームサーバーが1日に文字起こしできる音声の長さは、測定したリアルタイム係数と利用可能な稼働時間によって、1時間未満から数百時間まで変わります。

リアルタイム係数が0.25の場合、1時間の音声に15分かかり、処理時間1時間あたり4時間分の音声を処理できます。文字起こしを実時間で20時間実行できるなら、再試行や取り込みのオーバーヘッドを除いた理論上の1日あたりの処理能力は80時間分の音声です。ただし、予定している夜間の処理時間全体に対して、ハードウェア名だけでこの数値を確実に判断することはできません。

リアルタイム係数で処理速度を1日の処理能力に換算する

リアルタイム係数とは、音声の長さに対する処理時間の割合です。RTFが1.0なら実時間で処理し、0.5なら実時間1時間あたり2時間分の音声を、0.1なら10時間分を処理します。1日の処理能力は、予定処理時間をRTFで割って求められます。

公開されているWhisperのスループットベンチマークでは、モデル、GPU、音声の長さ、バッチ処理によってスループットが大きく変わることが示されています。測定時の構成は、実際のホーム環境のワークロードと一致していなければなりません。

この計算で数えるのは経過したファイル数ではなく、元の音声の長さです。無音の除去によって処理量を減らせる一方、話者分離、アライメント、翻訳、字幕の整形によって工程が増えることがあります。24時間の録音でも、発話は数時間しか含まれていない場合がありますが、それでもデコードとセグメント分割は必要です。

モデルとバッチ処理が速度と精度のトレードオフを左右する

通常、小型モデルや蒸留モデルはより高速に処理でき、必要なメモリも少なくなります。一方、大型の多言語モデルは、難しい言語での精度を高められる場合があります。バッチ処理は多数のファイルを処理する際にGPU使用率を高められますが、緊急性の高い1つのクリップでは待ち時間が増えます。

コミュニティによる実行時間の測定結果では、バッチ処理とパイプラインの利用率を考慮しない限り、理論上の計算性能は文字起こし速度に直線的には反映されないと指摘されています。

短いクリップは、長時間の録音に比べて、セットアップ、ファイルのオープン、スケジューリングにかかるオーバーヘッドの割合が大きくなります。言語検出やビームサーチによっても実行時間は変わります。単語誤り率が高く、文字起こし結果を使えないのであれば、1日あたりの処理量が多くても意味はありません。

処理能力の計算式が適用できない場合

クリーンなモノラル音声で測定したRTFは、ステレオの会議音声、ノイズの多い録音、複数言語の音声、メモリの挙動が変わる長時間ファイルには適用できないことがあります。1日全体で見ると、サーマルスロットリングや同時実行中のNASジョブによって利用可能な計算リソースが減少します。

実用的なリアルタイム係数を見ると、デバイスによって大きな差があることが分かり、GPUのクラスだけからスループットを推測せず、実際のモデルを測定する必要性が改めて示されます。

入力ストリームに対する遅延を一定以下に保つ必要があるライブ文字起こしでは、この計算式は適用できません。オフライン処理ではバッチ処理や将来のコンテキストを利用できますが、リアルタイムアシスタントでは利用できません。1日の処理能力と対話時の遅延は、別々の指標です。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

測定したRTFを1日の処理能力の範囲に換算する

短いボイスメモ、長時間の会議、複数の言語、さまざまなノイズレベル、チャンネル数を含む代表的なデータセットを選びます。エンドツーエンドの処理時間、音声の長さ、ラベル付きサブセットでの単語誤り率、ピーク時のメモリ使用量、少なくとも3時間にわたる消費電力を測定します。実運用で必要であれば、話者分離やアライメントも含めます。

サーバーの実際の稼働率を把握できるよう、予定しているローカル音声処理ワークロードのサービスと並行してテストを実行します。コールドスタートは、ウォーム状態でのスループットとは分けて記録します。

1日の処理能力は、利用可能な処理時間をRTFの中央値で割って計算し、そのうえで計画時には、より遅いp95のRTFと20％の運用予備を適用します。精度が目標に届かない場合は、処理速度が速くても使えない結果を宣伝するのではなく、より高性能なモデルに切り替えて再計算します。