Qwen3.5-Omni API 定价、限制与部署选项（2026）

大家好！我是 Dora —— 三月底看到 Qwen3.5-Omni 发布 的时候，想跟大家分享一下我当时的第一反应。那一刻，我脑子里蹦出来的不是”哇，好厉害的模型”，而是：每次调用到底要花我多少钱？

原因很简单——我曾经吃过亏。我基于一个时髦的新多模态 API 搭了一条流水线，没仔细看计费文档，结果一旦音频处理进入较长的上下文范围，月账单直接翻了四倍。所以这次，我在写第一行集成代码之前，老老实实坐下来研读了 DashScope 的定价文档和官方 API 参考。

如果你是工程负责人或基础设施决策者，正在评估是否基于 Qwen3.5-Omni 进行开发或自托管，这篇文章涵盖了真正影响成本模型的关键内容——包括一个乍看非常反直觉、但坐下来仔细研究后才能看懂的定价结构。

Qwen3.5-Omni 的定价方式

DashScope 阶梯定价：基于输入 Token 的模型

最重要的事情先说：DashScope 不采用统一的每 Token 固定费率。 对于 Qwen3.5-Omni（以及其他几个 Qwen 模型，包括 qwen3.5-plus），定价采用基于当前请求输入 Token 数量的阶梯制。不是累计会话 Token——而是单次请求的输入规模决定你落在哪个定价档位。

这一点非常不直观，影响也是实实在在的。一个 5K Token 的短请求和一个 240K Token 的满载请求，不只是按比例定价不同——它们落在完全不同的费率档位。这种结构奖励保持请求简短，而这恰恰可能与你选用 256K 上下文模型的初衷直接冲突。

DashScope 官方定价页面展示了这种阶梯结构在 Qwen-Plus 及相关模型系列中的应用。每个音频 Token 和视频帧的 Omni 模态专属定价，在多模态计费部分有单独说明。

Plus、Flash 与 Light：性价比分布

Qwen3.5-Omni 提供三个变体，各有不同定位：

Plus 是基准旗舰模型——它在音频理解方面击败了 Gemini 3.1 Pro。Flash 以部分能力换取更低延迟和更低的单次调用成本。Light 是开放权重层：免费运行，但基础设施自己来。

对于 API 用户来说，实际决策是 Plus 还是 Flash。如果你的用例是高精度长录音转录或面向客户产品的语音克隆，Plus 是你的选择。如果你在做延迟预算更紧的实时对话，Flash 值得优先测试。

免费额度：包含哪些内容，何时用完

国际区（新加坡节点）的新 DashScope 账户可获得100 万输入 Token 和 100 万输出 Token 的免费额度，在激活模型工作室后 90 天内有效。全球部署模式（美国弗吉尼亚州）没有免费额度——如果你的团队在美国并希望从最近的节点测试，这一点很重要。

如果你在进行音频密集型测试，会发现这个免费额度消耗速度超出预期。一个 10 小时的音频文件就能达到 256K 上下文上限，仅这一个请求就消耗了你 100 万输入 Token 配额中的大约 25.6 万。

上下文窗口的经济学

256K Token 的实际含义：音频时长、视频秒数，以及真实成本

官方数据是 256K Token 可处理”超过 10 小时的连续音频”或”约 400 秒的 720p 视频（含音频）“。我们把这些数字转化成直观的成本感受。

音频的 Token 化速率大约是每小时 25,600 Token（256K ÷ 10 小时），即每分钟音频约 427 Token。视频按 1 FPS 采样，400 秒 720p 内容恰好填满完整上下文。

对照阶梯定价档位，考虑两种场景：

短请求（例如 5 分钟会议片段 ≈ 约 2,100 Token）： 落入最低定价档位，单次调用成本低。

长请求（例如 3 小时播客 ≈ 约 77,000 Token）： 跨入中等档位。每 Token 费率上涨，因此每分钟音频的成本明显高于短请求场景——不是因为使用了更多 Token，而是因为档位不同。

接近满载的请求（例如 8 小时音频文件 ≈ 约 205,000 Token）： 处于最高档位。按最高档定价处理一整天的音频，成本将远高于单独处理 40 个等效的 12 分钟片段。这就是阶梯模型迫使你做出的架构决策：长输入批处理 vs. 分块处理。

对于处理大量音频的开发者来说，分块处理实际上可能比利用完整上下文窗口更便宜——讽刺的是，大上下文恰恰是这个模型的卖点之一。

长上下文音频输入何时变得昂贵

在短上下文和长上下文之间，存在一个分块处理在成本上胜出的盈亏平衡点。具体数字取决于你的模态定价（DashScope 计费中，音频 Token 费率与文本 Token 费率不同），因此我建议在确定架构前先快速算一笔账：把你预期的音频时长分布分别代入阶梯定价公式和分块方案，比较一下。

速率限制与吞吐量

QPS / 并发限制的已知情况

Qwen3.5-Omni 的速率限制细节没有像纯文本模型那样有详细的公开文档。DashScope 对 API 用户的通用模式是：在账户级别应用 QPS（每秒查询数）和并发限制，企业账户可通过配额提升申请进行调整。如果你需要确认数字用于容量规划，向 DashScope 支持提交配额提升请求——他们会告知你账户层级的实际限制。

