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 頻譜轉成連續表徵，每四個時間步合併一次，再經 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 分鐘錄音，以及領域熱詞提示。模型卡自測在 AISHELL-4、Alimeeting、Podcast 與 Movies 上，多數 CER、cpCER 指標優於列出的商用及開放基線。然而 SGLang 說明中的 `movies800times`、`aishell4_long` 和 `googletime` 目前採私人授權，外部團隊難以完整重跑服務基準。接下來應關注公開資料上的吞吐、即時率、重疊語音錯配，以及長音訊批次是否因輸出長度差異造成排程尾延遲。