Qwen3.5-Omni API 定價、限制與部署選項（2026）

嘿，大家好！我是 Dora — 跟你們分享我在三月底看到 Qwen3.5-Omni 發布 時的驚訝。當下我的第一個念頭不是「哇，好酷的模型」，而是：這每次呼叫到底要花多少錢？

因為我之前就吃過虧了。我在一個閃亮亮的新多模態 API 上建了一條 pipeline，帳單文件沒仔細看，然後看著月費在音訊處理進入較長的 context 範圍後直接暴漲四倍。所以這次，我在寫任何整合程式碼之前，先坐下來仔細看了 DashScope 的定價文件和官方 API 參考。

如果你是工程負責人或基礎設施決策者，正在評估要在 Qwen3.5-Omni 上建構還是自行部署，這篇文章涵蓋了真正影響你成本模型的關鍵資訊 — 包括一個在你深入研究之前確實很不直覺的定價結構。

Qwen3.5-Omni 的定價方式

DashScope 分層定價：基於輸入 Token 的模型

最重要的事情先說清楚：DashScope 不是用固定的每 token 費率計費的。 對於 Qwen3.5-Omni（以及包含 qwen3.5-plus 在內的其他幾個 Qwen 模型），定價是根據當前請求的輸入 token 數量分層計費。不是累積的 session token — 而是單次請求的輸入大小決定你落在哪個定價區間。

這很不直覺，而且有實際影響。一個 5K token 的短請求和一個達到上限的 240K token 請求，不只是按比例定價不同 — 它們落在完全不同的費率區間。這種結構鼓勵你保持請求簡短，而這可能直接與你使用 256K context 模型的原因相衝突。

官方 DashScope 定價頁面顯示了這種分層結構應用於 Qwen-Plus 及相關模型系列。每個音訊 token 和影片影格的 Omni 模態定價，另外記載於多模態計費部分。

Plus vs. Flash vs. Light：成本效能比較

Qwen3.5-Omni 有三個定位不同的版本：

Plus 是基準標竿模型 — 它在音訊理解方面超越了 Gemini 3.1 Pro。Flash 以一部分能力換取更低延遲和可能更低的每次呼叫成本。Light 是開放權重版本：免費運行，但你要自己負責基礎設施。

對於 API 使用者，實際上的決策是 Plus 與 Flash 之間的選擇。如果你的使用場景是對長錄音進行高精度轉錄，或是為面向客戶的產品進行語音複製，Plus 是你的首選。如果你在做延遲預算更緊的即時對話，Flash 值得先測試。

免費配額：包含什麼以及何時用完

位於 International 地區（新加坡端點）的新 DashScope 帳號可獲得100 萬輸入 token 和 100 萬輸出 token 的免費配額，在啟動 Model Studio 後有效期為 90 天。Global 部署模式（美國維吉尼亞）沒有免費配額 — 如果你的團隊在美國並想從最近的端點測試，這一點很重要。

如果你在進行大量音訊測試，免費配額消耗速度會比你預期的快。一個 10 小時的音訊檔案就達到 256K context 上限，光是這一個請求就消耗了你 100 萬輸入 token 配額中的約 25.6 萬。

Context 視窗的經濟學

256K Token 的實際應用：音訊時數、影片秒數，以及實際花費

官方數字是 256K token 可處理「超過 10 小時的連續音訊」或「約 400 秒的 720p 影片（含音訊）」。讓我們把這些數字轉化為成本直覺。

音訊的 token 化速率約為每小時 25,600 token（256K ÷ 10 小時）。這大約是每分鐘音訊 427 個 token。對於以 1 FPS 取樣的影片，400 秒的 720p 內容會填滿完整的 context。

將這些數字套入分層定價區間，考慮兩種情境：

短請求（例如，5 分鐘會議片段 ≈ 約 2,100 token）： 落入最低定價區間。每次呼叫費用低廉。

長請求（例如，3 小時播客 ≈ 約 77,000 token）： 跨入中間定價區間。每 token 費率上升，因此你的每分鐘音訊成本明顯高於短請求情境 — 不是因為你使用了更多 token，而是因為所在的區間不同。

接近上限的請求（例如，8 小時音訊檔案 ≈ 約 205,000 token）： 你在最高定價區間。以頂層區間定價處理一整個工作日的音訊，費用會遠高於分別處理 40 個等效的 12 分鐘片段。這是分層模型強迫你做的架構決策：批次處理長輸入 vs. 分塊處理。

