TTS 文字轉語音完全指南:技術原理、聲音克隆與 2026 選型實戰

前陣子我在測 Qwen3-TTS,官方技術報告寫著首包延遲 97ms,聽起來就是為即時對話而生的。結果我照官方範例跑起來,按下生成、等了整整 10 秒才聽到第一個字。乾,差了一百倍。

這不是我環境爛,而是 TTS 這個領域的日常:論文數字、行銷頁數字、你實際跑出來的數字,是三個平行世界。97ms 是模型架構在特定串流管線下的能力值,官方釋出的推理程式碼卻是整段生成完才回傳——你拿到的「首包」其實是「全包」。

這篇文章是我最近一輪 TTS(Text-to-Speech,文字轉語音)研究的完整整理:技術原理怎麼走到今天、聲音克隆為什麼有人要 3 秒有人要 30 分鐘、2026 年雲端 API 的真實價格與盲測排名、本地部署誰最快,以及最重要的——那些行銷頁不會告訴你的坑。

TTS 聲波從機器音演化為自然人聲的概念圖

從機器音到以假亂真:TTS 技術是怎麼演進的

十年前的 TTS 是什麼樣子?導航機那種一個字一個字蹦出來的合成音。那個年代主流做法是「拼接合成」——把真人錄音切成音素片段,播放時再拼回去,像用剪報拼勒索信,字都對但就是不像人講話。

轉捩點是 2016 年 DeepMind 的 WaveNet 和 2017 年 Google 的 Tacotron:神經網路直接學習「文字到聲音」的映射,機器音瞬間變得有血有肉。但自迴歸模型要一個取樣點一個取樣點慢慢生,慢到不能上線。後來的 FastSpeech 用非自迴歸架構把生成平行化,VITS 把聲學模型和聲碼器合併成端到端訓練,速度和品質才總算都端上桌。

真正改變遊戲規則的是 2023 年微軟的 VALL-E :它把語音壓縮成離散的 codec token,然後把 TTS 當成「條件式語言模型」來做——跟 GPT 生成文字是同一套邏輯。這帶來一個副作用級的殺手功能:in-context learning。給模型 3 秒鐘的陌生聲音當 prompt,它就能用那個聲音講出任何內容。3 秒聲音克隆這件事,就是從這裡開始的。

2024 年之後的另一條路線是 flow matching:學一個從雜訊到聲學特徵的確定性映射,非自迴歸、全部音框平行生成。F5-TTS 就是這條路的代表作,推理效率在開源模型裡是第一梯隊。到了 2026 年,兩條路線開始合流——像 Qwen3-TTS 用 12Hz 多碼本 tokenizer 搭配輕量因果卷積網路,架構上做到 97ms 首包的串流能力(先不論你跑不跑得出來,後面會講)。

拼接合成(2016 前)→ 自迴歸神經網路(WaveNet / Tacotron)→ 非自迴歸(FastSpeech / VITS)
↓ 分成兩條路線 ↓
Codec 語言模型(VALL-E 路線)|Flow Matching(F5-TTS 路線)
↓ 兩路合流 ↓
混合串流架構(Qwen3-TTS 等 2026 世代)
神經網路 TTS 管線示意圖

聲音克隆:3 秒和 30 分鐘的差別在哪

聲音克隆(voice cloning)現在分成兩派,樣本需求差了幾百倍,很多人搞不清楚自己需要哪種。

Zero-shot 即時克隆:拿幾秒鐘的錄音當參考,模型直接模仿,不做任何訓練。Cartesia 只要 3 秒、Fish Audio 要 10 秒、ElevenLabs 的 Instant Voice Clone 建議 1 到 5 分鐘。原理就是前面說的 in-context learning——你的聲音只是一段 prompt。優點是快和便宜,缺點是它抓的是「音色的平均印象」,講話的小習慣、特殊的斷句節奏抓不太到。

微調式專業克隆:拿 30 分鐘以上的乾淨錄音去實際訓練模型權重。ElevenLabs 的 Professional Voice Clone 走這條路,官方說法是「幾乎無法分辨」;開源世界的 GPT-SoVITS 用 1 分鐘資料微調就有明顯提升。代價是要準備錄音素材、等訓練,而且通常要付訂閱費(ElevenLabs 要 Creator 方案 22 美元/月起)。

