在即時客服電話、AI 語音助理與互動式對話代理人（Voicebots）應用中，互動延遲直接決定了使用者體驗是否流暢自然。人類在日常對話中的輪替停頓（Turn-taking latency）通常介於 200 至 500 毫秒；一旦端到端交互延遲超過 800 毫秒，對話就會出現顯著的遲滯感，甚至引發使用者與語音機器人互相搶話（Talk-over）。
在典型的語音機器人架構中，延遲是由多個環節層層累積而成的：靜音偵測（VAD）、語音辨識（STT）、大型語言模型推論（LLM）、文字轉語音合成（TTS）以及網路媒體傳輸。由於語音合成位於 LLM 產出首批 Token 之後的關鍵路徑上，如何縮短 TTS 的首包音訊時間（Time-to-First-Byte, TTFB），成為將整體延遲壓制在 1 秒以內的關鍵關鍵。
Resemble AI 提供了基於 WebSocket 的即時串流介面（wss://websocket.cluster.resemble.ai/stream）。結合長連線複用、原生二進位 PCM 傳輸、非對稱文本分塊策略以及打斷（Barge-in）處理機制，開發者能將 Resemble AI 的語音合成響應延遲穩定壓縮至 200–350 毫秒。
1. 對話機器人的端到端延遲預算
為了找出系統效能瓶頸，我們需要拆解語音對話輪次中的耗時結構：
| 處理階段 | 典型耗時範圍 | 關鍵工程最佳化手段 |
|---|---|---|
| 語音活動偵測（VAD） | 200 ms – 400 ms | 微調靜音判定門檻（如 Silero VAD）；動態截斷語尾 |
| 語音辨識（STT） | 150 ms – 300 ms | 透過 WebSocket 串流接收即時部分轉錄 |
| 大型模型首字生成（TTFT） | 150 ms – 350 ms | 選用低延遲推論叢集；推測解碼；精簡系統提示詞 |
| 文本分塊與 TTS 首包（TTFB） | 200 ms – 350 ms | Resemble AI WebSocket 串流介面；非對稱文本分塊 |
| 網路傳輸與抖動緩衝 | 30 ms – 80 ms | WebRTC 媒體轉發（如 LiveKit）；同區域機房部署 |
| 端到端總延遲 | 730 ms – 1480 ms | 必須透過串流流水線重疊執行，以達到 800 ms 自然體驗 |
傳統 REST API 模式下，系統必須等待整句甚至整個段落文字合成完畢後才返回完整的音訊檔案，單是 TTS 階段就會產生 1.5 到 3 秒的等待時間。而在串流合成模式中，首個音訊訊框生成即可立即送入播放端，使語音合成耗時脫離串行阻塞路徑。
2. 合成傳輸協定的評估與選擇
Resemble AI 提供三種主要的語音合成模式，但在對話式語音機器人場景中，傳輸協定的選擇至關重要：
同步 REST 介面（POST /api/v2/projects/{project_uuid}/clips）
完整產生整個音訊片段後單次返回檔案。適合非同步批次作業、靜態語音提示（IVR）或長片旁白，完全不適合低延遲對話。
HTTP 分塊串流介面（POST https://f.cluster.resemble.ai/stream）
透過 HTTP 分塊編碼返回 WAV 資料流。雖然可以在音訊生成時邊收邊播，但每個對話輪次都必須重新發起 HTTP 請求，伴隨重複的 TCP 握手與 TLS 協商成本（每次增加 80–150 ms 的網路額外開銷）。
WebSocket 即時串流介面（wss://websocket.cluster.resemble.ai/stream）
維持持久雙向 WebSocket 長連線。在整個通話或連線期間維持熱連線狀態，徹底消除了重複建立連線的往返損耗。音訊以輕量訊框連續傳輸，並附帶單詞等級的時間戳記中繼資料。
方案等級與並發限制： Resemble AI WebSocket 串流介面需要 Business 或更高階方案。官方預設每個叢集支援最多 20 個並發連線階段，每個 API 金鑰支援 20 個平行連線。
3. 請求承載資料與音訊參數最佳化
在 WebSocket 通訊中，合理配置音訊參數不僅能降低網路傳輸資料量，還能顯著減輕媒體伺服器的編解碼計算負擔：
{
"voice_uuid": "YOUR_VOICE_UUID",
"project_uuid": "YOUR_PROJECT_UUID",
"data": "您好！請問有什麼我可以為您服務的？",
"binary_response": true,
"request_id": 1,
"output_format": "wav",
"sample_rate": 16000,
"precision": "PCM_16",
"no_audio_header": true,
"apply_custom_pronunciations": false
}
關鍵參數調校實踐
-
binary_response: true
預設情況下（false），伺服端以 JSON 格式返回 Base64 編碼的音訊字串。Base64 會增加約 33% 的頻寬消耗，並在收發兩端帶來額外的字串序列化與解碼計算。開啟binary_response: true直接串流傳輸純二進位音訊位元組，效能最佳。 -
precision: "PCM_16"
Resemble 部分端點預設採用PCM_32。在人聲通話場景中，16 位元線性 PCM（PCM_16）在維持極高品質人聲的同時，傳輸資料量直接減半。此外，PCM_16與絕大多數 WebRTC 引擎和電話媒體閘道器的原生格式相容，免去了在中間伺服器重新取樣或轉換位元深度的耗時。 -
sample_rate: 16000（或24000）
錄音室製作多採用 44.1 kHz 或 48 kHz，但在互動式語音機器人或電話系統（如 Twilio、SIP、G.711、Opus）中，16 kHz 寬頻音訊已具備極高的清晰度。相比 48 kHz，16 kHz 的傳輸位元組量減少了三分之二，可大幅降低網路抖動與封包排隊延遲。 -
no_audio_header: true
在二進位回應模式下，開啟此參數會移除首個音訊區塊中的標準 44 位元組 RIFF/WAV 檔頭，直接輸出純粹的 PCM 採樣串流。下游媒體管線（如 WebRTC AudioTrack 或電話 RTP 封包處理器）可直接推流，無須進行檔頭剝離處理。 -
apply_custom_pronunciations: false
除非業務流程中必須比對特定的專有名詞發音字典，否則建議設為false，避免在每次合成時增加發音字典的檢索延遲。
4. 文本分塊策略：非對稱管線設計
將大語言模型的串流 Token 輸出接入 Resemble AI 時，開發者經常面臨分塊粒度的取捨難題：
- 依單字發送（粒度過細）： 僅累積 2–3 個字詞就送入 TTS，語音引擎缺乏語意與語調上下文，容易導致語調平淡、生硬，且造成 WebSocket 請求過於頻繁。
- 依整句或整段發送（粒度過粗）： 等待大模型生成完整長句再進行合成，強行增加了 800–1500 毫秒的大模型串行等待時間。
最佳解法是採用非對稱文本分塊策略（Asymmetric Utterance Planning）：
[ 使用者結束發言 ]
│
▼
[ LLM 開始串流輸出 Token ]
│
├─► 第 1 塊（激進低延遲）：截取至第一個標點（逗號/冒號/破折號）或 4–8 個詞
│ │
│ ▼
│ 推入 Resemble AI WebSocket ──► 首段音訊在 ~300 ms 內起播
│
└─► 第 2 塊及後續（語法完整句）：按完整句尾標點（句號/問號/驚嘆號）分塊
│
▼
推入 Resemble AI WebSocket ──► 在第 1 塊播放時於背景合成，平滑銜接
第一塊：激進的小片段
偵測到第一個子句停頓符號（如逗號 ,、分號 ;、冒號 :、破折號 —）或累積至 4 到 8 個單詞（約 20–35 個字元）時，立即截斷並提交給 Resemble AI。即使只有 5 個單詞，音訊播放也需要 1.5 到 2.5 秒，這為後續文本的生成與合成爭取到了充裕的緩衝時間，同時將首聲響應壓制在 300 ms 左右。
後續分塊：完整的自然句
當第一塊音訊在用戶端緩衝播放時，系統將後續 Token 按照完整句子邊界（句號 。/.、問號 ？/?、驚嘆號 ！/!、換行符號）進行累積與分塊。這能讓 Resemble Ultra 充分掌握語意斷句、語氣起伏與自然呼吸感，保障高擬真度的語音輸出。
文本清洗與格式過濾
大模型在對話中常輸出 Markdown 標記符號（如粗體 **、斜體 *、清單項目 - 、反引號等）或 Emoji。若直接送入 TTS，模型可能會讀出特殊字元或造成異常停頓。在送入 WebSocket 之前，應透過輕量正規表達式進行即時過濾：
import re
CLEANUP_REGEX = re.compile(r"[*_#`~]|\[.*?\]\(.*?\)|\n\s*[-*]\s*")
def sanitize_for_tts(text: str) -> str:
cleaned = CLEANUP_REGEX.sub(" ", text)
return " ".join(cleaned.split())
5. 連線池管理與請求追蹤
為每個對話輪次建立新的 WebSocket 連線會徹底抹消所有的延遲最佳化效益。每一次 TLS 握手與連線建立都需要 100 至 250 毫秒的網路往返時間。
架構實踐準則
- 維持會話層級長連線： 在整個語音通話或 WebRTC 連線期間，保持 WebSocket 連線在線。
- 預熱連線池（Warm Connection Pool）： 在高並發媒體伺服器中預先建立與
wss://websocket.cluster.resemble.ai/stream的長連線池，新通話建立時直接分派閒置 Socket。 - 利用
request_id關聯狀態： 在同一條連線上發起多次合成時，透過遞增request_id區分。當收到帶有相應request_id的audio_end訊息時，狀態機確認該片段推送完成。
import asyncio
import json
import websockets
class ResembleAudioStreamer:
def __init__(self, api_token: str, voice_uuid: str, project_uuid: str):
self.uri = "wss://websocket.cluster.resemble.ai/stream"
self.api_token = api_token
self.voice_uuid = voice_uuid
self.project_uuid = project_uuid
self.ws = None
self.request_counter = 0
async def connect(self):
headers = {"Authorization": f"Bearer {self.api_token}"}
self.ws = await websockets.connect(self.uri, extra_headers=headers)
async def stream_utterance(self, text_chunk: str, audio_queue: asyncio.Queue):
self.request_counter += 1
req_id = self.request_counter
payload = {
"voice_uuid": self.voice_uuid,
"project_uuid": self.project_uuid,
"data": text_chunk,
"binary_response": True,
"request_id": req_id,
"output_format": "wav",
"sample_rate": 16000,
"precision": "PCM_16",
"no_audio_header": True
}
await self.ws.send(json.dumps(payload))
while True:
message = await self.ws.recv()
if isinstance(message, bytes):
# 接收純 PCM_16 二進位音訊資料，送入媒體播放佇列
await audio_queue.put(message)
else:
data = json.loads(message)
if data.get("type") == "audio_end" and data.get("request_id") == req_id:
break
elif data.get("type") == "error":
raise RuntimeError(f"Resemble API 錯誤: {data.get('message')}")
6. 使用者插話（Barge-In）與通訊端保活
在自然的語音對話中，使用者經常會在語音機器人說話時打斷。一旦 VAD 在機器人播音時偵測到使用者開始說話，系統必須立即執行快速插話中斷機制：
- 立即清空播放緩衝區： 瞬間丟棄用戶端播放佇列、WebRTC 軌道或電話抖動緩衝區中的音訊資料，確保在 50 毫秒內靜音。
- 捨棄過期音訊訊框： 遞增內部的對話輪次識別碼（如
active_turn_id）。後續從 Resemble WebSocket 收到的舊request_id音訊訊框直接捨棄，不送入播放端。 - 切勿關閉 WebSocket： 嚴禁因為使用者打斷而中斷 TCP/WebSocket 連線。重新連線會導致下一輪語音回答多出數百毫秒的建連延遲。只需忽略舊的在途資料，即可在同一條連線上直接發送新的合成請求。
7. 開源框架整合方案
為了避免自行從頭撰寫底層狀態機，現代語音機器人架構多採用成熟的編排框架來整合 Resemble AI：
LiveKit Agents（livekit-plugins-resemble）
LiveKit 是業界廣泛採用的開源即時音訊框架，支援極低延遲的 WebRTC 傳輸與電話閘道器整合：
uv add "livekit-agents[resemble]~=1.8"
from livekit.agents import AgentSession
from livekit.plugins import resemble
session = AgentSession(
tts=resemble.TTS(
voice_uuid="YOUR_VOICE_UUID",
),
# 設定相應的 VAD、STT 與語言模型
)
LiveKit 原生具備抖動緩衝處理、WebRTC 封包管理與即時插話中斷清理功能，能將 Resemble 合成的串流音訊無縫推送至通話房間。
Pipecat（pipecat-ai[resemble]）
Pipecat 採用管線與訊框驅動架構（Frame-based Pipeline），其內建的 ResembleAITTSService 提供了非同步訊框串流、單詞級時間戳記對齊以及開箱即用的打斷回復能力。
8. 低延遲工程自檢清單
在將基於 Resemble AI 的語音機器人部署到生產環境前，請依照以下檢查清單逐項核對：
- 協定選用： 確認使用
wss://websocket.cluster.resemble.ai/stream長連線，杜絕在即時對話中使用同步 REST 請求。 - 參數調校： 確保啟用
binary_response: true、precision: "PCM_16"、sample_rate: 16000與no_audio_header: true。 - 分塊策略： 實作非對稱管線——首個區塊在第一個逗號或 4–8 個詞時立即發送，後續文本按完整自然句聚合發送。
- 文本過濾： 在送入合成前剔除 Markdown 標記與程式碼區塊，防止模型誤讀或異常停頓。
- 連線複用： 在多輪對話與插話情境下持續維持 WebSocket 在線，嚴禁插話時暴力斷線重連。
- 同區域部署： 將機器人編排服務與 Resemble 叢集及大模型部署於相同或鄰近的雲端機房區域，最小化網路來回時間。