faster-whisper は SYSTRAN がメンテナンスしている Whisper 推論実装です。CTranslate2 をバックエンドとして使い、Whisper に近い使い勝手を保ちながら、推論速度、メモリ使用量、デプロイの柔軟性をエンジニアリング用途に合わせやすくしています。
すでに openai/whisper を使ったことがあるなら、faster-whisper はより本番運用向けの代替実装として理解できます。インターフェースはモデル読み込み、音声文字起こし、セグメント結果の取得を中心にしていますが、実行層はより高速で、CPU、GPU、量子化、バッチ処理に合わせて調整しやすくなっています。
何を解決するのか
Whisper の精度は優れていますが、元の実装をそのままデプロイすると、よく次のような問題に当たります。
- 長い音声の文字起こしに時間がかかる。
- GPU メモリ使用量が大きい。
- CPU でも動くが、速度が十分でないことがある。
- 大量の音声や動画をバッチ処理するとき、スループットを上げにくい。
faster-whisper は主にこれらの問題を改善するための実装です。プロジェクトの README では、同じ精度で openai/whisper より最大 4 倍高速で、メモリ使用量も少ないと説明されています。8-bit 量子化を使うと、さらに速度を上げられます。
インストール
通常の Python 環境では、そのままインストールできます。
|
|
GPU を使う場合は、ローカルの CUDA、cuDNN、CTranslate2 のバージョンが合っているか確認してください。ここでつまずきやすいのは、GPU ドライバーと CUDA ランタイムの不一致です。コード自体に問題がなくても、モデル読み込み時や初回推論時に失敗することがあります。
基本的な使い方
最小構成の例はシンプルです。
|
|
主なパラメータは次の通りです。
| パラメータ | 役割 |
|---|---|
model_size |
small、medium、large-v3 などの Whisper モデルサイズを選ぶ |
device |
推論デバイス。よく使う値は cuda または cpu |
compute_type |
計算精度。例:float16、int8_float16、int8 |
beam_size |
デコード時の探索幅。大きいほど安定しやすいが遅くなる |
ローカルで素早く文字起こししたい場合は、まず medium または large-v3 から試すとよいです。GPU メモリが厳しい場合は、量子化を検討します。
CPU と GPU の選び方
NVIDIA GPU がある場合は、まず次の設定を使います。
|
|
GPU メモリが足りない場合は、次のように変更できます。
|
|
GPU がない場合は、CPU で実行できます。
|
|
CPU モードは軽いタスク、低頻度のバックグラウンド処理、または GPU のないサーバーに向いています。大量の長い音声を処理するなら、やはり GPU のほうが適しています。
バッチ文字起こし
faster-whisper はバッチ文字起こしにも対応しています。大量の短い音声を処理する場合や、GPU のスループットを上げたい場合に便利です。
|
|
batch_size は大きければよいわけではありません。スループットは上がりますが、GPU メモリの負荷も増えます。実際のデプロイでは、4、8、16 のような値を段階的に試し、安定して動く点を探すのがおすすめです。
VAD と単語単位のタイムスタンプ
音声文字起こしでは、長い無音、背景ノイズ、字幕の位置合わせがよく問題になります。faster-whisper には、文字起こし時にそのまま有効化できる実用的なパラメータがあります。
VAD を有効化する例:
|
|
単語単位のタイムスタンプを取得する例:
|
|
VAD は、会議録音、ポッドキャスト、ライブ配信のアーカイブなど、長い無音を含む音声に向いています。単語単位のタイムスタンプは、字幕生成、逐語録の校正、プレイヤー上での単語ハイライトに便利です。
モデルの選び方
モデル選びでは、主に精度、速度、マシンリソースを見ます。
| 場面 | 推奨 |
|---|---|
| すばやく試す | small または medium |
| 中国語コンテンツで品質優先 | large-v3 |
| GPU メモリが厳しい | int8_float16 またはより小さいモデル |
| CPU でバックグラウンド処理 | 小さいモデルと int8 |
| 大量の短い音声 | BatchedInferencePipeline を試す |
中国語音声では、品質を重視するならまず large-v3 を試すのがおすすめです。マシンへの負荷が大きすぎる場合は、モデルサイズを下げるか量子化を使います。最初から速度だけを見るのは避けたほうがよいです。文字起こし品質が下がると、手作業の校正時間で推論時間の節約分が消えてしまうことがあります。
向いている用途
faster-whisper は次のようなタスクに向いています。
- 動画字幕の生成。
- ポッドキャスト、会議、講義録音の文字起こし。
- Bilibili、YouTube などの動画をローカルで文字起こしするワークフロー。
- 音声の一括アーカイブと検索。
- 音声コンテンツを RAG、ナレッジベース、検索システムに渡す処理。
話者分離、要約、チャプター分割のような上位タスクを直接解決するものではありませんが、安定した文字起こし層として使えます。その後に pyannote で話者分離を行い、LLM で要約や構造化整理を行う構成にできます。
デプロイ時のすすめ方
実際に使うときは、次の順番で調整するとよいです。
- まず 1 から 3 分程度の音声で、環境が正しく動くか確認する。
- 対象言語と実際の音質に近いサンプルで精度を確認する。
- GPU メモリ使用量を見て、量子化を有効にするか決める。
- 長い音声は先に分割し、失敗時にすべてを再実行しなくて済むようにする。
- 結果は TXT と SRT の両方で保存し、後から校正しやすくする。
サーバータスクでは、リクエストごとにモデルを読み込むのではなく、サービス起動時にモデルを読み込むのがよいです。モデル読み込みには時間がかかり、頻繁に読み込むと GPU メモリ管理も不安定になりやすくなります。
まとめ
faster-whisper の価値は、Whisper を長期運用しやすい文字起こしコンポーネントにする点にあります。別のモデルに置き換えるのではなく、より効率のよい推論バックエンドとエンジニアリング向けのインターフェースを使う、という位置づけです。
個人のワークフローでは、動画、会議、講義音声をすばやくテキスト化できます。サーバー側のタスクでは、GPU、量子化、バッチ処理、VAD を組み合わせて性能を調整できます。マシン環境が正しく設定されていれば、安定した一括音声文字起こしには元の Whisper 実装より扱いやすい選択肢になります。