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 月 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 月 7, 2026 | 未分類
✅ VoxelCPM vs. 雲端服務實測對比摘要
語音自然度： ★★★★☆（本地部署中文方言表現更佳）。安裝速度&執行穩定性： ✅ 整合包版本極易上手。一次 setup，全部完成！（Windows/Mac 通用）擴展性： 只要 CPU 核心足夠即可批量處理多線程聲音任務！雲端服務更依賴網路狀態與排程延遲。
VoxelCPM 的本地化部署模式，讓 「完全離線語音合成」 這個概念不再是科幻故事。尤其在隱私敏感企業與高頻率應用場景下，它可以節省可觀 API 成本。
5秒複製你的聲音：零門檻本地 TTS 工具 VoxelCPM 實戰指南＋完全離線部署
想不想只需錄短短幾秒鐘的聲音，就能在任何情境下「完美復刻」你自己的語音？現在，不需要昂貴的雲端服務費，也能在自己的電腦上實現這個需求。透過 VoxelCPM （或稱 VoxCPM），您可以直接在本地端訓練專屬的 TTS（文字轉語音）模型，支援 30 種語言與多種方言。
⚡ 為什麼需要本地端 TTS？
隱私保護： 敏感數據（如客戶錄音、個人日誌）不需要上傳到雲端伺服器。零月費門檻： 一次安裝，永不再收 API 費用。對於需要長期大量生成語音的專案來說，省下的費用驚人。完全自定義： 只要幾秒鐘的錄音素材，即可客製化出屬於您的專屬音色！
🔊 VoxelCPM 核心優勢與實測比較
項目 VoxelCPM（本地） 雲端服務 （AWS Polly 等）
數據隱私 極高 （資料全在本地）需要上傳到第三方伺服器端
持續月費 $0 完全免費開源！
按量計費，長期使用成本驚人
方言支援 30+種語言與豐富台語粵語等方言兼容！
標準語音為主，方言受限嚴重
設置難度 中等（Python 或整合包環境）；一鍵部署已極簡化。
低（只需呼叫 API Key 即可）
🛠️ VoxelCPM 實戰教學：快速上手！
步驟一：下載環境 GitHub /AI探索与发现 頻道或官方整合包取得。目前支援 Windows/Mac/Python 虛擬環境，安裝過程已經將複雜依賴性全部打包！pip install -r requirements.txt
步驟二：準備你的聲音素材 (只需 5~10 秒)「今天天氣真好」 的語音。語速正常、環境安靜即可。
步驟三：開始訓練與生成！(One-Click)
🔊特別注意：影片教學中強調的「方言」支援能力。 無論是台語還是其他特定區域口音，VoxelCPM 皆能精準捕捉聲音的特徵變化！
✅ VoxelCPM vs. 雲端服務實測對比摘要
語音自然度： ★★★★☆（本地部署中文方言表現更佳）。安裝速度&執行穩定性： ✅ 整合包版本極易上手。一次 setup，全部完成！（Windows/Mac 通用）擴展性： 只要 CPU 核心足夠即可批量處理多線程聲音任務！雲端服務更依賴網路狀態與排程延遲。
VoxelCPM 的本地化部署模式，讓 「完全離線語音合成」 這個概念不再是科幻故事。尤其在隱私敏感企業與高頻率應用場景下，它可以節省可觀 API 成本。
參考資料
論文
模型
by Rain Chu 4 月 15, 2026 | 未分類
🌍 Google Nano Banana 18 招實戰玩法
1️⃣ 環遊世界攝影（不用出國）
把人物丟進巴黎、東京、冰島
2️⃣ 多主體合成（超強合成能力）
3️⃣ 首尾幀影片生成
只給「開始 + 結束」
4️⃣ 無限 P 圖（換臉＋換裝＋換場景）
👉 一張圖變 100 張
5️⃣ 電商產品圖（Home Canvas）
👉 白底 → 高質感品牌圖
6️⃣ 火柴人 → 動漫影片
草圖 → 完整動畫
7️⃣ 地圖視覺推理
AI 看地圖 → 推理現場畫面
8️⃣ 遊戲人物設計
👉 RPG / 科幻 / 二次元
9️⃣ 海報設計置換
👉 改人物 / 改產品 / 改標題
🔟 真實手辦生成
👉 角色 → 手辦展示圖
1️⃣1️⃣ AI 影片生成
👉 靜態圖 → 動態影片
1️⃣2️⃣ 虛擬形象設計
👉 打造你自己的 AI 分身
1️⃣3️⃣ LINE 貼圖設計
👉 一鍵生成貼圖包
1️⃣4️⃣ 食物美化（美食攝影）
👉 讓普通食物變米其林等級
1️⃣5️⃣ 食物拆解（視覺推理）
👉 漢堡 → 分解食材
1️⃣6️⃣ 一張圖說故事
👉 一張圖就能講完整故事
1️⃣7️⃣ 視角轉換（鏡頭改變）
👉 正面 → 空拍 / 側拍
1️⃣8️⃣ AI 創意無限延伸
👉 所有創意都可以延伸
🧩 核心能力總結
Nano Banana 的強大在於：
🧠 視覺理解（不是只生成）
🔄 可重組（多圖融合）
🎬 動態生成（圖片 → 影片）
🎨 風格自由轉換
👉 已經不是工具，而是「創作引擎」
🚀 適合誰用？
電商賣家（商品圖）
設計師（海報 / 品牌）
自媒體（短影片）
遊戲開發（角色設計）
AI 創作者（虛擬人 / 貼圖）
🔗 官方入口
👉 Google AI Studio
by Rain Chu 8 月 7, 2025 | 未分類
gpt‑oss 教學，可以在 16 GB 筆電上免費使用 OpenAI 的開源 gpt‑oss‑20B / 120B GPT 模型，2025/8/5 OpenAI 終於推出的 gpt‑oss （包括 gpt‑oss‑20B 與 gpt‑oss‑120B）簡直是福音！這些開源模型支持在具備足夠資源的電腦上離線運行，完全不需要存取 OpenAI 伺服器，既保護資料隱私，又零使用量限制。
GPT‑OSS 模型概覽
gpt‑oss‑120B gpt‑oss‑20B
兩者皆採用 Mixture-of-Experts 架構（MoE），對每個 token 只啟用一部分參數，有效節省記憶體與運算資源。
為什麼它值得推薦？
真·免費 & 無使用限制 ：完全無需訂閱、不計費，也無 API 次數限制。離線運行，資料更安全 ：不連網執行，所有運算都在本地完成，隱私無虞。高效能與實用性並重 ：gpt‑oss‑20B 適合筆電、家庭工作站；gpt‑oss‑120B 則適用於高性能 GPU 主機。
如何開始在本地使用 GPT‑OSS？
以下以 Ollama 為例，快速上手流程：
安裝 Ollama （適用於 Windows / macOS / Linux）。使用指令下載模型：ollama pull gpt‑oss:20b
啟動模型聊天介面：ollama run gpt‑oss:20b
要完全離線，也可在 Ollama 設定中啟用「飛航模式」。
ollama pull gpt‑oss:20b # 適合 16 GB 裝置
ollama pull gpt‑oss:120b # 適用於 GPU ≥ 60 GB 設備
對部分硬體較低端的使用者，也可透過像 llama.cpp 加上 GGUF 精簡版模型運行，建議至少 14 GB 記憶體以獲得流暢回應。
歸納總結
模型版本 適用裝置 模型特性 gpt‑oss‑20B 筆電 / Mac 開發者 約 210 億參數、效能近 o3‑mini gpt‑oss‑120B 高階工作站 / GPU 主機 約 1170 億參數、推理接近 o4‑mini
兩者皆具備開源特性，可離線運行、免費使用、無使用量限制，非常適合自主部署與隱私需求高的專案。此外，也可透過 Hugging Face、Azure、AWS 等多平台取得模型。
同場加映
可以用於 mac mini 建議用 oss-120B 放在 MAC 128G 共同記憶體以上的機器，可以有每秒 40 token
不想買機器的，可以先用 openrouter 或是 Groq
內建有 BrowserUse，Python，MCP
可以控制推理強度
MoE混合推理模型
支援企業級應用 vLLM ，SGLang
可以用於 Agent，微調
原生支援MXFP4，ollama等無須轉換
參考資料
https://github.com/openai/gpt-oss
VIDEO
VIDEO
VIDEO
近期留言