语音识别与语音合成：一通电话里那两秒花在哪
识别、理解、合成三段串起来，才是客户感知到的延迟。这一页给技术选型的人四个答案：ASR 为什么必须流式、TTS 的音质与首帧怎么取舍、七个环节各花多少时间、以及为什么「CPU 也能跑」这句话只对识别成立。
技术口径
客户说完到我们开口，中间那两秒花在哪
电话里的「像不像人」，不是音色决定的，是节奏决定的。 任何一段多花三百毫秒，整体就会被听成「卡住了」。
一通电话的体验只由三件事决定：听得清（语音识别）、 想得明白（意图、检索、大模型）、说得出来（语音合成）。 这三段串起来，才是客户感知到的那两秒。分开看每一段都不慢，串起来就慢了 —— 这是选型时最容易算错的地方。
先说结论，后面逐段展开：语音识别可以在 CPU 上跑，语音合成与大模型推理不行。 「CPU 也能跑」这句话本身没错，但它只对识别成立。把这句话套到合成上， 做出来的演示在单句、单路、无并发的情况下看着能用，一上量就完全不是一回事。
这一页不给排行榜，给的是口径：每一段的时间量级是多少、哪些数字代表可以上线、 哪些数字只在实验室里成立。技术选型真正需要的不是「哪个模型更强」， 而是「在我的并发、我的线路、我的噪声环境下，这套东西能不能稳定地在两秒内开口」。
还有一个前提要先讲清：电话是窄带通道。运营商侧的通话音频通常是 8kHz 采样， 高频在进入系统之前就已经丢了。这意味着再好的模型也只能在有限的信息上工作， 任何宣称「电话里能听出细微情绪」的说法，都值得追问一句测的是什么通道。
链路每一段都不慢，串起来才是客户听到的那两秒。
「CPU 也能跑」的适用范围只有识别
识别是编码器 + 小解码器，算力需求相对可控，实时率低于 1 就能用。 语音合成要逐帧生成波形，大模型要逐 token 生成文本 —— 这两件事在 CPU 上不是「慢一点」，是慢到无法在通话中开口。
语音识别
流式不是优化项，是前提
非流式识别要等一句话说完再整段返回，这段时间客户是在干等的。 电话场景里，这段等待直接等于「反应慢」。
流式与非流式的实际差别
非流式：录完整段音频，一次性送进模型，返回整句文本。准确率通常略高， 因为它能看到完整上下文；代价是必须等端点判定之后再等一次推理。 用在通话里，等于客户说完还要再停顿一次。
流式：音频边说边送，模型持续输出中间结果。客户说到第三个字时， 系统已经在出字了；端点一判定，最后几个字补上即可。 代价是中间结果会反复修正，需要一套「稳定文本」的策略 —— 不能拿还在变的中间结果去做意图判断。
端点检测是第一个可调旋钮
系统怎么判断「客户说完了」？靠静音时长。这个阈值通常在三百到七百毫秒之间： 设得太短，客户只是换气就被打断；设得太长，每一轮对话都多等半秒， 累积起来就是一通「反应慢」的电话。
这个值没有通用最优解。语速慢的客户、老年客户、方言口音重的客户， 需要的静音窗口更长；业务话术里如果常有「嗯」「这个」这类填充词， 阈值设短会把一句话切成两段。可行的做法是按业务线配两到三档， 并在通话中根据上一轮的长度自适应。
热词：专有名词靠表，不靠模型猜
产品型号、地名、公司名、人名，是识别错误最集中的地方。 这类词的正确做法是维护热词表：写全称，同时写常见误听写法， 按业务线分开维护，每条注明负责人。
热词表不是越长越好。塞进去几千条，等于给模型加了一堆互相干扰的候选， 反而会拉低常用词的准确率。合理的量级是一个业务线几十到两百条， 并且每月按实际错例增删。
噪声：损失的不是音量，是辅音
车间、门店、车内、路边，这四类环境的噪声特性不同：车间是稳态机械噪声， 门店是人声混叠，车内是低频路噪，路边是突发鸣笛。 窄带通道已经把高频削掉一截，而 s、sh、f、h 这些辅音主要靠高频区分， 所以噪声环境下错得最多的是数字和姓氏 —— 恰好是核验身份最关键的部分。
工程上的应对不是「换个更强的模型」就完事：要在关键字段上做二次确认 （复述、逐位确认），并且在置信度低时主动追问，而不是硬猜一个结果写进系统。
识别准确率要分场景报
安静环境、办公室、车间、车内，四个场景的准确率可以差出十几个百分点。 只报一个总数，等于什么都没说。选型时应当要求供应商按场景给数字， 并且说明测试集是自有录音还是公开数据集。
语音合成
音质、自然度、首帧，三个不能同时要
合成这一段的取舍比识别更明显：模型越大音质越好，首帧越慢。 电话场景里，首帧慢半秒比音质差一档更难接受。
采样率不是越高越好，是要匹配通道
电话通道是 8kHz，播出去的音频最终会被重采样到 8kHz 再传。 用 48kHz 的模型合成，再压到 8kHz，听感上不会有 48kHz 的优势， 反而多了一道重采样的开销。48kHz 的意义在网页、APP、录音回放这些宽带场景。
所以选型时要问清楚：模型原生输出是多少、链路上在哪一步重采样、 电话侧有没有做窄带优化。把 48kHz 当成卖点讲给电话场景，属于口径错位。
音色克隆：克隆的是音色，不是语气
零样本克隆需要一段干净的参考音频：单人、无背景音乐、无明显混响、 时长几十秒到一分钟。参考音频里的噪声会被一起学进去， 所以「随便录一段」通常得到的是一个带底噪的音色。
克隆得到的是音色与基本发音习惯，不包括语气、情绪和节奏。 同一段参考音频，换不同的文本和标点，出来的停顿与重音会不一样 —— 这也是为什么话术里的标点要认真写，逗号顿号的位置会直接影响听感。
合规上还有一条：使用真人音色做克隆，必须有本人的书面授权， 并约定使用范围与期限。未经授权克隆他人声音，风险不在技术层面。
自然度与首帧的取舍
大模型 TTS 的音质明显更好，但首帧更慢；流式声码器的首帧可以压到一百多毫秒， 代价是韵律的细节少一些。电话场景的可行做法是分段合成： 按标点把回复切成短句，第一句先合成先播，后面的边播边生成。
分段也有代价：句与句之间的衔接会变硬，长句的语调会失去整体感。 所以分段策略要跟话术长度匹配 —— 回复本身写得短，分段的副作用就小； 回复写成一长段，怎么切都会露痕迹。
数字、型号、缩写的读法要单独处理
「2026」读二零二六还是两千零二十六，「A17」读 A 十七还是 A 一七， 「3.5」读三点五还是三五 —— 这些不取决于模型，取决于文本前端。 电话里最容易被听错的就是数字和型号，而这两类恰好是核验身份时必须说清的。
可行的做法是：关键字段（金额、日期、订单尾号、型号）在送进合成之前先做口语化改写， 并且在话术里安排一次复述。复述不是为了礼貌，是为了给客户一次纠错的机会。
判断合成好不好，用这三个场景听
一、含数字与型号的一句（订单尾号、金额、设备型号）； 二、含疑问语气的一句（「您是说要改成明天下午，对吗」）； 三、连续三句以上的短回复（听句间衔接）。
这三个场景能过，日常通话基本就够用。用一段朗读体散文去评测， 得到的结论和电话里的实际听感关系不大。
打断必须真的停下来
客户插话时，系统要在一个音节内停止播放，而不是把这句话播完。 实现上取决于播放缓冲与端点检测的联动：缓冲越长，停得越慢； 停得太慢，客户会重复说一遍，这一轮的节奏就乱了。
打断之后还要决定「听到哪了」—— 是重播整句，还是从断点继续。 重播整句更安全，但从断点继续更像人。
延迟拆解
七个环节，加起来的才是客户听到的
下面每一段都是量级，不是精确值；硬件、模型、并发不同， 同一段可能差一倍。要看的是哪几段真正可控。
| 环节 | 在做什么 | 时间量级 | 决定因素 | 常见误区 |
|---|---|---|---|---|
| VAD 端点判定 | 判断这句话说完了没有 | 300–700ms | 静音阈值、环境噪声、语速 | 以为这段是「零成本」，其实它是最大的一块 |
| ASR 收尾 | 把最后几个字补进文本 | 100–300ms | 流式模型、端点后的补帧策略 | 拿整段识别的准确率评估流式效果 |
| 意图与检索 | 判断客户在说什么、查知识库 | 30–150ms | 索引结构、知识库条目数、缓存命中 | 每次都全量检索，不做缓存 |
| 大模型首 token | 组织这一句该怎么回 | 200–800ms | 模型规模、GPU、上下文长度 | 把「整句生成完」当成首 token 时间 |
| 回复策略 | 套话术模板、填字段、做合规拦截 | 10–50ms | 规则条数、拦截复杂度 | 把合规检查放到合成之后，白算一遍 |
| TTS 首帧 | 生成第一个可播放的音频块 | 150–500ms | 模型类型、是否流式、是否分段 | 用整句合成耗时当作首帧延迟 |
| 编解码与网络 | 打包、传输、线路侧解码 | 50–150ms | 线路质量、是否跨地域、是否经公网 | 内网测试通过就认为线上没问题 |
合计与门槛
把上面七段按中间值相加，大约一秒到两秒半。行业的可用门槛通常是这样： 端到端首帧在两秒以内可以上线，一秒半以内算自然，超过两秒半客户会开始怀疑线路。 这些是量级判断，不是承诺值 —— 同一个系统在二十路并发下的数字， 会比单路测试高一截。
只有三段是真正可控的
端点判定、大模型首 token、TTS 首帧，这三段占了总延迟的七成以上， 也都有明确的调法：端点阈值按业务线调，首 token 靠缩短上下文与提高算力， TTS 首帧靠流式与分段。剩下的段（网络、编解码）要么是固定的， 要么由线路质量决定，优化空间有限。
所以「把延迟降下来」这件事，实际动作通常只有三个：换更快的推理硬件、 把回复写短、把端点调准。前两个是成本，第三个是设计。
客户感知的不是平均延迟
一通电话里，客户记住的是最慢的那几次。平均值一秒二，但有几轮到了三秒， 整通电话的感受就是「有时会卡」。所以验收要看 P95，不看均值； 要按并发档位分档看，不看单路。
缩短回复，是最便宜的优化
回复从四十个字压到十五个字，首 token 之后要生成的量少了六成， 合成也少一半。多数通话里，回复本来就不需要那么长 —— 长回复通常是因为话术里塞了太多解释，而不是客户需要那么多信息。
别在演示里用缓存过的结果
演示时如果客户问的是准备好的问题，检索和生成都可能命中缓存， 延迟看起来很好。真实通话里，每一句都是新的。 验收要用真实录音回放，不能用脚本念稿。
硬件
CPU 跑识别可以，跑合成与大模型不行
这不是偏好问题，是算术问题。逐帧生成波形和逐 token 生成文本， 算力需求比识别高一个量级以上。
识别为什么可以在 CPU 上跑
流式识别用的是编码器加小解码器的结构，算力集中在短时特征提取上。 单路实测的实时率可以到 0.165 —— 也就是说，处理一秒音频只用 0.165 秒， 距离「算不过来」还有很大余量。这也是为什么识别可以放在边缘、 放在本地、放在没有 GPU 的机器上。
但余量不等于可以无限加并发。并发上来之后，CPU 的调度开销和内存带宽会成为瓶颈， 实时率会往上走。要按「峰值并发时的实时率仍然小于 1」来配机器， 而不是按单路测试的数字。模型与数据不出内网的部署方式见私有化部署。
合成与大模型为什么不行
语音合成要输出波形：一秒 8kHz 音频是八千个采样点， 每个点都要算。模型再小，这一步的算力密度也远高于识别。 大模型推理要逐 token 生成，每个 token 都要过一遍全部参数。 这两件事的共同点是：输出是按时间线性展开的，无法靠批处理摊薄到可忽略。
CPU 上不是「慢一点」，是慢几十倍。一句八秒的语音，在 CPU 上合成可能要几十秒； 大模型的首 token 会从几百毫秒变成数秒。放进通话里，就是客户说完之后长时间的空白 —— 这已经不是体验问题，是这通电话根本进行不下去。
GPU 上的并发不是线性的
同一张卡，单路跑得快，不代表能跑十路。批处理能提高吞吐， 但会增加单路的等待时间 —— 因为要等一批凑齐。 所以并发规划要同时看两个数：每秒能处理多少秒音频（吞吐）， 以及在这条并发下的首帧延迟（时延）。
可行的做法是给不同环节分配不同的资源池：识别可以多路共享， 合成与大模型按并发预留，并且在超载时降级 —— 降级不是降低音质硬撑， 而是转到人工或转成文字通道。
怎么在自己的机器上量
取十分钟真实通话录音，按时长统计；单路先跑一遍，记首帧与总耗时； 再按目标并发放同样多的路数，记 P95。两次结果都要留档， 上线后按季度复测 —— 模型和驱动升级都会改变这两个数。
验收口径
四条验收，不做一条就不算跑通
演示能过不代表能上线。下面四条都是可以在自己环境里复现的， 不需要依赖供应商的说法。
- 真实录音回放。用你自己的历史通话录音，不要用朗读体样本。 噪声、口音、抢话、方言，这些只有真实录音里才有。
- 并发下看 P95。按目标并发的八成跑一遍，看首帧的 95 分位。 均值好看、P95 难看，说明系统在排队。
- 合成回读闭环。把 TTS 的输出再送进 ASR 识别一遍， 比对文本。数字、型号、金额这三类如果回读不一致，说明文本前端有问题， 而不是模型有问题。
- 降级路径。把 GPU 占满、把知识库断掉、把线路打满， 看系统是转人工、转文字，还是直接挂断。没有降级路径的系统， 在峰值那天一定会以最难看的方式失败。部署侧的容量与网络要求， 在部署与集成里按机房条件分档写了。
为什么不建议只看一个综合分
供应商给的「语音质量综合分」通常是把识别、合成、延迟混在一起算的。 这个分数没法用来做决策：你可能识别很好但首帧太慢，也可能音质很好但噪声下崩掉。 拆开看每一项，才知道这套东西适不适合你的场景。
拆开之后还要问一句：这个数字是在什么通道、什么并发、什么噪声下测的。 没有这三个前提的技术指标，只能当参考。
可以接受的三类不完美
一是偶发的识别错误，只要关键字段有复述兜底； 二是合成里轻微的机械感，只要节奏对了，客户不会在意； 三是极端噪声下的降级，只要系统主动说出来「这边有点吵， 我重复一遍」，而不是硬猜。
这三类都能通过话术设计吸收掉。真正吸收不掉的是延迟不稳定 —— 客户无法预期下一句要等多久。
模型会换，口径不要换
识别与合成模型一年会换两三次。每次换模型都重新定一套指标， 历史数据就作废了。可行做法是把验收口径固定下来（同一批录音、 同一并发档、同一统计方式），换模型只换被测对象。
常见疑问
选型时最常被问到的五个问题
这五个问题的答案，基本决定了一套方案能不能落在真实业务里。
为什么不能直接用云端的语音接口？
可以，但要分清代价。云端接口的优势是省硬件、随时可升级； 代价是每一句都要走公网，延迟受网络与对方排队影响， 而且音频要离开你的机房。对通话这种强时延场景，公网往返本身就是一段不可控的延迟。
更实际的是并发与成本：大批量外呼时，云端按调用量计费， 费用随通话量线性增长，而自建是一次性投入。 数据合规要求高的行业（金融、医疗），音频不出内网往往不是选项而是前提。
48kHz 采样率对电话有意义吗？
对电话通道没有意义。运营商侧通常是 8kHz 窄带，48kHz 的音频最终要重采样下去， 高频部分在传输前就被丢掉了。48kHz 的价值在网页试听、APP 播放、 录音回放这些宽带场景。
选型时真正该问的是：电话侧有没有做窄带优化、重采样发生在哪一步、 8kHz 下的音色是否还稳定。把采样率当成唯一指标，容易被一个不相关的数字说服。
方言和口音能识别吗？
带口音的普通话通常可以，方言取决于模型覆盖范围。要问清楚的是「覆盖哪几种方言」， 而不是「支持方言」这种笼统说法。同一个省内不同片区的口音差别也可能很大。
工程上的兜底比模型更重要：关键字段（姓名、地址、金额）一律复述确认， 置信度低时主动追问，而不是硬猜。识别率再高，也总有猜错的一次， 而那次如果正好是地址，代价就是一次送错货。
客户抢话、打断，系统怎么处理？
三件事要同时做到：在一个音节内停止播放、判断客户是在补充还是在纠正、 决定从断点继续还是重播整句。第一件靠播放缓冲与端点检测的联动， 第二件靠意图判断，第三件靠话术设计。
这套机制做不好的典型表现是：客户插了一句「不是这个」，系统还在把上一句播完， 然后接着问下一个问题 —— 客户会立刻意识到对面没有在听。
自建一套要多少算力？
取决于并发，而不是取决于通话总量。要算的是「同时在通话的路数」乘以每路的算力需求， 再按峰值留余量。识别可以多路共享 CPU，合成与大模型要按并发预留 GPU。
一个务实的起点是先按目标并发的一半配，跑两周看实际的峰值占用与 P95， 再决定加卡还是优化话术。直接按「全年通话量」配机器， 大概率会买多，或者买错方向。