DAY 05 已經把 STT、LLM、TTS 串起來，AI Companion 終於可以完成完整語音對話。

但實際使用後會發現：

可以對話，不代表聊起來自然。

如果使用者說完一句話後，AI 要停頓很久才回答，即使辨識和回答都正確，還是會有很明顯的機器感。

所以今天先不增加新功能，而是拆解目前 CONVERSATION PIPELINE 的延遲。

目前的 PIPELINE

MICROPHONE  
↓  
VAD  
↓  
SPEECH END
↓  
FINAL STT  
↓  
LLM
↓  
TTS 
↓  
PLAYBACK

目前最大的問題是，這些步驟幾乎都是依序執行。

使用者說完
→ 等 VAD 判定結束
→ 等 STT 辨識
→ 等 LLM 完整回答
→ 等 TTS 生成
→ 才開始播放

即使每個階段只有幾百毫秒，全部累積起來還是會產生明顯延遲。

延遲拆解

我把一次對話拆成幾個時間點：

t0 SPEECH END
t1 VAD CONFIRM
t2 FINAL STT DONE
t3 LLM FIRST TOKEN
t4 LLM DONE
t5 TTS DONE
t6 PLAYBACK START

這樣就能分別量測：

• VAD 判定時間
• FINAL STT 時間
• LLM FIRST TOKEN
• LLM TOTAL
• TTS 生成時間
• PLAYBACK 啟動時間

其中最重要的指標是：

SPEECH END → FIRST AUDIO

因為這才是使用者真正感受到的等待時間。

LATENCY LOG

之後每一輪對話都會統一記錄：

VAD
FINAL STT
LLM FIRST TOKEN
LLM TOTAL
TTS
PLAYBACK
TOTAL

DAY 05 的短句測試中，FINAL STT 約 0.23 秒，LLM 完整回覆約 0.48～0.71 秒。

不過今天沒辦法完成真人麥克風的多輪實測，因此先不加入新的 BENCHMARK 數字，避免用推測代替實測。

BOTTLENECK 在哪？

目前看起來，最大的問題不一定是某個模型特別慢，而是：

每個階段都要等前一步完全完成。

例如 LLM 已經產生：

「今天天氣不錯……」

目前還是必須等整段回答完成後，才能交給 TTS。

TTS 也要生成完一整段語音後，才開始播放。

所以單純把模型換快一點，改善仍然有限。

FIRST ROUND OPTIMIZATION

在 STREAMING 前，先做一些基本優化：

• 模型預先 WARM-UP
• 模型常駐，不重複載入
• 減少不必要的 FILE I/O
• 控制 LLM 回覆長度
• 統一記錄各階段時間

這些結果也會成為 DAY 07 的 BASELINE。

NEXT STEP

目前的流程是：

STT → LLM → TTS → PLAYBACK

DAY 07 準備把它改成 STREAMING PIPELINE，讓 LLM 還在生成時，前面的文字就能先交給 TTS。

也就是不再等：

「整句都想完才開口」

而是：

「想到一部分，就先開始說。」