對於處理大量音訊的建構者來說，分塊可能實際上比利用完整 context 視窗更便宜 — 這很諷刺，因為大 context 部分就是它的賣點。

長 Context 音訊輸入何時變得昂貴

在短 context 和長 context 之間的某處存在一個盈虧平衡點，分塊在成本上佔優。確切數字取決於你的特定模態定價（DashScope 計費中音訊 token 費率與文字 token 費率不同），因此我建議在確定架構之前先快速計算一下：將你預期的音訊長度分佈分別套入分層定價公式和基於分塊的方法來比較。

速率限制與吞吐量

QPS / 並發限制的已知資訊

Qwen3.5-Omni 的速率限制細節並未以與純文字模型相同的詳細程度公開記載。DashScope 對 API 使用者的一般模式是在帳號層級應用 QPS（每秒查詢數）和並發限制，企業帳號可透過配額增加申請進行調整。如果你需要確認容量規劃的數字，請向 DashScope 支援提交配額增加申請 — 他們會回覆你帳號層級的實際限制。

DashScope 國際版 vs. 中國大陸端點

非中國團隊需要了解三個主要端點地區：

International（新加坡）： https://dashscope-intl.aliyuncs.com/compatible-mode/v1 — 資料和端點在新加坡，推理在全球排程（不含中國大陸）。這是大多數國際建構者的預設選擇。免費配額適用。
Global（美國維吉尼亞 / 德國法蘭克福）： https://dashscope-us.aliyuncs.com/compatible-mode/v1 — 資料和端點在美國維吉尼亞地區，運算在全球排程。無免費配額。 適合美國地區的低延遲需求。
中國大陸（北京）： https://dashscope.aliyuncs.com/compatible-mode/v1 — 僅限在中國境內運營的團隊。每 token 定價明顯更低。

美國地區可用性（維吉尼亞端點）

美國（維吉尼亞）端點適用於 Qwen 文字模型。截至目前，請直接透過 DashScope API 參考確認 Qwen3.5-Omni 多模態推理是否路由到美國端點，或是回退到新加坡。一般多模態端點模式為：

POST https://dashscope-us.aliyuncs.com/api/v1/services/aigc/multimodal-generation/generation

對於有資料駐留要求的團隊，請向阿里雲確認透過美國端點處理的音訊/影片內容是否在推理 pipeline 的任何環節儲存於美國境外。

使用 vLLM 自行部署

為何 Qwen 團隊推薦 vLLM 而非 HuggingFace Transformers 用於 MoE

Qwen3.5-Omni-Plus 使用混合注意力專家混合（MoE）架構。Qwen 團隊明確推薦 vLLM 而非 HuggingFace Transformers 用於任何生產工作負載 — 原因特別與 MoE 有關：MoE 模型中的專家路由會造成不規則的記憶體存取模式，HuggingFace Transformers 對此優化不佳。vLLM 的 PagedAttention 和 MoE 感知排程能顯著更好地處理這個問題，在負載時帶來實際的吞吐量差異。對於大規模呼叫或低延遲需求，官方指導是使用 vLLM 或直接使用 DashScope API — 而非原始的 Transformers。

Plus（30B-A3B 等級）的基礎設施需求

Plus 版本（總參數 30B，每個 token 激活 3B）在 BF16 下舒適推理需要至少 40GB VRAM。實際上：

單張 A100 80GB：在 FP8 或 INT8 量化下可運行 Plus。BF16 在完整 context 下很吃緊。
單張 H100 80GB：在 BF16 下運行舒適，在較短 context 下 KV cache 有一定餘裕。
RTX 4090（24GB）：不足以運行 Plus。可在量化下運行 Flash 或 Light 版本。

特別針對 Omni 模型，你還需要考慮 Talker 元件音訊解碼器的記憶體 — 不只是語言模型的權重。有報告指出 RTX 4090D（48GB VRAM）能以 AWQ 4-bit 量化運行 Qwen3-Omni 30B-A3B，但 KV cache 餘裕極小，生成吞吐量約為 64 token/秒。

Docker 映像的可用性與設定

Qwen 團隊提供了一個 Docker 映像，包含 HuggingFace Transformers 和 vLLM 的完整執行環境。建議使用它 — 手動設定 Omni 專用的 vLLM fork（qwen3_omni 分支）很麻煩。使用官方套件安裝：

