
音声インタラクションには、毎回レイテンシー予算があります。
ユーザーがアプリの応答を耳にするまでに、音声の収録、音声認識、LLM の実行、コンテキストの検索、応答の生成など、さまざまな処理で貴重なミリ秒を消費しています。テキスト読み上げ(TTS)は最後の工程であり、ユーザーが最も直接的に体感する工程でもあります。音声の生成に時間がかかれば、体験全体が遅く感じられてしまいます。
自分で実行・最適化できる処理が多いほど、取り戻せるレイテンシー予算も大きくなります。
音声 AI は急速に進化しています。統合型音声モデルは、1 回の API 呼び出しで音声入力と音声出力を処理できるため、より簡単に導入できます。しかしその代わりに、各コンポーネントを自分の分野に合わせて微調整したり、より優れたモデルがリリースされた際にモデルを置き換えたり、データレジデンシー要件に対応したり、レイテンシーが実際にどこで発生しているのかを正確に把握したりすることが難しくなります。より高い制御性が必要な場合は、カスケード型アーキテクチャによって専用の ASR、TTS、LLM コンポーネントを組み合わせ、各レイヤーを個別に最適化し、所有するインフラストラクチャ上にデプロイできます。
NVIDIA Magpie 多言語 TTS は、まさにこの目的のために開発されました。オープンウェイト、本番環境向けの NVIDIA NIM、そして 12 言語への対応により、自社インフラストラクチャ上に多言語音声をデプロイし、ワークロードに合わせてレイテンシーを最適化しながら、自分の環境内でモデルをエンドツーエンドに特定分野向けにカスタマイズできます。
最新バージョンでは、現代標準アラビア語、韓国語、ブラジルポルトガル語を追加し、多言語対応を拡張しました。また、トレーニングデータの更新とモデルの改良により、既存の複数言語の品質も向上しています。
カスタマーサポートエージェント、医療アシスタント、エンタープライズ Copilot、翻訳システム、対話型 AI アプリケーションのいずれを構築する場合でも、Magpie は本番環境向け音声 AI のオープンな基盤を提供します。
音声 AI は多言語対応が当たり前になりつつある
現在の音声アプリケーションは、単一の言語だけを対象とするものではありません。
グローバルなカスタマーサポート、エンタープライズアシスタント、医療文書作成、小売業務の自動化、翻訳ワークフローでは、複数の言語で自然に対話しながら、低レイテンシーを維持することがますます求められています。
より多くの言語に対応することは、課題の一部にすぎません。開発者には、次のことも求められます。
- データが存在する場所にデプロイする
- 企業のプライバシー要件を満たす
- 発音や音色をカスタマイズする
- 本番負荷におけるレイテンシーを予測する
- 自社インフラストラクチャ上でスケールさせる
オープンモデルによって、これらすべての可能性が変わります。
1 つのオープンモデルで 12 言語に対応
Magpie TTS 多言語版は、3 億 6,400 万パラメータのオープンウェイトモデルで、以下の言語に対応しています。
英語 · スペイン語 · フランス語 · ドイツ語 · イタリア語 · ベトナム語 · 中国語(標準語) · ヒンディー語 · 日本語 · 現代標準アラビア語(新規) · 韓国語(新規) · ブラジルポルトガル語(新規)
各言語では、共有される多言語話者表現を通じて、男性・女性の話者音色を利用できます。
今回のバージョンでは、ヒンディー語と日本語のコードスイッチングへの対応も拡張され、多言語運用の柔軟性が向上しています。この機能は、IPA の書記素から音素への変換(grapheme-to-phoneme)処理とカスタム発音辞書によって実現されており、人名、技術用語、複数言語が混在するコンテンツをより正確に読み上げられます。
開発者は、地域ごとに個別の TTS モデルを維持する必要がなくなり、1 つのオープンな基盤上で多言語アプリケーションを構築できます。
ユーザーが実際に体感するレイテンシー
対話型 AI では、テキスト読み上げがユーザーに応答が届く前の最後の段階です。そのため、音声生成の開始から最初の音声がユーザーに届くまでの遅延を示す首音声時間(Time to First Audio、TTFA)は、音声処理パイプラインにおける最も重要なレイテンシー指標の 1 つです。
Magpie TTS は自分の環境にデプロイできるため、測定されるレイテンシーは、実際に制御可能なサーバー側のレイテンシーとなります。ホステッドサービスとの往復で発生する遅延は含まれません。
| GPU | 単一ストリーム TTFA | 単一ストリーム RTFX | 64 ストリーム TTFA | 64 ストリーム RTFX |
|---|---|---|---|---|
| B200 | 32 ms | 12.1× | 239 ms | 319.81× |
| H100 | 47 ms | 14.7× | 275 ms | 290.79× |
| DGX Spark | 53 ms | 9.8× | 962 ms | 75.88× |
| A100 | 79 ms | 12.2× | 395 ms | 197× |
出典:NVIDIA TTS NIM パフォーマンスドキュメント(v26.07)。データはローカルデプロイ環境で 3 回テストした平均値です。
TTFA = 最初の音声が届くまでの遅延、RTFX = リアルタイム速度に対する倍速で表したスループット。
B200 上での Magpie の TTFA は 32 ミリ秒です。これにより、ASR や LLM の処理など残りの工程にレイテンシー予算を確保し、エンドツーエンドの総レイテンシーを自然な会話に必要とされる 200 ミリ秒以内に維持できます。NVIDIA GPU 上では、Magpie は単一ストリームで 32~79 ミリ秒の首音声遅延を実現できます。64 ストリームの同時実行時には、B200 で TTFA 239 ミリ秒を実現しながら、リアルタイムの 320 倍のスループットを達成します。つまり、同時実行負荷がかかった状態でも、音声の生成速度は再生速度の 300 倍を超えます。
上の表は、NVIDIA NIM として提供される Magpie をローカルデプロイ環境でテストした結果です。つまり、自社 GPU 上で動作する最適化済みコンテナを使用しています。Hugging Face で公開されているチェックポイントは同じモデルであり、研究や微調整に利用できます。一方、NIM は最適化されたサービングスタックで、上記の本番環境向けレイテンシーを実現します。どちらも、ユーザーが管理するハードウェア上で動作します。
モデルが自社インフラストラクチャ上で動作するため、パフォーマンスを直接ベンチマークし、デプロイ環境に合わせて最適化し、ワークロードに応じてスケールさせることができます。リアルタイム音声エージェントにとって、これは対話が素早く応答しているように感じられるか、それとも遅延しているように感じられるかを左右します。
リアルタイム音声生成に向けた最適化
低レイテンシーは偶然に実現したものではありません。Magpie では、音声品質を維持しながら推論時間を短縮する、相互補完的な 2 つのアーキテクチャ改善を導入しています。
フレームスタッキング(Frame stacking)。 デコーダーは、各デコードステップで 1 つではなく 2 つの音声フレームを予測します。これにより、デコーダーの反復回数が半分になり、生成時間が短縮され、スループットが向上します。
ローカル Transformer(Local transformer)。 フレームスタッキングだけを使用すると、同時に生成されるコードブックトークン間に依存関係が生じ、音声品質が低下する可能性があります。ローカル Transformer はこうした依存関係をモデル化し、生成された音声を洗練することで、フレームスタッキングによって本来生じ得る品質低下を補います。
この 2 つの技術を組み合わせることで、より高速な生成と自然な音声合成を両立できます。アーキテクチャの詳細については、論文 Frame-Stacked Local Transformers for Efficient Multi-Codebook Speech Generation(ICASSP 2026)をご覧ください。
自然に聞こえなければ、速くても意味がない
今回のバージョンでは、対応言語を増やしただけでなく、既存の複数言語における合成品質も向上しています。前バージョンと比較して、Magpie は複数の言語で、より低い文字誤り率(CER)と、より高い話者類似度(SSIM)を実現しました。特にフランス語とスペイン語で大きく改善されています。
| 言語 | CER(前バージョン) | CER(今回のバージョン) | SSIM(前バージョン) | SSIM(今回のバージョン) |
|---|---|---|---|---|
| フランス語 | 2.70% | 1.54% | 0.703 | 0.747 |
| スペイン語 | 1.14% | 0.60% | 0.715 | 0.793 |
| ドイツ語 | 0.66% | 0.80% | 0.626 | 0.742 |
出典: