by Rain Chu 7 月 15, 2026 | 未分類
開源 TTS 最近很熱，但 dots.tts 值得特別看，原因不是只有聲音像，而是它把文字轉語音的路線又往前推了一步，它是一個 2B 參數的全連續端到端自回歸 TTS 系統，官方說明裡最關鍵的一句話是，整條管線不使用離散 token，而是用連續 latent 來完成語音生成。
如果你已經看過 Qwen3-TTS 的音色設計 ，或之前玩過 VoxelCPM 本地聲音復刻 ，dots.tts 可以放在同一條脈絡裡理解，以前很多 TTS 工具在可用性上已經不差，現在競爭點開始變成音色相似度、情緒穩定度、跨語言保真，以及能不能進一步做成即時語音 Agent 的底層能力。
先講結論
dots.tts 最適合被理解成一個偏研究與工程兼具的開源 TTS 底座。它不是只把文字念出來，而是把語意編碼器、LLM、自回歸 flow-matching 聲學頭、48 kHz AudioVAE 和 speaker x-vector 接成一條完整語音生成管線。
它目前最吸引人的地方有三個。
第一，官方釋出 pretrained、SCA 和 MeanFlow distilled 三種 checkpoint。
第二，SCA 版本主打更好的 voice cloning 表現。
第三，MeanFlow 版本用比較少的取樣步數換取推理速度，比較適合在產品或本地服務裡評估。
dots.tts 是什麼
dots.tts 是一個 2B 參數的 fully continuous end-to-end autoregressive text-to-speech 系統。官方 README 寫得很直接，它的骨幹由 semantic encoder、LLM 和 autoregressive flow-matching acoustic head 組成，底層則接 48 kHz AudioVAE。
這裡的重點是 fully continuous。傳統語音生成常會把聲音先離散化成 codec token，再讓模型預測 token，dots.tts 選擇不要走這條路，而是在連續 latent 空間裡處理語音。這個設計會讓架構更複雜，但它也讓音色、韻律和情緒細節有更大的保留空間。
三個 checkpoint 怎麼選
官方目前釋出三個 Hugging Face checkpoint，它們共用同一個 backbone，差別在品質、速度與對 voice cloning 的優化方向。
我會先從 dots.tts-soar 開始測，因為 voice cloning 通常是大家最在意的部分。如果要做服務化，才把 dots.tts-mf 拉進來比較延遲與硬體成本。
它的架構重點
官方架構可以拆成四層來看。AudioVAE 負責把 48 kHz mono waveform 編碼成連續 latent，也負責還原成聲音。Semantic encoder 會把新生成的 VAE patch 重新編碼成較緊湊的語意表示，LLM 由 Qwen2.5 1.5B Base 初始化，直接吃 BPE text。最後的自回歸 flow-matching acoustic head 則負責預測下一段聲音 latent。
這個設計有一個很有意思的方向。它不只是 TTS，也比較像是在替語音互動系統準備底座，官方提到 1T1A interleaved mode，可以讓一個 BPE token 和一個 audio step 交錯，目標是低延遲 streaming。這就會和 本地即時語音 Agent 的方向接起來。
數據上有多強
官方 benchmark 裡最直觀的是 Seed-TTS-Eval，dots.tts SCA 在中文測試的 WER 是 0.94，英文是 1.30，中文 hard set 是 6.60，平均 WER 是 2.95。這組數字和 Qwen3-TTS、CosyVoice 3、F5-TTS 放在一起看，已經是開源 TTS 裡非常前段的位置。
模型 參數量 英文 WER 中文 WER 中文 hard WER 平均 WER dots.tts SCA 2B 1.30 0.94 6.60 2.95 Qwen3-TTS 1.7B 1.23 1.22 6.76 3.07 CosyVoice 3 1.5B 2.22 1.12 5.83 3.06 F5-TTS 0.3B 2.00 1.53 8.67 4.10
平均 WER 越低代表文字內容錯誤率越低。這張圖只取官方 README 表格中的部分模型，方便快速比較。 另一個值得注意的是 MiniMax Multilingual ，官方寫到 dots.tts SCA 的平均 speaker similarity 是 83.9，並且在 24 種語言裡有 19 種取得 SIM 領先，另有 2 種並列，這代表它的聲音相似度不是只在中文或英文好看，而是有跨語言保存音色的能力。
本地部署先看這幾件事
官方建議用 Python 3.10 到 3.12 開新的 conda environment，再從 source 安裝。這類語音模型通常對套件版本很敏感，所以我會照官方 constraints 跑，不會一開始就混用自己環境裡的 torch、transformers 或音訊套件。
conda create -n dots_tts python=3.10 -y
conda activate dots_tts
python -m pip install --upgrade pip
python -m pip install -e . -c constraints/recommended.txt 最小測試可以用 CLI。voice cloning 建議給一段乾淨 reference audio，官方建議大約 10 秒就好，太長不會帶來更好的結果。更重要的是 prompt text 要和 reference audio 實際說的內容一致，不一致會讓穩定度變差，甚至出現 word-level 錯誤。
dots.tts --model-name-or-path rednote-hilab/dots.tts-soar --text "這是一段語音合成測試" --prompt-audio /path/to/reference.wav --prompt-text "參考音訊實際說出的文字" --num-steps 10 --output clone.wav 我會怎麼測 dots.tts
第一輪不要急著做長文朗讀，先準備三種 reference audio，分別是乾淨女聲、乾淨男聲、帶一點情緒的自然說話，每段控制在 8 到 12 秒，背景聲音越少越好，然後用同一段中文、英文和中英混合文字跑三次，看它的穩定度和語言切換表現。
第二輪才測情緒與語氣，這裡不要只聽像不像，還要看文字內容是否漏字、重複、破音，還有語尾是否自然，TTS 如果只追求音色相似，很容易忽略可讀性，真正能進工作流的 TTS，應該是長時間輸出也不容易出錯。
第三輪測 streaming，官方 Python API 提供 generate_stream，這對語音助理、客服機器人、角色互動很重要，這也能和我之前整理的 audio.cpp 本地語音 AI 底座 放在一起看，未來本地語音工作流很可能會走向 ASR、LLM、TTS 都可替換的模組化架構。
限制也要先看清楚
dots.tts 不是所有語言都一樣穩，官方風險與限制裡提到，低資源語言會有 WER gap，特別是阿拉伯文、印地文、土耳其文、越南文這類資料覆蓋比較吃緊的語言，它可以保住 speaker similarity，但文字正確率不一定跟高資源語言一樣漂亮。
另一個限制是訓練資料偏 speech-heavy，AudioVAE 雖然原則上是 modality-agnostic，但這次釋出的模型不涵蓋唱歌，也不是統一的 speech 加 sound generation 模型。所以如果你的需求是歌曲翻唱、音效生成或完整聲音設計，它不是最直接的答案。
我的判斷
dots.tts 最值得關注的不是 3 秒復刻這種口號，而是它把開源 TTS 拉到更接近產品級底座的位置，2B 參數、連續 latent、自回歸 flow matching、SCA 對齊、MeanFlow 蒸餾，這些都不是單純 demo 型專案會一次放齊的東西。
如果你只是想快速產生中文旁白，現成工具可能更省事，如果你想研究本地 voice cloning、即時語音 Agent、跨語言音色保留，或把 TTS 放進自己的產品工作流，dots.tts 很值得列入測試清單 。
延伸資源
FAQ
dots.tts 適合拿來做聲音復刻嗎？
適合評估，尤其是 dots.tts-soar。官方把它定位成 voice cloning 表現最好的 checkpoint，但實際品質仍取決於 reference audio 是否乾淨，以及 prompt text 是否和參考音訊一致。
dots.tts-mf 和 dots.tts-soar 差在哪裡？
dots.tts-soar 偏向品質與聲音復刻，dots.tts-mf 是 MeanFlow distilled student，官方建議 4 steps，目標是降低推理成本與提升速度。
參考音訊要多長？
官方建議大約 10 秒。更長不一定更好，乾淨、高取樣率、低背景噪音、自然說話，比單純拉長音訊更重要。
dots.tts 可以做唱歌或音效生成嗎？
不建議把它當成這類任務的主要方案。官方限制裡寫到這次釋出偏 speech-heavy，沒有覆蓋唱歌，也不是 speech 加 sound 的統一生成模型。
by Rain Chu 7 月 15, 2026 | Agent , AI
Windows 跑 AI Agent，真正的關鍵不是把所有工具硬裝進 PowerShell，而是把 Windows 當成桌面和硬體入口，把 Linux 工具鏈交給 WSL 2，這樣做的好處很直接：Python、Node、Docker、Git、CUDA、各種開源 Agent 工具，都會更接近它們原本被設計和測試的環境。
我的判斷是，如果你在 Windows 上做 Codex、Claude Code、Cursor、OpenCode、本地模型或自動化 Agent，WSL 2 幾乎是標準底座，不是因為 Windows 不行，而是 AI Agent 這一波工具鏈大多先從 Linux 生態長出來。
先講結論
Windows 11 或新版 Windows 10 可以用 `wsl –install` 安裝 WSL，預設會走 WSL 2。
AI Agent 專案建議放在 WSL 的 `/home` 目錄，不要長期放在 `/mnt/c`。
VS Code 建議用 Remote WSL，讓編輯器在 Windows，工具鏈在 Linux。
Docker Desktop 可以啟用 WSL 2 backend，適合需要容器化 Agent 服務的人。
NVIDIA GPU 可以在 WSL 2 裡用 CUDA，但重點是安裝 Windows 端驅動，不要在 WSL 裡裝 Linux 顯示驅動。
為什麼 Windows 跑 AI Agent 需要 WSL
Microsoft 對 WSL 的定位很清楚：讓開發者可以在 Windows 上直接使用 Linux distribution、Linux 應用、工具和 Bash 命令列，而且不需要傳統虛擬機或雙系統。對 AI Agent 來說，這剛好補上 Windows 和開源工具鏈之間的落差。
很多 Agent 專案會同時碰到 Python、Node、Playwright、ffmpeg、SQLite、Docker、Git hooks、shell scripts。這些東西在 Linux 裡比較自然，在 Windows 原生環境則容易遇到路徑、權限、編碼、套件編譯和命令差異。
如果你正在使用 Codex 與 ChatGPT Work ，或想把 OpenWork 和 OpenCode 桌面工作台 跑穩，WSL 可以讓 Windows 變成比較舒服的 Agent 開發機，而不是一直在修環境。
第一步：安裝與確認 WSL 2
Microsoft 官方文件建議，在符合版本的 Windows 上，可以用系統管理員 PowerShell 執行：
安裝後可以用下面指令查看 distribution 和 WSL 版本：
如果你有多個 Linux distribution，可以用 `wsl.exe –set-default` 設定預設環境。對大多數 AI Agent 使用者，我會建議先用 Ubuntu，原因不是它最酷，而是教學、套件、問題排查和相容性資料最多。
第二步：專案不要放在 /mnt/c
這是最常見的坑。Microsoft 文件明確建議，如果你主要在 Linux 命令列裡工作，專案檔案應該放在 WSL 檔案系統內，例如 `/home/你的帳號/projects`。不要把主要專案放在 `/mnt/c/Users/…` 下面長期開發。
原因是跨 Windows 和 Linux 檔案系統會影響效能，也可能讓檔案權限、大小寫、watcher、node_modules、Python venv 出現奇怪問題。AI Agent 工作流常常有大量小檔案、快取、套件安裝和檔案監看，這種差異會被放大。
簡單說：Linux 工具鏈處理的專案，就放 Linux 檔案系統，需要從 Windows 檔案總管打開時，可以在 WSL 目錄下執行：
explorer.exe .第三步：VS Code 用 Remote WSL
不要把 VS Code 直接開在 Windows 路徑裡，再讓終端機切來切去。比較乾淨的方式是安裝 VS Code 的 WSL 支援，從 WSL 裡開專案：
code .這樣 UI 還是在 Windows，但 extension host、terminal、語言服務和套件環境會跑在 WSL。對 Python、Node、Rust、Go、Docker compose、Playwright 這類 Agent 常用工具，這種模式會少很多不必要的摩擦。
第四步：Docker 交給 WSL 2 backend
很多 AI Agent 工具會需要資料庫、瀏覽器服務、向量資料庫、Redis、sandbox 或 API mock。這時候 Docker 是很自然的選擇。Docker Desktop 支援 WSL 2 backend，可以讓 Windows 上的容器工作流更接近 Linux。
我會把它看成「可複製環境」的保險。今天你在 Windows WSL 跑得起來，明天移到 Linux server 或雲端 VM，踩坑會少很多。這和我之前整理 Docker 跟 command line 一樣使用 的方向一致，容器不是炫技，而是讓環境可重現。
第五步：GPU 和 CUDA 要小心裝
如果你要跑本地模型、推理框架或 CUDA 工具，WSL 2 可以吃到 NVIDIA GPU，NVIDIA 官方文件的關鍵提醒是：安裝 Windows 端 NVIDIA 驅動後，CUDA 驅動會映射進 WSL，不要在 WSL 裡安裝 Linux 顯示驅動。
這點很重要。很多人一進 Ubuntu 就照 Linux 教學裝完整 NVIDIA driver，反而把環境弄壞，WSL 裡需要的是相容的 CUDA toolkit 和使用者空間工具，不是另一套 Linux 顯示驅動。
如果你在 Windows 上遠端連自己的 AI server，可以參考我之前寫的 Windows PowerShell 連接 Ollama AI Server 。如果是要本機推理，則更需要把 WSL、GPU driver、CUDA 和模型框架的版本關係先整理好。
Windows 跑 AI Agent 的 WSL 檢查表
階段 建議做法 原因 安裝 使用 wsl –install 並確認 WSL 2 取得 Linux 工具鏈與較完整相容性 檔案 專案放在 /home 內 避免 /mnt/c 跨檔案系統拖慢 I/O 開發 VS Code Remote WSL 讓編輯器在 Windows，工具鏈在 Linux 容器 Docker Desktop WSL 2 backend 讓 Agent 工作流更容易複製 GPU Windows 驅動 + WSL CUDA 避免在 WSL 內安裝 Linux 顯示驅動
WSL 跑 AI Agent 的重點不是只把 Ubuntu 裝起來，而是把檔案、編輯器、容器和 GPU 全部放在正確位置。 我會怎麼配置一台 Windows AI Agent 機
如果是我自己整理一台 Windows AI Agent 工作機，我會照這個順序來：
Windows Terminal 裝好，PowerShell 和 Ubuntu 分開使用。
WSL 2 裝 Ubuntu，專案目錄固定放在 `/home`。
VS Code 用 Remote WSL 開專案。
Python 用 uv 或 venv 管，Node 用 nvm 或 corepack 管。
需要服務就用 Docker compose，不把資料庫亂裝在 Windows 裡。
需要本地模型時，先確認 NVIDIA Windows driver、WSL kernel、CUDA toolkit 和推理框架版本。
如果你的目標是 本地大模型推理框架 ，WSL 可以讓 vLLM、SGLang、llama.cpp、Ollama 周邊工具更接近 Linux 使用方式。如果你的目標是 Agent 開發，WSL 則可以讓 shell、瀏覽器自動化、檔案操作和套件安裝更穩。
我的判斷
Windows 不需要變成 Mac，也不需要硬裝成 Linux。最好的方式是讓 Windows 做它擅長的事：桌面、驅動、硬體管理、遊戲和日常軟體。讓 WSL 做它擅長的事：Linux 工具鏈、開源套件、容器、AI Agent 環境。
真正穩的 Windows AI Agent 工作流，不是把所有東西混在同一個地方，而是把邊界分清楚。Windows 管外層，WSL 管開發環境，Docker 管可重現服務，GPU driver 留在 Windows，專案檔案留在 Linux 檔案系統。這樣才比較不會每次換工具就重修一次環境。
延伸資源
FAQ
Windows 跑 AI Agent 一定要用 WSL 嗎？
不一定，但如果工具鏈偏 Linux、需要 Python、Node、Docker、CUDA 或多個開源套件，WSL 2 通常比純 Windows 環境穩定。
WSL 專案檔案應該放哪裡？
如果主要在 Linux 命令列工作，專案最好放在 WSL 的 `/home` 目錄，不要放在 `/mnt/c`，這樣 I/O 效能和權限行為通常比較穩。
VS Code 可以直接編輯 WSL 專案嗎？
可以。建議使用 VS Code Remote WSL，讓編輯器留在 Windows，語言工具鏈、終端機和套件環境跑在 WSL 裡。
WSL 可以用 NVIDIA GPU 嗎？
可以，但要用支援 WSL 的 Windows NVIDIA 驅動。重點是不要在 WSL 裡安裝 Linux 顯示驅動，CUDA 驅動會從 Windows 端映射進 WSL。
Docker Desktop 和 WSL 2 有什麼關係？
Docker Desktop 可以使用 WSL 2 backend，讓 Windows 上的容器工作流更接近 Linux 開發環境，適合需要複製 AI Agent 服務環境的人。
by Rain Chu 7 月 14, 2026 | AI , QWEN , 模型
NVFP4 和 MTP 最近被放在一起討論，原因很簡單：本地大模型推理開始從「能不能放進顯存」進入「怎麼把記憶體搬運成本壓到最低」的階段，Unsloth 釋出的 Qwen3.6 NVFP4 quants 主打 27B 模型可在 24GB VRAM 上運行，35B-A3B 在 B200 上可達 17,561 tok/s，並宣稱相對 NVIDIA NVFP4 quant 有 2.5 倍速度提升。
這些數字很吸引人，但不能直接翻譯成「買 RTX 5090 就一定變快」。真正該看的，是 NVFP4 和 INT4 的格式差異、MTP 如何降低推理瓶頸，以及消費級 Blackwell 現階段為什麼可能吃不到企業級 B200 的完整紅利。
先講結論
NVFP4 是 4 位元浮點量化，不是傳統 4 位元整數量化
INT4 的刻度固定，NVFP4 的浮點表示更適合保留權重動態範圍
MTP 是多 Token 預測，重點是減少每個 token 都重新搬一次權重的浪費
17,561 tok/s 是特定企業級硬體條件下的吞吐量，不是一般 RTX 50 的保證值
企業部署時，驅動、CUDA、vLLM、llama.cpp、環境變數和自動更新都可能比模型本身更容易出事
如果你之前看過我整理的 Qwen 3.6、MXFP8、NVFP4 比較 ，這篇可以當成補充版，前一篇偏選型，這篇偏底層原因和部署風險。
NVFP4 和傳統 INT4 差在哪
INT4 是 4 位元整數量化。你可以把它想成一把固定刻度的尺，每一格距離都一樣。問題是神經網路權重分布通常不是均勻的，很多重要數值會擠在接近零的位置，也會偶爾出現比較大的極端值。固定刻度很省空間，但容易犧牲細微權重差異。
NVFP4 則是 4 位元浮點量化，它仍然只用 4 位元，但用浮點格式表達數值，能用有限 bit 描述更大的動態範圍，小數值區域可以保留比較細的變化，大數值區域則用比較寬的範圍表示，這就是為什麼 NVFP4 在某些模型上可以比傳統 INT4 更接近原始權重的行為。
項目 NVFP4 傳統 INT4 數值格式 4 位元浮點 4 位元整數 刻度特性 動態範圍 固定刻度 細節保留 較能保留小數值 細微權重較易流失 硬體依賴 需要 FP4 支援與 kernel 最佳化 生態成熟 實務風險 新硬體仍看驅動成熟度 穩定但精度較受限
這裡要補一個很重要的判斷：NVFP4 不是自動贏 INT4。若硬體、驅動、kernel、推理框架都沒有最佳化，NVFP4 可能反而更慢。格式更先進，不代表你手上的卡和軟體棧已經準備好了。
MTP 為什麼會讓速度暴衝
MTP 是 Multi-Token Prediction，也就是多 Token 預測。傳統自回歸語言模型通常一次產生一個 token。每產生一個 token，都要讀取大量模型權重，再做一次運算。對大模型來說，很多時間不是花在純計算，而是花在權重從顯存搬到運算核心的路上。
MTP 的核心思路，是在一次權重讀取裡嘗試預測多個後續 token。它不是讓模型魔法般跳過推理，而是把原本每一步都要重複付出的記憶體傳輸成本攤薄。當瓶頸主要在顯存頻寬和權重搬運時，這種方式就能明顯提高吞吐量。
Reddit 原始討論裡也有人問 MTP 是否已加入，Unsloth 相關回覆指出 MTP 已經在裡面，並且有說法提到 MTP tensors 已直接內建到 quants 中。這表示使用者不只是拿到一個 NVFP4 量化權重，而是拿到帶有 MTP 加速路徑的版本。
2.5 倍速度提升要怎麼看
這次最容易被誤讀的是「2.5 倍」。Reddit 討論中有人問這個速度提升是不是相對 Q4，Unsloth 回覆脈絡指出，這個比較是相對 NVIDIA 的 NVFP4 quant，而不是拿所有 Q4 或 INT4 實作一起比較。這一點很重要，因為不同量化格式、不同框架、不同 GPU、不同 batch 和 context 設定，都會影響 token/s。
另外，35B-A3B 達到 17,561 tok/s 的數字是在 B200 這類企業級硬體條件下出現。這可以說明 NVFP4 和 MTP 的上限很高，但不代表一般 RTX 50 系列能直接複製。企業採購或本地部署，最怕把資料中心卡的極限數字誤當成桌機卡的常態表現。
為什麼 RTX 50 可能反而沒有變快
同樣叫 Blackwell，不代表所有 Blackwell 都一樣。B200 屬於資料中心路線，軟體路徑和底層 kernel 通常優先被最佳化。RTX 50 消費級卡雖然也有新架構能力，但 SM120 的軟體支援成熟度可能還沒跟上。
Reddit 討論中有人提到，消費級 Blackwell 的 NVFP4 利用率仍可能不理想，也有人實測 NVIDIA NVFP4 Qwen3.6 27B 對比原本 INT4 時，token 生成速度不但沒有提升，還有下降的案例。這些不是說 NVFP4 沒用，而是說「硬體支援」和「軟體真的最佳化」中間有一段距離。
如果你正在看 RTX 5090、5080 或 5060 Ti 類配置，不要只看 NVFP4 四個字。你要確認推理框架是否真的支援你的 GPU、驅動和 CUDA 是否符合要求、實際模型是否有對應 kernel，還要看你的工作負載是 prompt processing 重，還是 token generation 重。
企業部署最容易踩到的不是模型，而是環境
這類極限加速模型最怕直接上正式環境。逐字稿和社群討論都提到一個共通風險：推理框架和底層格式更新太快，vLLM、CUDA、驅動、模型權重、環境變數任何一層沒對上，都可能變慢甚至崩潰。
我會把部署流程拆成四步。第一步先在單機沙盒測模型能不能正常跑。第二步測固定 prompt、長上下文、工具調用和 agent loop。第三步鎖定版本，關掉正式環境自動更新。第四步再進入內部 PoC。這和我之前整理的 本地大模型推理框架選型 是同一個邏輯，速度只是其中一個指標，穩定性才決定能不能上線。
正式環境不要開自動更新
先鎖定 CUDA、driver、vLLM 或 llama.cpp 版本
不要把 B200 benchmark 直接套到 RTX 50 採購決策
工具調用和 agent 流程要單獨壓測
用 24GB VRAM 跑 27B 可以測，但不代表企業就一定該選最大模型
為什麼 9B 和 GGUF 反而更實用
當大家看到 27B 可塞進 24GB VRAM，甚至 35B-A3B 跑出極限吞吐量，很容易以為模型越大越好。但真正落地時，很多企業只需要工單分類、客服輔助、內部文件查詢、簡單自動化。這些任務未必需要 27B 或 35B。
9B 模型的價值在於部署門檻更低，可以放進 12GB 或 16GB 顯卡，還能保留更多 VRAM 給上下文和工具調用。GGUF 則讓 llama.cpp 這類本地推理路線更容易接上 CPU 或低階硬體。這也是為什麼社群一邊討論 17,561 tok/s，一邊仍然敲碗 9B 和 GGUF 版本。
對中小企業來說，我會優先問三個問題。你的資料是否需要完全本地化，你的任務是否真的需要大模型，你是否有能力維護最新 GPU kernel 和推理框架。如果答案不明確，小模型加穩定部署，通常比追逐極限跑分更務實。
我的判斷
NVFP4 和 MTP 很重要，因為它們代表本地 AI 推理正在處理真正的瓶頸：顯存容量、權重搬運、吞吐量和模型品質之間的平衡。NVFP4 解決的是低 bit 量化下如何保留更多數值動態範圍，MTP 解決的是一次只吐一個 token 帶來的記憶體傳輸浪費。
但我不會把它解讀成「RTX 玩家立刻起飛」。比較健康的看法是：資料中心硬體已經看到 NVFP4 和 MTP 的上限，消費級硬體還在等軟體棧補齊。現在要採購或部署，應該把 PoC、版本鎖定、框架支援和真實任務測試放在跑分前面。
真正值得期待的是，這些技術成熟後，27B 不再只能放在機房裡，9B 和 GGUF 也能讓更小的團隊取得足夠好用的本地 AI。極限跑分很好看，但真正改變企業日常的，通常是穩定、便宜、好維護的那一條路。
延伸資源
FAQ
NVFP4 是什麼？
NVFP4 是 NVIDIA 4 位元浮點量化格式。它和 INT4 一樣節省記憶體，但用浮點方式表達數值，較適合保留神經網路權重中的動態範圍。
NVFP4 和 INT4 最大差異是什麼？
INT4 是固定刻度的整數量化，NVFP4 是 4 位元浮點量化。前者生態成熟，後者更依賴硬體 FP4 支援和軟體 kernel 最佳化。
MTP 是什麼？
MTP 是 Multi-Token Prediction，多 Token 預測。它讓模型在一次權重讀取中嘗試預測多個後續 token，降低記憶體傳輸瓶頸，提高吞吐量。
by Rain Chu 7 月 11, 2026 | 未分類
本地部署大模型到了 2026 年，問題已經不只是「模型要選哪一個」。同一張顯卡、同一台 Mac、同一個模型，只要推理框架選錯，吞吐量、延遲、顯存使用率和維運成本都會差很多。
這也是為什麼 vLLM、SGLang、llama.cpp、MLX、Ollama 這五個工具會被放在一起比較。它們不是同一類產品的不同包裝，而是對應不同部署場景的五種答案。選對框架，比盲目追更大參數更實際。
先講結論
如果你要做高併發 API 服務，先看 vLLM。如果你在做 AI Agent、RAG、多輪工具呼叫，SGLang 很值得研究。如果你要跨平台、邊緣設備、低資源環境，llama.cpp 仍然是最靈活的選擇，如果你主要用 Apple Silicon，MLX 是最貼近硬體的路線。如果你只是想快速讓團隊或個人跑起來，Ollama 依然是最省心的入口。
五個框架的定位差異
框架 核心強項 適合場景 不適合情況 vLLM PagedAttention、Continuous Batching、高吞吐 生產 API、多使用者併發、GPU 服務 個人桌機快速試模型 SGLang RadixAttention、KV Cache 重用、結構化輸出 Agent、RAG、多輪對話、JSON 輸出 只想一鍵跑模型 llama.cpp GGUF、生態成熟、跨平台 CPU、邊緣設備、Mac、Windows、Linux、嵌入式 大規模高併發服務 MLX Apple Silicon 統一記憶體最佳化 M 系列 Mac、本地研究、Mac 開發者 NVIDIA GPU 伺服器 Ollama 安裝簡單、模型管理方便、API 友善 個人使用、團隊內部工具、快速 Demo 需要極致吞吐與深度客製
vLLM：高併發服務優先
vLLM 的代表性技術是 PagedAttention，可以把它理解成用作業系統管理記憶體的思路來管理 KV Cache，讓不同長度的請求不會浪費大量顯存，再加上 Continuous Batching，當某個請求完成後，新請求可以馬上進入批次，不必等整批全部結束。
所以 vLLM 最適合放在需要吞吐量的地方，例如公司內部模型 API、客服系統、多人同時使用的知識庫、需要穩定服務層的產品，你如果正在評估顯卡工作站，也可以對照我之前整理的 RTX PRO 6000 Blackwell 選購分析 ，因為推理框架和硬體規格要一起看才有意義。
SGLang：Agent 和 RAG 的效率選擇
SGLang 的重點不只是跑得快，而是能把複雜互動流程裡重複的上下文計算省下來，它的 RadixAttention 對多輪對話、RAG、知識庫查詢、Agent 工具呼叫很有價值，因為這些場景常常有大量共用前綴和重複上下文。
如果你的應用是「使用者問一句，模型答一句」，SGLang 的優勢不一定完全發揮。但如果你要處理多步驟推理、固定系統提示、文件檢索、JSON 格式化輸出，它會比一般推理框架更貼近 Agent 工程需求。
llama.cpp：跨平台與低資源環境的底座
llama.cpp 最大的價值是能跑在很多地方，從 Mac、Windows、Linux，到 CPU-only、小型邊緣設備、GGUF 量化模型，它提供的是一種很穩的本地推理底座，你不一定拿它做高併發生產 API，但它很適合實驗、嵌入式、離線環境、低成本部署。
如果你關心本地離線模型，之前整理過 gpt-oss 本地離線運行 ，那篇的思路也可以放到 llama.cpp 生態來看。
MLX：Apple Silicon 使用者要特別看
MLX 是 Apple Silicon 上很有意思的選擇。M 系列晶片的統一記憶體架構，讓 CPU、GPU 可以更有效率地共享資料，MLX 的價值就在於它不是把 Mac 當成一般電腦硬跑，而是更貼近 Apple 自家的硬體特性。
如果你手上是 Mac Studio、MacBook Pro 或其他 M 系列設備，MLX 適合拿來做本地研究、模型微調實驗、小型推理服務。它不是 NVIDIA 伺服器的替代品，但在 Mac 生態裡，這條路線會越來越重要。
Ollama：最容易讓人開始用
Ollama 的優勢不是極致效能，而是降低使用門檻。安裝、拉模型、切模型、提供本地 API，整個體驗很適合個人、教學、內部工具和快速 Demo。對很多團隊來說，先用 Ollama 把流程跑通，比一開始就追求 vLLM 的生產級架構更務實。
如果你要把 Ollama 放到內網或 AI Server 上，可以看 Ollama 遠端連線教學 。如果你想把開發環境成本壓低，也可以參考 LM Studio 與 Ollama 的零 API 成本開發環境 。
不要只選一個，混合部署更實際
真正成熟的部署，不一定是一個框架包打天下。比較實際的做法是分層：個人和內部 Demo 用 Ollama，Mac 研究環境用 MLX，跨平台和邊緣設備用 llama.cpp，RAG 和 Agent 後端看 SGLang，高併發正式服務再交給 vLLM。
如果你的硬體是 DGX Spark 或其他 AI Server，也可以把 DGX Spark GB10 Ollama 最佳設定 當作入口，再逐步把高併發服務拆到更專業的推理框架。
我的選型建議
個人開發者：先用 Ollama，真的需要跨平台或量化控制，再補 llama.cpp。
Mac 使用者：Ollama 做入口，MLX 做進階研究和 Apple Silicon 最佳化。
企業內部知識庫：先確認 RAG 架構和上下文重用需求，再評估 SGLang。
正式 API 服務：vLLM 是第一優先，特別是多使用者併發和 GPU 成本敏感時。
邊緣設備或離線場景：llama.cpp 的彈性仍然很難取代。
2026 年的本地 AI 部署，重點會從「能不能跑」走向「跑得是否有效率」。模型能力很重要，但推理框架決定了你花出去的硬體成本能不能真正轉成服務能力。選型時不要只看 benchmark，要看你的流量模式、硬體環境、維運能力和未來要不要接 Agent 工作流。
FAQ
本地大模型推理框架要先學哪一個？
一般使用者先學 Ollama，工程師再補 llama.cpp。需要生產服務時，再研究 vLLM 或 SGLang。
vLLM 和 SGLang 差在哪裡？
vLLM 強在高併發吞吐和生產服務，SGLang 更適合多輪對話、RAG、Agent 和重複上下文很多的流程。
Mac 使用者該選 MLX 還是 Ollama？
想快速跑模型先用 Ollama，想深入 Apple Silicon 最佳化和研究實驗，再看 MLX。
llama.cpp 還值得學嗎？
值得。它在 GGUF、量化、跨平台、CPU 和邊緣設備上仍然非常重要，是本地模型生態的底層工具之一。
by Rain Chu 7 月 8, 2026 | AI , Hermes , 模型
Ornith 35B 真正有趣的地方，不是「小模型打敗大模型」這句話本身，而是它把本地 AI 編程 Agent 這條路線重新推到桌面上：我們是不是可以把一部分 coding agent 能力，從雲端 API 搬回自己的機器？
這個問題很現實。雲端工具反應快、整合好，但 token 成本、隱私、企業程式碼外流、模型選擇權，始終卡在開發者心裡。本地模型則剛好反過來：你要自己處理硬體、速度、部署與穩定性，但換來的是成本可控、資料留在本地，以及比較完整的架構控制權。
Ornith 1.0 前一篇已經整理過核心定位，這篇換個角度：如果把 Ornith 35B 接進 Hermes 這類 Agent 工作流，它應該放在哪裡？是主控模型、任務 worker，還是只適合做某些短程工具任務？
先講結論：35B 有想像空間，但不要把 benchmark 當保證書
Ornith 35B 的吸引力在於，它不是 397B 那種多 GPU 伺服器級模型，也不是 9B 那種比較像入門測試的輕量模型。35B 落在一個很微妙的位置：高階個人工作站有機會跑，能力又足以進入 coding agent 測試。
官方數據裡，Ornith 35B 在 Terminal-Bench 2.1 拿到 64.2，SWE-bench Verified 拿到 75.6。397B 更高，Terminal-Bench 2.1 為 77.5，SWE-bench Verified 為 82.4。這些分數很漂亮，但漂亮不等於放進你的專案就穩。
模型 Terminal-Bench 2.1 SWE-bench Verified 適合觀察的方向 Ornith-1.0-9B 43.1 69.4 低成本本地測試、短程 worker Ornith-1.0-35B 64.2 75.6 本地 coding agent 實驗主力 Ornith-1.0-397B 77.5 82.4 企業級或多 GPU 私有部署
這也是為什麼我不想把它寫成「35B 擊敗雲端大模型」這種單線結論。更準確的說法是：Ornith 35B 在某些 agentic coding benchmark 和視覺/前端生成任務上很值得測，但長程任務和大型 codebase 仍要小心。
Self-Scaffolding RL 到底改變了什麼？
一般 coding agent 常見的架構，是人類工程師先寫好 harness：
什麼時候讀檔、什麼時候跑 command、失敗怎麼 retry、怎麼記憶、怎麼驗證。模型很聰明，但它通常只是被放進這套流程裡填空。
Ornith 1.0 的 Self-Scaffolding RL 想走的是另一條路：
讓模型不只學 solution rollout，也學會產生任務 scaffold。換句話說，它不只是演員，也開始學會改劇本，任務跑得好，解法和引導解法的 scaffold 都一起被獎勵；任務跑得差，兩者都會被調整。
這和 前一篇 Ornith 1.0 介紹 裡談到的「先搭工作台，再開始解題」是同一件事。對開發者來說，重點不是模型多會補 code，而是它能不能在遇到限制、錯誤、缺資料時，重新安排自己的工作流程。
Hermes 的位置：還是 harness，但已經比較動態
Hermes 在這裡比較像運行時的動態編排層。它仍然是 harness，但不是傳統那種完全寫死的腳本；它可以在任務過程中調整步驟、改工具、補資料，讓 agent 比較像真的在做一件工作，而不是只照著固定模板回答。
把 Ornith 35B 接進 Hermes 的想像是：Hermes 負責任務框架、工具調用和流程管理，Ornith 35B 負責本地推理、程式生成、局部 debug 與前端/視覺任務。這樣的分工，比「讓 35B 一個模型主控所有事情」更合理。
站上之前有兩篇 Hermes 相關內容可以放在一起看：
Hermes Agent 完整實測 和 Hermes Agent WebUI 。如果 Hermes 是工作台，Ornith 35B 就是可以被放進工作台裡的一顆本地引擎。
實測起來
Ornith 的幻覺率仍然偏高，很多 fine-tune 模型 benchmark 強，但長程任務容易歇菜；更穩的方式可能是官方模型搭配優化過的 Jinja template 來跑長程任務。
小模型非常適合做 worker，處理葉節點任務，用完即毀；但如果拿它當整個系統的主控，很可能是用錯地方，可以當作 Ornith 35B 的導入原則。
短程、明確、可驗證的任務，可以交給 35B worker。
長程規劃、多輪重構、跨大型 codebase 的任務，先不要完全放權。
需要主控決策時，最好搭配更強模型或更嚴格的 Hermes/harness。
所有結果要能重跑、能測試、能看 log，不要只看模型自我回報。
這裡的核心不是「小模型沒用」，而是小模型要放對位置，主控、規劃、長上下文記憶是白領工作；批次修小 bug、生成局部元件、跑固定格式分析，反而是本地 35B 很適合切進去的地方。
本地部署的價值：不是零成本，而是可控成本
本地跑 Ornith 35B 很容易被包裝成「零 token 成本」。這句話只說對一半。雲端 token 成本下降了，但你換成了硬體成本、電費、散熱、維護、模型部署和速度瓶頸。
真正的優勢是可控。你知道模型跑在哪裡，知道資料是否離開內網，知道長任務不會因為 token 計費一路燒上去。對需要保護程式碼或內部文件的團隊，這比單純省錢更重要。
如果你本來就在研究本地 AI 開發環境，可以延伸看 Claude Code 搭配 LM Studio 與 Ollama 的零 API 成本環境 ，以及 Mac Studio 跑大型模型的 VRAM 調整 。Ornith 35B 的問題，最後仍然會回到你的硬體、記憶體和任務型態。
我會怎麼把 Ornith 35B 放進 Hermes？
我不會一開始就讓 Ornith 35B 當整個 Hermes 系統的最高決策者。比較合理的導入方式，是先讓它做 worker。
先挑 5 到 10 個固定任務，例如小型前端元件、局部 bug 修復、測試補齊、簡單重構。
每個任務都要有明確驗證方式，例如單元測試、Playwright 截圖、lint、build。
Hermes 負責任務切分、重試策略、log 收集和失敗回報。
Ornith 35B 只處理其中一段，不直接改全專案、不直接做不可逆決策。
連續跑幾輪，看錯誤類型是否固定，再決定要不要擴大權限。
這樣的測法比較慢，但比較接近真實工程，AI Agent 的能力不是靠一個漂亮 demo 決定，而是看它能不能在可重複、可驗證、可回滾的流程裡穩定工作。
Ornith 35B 是值得測的本地引擎，不是萬能主控
Ornith 35B 最好的位置，暫時不是取代 Claude Code、Codex 或雲端大模型，而是進入 Hermes 這類 agent 工作流，成為一顆可控、可替換、可驗證的本地推理引擎。
它的優點很清楚：成本可控、資料留在本地、前端與視覺任務有亮點、自我 debug 的思路值得追。它的風險也很清楚：benchmark 不能直接代表長程任務，幻覺與錯誤累積仍然存在，小模型放錯位置會把整個 agent 工作流拖垮。
所以我會把 Ornith 35B 放進觀察名單，但會用 worker 的方式開始，而不是把整個系統交給它。這條路如果走通，本地 AI 編程的價值就不是「省 token」而已，而是開發者重新拿回 AI 架構控制權。
近期留言