哪個好?取決於你要騙過誰。做影片旁白、有聲書,zero-shot 通常夠用,聽眾對「像不像本人」的敏感度沒你想的高。但如果是品牌聲音、Podcast 主持人的數位分身,微調式的差距一聽就出來。

還有一個台灣使用者才會踩到的坑:腔調漂移。MiniMax 的克隆還原度在台灣社群實測是第一名,但多位使用者回報克隆出來的中文帶「中國腔」——模型會把你的台灣腔往標準普通話拉。這不是 bug,是訓練資料分布的必然結果。想保留台灣腔,目前最可靠的路是本地微調 GPT-SoVITS,用你自己的錄音把腔調「鎖」進權重裡。

聲音克隆的鏡像波形概念圖

2026 雲端 API 評比:盲測排名與價格的落差

先看客觀數據。Artificial Analysis 的語音盲測排行 (2026 年 6 月,ELO 制)給了一個很多人意外的結果:

服務盲測 ELO價格(每百萬字元)克隆樣本
Inworld TTS 1.5 Max1208(第 1)$25–35數秒,免費
Google Gemini 3.1 Flash TTS1206(第 2)$36.6不支援
ElevenLabs Eleven v31178(第 4)$100IVC 1–5 分鐘
MiniMax Speech 2.8 HD1164(第 5)$100數十秒,$3/顆
Fish Audio S2 Pro1128(第 11)$15(注意單位是 bytes)10 秒,免費
Azure AI Speech HD1123(第 12)$22需申請
OpenAI TTS-11102(第 17)$15不支援
Cartesia Sonic-31070(第 25)約 $393 秒,免費

看到了嗎?ElevenLabs 收最貴的錢,盲測卻只排第 4。它贏的地方在別處:發音錯誤率最低、幻覺最少、工作流最完整。Reddit 上的評價很一致——「準確、快、錯誤少,但貴,而且常常要重新生成」。

Cartesia 則是被低估的性價比之王:5 美元/月就含商用授權和 3 秒即時克隆,延遲約 90ms 是業界最低。從 ElevenLabs 跳槽過去的使用者說法是「品質差距遠小於價格差距,大概便宜 8 倍」。

然後是三個行銷頁不會寫的坑,每個都是真金白銀:

Fish Audio 的 bytes 陷阱。它的 $15/1M 是按 UTF-8 bytes 計費,一個中文字佔 3 bytes——寫中文的人實際成本是 $45/1M 字,「比 ElevenLabs 便宜 70%」的甜頭瞬間縮水成三分之一。官方定價文件 寫得清清楚楚,只是沒人細看。

ElevenLabs 的 credit 燒錢術。重新生成扣點、預覽扣點、調參數也扣點。訂閱制下 Creator 方案 22 美元換 10 萬 credits,實質單價約 $220/1M 字元,是行銷頁「$100/1M」量販價的兩倍多。加上並發數限制綁方案,量一大就被逼著升級,啊不就好棒棒。

MiniMax 的腔調問題。前一段講過了,中文還原度第一,但台灣腔會被吃掉。它的 Fluent LoRA 技術能把不流利的錄音變流利——這既是功能,也是腔調被「標準化」的原因。

開源與本地部署:RTF 才是你該看的數字

開源這邊,2026 年的重點只有一句話:品質已經追上付費服務,剩下的差距在部署難度。Resemble AI 的 Chatterbox 在盲測中拿下 63.8% 的聽眾偏好、贏過 ElevenLabs(注意這是 Resemble 自家委託的測試,看看就好,但至少說明差距不大)。

本地部署最重要的指標是 RTF(Real-Time Factor):生成 1 秒音訊要花幾秒,小於 1 就是快於即時。實測數據:

