語音 – Page 2 – InferNews

Qwen-Audio Realtime API 上線：以 WebSocket 即時串接語音對話

2026 年 9 月 5 日

阿里巴巴雲 Model Studio 推出 Qwen-Audio Realtime API，用 WebSocket 串流處理語音輸入與輸出，支援 VAD 偵測與雙向文字回傳，適合即時語音助理開發。

想在應用程式裡加入即時語音對話，但又不想自己串接一堆音訊前處理、ASR、TTS 的流程？阿里巴巴雲 Model Studio 這次直接把 Qwen-Audio 做成可即時呼叫的 Realtime API，開發者只要透過 WebSocket 連線，就能處理語音輸入、文字輸入，並即時收到串流音訊與文字回應。

這個 API 的設計重點在於「一條連線做完整件事」。客戶端與伺服器以 JSON 事件雙向溝通，支援語音活動偵測（VAD），讓系統知道用戶何時開始與結束說話，省去自行判斷靜音的麻煩。對話中的每一則訊息會以 conversation item 形式保存，整個 session（即一條 WebSocket 連線）則負責維護設定與上下文狀態。

服務端點分為中國（北京）與新加坡兩個區域，皆已改用 workspace-specific 專屬網域，官方表示穩定度與推論表現都比原本的共用網域更好。連線時需使用 wss:// 協定，並在 request header 帶上 Authorization: Bearer <your_api_key>，API key 會在 WebSocket 握手階段驗證，若無效會直接回 HTTP 401/403。

若你的項目是語音助理、即時翻譯、客服 robot 或電話自動化，會感受到整合成本明顯降低——不用分別串 ASR、LLM、TTS，只要管理好 WebSocket 的事件流即可。舊網域雖然仍可用，但官方強烈建議遷移至新網域以取得更佳體驗。

重點摘要

即時雙向串流：WebSocket 連線同時處理音訊輸入與串流輸出，搭配 VAD 自動偵測語音起止。
JSON 事件溝通：所有互動以結構化事件傳遞，方便除錯與日誌記錄。
雙區域專屬網域：中國（北京）與新加坡皆提供 workspace-specific 端點，穩定度與推論表現提升。
簡化整合流程：免去自行串接 ASR、LLM、TTS 的負擔，適合快速建構語音應用。
原有網域仍可用：但官方建議盡快遷移以享受新網域的效能改善。

項目主頁

Categories: 阿里巴巴, 文字轉語音, Qwen, API, Audio, Robotic, 語音, 中國

Breeze TTS 2 即時語音生成

2026 年 9 月 2 日

Breeze TTS 2 主打即時語音互動，兼顧聲線設計、聲線模仿與低延遲串流。它把自然語言指令和參考音訊結合起來，令語音生成更靈活。

Breeze TTS 2 屬於 text-to-speech（TTS）模型，核心目標是把即時語音互動做得更自然，並同時處理聲線模仿、聲線設計和語氣控制。它基於自然語言指令，既可以用參考音訊去保留聲線特徵，也可以不靠參考音訊直接設計聲音，這令使用場景比一般單一路徑的 TTS 更廣。

模型權重只限研究與非商業用途，而原始程式碼則採用 Apache 2.0，這表示權重與程式碼的授權條款並不相同。

Breeze TTS 2 支援 Voice Clone、Voice Design、Voice Direction，同時提供 Vocal Events，讓使用者可在文字中加入 (laugh)、(cough) 之類的表現指令。頁面亦強調它有 ultra-low-latency streaming，適合需要即時回應的對話式語音互動。

重點主要集中在功能和評測定位，沒有提供 GGUF 檔案、mmproj、量化版本、檔案大小，亦未提到 llama.cpp、Ollama 或 LM Studio。只見到它在 Artificial Analysis TTS leaderboard 排名第一，並聲稱表現超越部分閉源前沿系統；但由於頁面未展示完整測試細節，較適合把它視為一個以互動延遲、可控性和聲線表現力作賣點的語音模型。

支援參考音訊模仿，也支援純文字描述生成新聲線
可以用文字內嵌事件控制笑聲、咳嗽等表現細節
主打低延遲串流，適合即時語音互動
權重屬研究與非商業用途，授權限制要先看清
頁面未提供量化、GGUF 或本地推論框架資訊

模型

Categories: 開源, 文字轉語音, 模型, 語音

Breeze TTS 2：低延遲語音生成再推一級

2026 年 8 月 28 日

