如果你也想打造類似 Neuro-sama 那樣極具娛樂效果的 AI 直播，那麼「雙 AI 角色互相 ban-and-banter（對話），同時還能被觀眾留言打斷」的雜談台，絕對是最理想的驗證目標。
在我們的 010-AI-VTuber 專案中，這項「方針 1」的演出方針已於 2026-06-10 正式拍板。本篇將會詳細拆解雙 AI 雜談台的架構設計與執行步驟。如果你對 AI VTuber 的基礎概念還不熟悉，建議先閱讀這篇前置準備：AI-VTuber 是什麼-白話入門。
以下是我們針對這個系統運作的硬體可行性評估、技術挑戰，以及分階段驗證的實戰藍圖。
0. 硬體可行性評估：GTX 1660 6GB 實測結論
在動手寫程式之前，大家最關心的通常是硬體門檻。經過筆者在 2026-06-10 的實際測試，答案是完全可行，顯卡 VRAM（視訊記憶體）並非此架構的瓶頸。
這與先前嘗試在本地部署 GPT-SoVITS 與 Live2D 接線安裝指南 的狀況正好相反：
| 評估項目 | 之前本地部署 GPT-SoVITS | 方針1 雙AI 運作架構 |
|---|---|---|
| 本地深度模型 | 有（FP32，吃好幾 GB） | 無 |
| LLM（大語言模型） | — | 雲端 OpenRouter（0 本地 VRAM） |
| TTS（語音合成） | 本地克隆吃 VRAM | edge-tts 雲端（0 本地 VRAM） |
| 本地 GPU 負擔 | VTS + FP32 運作 → 容易爆掉 | 只多「第 2 個 Live2D 渲染」（2D，負擔極輕） |
實測數據參考（單一 VTube Studio 實例開啟時）： 在 6144MiB (6GB) 的總 VRAM 中，已用約 2.1GB、剩餘約 3.8GB、GPU 使用率 29%。 依此推算，未來開啟「雙 VTS + OBS」運作時，預估僅需 3.5–4GB 的 VRAM（因為第二個 VTS 實例只會額外增加約 0.5~1GB 消耗，桌面基底資源是共用的）。這對於 6GB 的顯卡來說依然綽綽有餘。
由此可見，真正的風險與瓶頸並非硬體規格，而是屬於純軟體層面的「編排層（Orchestration Layer）」設計。
1. 雙機運作面臨的三大挑戰
要讓雙 AI 順利上線，我們必須克服以下三個層面的挑戰：
| 挑戰項目 | 具體內容 | 難易度 |
|---|---|---|
| 設定 A | VTS 一個實例只能載入一個模型 → 雙角色必須開啟 2 個 VTS 實例。 | 低 |
| 設定 B | 需要 2 條獨立的虛擬音訊線，確保每個角色的聲音只會驅動各自的嘴巴。目前系統只有 1 條 VB-CABLE，後續需加裝第 2 條（如 VB-CABLE A+B 或 Voicemeeter）。 | 中 |
| 核心挑戰 | 編排層設計：如何讓兩個 AI 輪流說話、不同時出聲、不產生鬼打牆現象，且能隨時被聊天室觀眾打斷。 | 高 |
2. 兩階段驗證策略：低成本拆解風險
為了避免一開始就卡在硬體和複雜的音訊設定，我們採取「先驗證軟體邏輯，再串接硬體畫面」的兩階段策略，以最便宜、高效的方式排除專案風險。
階段 A：雙 AI 對話（零額外硬體，優先驗證）
這個階段的目標是先驗證最難、最關鍵的「對話是否精彩好看」，此時完全不碰 VTS 與音訊線。
- 撰寫第 2 個角色的描述 JSON（設定與第一隻角色形成性格反差）。
- 設計「輪流發話」的調度邏輯：決定誰先起頭、如何分配輪次，並將對方的上一句話正確餵進彼此的 context 中。
- 串接兩種 edge 聲線，零成本地區分兩個角色的聲音。
- 實作「出聲互斥」機制：引入佇列鎖（Queue Lock），避免兩張嘴同時說話。
- 防鬼打牆機制：共享最近話題記憶，一旦偵測到重複語意就強制換題。
- 實作「觀眾打斷」功能：留言進來時，打斷原本的自走對話，優先回應觀眾。
- 用單一喇叭播放完整對話，驗證整體對話流暢度。
階段 B：上臉與推流（A 階段成功後才啟動）
- 實際開啟 2 個 VTube Studio 實例。
- 設置第 2 條虛擬音訊線，確保每種聲音只驅動其對應模型的嘴巴。
- 修改
main.py：使其支援「每個角色路由到不同的音訊輸出裝置」（目前為單一全域設定，需進行小幅度改寫）。 - 在 OBS 進行雙視窗排版（同框配置），並進行推流穩定性實測。
- 持續監看 1660 顯卡的實際 VRAM 與 GPU 使用率，確保直播不掉幀。
3. 編排層設計的核心重點（核心風險所在）
雙 AI 的架構絕非「兩個機器人各自對話」那麼簡單。要讓直播具有觀賞性，對話必須聽起來像真實的互動：
- 回合制調度：運作流程為「A 說話 → 將 A 的回覆作為輸入餵給 B → B 回應 → 再將 B 的回應餵回 A」，以此輪流推進對話。
- 出聲互斥（重要）：必須設計一個全域的「說話佇列鎖（Queue Lock）」。在同一時間內，只允許一個角色進行語音合成與輸出，講完後釋放鎖，另一個角色才能接力說話，否則兩條 TTS 音訊會重疊在一起，導致觀眾聽不清楚。
- 防鬼打牆機制：系統需要維護一個「最近 N 個話題」的共享記憶庫。一旦偵測到兩者對話語意開始重複，就必須強制注入新的話題種子來轉換話題。
- 聊天室打斷（混合模式）：平常兩個 AI 的「自走對話」在背景持續運行；當系統偵測到有觀眾留言時，會暫停自走對話，優先指派其中一個角色來回應留言，回應完畢後再恢復原本的對話流。
這也是為什麼我們需要將原本規劃在後期的「自寫排程/編排層」提早拉到第一線進行開發——因為目前市面上沒有現成的開源方案，這是本專案自研量最大、最核心的部分。
4. 延伸閱讀與相關資源
若想了解更多關於此架構的技術細節，可以參考以下整理好的主題筆記：
- 全貌入門：AI-VTuber 是什麼-白話入門
- 記憶與主動發話：AI VTuber 的記憶與自主性設計
- 聲線/臉/推流接線：GPT-SoVITS 與 Live2D 接線安裝指南
- 延遲優化：直播延遲優化方案
- 方針 3 知識型路線參考：企業客服 RAG 原理與製作
小結
透過這次的硬體實測，我們確認了即便是中階顯卡（1660 6GB），在採用雲端 LLM 與 TTS 的架構下，也完全足以應付雙 AI VTuber 的運作。這讓我們能把所有的開發專注力，放在最核心的「編排層（Orchestration Layer）」設計上。
接下來，我們將正式進入「階段 A」的雙 AI 對話邏輯驗證。如果你也對打造自主對話的 AI 角色感興趣，不妨依照本篇的兩階段步驟，一起動手試試看吧！