DashScope 国际区与中国大陆节点

对于非中国团队，有三个主要节点区域需要了解：

国际区（新加坡）： https://dashscope-intl.aliyuncs.com/compatible-mode/v1 —— 数据和节点在新加坡，推理在全球调度（不含中国大陆）。这是大多数国际开发者的默认选择，免费额度适用。
全球区（美国弗吉尼亚州 / 德国法兰克福）： 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

对于有数据驻留要求的团队，请向阿里云确认：通过美国节点处理的音频/视频内容，在推理流水线的任何环节是否会存储于美国境外。

使用 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 变体（总参数 300 亿，每 Token 激活 30 亿）在 BF16 精度下舒适推理至少需要 40GB 显存。实际情况：

单张 A100 80GB：在 FP8 或 INT8 量化下可运行 Plus，BF16 满上下文较为吃紧。
单张 H100 80GB：BF16 下运行舒适，较短上下文时有 KV 缓存余量。
RTX 4090（24GB）：不足以运行 Plus，可量化后运行 Flash 或 Light 变体。

对于 Omni 模型，还需要为 Talker 组件的音频编解码器预留显存——不仅仅是语言模型权重。有报告称 48GB 显存的 RTX 4090D 可在 AWQ 4-bit 量化下运行 Qwen3-Omni 30B-A3B，但 KV 缓存余量极小，生成吞吐量约为 64 Token/秒。

Docker 镜像可用性与部署设置

Qwen 团队提供了一个 Docker 镜像，捆绑了 HuggingFace Transformers 和 vLLM 的完整运行时。推荐直接使用——手动配置 Omni 专用的 vLLM 分支（qwen3_omni 分支）相当繁琐。使用官方工具栈安装：

# 克隆 Omni 专用的 vLLM 分支
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 显卡上将上下文推向 256K 需要激进的量化，并会严重限制批处理大小。根据 vLLM 官方部署文档，PagedAttention 能高效管理 KV 缓存内存，但具有多码本 Talker 输出的音视频模型比纯文本模型有更高的 KV 缓存压力。

DashScope API vs. 自托管：决策框架

DashScope 适合的场景

你需要在数天而非数周内上线生产
每月 Token 用量在约 5000 万以内（API 单位经济仍然合算）
你没有 GPU 基础设施，也不想自建
语音克隆功能有需求——该功能仅通过 API 在 Plus 和 Flash 上提供；Light 开放权重不暴露此功能
你需要新加坡或美国区域的数据路由，并有合同保障

自托管适合的场景

每月用量持续超过 5000 万至 1 亿 Token，且每 Token 成本对你来说意义重大
DashScope 的区域节点无法满足的数据驻留要求
需要延迟控制以达到依赖同机房部署的 200ms 以内响应目标
你在运行 Flash 或 Light 层级的工作负载，硬件适配你现有的机队
需要自定义微调或模型改造（仅开放权重的 Light 层级可实现）

实际转折点：在高用量下，在专用 H100 上运行 Plus，按云端约 2-3 美元/小时的成本计算，可能比 DashScope 按调用收费更便宜。具体算法取决于利用率——GPU 有 40% 时间空闲会显著改变这笔账。

隐藏成本注意事项

音视频预处理开销

发送给 Qwen3.5-Omni 的音频在到达 API 之前需要格式正确。qwen-omni-utils 库负责重采样、声道归一化和分块编码——但这些预处理会在你这边增加延迟和计算开销。对于视频，1 FPS @ 720p 是文档中的参考采样率，但从任意视频格式中实际提取帧需要 FFmpeg 或同类工具。在规划每次调用的延迟预算时，务必将这部分纳入考虑。

流式语音输出与单次调用成本

Thinker-Talker 架构实时流式输出语音——完整响应生成完成之前，第一批音频字节就已到达，这正是实时语音对话体验自然流畅的原因。但流式传输会增加每次调用的开销：连接保持时间更长，音频编解码器（Code2Wav 渲染器）生成多码本序列，这些都会计入输出 Token 数量。如果你使用语音输出模式，对于相同的底层响应，你的实际输出 Token 数会高于纯文本模式。请在 DashScope 计费文档中确认语音输出 Token 是否与文本输出 Token 按相同费率计费——计费文档在多模态定价部分对不同模态有所区分。

常见问题

DashScope 上的 Qwen3.5-Omni 有免费层级吗？

有，适用于国际区（新加坡节点）。新账户可获得 100 万输入 Token 和 100 万输出 Token 的免费额度，在激活模型工作室后 90 天内有效。美国（弗吉尼亚州）全球部署模式无免费额度。

DashScope API 的速率限制是多少？

截至 2026 年 3 月，Qwen3.5-Omni 的具体 QPS 数值未公开记录。账户创建时应用默认限制；在上线生产前，请联系 DashScope 支持并告知你的预期吞吐量，申请配额提升。

我能在单张 A100 上运行 Qwen3.5-Omni-Plus 吗？

在 FP8 或 INT8 量化下可以——A100 80GB 能够在受限的 KV 缓存余量下运行 Plus。在 BF16 精度、256K 上下文下则不行。在单张 80GB GPU 上，预计需要将 max-model-len 限制在 32K-64K 左右，才能保持稳定的吞吐量。

往期文章：