什麼是Qwen3.5-Omni：功能、版本與API存取

大家好！我是 Dora，又回來了！我正在剪輯一個影片專案時，通知突然出現：Qwen3.5-Omni 剛剛發布了。幾個月來我一直在一些生產工作流程中使用 Qwen3-Omni 系列，所以我立刻意識到這不是小幅度的更新。256K 上下文視窗、語音克隆、語義中斷，以及支援 113 種語言的語音識別——全部整合在一個模型中。我不得不停下手邊的工作。

如果你在開發語音代理、字幕處理管線，或任何需要同時處理真實人類音訊和影片的應用，這次發布與你直接相關。讓我帶你了解它的實際功能、三個版本在實際應用中的差異，以及如何獲取存取權——包括截至今日仍不明確的部分。

Qwen3.5-Omni 的實際功能

文字、圖像、音訊與影片在單一推理呼叫中處理

這是 AI 公告中持續被低估的一點：原生多模態處理與拼接式管線多模態處理並不相同。

當非全模態模型如 ChatGPT 5.4 接收影片輸入時，它必須透過視覺模型提取影格，透過 Whisper 等工具進行音訊轉錄，並使用 OCR 讀取嵌入字幕——三個獨立流程拼接在一起，模擬真正的全模態模型在單次處理中完成的工作。在理想條件下，畫面清晰、音訊乾淨的片段，一次真實測試中花費了九分鐘。

Qwen3.5-Omni 在單次呼叫中處理相同輸入。你傳入影片，得到回應。沒有中間管線，沒有格式轉換開銷，沒有不知道螢幕上發生什麼的音訊模型，也沒有什麼都聽不到的視覺模型。

該模型支援文字、圖像、音訊及音訊-影片理解，Thinker 和 Talker 元件均採用 Hybrid-Attention MoE 架構。最後這點比聽起來更重要，我將在下面的架構部分詳述。

「全模態」在實際應用中的意義 vs. 拼接式管線

差異在真正難以應對的場景中顯現出來。想想：有人同時在寫程式並旁白的螢幕錄製。或是背景有一半是口頭、一半是螢幕上的客服電話。或是環境音訊和視覺動作都各自帶有意義的無障礙字幕工作流程。

Qwen 團隊展示了他們所謂的「音訊-視覺 Vibe Coding」——模型可以觀看程式設計任務的螢幕錄製，並純粹根據所見所聞撰寫可運行的程式碼，完全不需要文字提示。

這個示範的名稱有點奇怪，但它是相對於附加了音訊功能的文字優先模型而言真實存在的能力差距。當推理和感知在同一個模型中同時發生，需要跨模態上下文的任務才能真正運作。

三個版本：Plus、Flash 與 Light

Plus——基準測試領導者，值得投入成本時的選擇

Qwen3.5-Omni-Plus 在音訊和音訊-影片理解、推理及互動任務中達成了 215 項 SOTA 結果。這是個很大的數字，阿里巴巴的基準測試傾向於積極計算——但獨立比較在重要的類別中正在驗證這一點。

在標準基準測試中，Qwen3.5-Omni Plus 在通用音訊理解、推理和翻譯任務上超越了 Gemini 3.1 Pro，並在音訊-視覺理解上與之齊平。在 20 種語言的多語言語音穩定性測試中，它擊敗了 ElevenLabs、GPT-Audio 和 Minimax。

語音克隆可透過 API 在 Plus 和 Flash 上使用——你傳送 10 到 30 秒的語音樣本，模型即可克隆該語音用於輸出。

什麼時候值得付費選擇 Plus？當輸出品質是你的用戶真正在意的事情時。語音自然度是核心價值主張的語音代理產品。準確性在稀有語言上至關重要的高風險轉錄。任何需要直接與 Gemini 或 GPT-Audio 比較並在品質上勝出的場景。

Flash——吞吐量與延遲的權衡

根據 API 文件，Flash 是生產使用的預設推薦。模型 ID 為標準版本的 qwen3.5-omni-flash，Flash 被描述為在大多數生產場景中平衡延遲、品質和回應的預設選擇。

對於開發 AI 輔助工作流程的創作者——自動字幕管線、即時訪談轉錄、大規模影片摘要——Flash 幾乎肯定是你的起點。你針對 Plus 進行批次測試，看看品質差異是否值得為你的特定使用案例支付額外費用。

前代 Qwen3-Omni Flash 的串流語音回應延遲已低至 234 毫秒。預計 Qwen3.5-Omni Flash 處於類似範圍，但 3.5 版本的確切已發布延遲基準在初始發布說明中尚未確認。

