語音代理最怕沉默：使用者在畫面前等了三百毫秒還聽不到聲音，體感就是卡住了。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* 同場比較，而且先把每套引擎都調到低延遲串流的最佳狀態才開始比。結果相當殘酷：調校後只有 VoxServe 在每秒一次請求時勉強達標（p95 TTFA 49.3 毫秒），vLLM-Omni 是 56.8 毫秒，M* 與 SGLang-Omni 都超過 100 毫秒；到了每秒 6 次請求，四套引擎全部落在約 100 毫秒以上。
Nari 自己的版本則把 50 毫秒的 p95 TTFA 一路撐到 10 RPS，20 RPS 時也還守在 100 毫秒以內。同樣的模型，同樣的硬體，差的是服務層的工程。
一個排程器管三個模組
Qwen3-TTS 的架構分成三段：Talker 預測每個音訊框的第一組離散碼，Code Predictor 補齊其餘 15 組碼，causal Codec 把碼轉成波形。多數服務實作把前兩段綁在一起跑、Codec 另外排程；Nari 反其道而行，把三個模組全部變成獨立可排程的任務，交給同一個排程器管理，設計參考了 M*。
關鍵不是「拆開」而是「合管」。把 Talker 和 Code Predictor 合併看起來少一次交接，但合併後的操作容易變成不可搶佔的大任務，反而擋住更急的 Codec 工作；模組各自獨立，工作單位變短，排程器才有空間隨時插隊、按急迫度重排順序。
圍繞語音串流的緊急度排程
語音串流有兩種完全不同的「急」。第一音出來之前，每多一毫秒都直接算進延遲；但播放開始後，下一塊音訊只要趕在目前的音檔播完前抵達就好，早到對使用者沒有任何可感知的好處。
Nari 的排程器因此讓「還沒出聲」的請求拿高優先級；已開始的串流只在接近播放期限時才升級為緊急。為了不摧毀批次效率，排程器會挑一個緊急請求當錨點，再用相容的工作填滿同一批——急活兒優先，但批次照樣塞滿。
對語音開發者的意義
這篇貼文對做語音產品的人有三個訊號。第一，TTS 的競爭點正在從音質轉向延遲與併發：模型相同，服務層的工程可以差出一個量級，選供應商時該問的是排程器而不是取樣器。第二，「即時」該寫進你的服務水準目標——p95 首音延遲、緩衝中斷次數、高併發下的表現，這三個數字比任何展示影片都誠實。第三，實作與基準已開源，自架語音服務的團隊可以直接拿來量測自己的工作負載，不必再靠官網 demo 猜性能。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。