Breeze TTS 2 把即時語音互動、聲線設計同語氣控制放埋一齊，主打低延遲同高可塑性。它較適合要做配音、語音代理或互動內容嘅團隊。

Breeze TTS 2 係一個文字轉語音（text-to-speech, TTS）模型，重點唔止係把文字讀出，而係處理即時互動入面最難平衡嘅兩件事：聲音要自然，回應又要夠快。佢支援 Voice Clone、Voice Design 同 Voice Direction，代表可以由參考錄音複製聲線，亦可以純靠自然語言描述去設計新聲線，再按指令調整語氣、節奏同表達。

對內容製作、語音代理、遊戲角色配音同多語言產品來講，呢種做法比單純 TTS 更有彈性。文本內仲可以插入 Vocal Events，例如笑聲、咳嗽、清嗓子呢類表情提示，令生成聲音更接近真人演繹，而唔係只係平鋪直敘讀稿。

項目資料顯示，佢喺 Artificial Analysis TTS leaderboard 排名第一嘅 open-weight 模型，亦聲稱喺部分測試中超越商業系統。低延遲係另一個賣點：warming 後喺 NVIDIA H100 可做到少於 40 ms 的 time to first audio，RTF 約 0.32，適合即時對話場景。

不過，repo 同時寫明模型權重、衍生模型同 self-hosted outputs 只限研究同非商業用途，呢點對想直接落地嘅團隊影響好大。代碼層面提供 PyTorch inference code，但原始資料未交代完整安裝流程或部署細節，較合理嘅理解方式係先把佢視為一個面向研究與產品原型驗證的高性能 TTS 模型。

支援參考錄音複製聲線，亦支援純文字描述設計新聲線
可以用指令調整語氣、情緒、語速同演繹方式
低延遲串流適合即時語音互動同 voice agent
在 open-weight TTS 基準中聲稱領先，但授權限制較嚴
適合配音、互動內容、多語言語音產品同研究團隊

項目主頁 · GitHub · 模型

Categories: 開源, 文字轉語音, Agentic, 模型, NVIDIA, Audio, Clone, Python, 語音, Dataset 數據集

VoiceMem 讓語音 AI 記住你的情緒與偏好

2026 年 8 月 27 日

VoiceMem 以流式雙腦架構處理事實記憶、情緒與人格，讓語音智能體在對話中更懂使用者，同時控制延遲與成本。

語音智能體要記住「我是素食者、對堅果過敏」，並不只是保存轉錄文字，還要分辨人物、情緒、偏好與性格。VoiceMem 屬於語音 AI 記憶引擎及可整合的庫，處理音訊輸入、記憶抽取、檢索和回應前的上下文注入，讓長期個人化對話不必每次重新建立背景。

它採用 VoiceMem Dual-Brain Streaming Architecture（流式雙腦架構）：左腦以 schema 與 entity 組織事實記憶，右腦獨立管理情緒、偏好和人格，亦維護跨 entity 的關聯。音訊仍在輸入期間，系統已經分段、轉錄、抽取資料並寫入記憶圖；查詢時先路由及排序，只把 Top-K 記憶放入上下文，減少語音回應需要處理的內容。

左腦在 Top-3 限制下維持 Mem0 的滿載性能
右腦加入長短期情緒歸因及交叉節點
透過壓縮資訊、分層儲存和流式查詢降低等待時間
單輪查詢約需 300 token，架構及底層記憶引擎可替換

VoiceMem 內置 ASR（Automatic Speech Recognition）、聲紋、場景、情緒感知及本地 embedding 元件，亦提供離線記憶引擎和 streaming interface。倉庫資訊包含 Python 庫、互動式網頁 demo、VoiceMem_Default_Models_Env 模型環境，以及可選的 Qwen 回應模型；但完整硬件要求、服務依賴和模型授權仍需按連結內容逐項確認，不能單靠 README 推斷。

ChatMem-400K 以記憶世界構建、SLM 驗證的 online on-policy distillation 和人工修訂三階段製作，配合 VoiceMem Model Families 的 Qwen3 6 35B A3B Qlora 模型系列。這令項目較適合需要長期語音陪伴、個人助理、客服或具情緒連續性的 voice agent 團隊；對只需短對話轉錄的工作流，雙腦記憶層會增加整合和維護成本。

項目主頁 · GitHub · 模型

Categories: 開源, 香港中文大學, 清華大學, Agentic, Embedding, 多模態模型, Qwen, Python, 庫, 語音

Super-Star：讓數字人邊聽邊做

2026 年 8 月 27 日

Super Star 將串流語音、對話和身體動作連成一條即時管線，令 3D 數字人毋須等待完整語音才開始配合手勢。

數字人要一邊回應、一邊自然做出配合語氣的動作，關鍵不只是生成語音，而是不能偷看未來內容。Super Star 屬於面向 3D 數字人的即時互動框架，處理多模態輸入、串流回應語音，以及與語音同步的身體姿態生成。

Super-Star 把 Streaming Speech Response 與 Online Gesture Generator 兩個模組接合。前者採用 Qwen3-omni 產生串流回應語音，後者是因果多模態自回歸模型，根據目前收到的語音和 motion history 預測下一段動作，因此可在低延遲下生成手勢，不需等整段對話完成。

離線資料流程會按主題和情緒建立人機對話，再為回應語句生成 co-speech gestures；線上互動收集到的使用者偏好，會回流到 closed-loop self-evolving data pipeline，支援持續調整。相比先取得完整語音再生成動作的做法，Super Star 以較少未來資訊換取即時性，但動作預測亦更依賴目前語音片段和歷史狀態。

串流語音與動作同步，適合虛擬陪伴、直播角色及互動式數字人
Qwen3-omni 負責回應語音，Online Gesture Generator 負責身體動作
研究結果主張改善 latency-quality trade-off、語音動作同步及使用者偏好
訓練 Motion Tokenizer 和 Online Gesture Generator 時需要 WAV 音訊
CUDA driver 需為 12.4 或以上，完整執行細節仍要配合 Qwen3-omni 及 vLLM-Omni 文件

提供的資料包含 training、inference 和 evaluation code。訓練部分使用 RQVAE 的第一層 codebook 解碼，對應論文線上模型採用的 VQVAE，測試者需要準備 WAV 檔案並填寫音訊路徑和輸出目錄。對研究團隊及需要低延遲數字人互動的開發者而言，項目較適合作為研究原型或客製化系統的起點，而非即裝即用的成品。

項目主頁 · GitHub

Categories: 開源, 騰訊, Agentic, 多模態模型, 模型訓練, Qwen, NVIDIA, Audio, 3D, 語音, Dataset 數據集

Gemini Live 語音代辦操作，對話直接推進工作流程

2026 年 8 月 27 日

Gemini Live 開始將語音對話變成可執行動作，減少你在應用程式之間來回切換。這次更新瞄準的是日常處理待辦事項時最容易中斷節奏的那一步。

一邊講電話、一邊行路，或者手上正做緊其他事時，最麻煩往往唔係記低待辦，而係之後仲要再打開日曆、記事或清單工具逐個輸入。Gemini Live 今次更新，正正係想將語音對話直接接駁到生產力工作流，令你講完就可以即時推進下一步，而唔係停留喺一段只會回應問題嘅聊天。

Google 把這次升級放在 Gemini Live 內，主打用聲音委派待辦事項。公開內容雖然未詳細列出所有支援動作，但方向已經相當明確：Gemini app 不再只做對答，而係更貼近可代你整理、記錄同安排事項嘅 Agentic 工具。對平日靠手機快速處理雜務、會議後即場補記重點，或者想減少手動輸入嘅人，分別會幾直接。

同常見語音助理只幫你查資料、設鬧鐘相比，呢類整合更著重「講完之後有冇後續動作」。價值唔單止在於語音輸入，而係把理解內容、整理意圖同觸發下一步放入同一段互動入面。代價亦好清楚：功能好不好用，仍然取決於它能接到幾多工具、判斷待辦內容有幾準，以及會唔會喺多步操作中出錯。

把語音對話直接轉成待辦相關動作，減少手動整理
焦點放在生產力場景，而不只是語音問答
Gemini Live 朝住 Agentic assistant 方向再行前一步
真正體驗取決於工具整合深度同指令理解準確度

現時公開資訊較似功能發布預告，未見完整技術細節、評測數字或支援範圍清單。不過訊號已經好明顯，Google 想令 Gemini app 在對話之外，開始處理更多可落地執行的工作。對想用語音把碎片化雜務一次過交畀系統處理的人，這次更新比單純加強聊天自然度更有實際意義。

項目主頁

Categories: Agentic, Google, Gemini, 工具, 語音, 安全

TLive-Omni：專攻直播電商的多模態理解模型

2026 年 8 月 26 日

TLive-Omni 將影像、影片、語音和文字統一成文字輸出，特別適合要即時理解直播內容的場景。它同時處理商品畫面、聲音與對話脈絡，目標是減少直播電商裡資訊斷裂的問題。

