用一台舊世代的 GTX 1660（6GB VRAM）個人電腦，有沒有可能從零打造出一群類似 Neuro-sama 的 2D AI VTuber，並在 YouTube 上進行 24/7 的直播？更重要的是，能不能把每月的營運成本壓在極低的 10 到 60 美元之間？
這篇專案複盤記錄了我作為獨立開發者，在技術選型、成本工程、原型實作到上線驗證規劃的完整過程。我們將深入探討在「本地硬體與雲端 API 取捨」、「現成開源框架選型」以及如何打造「擬自主行為」等關鍵決策上的實戰經驗。
如果你也對低成本構建 AI 角色感興趣，希望這篇複盤能為你提供一些實質的啟發。
專案成果與現況
在硬體資源極度受限的情況下，本專案目前已完成了第一階段的技術驗證，具體成果如下：
- 單角色全鏈路打通：成功實現了「輸入文字 → LLM 推理 → TTS 語音合成 → Live2D 唇形同步（Lip-sync）」的完整流程，單一角色已能流暢運行。
- 延遲優化路徑清晰：針對直播端實測高達 28 秒的延遲問題，我已經拆解並規劃出將延遲降至 4 至 5 秒的具體優化方案（詳細分析可參考 直播延遲優化方案）。
- 硬體天花板下的成本平衡：在 GTX 1660 顯示卡的限制下，摸索出「LLM 走雲端 API、TTS 走本地運行」的混合架構，成功將預估的月營運成本鎖定在 USD 10-60 的區間。
目前，雖然聲線克隆功能因硬體 FP16 效能與 VRAM 限制暫時擱置，但第一階段的唇形同步與基礎互動鏈路已完全跑通。專案正處於「單角色可運行、待擴展多角色與上線驗證」的階段。
關鍵技術決策：硬體天花板下的成本工程
本專案的核心定位是「先低成本驗證可行性，成功後再轉為正式經營」。在預算極其有限的前提下，如何妥協與取捨技術架構是最大的挑戰。
1. 混合架構：LLM 走 API + TTS 走本地
開發機配備的 GTX 1660（6GB VRAM，且無 Tensor Core）根本無法流暢運行參數規模足夠聰明的本地大語言模型。因此，我採取了「哪個環節省、哪個環節租」的成本工程策略：
- LLM（大語言模型）：託管給外部 API（例如透過 OpenRouter 呼叫適合的輕量模型），確保角色足夠聰明，且不佔用本地 VRAM。
- TTS（語音合成）：將 GPT-SoVITS 等語音合成引擎部署在本地執行，以此省去昂貴的語音 API 費用。
2. 站在巨人的肩膀上，不重造輪子
市面上已有如 AIRI、Open-LLM-VTuber 等開源專案，它們已經把 LLM + TTS + Live2D + 推流等基本功能串接完畢。起步階段的最佳解是直接採用這些現成框架，快速搭建原型，並把珍貴的開發精力留給「24/7 推流自動化」與「多角色編排」等目前市面上沒有現成解決方案的痛點上。
3. 聲線克隆暫時冷凍
受限於 GTX 1660 的硬體極限，進行高品質的即時聲線克隆（Voice Cloning）在 VRAM 與運算速度上都面臨瓶頸。為了確保整條互動鏈路的流暢度，此功能在第一階段先予以擱置，優先確保 Live2D 唇形同步的穩定性。
4. 變現與經營面的現實
在技術之外，我們也必須務實面對平台門檻。YouTube 開通營利功能需要達到一定的訂閱數與觀看時數，這意味著在技術驗證成功後，如何度過前期的流量累積期，是經營層面必須先做好的心理準備。
讓 AI VTuber「像活的」三大技術支柱
許多人會好奇，AI 到底要怎麼展現出個性？務實地說，目前的 LLM 並沒有真正的意識，所謂的「像活的」，其實是透過以下三項工程設計所堆疊出來的「工程錯覺」：
1. 長期記憶（Long-term Memory）
陽春的原型（Prototype）通常只有 Context Window 的短期記憶，一旦程式重啟，AI 就會忘記之前與觀眾的互動。要建立長期記憶，技術上由淺入深可分為四個層次：
事實清單（Fact List） → 滾動摘要（Rolling Summary） → 向量資料庫（Vector DB RAG） → 知識圖譜（Knowledge Graph）
在專案起步階段，使用「事實清單 + 滾動摘要」的純文字檔案做法就完全夠用，不僅實作簡單，而且還是「零成本」。
2. 主動迴圈（擬自主行為 / Active Loop）
如果 AI VTuber 只是被動地等待觀眾打字才回應，看起來就會像一個精緻的客服機器人。為此，我們需要引入一個「排程器（Scheduler）」。當直播間一段時間沒人發言時，系統會自動戳一下 LLM 並發送 Prompt：「你現在想說點什麼？」。這樣一來，AI 就能主動開創話題、分享近況，甚至回應先前的彈幕，這是提升角色靈活度 CP 值最高的一步。
3. 人格一致性（Personality Consistency）
透過精心設計的 System Prompt（系統提示詞）與長期記憶機制，約束角色的說話口吻、常用語與情緒反應，避免在長時間的對話中出現角色設定漂移（Character Drift）的問題。
行業觀察：在目前的技術水平下，讓 AI VTuber 自動玩遊戲（例如需要視覺模型 VLM 讀取畫面）在技術上不僅又貴又慢。因此，業界許多商用案例其實採用「半自動」模式——由真人負責操作遊戲與基本控制，而 AI 專注於即時彈幕互動與配音。
起步的三個階段
本專案的實作規劃分為三個階段循序漸進：
- 單角色跑通（完成）：打字 → LLM → TTS 出聲 → Live2D 唇形同步整條鏈路順暢運行。
- 上線短時段驗證（進行中）：將系統推流至 YouTube 進行短時間的直播，實測觀眾互動與系統穩定度。
- 擴展多角色生態（未來規劃）：進行多角色編排，讓多個 AI 角色能在同一個直播間互相對話、吐槽。這部分目前市場上幾乎沒有現成的開源方案，將是後續研發的重點。
小結
透過這次的專案複盤，我們證實了即使在 GTX 1660 這類低配硬體下，透過「LLM API + 本地 TTS」的混合架構，依然能以極低的預算成本（每月 10-60 美元）搭建出具備互動能力的 AI VTuber 原型。而要讓角色真正「活過來」，關鍵並不在於堆砌昂貴的硬體，而是在於如何巧妙地設計主動迴圈、長期記憶與維持人格一致性。
接下來，專案將朝向多角色編排與直播延遲優化邁進。如果你對相關的技術細節感興趣，歡迎閱讀以下延伸筆記：
- AI-VTuber-MOC — 本主題完整索引
- AI-VTuber 是什麼-白話入門 — 從零理解組成零件
- AI VTuber 的記憶與自主性設計 — 記憶四層與主動迴圈的深入版
- GPT-SoVITS 與 Live2D 接線安裝指南 — 升級到會動的臉 + 可推流
- 專案複盤-MOC