模型RTF硬體克隆授權
GPT-SoVITS v2 ProPlus0.014(RTX 4090)/ 0.526(M4 CPU)GPU 佳微調式MIT
小米 OmniVoice0.025GPU3 秒 zero-shotApache 2.0
Kokoro-82M0.44(Mac MPS),CPU 可即時CPU 即可無克隆Apache 2.0
F5-TTS開源第一梯隊GPUzero-shotCC-BY-NC,不可商用
Chatterbox4.55(Mac,GPU 上好很多)建議 GPU10 秒MIT

GPT-SoVITS 的數字值得單獨拿出來講:RTX 4090 上 RTF 0.014,官方實測 4 分鐘的音訊 3.36 秒生成完,比即時快 70 倍。而且它是微調式克隆,正是保留台灣腔的解法。缺點是學習曲線陡,WebUI 一堆參數,第一次開會有點懷疑人生。

授權地雷區要特別畫重點:F5-TTS 是 CC-BY-NC、XTTS v2 是 CPML,都不能商用。做 YouTube 有營利、接案、公司產品,用了就是法律風險。要商用又要開源,選 MIT(GPT-SoVITS、Chatterbox)或 Apache 2.0(Kokoro、Qwen3-TTS、OmniVoice)。

沒有 GPU 也別急著關頁面。Kokoro 只有 82M 參數,筆電 CPU 就能即時生成(但沒有克隆);Kyutai 在 2026 年 1 月發布的 Pocket TTS 用 100M 參數做到 CPU 即時又能克隆,這個規模半年前還被認為不可能。

雲端服務與本地部署的對比

延遲的真相:97ms 是怎麼變成 10 秒的

回到開頭那個 97ms 變 10 秒的謎題,把它拆開看,你會學到怎麼讀所有 TTS 的延遲數字。

問題現象:照 Qwen3-TTS 官方 HuggingFace 範例跑 generate_voice_clone,首包 10 秒起跳。原因分析:官方釋出的 Python 推理程式碼根本不支援串流——它把整段音訊生成完才回傳。HuggingFace 討論區有人問了一模一樣的問題 ,得到的答案是:97ms 是架構能力,要靠另外的串流管線才拿得到。更慘的案例是 GitHub issue #89 :有人在 RTX 5090 上跑出比即時慢 10 倍的速度,GPU 使用率只有 4–5%——錢花了,卡在那邊納涼。

解決方案是換推理引擎。vLLM-omni 是 vLLM 官方的多模態擴展框架,2026 年 2 月合併了 Qwen3-TTS 的 CUDA Graph 加速和串流輸出,社群實測 1.7B 模型首包 80–90ms、RTF 0.3–0.4。同一顆模型,換個引擎,延遲差一百倍。

所以讀 TTS 延遲數字的正確姿勢是問三個問題:這是串流首包(TTFA)還是全段生成時間?是什麼推理管線量出來的?我的部署方式跑不跑得出同一條管線?行銷頁的數字永遠是三者最理想的組合。

如果你不想自己架,聚合平台是捷徑。以 fal.ai 上的 Qwen3-TTS 為例,克隆分兩步——先用參考音檔產生 speaker embedding,再拿 embedding 去合成:

# pip install fal-client;需設定環境變數 FAL_KEY
import fal_client

# 第一步:從 10 秒左右的參考音檔建立聲音 embedding
clone = fal_client.subscribe(
    "fal-ai/qwen-3-tts/clone-voice/1.7b",
    arguments={"audio_url": "https://example.com/my-voice-10s.wav"},
)
embedding_url = clone["speaker_embedding"]["url"]

# 第二步:用克隆的聲音合成語音
result = fal_client.subscribe(
    "fal-ai/qwen-3-tts/text-to-speech/1.7b",
    arguments={
        "text": "大家好,這是用三秒克隆技術生成的聲音。",
        "language": "Chinese",
        "speaker_voice_embedding_file_url": embedding_url,
    },
)
print(result["audio"]["url"])  # 生成音檔的下載連結

這個端點我實際查價是 $0.0008/分鐘音訊,便宜到我一度以為查錯,做影片旁白等於零成本。代價是走 queue 沒有串流,適合離線批量生成,不適合即時對話。

選型建議:一張表決定你該用哪家

講了這麼多,直接上決策表:

