摘要： Nari Labs 公布的 Qwen3-TTS 1.7B 部署在單張 NVIDIA H100 SXM 上維持每秒 10 次請求，p95 首音延遲低於 50 毫秒。關鍵做法是把 Talker、Code Predictor 與 Codec 交給同一個共用排程器，並依是否尚未產生首音來排定急迫度。開源實作與基準顯示服務層工程足以大幅改變即時語音的可用性。
對語音代理來說，沉默是最要命的失敗。使用者盯著畫面等三百毫秒，耳朵裡卻還沒有一點聲音，感受上就已經壞了。Nari Labs 在 8 月 19 日發布的研究貼文，說明服務層能把這個數字推到哪裡：他們的 Qwen3-TTS 1.7B 部署跑在單張 NVIDIA H100 SXM 上，維持每秒 10 次請求，p95 首音延遲（TTFA）低於 50 毫秒，播放不中斷。實作與基準測試都已開源。
即時語音的四項門檻
Nari 把即時 TTS 服務拆成四件事。首音要快，也就是請求送出到第一個可聽見樣本之間的時間必須短；播放不能斷，用戶端緩衝不得見底；規模要撐得住，讓前兩項在併發量攀升時依然成立；輸出要正確，語音必須聽得懂。
主角選 Qwen3-TTS 1.7B CustomVoice，理由是實務考量：使用者多、授權寬鬆。測量紀律和目標一樣重要——每輪以 Poisson 開環流量跑滿五分鐘，方法學對齊 Fireworks AI 的 LLM 基準；偵測的是「可聽見的 TTFA」，播放流程依收到的 PCM 重建，完成的音訊再交給 Deepgram 語音辨識評估。五套引擎，同一把尺。
五套引擎，同一場比較
Nari 用自己的實作對上 vLLM-Omni、SGLang-Omni、VoxServe 與 M*，而且是在把每套引擎都調到低延遲串流的最佳狀態之後，才開始比較。結果並不客氣：調校完成後，1 RPS 時只有 VoxServe 勉強跨過門檻，p95 TTFA 為 49.3 毫秒；vLLM-Omni 為 56.8 毫秒，M* 與 SGLang-Omni 都超過 100 毫秒。到了 6 RPS 左右，四套引擎通通落在約 100 毫秒以上。
Nari 的版本則把 p95 TTFA 低於 50 毫秒的水準一路維持到 10 RPS，20 RPS 時也還不到 100 毫秒。模型相同、硬體相同，差別全在服務層的工程。
三個模組，一個排程器
Qwen3-TTS 是分成三段運作的模型：Talker 預測每個音訊框的第一組離散碼，Code Predictor 補上其餘 15 組碼，causal Codec 再把碼轉成波形取樣。多數服務堆疊把前兩段一起執行，Codec 另外排程。
Nari 走的是相反的路：三個模組全都變成可獨立排程的任務，交給同一個共用排程器，設計參考了 M*。重點不在拆開，而在合管。把 Talker 與 Code Predictor 併在一起，看似少掉一次交接，但合併後的操作會變成不可搶佔的工作單位，反倒擋住更急迫的 Codec 任務；模組各自獨立則產生更短的工作單位，排程器才有餘裕按急迫度交錯安排請求，而非照固定順序執行。
按語音急迫度排程
語音串流裡的「急」有兩層完全不同的意思。第一批音訊抵達之前，每一毫秒都直接加進感知延遲；但播放一旦開始，下一塊音訊只要在目前這段播完之前送到就好，提早抵達對使用者沒有任何好處。
所以 Nari 的排程器把高優先級給了尚未產生音訊的請求，已經在播的串流則要接近播放期限才升級為緊急。為了不犧牲批次效率，排程器會挑一個緊急請求當錨點，其餘批次用相容的工作填滿：急件先插隊，但每一批離開 GPU 時仍然是滿的。
對語音開發者的三個訊號
第一，TTS 的競爭前線正從音質轉向延遲與併發：模型不變，服務層的工程就能讓數字差出一個量級，所以該問供應商的是排程器，而不是取樣器。第二，把「即時」寫進你的服務水準目標——p95 首音延遲、緩衝中斷次數、負載下的表現，這三個數字比任何展示影片都誠實。第三，實作與基準都已開源，自營語音服務的團隊可直接拿它對照自己的工作負載，不必從官網 demo 猜性能。