講演者: Liu Chuan、NVIDIA シニア ソリューション アーキテクト

編集・編集：李玉良

コミュニティ制作 | DataFun

会話型AIシナリオの概要

会話型AIワークフローは、主に3つのアルゴリズム関連モジュールで構成されています。ASR （自動音声認識）はユーザーの音声をテキストに変換し、 NLU（自然言語理解）は認識された内容に基づいてテキスト応答を提供します。TTS （音声合成）は、応答を音声に変換し、プロセス全体の戻り値として提供します。NVIDIAはこれら3つの分野で幅広いアルゴリズムとアクセラレーション技術を保有しており、この記事ではASRとTTSに焦点を当てます。

2. 問題点と課題

音声 AI ワークフローの導入には、次のような多くの課題があります。

① 音声認識精度の向上が難しく、合成音声の品質が悪い。

② 複数のモデルとフロントエンド・バックエンドプロセスが関与するため、ワークフローが複雑になります。ストリーミングタスクのスケジュールと管理はさらに複雑になり、開発が困難になり、スケジュール管理も非効率的になります。

③ GPU リソースの使用効率が悪いため、サービス遅延が高く、同時パス数が少なく、導入コストが高いままです。

上記の問題を解決するために、主に Triton Inference Server と TensorRT を使用します。

02

ASR GPU 導入のベストプラクティス

1. Triton推論サーバーの紹介

Tritonは、学習済みモデルをマイクロサービスとしてデプロイできるオープンソースの推論サービスデプロイメントフレームワークです。このフレームワークは、リクエストのスケジュール設定、モデルの管理、推論リクエストの処理、そして結果の返却を行います。GPUとCPUの両方の推論をサポートし、PyTorchやTensorflowなどの様々なディープラーニングフレームワークと互換性があります。

2. ASRワークフローの概要

NVIDIAは、Triton Inference ServerをベースとしたクラウドGPUにASRクラウドサービスを展開するためのワークフローを提供しています。プロセス全体は3つの部分で構成されています。

① Kaldifeat の Fbank 特徴抽出器を使用して、GPU 上の複数のオーディオ ファイルから特徴を効率的に抽出します。

② 音声特徴に基づいてデコードに必要な入力を推測するConformer Encoder

③ CTCプレフィックスビームサーチのデコードには、N-Gram言語モデルを導入し、コンフォーマデコーダーとエンコーダーの出力を組み合わせてN-Bestを再スコアリングします。

Triton Inference Server を使用して WeNet ASR ワークフローを展開する理由は、これら 3 つのモジュールを整然と組み合わせて、3 つのモジュール間でデータ フローを整然とできるようにするためです。

3. リクエストでのTritonスケジューリングモデルの使用

Tritonのアンサンブルモデル機能では、モジュール間の依存関係を設定できるため、前述の3つのモデルをワークフローにデプロイできます。さらに、3つのモデルは独立してデプロイされ、並列実行が可能です。つまり、後続のモデルが前のリクエストを処理している間に、先行するモデルが同時に次のリクエストを推論することができます。これにより、3つのモデルの統合と、パイプラインの並列処理とモデル推論の分離が実現されます。

さらに、前述の3つ目のモジュールはCTCとDecoder Rescoringの連携を伴い、最後のチャンクに到達した場合に再スコアリングが必要となる論理演算を提示します。Tritonのビジネスロジックスクリプティング機能はこの問題を解決できます。これはシンプルなPythonスクリプトであり、シンプルなコードで他のモデルを呼び出すことで、様々な論理演算を容易に実装し、モデル間のデータフローを制御できます。

さらに、リクエスト側のスケジューリングに関しては、Triton のダイナミック バッチ スケジューラはハードウェア リソースを最大限に活用し、複数のクライアントから同時に送信されたリクエストを大きなバッチにマージすることで、高い同時実行性と高いスループットを実現します。

4. Tritonのストリーミング推論メカニズム