你的場景首選理由
影片旁白、批量生成,預算越低越好fal 上的 Qwen3-TTS幾乎零成本,中文原生
中文克隆還原度優先MiniMax台灣社群實測還原度第一,但注意腔調
英文內容、品質零妥協ElevenLabs 或 Inworld錯誤率最低 vs 盲測第一名還便宜
即時語音對話 agentCartesia90ms 延遲業界最低,$5/月含克隆
想保留台灣腔本地 GPT-SoVITS 微調唯一能把腔調鎖進權重的路
沒有 GPU 的本地玩家Kokoro(純 TTS)/ Pocket TTS(克隆)CPU 即時

我自己的建議是別急著訂閱任何服務。先拿 10 秒自己的錄音去 fal 上的 Qwen3-TTS 跑一輪,成本趨近於零;聽不滿意再花 $1.5 建一顆 MiniMax 克隆比較看看;兩個都過不了你的耳朵關,才需要考慮 ElevenLabs 的訂閱或本地微調。從免費往上爬,而不是從最貴的往下砍。

最後提醒一件比選型更重要的事:克隆只能用在你有合法使用權的聲音上。各家平台都有驗證機制,但技術上 3 秒就能克隆任何人的聲音,也代表詐騙集團同樣做得到——這一年語音詐騙的新聞沒少過。自己的聲音自己克隆,別人的聲音先拿到授權,這條線別踩。

TTS 這個市場每季都在洗牌,ElevenLabs 兩年內改了三次價格結構,開源模型每兩個月就有新王。這篇的數據以 2026 年 7 月為準,半年後記得重新查價。如果你有實測過其他組合,特別是台灣腔克隆的成功案例,歡迎留言分享——這塊的公開資料真的太少了。

TTS 選型決策路徑示意

參考資料

同一顆基座、兩種靈魂:Holo 3.1 與 Qwythos-9B 怎麼在你本機組成 Claude Computer Use

Holo 3.1 與 Qwythos-9B 主視覺:眼手與大腦

先講結論。這篇不是「盤點兩個新模型」的媒體稿,而是想解一個技術判斷題:

2026 年 6 月,兩個都基於 Qwen3.5-9B 、都掛 Apache 2.0、都在同月開源的模型,H Company 的 Holo 3.1 跟 Empero AI 的 Qwythos-9B ,我到底該用哪一個?

實測跑過兩週後,我的答案變成:兩個都要。它們不是同一條賽道上的競爭者,而是同一台本地 Claude Computer Use 的左手跟右手——一個是眼睛加雙手,一個是大腦加嘴巴。這篇就是把「為什麼」跟「怎麼做」拆給你看。


為什麼今年開源社群長得越來越像 Qwen3.5 生態圈

先鋪一下背景,這件事比模型本身更有意思。

過去半年,開源社群幾乎所有值得注意的專門化模型都往同一個基座靠:Qwen3.5。原因不神秘——Qwen3.5 提供了 0.8B 到 397B 的完整 dense/MoE 家族、原生 262k 脈絡、hybrid GDN+Attention 架構、以及真正商用友好的 Apache 2.0 授權。這在 Llama 4 的社群授權還有 700M MAU 上限、Gemma 有自訂條款的環境下,幾乎沒得挑。

於是我們看到的畫面是:Qwen 團隊把「作業系統」造好,其他實驗室在上面裝專用軟體。Holo 3.1 是「電腦操作」這個 app,Qwythos-9B 是「Claude 級推理」這個 app。兩個 app 都不重造輪子,都拿 Qwen3.5 當 kernel。這個現象跟去年 Llama 3 一枝獨秀時完全不同——基座之爭已經結束,戰場搬到後訓練專門化了

理解這一點之後,同月出兩個 Qwen3.5 微調模型就不是巧合,而是常態。而能不能組合起來,才是判斷開源生態成熟度的真正指標。


Holo 3.1:把螢幕看懂、把滑鼠鍵盤打通

同基座長出兩棵完全不同的樹

Holo 3.1 是 H Company 於 2026 年 6 月 2 日發布的 Computer-Use Agent VLM 家族。它做的事情很純粹:吃一張螢幕截圖 + 一個自然語言目標,吐出「下一步要點哪、打什麼、滾多少」。

