雙AI雜談台：讓兩個AI角色輪流講話，不同時開口也不繞圈子
這篇解決什麼問題：讓兩個AI角色在直播裡輪流講話，不會同時開口，不會兩人一直繞著同一個話題打轉，觀眾在聊天室打字時還能插得進去。難的是「誰什麼時候可以說話」這件事。
適合誰讀：已經有一個AI角色能講話、想擴成兩個角色互動直播的人。看得懂「排隊」與「鎖」這兩個概念就夠，不需要額外的深度學習知識。
讀完能做到什麼：能設計出一套讓兩個角色輪流發言、可被留言打斷的調度規則，並判斷自己手上那台電腦跑不跑得動。
這是010-AI-VTuber專案在2026-06-10拍板的第一個驗證目標：兩名AI角色互相對話，同時可被聊天室留言打斷的雜談台，走的是最像Neuro-sama的娛樂路線。互動模式是混合式，留言優先，冷場時自己接話；節奏抓短時段定時，一到兩小時。背景知識可以先看AI-VTuber 是什麼-白話入門。
1660 6GB顯卡跑得動雙AI，因為深度學習模型全丟給雲端
LLM丟給雲端OpenRouter、TTS用edge-tts雲端服務，本機完全不用扛深度學習模型，唯一多出來的負擔是多開一個Live2D角色的渲染，而2D渲染本來就很輕。
雙角色連續跑十分鐘，GPU使用率峰值41%,VRAM峰值2799 MiB，這台顯卡總共只有6144 MiB，用不到一半。
技術細節：事前推估與事後實測差多少
事前（2026-06-10，只開一個VTS時）實測：6144MiB中已用約2.1GB、剩約3.8GB、GPU 29%。據此推估雙VTS加OBS大概要3.5到4GB，理由是第二個VTS實例只多0.5到1GB、桌面基底共用。 事後（2026-06-12）雙VTS實跑十分鐘：GPU峰值41%、VRAM峰值2799 MiB，比推估還低。推估偏保守的原因是把第二個Live2D渲染的成本抓太高，2D渲染其實很輕。
真正的風險不在硬體，在編排層這個純軟體問題，也就是怎麼安排兩個角色講話的順序。
三個待解問題，只有編排層沒有現成答案
雙AI要上線，有三件事要處理。前兩件是體力活，第三件才是硬仗。
VTS（VTube Studio）一個實例只能對應一個模型，兩個角色就要開兩個VTS實例，難度低。聲音也要分流：現在只有一條VB-CABLE虛擬音訊線，兩個角色要各自對嘴，就得加一條，方案是VB-CABLE A+B或Voicemeeter，難度中等。
真正卡人的是編排層：怎麼讓兩個AI輪流講、不同時出聲、不繞著同一個話題打轉，還能被聊天室留言打斷。這件事沒有現成方案可以抄，得自己設計調度規則。
先驗證對話好不好看，再花時間接硬體
雙AI的風險拆成兩階段驗證，先解決最貴的問題，硬體留到後面。
階段A完全不碰VTS和音訊線，只驗證兩個AI對話好不好看。要做的事包括：寫一個和第一隻角色個性有反差的第二個角色設定檔；設計輪流發話的調度邏輯，決定誰先講、輪次怎麼推進、把對方上一句話餵進自己的對話情境；用兩種不同的edge-tts聲線做零成本的角色區分；加一把佇列鎖避免兩張嘴同時講話；維護一份共享的最近話題記憶，偵測到重複就強制換題；讓聊天室留言可以打斷自走對話並優先回應。全部做完只用一個喇叭聽完整對話，驗證概念是否成立。
階段A通過後才進階段B，開始動硬體：開兩個VTS實例、加第二條虛擬音訊線讓聲音只驅動自己的嘴、把主程式從單一全域音訊裝置改成每角色路由到不同裝置、在OBS排出雙視窗同框畫面並實測推流穩定性、監看1660顯卡的實際VRAM與GPU使用率確認不掉幀。
靠回合制與佇列鎖，讓兩個角色像真的在對話
雙AI要組成一個看起來像真的在對話的迴路。調度用回合制：A講完，把A的話當輸入餵給B,B回完再餵回A，這樣輪流推進對話。出聲互斥是關鍵，靠一個全域的說話佇列鎖確保同一時間只有一個角色在出聲，講完才換手，否則兩條TTS的聲音會疊在一起。
防止兩人繞著同一個話題打轉，靠維護一份最近N個話題的共享記憶，一旦偵測到語意重複就強制換題，也可以定時注入新的話題種子。聊天室打斷走混合模式：自走對話平常跑在背景，一旦偵測到觀眾留言，就暫停自走、優先讓某個角色回應留言，回完再接續原本的話題。
flowchart TD 留言判斷{有觀眾留言嗎} 留言判斷 -- 有 --> 暫停自走對話 暫停自走對話 --> 優先回應留言 優先回應留言 --> 佇列鎖釋放 留言判斷 -- 沒有 --> A角色發話 A角色發話 --> 佇列鎖鎖定 佇列鎖鎖定 --> 餵入B角色情境 餵入B角色情境 --> B角色發話 B角色發話 --> 偵測話題重複 偵測話題重複 -- 重複 --> 注入新話題種子 偵測話題重複 -- 不重複 --> 佇列鎖釋放 注入新話題種子 --> 佇列鎖釋放 佇列鎖釋放 --> 留言判斷
這整套編排層，是專案原本規劃在第三階段才要做的自寫排程，被提前拉到第一線，因為沒有現成方案可以套用，是整個專案裡自研比重最高的一塊。
接話延遲壓到零，雙視窗同框推流長測通過
兩個角色各有一張自己的臉、各走一條自己的聲音線，兩張嘴各自對嘴不會一起動；接話之間的空白壓到零秒；語調有情緒起伏；觀眾留言可以打斷對話；問到產品問題還會自動去翻資料庫再回答。
06-09打通單角色的核心迴路，06-12雙臉雙線接上，06-13收尾。做法細節，包含接話延遲怎麼壓到零、情緒通道怎麼做，寫在雙AI上臉實戰：雙音訊線、語音預生成與情緒通道。
剩下的問題是角色性格，寫程式解決不了
兩個角色目前只是實驗用的占位人設，要定稿成什麼樣的個性還沒決定。這件事沒辦法靠寫程式解決。
相關筆記
- 全貌入門：AI-VTuber 是什麼-白話入門
- 記憶與主動發話：AI VTuber 的記憶與自主性設計
- 聲線／臉／推流接線：GPT-SoVITS 與 Live2D 接線安裝指南
- 延遲優化：直播延遲優化方案
- 另一條路線（知識型）：企業客服 RAG 原理與製作