以前、ストリーミング以外の計算の最適化について説明しました。現実のシナリオでは、ASRサービスは複数の音声データストリームを同時に処理する必要があります。例えば、単一のユーザーが複数の音声メッセージを送信する場合などです。Tritonは、主に以下の機能を含む依存関係を持つストリーミング計算を最適化するためのストリーミングAPIを提供しています。

① 各チャンクに 4 つのラベルを追加します: Start - ストリームの開始チャンクであるかどうか、Ready - 推論するデータがあるかどうか、End - ストリームの終了チャンクであるかどうか、Corrid - チャンクが属するストリーム。

② 複数のストリームからチャンクをマージして推論を行う。Tritonはモデルインスタンスを用いて推論を行う。単一のGPU上で複数のインスタンスを起動することができ、各インスタンスはN個のスロットに分割されているため、1つのインスタンスはN個のデータストリームを同時に推論することができる。データストリームはまずSequence Batcherの候補キューで処理を待機し、空きスロットが空いた時点で処理を開始できる。データストリームの状態を維持するため、データストリームのすべてのチャンクは同じインスタンス上でのみ推論され、各ストリームの状態が維持される。さらに、依存関係のため、同じタイムステップにおけるすべてのスロットのチャンクは、異なるストリームからのもののみが許可される。

③ Tritonは暗黙的な状態管理機能を提供します。これにより、設定ファイルでモデルの状態入力と出力を定義することで、状態テンソルの管理と更新が可能になります。さらに、データストリームが変化した際に、対応するデータストリームの状態に切り替えることができます。これにより、ストリーミング計算における状態管理が大幅に簡素化されます。

5. パフォーマンスの向上

WeNetモデルのストリーミング音声認識（ASR）の性能をA10 GPU上でテストしました。アテンションリスコアリングを使用し、5つのチャンクを遡って（各チャンクの長さは640ミリ秒）、400～500の同時パスでリアルタイム推論を実行できます（注：このテストはユーザーの実際のストリーミング音声をシミュレートするものではなく、各ストリームのすべてのチャンクを中断なく非同期的にサーバーに送信します） 。

ストリーミング以外のシナリオでは、 ONNXとTensorRTの両方のバックエンドをテストしました。ONNXは、8秒のオーディオファイルに対して1秒あたり180件のリクエストを処理できます。さらに、TensorRTアクセラレーションソリューションも提供し、特定のレイヤーでのデータオーバーフロー、特定の操作のサポート不足、精度と速度の低下といったネイティブTensorRT特有の問題に対処しました。TensorRTは1秒あたり280件のリクエストのスループットを達成し、ONNXをさらに上回りました。

6. さらなる拡大

私たちのベストプラクティスはさらに拡張可能です。例えば、ASRをベースに、VADモジュールと音声セグメンテーションモジュールを追加できます。これにより、パイプライン全体が音声特徴抽出、VADエンドポイント検出、音声セグメンテーション、そしてASR推論を含むようになります。これらのモジュールは、前述のビジネスロジックスクリプトを使用して相互に連携されます。必要に応じて、話者認識、感情分析、句読点予測などのモジュールを追加することも可能です。

さらに、Triton は、オーディオセグメントを複数のセグメントに分割した後、個別に推論を行い、再度結合できるという問題も解決しました。異なるクライアントやリクエストから切り出されたすべてのオーディオセグメントをまとめて推論処理し、最終的に各オーディオセグメントがどのオーディオリクエストに属しているかを識別できるようになりました。

Triton推論サーバー全体をDockerコンテナとして使用したり、Kubernetesクラスター内のポッドとしてデプロイしたり、複数のTritonポッドを異なるノードにデプロイしたりできます。さらに、Tritonが提供するメトリクスを使用して、弾力的にスケールアップまたはスケールダウンすることで分散デプロイメントを構築し、スループットを線形に向上させ、トラフィック量の多いビジネスシナリオにも適応できます。

03

TTS GPU 導入のベストプラクティス

1. ストリーミングTTSの導入方法