家族尺寸從 0.8B 一路開到 35B-A3B MoE,跟 Qwen3.5 一一對應。旗艦款 35B-A3B 依社群拆解(對應 Qwen3.5-35B-A3B)大約是 256 個 experts、top-8 routing,激活參數只有 3B——白話就是「35B 級的能力,但推理速度接近 3B」。這對本地部署是天大的好消息,VRAM 帳單走總參數(Q4 大約 21GB),算力帳單走激活參數,24GB 的 RTX 4090 剛好塞得下。

真正拉開跟 Holo 3 差距的是三件事:

  1. 手機加進來了。AndroidWorld 從 67% 直接跳到 79.3%,4B/9B 也從 58% 拉到 71%
  2. Native function-calling。之前是 prompt 硬擠 JSON,現在是原生工具呼叫協議,跟任何 ReAct 框架能直接兼容
  3. 量化 checkpoint 三件套:NVFP4 給 DGX Spark、FP8 給 H100、Q4 GGUF 給消費硬體跟 Apple Silicon

我在自己 DGX Spark + NVFP4 + vLLM 環境下實測,35B-A3B 的 agent step time 從 FP8 baseline 的 6.8 秒直接砍到 3.3 秒(用 OSWorld 任務子集,10 步平均)。跟 H Company 官方 blog 揭露的 ~2× 端對端加速數字對得起來。這已經不是優化,是換引擎,夭壽。

放在整個 Computer-Use 賽道看,Holo3.1 的定位大概是:單一開源模型級別逼近人類基準。AndroidWorld 人類基準 80.0%,Holo 拿 79.3%;OSWorld-Verified 人類基準 72.4%,Holo 大約也逼到 80% 附近的水位。跟 ByteDance 的 UI-TARS-2 (OSWorld 47.5% / AndroidWorld 73.3%)相比,Holo 在同尺寸級別領先明顯。

但注意「單一模型」這四個字。H Company 自家的 Surfer 2 agent 系統把 OSWorld 拉到 60.1%、AndroidWorld 拉到 87.1%(見 Surfer 2 論文 arXiv 2510.19949 ),那是「Holo 當模型 + agent 框架」的組合結果。Holo 3.1 提供的是最強的零件,不是完整方案。這件事等下講雙引擎的時候會回來。


Qwythos-9B:把 Claude 的推理鏈灌進 9B

Qwythos-9B(全名 empero-ai/Qwythos-9B-Claude-Mythos-5-1M)是 Empero AI 在同月釋出的推理模型。它跟 Holo 3.1 用同一顆基座——Qwen3.5-9B——但完全不做 Computer-Use。

它做的是把 Claude Mythos 5 跟 Claude Fable 5 的推理鏈路徑,用 500M+ tokens 的 trace 資料,全參數 SFT 灌進一顆能跑在筆電上的 9B 模型。訓練用了兩階段課程學習:先廣泛推理語料,再聚焦 agentic + coding,用 bf16 + paged AdamW 8-bit + chunked NLL assistant-only loss。

技術亮點三個:

  • 1,048,576 token context:從 Qwen3.5 原生 262k 用 YaRN factor=4 直接擴到 1M。消費硬體開 32k~128k 較實際,48GB A6000 才能吃到接近全窗
  • 原生 function-calling:官方 tool-use test 拿 7/7,且答案帶真實來源引用
  • 深度無審查:官方 model card 明講「engage seriously with cybersecurity, red-teaming, pharmacology, clinical medicine」。這是把雙面刃

跟 Qwen3.5-9B base 相比,Qwythos-9B 在 MMLU 上 +34.3,GSM8K strict-match +30.0(flexible-extract 口徑則是 +19,官方 model card 兩個都給了,我這裡取 strict 是為了避免 extraction 誤差干擾)。這差距不像是同尺寸 fine-tune 該有的,比較像「9B 皮、Claude 骨」。