# Clone Omni 專用的 vLLM fork
git clone -b qwen3_omni https://github.com/wangxiongts/vllm.git
cd vllm

# 安裝相依套件
pip install -r requirements/build.txt
pip install -r requirements/cuda.txt
VLLM_USE_PRECOMPILED=1 pip install -e . -v --no-build-isolation

# 安裝必要套件
pip install transformers==4.57.3 accelerate
pip install qwen-omni-utils -U
pip install -U flash-attn --no-build-isolation

然後啟動服務：

vllm serve Qwen/Qwen3-Omni-30B-A3B-Instruct \
  --tensor-parallel-size 2 \
  --gpu-memory-utilization 0.90 \
  --max-model-len 32768

max-model-len 32768 的限制對單 GPU 設定是實際的做法 — 在單張 80GB 顯示卡上將 context 推向 256K 需要積極量化，並大幅限制批次大小。根據 vLLM 自己的部署文件，PagedAttention 能有效率地處理 KV cache 記憶體，但具有多 codebook talker 輸出的音訊視覺模型，KV cache 壓力高於純文字等效模型。

DashScope API vs. 自行部署：決策框架

DashScope 何時適合

你需要在幾天內上線，而非幾週
你的月 token 用量低於約 5,000 萬 token（API 單位經濟效益仍然有利）
你沒有 GPU 基礎設施且不想建置
語音複製功能很重要 — 僅 Plus 和 Flash 透過 API 提供；Light 開放權重不公開此功能
你需要具有合約保證的新加坡或美國地區資料路由

自行部署何時適合

月用量持續超過 5,000 萬至 1 億 token，且每 token 成本有意義
DashScope 的地區端點無法滿足的資料駐留要求
依賴同機房部署實現 200ms 以下回應目標的延遲控制需求
你在運行符合現有機群硬體規格的 Flash 或 Light 層級工作負載
客製化微調或模型修改（僅限開放權重 — Light 版本才有可能）

實際的轉折點：在高用量下，以每小時約 $2-3 的雲端費用在專用 H100 上運行 Plus，比 DashScope 的每次呼叫費率更便宜。數學計算會因使用率而改變 — 40% 時間閒置的 GPU 會顯著影響計算結果。

隱藏成本考量

音訊/影片前處理的額外負擔

傳送至 Qwen3.5-Omni 的音訊在送達 API 之前需要是正確的格式。qwen-omni-utils 函式庫負責重新取樣、聲道正規化和分塊編碼 — 但這些前處理在你這端增加了延遲和運算成本。對於影片，1 FPS 取樣於 720p 是文件中的參考速率，但從任意影片格式實際提取影格需要 FFmpeg 或等效工具。請將這些納入你的每次呼叫延遲預算。

串流語音輸出與每次呼叫成本

Thinker-Talker 架構即時串流語音輸出 — 在完整回應生成之前，第一個音訊位元組就已送達，這使得即時語音對話感覺自然。但串流增加了每次呼叫的額外負擔：連接保持開啟時間更長，音訊解碼器（Code2Wav 渲染器）生成的多 codebook 序列會增加輸出 token 計數。如果你使用語音輸出模式，相同的底層回應，你的有效輸出 token 計數會高於純文字模式。請確認 DashScope 是否以與文字輸出 token 相同的費率計費語音輸出 token — 計費文件在多模態定價部分對模態有所區分。

常見問題

DashScope 上的 Qwen3.5-Omni 有免費方案嗎？

有，適用於 International 地區（新加坡端點）。新帳號可獲得 100 萬輸入 token 和 100 萬輸出 token 免費配額，在啟動 Model Studio 後有效期 90 天。美國（維吉尼亞）Global 部署模式無免費配額。

DashScope API 的速率限制是多少？

截至 2026 年 3 月，Qwen3.5-Omni 的具體 QPS 數字未公開記載。帳號建立時套用預設限制；請在上線前聯繫 DashScope 支援，提供你預期的吞吐量以申請配額增加。

我可以在單張 A100 上運行 Qwen3.5-Omni-Plus 嗎？

在 FP8 或 INT8 量化下可以 — A100 80GB 可以在受限的 KV cache 餘裕下運行 Plus。在 BF16 下以 256K context，則不行。預計在單張 80GB GPU 上將 max-model-len 限制在約 32K–64K 左右，以維持穩定的吞吐量。

往期文章：