ASRと比較して、TTSには強力なオープンソースコミュニティが不足しており、これが課題の一つとなっています。クライアントからのテキストリクエストの管理とスケジュール設定、そしてパディングやバッティングなどの前処理を実行するために、Triton C++カスタムバックエンドを実装しました。このバックエンドは、Triton Ensembleを使用して統合された2つのモジュールを呼び出します。

① フロントエンド・エンコーダーモジュールは、テキスト前処理フロントエンド（Pythonバックエンドを使用）と音響モデルエンコーダー（FastPitchとTensorRTバックエンドを使用）の2つのコンポーネントで構成されています。テキストはこれらの2つのコンポーネントを一度しか通過しないため、これらを統合します。

② Decoder-Vocoderモジュールには、Decoder（FastPitchとTensorRTバックエンドを使用）とVocoder（HiFi-GANとTensorRTバックエンドを使用）が含まれています。これらの2つのコンポーネントはストリーミング計算で複数回呼び出される必要があるため、アンサンブルとして統合されています。

このプロセスにおいて、Tritonのカスタムバックエンド機能を利用することで、C++またはPythonでロジックモジュールを開発し、これらのカスタムモジュールをモデルとしてデプロイすることが可能です。音響モデルについては、Tritonに組み込まれているTensorRTをデプロイ用のバックエンドとして使用することで、モデル推論速度が大幅に向上しました。

TTS（テキスト読み上げ）の入力は、大きなテキストブロックで構成される場合があります。最初のパケットの遅延を削減するため、私たちの実践ではTritonを使用して、複数のチャンクからなるストリーミング出力を提供しています。TritonのDecoupled Responseにより、モデルの複数の出力を元の入力リクエストにバインドできるため、各チャンクに対応するテキストとユーザーを特定しやすくなります。

2. 推論性能

この導入環境の推論パフォーマンスを、A10上で異なる長さのテキスト（ショートテキスト：15文字、ミドルテキスト：20文字、ロングテキスト：30文字）でテストしました。QPS（1秒あたりのクエリ数）が200の場合、この導入環境の最初のパケットレイテンシは100ミリ秒未満に抑えられました。

04

結論

Nvidia は、音声の分野で次のような役立つベスト プラクティスを生み出しました。

ASR の分野では:

① 当社は Triton をベースにストリーミングおよび非ストリーミング WeNet を展開した経験があり、非ストリーミング WeNet を高速化するために TensorRT を使用しています。

② このソリューションは、K8S クラスター上の複数のマシンと複数の GPU を使用した分散展開をサポートします。

③ この一連の実践に基づいて、VAD を統合するためのリファレンス ソリューションを提供します。

④WeNet社のWeSpeaker話者認識機能に対応しました。

TTSについて:

① FastPitch + HiFiGAN に基づくストリーミングバイリンガルコンテンツを展開するためのベストプラクティス。

②現在、マルチスピーカーTTSの研究を行っています。

NLUに関しては、INT8量子化も最適化しましたが、ここでは取り上げません。セミオープンソースのGitHubプロジェクトCISI（github.com/nvidia-china-sae/CISI）をご覧ください。メールでアクセスすることも可能です。ぜひフォローしてください。

05

質疑応答セッション

Q1: モデルを接続するためにキューが使用されていますか？これによりレイテンシが高くなりますか？

A1: Tritonはモデル接続において非常に効率的です。複数のモジュールがGPU上に配置されている場合、TritonはGPUとメモリ間のコピーを回避します。アンサンブルモードでは、ワークフロー内の複数のモデルを並列に実行できます。これらの特性に基づき、Tritonは不要なオーバーヘッドを削減し、効率を向上させます。

Q2: ストリーミング推論において、インスタンスが 2 つのスロットを開始するが、データ ストリームが 1 つしかない場合、効率は低くなりますか?

A2: はい。これはGPUパフォーマンスが要件を超えていることを示しており、GPUパーティショニング（MIG）を実行することをお勧めします。または、同じGPUに複数のモデルをデプロイして、リソースを最大限に活用してください。

Q3: リクエストがバッチ処理されるのを待つ間に遅延が発生しますか?

A3: 待機時間を設定できます。非常に短い時間に設定すると、同時に受信したリクエストのみがバッチ処理されます。

