提升正式環境 TTS 效能的九種降延遲方法

文字轉語音延遲，是指送出文字到聽見第一個音訊之間的時間差。對語音代理或即時字幕而言，這段時間正是使用體驗的關鍵。Speechify API 提供多種工具來降低延遲。本文將介紹九種優化方法，涵蓋模型選擇到連線重用。

如需深入了解各項優化的工程細節，請參閱 speechify.ai 的更新日誌。你也可以先從串流 TTS 說明開始：speechify.ai/streaming-tts。

如何選擇最快的 TTS 模型？

英文任務建議使用 Simba 3.2。這是推薦模型，專為串流優化，首字節延遲最低。多語言文本可選用 Simba 3.0，只需額外設定語言參數，速度同樣很快。舊款模型僅為相容性而保留，延遲較高，不建議優先使用。

請依實際需求選擇模型。若是低延遲語音代理，建議使用 Simba 3.2。若是長篇有聲書，則兩種模型皆可，因為不需要即時回應。

該用串流，還是等待完整音檔？

如果使用者需要即時收聽，就應使用串流。呼叫 POST /v1/audio/stream 後即可邊收邊播，無需等待整份音檔完成。串流端點會分段回傳音訊，讓第一個聲音能更快送達：https://docs.speechify.ai/build/api-reference/v1/audio/stream

如果串流時還需要取得時間戳記或逐字標記，可使用 POST /v1/audio/stream/with-timestamps 端點：https://docs.speechify.ai/build/api-reference/v1/audio/stream/with-timestamps

邊緣部署有幫助嗎？

有，可以少一次網路往返。單一邊緣函式可呼叫 API，並即時將音訊串流回傳，而且執行位置更靠近使用者。最終延遲取決於從使用者端到我們 API 伺服器再回傳的總時間，無論請求來自使用者、本地應用程式或邊緣端。

哪種輸出格式最快？

請選擇可直接播放、無需轉碼的格式。電話系統建議使用 ulaw_8000，符合 Twilio 格式；瀏覽器則建議使用 PCM，或播放器可直接處理的格式，以避免額外解碼延遲。

從 API 到喇叭之間的轉換步驟越少，延遲就越低。

並行處理如何降低感知延遲？

如果有多段短文本，建議並行生成。一次生成十段字幕，通常比逐條處理快得多。API 支援並發請求，可依工作量分批處理。

為什麼要重用連線？

盡量只建立一條 HTTP 連線並持續重用。TLS 交握與連線建立雖然每次只花一點時間，但累積到數千次請求後，開銷就會變得明顯。重用連線可省去這類成本。

重複文本可以快取嗎？

經常會唸出的文本，很適合做音訊快取。例如按鍵提示、問候語和固定 UI 字串，都常重複出現。可依輸入內容、聲線和模型設定組合建立快取鍵，下次直接重用。完整做法可參考快取 TTS 成本的專文。

如何精簡輸入？

文本越短，合成就越快。刪除多餘內容、縮短開場白，只傳送使用者真正需要聽到的內容。文字越精簡，音訊越短，第一段輸出也會更快。

逐字時間標記能掩蓋延遲嗎？

可以。使用 POST /v1/audio/stream/with-timestamps 串流時，可同步取得逐字標記。字幕能隨文字逐字顯示，讓使用者即時看到進度。即使音訊總長不變，整體體驗也會更流暢。

常見問答

理想的 TTS 延遲目標是多少？

語音代理應以首個聲音能在數百毫秒內播放為目標。串流技術可以做到。若是批次工作，則應更重視總時長，不必過度在意首字節延遲。

串流生成會增加費用嗎？

不會。費用是依合成字數計算，串流只影響交付方式，價格不變。

Speechify 哪個模型最快？

Simba 3.2。這是官方推薦、原生支援串流的模型，在英文任務中的首字節延遲最低。

應該快取 TTS 音訊嗎？

若是重複文本，建議快取。以輸入內容、聲線和模型作為快取鍵來保存生成片段，就能直接重用，無需重新合成。