TLive-Omni 是一個多模態理解模型，針對直播電商場景，把影像、影片、語音和文字整合到同一個文字輸出介面。對做直播監控、商品理解、內容標註或客服輔助的人來說，它處理的是同一場直播裡多種訊號難以對齊的問題。

這個項目建基於 Qwen3.5 backbone，再接入 AuT audio encoder 和輕量 MLP 對齊層，並用 timestamped Per-vGrid 把聲音片段和對應畫面放在一起。它支援最長 256K tokens context，適合長時間直播流的連續理解，而不是只看單段截圖或單句語音。

訓練流程分三階段 SFT，先做語音與語言對齊，再擴展到完整多模態指令跟隨，之後加入 Faithful-RFT，強調回答要貼近直播場景的即時需要。README 亦列出聲音辨識、講者分析、商品視覺定位、文字辨識、時序定位、影片密集描述和 omni-modal QA 等能力，顯示它不是單一功能模型，而是面向直播任務的綜合型系統。

4B 和 9B 版本都已公開，方便按算力和部署成本選擇。
在直播電商的音訊、影像和影片任務上有不錯表現。
對一般基準也有泛化能力，不只局限於單一場景。
更適合需要長上下文、多訊號同步分析的團隊。
取捨在於它很聚焦直播電商，未必是通用多模態助手的最佳替代。

整體來看，TLive-Omni 把直播場景最麻煩的訊號對齊、長上下文理解和即時回答放在同一條路徑處理，對做電商直播分析、內容審核和銷售輔助的團隊會更實用。它的價值不在於把功能堆滿，而在於把多模態理解收斂到直播工作流裡真正會撞到的問題。

項目主頁 · GitHub · 模型

Categories: 開源, AI productions, 多模態模型, Qwen, Video, Audio, 語音

VoxEMW：把 Mac 變成 1.3 秒回應的私人語音助手

2026 年 8 月 24 日

VoxEMW 將語音處理放在 Apple Silicon Mac，手機只需透過瀏覽器或 iOS 客戶端對話，回應速度與音色克隆是最大賣點。

對住手機講完一句話，約 1.3 秒後便聽到固定角色用克隆聲線回答，VoxEMW 屬於開源語音助手項目，處理判停、轉寫、對話調度及語音合成，解決語音對話延遲高、角色聲線難以保持的問題。Mac 負責主要語音管線，只有 LLM 大腦經 DeepSeek API 上雲，日常成本相對可控。

整套流程由 Silero 加 SmartTurn 負責判斷何時真正講完，Qwen3-ASR-0.6B-hf 在 MPS 上轉寫，再由 DeepSeek v4-flash 產生回覆，Qwen3-TTS-1.7B-Base 以 MLX 6bit 執行零樣本音色克隆。參考聲音配合逐字台詞便可註冊角色，首段聲音約 0.5 秒生成；中途打斷時，已播放及已聽內容會寫回上下文，對話較不容易斷層。

一块 4090 跑通 AI 视频通话全栈：Qwen3.8-27B 本地部署，对话时延 2 秒

Watch this video on YouTube

項目需要 Apple Silicon Mac 作本地伺服器，實測以 M5、16GB 記憶體可以流暢運行，模型及環境約需下載 4GB。瀏覽器可直接連接本機介面；iPhone 或 iPad 則要透過局域網 HTTPS/WSS 連線，並自行處理 TLS 證書、Xcode 簽署及免費帳戶七日側載限制。

• 回應最快 1.26 秒，中位數約 1.6 秒，實際速度仍受網絡及 API 影響
• VAD、STT、TTS 留在本機，DeepSeek API 按 token 收費
• 支援流式字幕、空回覆重試及語音中斷後續接
• 全屏星空會隨說話及聲波變化，增加角色互動感

相比全程雲端方案，VoxEMW 減少語音資料離開家中 Mac，但需要一部 Apple Silicon Mac 長期運行；相比完全離線方案，DeepSeek API 帶來額外費用及資料傳輸考慮。適合想建立固定聲線角色、研究低延遲語音管線，或有 Mac 作家庭伺服器的開發者，普通使用者則要先接受證書、模型環境及 API 金鑰設定等門檻。

GitHub

Categories: 開源, 文字轉語音, Qwen, DeepSeek, API, 框架, Mac, 語音, 蘋果

4DAnyone 把單鏡頭影片重建 4D 多視角

2026 年 8 月 22 日

由一段普通單鏡頭人物影片開始，4DAnyone 生成具一致性的多視角影片，再交由 4DGS 重建可動人物。

