把 AI 开口时间从 3 秒多压到 1 秒：一笔延迟分解账

做实时语音 AI 这半年，我最深的体会是：用户不会夸你延迟低，但一定会嫌你慢。 你说完一句话，AI 三四秒才开口——这个静默期足以杀死「对话感」，再好的音色和内容都救不回来。面对面聊天的自然停顿大约在 1 秒以内，这就是及格线。

我的系统一开始的成绩：光「判断你说完了没」就要 3.3 秒；一路优化后真实端到端还剩约 2.5 秒。现在：感知上不到 1 秒。这篇文章把这笔账一段一段摊开。

先立方法论：延迟不是一个数，是一条链

「AI 开口慢」是一个笼统的感受，背后其实是一条流水线：AI 判断你说完了没（判停）→ 大脑想出第一个字（模型首字）→ 嘴巴发出第一个音（合成首音）。三段各有各的账，混在一起就没法优化。所以第一步不是调参，是把每一段的耗时都量出来——量不出来的东西砍不动。

第一笔：判停——最大的隐形浪费

最反直觉的发现是：大头不在「AI 想得慢」，在「AI 等得久」。 你话音落下后，系统要等一段静音才敢确认「他说完了」——这个等待在我最初的配置里长达 3 秒多。也就是说，用户抱怨「AI 反应慢」的时候，AI 其实还没开始想，它在傻等。

这一段的优化分两步：先把语音识别服务的判停窗口从默认的近 3 秒压到 1 秒左右；再叠加「语义判停」——不死等静音，AI 根据你这句话说没说完来提前收口——最终压到 0.6 秒左右，这已经接近这类架构的物理极限。一段链路，砍掉了全程最大的一块。如果你只有时间优化一处，先查判停。

第二笔：大脑抖动——两个模型赛跑

模型出第一个字的速度，平时几百毫秒，很稳。但一到网络或服务高峰抖动，同一个模型可能要等几十秒——快时不到 1 秒、抖时 40 秒，这种「偶尔特别慢」比「一直有点慢」伤害大得多，因为用户无法建立预期。

我的解法不是换更贵的模型，是让两个模型同时起跑，谁先出声用谁，慢的那个直接作废。这比「等超时了再切备胎」好在：你根本不用猜该等多久。抖动被赛马结构吸收掉了，用户永远拿到两者中较快的那个。

第三笔：深度思考模式的代价

一个容易踩的选型坑：现在很多模型默认开着「深度思考」（回答前先自己推理一轮）。对写代码、做分析是好事，对语音对话是灾难——实测同档模型，开着思考模式的首字时间是不开的六倍以上（几秒 vs 几百毫秒）。语音场景选型的第一条筛选标准应该是：思考模式能不能关掉。

第四笔：嘴巴的最后一截

合成语音的首音也有零碎的账：比如每次开口前才去建立与合成服务的连接，一次握手就白白多花两三百毫秒——改成连接池（提前把连接建好养着）就省下来了；再比如通话链路的回声消除模块有个「热身期」，冷启动时会吃掉开头几百毫秒甚至几秒的音频，表现为「AI 听漏了你的第一个字」——这类问题不量到具体模块头上，永远只会被归咎为「网络不好」。

第五笔：砍不动的部分，让感知替你扛

物理极限摆在那：有些回答就是需要一两秒的真实计算。这时候的解法从工程转向体验设计——在完整回答就绪前，先让 AI 自然地接一句话：「嗯，这个问题有意思」「让我想想啊」。

关键是这句承接不能瞎哼：我按用户话语的语义分了几十条承接语料，根据你说的内容选那句最像「听懂了」的——问难题接「让我想想」，报好消息接「哇真的呀」。承接句的时长还要和真实回答的就绪时间对齐，不然就会「垫了话还是冷场」。这一层做完，感知首响从约 2.5 秒进到 1 秒以内——用户的体感是「它反应真快」，尽管完整答案还在路上。

账本合计

判停 3 秒多 → 0.6 秒；模型首字用赛马吸收抖动；语音场景关掉思考模式；合成连接池化、回声消除热身期从 3 秒压到 0.5 秒；最后用语义承接句盖住剩余延迟。每一步都对应一段被量化过的耗时——低延迟不是一个大招，是一笔一笔省出来的账。

这套系统是我一个人 vibe coding 搭起来的，AI 是我的手脚，我负责定标准和验收——包括这份账本本身，每个数字都是真机量出来的。