Qwen3-TTS 低於 50 毫秒延遲的效能與成本優化

Nari Labs 已開發出 Qwen3-TTS 1.7B CustomVoice 模型的客製化實作，可在單一 NVIDIA H100 SXM 上以每秒 10 個請求（RPS）的實時播放速率，達成 p95 時間至第一個音訊（TTFA）低於 50 毫秒的表現。此優化大幅降低高階語音合成的成本，估計在全負載下每百萬字元成本約為 2 美元。

實時 TTS 性能基準測試

為評估實時可行性，Nari Labs 定義成功的 TTS 伺服器需符合四項標準：低可聽 TTFA、零音訊欠載（即客戶端耗盡緩衝音訊）、隨著 RPS 提升仍具高容量，以及輸出內容清晰可辨。

在對五種實作（包括 vLLM-Omni、SGLang-Omni、VoxServe 和 M*）的基準測試中，Nari Labs 的實作是唯一在 10 RPS 下仍能維持低於 50 毫秒 p95 TTFA 的方案。雖然其他引擎如 VoxServe 在 1 RPS 時可達低於 50 毫秒，但隨著負載增加，其延遲顯著上升；例如在 6 RPS 時，大多數引擎的 p95 TTFA 都超過 100 毫秒。

解決常見延遲瓶頸

針對所有測試引擎，Nari Labs 套用兩項主要優化以建立公平基準：

前置靜音移除：模型通常在第一個聲音前產生數十毫秒的靜音。Nari Labs 實作了動態修剪機制，透過 RMS 窗口偵測持續語音並移除前置靜音，使 TTFA 改善約 80 毫秒。
幀累積調校：系統在解碼前平衡收集的編碼器幀數量。較小的初始片段可降低 TTFA，但增加解碼器開銷；較大的片段則提升批次處理與播放穩定性。最佳配置使用小初始片段，並在後續輸出中逐步增加大小。

Qwen3-TTS 的架構優化

Qwen3-TTS 使用分層多碼本生成流程，包含三個模組：Talker（預測第一個碼本的 token）、Code Predictor（生成剩餘 15 個 token）與 Codec（將 token 轉換為波形）。

統一排程表面

Nari Labs 不將流程拆分為生成與解碼兩個階段，而是將 Talker、Code Predictor 與 Codec 視為單一排程器下的三個獨立可排程工作。此設計允許系統根據緊急程度重新安排工作——例如優先處理即將到達播放截止時間的 Codec 工作，而非 Talker 工作——並支援更細粒度的批次處理，針對等待相同模組的請求進行整合。

基於緊急程度的排程

排程器區分兩種緊急程度：

初始延遲：尚未產生第一個音訊片段的請求，給予最高優先權以最小化 TTFA。
播放截止時間：一旦播放開始，僅在片段接近所需截止時間時才進行優先排序，以防止欠載。

為維持 GPU 效率，排程器會選取一個緊急請求作為「錨點」，並以相容的非緊急工作填滿批次餘額。

Code Predictor 與 Codec 優化

CUDA Graphs 與 Triton Kernel：由於 Code Predictor 每幀執行固定次數（15 次）的步驟，Nari Labs 將整個迴圈封裝為單一 CUDA graph，並使用專用的 Triton 注意力 kernel 來處理短上下文，降低主機驅動的開銷。
狀態快取的增量解碼：為避免每次新片段都重新處理完整幀歷史，Codec 使用狀態快取來保留 Transformer 上下文與卷積狀態。系統對第一個音訊片段使用完整解碼以最小化初始化開銷，之後則切換至增量解碼以維持持續播放。

產業觀點與權衡取捨

社群討論凸顯了在生產環境中部署超低延遲 TTS 時的幾個關鍵考量：

「怪異」速度谷底：部分開發者認為，低於 200 毫秒的回應會讓人感覺不自然或「怪異」，因為人類通常有 200 毫秒的聽覺處理延遲。可能需要人為加入延遲或設置限制，才能讓對話感覺更像真人。
品質與延遲的權衡：存在明顯的「品質硬牆」，進一步降低延遲可能損害語調、表達與整體自然度。
裝置端需求：雖然 H100 的表現令人印象深刻，但許多開發者的最終目標是將這些功能移至行動裝置，以消除雲端延遲並提升隱私性。
端到端延遲：在代理情境中，TTS 延遲僅是整個鏈路的一環。總感知延遲還包括 STT（語音轉文字）與 LLM 推理。有人建議，唯有將語音 token 直接內嵌於 LLM 中的模型（如 OpenAI 的 GPT-4o/Realtime）才能真正解決端到端延遲問題。

Nari Labs 已將實作與基準測試套件開源。