Light——邊緣運算與預算受限的使用案例

Light 是系列中最小的版本。3.5-Omni 系列的參數數量在撰寫本文時尚未完全確認，但前代的 30B-A3B 模型在適當量化下能在消費級硬體上合理運行，Light 版本可能遵循類似模式。

如果你在原型開發、為推理成本緊張的客戶建構專案，或真的在邊緣端運行，Light 就是你的起點。不要把它視為「差的那個」——對於許多創作者工具工作流程（例如：自動縮圖字幕、上傳音訊的簡單問答），它很可能已綽綽有餘。

相較於 Qwen3-Omni 的新功能

上下文視窗：256K Token，10 小時以上的音訊

從實際生產角度來看，這是我最關心的變化。

256K token 的上下文視窗可轉換為超過 10 小時的音訊，或約 400 秒含音訊的 720p 影片。這是一個有意義的飛躍。前代 Qwen3-Omni 的思考模式上限為 65,536 token，推理鏈為 32,768 token——有用，但對於較長的媒體內容有所限制。

對於播客分析、長篇訪談處理、延伸客服電話摘要——這個上下文視窗改變了在單次 API 呼叫中實際可行的範疇。

語言覆蓋：113 種識別，36 種生成

語音識別現在涵蓋 113 種語言和方言，較前代的 19 種有大幅提升。語音生成從 10 種語言擴展到 36 種。

在此誠實說明：阿里巴巴計算地區方言的方式，與 OpenAI 計算相同覆蓋範圍的方式相比，會使這些數字顯得更大。即使打了折扣，躍升仍是真實的。如果你在為東南亞市場、阿拉伯語內容或任何多語言語音工作流程開發，這是一個重大的實際改進。

搭載 Hybrid-Attention MoE 的 Thinker-Talker 架構

Thinker-Talker 架構首次在 Qwen2.5-Omni 中引入。3.5-Omni 的重要升級是兩個元件現在都使用 Hybrid-Attention MoE（混合專家）設計，與更廣泛的 Qwen3.5 系列向稀疏架構的轉變保持一致。

對開發者而言這意味著什麼：Thinker-Talker 的分離讓外部系統——RAG 管線、安全過濾器、函數呼叫——可以在語音合成開始之前介入這兩個階段之間。這不只是架構細節。它意味著你可以在模型推理的內容和它說出來的內容之間插入自己的邏輯。對於生產語音代理來說，這確實有用。

語義中斷與語音克隆

任何部署過語音機器人的人都知道那種痛苦：用戶咳嗽、狗吠、有人說「嗯嗯」，機器人就在回應中途停止，以為自己被打斷了。

Qwen3.5-Omni 新增了語義中斷功能，嘗試區分用戶真正想要插話與環境背景噪音或隨口評論之間的差異。這是那種在更新日誌中聽起來微不足道，但實際上是讓語音助理令人沮喪和讓人持續使用之間的關鍵差異的功能。

語音克隆和即時語音控制（速度、音量和情感）也是新功能。團隊提到了一個名為 ARIA 的功能，可提升語音輸出的穩定性和自然度——ARIA 在內部具體做什麼的技術細節在初始發布中尚未詳述。

如何存取 Qwen3.5-Omni

DashScope API（阿里雲）

主要的生產存取路徑是透過阿里雲的 DashScope API。它使用與 OpenAI 相容的介面，這意味著如果你已經在透過 OpenAI SDK 呼叫 GPT-4o 或 Claude，遷移過程很直接。

DashScope 支援多個地區：新加坡（國際）、美國維吉尼亞州、中國北京和香港，每個地區有不同的端點 URL。對於大多數非中國的團隊，新加坡國際端點是你的預設選擇：dashscope-intl.aliyuncs.com。

三個版本的模型 ID 遵循 qwen3.5-omni-plus、qwen3.5-omni-flash 和 qwen3.5-omni-light 的格式。API 結構遵循標準的 /v1/chat/completions 格式，帶有 modalities 參數以指定你希望在回應中獲得文字、音訊或兩者。

vLLM 自架選項

Qwen 團隊強烈推薦使用 vLLM 進行 Qwen-Omni 系列模型的推理和部署，提供包含 HuggingFace Transformers 和 vLLM 完整運行環境的 Docker 映像檔。

需要注意的是，在 MoE 模型上使用 HuggingFace Transformers 的推理速度可能非常慢，因此對於大規模或低延遲需求，vLLM 或 DashScope API 是推薦的路徑。

