正在加载，请稍候
识别链路最高降 95%、合成降约 70%，语音客服从演示品变成可算账的交付项。但降价只解决单价，四道工程卡口要自己填。
2026 年 9 月 23–24 日这两天，语音链路的价目表被重画了一遍：识别最高降 95%，合成约降 70%，端到端实时链路约降 85%。语音第一次成了能算进毛利表的交付项——前提是链路拆对了。
我们在 8 月做过一版移动端语音工单助手的内测，降价前每分钟综合成本压在 0.4 元上下，降价后同样的链路预估掉到 0.07 元量级。单价不再是问题，卡住上线的全部是工程细节。
阿里云百炼的模型目录已经把这套能力拆成三条独立产品线：流式识别、文件转写、端到端实时对话。以该平台的 qwen-audio-3.1 系列为例，三条线在计费口径上是分开的（百炼模型与计费文档）。拆线本身就是信号——厂商认为多数人只需要其中一段，而不是整包。
同一周，Google 侧把 Flash 档的语音合成补齐成两个型号，把批量合成也拉进了低价位带。OpenAI 则把语音入口从聊天窗口推进到工作流：ChatGPT Voice 现在可以调用邮件、日历和 Slack 插件，并在 ChatGPT Work 的网页端与移动端同时开放（9 月 23–24 日产品更新）。
三件事叠在一起，计价方式从"按分钟包月"变成了"按链路分段计价"。这直接改变选型逻辑：可以只买识别、自建合成，也可以只买实时通道、把意图判断放回自己的服务里。
| 链路形态 | 计价口径 | 延迟量级 | 适用场景 | 成本陷阱 |
|---|---|---|---|---|
| 批量文件转写 | 按音频时长 | 分钟级 | 历史录音质检、工单字段抽取 | 降幅最大，但拿不到实时话轮 |
| 流式识别 + 流式合成 | 时长 + 合成字符数 | 亚秒级 | 通话中问答，可混用多家供应商 | 两段各自计费，长话轮会双倍放大 |
| 端到端实时 | 按音频时长或音频 token | 最低 | 高频打断、短话轮 | 话轮变长后单价反超分段方案 |
我们最后的组合是"流式识别 + 云端小模型 + 流式合成"，端到端通道只留给 30 秒以内的短指令。原因不是延迟，而是端到端链路拿不到中间态——看不到识别文本，就没法做话术兜底和合规过滤。
用户说"不是这个，我是想问上周那张单子"，你要作废的不只是正在播的那句话。
排队中的识别分片、已经发出的工具调用、已经生成但还没播的后续话术，全部要一起撤。少撤一样，用户就会听到"好的，我帮您转到…"然后再也没下文。
on BARGE_IN:
cancel(tts_stream) # 停播
drop(asr_partial_after=last_committed) # 只保留已确认分片
rollback(pending_tool_calls) # 未落地副作用直接丢
state = LISTENING
状态只要四个：等待输入、思考、播报、被打断。多的状态都是给调试添麻烦。
我们踩过的坑是用播放器状态当作打断信号。用户随口"嗯"一声就切走，一通话里被切了 11 次，体验比不打断还糟。现在的做法是先过一道 200–300ms 的语音活动门，再判断这半句是否构成完整语义单元，两层都过才触发。
还有一类副作用撤不掉：已经下单、已经发出去的短信。这类动作必须带幂等键，并在打断恢复后主动向用户复述一次，让他知道"刚才那步已经生效了"。
移动网络下，首响超过 800ms 用户就会觉得"它没在听"。这个预算是硬约束，得按毫秒切开分给各段：
加起来 570–960ms，超支的部分几乎都出在第三项。把系统提示词压到 800 字以内、把本轮需要的槽位预填好，首 token 能省掉约 100ms。
更有效的是并行：识别结果只要出现稳定前缀就直接送模型预热，不等整句结束；模型吐出第一个完整句子就立刻送合成，不等整段回复生成完。这两处改完，我们实测首响从 1.4 秒降到 0.72 秒。
"用户生气了就转人工"是没法实现的描述。可落地的是几个可测信号：语速超过基线 1.4 倍、音量持续上扬、同一诉求重复到第三遍、静默超过 4 秒、命中脏话词表、用户直接说出"转人工"。
降级按阶梯走，一次只降一级：先复述确认诉求，再切成短句（每句不超过 15 字），再跳过解释直接给结论，最后主动提出转人工并说明预计等待时长。
这里有个真实的权衡。我们把降级门槛调得太敏感时，转人工率从 18% 涨到 27%——人一被转走，语音链路省下的钱就全赔回去了。后来把"重复到第三遍"从硬触发改成加权信号，转人工率回到 21%，投诉率同时下降。
双录（原始音频 + 转写文本）在多数行业属于必须留存、也最容易越界的资产。四条边界建议写进设计文档：
落地时最容易漏的是第三项。转写走的是境内节点，合成却可能被路由到海外加速节点——链路里的文本同样算个人数据，这条要提前和法务对齐。
降价之后"上本地模型省钱"这个理由基本不成立了。本地识别的价值只剩下三件事：断网可用、隐私不出设备、以及弱网下的首响兜底。
Google 的 Antigravity SDK 已经支持通过 LiteRT 跑本地模型并完全离线运行智能体，官方建议设备有 24GB 以上显存或统一内存（SDK 更新说明）。这个门槛决定了它只能落在高端机型上做兜底，不能当主力。
| 场景 | 建议分工 | 理由 |
|---|---|---|
| 电梯、地库、地铁 | 本地识别兜底 | 网络断了也要能接住前两句 |
| 长尾语义、多轮工具调用 | 云端旗舰模型 | 本地模型在槽位推理上错得更多 |
| 短指令（挂断、重播、确认） | 本地判定 | 省一次往返，首响能压到 300ms 内 |
| 涉及身份、支付的话轮 | 强制云端 + 合规过滤 | 本地链路无法做集中审计 |
把文本客服的意图识别模型直接搬到语音上，第一周就会发现问题：大量话轮根本没有意图。
"喂""你在吗""嗯""那个"这类无效话轮在实际通话里占比超过两成，它们会被文本模型强行归类成一个意图，然后触发一堆错误动作。工程上要做的是先过滤再识别。
静默检测同样需要分级：3 秒无语音给一句轻提示，6 秒确认掉线并改走回呼，而不是一直等。方言与噪声则要先看信噪比，低于阈值时提示用户换到安静环境，比硬识别出一段乱码再道歉便宜得多。
还有一个容易被忽略的差异：语音没有滚动回看。用户一口气说三个诉求，后两个很容易丢失。做法是在槽位填满后主动复述一次"我先确认三件事"，把丢单率压下来。
站内另一篇讲小程序端文本首响与上下文取舍的实录（文本链路怎么分配首响预算）结论在这里不适用——文本的上下文可以靠滚动补齐，语音只有一次机会，所以语音侧要更早复述、更早降级。两条链路别共用一套指标。
指标本身不难，难的是口径先写死，否则三个月的对比全是噪声。我们用的是下面五条：
| 指标 | 口径 | 采数方式 | 优化方向 |
|---|---|---|---|
| 有效通话率 | 含至少一轮完整意图交换的通话占比 | 服务端会话日志 | 环比上升 |
| 转人工率 | 主动发起转接 ÷ 总通话量 | 转接事件埋点 | 降级门槛调优后环比下降 |
| 单次通话成本 | 识别 + 模型 + 合成三段合计 ÷ 通话量 | 各供应商用量对账 | 随场景路由细化下降 |
| 投诉率 | 投诉工单 ÷ 通话量 | 工单系统打标 | 与转人工率同时观察 |
| 录音合规抽查通过率 | 抽查中脱敏与留存合规的样本占比 | 每周人工抽检 | 不低于首月基线 |
第五项经常被跳过。但只要有一次抽查不过，前面四项全部归零——所以它应该是唯一不允许放宽的门。
不要按"每分钟多少钱"重算，按链路分段重算：识别按音频时长、模型按 token、合成按字符数。分段之后你会发现成本大头往往从识别挪到了模型侧，尤其是长话轮和多轮工具调用。
因为端到端拿不到中间态。没有识别文本就没法做敏感词过滤、话术兜底和质检留痕。涉及身份与支付的场景基本只能走分段，端到端留给短指令和低风险问答。
两句话：要么用户插话后系统继续把上一段说完，要么系统被"嗯""啊"这类语气词频繁打断导致逻辑跳步。前者是状态机缺 BARGE_IN 事件，后者是缺少语音活动门和语义完整性判断。
只在三种情况下值：断网必须可用、音频不允许出设备、弱网首响必须压到 300ms 内。单纯为了省单价不值得，降价之后云侧成本已经低于维护一套本地识别引擎的工程师成本。
音频与文本分开定。原始音频按争议复核周期定，通常短于文本；转写文本按行业质检要求定，但必须在落库前去标识化。具体年限要按所在行业监管要求确认，不要照抄别家方案。
蓝曜炬辉（www.lanyaoai.com）做过多个客服与流程自动化类项目，链路拆解和验收口径的原始版本可以在 客服类项目实录 里看到；需要按你的通话量算一份分段成本模型，直接 联系我们，我们把三段计价表和首响预算模板一起发你。