直播延遲優化方案

在經營 AI VTuber 的過程中，你是否也遇過「觀眾在聊天室打完字，卻要等上快半分鐘才聽到角色回應」的尷尬狀況？

為了提升直播的即時互動感，我們的目標是將「打字送出 → 直播端聽到第一個字」的延遲，從原本漫長的 28 秒 壓縮到可接受的實用範圍（對於 AI VTuber 來說，通常延遲在 5 至 7 秒內 就算是相當流暢、堪用的體驗了）。

本篇文章將基於 010-AI-VTuber 專案的 prototype（main.py）於 2026-06-09 的實測數據，為大家拆解延遲的組成，並提供一套循序漸進的優化指南。

在動手之前，建議先閱讀 AI-VTuber 是什麼-白話入門與 GPT-SoVITS 與 Live2D 接線安裝指南來幫助你掌握整個系統的架構。

實測基準與延遲拆解 (2026-06-09)

在未優化的狀態下，我們的 main.py 內建計時顯示：LLM 6.4s ｜語音 9.4s ｜合計 15.9s。然而，直播端觀眾實際上卻要等大約 28 秒 才能聽到第一個字。這中間的落差究竟在哪裡？

首先，我們要先釐清兩個非常容易誤判的關鍵點：

「語音 9.4s」並不等於純延遲：在程式碼中，播放語音的行為是「阻塞式」的（也就是在 _play_buffer 的 s.write(data) 執行時，必須等到整段話全部播完才會返回）。因此，這 9.4 秒其實包含了：語音合成時間 + ffmpeg 轉檔時間 + 語音本身的播放長度。真正導致「開口前等待」的系統延遲，其實只有 LLM 6.4s + 合成與轉檔約 2–3s ≈ 9s，剩下的時間只是它在說話。
28s − 15.9s ≈ 12s 的時間差，幾乎全是 YouTube 串流緩衝：這段高達 12 秒的延遲，其實不需要改任何程式碼，單純調整平台設定就能立刻砍掉，是目前最大、也最容易解決的痛點。

延遲組成視覺化拆解

打字 ──▶ [LLM 生成 ~6.4s] ──▶ [合成+轉檔 ~2-3s] ──▶ [開口、講完 ~6s] ──▶ [YouTube 串流緩衝 ~12s] ──▶ 觀眾聽到
        └────────── main.py 計時的 15.9s ──────────┘   └──── 設定就能砍 ────┘

延遲優化方案（按投報率排序）

針對上述拆解，我們規劃了四個優先等級（Tiers）的優化手段。建議大家按照順序執行，以取得最高的投資報酬率。

第一優先｜Tier 1：調整平台與軟體設定（0 程式碼，立刻砍掉約 12 秒）

這是完全不需要動到 code、零風險且立竿見影的優化：

YouTube 後台調整：進入串流設定，將「串流延遲」改為 「超低延遲 (Ultra-low latency)」。一般模式的延遲約為 15–20 秒，而超低延遲可壓在 2–4 秒。光是這一步，就能讓觀眾端延遲從 28 秒直降到約 16 秒。
OBS 編碼設定：使用 NVIDIA 顯示卡的硬體編碼（NVENC），並在預設檔（Tune）中選擇「low latency（低延遲）」，同時將關鍵影格間隔（Keyframe Interval）設定為 1–2 秒。

第二優先｜Tier 2：重構程式碼，改為逐句串流（大幅降低首字反應時間）

目前的程式邏輯是「完全序列式」的：必須等待整段 LLM 文字生成完畢 → 開始語音合成 → 播放。我們可以將其重構為：

LLM 啟用串流：設定 stream: true，讓 LLM 邊生成邊接收 token。
逐句切割與播放：當程式收到第一個句號或驚嘆號（如：。！？）時，立刻將第一句話送去合成並播放；在此同時，後面的句子則在背景一邊合成、一邊放入播放佇列中。
這樣一來，「開口前的等待時間」會直接從「整段 LLM + 整段語音合成」縮短為「第一句 LLM + 第一句語音合成」，大約只需 3–4 秒。

配合 Tier 1 的設定優化後，觀眾端在 6–7 秒內 就能聽到 AI VTuber 開口。

第三優先｜Tier 3：減少生成工作量（快速且立即見效）

精簡 System Prompt：在 AI 的人設提示詞中，明確限制「回覆控制在 1–2 句內，並盡量口語化」，同時將 API 呼叫的 max_tokens 限制在 100 左右。生成字數變少（LLM 變快）、需要合成的語音變短（TTS 變快），雙重受益。這對於免費的 chatty 模型尤為有感。
優化轉檔路徑：將 _to_wav48 的 ffmpeg 轉檔邏輯移出關鍵路徑。在實現「逐句串流」後，轉檔動作可以與語音播放重疊進行，這部分的影響將會降到最低。

第四優先｜Tier 4：改用付費 LLM（提升穩定性與首字延遲）

免費層的模型有時會遇到冷啟動或排隊問題，這也是為什麼有時 LLM 反應會拖到 6.4 秒。付費模型（例如 deepseek-chat）通常能在 1–3 秒內給出回應且表現穩定。在串流模式下，首字延遲（TTFT, Time-to-first-token） 的表現至關重要。其成本大約只需儲值 $10 美元，每次對話僅花費幾分錢，非常划算。

建議執行順序與預期成效

建議大家按照以下步驟逐步實施優化：

現在立刻動手：修改 YouTube 後台的「超低延遲」並調整 OBS 編碼為 low latency。這是一點進去就能改好的，完全沒有開發風險。
改寫程式碼：將 speak() 方法與 LLM 的呼叫邏輯重構成**逐句串流（Streaming）**模式，並在 prompt 中加入精簡回覆的限制與 max_tokens 設定。
實測與評估：跑完上述兩步後，觀察新的延遲數據。如果覺得速度仍不夠穩定，再考慮付費升級 LLM API。

預期優化成效表

階段	觀眾端聽到第一個字的時間
現況（未優化）	~28s
加上 Tier 1（超低延遲設定）	~16s
加上 Tier 2（逐句串流重構）	~6–7s
加上 Tier 3/4（精簡 Prompt + 付費 API）	~4–5s

小結

優化 AI 直播延遲的核心邏輯，在於「減少不必要的等待」與「利用非同步併發來隱藏延遲」。藉由 YouTube 平台設定與程式端改為「逐句串流」雙管齊下，我們成功把原本令人出神的 28 秒延遲，壓縮到了極具互動感的個位數秒數。如果你也正在開發自己的 AI 串流專案，不妨今天就試試這套優化方案！

Jun 的學習筆記

探索