如果你要自架，請特別針對 vLLM 0.13.0 進行規劃——這是官方設定文件中引用的版本。MoE 架構意味著記憶體需求低於同等品質水準的可比較稠密模型，但在啟動生產部署之前，你仍需要驗證 GPU 配置。

開放權重狀態：已確認 vs. 待確認

這是我想謹慎對待、不超出已確認範圍推測的部分。

Qwen3-Omni（前代）以 Apache 2.0 授權在 GitHub 和 HuggingFace 上發布。Qwen3.5-Omni 的權重是否會遵循相同的 Apache 2.0 授權路徑，在初始公告中尚未確認。前代的權重已公開可用——3.5 的權重可能會跟進，但截至 3 月 30 日的發布日期，該確認仍待定。

在官方 GitHub 倉庫或 HuggingFace 模型卡確認授權之前，不要以此規劃你的開放權重部署計劃。請關注 QwenLM GitHub 的更新。

誰應該關注這次發布

語音代理與即時對話開發者

如果你在開發以語音為主的應用程式——客服機器人、AI 伴侶、互動式語音工具——Qwen3.5-Omni 值得認真評估。光是語義中斷就解決了每個語音代理開發者都遇到過的已知痛點。加上原生函數呼叫和網路搜尋，這開始看起來像真正的基礎設施，而不是研究發布。

Qwen 部落格文章強調直接內建於全模態模型中的原生網路搜尋和函數呼叫支援，這將其定位為語音優先應用程式的基礎設施，而非研究成果。

音訊-視覺製作與字幕工作流程

對於創作者工具、影片製作自動化以及大規模字幕製作——這是目前開放權重多模態領域中最引人注目的發布。10 小時以上的音訊上下文意味著你可以在單次呼叫中處理完整長度的內容。擴展的語言覆蓋意味著多語言內容不再是特殊情況。

在單次推理呼叫中結合音訊理解和影片影格分析，也使其對以下用途真正有用：自動精華片段提取、B-roll 字幕、帶有螢幕文字關聯的配音轉錄。

已在生產環境中運行 Qwen3-Omni 的團隊

如果 Qwen3-Omni 已在你的技術棧中，升級到 Qwen3.5-Omni 很直接。API 結構保持一致。光是上下文視窗的升級就值得在現有工作負載上進行測試——尤其是任何觸碰到 65K token 上限的工作。

不涵蓋的功能

不是圖像生成模型

值得明確說明，因為「全模態」會造成一些混淆：Qwen3.5-Omni 生成文字和語音。它不生成圖像或影片。它理解圖像和影片作為輸入——這是完全不同的能力。如果你需要圖像生成，請查看 Qwen 獨立的 VL 和圖像生成模型系列，或 DashScope 目錄中的 qwen-image-plus 模型。

MoE 推理速度：vLLM vs. HuggingFace Transformers

這讓許多人在使用 Qwen3-Omni 時栽了跟頭，使用 3.5-Omni 時也會讓人栽跟頭。由於 Qwen3-Omni 採用 MoE 架構，在 MoE 模型上使用 HuggingFace Transformers 的推理速度可能非常慢。對於大規模呼叫或低延遲需求，強烈推薦使用 vLLM 或 DashScope API。

不要在 HuggingFace Transformers 上進行基準測試後就得出模型速度慢的結論。在對生產可行性形成看法之前，請先在 vLLM 或託管 API 上進行測試。

常見問題

Qwen3.5-Omni 是開源還是開放權重？

截至 2026 年 3 月 30 日發布，Qwen3.5-Omni 的開放權重狀態尚未正式確認。前代 Qwen3-Omni 以 Apache 2.0 開放權重在 HuggingFace 上提供。預計 3.5-Omni 會有類似的發布節奏，但在依賴它之前請在官方 QwenLM GitHub 上驗證。

我可以自架 Qwen3.5-Omni-Plus 嗎？

DashScope API 是今天確認的生產路徑。透過 vLLM 自架對 Qwen3-Omni 受支援，一旦權重發布，可能也會支援 3.5-Omni。Plus 版本的 MoE 架構意味著活躍參數需求低於可比較的稠密模型，但完整 Plus 版本需要多 GPU 設置。

它原生支援函數呼叫和網路搜尋嗎？

是的。Qwen 部落格文章明確強調內建於全模態模型中的原生網路搜尋和函數呼叫支援。函數呼叫透過 DashScope API 遵循標準 OpenAI tools 格式。這是一個有意義的差異化因素——你可以建構查詢即時資料的語音代理，而無需透過獨立的編排層進行路由。

相關文章：