Qwen3-TTSを10 RPS、サブ50 ms TTFAで：Nari Labsが速度とコストの最前線を押し上げる

Nari Labsは、Qwen3-TTS 1.7B CustomVoiceのサービングに関するベンチマークとオープンソース実装を公開し、大幅な速度とコストの優位性を主張している。彼らのスタックは、単一のNVIDIA H100 SXM上で、毎秒10リクエスト（RPS）を、p95の初回音声までの時間（TTFA）が50 ms未満で達成し、リアルタイム再生をアンダーランなしで維持する。フル稼働時には、約100万文字あたり2ドルに相当し、ElevenLabs V3の100万文字あたり100ドル、Cartesia Sonic 3.5の49ドルと比較される。

ここでの「リアルタイム」の意味

著者らは、リアルタイムTTSを4つの部分からなる問題と定義している：可聴TTFAが低いこと、再生開始後のアンダーランがゼロであること、RPSが増加しても容量が維持されること、そして不正な出力がないこと。彼らは、Fireworks AIのLLMベンチマーク手法に従い、ポアソン開ループトラフィックで5分間ベンチマークを行う。各エンジンは、単一のHTTPリクエストで全文を受け取り、音声がストリーミングで返される。

ベースライン性能：改善の余地

デフォルト設定での1 RPSでは、比較した4つのエンジンのp95可聴TTFAに大きなばらつきが見られる：vLLM-Omniは277.9 ms、SGLang-Omniは1,140.7 ms、VoxServeは315.1 ms、M*は1,160.0 ms。すべてに有意な先行無音（30〜90 ms）があり、vLLM-Omniの場合はリクエストの100%でアンダーランが発生した。

低遅延向けにチューニング（先行無音の除去とフレーム蓄積の調整）を行った後、状況は変わる。1 RPSでは、VoxServeはp95 TTFA 49.3 msを達成するが、6 RPSでは363.2 msに劣化する。他のエンジンは1 RPSでも100 msを超えたままである。Nari Labsの実装は、10 RPSまでp95 TTFAを50 ms未満に維持し、20 RPSでも100 ms未満を維持する唯一のものである。

主要な最適化：3つのモジュールのための1つのスケジューラ

Qwen3-TTSは3つの部分からなるモデルである：Talkerはオーディオフレームごとの最初のコードブックトークンを予測し、Code Predictorは残りの15トークンを生成し、因果Codecはトークンを波形サンプルに変換する。ほとんどのサービングスタックはこれを2つのステージ（Talker+Code Predictorをまとめて、Codecを別々に）に分割し、リクエスト間で生成とデコードを重ね合わせる。

Nari Labsは代わりに、M*から着想を得て、3つすべてを単一のスケジューリング面上で独立してスケジュール可能なタスクとして公開する。これにより、スケジューラは緊急度に基づいて優先順位を付けることができる：最初の音声の前は、すべてのミリ秒が重要であり、再生開始後は、次のチャンクが現在の音声が終了する前に到着すればよい。スケジューラは、同じモジュールを待っているリクエストをバッチ処理し、再生の締め切りに間に合うように作業を並べ替えることができる。

著者らは、TalkerとCode Predictorを組み合わせることは一見効率的に見えるが、プリエンプト不可能なユニットを作り出し、より緊急な作業をブロックすると主張している。それらを分離しておくことで、より短いユニットとより多くのインターリーブの機会が得られる。

コストとオープンソース

1× H100 SXMインスタンス（Lambda価格）で1時間あたり4.29ドルとすると、10 RPSでの毎秒約630文字の主張されるスループットは、100万文字あたり約2ドルになる。実装とベンチマークハーネスはGitHubでオープンソース化されている。