为什么要把延迟拆开算

语音对话卡顿，最常见的处理方式是「换个更快的模型试试」。但这一步经常白做—— 因为你不知道那一秒钟到底花在哪儿了。它可能根本不在推理上，而在流水线主动等你的那几百毫秒里。

一次语音回合的首响应延迟，大致由这样一串组成：你停止说话 → VAD 判定这是一段静音 → Smart Turn 校验「这轮真的说完了吗」并产生对应的等待 → STT 把音频转成文本 → LLM 吐出第一个 token → TTS 合成出第一块音频 → 经网络传到你耳朵里。

这一串里，前半段和后半段的性质完全不同，而这正是这个工具把输入分成两类的原因。

两类数字，别混着看

A 类是流水线配置引入的等待。它们是 speech-to-speech 仓库里的参数， 页面里给出的默认值取自该仓库的参数默认值——是配置项没被改动时的取值，不是实测延迟。 这类数字的特点是：你改配置它就变，而且变化是确定的，不依赖任何硬件。

B 类是算力引入的耗时。STT 转写、LLM 首 token、TTS 首包、网络往返。 这四段取决于你选的模型、跑在什么卡上、服务部署在哪、并发多少。 本站没有跑过任何一台机器，所以这四个输入框里一个预设数字都没有， 必须你自己测了填进去。这不是偷懒，是给不出来——凡是给你「参考区间」的表格， 你都该先问一句它测的是哪块卡、哪个模型、什么并发。

三条路径分别怎么等

Smart Turn 是一个外部模型（pipecat-ai/smart-turn-v3，CPU ONNX）， 用当前轮次的内容与韵律来校验 Silero 给出的「说完了」判断。它默认是开的， 要关得显式传 --no_smart_turn。判定结果不同，等待项的组成就不同：

• 判定完整：立刻开始处理，提交输出前使用推测重开窗口。 等待项 = min_silence_ms + speculative_reopen_ms。
• 判定不完整：先晾一会儿再启动 STT/LLM，让可能恢复的语音有机会 在昂贵计算开始之前把这次修订作废。等待项 = min_silence_ms + smart_turn_incomplete_delay_ms，而输出继续被 smart_turn_max_wait_ms 门控。
• 关闭 Smart Turn：没有不完整这条路，回到 min_silence_ms + speculative_reopen_ms。

所以这几个毫秒数字买的不是延迟，而是误判成本—— Silero 一说「完了」就开工能省时间，但用户只是喘口气的话这活就白干了。 Smart Turn 给「白干」上了一个成本可控的闸。参数细节可以看 VAD 参数全解和 Smart Turn 的判定机制。

怎么用

第一步，选路径。你想分析哪种情况？句尾干净利落的短问句多半走「判定完整」， 说话带思考停顿的长句更容易走「判定不完整」。两条都算一遍，差值就是不完整判定给你带来的额外等待。

第二步，A 类按需改。如果你改过配置，把你实际启动命令里的值填进去； 没改过就留着默认。注意 min_silence_ms 默认只有 64—— 这个值很小，切得很碎，别把它记成 640。

第三步，B 类老老实实测。最省事的做法是在流水线各环节前后打时间戳， 跑十几轮取个中位数，别用第一次冷启动那一轮（模型加载会把数字撑得很难看）。 网络往返在本机跑就填 0。

第四步，看「最大的一段」。如果最胖的是 A 类，说明你卡在配置的等待上， 改参数就能动——但要清楚代价是误判成本上升。如果最胖的是 B 类，改流水线参数没用， 得从模型、量化、硬件或部署位置上想办法。

为什么门控上限不加进合计

smart_turn_max_wait_ms（默认 2000）经常被误当成「不完整轮次要等 2 秒」。 它不是一段串行耗时，是一个上限：判不完整时那 600 ms 的延迟跑在这个宽限期之内， 输出继续被它门控；期间只要语音恢复，现有轮次就被重开为一个更新的修订版， 累积的音频重新发出，上一版的工作在到达用户之前就被丢弃。

把上限加进总和，等于把「最坏情况的天花板」和「这一次实际串行的等待」混成一个数。 所以页面把它单独列出来。三个重开窗口之间还有钳制关系，容易讲错， 单独写在三个重开窗口的层级关系那篇里。

它算不了什么

它不预测你的延迟。它只把你填的数加起来，再告诉你哪一段最胖、各占多少。 真实链路里还有一堆这里没建模的东西：音频采集与缓冲、进程间排队、TTS 播放启动、 抢话与重开导致的返工。而且 A 类是「等待」、B 类是「计算」， 在真实实现里未必严格串行——推测式执行本来就是让计算提前于确认发生的。

它也不会告诉你「你的显卡够不够」「这个延迟算好还是坏」。 本站没有任何实测数据，任何关于「某某模型首 token 大约多少毫秒」的说法都不会出现在这个页面上。 想了解整条链路的拆法，可以接着看 语音延迟预算怎么拆， 或者从speech-to-speech 专题进去按顺序读。