SGLang-OmniがMOSS-Transcribe-Diarizeに対応、複数話者文字起こしを連続バッチ処理サービスに統合

SGLang-Omniは、MOSS-Transcribe-Diarize向けの正式なサービング構成を公開し、この0.9Bの複数話者音声モデルをOpenAI互換の`/v1/audio/transcriptions`エンドポイントに接続した。アプリケーションは音声を直接アップロードし、`verbose_json`を指定することで、テキスト、開始・終了時刻、匿名の話者ラベルを取得できる。長時間録音の場合は`max_new_tokens`を増やすことで、セグメント単位の出力が完了する前に自己回帰デコードが打ち切られるのを防げる。

この統合の技術的な要点は、単にAPIをもう一層ラップしたことではなく、音声モデルをSGLang-Omniの多段階実行パイプラインに組み込んだ点にある。MOSS-TDはまず、24層のWhisper encoderで80-bin log-melスペクトログラムを連続表現へ変換し、4タイムステップごとに統合した後、MLPを通じて言語モデルのembedding空間へ投影する。続いて28層のQwen3 decoderがKV cacheを構築し、話者とタイムスタンプを含む構造化された文字起こしをtoken単位で生成する。このプロセスでは、ASR、アライナー、diarizationモデルを別々に実行して結果を統合する必要がない。

これによりSGLang-Omniは、既存のCUDA Graph、非同期デコード、連続バッチ処理、KV-cache管理を音声認識ワークロードにも適用できる。公式の起動例では、最大同時リクエスト数、CUDA Graph batch size、静的メモリ比率を設定できる。すでにOpenAI transcription clientを利用しているチームにとっては、カスタムRPCインターフェースを導入する場合よりも移行コストが低い。

モデル自体は50を超える言語、128K context、最長約90分の録音、ドメイン固有のhotwordプロンプトに対応する。モデルカードによる自己評価では、AISHELL-4、Alimeeting、Podcast、Moviesにおいて、多くのCERおよびcpCER指標が、掲載されている商用・オープンベースラインを上回った。一方、SGLangの説明によると、`movies800times`、`aishell4_long`、`googletime`は現在、非公開ライセンスで提供されているため、外部チームがサービングベンチマークを完全に再現することは難しい。今後は、公開データ上でのスループット、リアルタイム係数、重複音声における話者割り当てエラー、さらに長時間音声のバッチ処理で出力長の違いによるスケジューリングのテールレイテンシが発生するかどうかに注目すべきだ。