实时语音在百炼能力栈里的位置：从三段式管线到一条 WebSocket

过去两年，语音应用的主流做法是拼管线：ASR 负责听，LLM 负责想，TTS 负责说。三段各自都能找到不错的服务，拼在一起也能用，但工程复杂度全在「拼」上：三段之间的排队、超时、打断、上下文传递，每一项都要自己写。

qwen3.8-omni-flash-realtime 把这三段收进了一个会话。对平台用户来说，这不只是「少调两个接口」，而是把语音应用的架构单位从「三个服务」变成了「一条连接」。

这篇文章的实测部分交给 Agent 完成。我只说了一句「用实时语音搭一个能听、能查订单、能被叫停的售后客服」，它就去翻 WebSocket 接入文档，回报三个关键参数：Workspace 子域名端点、16kHz PCM 输入、24kHz WAV 输出。四组实验的数字都由它跑出来。

能力栈里的位置

把百炼的语音相关能力摊开看，分工是清晰的：

实时语音不是「ASR + TTS 的打包版」。它的输入输出是音频流，会话有状态，服务端自己判断轮次，工具调用发生在对话中间。这三点决定了它适合交互式场景，不适合批处理场景。

接入形态

接入是标准 WebSocket：wss://{WorkspaceId}.cn-beijing.maas.aliyuncs.com/api-ws/v1/realtime?model=qwen3.8-omni-flash-realtime。鉴权用百炼 API Key，没有额外的服务开通步骤。

会话参数里比较关键的是三个：

• modalities：只出文字，还是文字加音频
• turn_detection：服务端 VAD 还是客户端手动提交
• tools：Function Call 定义，或 MCP 服务配置

输入音频要求 PCM 16kHz 单声道，输出 WAV 24kHz。对做硬件的团队，这个格式转换在端上完成即可。

实测数据

我们在北京区跑了一组端到端实验，覆盖文本输入、语音输入、打断、工具调用四种形态：

这组数字里，对架构决策最有参考价值的是两个：

第一，语音输入到首音频 1.37 秒。它没有做到人类对话的 500 毫秒响应窗口，但已经落在「可以接受」的客服节奏里。如果业务要求 500 毫秒以内，需要在端上做流式采集和播放缓冲，不能等一整轮结束。

第二，工具调用把一轮对话从 2.37 秒拉长到 4 秒左右。这是业务查询的固有成本，不是模型慢。做产品时要给用户一个「正在查」的反馈，否则 4 秒会被感知成卡顿。

成本结构

实时语音按 token 计费，四档价格：音频输入 6 元/百万 token，文本、图片、视频输入 1.5 元，文本输出 4.5 元，音频输出 12 元。开音频输出时，输出的文字部分不重复计费。

实测成本：一轮语音对话约 0.0025 元，两轮工具调用约 0.0067 元。换算成一分钟连续对话，大约 1 分钱出头。

这个价格对企业的意义，不是「比人工便宜」，而是「可以大规模做灰度」。以前做一个语音客服原型要采购三套服务、走三次审批，现在一个 Key、一条连接、几分钱就能验证。

工程边界

第一，实时语音不等于「语音版聊天」。它适合交互，不适合批量转写、批量配音。批量任务用 ASR、TTS 更便宜也更稳。

第二，VAD 模式对合成音频不友好。TTS 生成的音频结尾没有自然停顿，服务端检测不到「说完」，会一直等。自动化测试要么补静音，要么改手动提交。

第三，输出模态决定事件名。只开文本时收 response.text.delta，带音频时收 response.audio_transcript.delta。这个差异在写接收逻辑时必须先确认。

第四，bl omni 不能替代实时语音。它是单轮多模态对话，没有长连接和 tools。CLI 在这条链路里的位置是外围工具：造测试音频、查价格、核对用量。

适合谁先上

客服和售后是最直接的方向：查订单、查物流、查退货资格，这些都是工具调用能落到业务系统的事。

智能硬件是第二方向：车机、音箱、穿戴设备，用户对「按下就说、说完就答」有明确预期。

AI 陪伴是第三方向：打断和语气是体验的核心，实时语音在这两点上比级联管线自然。

如果只是想把录音转成文字，或者把稿子念出来，不需要上实时语音。能力选型的第一原则是匹配交互形态，不是追新。

百炼控制台在这里，API Key 在这里。