它適合的場景是那些要讀很多、想很深、講很久的活:長文件分析、整個 codebase 一次讀進 context、多步 agent 工作流、需要 Python executor 驗證的長推理。不適合的場景也很清楚:想要輕鬆閒聊、沒有 GPU、不想處理 <think> 區塊、面對消費者的產品——因為它會直接回答那些多數對齊模型會拒絕的問題,安全層要自己補。


為什麼兩個放一起,就變成 Claude Computer Use

看到這裡應該有感覺了。Holo 3.1 缺什麼?思考深度。Qwythos-9B 缺什麼?眼睛跟手

這不是巧合。Computer-Use Agent 的兩大瓶頸就是這兩個:

  1. 看不清螢幕:早期 Claude Computer Use 常在 GUI 邊界判斷失誤,Anthropic 內部承認純 LLM+screenshot 的 grounding 有天花板
  2. 想不夠深:純 Vision-Language Model 為了 UI grounding 犧牲了長脈絡與深度推理,這是 UI-TARS 系列在複雜跨應用任務會卡住的主因

Holo 3.1 把 grounding 這面推到接近人類;Qwythos-9B 把 reasoning 這面推到接近 Claude。你把它們串成一個雙引擎 agent loop,就在自己電腦上組出了功能等價於 Claude Computer Use 的完整堆疊,而且完全離線。

架構長這樣:

使用者自然語言目標
        ↓
Qwythos-9B(高階規劃 + 1M context,讀歷史操作/文件/規格)
        ↓ function_call
Holo 3.1(低階執行 + 螢幕理解,決定像素座標動作)
        ↓ action
Sandbox / OS(執行動作 → 新截圖)
        ↑ 回到 Holo,狀態摘要回到 Qwythos
        ↓ 迴圈直到完成
最終結果 → 使用者

分工邏輯很簡單:Qwythos 收「目標 + 完整歷史脈絡 + 上次截圖的文字描述」→ 輸出「下一步計畫 + 要 Holo 執行的 tool_call」。Holo 收「這個 tool_call + 當前截圖」→ 輸出「像素座標動作」。動作執行完,新截圖回到 Holo,狀態摘要回到 Qwythos。

一台 24GB VRAM 的 RTX 4090,可以同時裝 Qwythos-9B Q4 GGUF(約 5.6GB)+ Holo-3.1-9B Q4 GGUF(約 6GB),剩下 12GB 留給兩顆的 KV cache。或者 M3 Max 64GB 統一記憶體全跑起來,一台筆電就是完整推理 rig。


OpenClaw:兩個模型碰上生態圈的巧遇

OpenClaw 當整合中樞

理論組合聽起來很美,實務要怎麼把兩個 llama-server 綁進同一個 agent 框架?答案是 OpenClaw ,一個由 Peter Steinberger 在 2025 年底開源的本地優先 agent runtime,社群成長很誇張——推出 24 小時內就衝破 9000 星,到 2026 年 Q1 已經是六位數等級的專案。

有趣的是,兩個模型跟 OpenClaw 的關係並不對稱:

模型OpenClaw 整合證據
Holo 3.1有專門部署教學KnightLi 部落格 Holo 3.1 Local Deployment Guide 手把手教你用 openclaw skills install agent-browser 把 Holo 掛進 gateway(該站點會導向自訂 port,若瀏覽器擋下請手動信任)
Qwythos-9B沒專屬教學但通用可行官方文件只講 vLLM / SGLang / Transformers / Ollama。因為 OpenClaw 支援任何 OpenAI 相容端點,Qwythos 可以透過 Ollama provider 間接接上

差距在哪?Holo 3.1 是 GUI 專職模型,跟 OpenClaw 的 agent-browser skill 幾乎是零距離的天生一對——它就是為了 browser/desktop 操作而生。而 Qwythos 定位是「推理 + tool use」文字模型,OpenClaw 社群還沒有為它做專案,但它拿 7/7 tool-use test 加上 function-calling 支援,是 OpenClaw primary model 的優質候選。

換句話說,Holo 是已被 OpenClaw 生態圈收編的模型,Qwythos 是可以但還沒被收編的模型。有沒有覺得這缺口剛好是給你的機會?

實作:把兩個模型掛進同一個 OpenClaw

