Hugging Face Inference Endpoints での Speech-to-Speech のデプロイ

Hugging Face は、Inference Endpoints 上でカスタム Docker イメージを使用して Speech-to-Speech (S2S) パイプラインをデプロイする方法を導入しました。このアプローチにより、開発者は基盤となるハードウェアを管理せずにスケーラブルな GPU インフラを活用し、低レイテンシで計算負荷の高いマルチモデルパイプラインを実行できます。

Speech-to-Speech (S2S) パイプライン

Speech-to-Speech プロジェクトは、Transformers ライブラリのモデルを使用したカスケード型パイプラインを実装しています。このシステムは、ユーザーが話すと合成音声で応答を受け取ることができ、以下の4つの主要コンポーネントで構成されています。

  1. 音声活動検出 (VAD)
  2. 音声からテキストへ (STT)
  3. 言語モデル (LM)
  4. テキスト音声合成 (TTS)

このパイプラインは英語、フランス語、スペイン語、中国語、日本語、韓国語をサポートし、auto フラグで自動言語検出が可能です。

カスタム Docker イメージによるデプロイ

S2S は大量の計算リソースを必要とするため、Hugging Face は、事前構築されたモデルやカスタムハンドラではなく、カスタム Docker イメージを使用した Inference Endpoints (IE) の利用を推奨しています。この方法は、すべての依存関係とデータをイメージ内にカプセル化することでパフォーマンスを最適化します。

カスタムイメージの構築

デプロイ用イメージを作成するには、まず huggingface-inference-toolkit リポジトリをクローンし、推論ワークロード用に事前最適化されたベースを確立します。カスタマイズプロセスは以下を含みます。

  • コードとデータの統合: S2S のコードベースと必要なデータセット（例: fast-unidic）を git サブモジュールとして追加します。データをコンテナに直接含めることで、エンドポイント作成時にデータセットをダウンロードする必要がなくなり、起動時間が短縮されます。
  • 依存関係の簡素化: Dockerfile を修正し、不要なパッケージを削除し、requirements.txt のインストールをエントリーポイントからビルド段階へ移動させ、実行時前に依存関係が事前にインストールされるようにします。

デプロイ設定

カスタムイメージは Inference Endpoints の GUI または API を通じてデプロイできます。主な設定要件は以下の通りです。

  • ハードウェア: AWS GPU L4 インスタンスの使用が推奨されます（約 $0.80/時間）。
  • コンテナ設定: コンテナポートは 80 に設定する必要があります。これはデフォルトのツールキットエントリーポイントがポート 5000 を使用しているため、Inference Endpoint の期待に合わせるためです。
  • セキュリティ: HF_TOKEN をシークレットとして提供し、Meta-Llama-3.1-8B-Instruct などのゲート付きモデルをコンテナがダウンロードできるようにします。

低レイテンシのための技術アーキテクチャ

低レイテンシを実現するため、デプロイは標準的な HTTP リクエストではなく、カスタム Web サーバーと専用クライアントを利用します。

WebSocket Webサーバー

Starlette を使用して実装された Web サーバーは、音声ストリーミングを可能にする WebSocket 接続をサポートします。サーバーは起動時に prepare_handler を実行し、モデルの初期化とウォームアップを行います。稼働中は、inference_handler.process_streaming_data メソッドが音声を受信し、VAD 用にチャンク分割し、合成音声応答の処理と返却のためのキューを管理します。

音声ストリーミングクライアント

専用クライアントはユーザーのハードウェアと Web サーバー間のインターフェースを担当します。その責務は以下の4つの主要タスクに分かれます。

  1. 録音: audio_input_callback を通じて音声を取得し、チャンクをキューに送信します。
  2. 送信: send_audio メソッドを使用して音声をサーバーに送ります。
  3. 受信: on_message メソッドでサーバーからの応答を受け取り、サーバーが応答を完了したか、再生キューに追加すべきデータがあるかを判断します。
  4. 再生: audio_output_callback を通じて音声応答を再生し、ハードウェア損傷を防ぐために音量が安全範囲内であることを確認します。

Sources