by Rain Chu | 9 月 25, 2026 | Agent, AI, 模型
Laya 提供了可以在本機執行的開源決策模型,但目前還不足以支持「直接取代 Jev」,在相同的垃圾簡訊與銀行客服分類樣本上,Jev 的準確率較高,Laya 則在 Apple M3 上呈現較短的實際等待時間。
Laya 是什麼?把語意轉成程式可用的判斷
Laya 接收文字或結構化狀態,再依你定義的問題回傳選項、分數或機率。它採用非自回歸架構,經由編碼器理解輸入,再由決策頭評估候選答案,省去逐字生成回答與解析自由文字的步驟。
可以用一張客服單理解三種題型:
choice 判斷要分給帳務、技術還是業務,score 依事先描述的等級評估急迫性,noul 回傳「客人是否明確要求退款」這類命題成立的機率。
這與 TypeSafe 的 System One 設計有相近的工作分工,需要分類、分流與檢查時使用決策模型,需要撰寫回覆時再接生成模型,想先了解實際如何串接,可以參考 Jev 的五個工作流場景。
Laya 英文模型卡列出的基礎版本採用 ModernBERT-large,總參數量約 4.21 億,權重採 Apache 2.0 授權。
另有多語言與 typed-decisions 等 checkpoint。這次受測的是英文基礎版,沒有為這兩份評測資料另外微調,不能把其他版本的分數直接套過來。
Laya 的 開源專案也提供相容 Jev 請求形狀的介面,能降低改接服務的工作量。
這次比較怎麼做?先把版本與條件固定
依 公開評測紀錄,Laya 測試日期為 2026 年 9 月 23 日,使用 Laya 0.3.11、英文 convaiinnovations/laya checkpoint,以及 Apple M3 的 MPS 加速。Jev 沿用 9 月 20 日透過 OpenRouter 取得的 jev-1.13 原始回答,兩者並非同一時間重新呼叫。
- SMS Spam:200 則英文簡訊,其中 27 則垃圾訊息、173 則正常訊息。
- Banking77:462 則英文銀行客服訊息,77 個意圖各取 6 則。
- 兩邊使用相同的樣本 ID、輸入狀態、正確答案與題目設定,再由同一份評分程式計算結果。
- Laya 在本機逐筆執行,Jev 走雲端服務。延遲反映這兩條實際執行路徑,並非相同硬體下的模型速度測試。
核對資料時,官網已列出 0.3.20 的更新內容,下文數字應視為 0.3.11 英文基礎版的固定評測,不是對所有新版本、所有語言或微調模型的總排名。
範例一:垃圾簡訊二分類,84% 準確率該怎麼看?
這個任務只問一件事:簡訊是不是垃圾訊息。評分程式把 noul 大於或等於 0.5 的回答判成垃圾訊息,再與資料標籤比較。Jev 答對 193 則,Laya 答對 168 則。
| 任務 | 模型 | 答對 / 樣本 | 準確率 | Macro F1 |
|---|
| SMS Spam | Jev | 193 / 200 | 96.5% | 0.926 |
| SMS Spam | Laya | 168 / 200 | 84.0% | 0.759 |
| Banking77 | Jev | 377 / 462 | 81.6% | 0.806 |
| Banking77 | Laya | 183 / 462 | 39.6% | 0.346 |
資料:01Coder 公開評測,Laya 0.3.11 英文基礎版。本文已由原始回答重新核算答對筆數與 Macro F1。
這裡不能只盯著 84%。因為正常簡訊佔 173 / 200,若把全部訊息都判成正常,準確率也有 86.5%。這是依樣本比例計算的簡單基準,說明類別不平衡時,整體準確率可能掩蓋模型對少數類別的處理能力。
原始錯誤也不是完全重疊:29 則只有 Jev 答對,4 則只有 Laya 答對,另外 3 則兩者都錯。這顯示 Jev 在這份樣本上整體較好,但仍有值得回頭檢查的個別案例,不能把任何一方當成永遠正確的裁判。
範例二:Banking77 的 77 選 1,差距為什麼變大?
Banking77 資料集把銀行客服需求拆成 77 個意圖。這組測試的任務,是從所有候選意圖裡直接選出一個。Jev 答對 377 / 462,Laya 答對 183 / 462,Macro F1 也從 Jev 的 0.806 降到 Laya 的 0.346。
候選答案多,不只增加選擇難度,也會消耗描述選項的空間。依官方目前的限制說明,英文 Laya 的選項提示預算 head_max_len 預設為 192 tokens,所有選項必須共享這段空間。當相近的分類名稱與描述被裁短,模型可能失去區分它們的重要文字。
官方提醒,有簡短描述的選項增加到大約 20 個後,就應留意預算與裁切。20 不是所有請求通用的硬性上限,實際影響取決於指令、標籤長度與 checkpoint。77 選 1 已超出建議的使用範圍,因此這個結果同時反映任務難度與目前設定的限制。
分成兩層分類,是可以驗證的改法
一種改法是先把候選答案縮到幾個大類,再在選中的大類裡做細分。以概念示例來說,先分出「卡片」「轉帳」「現金提領」「帳戶」,再於卡片類別中辨認啟用、遺失或付款問題。這樣每一步需要容納的描述較少。
這個策略值得測試,但本文引用的 77 選 1 成績不是兩階段分類的成績。第二層也會受到第一層錯誤影響,所以要評估完整流程的最終分類準確率、兩次呼叫的總延遲,以及無法判斷時的回退方式。不能只拿第一層大類的分數宣稱問題已解決。
Laya 比較快嗎?先分清楚本機等待時間與模型速度
| 任務 | Jev p50 | Laya p50 | Jev p95 | Laya p95 |
|---|
| SMS Spam | 447 ms | 50 ms | 922 ms | 66 ms |
| Banking77 | 432 ms | 294 ms | 658 ms | 354 ms |
同一公開評測的觀察值,單位為毫秒。Jev 經網路呼叫,Laya 在 Apple M3 本機 MPS 執行,不能當成純模型速度比。
p50 是中位數,p95 反映較慢端的等待情況。在這台電腦與這批請求上,Laya 的兩項數值都較低,但差距會隨任務改變。垃圾簡訊的 p50 為 50 毫秒,77 類銀行意圖則上升到 294 毫秒,說明「一次前向運算」不代表任何問題都花相同時間。
更精確地說,銀行客服的原始請求同時包含 77 類 intent 與 10 類 group 兩個獨立問題,所以表中的延遲是整次請求的耗時。這與先取得大類、再縮小選項進行第二次呼叫的分層分類不同,兩者不能混為一談。
這些數字也不能涵蓋首次下載與模型載入。常駐服務可以攤平啟動成本,偶爾才執行一次的工具則可能更在意冷啟動。重新測試時,應把啟動、單筆延遲、批次吞吐量與尖峰等待分開記錄。
本機執行能減少推論時把輸入交給外部服務的需要,但「沒有逐次 API 費用」仍要加上硬體、電力與維護成本。若系統還會使用雲端備援或外部工具,資料流向也要一起看,這與 本機 AI 與雲端分流的取捨有直接關係。
信心值與微調,不能省略的兩個驗收環節
信心值很高,只能描述模型如何分配機率,不能直接當成答案正確的保證。公開評測特別記錄,0.3.11 在 11 個以上選項時會限制溫度,回傳的信心值也未完成相應校準,因此這次沒有拿 77 類任務做可直接比較的信心門檻結論。
如果原本 Jev 設定某個門檻就自動處理,換成 Laya 時不能只保留相同數字。應用自己的已標註資料檢查:門檻提高後,剩下多少案件能自動處理,其中又有多少判錯。選擇門檻的依據,應是可接受的錯誤與覆蓋率。
另一方面,基礎 checkpoint 能直接接受新題目,不等於在任何領域都已經可靠。Laya 官方同時提供微調方向,且承認基礎版在部分工作流測試中表現有限。用自己的領域資料訓練,可能改善結果,但必須留出沒有參與訓練的測試資料。
微調、蒸餾與量化處理的是不同問題。如果要用較強模型產生教學訊號來訓練小模型,可以延伸閱讀 模型蒸餾與本地部署的差異。不能只因為模型變小、能在本機跑,就推論判斷能力等同原服務。
想試 Laya,先從一個可驗收的任務開始
- 先選標準清楚、選項不多的任務,例如把客服單分到幾個部門,並保留其他或資訊不足的處理方式。
- 建立代表真實需求的標註集,涵蓋常見、少見與容易混淆的案例。同時比較簡單規則、Laya 與目前採用的服務。
- 記錄 checkpoint、套件版本、題目文字、選項描述、裝置與推論設定,讓數字可以重現。
- 先找出錯誤集中在哪些分類,再判斷要改題目、縮短選項、分層分類或微調。一次改一個主要因素。
- 把正確率、各類別表現、誤判成本與整條流程的延遲一起驗收,再決定哪些判斷可以自動處理。
如果要重現這次比較,可從 完整評測目錄取得樣本、題目、原始回答與評分程式。只想核對現有數字時,先讀保存的 runs 與 reports 即可。要重跑模型,再依 LAYA.md 的鎖定環境操作,並確認是否沿用了舊結果檔,避免把跳過已完成項目的續跑誤認為新的全量測試。
Laya 與 Jev 常見問題
Laya 可以直接取代 Jev 嗎?
介面相容有助於改接,但不能保證判斷品質相同。在這次 662 筆英文樣本中,Jev 的準確率較高,Laya 的本機延遲較低,是否替換仍需用自己的任務驗收。
Laya 一定要微調才能使用嗎?
基礎 checkpoint 可以直接接受新題目,但可執行不代表準確度足夠。先測原始模型,若錯誤超出需求,再評估題目設計、分層分類或領域微調。
Laya 最多只能選 20 個類別嗎?
約 20 個是官方對預設選項預算的實務提醒,不是固定上限。指令和標籤長度都會影響裁切,候選類別很多時,應檢查預算並測試縮小候選集合的方法。
這次測試能代表 Laya 的中文能力嗎?
不能。受測的是英文基礎 checkpoint 與兩份英文資料集。中文工作應選適合的 checkpoint,另用中文標註資料驗證,不能沿用這裡的準確率。
選擇的依據,是你的任務能不能通過驗收
這次結果支持一個務實的起點:把 Laya 當成可自行部署、值得針對固定任務調整的決策元件。需要大量細分類、又希望直接使用預設設定時,這份測試裡 Jev 的表現較好。先挑一個明確任務做完整驗收,再決定是否替換或混合使用,會比只看「開源平替」四個字更有幫助。
by Rain Chu | 9 月 25, 2026 | AI, claude, 程式開發
Claude Opus 5.5 值得關注的地方,是把需求轉成可操作作品的能力。
同樣交給 AI 一段描述,成果可以是動畫、原生 App、可走進去的 3D 房屋,也可以是帶有武器切換與戰鬥互動的遊戲。真正要問的,是這些作品做到哪裡,以及哪些地方仍需要人檢查。
這次整理把公開案例分成動畫、應用程式、空間、遊戲、介面與機械六個方向。
Opus 5.5、Claude Code、Claude Design,分別負責什麼?
Anthropic 於 2026 年 9 月 22 日推出 Claude Opus 5.5,官方 Claude Code 文件說明了這些操作能力,單純在聊天視窗請模型寫一段程式,與讓它在完整專案裡編譯、測試,是不同的工作方式。
Claude Design則偏向視覺設計與互動原型,它適合探索頁面、版型和設計方向,但畫面上的按鈕可以切換,不代表會員、金流、資料庫與部署已經接好。選工具前,先決定要的是設計提案、可執行專案,還是正式服務。
動畫案例:蝴蝶、水墨與中子星,要分別驗收
蝴蝶生命週期:連續動作比單張漂亮畫面更重要
蝴蝶案例串起卵、幼蟲吃葉成長、結蛹、羽化與展翅飛行,成蝶剛離開蛹時,翅膀仍處於折疊狀態,之後才逐步展開,這種任務同時考驗形態變化與時間節奏,不能只看某一幀像不像蝴蝶,若用於教學,還要檢查各階段的順序與說明是否正確。
需求可以寫成「每個階段停留到足以辨認,再進入下一段,提供暫停與重播」。這比只要求畫面華麗更容易驗收,也能讓模型把時間軸與互動控制一起規劃。
國風水墨:觀察暈染與轉場是否連續
水墨案例在 Claude Design 中完成,從墨色在宣紙上暈染開始,接著帶出層疊山脈、日輪、飛鳥、水面與小船,再轉到荷葉荷花、梅樹,最後以多色墨跡旋轉交織收尾。它把抽象風格落到連續的動態規則,包含擴散速度、留白、筆觸密度與前後景層次。
要延伸成品牌片或教學動畫,可以先做一小段品質樣本,再擴充完整分鏡。站上的Claude Code 與 Remotion 動畫工作流提供了分鏡、工具分工與逐幀檢查的方法,適合把一次展示整理成可重複修改的製作流程。
中子星:視覺化與物理模擬是兩種交付
另中子星動畫展示,透過自動播放與不同角度呈現天文題材。這段口述的模型名稱與全片主題不完全一致,因此本文只把它當成視覺化題材示例,不作單獨的版本比較依據。若要作為科學教材,還須說清楚哪些是示意,哪些參數有資料依據,畫面有說服力並不會自動證明物理模型正確。
原生 App:macOS 音樂播放器與 iOS 背單字工具
macOS 音樂播放器:介面之外,播放流程才是重點
音樂播放器案例採取接近 Apple Music 的介面方向,在 Xcode 開啟專案後執行,展示匯入音樂、播放、暫停與調整音量,也能建立播放清單、瀏覽歌曲、專輯與歌手,並叫出迷你播放器。這讓驗收從靜態畫面進一步走到檔案與媒體操作。
如果要延伸成日常使用的工具,我會再檢查取消匯入、無法辨識的檔案、重複歌曲、播放進度與重新啟動後的資料保留。這些都是下一步的驗收項目,不能因為正常播放一次,就推定全部都已完成。
3D 房屋:從平面圖走進空間,也要檢查還原程度
把一張平面圖轉成能探索的三維房屋,是這組案例很直觀的亮點。操作包含切換一樓與二樓俯視圖,再進入屋內探索客廳、臥室、廚房、洗手間與書房。門會在靠近與離開時自動開關,也能沿樓梯上樓,從臥室走到陽台。
我會把驗收拆成兩部分。第一部分是空間對應,房間的位置、連通關係與樓層是否符合原圖。第二部分是互動,能不能正常進出、是否穿牆、樓梯是否可走。建模結果適合空間溝通或概念展示,不能直接視為具有尺寸與結構驗證的施工模型。
Claude Design:鍵盤詳情頁與宇宙探索 App 原型
鍵盤詳情頁:漂亮版型要能支持產品資訊
鍵盤產品頁展示不同視覺方向,包含深色主題,用產品圖像、留白與版面安排呈現較俐落的風格。若要從設計展示變成電商頁,還要確認規格、選項、價格與購買路徑,並測試手機版是否仍容易操作。
可以搭配Claude Code 網站製作工作流,把設計方向、元件、動效與正式網站需求分開規劃,減少外觀已完成、功能仍空白的落差。
宇宙探索 App:探索體驗與內容可信度分開檢查
宇宙探索原型提供不同風格,能切換探索、太陽系與星空等頁面,拖曳查看行星,打開木星、地球等天體詳情,並比較行星大小。它展示了導覽與資訊卡片如何串接,但天體數據、比例與描述仍需另行核對,不能把可點擊的原型當成已驗證的天文資料庫。
Claude Opus 5.5 價格:單價降低,不代表每個任務固定省多少
依官方 Opus 價格資訊,標準 API 單價如下。這是按 tokens 計費的價格,不是 Claude 訂閱月費。
| 每百萬 tokens,美元 | Opus 5 | Opus 5.5 |
|---|
| 輸入 | 5.00 | 4.00 |
| 輸出 | 25.00 | 20.00 |
| 快取讀取 | 0.50 | 0.20 |
2026 年 9 月 23 日核對的標準 API 單價,不含 Fast mode 或其他服務費用。
任務總成本還取決於輸入量、輸出量、快取命中、重試次數與工具使用。官方對典型工作負載的節省估計,不能直接套用成每個專案的保證。想比較模型,最好給相同需求與驗收條件,同時記錄費用和修改次數。
把案例用到自己的專案:先做一條完整流程
在 Claude Code 中,可依官方模型設定說明指定 claude-opus-5-5。帳號可用性與額度仍以實際介面為準,不要只憑模型自稱的版本判斷是否切換成功。
如果要開始嘗試,可以先選一個範圍小、結果清楚的任務。播放器先完成匯入與播放,單字 App 先完成一輪學習與保存,3D 房屋先完成一個房間與一扇門。把這條流程做對,再增加視覺細節與次要功能。
開工前可先用需求訪談的方式釐清使用者、裝置、資料來源與驗收標準。不要只交付「做得漂亮」,而要列出哪些操作必須成功,以及失敗時應該發生什麼。
專案開始修改前也要留好版本。依Vibe Coding 版本管理方法分階段保存,出現問題才有辦法知道改了哪裡、回到哪一版。模型變強,並不會讓版本管理與驗收失去必要性。
想延伸研究,可從作者的公開 GitHub 專案入口查找相關工具,但不能據此假定本次所有展示都有提供原始碼。重現案例前,應先確認有沒有完整專案、依賴與執行方式。
Claude Opus 5.5 常見問題
Claude Opus 5.5 可以直接做出可上架 App 嗎?
它能協助產生與修改原生 App 專案,但可執行原型和正式上架不同。仍需檢查功能、資料保存、權限、簽署與發行流程。
Claude Code 和 Claude Design 要怎麼選?
要編輯專案、執行工具與測試,可使用 Claude Code。要探索視覺方向和互動原型,可使用 Claude Design。兩者都需要清楚的需求與驗收標準。
Opus 5.5 API 多少錢?
標準 API 每百萬 tokens 的輸入為 4 美元、輸出為 20 美元、快取讀取為 0.20 美元。訂閱方案、Fast mode 與其他服務費用另計。
Opus 5.5 的知識更新到什麼時候?
官方支援文件列出訓練資料截至 2026 年 6 月。即時問題仍應透過可靠來源查證,不能只相信模型自述。
by Rain Chu | 9 月 21, 2026 | AI, TTS, 圖型處理, 影片製作, 模型, 虛擬人, 語音合成, 語音辨識
AI 女友本地部署,可以做成真正接得上話的語音數位人:當麥克風收音後,由語音辨識轉成文字,Qwen3 產生回答,Qwen3-TTS 合成聲音,再交給 LiveTalking 生成嘴型畫面。角色的回答隨當下對話產生,不只是播放固定台詞。
最實用的起步方式,是先把「聽得懂、答得出、播得出聲音」跑通,再加入人物形象。
這套系統有好幾個服務,任何一層沒啟動,都可能看起來像整個網頁壞掉。
先看懂整套流程:聊天模型只是其中一站
語音互動可拆成五個環節:VAD 判斷你是否正在說話,faster-whisper 辨識語音,Qwen3 組織回覆,Qwen3-TTS 產生音訊,LiveTalking 把音訊轉成嘴型並傳回瀏覽器,畫面與對話分工之後,才有辦法逐層測試。
Hugging Face speech-to-speech採用可替換元件的語音流程,語言模型可以接自己的 llama.cpp 服務,初次接觸這類架構,可以先看本地即時語音 Agent 的元件分工,再加上數位人畫面。
「免 API 費」比較精確的意思,是不必向雲端模型服務支付推理費,程式之間仍可能透過本機 API 溝通,電腦硬體、用電與安裝時間也不會因此消失。
8GB 顯卡能跑嗎?先算所有常駐元件
只看 Qwen3 能不能載入,會低估整套系統的需求。語音辨識、語音合成、嘴型模型、上下文快取與桌面顯示,都可能一起使用顯示記憶體。素材生成階段的 ComfyUI 也有自己的負載,完成底片後應釋放它的資源,再測常駐對話服務。
下表採用作者教學頁列出的 RTX 4090 配置估算,方便理解資源分配。這些近似值不是本文實測,也不是官方最低需求。
| 元件 | 範例配置 | 約用顯示記憶體 |
|---|
| 語言模型 | Qwen3-14B Q4_K_M | 9GB |
| 語音辨識 | faster-whisper large-v3 | 3GB |
| 語音合成 | Qwen3-TTS 1.7B | 4GB |
| 嘴型同步 | wav2lip256 | 1.3GB |
作者配置的近似值,僅供理解各元件負載,不能視為最低硬體門檻。
因此,不能把這份完整配置原封不動套到 8GB 顯卡,容量有限時,先選較小的量化 Qwen3、縮短上下文,再評估語音辨識模型與運算位置,faster-whisper 官方效能資料也顯示,精度與批次設定都會改變記憶體需求,光是模型名稱一樣,佔用量仍可能不同。
步驟一:準備 WSL,先確認 GPU 與資料夾
以下以 Windows 搭配 NVIDIA 顯卡及 WSL 2 為主。先安裝 Windows 端的 NVIDIA 驅動,再安裝、更新 WSL,NVIDIA 官方文件明確說明,WSL 使用 Windows 驅動映射的 CUDA 支援,不要在 WSL 裡另外安裝 Linux 顯示驅動。
Windows PowerShell 的起步指令如下,若已有 Ubuntu,不必重複安裝。
依畫面要求完成重啟與帳號設定後,在 Ubuntu 執行 nvidia-smi 確認顯卡可見。
wsl --update
wsl --install -d Ubuntu-24.04
Python 環境、模型處理與執行檔案,建議放在 WSL 的 Linux 家目錄下,Microsoft 的檔案系統建議是讓 Linux 工具優先使用 Linux 檔案系統,可減少跨系統讀寫負擔,環境基礎可參考Windows 與 WSL 的 AI 開發環境整理。
WSL 網路設定不是一個開關解決全部問題
Windows 11 22H2 以上可在使用者目錄的 .wslconfig 啟用 mirrored 網路,Microsoft 說明指出,這種模式支援 Windows 與 WSL 透過 127.0.0.1 互連。記憶體上限則應按實際機器調整,不要照抄別人的容量。
[wsl2]
networkingMode=mirrored
hostAddressLoopback=true 是額外允許透過主機其他 IPv4 位址互連的設定,只在 mirrored 模式下適用,官方設定文件並未說所有 WebRTC 失敗都必須靠它修復。改完設定後,可在保存其他 WSL 工作後執行 wsl --shutdown,再重新啟動環境。
步驟二:先讓 Qwen3 單獨回答文字
從 llama.cpp 官方專案選擇適合 Windows 與顯卡的版本,下載對應的 GGUF 模型,容量有限時,可先研究 Qwen3-4B 官方 GGUF,而不是直接載入較大的模型。檔名應以實際下載結果為準。
下面是啟動本機文字服務的設定範例,請把模型路徑換成自己的檔案。這組命令只用來說明參數,未在本文中進行 GPU 實測。
llama-server -m "C:\AI\models\your-qwen3-model.gguf" -ngl 99 -np 1 -c 4096 --host 127.0.0.1 --port 8090
先開啟 http://127.0.0.1:8090 測試文字回覆,再把語音服務的模型端點指向同一個位址與連接埠,llama-server 文件列有模型路徑、上下文與監聽位址參數,若使用 NAT 網路跨 Windows 與 WSL 連線,位址安排會不同,應按前一節的網路模式處理。
連接埠不是非 8090 不可。若無法綁定,先看錯誤與 Windows 保留區間,再選可用的埠,也不必為了單機測試直接監聽全部網卡,只有確實需要其他位址連入時,才調整監聽範圍與防火牆。
步驟三:接上語音辨識與 Qwen3-TTS
先用一句短句測試語音辨識,再讓 TTS 單獨唸出固定文字,兩者各自正常後,才把它們接到文字模型,這樣能分辨「沒聽見」「辨識錯」「模型沒回覆」與「音訊沒播出」是哪一段出問題。
若使用作者整合包,install-voice.sh、start-voice.sh 與後續的橋接檔案應維持同一版本,這些是教學包的客製腳本,並不是所有官方專案都有的通用指令,下載入口可由原作者部署教學取得,本文未執行或驗證該整合包。
自行安裝目前官方 speech-to-speech 時,要明確選定本機 LLM 端點與本地語音元件,單獨執行預設服務命令,不代表一定選到全本地配置,首次啟動還需要下載模型與完成載入,前端頁面能打開,不代表語音後端已準備好。
聲音復刻要選 Base,固定音色則看 CustomVoice
Qwen3-TTS 官方說明區分 Base、CustomVoice 與 VoiceDesign,想根據參考錄音復刻聲音,應使用支援 voice clone 的 Base 路徑,CustomVoice 提供預設說話者,不能把兩者的參數直接互換。
參考音訊使用自己錄製或有授權的聲音,保持單人、背景乾淨,並準備正確的逐字內容,
不要只把 MP3 副檔名改成 WAV,也不要假設所有模組都用同一取樣率,應在需要的交接點真正轉換格式。更多音色選擇可參考Qwen3-TTS 音色設計與聲音復刻。
步驟四:用 LiveTalking 驗證聲音與嘴型
LiveTalking 官方專案支援 Wav2Lip 等嘴型模型,並提供 WebRTC 輸出,先依目前 README 安裝相容環境與權重,使用官方範例形象測試。舊教學的 Python、PyTorch 版本可能和目前文件不同,不要任意混裝兩套依賴。
完成官方安裝與模型放置後,範例啟動命令如下。開啟 http://localhost:8010/index.html,建立連線後先測畫面,再測文字或音訊驅動。官方文件要求把對應權重放到指定目錄,檔名也要相符。
python app.py --transport webrtc --model wav2lip --avatar_id wav2lip256_avatar1
這一步的目標是確認嘴型服務本身能工作,範例能出聲音,不足以證明聲音是本地生成的。仍要核對選用的 TTS 後端,確保正式串接時收到的是前一層本地 TTS 的音訊。
步驟五:準備自己的形象,最後才做整合
人物底片使用嘴部清楚、沒有手遮擋、動作平穩的素材。可以自己錄製,也可先用 Wan2.2 等圖生影片工具製作一小段待機畫面。鏡頭固定、人物稍微呼吸或眨眼即可,避免原片持續大幅說話,讓後續嘴型替換更容易處理。
底片長度、解析度與幀率要配合生成模型及後續預處理,不能把某份模板的幀數與匯出設定,說成整個 Wan2.2 系列只能產生固定秒數,若模板有提示詞擴寫功能,先確認它是否改寫了你要保留的場景。
LiveTalking 提供 /avatar.html 形象建立頁面,可上傳影片並產生角色資料,完成後,用新形象的 ID 啟動服務,再確認嘴部邊緣、遮擋與音畫同步。底片是角色外觀素材,實際回話的嘴型仍依當下音訊產生。
完整整合需要橋接語音輸出與人物服務。作者教學包中的 avatar-sync.js 承擔這部分工作,因此不能只安裝兩個官方專案,就假設它們會自動連接。建議依序啟動文字模型、嘴型服務、語音服務,再開前端檢查每一層日誌。
讓對話更自然:回覆長度比華麗人設更有用
語音回答先控制在一兩個重點,避免長篇條列與會被唸出來的格式符號。以下是可自行調整的原創人設示例,重點是語氣與回覆形式,不需要要求角色否認自己是 AI。
你是一位名叫小晴的虛擬聊天夥伴。
使用自然的臺灣繁體中文口語,回覆以兩三句為主。
先回應對方剛說的內容,再視情況提出一個簡單問題。
不要使用 Markdown、編號或表情符號。
不知道的事情直接說不知道,不要虛構共同經歷。
支援思考切換的 Qwen3 模型可以用 /no_think 控制模式,但仍要依模型與聊天模板確認,若換成不同的 Instruct 版本,不能假設同一控制文字都有相同效果。
聲音很自然,回答就一定聽懂了嗎?
聊天時最容易混淆的是語氣與理解能力。角色能用自然音色談論喝奶茶、工作很累等日常話題,並不代表它穩定追蹤了誰在說話、誰與誰是什麼關係。多人輪流發言或連續追問身分時,回覆可能仍然流暢,內容卻已經接錯人或繞回固定話題。
驗收時應把「聲音像不像真人」與「答案有沒有回應問題」分開。用幾句意思相近但主詞不同的問題測試,再核對辨識文字。如果前一層把話聽錯,先修收音與轉錄。如果轉錄正確而回覆混亂,再調整對話歷史、角色規則或模型,不能只因為聲音很順就判定整套系統成功。
搶話、沒反應、WebSocket 失敗,分層排查
一直顯示「等待語音後端就緒」
先查看後端是否正在下載模型,或已經因套件、CUDA、磁碟空間而退出。檢查真正的錯誤訊息與下載進度,再決定是否重啟。只重整前端頁面,無法修復後端缺少權重的問題。
網頁打得開,但 WebSocket 連不上
官方瀏覽器示範文件區分前端頁面與語音後端。例如頁面可位於 7860,而語音連線使用另一個埠與 /v1/realtime 路徑。依實際版本核對位址、連接埠、路徑及協定,不能把前端網址直接當成 WebSocket 端點。
WebRTC 失敗則要看服務端、ICE 候選、網路模式與防火牆。
前端出現 JSON 解析錯誤,可能只是收到錯誤回應,不能僅憑這句話認定是某個 WSL 開關沒開。
麥克風有權限,卻完全沒有辨識結果
先確認選到正確輸入裝置與收音電平,再調整 noise gate 與 VAD 門檻。
門檻過高可能把正常說話擋掉,降得太低也可能讓環境聲觸發回應,瀏覽器麥克風規則要求安全環境,本機可用 localhost,其他裝置連入通常應使用 HTTPS。
還沒說完就被搶答,或聽起來像在等很久
先調整結束發言的靜音等待,再測辨識與合成速度。等待較長,較能容忍句中停頓,但回答也會更晚開始。這是輪流說話的取捨,不能單靠加大模型解決。使用耳機也能避免喇叭聲再次進入麥克風,造成誤觸發。
衡量延遲時,要從你停止說話算到真正聽見第一個字,包含等待、辨識、文字生成、音訊生成與播放緩衝。嘴型影片播放流暢,只代表畫面跟得上,不等於對話回覆沒有延遲。
離線與免費,最後要驗收哪些條件?
首次安裝與模型下載通常需要網路。若要斷網使用,先讓選定的全本地配置完整啟動一次,再檢查模型快取、前端資源、語音後端,以及是否仍依賴外部 STUN 或其他服務。外網通道與雲端語音服務也不能算成純離線方案。
原始 Wav2Lip 專案對其開源模型的商用有明確限制,不能因整合框架使用 Apache 授權,就推論整套權重都可任意商用。對外使用前,應核對實際下載模型的來源與授權。
第一個完成標準可以很簡單:連續問幾個新問題,辨識內容正確、回答有關聯、聲音完整、嘴型能跟上。這些都穩定後,再增加個性設定、外觀與更長的對話記憶。
常見問題
要復刻聲音,Qwen3-TTS 該用哪一版?
應使用支援參考音訊復刻的 Base 路徑。CustomVoice 提供預設音色,與聲音復刻的輸入方式不同。
為什麼 localhost 頁面能開,語音卻連不上?
前端頁面與語音後端可能使用不同連接埠。應先確認後端啟動完成,再核對 WebSocket 位址、路徑、協定與網路設定。
AI 女友本地部署後可以斷網聊天嗎?
選定的模型、依賴與前端資源都已備妥,而且語音、對話與串接服務不依賴雲端時,才可能離線使用。應先跑通完整配置,再做斷網測試。
by Rain Chu | 9 月 18, 2026 | AI, 模型
模型蒸餾,是用教師模型提供的學習訊號訓練學生模型,讓學生在指定任務上學會更好的判斷與回應。常見目標是把能力轉移到較容易部署的小模型,降低使用時的資源需求。它需要新的訓練過程,效果取決於教師、學生本身的能力,以及準備了什麼資料。
理解這件事,最有用的起點是分清楚兩種做法:讓學生學教師的機率分布,以及讓學生學教師產生的完整答案。這也能解釋為什麼同樣叫蒸餾,有的需要取得模型內部輸出,有的只靠生成文字就能進行。
模型蒸餾是什麼?教師提供訊號,學生更新參數
Hinton、Vinyals 與 Dean 的知識蒸餾論文提出用大型模型或模型集成的預測分布,訓練另一個容易部署的模型。學生學習的是教師在不同輸入下的行為,不必照抄教師的架構,也不是把教師權重直接截取一部分。
一般離線蒸餾會先準備好教師,再固定教師的參數,由學生反覆預測、計算差距、更新自己的參數。完成訓練後,學生可以獨立推論。若產品另外設計了雲端備援,那是部署流程的選擇,並非蒸餾必然要求。
軟標籤:除了正確答案,還學選項之間的關係
以辨識貓、狗與汽車為例,人工標籤可能只寫「貓」。教師除了選出貓,還會對其他類別給出機率。狗的可能性高於汽車,透露出這張照片在模型眼中更接近哪類事物。這種帶有相對關係的訊號,就是軟標籤的價值。這裡是概念示例,並非實測數據。
經典做法會調整 softmax 的溫度,讓機率分布更平滑,使原本很小的機率差異更容易參與學習。溫度過高也會讓分布過於平均,因此仍需驗證。它不是「溫度越高,學生就越聰明」的設定。
PyTorch 官方教學示範把兩種訓練目標加權:一種要求學生接近教師分布,另一種要求學生符合真實標籤。分布差距可透過 KL divergence 等目標衡量。訓練時仍應保留正確答案的約束,教師的自信不等於答案一定正確。
實作時,直接比對逐 Token 分布通常還需要處理詞彙表、Tokenizer 與序列位置的對齊。光是教師和學生都能生成中文,並不足以保證它們的機率陣列可以直接相減。
回答蒸餾:把教師輸出變成學生的訓練資料
另一條路徑是先讓教師回答問題,整理成「輸入與目標回答」的資料集,再用監督式微調訓練學生。學生逐步學習如何產生這些答案,不需要拿到教師的全部權重。若服務只提供文字輸出,也可能採用這種方式,前提是取得與使用資料的條件允許。
Sequence-Level Knowledge Distillation在機器翻譯研究中,探討把整段生成序列作為蒸餾訊號。放到語言模型的應用裡,資料可以包含回答格式、分類結果、解題步驟與工具使用範例,但具體要教什麼,仍由資料與訓練目標決定。
例如,希望學生整理客服工單,就應準備真實會遇到的問法,要求教師產生正確分類、摘要與缺漏欄位,再經規則或人工檢查。只收集漂亮、流暢的回答,未必能教會學生處理錯字、矛盾敘述與資訊不足。這是本文用來說明資料設計的應用示例。
DeepSeek-R1 的蒸餾模型,為什麼會叫 Qwen 或 Llama?
DeepSeek-R1 官方模型卡說明,Distill 系列以 Qwen 與 Llama 的既有模型為基礎,使用 DeepSeek-R1 生成的樣本進行微調。名稱同時反映了提供訓練訊號的來源,以及學生採用的基礎模型。
因此,DeepSeek-R1-Distill-Qwen 不是把完整 R1 的參數切小,也不能直接當成 R1 的量化版。挑選時應確認學生模型、適用任務、Tokenizer 設定與部署需求。官方基準測試能提供參考,但不能推論小模型在所有領域都等同教師。
蒸餾、微調、量化與剪枝,各自在改什麼?
微調著重於用資料更新既有模型。蒸餾著重於知識訊號來自教師,兩者可以同時成立。用教師生成的答案微調學生,就是常見的交集。LoRA則是透過低秩更新降低需要訓練的參數量,是微調方法之一,本身不代表模型已完成蒸餾,也不等於把基礎模型縮成更少參數。
量化著重於數值表示的精度。Hugging Face 量化文件說明,較低精度的權重表示能降低記憶體需求,並盡量保留準確度。參數量可以不變,但每個權重佔用的空間減少。量化後是否更快,還要看硬體、運算支援與實際負載。
剪枝著重於移除或遮蔽部分權重與結構。PyTorch 剪枝教學展示了不同剪枝方式。權重變成零,不保證一般推論程式就會自動跳過運算。要換成實際加速,仍需相應的結構或稀疏運算支援。
這些方法可以組合,例如先訓練出合用的學生,再評估量化部署。想把概念接到本機環境,可延伸閱讀Qwen 本地部署與 GGUF 設定,但不同模型與硬體的需求要分別核對。
API 已經夠方便,什麼情況還值得蒸餾?
判斷方式是先看工作量與限制。若需求經常改變、使用量不大,直接使用現成模型可能更省事。若每天反覆處理相近任務,而且對回應時間、併發量、離線使用有明確要求,才值得把學生模型列入比較。這是部署規劃上的判斷,並非固定的成本結論。
比較時要把整段使用週期算進去,包括教師生成資料、資料審查、訓練、評估、硬體、維運,以及學生失敗後的重試或轉接。單次推論便宜,不能代表整個專案一定便宜。反過來,網路速度很好,也不會消除資料處理範圍與服務可用性的需求。
開始訓練前,先測未蒸餾的小模型是否已經夠用。如果簡單提示詞或現成模型就能完成工作,便沒有必要為了使用蒸餾而建立訓練管線。需要測試不同本地與雲端模型時,可參考LibreChat 與 Ollama 的整合方式,用同一批任務比較實際結果。
本地蒸餾模型的隱私,要沿著資料流檢查
學生在本機推論,確實可以減少把使用者輸入送往外部服務的需要。不過,隱私取決於整個系統如何傳遞與保存資料,不能只看模型檔案放在哪裡。
先看訓練前的資料準備。如果把內部文件送給雲端教師生成範例,資料在這一步就已經離開本機。再看實際使用時,是否另有雲端搜尋、遠端 Embedding、外部工具、遙測或日誌服務。最後看備援路徑,學生答不好時若自動轉給雲端大模型,轉交的問題、文件與歷史對話仍可能外傳。
有資料不外傳的要求時,應設計為本地處理、明確拒答或交由內部人員處理。允許混合部署時,則應先定義可外傳的資料範圍,並告知使用者何時轉交。把「本地模型」當作隱私保證,容易漏掉真正的資料出口。
實作蒸餾,先定義任務,再決定要不要訓練
以下是依前述方法整理的實務流程,適合用來規劃第一個小型試驗,不代表所有專案都需要同一套訓練參數。
先建立基準與驗收題目
選一個邊界清楚的任務,例如工單分類或固定欄位擷取。先測現成學生模型和教師各自的表現,定義正確率、格式完整性、回應時間與可接受的失敗方式。測試題目應與訓練資料分開,也要包含少見與資訊不足的情況。
生成範例後,先檢查品質
教師輸出需要去重、檢查事實、移除敏感內容,並確認符合任務規格。對答案可直接驗證的題目,優先使用程式規則或單元檢查。若蒸餾的是解題步驟,也不能只檢查最後答案正確,就認定中間推導全部可靠。
選擇訓練訊號,保留比較組
只有教師文字輸出時,可從回答資料微調開始。能取得分布且處理好對齊時,再評估軟標籤蒸餾。進一步的GKD 方法會讓學生在自己生成的序列上取得教師回饋,處理訓練資料與學生實際生成行為之間的差異。方法更複雜,並不代表每個任務都需要採用。
驗證泛化能力,再測實際部署
The False Promise of Imitating Proprietary LLMs在其研究設定下發現,模仿模型可以學到很像教師的回答風格,卻未必同步取得相同的事實能力。這項結果提醒我們,應檢查資料覆蓋之外的任務,不能只以流暢程度驗收,也不宜把該研究解讀成所有蒸餾都無效。
完成離線評估後,還要用目標硬體測記憶體、延遲與同時請求的表現。如果任務需要查詢經常更新的內部資料,可考慮讓模型搭配檢索,而非每次更新文件都重新蒸餾。站內的CrewAI 與 RAG 概念整理可作為理解工具與檢索分工的延伸閱讀。
模型蒸餾常見問題
模型蒸餾就是把大模型壓縮成小檔案嗎?
蒸餾是用教師訊號訓練學生,模型檔案大小取決於學生架構與數值精度。若只改變權重精度以縮小檔案,通常是在做量化。
只有教師模型的 API,也能做蒸餾嗎?
若 API 提供的輸出及使用條件允許,可以收集教師回答來微調學生。這與取得完整機率分布後進行的軟標籤蒸餾不同。
蒸餾後的小模型一定和大模型一樣強嗎?
不一定。效果受學生原本能力、資料覆蓋與任務影響,必須使用獨立題目評估,不能只看回答是否流暢。
Token 成本低,還需要自己蒸餾嗎?
未必。先比較現成模型是否夠用,再看使用量、延遲與離線需求。成本需要包含資料準備、訓練和維運,不能只看單次推論。
把小模型用在能驗收的任務上
蒸餾最值得關注的成果,是學生能否在你的任務上穩定達到要求,同時讓部署更容易。先建立現成模型的基準,找出缺口,再決定要準備什麼教師資料。當品質、速度與整體成本都有實際驗證,才能判斷這次訓練是否值得。
by Rain Chu | 9 月 17, 2026 | AI, 模型
Ornith 1.5 把本地 AI 的一個老問題攤得很清楚:每秒吐出多少 token,和最後有沒有把工作做完,是兩回事,35B-A3B 版本靠 MoE 架構降低每個 token 的運算量,在公開實測中展現速度優勢,也出現思考太久、額度用完卻沒交出程式碼的案例。
如果你想找一顆接在本地程式代理後面的模型,Ornith 1.5 35B 值得列入測試,評估時要一起看量化格式、記憶體餘裕、工具相容性與任務完成率,下面先拆開「自我改進」的意思,再看官方評分、兩組不同硬體的實測,以及實際上手順序。
Ornith 1.5 更新了什麼?先分清楚三種模型
Ornith 1.5 家族包含 9B Dense、35B MoE 與 397B MoE。手機部署的主角是 9B-Mobile 量化版本,與旗艦商用模型比較的宣傳則主要圍繞 397B。本文聚焦中間的 35B-A3B,不能把另外兩款的部署條件或成績直接套過來。版本資訊可從 官方模型集合查看。
如果你看過 Ornith 1.0 的自我拆解任務方式,這次最主要的延伸是把「生成訓練任務」也納入改善流程。
自我改進發生在訓練期間,下載後不會自動改寫權重
依照 Ornith 官方技術說明,模型在訓練中依序扮演三個角色:先根據程式庫與過去解題紀錄出題,再安排工具、指令與拆解方法,最後嘗試解題。結果回饋到強化學習流程,讓題目、執行安排與解法一起改善。
出題也有條件:題目要能驗證、難度合適,而且不能一直重複,官方把目標成功率設在約 20%,讓模型練習有挑戰但仍可能解出的題目。這個百分比是訓練課程的設計目標,不是產品的答題正確率。
可以把它想成練習寫程式時,不只修答案,也回頭調整練習題與測試方式。
下載回來的則是訓練後的模型權重,日常對話、保存記憶或反覆提示,不代表權重正在持續更新。
AlphaLab 對自我改進邊界的分析也提醒,環境與評分規則仍由人設計,分數上升還要確認是否真的學會解題。
35B-A3B 的 A3B,不是記憶體只要放下 3B
MoE 每次只選部分專家參與計算,但其他專家的權重仍要有地方存放。活躍參數主要影響每一步的運算量,總權重與快取才是估算記憶體的起點。官方 35B 模型頁列出約 3B 活躍參數,BF16 權重約 70GB,原生上下文為 262,144 token,模型規格與啟動範例可作為設定依據。
以目前 官方 GGUF 檔案清單為例,Q4_K_M 單一模型檔約 21.71GB,換算約 20.22GiB,這還沒加上推論引擎、上下文快取或視覺投影檔,因此「有 24GB 顯示記憶體」只能作為測試起點,不能直接承諾長上下文與多個並行任務都放得下。
12GB 或 16GB 顯示卡若想跑這個 Q4 檔,通常還得規劃部分權重放在系統記憶體,或改用其他量化版本,能載入模型、能順利對話、能在長任務中維持速度,應分開驗收。Mac 使用統一記憶體,也要預留系統空間,可搭配 本地 AI 的記憶體與頻寬選擇理解這個差別。
官方評分顯示程式能力進步,但要連測試框架一起看
以下是官方模型卡中同尺寸模型的部分成績。
Ornith 1.5 的結果為團隊自報的五次執行平均,並非本文重跑,也不等於所有電腦都會得到相同結果。
| 測試 | Ornith 1.5 35B | Ornith 1.0 35B | Qwen3.6 35B |
|---|
| Terminal-Bench 2.1/Terminus-2 | 67.8 | 64.2 | 52.5 |
| SWE-bench Verified | 79.0 | 75.6 | 73.4 |
| SWE-bench Pro | 59.6 | 50.4 | 49.5 |
資料來源:Ornith 35B 官方模型卡。各項測試使用各自的評測設定,不能相加成通用能力分數。
Terminal-Bench 的上述結果使用 Terminus-2,SWE-bench 使用 OpenHands。工具、提示、可用時間與上下文都會影響代理表現。「追平 Claude Opus」應限於官方列出的特定 397B 比較,無法據此宣稱 35B 全面取代商用模型。
對上 Qwen3.8 27B:生成得快,整個任務卻可能更慢
DIY Smart Code 的 Benchy 本地測試使用 RX 7900 XTX 24GB、Ryzen 9、64GB 系統記憶體與 Ollama,比較兩款 Q4 模型。Ornith 測試標示 32K 上下文。這是作者自建測試集的一組案例,量化檔案與測試工具的細節限制了外部重現,不能當成通用排名。
| 同一組 Benchy 案例 | Ornith 1.5 35B | Qwen3.8 27B |
|---|
| 通過項目 | 18/21 | 20/21 |
| 生成速度 | 約 74 tok/s | 約 58 tok/s |
| 提示處理速度 | 約 850 tok/s | 約 240 tok/s |
| 整組耗時 | 約 26 分鐘 | 約 17 分鐘 |
資料來源:DIY Smart Code,2026 年 8 月 22 日公開案例。數值依逐字稿約數整理,並非本文實測。
最有參考價值的是 DAG 非同步任務排程題:Ornith 花了約 18,000 個思考 token,耗盡輸出額度後沒有交出最終 Python 程式,Qwen 則完成程式並通過該題檢查。所以每秒輸出較快,仍可能因為思考與重試較多,拖長整個工作的時間。
這也不能反推成所有 MoE 都不擅長推理,或 Qwen 永遠比較穩,模型、量化、引擎與題型都不同,架構本身不能單獨解釋全部差異,要比較自己的程式任務,可參考 Qwen3.8 27B 本地部署教學,固定測試條件再重跑。
雙 GB10 的 NVFP4 實測:減少搬運,也能讓解碼加速
CyberQ 的雙 GB10 實測是在另一套硬體與 vLLM 環境中比較 BF16 與 NVFP4。它固定解碼 800 token,暖機後取三次量測中位數,因此較適合觀察格式差異,不適合直接和前面的 Ollama 成績排高低。
| 雙 GB10/TP=2 | BF16 | NVFP4 |
|---|
| 解碼吞吐量 | 48.41 tok/s | 101.86 tok/s |
| 12,001 token 提示處理 | 2,767 tok/s | 4,141 tok/s |
解碼約為 2.10 倍。這是特定硬體與引擎的量測結果。
該測試的 NVFP4 路徑先以低位元格式搬運權重,再反量化計算。當瓶頸是記憶體頻寬,減少搬運量就可能抵銷反量化成本。這是推論效率改善,不能解讀成硬體原生算力增加。
品質抽查中,兩種格式在 AIME 2026 都完成並答對 23/30 題,各有 7 題被輸出上限截斷。兩邊共同完成的 22 題答案一致,但答案一致不代表逐 token 的思考過程相同,也不能延伸成量化完全不損失品質。
本地部署怎麼開始?先讓短任務與工具呼叫跑通
先選權重格式與執行工具。桌面試用可從 GGUF 與 Ollama、llama.cpp 相容工具開始,伺服器則參考官方 vLLM 或 SGLang 範例。還不確定差別,可先看 本地大模型推論框架比較。
下載時認明 原始模型庫、官方 GGUF與 官方 NVFP4。另有 AtomicChat 的 GGUF 轉換版本可比較,請記錄實際檔名與量化等級,同樣寫 Q4 不表示所有檔案與執行結果完全相同。
測試時先縮短上下文、一次處理一個請求,確認記憶體與基本輸出正常,再逐步拉長。官方雖提供延伸到約 1M token 的設定,卻也提醒長上下文縮放可能影響一般長度的品質,不必第一次啟動就把視窗開到最大。
接代理前,再測試工具名稱、參數、工具結果回傳,以及模型能否繼續下一步。模型能輸出 tool_calls,只代表這段格式可用,MCP 伺服器還需要由代理程式接上。純聊天成功,不能代替完整工具流程驗收。
最後設定整個任務的時間、輸出與重試上限,並檢查所用引擎是否支援獨立思考額度。只縮小總輸出上限,可能更早截斷最終答案。日常試用可先用幾個有明確驗收條件的小任務,比較完成時間、人工修正量與失敗原因,再決定是否放入長時間自動化工作。
授權與手機部署,哪些說法還要保留?
T客邦的發布報導有助於了解系列定位,但授權敘述與官方 metadata 不一致。
本文以官方模型頁標示的 MIT 為準。
同樣地,9B-Mobile 支援行動裝置的宣稱,不能保證每一款手機都有足夠可用記憶體、支援對應模型格式,或能維持長上下文。先確認使用的 App、量化檔與裝置條件,比直接照搬桌面版的速度數字有用。
常見問題
Ornith 1.5 35B-A3B 是只有 3B 參數嗎?
不是。它是 35B 級 MoE 模型,每個 token 約啟用 3B 參數。儲存與載入仍需考慮完整權重,以及快取和引擎額外用量。
Ornith 1.5 放在本地使用會自己越來越聰明嗎?
官方的自我改進是訓練流程。下載後一般執行推論,不會因為聊天次數增加就自動更新模型權重。
24GB 顯示卡一定能跑 35B 的完整上下文嗎?
不能保證。官方 Q4_K_M 檔約 20.22GiB,還需預留引擎與快取空間。應從短上下文實測,再逐步調整。
Ornith 1.5 和 Qwen3.8 27B 該選哪個?
先用自己的任務比較。公開 Benchy 案例中 Ornith 生成較快,Qwen 通過較多項目。這組結果只適用於該測試條件。
這是美國團隊所推出的模型
Ornith 支援工具呼叫,就能直接連 MCP 嗎?
還需要代理程式與 MCP 連接層。應測試參數格式、工具執行與結果回傳的整個流程。
先看能否完成你的工作,再看分數有多高
Ornith 1.5 值得研究的地方,是它把練習題、工具安排與解法放進同一條訓練流程。而對本地使用者來說,35B-A3B 的實際價值仍要靠任務驗收:能不能在現有記憶體內跑穩、工具是否接得上,以及等待之後有沒有拿到可用成果。
先挑幾個你每週真的會做的工作,讓 Ornith 與現有模型各跑一次。保留設定、耗時與失敗紀錄,往往比看一張總排名更容易做出選擇。若想了解前述測試工具的設計,可再看 Benchy 測試工具建置說明。
by Rain Chu | 9 月 14, 2026 | AI, QWEN, TTS, 虛擬人, 語音合成, 語音辨識
把 AI 對話、即時語音和會動的人像放在同一台電腦上,現在已經可以做出一套不依賴雲端 API 的互動數位人,用 faster-whisper 聽懂麥克風,讓 Qwen3 產生回答,再交給 Qwen3-TTS 合成聲音,最後由 LiveTalking 完成口型同步與 WebRTC 串流。
先講我的結論。這套方案的價值是隱私、角色控制與離線能力,不是安裝後完全沒有成本。模型權重下載完成後確實不需要按次支付 API 費用,但顯卡、記憶體、硬碟、電力與維護時間仍然是成本,所謂 8GB 顯存能跑,也必須以較小的 LLM、量化權重和分階段載入為前提.若想讓 14B LLM、Whisper large-v3、1.7B TTS 與口型模型同時常駐,16GB 顯存仍可能不夠。
整套本地 AI 數位人怎麼運作
這不是單一模型,而是一條由五個服務組成的即時管線。
- VAD 判斷使用者何時開始與停止說話
- faster-whisper 把麥克風聲音轉成文字
- Qwen3 與 llama.cpp 根據角色設定產生回答
- Qwen3-TTS 把回答轉成指定音色的語音
- LiveTalking 接收音訊並驅動嘴型,再透過 WebRTC 顯示互動人像
這種模組化做法和我之前整理的 Hugging Face speech-to-speech 本地即時語音 Agent 是同一條思路。每一層都能替換,但每一層也有自己的模型、連接埠與執行環境。LiveTalking 不會自動知道 Qwen3-TTS 在哪裡,兩者中間仍需要官方支援的 TTS 外掛,或一個把生成音訊送到 /humanaudio 的橋接程式。
先算顯存,不要先相信 8GB 宣傳
| 元件 | RTX 4090 範例占用 | 低顯存調整 |
|---|
| Qwen3-14B Q4_K_M | 約 9GB | 改用 8B 或 4B 的 Q4_K_M |
| faster-whisper large-v3 | 約 3GB | 改用 medium,準確度會有取捨 |
| Qwen3-TTS 1.7B | 約 4GB | 改用 0.6B 或依序載入服務 |
| Wav2Lip 256 | 約 1.3GB | 降低批次並避免其他 GPU 程式常駐 |
這是 RTX 4090 整合環境的估計值,不同量化、上下文長度與 CUDA 版本都會改變結果
四個元件加起來約 17.3GB,還沒算 CUDA context、瀏覽器與暫存空間。16GB 顯卡跑到 99% 甚至整台機器失去回應,並不意外。6GB 顯存可以先用 Qwen3-4B 的 GGUF 量化版,並把語音辨識改成 medium。8GB 到 12GB 則適合 Qwen3-8B 搭配較小 TTS,或讓部分元件使用 CPU。若想了解 GGUF、llama.cpp 與 Ollama 的取捨,可以先看 本地大模型推理框架比較。
第一步,在 Windows 準備 WSL 2
這套整合方式把 llama.cpp 放在 Windows,語音與數位人服務放在 Ubuntu 24.04 的 WSL 2。先用系統管理員身分開啟 PowerShell。
wsl --update
wsl --install -d Ubuntu-24.04
Windows 使用者目錄的 .wslconfig 可以設定記憶體與鏡像網路。32GB 是範例,請依實際 RAM 調整,不要把主機記憶體全部交給 WSL。
[wsl2]
memory=32GB
networkingMode=mirrored
[experimental]
hostAddressLoopback=true
修改後重啟 WSL。
wsl --shutdown
進入 Ubuntu 後先用 nvidia-smi 檢查 GPU。NVIDIA 的 Linux 驅動不要再裝進 WSL,CUDA passthrough 由 Windows 顯示卡驅動提供。AMD 顯卡不能照搬這套 CUDA 整合包,需要改走 ROCm 支援的元件,或把無法使用 ROCm 的部分移到 CPU。
專案最好放在 Linux 家目錄,不要直接在 /mnt/c 執行。這能避開 I/O 速度、權限與換行格式問題。
mkdir -p ~/setup
cp -r "/mnt/c/Users/YOUR_NAME/Desktop/AI/." ~/setup/
cd ~/setup
sudo apt update
sudo apt install -y ffmpeg dos2unix python3-venv
dos2unix *.sh
chmod +x *.sh
第二步,用 llama.cpp 啟動 Qwen3
llama.cpp 提供 OpenAI 相容 HTTP 服務,語音管線不必知道底層跑的是 GGUF。16GB 以上可以從 Qwen3-14B 的 Q4_K_M 開始,8GB 到 12GB 建議改成 8B,4GB 到 6GB 則從 4B 測試。
llama-server -m E:\llama.cpp\models\Qwen3-14B-Instruct-Q4_K_M.gguf ^
-np 1 -c 8192 -fa on --temp 1.0 --top-p 0.95 ^
--host 0.0.0.0 --port 8090
新版 llama.cpp 文件也開始使用 llama serve 名稱,實際命令要以下載版本為準。Windows 的 8080 有時落在 Hyper-V 保留範圍,所以範例改用 8090。若服務無法綁定,可以先檢查保留埠。
netsh interface ipv4 show excludedportrange protocol=tcp
第三步,安裝即時語音管線
Hugging Face 官方 speech-to-speech 現在以 serve、talk 和 local 為主要命令,舊資料裡的 --mode 已經淘汰。先建立獨立環境,再安裝 faster-whisper 額外依賴。
python3 -m venv ~/venvs/s2s
source ~/venvs/s2s/bin/activate
python -m pip install --upgrade pip
pip install "speech-to-speech[faster-whisper]"
以下範例把 LLM 指向 Windows 上的 llama.cpp。不同版本的 STT 參數名稱可能調整,正式啟動前先執行 speech-to-speech serve --help 對照目前安裝版本。
speech-to-speech serve \
--stt faster-whisper \
--stt_model_name large-v3 \
--language zh \
--llm_backend responses-api \
--tts qwen3 \
--model_name Qwen3-14B-Instruct-Q4_K_M \
--responses_api_base_url http://127.0.0.1:8090/v1 \
--responses_api_api_key "" \
--responses_api_stream \
--enable_live_transcription
模型全部下載完成後,可以設定 HF_HUB_OFFLINE=1 驗證斷網狀態。這一步比口頭宣稱本地化更可靠,因為只要還有任一個後端指向雲端,就不算完整離線。
第四步,準備 Qwen3-TTS 與參考聲音
Qwen3-TTS 官方最簡單的安裝方式是獨立建立 Python 3.12 環境。它支援聲音克隆、音色設計與串流輸出。更多模型差異和 ComfyUI 節點用法,可以延伸看 Qwen3-TTS 音色設計整理。
conda create -n qwen3-tts python=3.12 -y
conda activate qwen3-tts
pip install -U qwen-tts
參考音訊建議控制在 5 到 15 秒,只留單一說話人,沒有音樂與明顯環境聲。參考文字必須和音訊實際內容完全相同,否則容易出現漏字、錯字與音色漂移。情緒也會一起被模仿,所以不要用過度激動的片段當作一般對話基準。
ffmpeg -i ~/setup/ref.wav -ac 1 -ar 16000 -c:a pcm_s16le ~/s2s/ref.wav
ffprobe -v error -show_entries stream=sample_rate,channels,codec_name \
-show_entries format=duration -of default=nw=1 ~/s2s/ref.wav
只應克隆自己或已取得明確授權的聲音。把真人聲紋放入公開服務前,也要考慮檔案存取權限、提示注入與未授權冒用。
第五步,製作自然的待機人像
人像素材不適合直接使用張嘴、手擋住嘴巴或劇烈轉頭的畫面。先生成嘴唇閉合、正面或微側面的基準圖,再用 Wan2.2 圖生影片做五秒左右的待機動作。提示詞只描述動作,不要重新描述人物外觀,能減少五官漂移。
電影感 16 比 9 構圖,一位成年東亞女性位於畫面右側三分之一,深色安靜房間,左側保留大量空間,螢幕冷光照亮臉部,輪廓帶柔和暖光,嘴唇自然閉合,雙手不遮擋嘴部,自然皮膚紋理,淺景深,真實攝影質感
負面提示詞
張嘴,說話,露齒,正面平光,明亮背景,過高對比,過度曝光,人物置中,多人,手遮擋嘴部,文字,浮水印,塑膠皮膚,過度修圖,卡通,3D 渲染
待機動畫提示詞
人物保持坐姿,只有細微自然呼吸,緩慢眨眼一次,頭部輕微移動後回到原位,嘴唇全程閉合,鏡頭完全鎖定,沒有縮放,沒有切鏡
關閉自動提示詞增強,輸出比例盡量和原圖相同。Wan2.2 常見原生片段是 81 幀、16 FPS,約五秒。若要二十秒待機,不要期待模型一次生成毫無漂移的長鏡頭,可以在自然停頓點循環短片。其他數位人生成思路可參考 LongCat 數位人工作流。
第六步,安裝 LiveTalking
LiveTalking 官方目前測試的環境是 Ubuntu 24.04、Python 3.12、PyTorch 2.9.1 與 CUDA 12.8。下面命令照官方版本撰寫,但 PyTorch 下載來源仍應配合自己的 CUDA 驅動,不要盲目安裝 cu128。
git clone https://github.com/lipku/LiveTalking.git
cd LiveTalking
conda create -n livetalking python=3.12 -y
conda activate livetalking
pip install torch==2.9.1 torchvision==0.24.1 torchaudio==2.9.1 \
--index-url https://download.pytorch.org/whl/cu128
pip install -r requirements.txt
下載官方提供的 wav2lip256.pth 後,把它放到 models,並改名成 wav2lip.pth。範例角色資料夾則解壓到 data/avatars。完成後啟動 WebRTC 服務。
python app.py --transport webrtc --model wav2lip \
--avatar_id wav2lip256_avatar1 \
--stun 'stun:stun.l.google.com:19302'
瀏覽器開啟 http://localhost:8010/index.html,按下開始連線。正式讓外部裝置使用時,官方提醒需要 TCP 8010 和 WebRTC 使用的 UDP 連接埠。不要直接把整段 UDP 範圍暴露到公網,應優先放在可信任區網、VPN 或經過限制的防火牆環境。
自己製作 Wav2Lip 角色時,可以把短影片轉成 avatar 資料。素材要維持正面可見、光線穩定與嘴部清楚。
python avatars/wav2lip/genavatar.py \
--video_path data/video/avatar.mp4 \
--img_size 256 \
--avatar_id my_avatar
第七步,正確啟動與串接
我會把服務拆成四個終端視窗,照下面順序啟動。每一步都先確認健康狀態,再開下一個服務。
- Windows 啟動 llama.cpp,確認
http://127.0.0.1:8090/v1/models 有回應
- WSL 啟動 Qwen3-TTS 或 speech-to-speech,先完成單句語音測試
- WSL 啟動 LiveTalking,確認 8010 網頁能顯示待機角色
- 最後啟動橋接程式,把 TTS 產生的音訊送入 LiveTalking 的
/humanaudio
作者提供的一鍵整合包包含自訂腳本與橋接程式,並不是 Hugging Face、Qwen 或 LiveTalking 的官方發行版。下載前應先檢查檔案來源、雜湊值、啟動腳本和網路連線,不要把未知執行檔直接放進主要工作電腦。想要長期維護,我更建議從官方專案建立環境,再自行補一個最小橋接層。
WebSocket failed 怎麼排查
- 先確認服務真的啟動。7860、8010 與 8090 是不同服務,瀏覽器頁面存在不代表後端 WebSocket 已連線
- 檢查 WSL 網路。修改
.wslconfig 後一定要執行 wsl --shutdown,鏡像網路與 hostAddressLoopback 才會重新載入
- 確認 Windows 防火牆。先只開必要 TCP 埠,在同一台電腦測通後再處理區網
- 不要混用 localhost。容器、WSL 與 Windows 各自看到的
127.0.0.1 可能不是同一個服務
- 確認瀏覽器麥克風權限。遠端網頁通常需要 HTTPS 或 localhost 才能取得安全的麥克風權限
- 降低 Noise Gate。如果網頁已連線但偵測不到聲音,先關閉門檻測試,再逐步調高
- 調整 VAD 停頓。約 900 到 1200 毫秒比較不容易搶話,但設定越長,回答開始時間也越慢
可以改成真正的 3D 角色嗎
可以,但不是把 Wav2Lip 模型換成一個 3D 檔案就完成。現在這條路線以 2D 影像或待機影片為基礎,口型模型直接修改臉部像素。真正的 3D 角色需要另外加入 Unity、Unreal Engine 或 WebGL renderer,再把 TTS 音訊轉成 viseme、音素或 blendshape 權重,驅動角色的嘴型、表情、眼神與骨架。
保留 VAD、Whisper、Qwen3 與 Qwen3-TTS,替換最後一層即可。新的輸出流程會變成 TTS 音訊、音素時間軸、3D blendshape、即時 renderer。若只是想讓角色有更豐富動作,可以先使用 LiveTalking 的自訂動作設定或多段待機素材,成本會比完整 3D 低很多。
本地不等於沒有風險
角色資料、聲音與對話都留在本機,確實能降低資料送往雲端的風險。但只要把服務開到區網或公網,就要重新考慮驗證、連接埠、惡意音訊、提示注入與檔案上傳。對話記憶也不是安裝完成就會永久存在,長期記憶需要另外接資料庫、摘要或向量檢索,否則聊天變長後仍可能忘記前文或開始胡亂延伸。
LiveTalking 官方也明確要求,使用此專案製作並發布到平台的內容必須包含 LiveTalking 浮水印與標誌。正式商用前要再確認每個模型、角色素材、聲音和整合程式的授權,不要只看程式能不能跑。
官方資源與參考資料
FAQ
8GB 顯存真的可以跑本地 AI 數位人嗎
可以做出可用版本,但不適合讓 14B LLM、large-v3、1.7B TTS 與口型模型全部以高規格同時常駐。建議改用 Qwen3-8B 或 4B 量化版、較小 TTS、較低 batch,必要時把部分模型放到 CPU。
可以完全離線,不使用任何 API 嗎
可以。前提是 STT、LLM、TTS 和數位人全部使用本地後端,而且模型與依賴已下載完成。設定 HF_HUB_OFFLINE=1 並在斷網環境測試,才能確認沒有隱藏的雲端依賴。
可以用英文或其他語言聊天嗎
可以,但 STT、LLM 與 TTS 三層都要支援目標語言。Whisper 與 Qwen3 的多語能力較完整,最終自然度通常由 TTS 音色與參考音訊決定。中英混合時要額外測試專有名詞、數字與語速。
Mac 可以照這篇安裝嗎
不能原封不動照做,因為本文整合路線依賴 Windows、WSL 與 CUDA。llama.cpp、Whisper 和部分 speech-to-speech 元件可以改走 Apple Silicon 的 Metal 或 MLX,但 LiveTalking 口型模型與整合腳本需要另外確認 macOS 支援,不能直接套用 NVIDIA 命令。
最後怎麼選
如果只是想快速聊天,雲端語音助手會更省時間。如果需求是讓私人對話留在本機、建立固定角色、接自己的資料或研究數位人介面,這套模組化管線就很值得做。我的建議是先讓文字對話跑通,再加入 STT 和 TTS,最後才接 LiveTalking。一次啟動所有元件,只會讓錯誤來源變得難以判斷。
真正值得學會的不是某個一鍵包,而是知道聲音在哪裡變成文字,回答在哪裡生成,音色在哪裡被控制,口型又由哪一個服務驅動。把這五層拆清楚後,未來換模型、換角色、換前端,整套系統仍然能繼續使用。
近期留言