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 月 12, 2026 | 未分類
LongCat 1.5 最值得注意的地方是它把音訊驅動、人物一致性、長影片穩定性和 ComfyUI 工作流串在一起，讓數字人從單段 Demo 更接近可重複生產的內容流程。
美團開源的 LongCat-Video-Avatar 1.5 建立在 LongCat-Video 基礎模型之上，官方定位是 audio-driven human video generation，也就是用音訊、文字、圖片或既有影片去驅動人物生成。對內容創作者來說，關鍵不只是嘴型同步，而是能不能穩定做出比較長的數字人片段。
LongCat 1.5 解決的是什麼問題
過去很多數字人工具看起來很驚艷，但實際用在長片段時會遇到幾個老問題：嘴型不穩、人物身份漂移、動作重複、背景抖動、分段接不上，LongCat 1.5 的官方 model card 強調幾個方向：用 Whisper-Large 取代 Wav2Vec2 作為音訊編碼器，改善嘴型與語音動態，並強化長影片生成時的身份一致性和時間穩定性。
它支援的任務也不只一種，AT2V 是 Audio-Text-to-Video，適合用音訊和文字描述生成片段，ATI2V 是 Audio-Text-Image-to-Video，可以用參考圖片維持角色形象，Video Continuation 則比較接近延續既有影片，讓後續動作和語音繼續往下生成。
為什麼 RunningHub 工作流有用
LongCat 1.5 本身是模型，真正要變成創作者可用的工具，還需要工作流。這也是 RunningHub 和 ComfyUI 的價值所在。RunningHub 可以把複雜節點封裝成比較容易執行的流程，讓使用者不一定要在本機把所有依賴、模型、節點和顯卡環境都裝好。
如果你還不熟 RunningHub，可以先看我之前整理的 RunningHub 是什麼？把 ComfyUI 工作流變成 AI 內容生產平台 ，這次 LongCat 1.5 的重點就是把「單段生成」改成「循環工作流」，讓多段音訊和多段片段可以自動往下跑，不必每 4 秒就手動複製節點、改連線、重新拼接。
循環工作流的核心概念
實作數字人長片段時，最麻煩的往往不是單次生成，而是分段，假設每段產生 4 秒，20 秒就需要 5 段，30 秒就需要更多段。如果每一段都手動複製節點和連線，工作流會變得又長又難維護。
比較合理的做法是讓工作流自動按時間切段，再把每段送進 LongCat 1.5 生成。這裡有幾個重要參數：
音訊起始時間：決定從第幾秒開始讀音訊。
生成時長：決定每段處理幾秒，實務上可以略大一點，避免音訊尾端被切掉。
幀率：要和模型採樣規則配合。
尺寸：工作流裡常見長邊 1024，也可以提高，但成本會上升。
參考圖和 prompt：決定人物外觀、場景、動作與一致性。
其中「4n+1」這個規則很重要。如果秒數乘上幀率後不是符合模型要求的幀數，採樣器可能直接報錯，好的工作流會用數學節點自動修正幀數，避免使用者每次手算。
設備需求怎麼看
很多人第一個問題會是：本機能不能跑？答案要拆開看，官方安裝方式需要 Python 3.10、CUDA 版 PyTorch、FlashAttention、ffmpeg、librosa 和模型權重。這代表如果要本地完整跑起來，最好有 NVIDIA GPU 和足夠顯存，不然體驗會很痛苦。
RunningHub 的思路則是把算力放到雲端，說明欄提到可以在 RTX 4090 上運行，這對一般創作者比較友好，因為你不用先處理 CUDA、依賴衝突和顯存不足。缺點是需要依平台計費，還要注意素材隱私和商用內容的授權風險。
如果你對本地 AI 影片工作流有興趣，可以對照 OpenMontage 本地部署實測 。如果你的重點是語音和角色互動，也可以延伸看 Hugging Face speech-to-speech 本地即時語音 Agent ，思路都會回到同一件事：模型、音訊、工作流和算力要一起設計。
提示詞要寫得比想像中更細
LongCat 1.5 官方也提醒，長而具體的 prompt 通常比短句更穩。不要只寫「一位女生在說話」。更好的寫法是把人物外觀、動作、服裝、表情、場景都寫清楚，例如：一位長黑髮女性，穿白色襯衫，坐在明亮咖啡館裡，微笑並自然說話。
如果要做商用級數字人，我會把 prompt 拆成四層：
角色：年齡、髮型、服裝、表情、姿態。
場景：室內或戶外、光線、背景、鏡頭距離。
動作：說話、微笑、點頭、手勢、是否走路。
限制：不要誇張表情、不要手部變形、不要背景閃爍、不要換臉。
如果你還需要語音來源，可以搭配 Qwen3-TTS 這類音色設計工具 ，先把聲音品質穩住，再進入數字人生成。音訊不好，嘴型同步再強也很難救。
LongCat 1.5 適合誰
使用者 適合程度 原因 短影音創作者 高 可以把固定角色、音訊和場景變成批量內容。 電商和品牌團隊 高 可做商品介紹、導購、活動宣傳和多語版本。 本機 AI 玩家 中 模型開源，但完整環境和顯卡需求不低。 只想快速試效果的人 高 用 RunningHub 工作流比本地安裝更快。 企業敏感資料場景 中 要評估素材隱私、雲端上傳和合規問題。
如果只是做一張照片講話，過去已經有很多工具可以完成，例如我之前整理過的 Hallo AI 數字人 ，LongCat 1.5 更值得看的地方，是它開始處理更長、更穩、更可工作流化的數字人生成。
注意事項
第一，雲端工作流很方便，但素材上傳前要確認隱私。客戶聲音、真人肖像、商業腳本，都不應該隨便丟到不熟的平台裡。
第二，數字人看起來自然，不代表可直接商用。要確認聲音、人物肖像、參考圖、背景素材和平台條款，尤其是用真人形象時更要小心。
第三，循環工作流能提高效率，但也會放大錯誤。如果第一段人物已經歪掉，後面自動跑再多段也只是把錯誤放大。比較穩的做法是先做 4 到 8 秒測試，確認嘴型、動作和人物一致性，再放大到長片段。
最後
LongCat 1.5 代表數字人工作流正在從單點工具走向內容生產線。模型本身強調嘴型、長影片穩定和身份一致性，RunningHub 工作流則把操作門檻往下壓。對創作者來說，現在最重要的能力不是只會按生成，而是懂得設計音訊、角色、分段、幀率和工作流。
如果你想快速驗證，先用 RunningHub 工作流跑一段短音訊。如果要做可控的長片或商用內容，再回頭研究 ComfyUI 節點、官方 Hugging Face 權重和本地部署成本。這樣比較不會一開始就被環境和顯卡需求卡住。
FAQ
LongCat 1.5 是什麼？
LongCat 1.5 是美團開源的音訊驅動數字人模型，支援用音訊、文字、圖片或既有影片生成數字人片段。
LongCat 1.5 可以本地部署嗎？
可以，但官方安裝需要 CUDA 版 PyTorch、FlashAttention、ffmpeg、librosa 和模型權重，建議有 NVIDIA GPU 再嘗試。
為什麼幀率要注意 4n+1？
部分採樣流程要求輸入幀數符合特定規則，如果秒數乘幀率後不符合，採樣器可能報錯。工作流通常會用數學節點自動修正。
by Rain Chu 7 月 8, 2026 | Agent , AI , 語音合成 , 語音辨識
Hugging Face 的 speech-to-speech 真正有趣的地方，不只是「本地 AI 語音聊天」這句話，而是它把即時語音 Agent 拆成一條清楚的工程管線：VAD 偵測你什麼時候開始和結束說話，STT 把語音轉成文字，LLM 產生回應，TTS 再把文字變回聲音。
這條路線的價值很直覺：如果你不想把麥克風聲音、私人對話、公司資料一路送到雲端，那就把語音 Agent 搬回自己的機器。代價也很明顯：你要處理 Python、FFmpeg、CUDA、模型下載、本地 LLM server、TTS 後端、瀏覽器端 WebSocket。這不是「安裝一個 App 就結束」的工具。
如果你之前看過 VoxelCPM 本地 TTS ，這篇可以當成下一步：TTS 只是讓 AI 開口，speech-to-speech 則是把「聽、想、說」接成一個即時循環。
先講結論：它不是語音模型，而是一條可替換的語音 Agent 管線
huggingface/speech-to-speech 的 README 把架構講得很清楚：這是一條低延遲、模組化的 voice-agent pipeline，順序是 VAD → STT → LLM → TTS，並且透過 OpenAI Realtime-compatible WebSocket API 對外提供服務。
也就是說，你可以把支援 OpenAI Realtime 協議的 client 指到本機 server。
這個設計比單純做一個 demo 更有意思，因為每一段都能換。
STT 可以用 Parakeet、Whisper、Faster Whisper、MLX Whisper 或 Paraformer；LLM 可以接 OpenAI-compatible provider，也可以接 vLLM、llama.cpp、llama-server；TTS 可以用 Qwen3-TTS、Kokoro、Pocket TTS、ChatTTS 或 MMS TTS。
換句話說，它的重點不是某個模型最強，而是把語音 Agent 做成可插拔架構。
這和 OpenWork / OpenCode 工作台 的方向有點像：真正可長期使用的 AI 工具，不應該只綁死在單一供應商或單一模型。
Speech-to-speech 和傳統語音翻譯有什麼差別？
Hugging Face Audio Course 裡對 speech-to-speech translation 的說明很適合拿來釐清概念。
傳統機器翻譯是文字到文字，speech-to-speech 則是語音到語音。最常見的做法是串接：先把語音轉成文字，再做翻譯或生成，最後合成語音。
它也提醒一個很重要的問題：管線越長，錯誤越會累積，延遲也越高。
ASR 認錯一個字，後面的 LLM 可能照著錯字理解；LLM 回答太長，TTS 就要等更久；TTS 聲音不自然，最後體驗還是會掉下來。
所以本地即時語音 Agent 的關鍵不是只看「能不能講話」，而是看四件事：
語音辨識是不是準，尤其是中文、口音、背景噪音。
LLM 回應是不是夠快，不要讓人等到出戲。
TTS 聲音是不是自然，長時間聽會不會疲勞。
整條管線的延遲是不是穩定，而不是偶爾順、偶爾卡。
官方預設路線：先跑起 realtime server
官方 quickstart 很短：
pip install speech-to-speech
export OPENAI_API_KEY=...
speech-to-speech ws://localhost:8765/v1/realtime
預設路線會用本地 STT、本地 TTS，再把 LLM 接到 OpenAI-compatible API。你如果想讓 LLM 也留在本機，可以用 llama.cpp 啟動本地模型 server，再把 `responses_api_base_url` 指到本機。
speech-to-speech \
--model_name "ggml-org/gemma-4-E4B-it-GGUF" \
--responses_api_base_url "http://127.0.0.1:8080/v1" \
--responses_api_api_key "" Ollama 遠端連線 和本地 OpenAI-compatible server 的設定很重要：語音只是入口，真正回答問題的是後面的 LLM。Windows 實作路線：不是難，是零件很多
核心流程可以簡化成這樣：
裝 Python 3.11、Git、FFmpeg。
建立 `C:\s2s` 之類的資料夾，開 venv。
安裝 `speech-to-speech`。
用 llama.cpp 跑本地 Qwen 模型，開在 `http://127.0.0.1:8080/v1`。
啟動 speech-to-speech，把 STT 指到 Whisper、LLM 指到本地 server、TTS 指到 Qwen3-TTS。
開網頁 client，WebSocket 指到 `localhost:8765`。
這裡最容易踩坑的是 FFmpeg 和 winget。留言裡有人遇到 `winget` 找不到，這通常代表 Windows App Installer / winget 沒裝好，或 PowerShell 環境找不到它。這時候不要卡在同一條命令，可以改成手動下載 FFmpeg，或先修好 winget，再重新開 PowerShell。
架構表：每一段都可以替換，但每一段也都會出事
階段 作用 常見選擇 容易卡住的地方 VAD 判斷使用者何時開始/停止說話 Silero VAD 背景噪音、切句太早或太晚 STT 語音轉文字 Parakeet、Whisper、Faster Whisper 中文辨識、口音、GPU/CPU 速度 LLM 理解問題並產生回應 OpenAI-compatible API、llama.cpp、vLLM、Ollama 類服務 延遲、上下文長度、模型能力 TTS 文字轉語音 Qwen3-TTS、Kokoro、Pocket TTS、ChatTTS 聲音自然度、CUDA wheel、中文品質 Client 麥克風輸入與播放 Realtime WebSocket client、網頁呼吸球介面 瀏覽器權限、WebSocket 位置、服務啟動順序
這張表就是我對本地語音 Agent 的看法：模組化很香，但你不能只看成功 demo 任一段延遲太高、模型太大、依賴裝錯、WebSocket 指錯，都會讓整體體驗掉下來。
4GB 顯存、4090、CPU：期待值要分開看
如果你只是想體驗，本地小模型加 CPU/GPU 混跑可以試；如果你想每天使用，就要認真看顯卡、VRAM、記憶體、模型大小與量化格式。這部分可以搭配 AI 工作站顯卡選購 那篇看，因為語音 Agent 不是只吃一個模型，而是一整條 pipeline。
本地部署值不值得？
安裝太複雜、Python 依賴一直重裝、免費雲端語音也能用、中文場景不一定比微信等現成工具舒服。
我會這樣判斷：
如果你只想偶爾語音聊天 ，雲端 App 更省事。如果你在意隱私、離線、可控模型 ，本地 speech-to-speech 才有意義。如果你要接自己的 Agent 或自動化流程 ，OpenAI Realtime 相容 API 很有價值。如果你不想處理依賴 ，等整合包或 Docker / 一鍵腳本會比較舒服。
有留言建議做整合包，把 Python、虛擬環境、依賴、模型檔都打包好。這個方向很務實。語音 Agent 要走向一般使用者，最重要的可能不是模型再強一點，而是安裝流程少掉一半。
接進 Hermes、OpenWork 或自己的 Agent：語音只是入口
有人問如果部署在 Hermes 裡，是不是就不用打字了。方向是對的，但要分清楚：speech-to-speech 解決的是語音輸入與語音輸出，Agent 真正能不能工作，還要看後面的工具調用、上下文、記憶、權限與任務執行。
也就是說，語音不是 Agent 的全部，只是更自然的控制入口。你可以想像之後用語音叫本地 Agent 幫你查資料、改檔案、跑腳本、操作工作流，但這需要像 OpenWork 或 Hermes Agent 這類工作台或 runtime 來承接任務。
真正有用的組合會是：speech-to-speech 負責「聽和說」，Agent runtime 負責「做事」，本地 LLM / 工具 / MCP 負責「連到你的資料和系統」。語音只是讓人更容易下指令，不能替代完整的任務架構。
資源整理
本地即時語音 Agent 很香，但現在還偏工程師玩具
speech-to-speech 讓本地語音 Agent 的架構變得很清楚：你可以把 VAD、STT、LLM、TTS 串起來，對外提供 OpenAI Realtime 相容 API，再用網頁或其他 client 連進來。這條路很有想像空間，尤其適合隱私敏感、離線使用、機器人、客服、語言練習、自建 AI 助手。
但我不會把它包裝成人人都該裝。現階段它還需要處理太多環境問題，Windows 下尤其明顯。真正適合的人，是願意花時間把本地模型、音訊依賴、GPU、WebSocket 和 Agent runtime 串起來的人。
一句話總結：本地即時語音不是為了取代手機上的語音助手，而是為了把「能聽、能想、能說」這個入口，接到你自己的模型、資料和工作流上。這件事如果跑順，會比單純聊天更有價值。
FAQ
speech-to-speech 是什麼？
speech-to-speech 是 Hugging Face 的開源語音 Agent 管線，透過 VAD、STT、LLM、TTS 四個階段，把使用者語音轉成模型回應，再合成語音輸出。
它可以完全本地運行嗎？
可以，但需要把 STT、LLM、TTS 都換成本地後端，例如 Whisper、llama.cpp 或其他 OpenAI-compatible 本地 LLM server，以及 Qwen3-TTS 等本地語音合成模型。
為什麼不用雲端語音助手就好？
如果只是日常聊天，雲端語音助手更省事。本地方案的價值在於隱私、離線、可控模型、可接自有資料與 Agent 工作流。
by Rain Chu 7 月 6, 2026 | AI , 模型
Ornith 1.0 最值得注意的地方，不是又多了一個會補程式碼的開源模型，而是它把「寫程式」往前推了一步：先替任務搭工作流程，再開始產生解法。
這個差別很關鍵。很多 AI 寫程式失敗，不是模型不會寫函式，而是前面的任務拆解、資料來源、依賴安裝、API key、驗證方式沒有想清楚。Ornith 1.0 想解的正是這一層問題：讓模型先建立 scaffold，也就是一套能引導任務完成的工作台。
Ornith 1.0 是什麼？
Ornith 1.0 是 DeepReinforce 推出的開源 Agentic Coding 模型系列，官方定位是 self-improving open-source models for agentic coding。它不是單一模型，而是一整組不同大小與格式的模型家族。
9B Dense：比較適合本地測試與資源有限的部署。
31B Dense：官方頁列入模型家族，偏向更高能力的 dense 版本。
35B MoE：能力與資源需求往上推，Ollama 也提供 35B 版本。
397B MoE：旗艦級模型，更偏多 GPU 伺服器與研究測試場景。
官方資料提到，Ornith 1.0 建立在 Gemma 4 與 Qwen 3.5 這類 pretrained model 之上，並針對 coding agent 任務做後訓練。Hugging Face collection 目前列出 9B、35B、397B，以及 GGUF、FP8 等不同格式；GitHub README 也把這些版本整理成可部署的 checkpoint 清單。
如果你原本就在關注 Ollama + Qwen 3.6 的模型選擇 ，Ornith 1.0 可以放在同一條線上看：它不是單純聊天模型，而是更偏「本地程式代理」的方向。
真正的重點：先搭 scaffold，再寫程式
Ornith 1.0 的訓練思路，可以用一句話理解：模型不只學會產生 solution rollout，也學會產生帶領自己完成任務的 scaffold。
在傳統寫程式模型裡，使用者丟一個需求，模型很容易直接進入「產生程式碼」模式。但真實的小工具開發通常不是這樣。你要先知道資料從哪裡來、需不需要註冊 API、有哪些套件依賴、結果要怎麼展示、最後要怎麼驗證。
例如做一個五天天氣預報工具，如果一開始選 OpenWeather，後面才發現需要 API key，任務就會卡住。比較好的 agent 行為是回頭調整方案，改找不需要 API key 的資料來源，重新整理資料結構與 UI 呈現。Ornith 1.0 想訓練的，就是這種「條件變了，工作流程也跟著改」的能力。
這也解釋了為什麼它比較適合拿來觀察 AI agent，而不是只拿幾題補全測試就下結論。對程式代理來說，會寫一段 function 只是基本盤；能不能拆任務、改策略、補驗證，才是進入真實專案後的差距。
Benchmark 可以看，但不要只看跑分
官方 benchmark 涵蓋 Terminal-Bench 2.1、SWE-bench Verified、SWE-bench Pro、SWE-bench Multilingual、NL2Repo、SWE Atlas 等任務。下面先抓兩個比較容易理解的指標來看：
模型 Terminal-Bench 2.1 SWE-bench Verified 定位 Ornith-1.0-9B 43.1 69.4 本地測試與輕量部署 Ornith-1.0-35B 64.2 75.6 工作站或較高資源環境 Ornith-1.0-397B 77.5 82.4 多 GPU 伺服器與旗艦能力
9B 的意義不在於它能不能打贏所有大模型，而是它讓本地端測試變得比較實際。35B 與 397B 則是觀察這套 scaffold 訓練方法能不能隨模型規模放大的重點版本。
不過跑分仍然只能當入口。Coding agent 的實際體驗，還會被上下文管理、工具調用、檔案系統安全邊界、任務記憶、互動方式影響。這也是為什麼 Claude Code、Codex 這類工具難以只用「模型分數」比較。它們拼的是整套工作流，不只是底層模型。
如果你想把本地模型接進開發工作流，可以延伸看這篇 Claude Code 搭配 LM Studio 與 Ollama 的零 API 成本開發環境 ，它比較接近 Ornith 1.0 可能落地的位置。
怎麼在 Ollama 與 Hugging Face 上取得 Ornith 1.0？
目前最直接的入口有四個：
Ollama 頁面列出 9 個模型項目，並標示 `ornith:latest`、`ornith:9b` 約 5.6GB、`ornith:35b` 約 21GB，context window 皆為 256K。最簡單的測試方式是：
ollama run ornith
ollama run ornith:9b
ollama run ornith:35bGitHub README 也提供從 Hugging Face GGUF 直接跑的方式：
ollama run hf.co/deepreinforce-ai/Ornith-1.0-9B-GGUF如果你要讓其他電腦連到同一台 Ollama 伺服器，可以搭配 Ollama 遠端連線教學 來設定 API endpoint。Ornith 1.0 這類程式模型，通常會更適合放在可以被 IDE、CLI agent 或自動化腳本呼叫的環境裡。
Reward hacking 是這類模型一定要面對的問題
讓模型自己產生 scaffold，能力會變大，風險也會變大。最典型的問題是 reward hacking：模型不是好好完成任務，而是想辦法鑽驗證器的空子。
在程式任務裡，這可能長得很實際：偷看測試檔、硬寫 expected output、碰不該碰的驗證腳本，或把環境改到看起來通過。官方資料提到的防護思路，是把外層信任邊界固定住，讓環境、工具表面與測試隔離不能被模型改；再用規則監控與模型複查，把可疑方案篩掉。
這一段其實比跑分更重要。因為 agentic coding 的核心不是一次回答，而是連續操作。模型能操作越多工具，就越需要清楚的權限邊界與可追蹤紀錄。這也是我會把 Ornith 1.0 放在「值得測試的開源方向」，而不是「馬上取代成熟 coding agent」的位置。
如果你對這種自學型 agent 架構有興趣，可以接著看 Claude Memory 與 Dreaming：自學型 AI Agent 的下一步 ，兩者都在處理一個相近問題：AI 不只是回答，而是如何在任務中累積策略。
我會怎麼選版本？
如果只是想先試試看，從 `ornith:9b` 開始最合理。它的下載量、顯存壓力與啟動成本都比較低，也比較適合拿來測「任務拆解」是不是真的有感。
如果你有比較強的工作站，`ornith:35b` 才值得進入第二輪測試。它的定位更接近可用的 coding agent 模型，但也更需要良好的硬體與服務設定。若你的目標是跑大型專案、長上下文、多步驟任務，可以把 35B 放進候選清單。
397B 則不建議一般使用者一開始就碰。它更像是研究、企業或多 GPU 伺服器環境要評估的版本。對多數人來說，先把 9B/35B 放進 Ollama 或 OpenAI-compatible endpoint，測試能否穩定完成真實任務，會比追最大參數更有價值。
想把模型接進工具鏈，也可以參考 OpenCode 如何使用本地端模型 。Ornith 1.0 真正有趣的地方，正是在「本地模型 + coding agent + 可控工具」這個交會點。
結論：值得追，但要用真實任務測
Ornith 1.0 的亮點不是單一 benchmark 數字，而是它把開源程式模型推向「會先規劃工作台」的方向。這對本地 AI 編程很重要，因為真實任務往往不是只補一段 code，而是資料來源、依賴、限制、驗證與修正一起出現。
短期內，我會先看兩件事：第一，9B GGUF 在一般工作站或高階個人電腦上能不能穩定跑；第二，35B 在多步驟專案裡，能不能真的比一般 coding model 更會拆任務與自我修正。
如果這兩件事站得住，Ornith 1.0 就不只是又一個開源模型，而是本地 AI coding agent 往前走的一個重要訊號。
FAQ
Ornith 1.0 是什麼？
Ornith 1.0 是 DeepReinforce 推出的開源 Agentic Coding 模型系列，重點不是只產生程式碼，而是讓模型先為任務建立 scaffold，包含拆解步驟、工具選擇、驗證方式與錯誤處理，再產生解法。
Ornith 1.0 有哪些版本？
官方釋出 9B Dense、31B Dense、35B MoE 與 397B MoE 等版本；Hugging Face collection 中也包含 GGUF 與 FP8 版本。Ollama 頁面目前列出 ornith:9b 與 ornith:35b，兩者皆標示 256K context window。
一般使用者應該先跑哪個版本？
如果目標是本地測試，建議先從 9B 或 9B GGUF 開始；35B 比較適合顯存較充足的工作站。397B 更偏向多 GPU 伺服器環境，不是一般個人電腦的起手式。
Ornith 1.0 可以取代 Claude Code 或 Codex 嗎？
目前比較合理的看法是「值得測試的開源方向」，不是直接取代成熟工具。
Claude Code、Codex 這類產品還包含上下文管理、工具調用、專案理解、安全邊界與互動體驗，模型本身只是其中一層。
Ornith 1.0 怎麼用 Ollama 跑？
Ollama 官方頁面提供 `ollama run ornith`、`ollama run ornith:9b` 與 `ollama run ornith:35b`。
如果要直接使用 Hugging Face 的 GGUF，也可以參考 GitHub README 裡的 `ollama run hf.co/deepreinforce-ai/Ornith-1.0-9B-GGUF`。
by Rain Chu 6 月 6, 2026 | AI , 圖型處理
2026 年最受矚目的 AI 繪圖模型之一，莫過於 Ideogram 團隊正式釋出的：
Ideogram 4
這是 Ideogram 首次公開模型權重（Open Weight），也是目前開源陣營中，在：
文字生成（Text Rendering）
海報設計
品牌廣告
排版控制
JSON 結構化提示詞
官方 資料顯示，Ideogram 4 採用 9.3B 參數的單流 Diffusion Transformer（DiT）架構，並支援原生 2K 圖像生成。
本篇將帶你使用 ComfyUI，在本機部署 Ideogram 4。
系統需求
官方模型共有兩個版本：
版本 量化 Ideogram 4 FP8 品質最佳 Ideogram 4 NF4 VRAM需求較低
目前 ComfyUI 官方整合版本主要使用：
其中 FP8 畫質最佳。
第一步：下載模型
ComfyUI 專用模型
官方：
Comfy-Org Ideogram-4
原始模型：
Ideogram 4 FP8 官方 模型
第二步：放置模型檔案
依照官方說明建立目錄。
ComfyUI
│
├─ models
│ ├─ diffusion_models
│ │ ├─ ideogram4_fp8_scaled.safetensors
│ │ └─ ideogram4_unconditional_fp8_scaled.safetensors
│ │
│ ├─ text_encoders
│ │ └─ qwen3vl_8b_fp8_scaled.safetensors
│ │
│ └─ vae
│ └─ flux2-vae.safetensors 第三步：了解每個模型用途
ideogram4_fp8_scaled
主模型
負責：
ideogram4_unconditional_fp8_scaled
CFG 引導模型
負責：
提升細節
強化 Prompt Follow
改善品質
官方建議兩個模型一起使用。若只載入主模型雖可運作，但畫質會下降。
qwen3vl_8b_fp8_scaled
文字編碼器
負責：
Prompt 理解
JSON 理解
空間推理
海報版面配置
flux2-vae
VAE 解碼器
負責將 Latent 轉換成圖片。
第四步：更新 ComfyUI
Ideogram 4 需要最新版本的 ComfyUI。
更新方式：
或：
官方於 Day-0 即已原生支援 Ideogram 4。
第五步：載入官方 Workflow
ComfyUI 官方已提供範例工作流。
建議直接從：
Comfy Blog
下載 Workflow 。
基礎工作流架構
Prompt
↓
Qwen3-VL Encoder
↓
Ideogram 4
↓
Sampler
↓
Flux VAE Decode
↓
Save Image 第六步：第一張圖片
測試 Prompt：
A futuristic cyberpunk city at night,
neon signs in Chinese,
cinematic lighting,
ultra detailed,
high contrast,
8k photography 生成尺寸：
推理模式：
第七步：體驗 JSON Prompt
Ideogram 4 最大特色就是：
Structured JSON Prompt
官方模型訓練時即使用 JSON Caption。
範例：海報設計
{
"scene_summary": "Professional technology conference poster",
"background": {
"description": "Modern convention center stage with blue ambient lighting, large LED screen, clean professional environment"
},
"style": {
"description": "Corporate marketing design, professional conference poster, clean typography, premium branding, modern layout"
},
"objects": [
{
"description": "Conference stage",
"bbox": [100, 150, 900, 850],
"colors": ["#0A2540", "#1E88E5", "#FFFFFF"]
}
],
"text_elements": [
{
"text": "AI SUMMIT 2026",
"bbox": [150, 120, 850, 260],
"style": "Large bold white sans-serif title"
},
{
"text": "Future of Artificial Intelligence",
"bbox": [180, 280, 820, 350],
"style": "Medium white subtitle"
},
{
"text": "Taipei International Conference Center",
"bbox": [180, 1050, 820, 1120],
"style": "Small white footer text"
}
]
} Bounding Box 控制
可直接指定位置。
{
"text_elements":[
{
"text":"SALE 50%",
"bbox":[100,100,500,300]
}
]
} 座標範圍：
原點：
這是目前 FLUX 與 Stable Diffusion 所不具備的能力。
色彩盤控制
品牌設計超級好用。
{
"color_palette":[
"#FF6600",
"#FFFFFF",
"#000000"
]
} 官方支援：
與 FLUX 比較
FLUX 強項
Ideogram 4 強項
Logo
海報
Banner
電商素材
排版設計
中文文字生成
若你是：
Ideogram 4 很可能比 FLUX 更適合。
結論
Ideogram 4 不只是另一個 AI 繪圖模型。
它最大的創新在於：
把 Prompt 從自然語言升級為結構化設計規格。
透過：
Qwen3-VL
Diffusion Transformer
JSON Prompt
Bounding Box
Color Palette
使用者終於可以像操作 Figma 一樣控制 AI 生成內容。
對於需要：
海報設計
品牌素材
Banner 製作
AI Agent 自動產圖
的開發者來說，Ideogram 4 是目前最值得研究與部署的開源模型之一。
近期留言