Q4: 数千分の数というリアルタイムレートは既に非常に高速です。WSTを考慮するとボトルネックになるでしょうか？

A4: WSTの最大の問題はパフォーマンスではなく、LMグラフのサイズが非常に大きく、ビデオメモリを大量に消費することです。他の解決策も検討中です。

06

劉川：WeNetコミュニティは拡大を続けています。ビンビンさん、WeNetの開発はどのように設計・計画されていますか？そして、WeNetの最終的な形はどのようなものですか？

張斌斌：これも検討中の課題です。例えば、トランスデューサーと認識関連の機能はWeNetプロジェクトに直接統合しています。一方、話者診断機能はWeSpeakerという別のプロジェクトに統合しています。TTS機能も同様です。水平統合と垂直統合のどちらにするかは、多くのオープンソースプロジェクトが当初から検討する問題です。WeNetコミュニティは、生産性、軽量設計、保守性を重視しています。そのため、コミュニティ内には水平統合されたプロジェクトが数多く存在します。

Liu Chuan: あなたはWeNetの責任者であり、Horizo​​n Roboticsの研究員でもあります。オープンソースプロジェクトの開発者とエンタープライズエンジニアとしての仕事のバランスをどのように取っているのでしょうか？オープンソースコミュニティと産業用アプリケーションをどのように組み合わせているのでしょうか？

張斌斌：まず、会社がオープンソースを支持しているかどうかです。以前の会社はオープンソースに比較的賛成でした。もう一つの点は、現在の会社はオープンソースに対する考え方が異なっているということです。Horizo​​n Roboticsとオープンソースコミュニティは相互に貢献し合い、Win-Winの関係を築いています。私は現在、Horizo​​n Roboticsで多くの開発業務に携わっており、業務外でもオープンソースコミュニティと議論し、問題解決に尽力しています。2つ目の質問については、私たちのコミュニティは業界の課題解決に重点を置いているため、オープンソースとエンジニアリングのバランスを効果的に取ることができます。

劉川：WeNetは音声業界で徐々に最も人気のあるコミュニティになりつつあるようですね。音声分野における知識や経験を共有するコースの提供は検討されていますか？

張斌斌：検討しました。現在、VoiceHomeと共同で、実践的な有料コースを準備中です。当初、コミュニティメンバーからは無料コースの要望がありましたが、商用化することで製品の品質をより保証できます。将来的には、他のプロジェクトのコースをWeChat公式アカウントや動画アカウントで直接公開する可能性もあります。

Liu Chuan: NVIDIA自身もいくつかのオープンソースプロジェクトに関わっています。これにはWeNetのようなオープンソースプロジェクトのサポートも含まれます。今後、NVIDIAは音声技術分野においてどのようなオープンソース活動を行う予定ですか？

張斌斌：TritonやNeMoといったオープンソース製品があり、製品チームはこれらの製品を改良するために業界からのフィードバックを継続的に収集しています。また、エンジニアにはオープンソースコミュニティへの参加を奨励しています。こうすることで、NVIDIAのアクセラレーション技術を活用してこれらのオープンソースプロジェクトを最適化することができます。今後は、特にトレーニングの最適化に注力し、TransducerやCTCといったより多くのモデルやデコーダーをサポートしていく予定です。

Liu Chuan ：人工知能はコンピューティングパワーに依存しており、個人開発者にとっては非常に高価です。NVIDIAは今後、オープンソースコミュニティにコンピューティングパワーのサポートを提供する予定はありますか？

張斌斌：オープンソースプロジェクトへの参加を通して、社内のGPUコンピューティングパワーを活用したアクセラレーションと最適化の取り組みを数多く行ってきました。これにより、GPU不足はある程度緩和されました。一方、NVIDIAはInceptionスタートアップアクセラレーションプログラムを実施しており、オープンソースコミュニティへの貢献を希望する企業にコンピューティングパワーの割引を提供しています。さらに、パブリッククラウドプロバイダーと協力し、優秀な学生にコンピューティングパワーのサポートを提供していきます。