Qwen-Audio-3.0-Realtime：实时语音开始自己办事，但价格口径要先看清

实时语音模型过去常见的取舍是：要么把响应压得很快，但回答变浅；要么把语音先转文字，再交给大模型推理，能力更完整，却牺牲了对话节奏。Qwen-Audio-3.0-Realtime 试图把这两个问题放进同一个端到端模型里处理：它通过 WebSocket 接收流式音频，同时流式返回文本和语音，还把工具调用、语义轮次判断和双工打断放进对话回路。

这款模型由「千问大模型」认证机构号在 2026 年 7 月 15 日发布说明，阿里云百炼的模型更新记录则把 Plus 和 Flash 的中国内地上架时间列为 7 月 14 日。[千问大模型官方发布] [阿里云模型上下架与更新记录]

先给判断：它最值得关注的地方不是又多了一个语音接口，而是语音模型开始被当作 Agent 的前端来设计。用户可以边说边改口，模型可以在上下文里决定是否调用工具，工具结果还能继续参与后面的对话。但它仍不是一个可以替代文本推理模型的全能入口：百炼文档明确写着，Qwen-Audio Realtime 不支持联网搜索，也不支持思考模式。[阿里云语音转语音选型与能力说明]

发布方用两组语音对话基准说明 Plus 与 Flash 的取向。在 VoiceBench 上，Plus 对标准化 prompt 的得分为 92.5，换成口语化 prompt 后为 90.5，下降 2.0；在更难的 AudioMultiChallenge 上，Flash 的对应分数为 43.6 和 38.1，下降 5.5。[Qwen-Audio-3.0-Realtime 官方发布]

这组数字真正说明的是抗口语化退化，而不是 Plus 一定全面强于 Flash。两个版本使用的基准不同，官方发布页也没有在这张对比中给出统一的时延分布、测试成本或第三方复现实验，因此不能把表格直接读成跨版本排行榜。更稳妥的解读是：团队把「真人说话不规整」当成了模型能力的一部分，而不是只优化书面 prompt 下的语音问答。

官方发布说明称，模型不必等用户明确说出「帮我打开」或「请查询」，就可以根据对话上下文决定是否调用外部工具；工具返回结果会被带回后续对话。例如先查附近的川菜馆，再追问评分和距离，模型可以继续利用前一轮结果。发布页同时提到 FunctionCall、MCP、API 和知识库接入。[Qwen-Audio-3.0-Realtime 官方发布]

这里需要把「模型会办事」和「应用能安全办事」分开。阿里云 WebSocket API 的定义是：模型输出函数调用项，客户端执行实际工具，再用 function_call_output 写回结果，最后通过 response.create 触发下一轮推理。换句话说，模型负责选择和组织调用，权限、参数校验、超时、重试和最终副作用仍由应用负责。[Qwen-Audio Realtime WebSocket API 参考]

这也是语音 Agent 比普通聊天更难的地方。一次误触发不只是答案错了，可能是错误下单、错误改期或把私人信息送进不该访问的工具。实际接入时，工具调用成功率和误调用率应与语音识别准确率分开评估。

发布方把共情对话作为一条独立升级线：模型会根据语境调整语气、节奏、音调，并利用笑声、叹息和犹豫等副语言信号回应。官方还称其在 VStyle 语音指令遵循基准上取得 SOTA。这里的价值不只是「声音更像人」，而是语音输出本身开始承载对话状态，例如争论时控制语气强度、陪伴场景里避免用统一播报腔。[Qwen-Audio-3.0-Realtime 官方发布]

不过，发布页没有展开 VStyle 的完整测试设置，也没有把情绪表达的稳定性、可控性和安全边界拆成独立指标。产品演示中的自然，不应直接等同于所有长对话都能保持一致的角色和情绪。

