Qwen3-TTS 50ms未満の遅延を実現する速度とコスト最適化

Nari Labsは、1台のNVIDIA H100 SXM上で10リクエスト/秒（RPS）のリアルタイム再生を維持しつつ、p95の最初の音声到達時間（TTFA）を50ミリ秒未満に抑える、Qwen3-TTS 1.7B CustomVoiceモデルのカスタム実装を開発しました。この最適化により、高性能音声合成のコストを大幅に削減し、フル利用状態で約100万文字あたり2ドルのコストを実現すると推定されています。

リアルタイムTTS性能のベンチマーク

リアルタイム運用の可能性を評価するため、Nari LabsはTTSサーバーが以下の4つの基準を満たすことを定義しています： audibleなTTFAの低さ、音声のアンダーラン（クライアントのバッファが空になる現象）のゼロ、RPSの増加に伴う高容量対応、そして理解可能な出力。

vLLM-Omni、SGLang-Omni、VoxServe、M*を含む5つの実装を比較したベンチマークでは、Nari Labsの実装が唯一、10 RPSまでp95 TTFAを50ms未満に維持できました。他のエンジン、たとえばVoxServeは1 RPSでは50ms未満に達することができましたが、負荷が増えると遅延が著しく上昇しました。たとえば6 RPSでは、ほとんどのエンジンが100msを超えるp95 TTFAを記録しました。

一般的な遅延ボトルネックへの対処

すべてのテスト対象エンジンに公平なベースラインを確立するために、2つの主要な最適化が適用されました。

先頭の静音除去：モデルは最初の音声の前に数十ミリ秒の静音を生成することがあります。Nari LabsはRMSウィンドウを用いた動的トリムを実装し、持続的な発話の検出により先頭の静音を除去することで、TTFAを約80ms改善しました。
フレーム蓄積のチューニング：デコード前に収集するコーデックフレーム数のバランスを調整します。小さな初期チャンクはTTFAを低くしますが、デコーダーのオーバーヘッドを増加させます。一方、大きなチャンクはバッチ処理と再生の安定性を向上させます。最適な構成では、初期の小さなチャンクから始め、その後の出力ではチャンクサイズを徐々に増やします。

Qwen3-TTSのアーキテクチャ最適化

Qwen3-TTSは、3つのモジュールを含む階層的なマルチコードブック生成プロセスを使用しています：Talker（最初のコードブックトークンを予測）、Code Predictor（残りの15トークンを生成）、Codec（トークンを波形に変換）。

統合されたスケジューリング表面

生成とデコードを2段階に分けるのではなく、Nari LabsはTalker、Code Predictor、Codecを単一のスケジューラ下で独立してスケジュール可能な3つのタスクとして扱います。これにより、再生のデッドラインに近づくCodecジョブをTalkerジョブよりも優先するなど、作業の優先順位を動的に再配置でき、同じモジュールを待つリクエストのより細かいバッチ処理が可能になります。

時間的緊急性に基づくスケジューリング

スケジューラは以下の2種類の緊急性を区別します：

初期遅延：まだ最初の音声チャンクを生成していないリクエストは、TTFAを最小限に抑えるために最高優先度を与えられます。
再生デッドライン：再生が開始されると、チャンクは再生のデッドラインに近づくにつれて優先度が付与されます。アンダーランを防ぐためです。

GPU効率を維持するために、スケジューラは緊急性の高いリクエストを「アンカー」として選択し、残りのバッチを互換性があり緊急性の低い作業で埋めます。

Code PredictorとCodecの強化

CUDA GraphsとTritonカーネル：Code Predictorは1フレームあたり固定のステップ数（15ステップ）を実行するため、Nari Labsは全ループを1つのCUDAグラフとしてキャプチャし、短いコンテキスト用に特別なTritonアテンションカーネルを活用することで、ホスト駆動のオーバーヘッドを削減しました。
状態キャッシュ付きインクリメンタルデコード：新しいチャンクごとにフルフレームの履歴を再処理するのを避けるために、CodecはTransformerコンテキストと畳み込み状態をキャッシュします。最初の音声チャンクにはフルデコードを使用して初期化オーバーヘッドを最小限に抑え、その後は継続的な再生にインクリメンタルデコードに切り替えます。

業界の見解とトレードオフ

コミュニティの議論では、プロダクション環境での超低遅延TTSの展開に際して、いくつかの重要な考慮点が浮き彫りになっています。

「不気味さの谷」：一部の開発者は、200ミリ秒未満の応答は不自然または「不気味」に感じられると主張しています。人間は通常、音声処理に200ミリ秒程度の遅延を持つため、会話が自然に感じられるようにするために、人工的な遅延や制限を設ける必要があるかもしれません。
品質 vs. 遅延：さらに遅延を削減しても、発話のリズム、表現力、全体的な自然さが損なわれる「品質のハードウォール」が存在することが指摘されています。
デバイス内要件：H100の性能は素晴らしいですが、多くの開発者の最終的な目標は、これらの機能をモバイルデバイスに移行し、クラウド遅延を排除し、プライバシーを向上させることです。
エンドツーエンドの遅延：エージェント系のシナリオでは、TTSの遅延はチェーンの一部にすぎません。全体の認識遅延にはSTT（音声認識）とLLM推論も含まれます。一部の意見では、音声トークンを直接LLMに組み込む（OpenAIのGPT-4o/Realtimeのように）モデルでなければ、エンドツーエンドの遅延問題を真に解決できないとされています。

Nari Labsは、実装とベンチマークスイートの両方をオープンソース化しました。