由未校準的 monocular video 出發，4DAnyone 可以為同一個人物生成多個目標視角，接着交給 4D Gaussian Splatting（4DGS）建立可渲染的 4D 人物。這個 GitHub 項目屬於 4D 人物重建工具，處理的是拍攝時沒有多部相機、相機內參或姿態資料，卻想取得多視角動態素材的問題。

它不只把畫面轉成另一個角度，而是嘗試維持不同視角之間的時間和外觀一致性，讓後續 4DGS 重建不必直接面對單鏡頭資料的視角缺口。相較於需要 rig、校準相機或固定三腳架的流程，這個方法換來的是對輸入影片質素和人物動作的依賴。

使用 inference.py 讀取影片，再以 views_per_layer、layer_pitches、start_yaw 和 yaw_span 控制相機層數、上下角度及水平覆蓋範圍。儲存庫提供 Python 3.11、requirements 和第三方 GVHMR 元件的安裝安排，缺少的模型及例子會在首次使用時自動取得；原始資料沒有交代硬件需求、推理時間或量化性能，因此不能把速度表現視為已被驗證。

支援全身或上半身、畫面只包含一人的影片
可生成 6、24、48 個或自訂數量的目標視角
兼容輕微鏡頭移動，以及未知相機內參和姿態的素材
可選 FlashAttention-3 或 SageAttention 加快推理

研究展示內容集中於不同人物影片、動作和場景的泛化能力。需要製作 4D 人物、研究自由視角影片，或建立動態人像資料的團隊；只想快速套用濾鏡或要求即時輸出的使用者，仍要先確認硬件、模型取得方式和影片條件是否符合要求。

項目主頁 · GitHub · 模型

Categories: 開源, 香港中文大學, 香港科技大學, AI productions, 數字人, 視頻模型, Video, Python, 語音

NAPE 簡化自監督音訊片段訓練

2026 年 8 月 21 日

NAPE 以因果 Transformer 預測下一個音訊 patch embedding，省去解碼器與 tokenizer，探索更精簡的音訊表徵學習方法。

音訊模型要兼顧訓練成本、表徵能力與模型規模，往往需要加入多個輔助模組。NAPE（Next Audio Patch Embedding prediction）是一個自監督音訊表徵學習框架，將 log-mel spectrogram 切成 patch，再由因果 Transformer 根據前面的片段預測下一個 patch embedding。

NAPE 沒有 reconstruction decoder、acoustic tokenizer、student-teacher 架構或額外正則化損失。它依靠三個機制維持學習訊號：causal masking 隱藏未來位置、prediction shift 要求位置 t 預測 t+1，以及 stop-gradient 固定目標 embedding，避免模型退化成輸出相同向量。

二維 spectrogram 會按指定 scanning order 轉成一維序列，研究涵蓋 raster、diagonal、zigzag 和 time-major 四種排列；其中 raster、diagonal 及時間方向的排列較符合聲音事件的發展。模型在 AudioSet 預訓練，再於 AudioSet-2M、AudioSet-20K、ESC-50、Speech Commands V1/V2 和 IEMOCAP 進行微調或 linear probing，資料顯示它在多項任務取得 state-of-the-art fine-tuning 結果，並具備穩定的跨規模擴展能力，但原始資訊沒有提供各項具體分數。

要求系統有 Python 3.10、PyTorch 2.8.0 和 Transformers 4.56.2 的環境，並提供 requirements 檔及部分資料集處理程式；ESC-50、Speech Commands V1/V2 和 IEMOCAP 有下載腳本，AudioSet 則要自行處理涉及 YouTube 的下載流程。研究團隊亦列出程式碼及預訓練 checkpoint 的發布資訊，但 Hugging Face checkpoint 仍標示為待辦，不能把完整模型取得流程視為已經齊備。

訓練訊號精簡：只用下一個 patch embedding 預測與 stop-gradient。
適合音訊表徵：可支援語音指令、環境聲音及情緒辨識等任務。
排列順序有影響：spectrogram 的線性化方式會改變模型看到的時間關係。
測試門檻清楚：需要 AudioSet 或下游資料集，以及 W&B 追蹤實驗。
限制在資料流程：AudioSet 不提供同等簡化的下載方式，checkpoint 取得狀態亦未完全明確。

項目主頁 · GitHub

Categories: 開源, Embedding, 模型訓練, Audio, Python, 語音

Page 2 of 8

« Previous 1 2 3 4 … 8 Next »