前置條件講在前面:

  • macOS / Linux / Windows(我在 M3 Max 64GB 跟 Ubuntu + RTX 4090 上都測過)
  • llama.cpp 或 Ollama 至少一個
  • OpenClaw(Homebrew 或官方 installer)
  • Chrome(如果要跑 browser skill)

第一步:用 llama.cpp 起 Holo 3.1 的 server

從 Hugging Face 抓 Hcompany/Holo-3.1-9B-GGUF 的主檔跟 mmproj 視覺投影檔,這裡 mmproj 常被漏掉,漏了就沒有視覺輸入。

llama-server \
  -m ./models/holo-3.1-9b.q4_k_m.gguf \
  --mmproj ./models/holo-3.1-9b-mmproj.f16.gguf \
  -ngl 999 -c 8192 -fa \
  --temp 0.2 --top-p 0.9 \
  --host 127.0.0.1 --port 8081

第二步:用 Ollama 起 Qwythos

ollama run hf.co/empero-ai/Qwythos-9B-Claude-Mythos-5-1M-GGUF:Q4_K_M

Q4_K_M 檔案約 5.2GB,跑起來一顆 8GB VRAM 就夠。Ollama 預設會開 http://localhost:11434 的 OpenAI 相容端點。

第三步:讓 OpenClaw 認識這兩顆模型

編輯 ~/.openclaw/config.json(不同版本路徑可能略異,用 openclaw config path 確認):

{
  "agents": {
    "defaults": {
      "model": { "primary": "ollama/qwythos-9b" }
    }
  },
  "models": {
    "providers": {
      "ollama": {
        "baseUrl": "http://localhost:11434",
        "apiKey": "ollama-local",
        "api": "openai-completions",
        "timeoutSeconds": 300,
        "models": [
          {
            "id": "hf.co/empero-ai/Qwythos-9B-Claude-Mythos-5-1M-GGUF:Q4_K_M",
            "name": "Qwythos-9B",
            "reasoning": true,
            "input": ["text"],
            "contextWindow": 131072,
            "maxTokens": 8192
          }
        ]
      },
      "holo-local": {
        "baseUrl": "http://127.0.0.1:8081/v1",
        "apiKey": "sk-local",
        "api": "openai-completions",
        "timeoutSeconds": 120,
        "models": [
          {
            "id": "holo-3.1-9b",
            "name": "Holo 3.1 9B (Vision)",
            "reasoning": false,
            "input": ["text", "image"],
            "contextWindow": 32768,
            "maxTokens": 2048
          }
        ]
      }
    }
  }
}

Qwythos 當 primary(負責思考跟規劃),Holo 當 vision 專用 provider(負責螢幕跟動作)。context window 我先給 131k 是保守值,硬體允許再拉。

第四步:裝 browser skill,把 Holo 綁上去

openclaw skills install agent-browser
openclaw doctor
openclaw gateway restart

agent-browser 這個 skill 會自動下載 Playwright + Chromium。裝完後可以在 skill 設定裡指定「vision model 用 holo-local/holo-3.1-9b」,這樣主 agent(Qwythos)就會把螢幕理解任務外派給 Holo endpoint。

第五步:試一個真實任務

在 OpenClaw chat 輸入:
「打開 hcompany.ai/holo3.1,找出 Holo 3.1 的 4B 模型在 AndroidWorld 的分數,
把來源 URL 一起回給我。」

會看到 Qwythos 先規劃步驟(<think> 區塊會冒出來),呼叫 browser skill 開頁,Holo 看截圖決定要往哪 scroll、要點哪個連結,資料回到 Qwythos 整理成有引用的答案。這就是本地版 Claude Computer Use 的最小可行迴圈。


踩過的坑跟一定要記的事

筆電上的本地雙引擎

實測兩週,踩到的雷整理如下。

坑一:Holo 3.1 各尺寸授權沒完全確認

只有 0.8B 我親眼看到 Apache 2.0 明確標示。4B / 9B / 35B-A3B 的 Hugging Face model card 我建議每一顆都自己去確認一次,特別是打算商業部署的話。H Company 上一代 Holo1.5 是「3B 掛 Qwen license、7B 掛 Apache 2.0、72B 掛 research-only」的分級模式,Holo 3.1 不保證統一。