百炼实时接口提供三种交互模式：server_vad 由服务端检测语音起止，smart_turn 同时参考声学信号和语义判断轮次，push-to-talk 则由客户端手动提交音频和触发推理。smart_turn 的目的，是避免「嗯」「啊」或背景声被误判为新一轮发言，也减少模型播报时不必要的打断。[Qwen-Audio Realtime WebSocket API 参考]

这比简单的静音阈值更接近真人对话，但也意味着产品需要针对真实环境做测试：开放工位的旁人说话、多人会议中的目标说话人切换、用户半句话改口，以及模型被打断后是否能正确恢复，都会影响最终体验。官方 API 还支持在首次会话配置时提交目标说话人的音频 URL，用于说话人增强，但这不是无限制的多人分离能力。[Qwen-Audio Realtime WebSocket API 参考]

Qwen 的解释是，团队让语音模型先按自己的策略生成回答，再由文本大模型在过程中进行纠正，将文本模型的推理能力迁移到语音模型；同时使用四类教师，分别覆盖口语多轮偏好、通用问答与推理、Agent 工具调用，以及音频理解和副语言信息。[Qwen-Audio-3.0-Realtime 官方发布]

这个训练思路解决的是一个实际矛盾：如果只把文本模型的最终答案蒸馏给语音模型，模型可能学会「说什么」，却没有学会在口语噪声、连续打断和工具反馈下「怎么继续做」。On-Policy Distillation 让学生模型暴露自己的生成轨迹，教师再针对这些轨迹纠正，更适合覆盖实时交互里的错误状态。

但「推理能力蒸馏进语音模型」不能被理解为百炼给它打开了文本模型的思考模式。官方 API 的模型选型表明确列出 Qwen-Audio Realtime 不支持思考模式和联网搜索；这款模型的优势是低延迟的直接响应与音频上下文理解，而不是长链条、可显式展开的深度推理。[阿里云语音转语音选型与能力说明]

这是 WebSocket 双工协议，不是把一段音频上传后等待完整结果的 HTTP 接口。官方文档列出的基本形态是音频流式输入、文本与语音流式输出；同一套会话还支持对话项的创建、查询和删除。实时场景通常从 server_vad 或 smart_turn 开始，按键说话则适合 push-to-talk。[Qwen-Audio 实时语音对话文档]

百炼模型页的价格不是一个简单的「输入价 / 输出价」。按官方页面列出的中国内地价格，单位均为元/百万 tokens：

其中，文本+音频输出一栏的说明是「输出的文本不计费」。因此，5 元和 3 元对应的是文本输入，不是音频输入；做语音客服的预算时，不能直接拿这两个数字乘以文本字数。具体价格以 Plus 模型页 和 Flash 模型页 为准。

音频 token 如何随采样率、时长和输入输出模态变化，不能从这张价格表推导出固定的「每分钟成本」。上线前应记录真实请求中的音频输入 token、文本输出 token 和音频输出 token，再按 Plus 与 Flash 分别做压测。

阿里云文档将两款模型都列为 WebSocket 实时语音对话模型，支持音频和文本输入、Function Calling，但不支持联网搜索和思考模式。[阿里云语音转语音选型与能力说明] 如果应用需要实时查询天气、股票或网页内容，应该由外部工具或另一条支持搜索的模型链路完成；如果应用需要长篇规划、复杂代码推理或可审计的思维过程，也不应把这款实时模型当作唯一大脑。

它适合三类场景：需要低延迟和自然打断的语音助手，需要把语音直接接入查询或业务工具的客服，以及希望在语气、节奏和副语言上做出差异化的互动产品。它的技术价值在于把「轮次控制、音频理解、工具调用、语音生成」放进一条更短的闭环，而不是单纯把 TTS 音质再提高一点。

验证时建议至少做三组 A/B：第一组测真实网络下的首包和打断恢复，第二组测工具误调用、重复调用和权限拒绝，第三组用真实音频 token 统计 Plus 与 Flash 的单位会话成本。通过这三组数据，才能判断「又快又聪明」在自己的业务里到底是体验收益，还是把复杂度从模型端转移到了应用端。