坑二:Qwythos 的 <think> 區塊

如果你把 Qwythos 接到使用者可見的 UI,<think>...</think> 會直接被吐出來,用戶會看到一大坨推理過程。正確做法是在 gateway 層過濾掉,或者把 reasoning 顯示切成摺疊區塊。

坑三:1M context 不代表消費硬體吃得下

Qwythos 的 config 寫 max_position_embeddings: 1048576,但 KV cache 會爆。8GB VRAM 建議只開 32k,24GB 開 128k,48GB 才有機會逼近全窗。不要看到 1M 就無腦塞整個 codebase,會 OOM。

坑四:Holo 3.1 GGUF 漏掉 mmproj

llama.cpp 的視覺模型要主檔 + mmproj 兩個檔一起載入。只載主檔,模型會啟動成功但看不見圖,這是最常見的初學者陷阱。

坑五:Qwythos 未審查是雙面刃

它是刻意 uncensored 的模型,你在自己實驗室跑當然沒問題,但只要要 serve 給外部使用者、或者接到公司內部系統,應用層 guardrail 必須自己補。Empero 的 model card 已經寫清楚這點,別假裝沒看到。

坑六:OpenClaw 對 tool_choice 的預設

OpenClaw gateway 預設 tool_choice: "auto"。Qwythos 因為每回合都會走推理再決定要不要呼叫工具,通常 auto 剛好;但如果你想強制每回合都用工具(例如純 agent workflow),要在 config 手動蓋成 "required"

"agents": {
  "defaults": {
    "models": {
      "ollama/qwythos-9b": {
        "params": { "extra_body": { "tool_choice": "required" } }
      }
    }
  }
}

誰該做、誰別做

不是每個人都需要組這個雙引擎。用途對應建議是這樣:

情境建議
想試試「本地 Claude 助理操作我電腦」雙引擎全套上,M3 Max 或 24GB VRAM 起步
只想跑 browser 自動化,不需要深度推理Holo 3.1 4B / 9B 單獨用就好,Qwythos 是浪費
只想讀 codebase / 論文,不操作電腦Qwythos-9B 單獨用,Holo 是浪費
想做無審查資安研究Qwythos + Docker sandbox,Holo 選配
面對消費者的產品兩個都不建議直接用,未審查跟企業對齊差距太大
資源極少(8GB 以下)Holo-3.1-0.8B 單引擎,Qwythos 最小也是 9B
想要極致速度別用 Qwythos,<think> 會拖 UX,改用 Holo + 更輕的規劃模型

結語:開源社群的成熟度訊號

我覺得 Holo 3.1 跟 Qwythos-9B 最值得記住的不是任何一個 benchmark 數字,而是它們同月由不同團隊獨立發布,卻能無縫組合這件事。

過去我們談開源 AI 生態,常常是「這個模型跟那個框架不相容」「這家的 tokenizer 跟那家不合」的碎片化狀態。而現在因為 Qwen3.5 這個共同底座、Apache 2.0 這個共同授權、OpenAI-compatible API 這個共同介面,你可以把兩個素不相識實驗室的模型,在同一個 gateway 裡兜成一個完整產品。

這個能兜起來的能力,本身就是開源社群長大的訊號。

如果你正在做本地 AI agent 相關的東西,這個週末花兩小時把 Holo + Qwythos + OpenClaw 這條線走一次,會比讀十篇 benchmark 分析更有感。硬體剛好 24GB VRAM 或 M3 級筆電的話,你已經比 90% 的 API 使用者更接近「AI 真的在幫我做事」這件事的本質。


參考資料

TTS 文字轉語音完全指南:技術原理、聲音克隆與 2026 選型實戰

前陣子我在測 Qwen3-TTS,官方技術報告寫著首包延遲 97ms,聽起來就是為即時對話而生的。結果我照官方範例跑起來,按下生成、等了整整 10 秒才聽到第一個字。乾,差了一百倍。 這不是我環境爛,而是 TTS 這個領域的日常:論文數字、行銷頁數字、你實際跑出來的數字,是三個...