有个非常大的疑惑，对话类VAD检测是否可以去掉

[liuhong1happy]

针对对话类客户端，客户端已经做了VAD，FunASR是否可以去掉VAD检测，加快对话节奏。
VAD服务端检测时间阈值，最短也需要200ms，对话类客户端要求总体 ASR/TTS 不要超过450ms，所有有服务端VAD反而造成对话不自然。

这里讨论的主要是serve_realtime_ws.py

[LauraGPT]

可以支持“客户端负责 endpoint、服务端不再跑 VAD”，但当前 serve_realtime_ws.py 还不能通过参数安全地关闭 VAD，也不能只删除 vad.feed()：

• DynamicStreamingVAD 的 current_speech_start 和 segment 结果同时驱动 partial 解码、final sentence 锁定、audio buffer 压缩以及 speaker 路径；
• 当前 STOP 表示整个 session 结束，不是保持连接的逐句 endpoint；
• RealtimeASRSession.decode() 在累计音频不足 960 ms 时，即使 is_final=True 也会直接返回而不做 ASR；
• 第一次 partial 还固定等待 480 ms，默认 --decode-interval 也是 0.48 s。因此在现有协议下，仅省掉最短 200 ms 的服务端 VAD，并不能保证 ASR/TTS 总时延低于 450 ms。

#3240 只是在修复内外两套动态静音阈值互相覆盖的问题，它不会绕过服务端 VAD，也不会改变上述 480/960 ms 门槛，建议不要把两件事合并。

对于已经有可靠客户端 VAD 的对话应用，更合适的是增加独立的 client-endpoint 模式，例如：

1. START 建立持续连接；
2. 客户端持续发送 PCM；
3. 每个客户端 endpoint 发送 COMMIT，服务端直接解码这句话的完整 buffer，并清理逐句状态但不关闭连接；
4. client 模式不加载 FSMN-VAD，也不依赖 480/960 ms 门槛；speaker 开启时再对已提交的完整 utterance 处理。

先确认一个协议需求：客户端 endpoint 到达前，你们还需要服务端持续返回 partial 文本，还是只需要 COMMIT 后的一次 final 文本？如果只需要 final，首版可以明显更小，也更容易把端到端延迟测准。

[liuhong1happy]

出现完整partial 文本后，到首次final 文本，间隔时间应该不要超过太长（这里如果能做到200ms-450ms其实非常好了），才能应对 对话类应用的要求。 @LauraGPT
如果只是做会议转录，没有这个时长限制，反倒是识别准确性要求会更高一点。

[LauraGPT]

收到，这个需求可以确定为 partial + final，不是 final-only。为了让后续实现和验收不依赖主观感受，建议把协议收敛为：

1. 说话期间服务端继续返回 partial；
2. 客户端 VAD 检测到 endpoint 后，在同一条 WebSocket 上发送逐句 COMMIT，连接不关闭；
3. 服务端使用此前已经连续收到的 PCM 立即完成该 utterance，并返回一次 is_final=true；
4. 小于当前 960 ms 门槛的短句也必须能够在 COMMIT 后完成；
5. “最后一个已基本完整的 partial 到 final 为 200-450 ms”可以保留为用户体验指标，但更稳定的服务端验收指标应是 收到 COMMIT 到发出 final 的耗时，因为某个 partial 是否“完整”只能事后判断。

还需要确认两个边界：

• 你们的客户端 VAD 能否在继续复用连接的同时发送一个明确的 endpoint/COMMIT 事件，并且 PCM 是边录边连续发送、不是 endpoint 后才整句上传？
• 这里的 200-450 ms 是从客户端发出 endpoint 到收到 ASR final 文本，还是还包含后续 TTS 首包？后者需要拆分记录 ASR final 与 TTS 首包两个时间点，不能只靠这个 ASR 服务端脚本验收。

确认这两点后，协议和回归测试范围就可以固定下来。

[liuhong1happy]

可以确认两点的是：

1. 客户端VAD 也是持续性发送PCM数据，不是endpoint后整句上传。
2. 200-450 ms 只需要是客户端发出 endpoint 到收到 ASR final 文本，不需要再包含TTS首包时间，已经是非常好的体验了。

[LauraGPT]

确认，协议和验收边界现在已经完整：

• 客户端持续、实时发送 PCM；
• 服务端在说话期间继续返回 partial；
• 客户端 endpoint 后在同一条 WebSocket 上发送逐句 COMMIT，连接继续复用；
• 服务端收到 COMMIT 后返回该句 final，小于当前 960 ms 门槛的短句也必须完成；
• 延迟只统计客户端 endpoint/COMMIT 到收到 ASR final，目标为 200-450 ms，不包含 TTS 首包。

后续测试会直接记录服务端 COMMIT received -> final sent，客户端再记录 endpoint sent -> final received，并同时保留音频时长、模型、硬件和并发数，避免把网络、排队或 TTS 时间混进 ASR 指标。现有默认 server-VAD 模式和 #3240 的阈值修复是另一条路径，不会混在这个验收里。

[liuhong1happy]

这是我今天优化后的效果代码，看能否参考。

• realtime_chat_ws.py 优化后的流式服务
• realtime_chat_client.html 客户端测试

移除大部分需要反复timeout check的逻辑，仅保留服务端VAD和稳定文本结果判断快速出结果。
保留VAD的原因，还是需要去除噪音和连续说话后的分段。

稳定文本结果判断快速出结果逻辑参考：
https://github.com/liuhong1happy/FunASR/blob/b03661283c5ec4c74b0c61d9820604fd4696b0f3/examples/industrial_data_pretraining/fun_asr_nano/realtime_chat_ws.py#L188

目前来看，能做到 200-450 ms左右返回。

[LauraGPT]

感谢提供可运行原型。我按固定提交 b036612 做了源码检查、确定性状态机探针，以及 H100 上的真实音频测试。

先说有效的部分：预热后，Fun-ASR-Nano 在 H100 + vLLM 0.12.0 上对逐步增长的音频前缀单次推理约为 66–166 ms。客户端 ScriptProcessor(4096) 在 16 kHz 下每帧是 256 ms，所以“上一个 partial 到下一次相同文本 final”约为 256 ms + 90 ms，你观察到的 200–450 ms 是可以复现的。

但当前 相同文本 x2 => final 还不能作为可靠的句末条件。真实测试使用仓库的 5.547 秒 runtime/funasr_api/asr_example.wav：

• 2,304 ms 时 partial 为“欢迎大家来体验。”；
• 2,560 ms 时文本相同，原型立即返回 final；
• 此时 VAD 仍是 is_speaking=true，当前 speech 从 610 ms 开始，完整音频仍在继续；
• handler 随后 session.reset()，同一句被拆成第二个 final“达摩院推出的语音识别模型。”；
• 最后的 170 ms 尾音在 STOP 时又被识别为“啊。”。

这不是单个样本偶然不变：连续前缀在 2,304/2,560 ms、2,816/3,072 ms、3,584/3,840 ms、4,864/5,120 ms 都出现了“文本连续两次相同，但后续语音仍会继续增长”。文本稳定适合抑制重复 partial 或作为候选信号，不能单独证明 endpoint。

另一个关键点是：原型虽然保留了 VAD，但忽略了 vad.feed() 返回的 confirmed segment。用已经合并 #3240 修复后的 VAD，同一音频按浏览器 4096-sample 帧输入时，VAD 在 5,888 ms 确认 [610, 5450]；就在这个时刻：

• vad.is_speaking == false
• session.should_decode() == false
• 没有发送 final
• 5,888 ms 音频仍全部留在 buffer，直到显式 STOP

另外还有几项实现回退：

• first_chunk_ms=240 虽能通过 should_decode()，但 decode() 仍在小于 chunk_ms=480 时直接返回空 partial；
• ASR/VAD 在 WebSocket coroutine 内同步执行，移除了主干已有的 asyncio.to_thread 和共享模型锁，多客户端会阻塞 event loop；
• audio buffer 没有主干已有的 compaction，静音连接也会持续增长；
• auto-final 后时间轴从 0 重新开始，而客户端期待 start_ms/end_ms，多句会重叠。

建议把这个方向保留为独立的 server-VAD chat mode，但合并前至少满足：

1. VAD confirmed segment 或客户端 COMMIT 才能产生 authoritative final；is_speaking=true 时不能因文本相同而 final。
2. 文本稳定只用于去重 partial，或与明确的 endpoint/silence 证据组合，不能独立 reset utterance。
3. 保留主干的 off-thread 共享模型锁、buffer compaction 和 WebSocket keepalive 配置。
4. 统一 first-decode 门槛，并覆盖小于 960 ms 的 COMMIT 短句。
5. 增加回归：连续说话不被稳定文本切开、VAD endpoint 必须恰好返回一次 final、同连接多轮时间戳单调、并发 1/4/8 的 p50/p95。

如果按最初已经确认的协议实现，客户端持续发 PCM、逐句发送 COMMIT、服务端继续给 partial，并统计 COMMIT received -> final sent，边界会比“猜测 partial 是否已经完整”可靠得多。当前原型可以作为低延迟调度参考，但不建议直接替换主干会话状态机。

[LauraGPT]

#3245 已合并到 main，commit 为 bd6e72142f1c。

启动方式：

python serve_realtime_ws.py --endpoint-mode client

同一连接发送 START，持续发送 PCM，每个客户端 endpoint 发送 COMMIT；服务端会保留 partial，并返回一次 final 后继续复用连接。900 ms 短句和绝对时间戳已覆盖。H100 实测本机 WebSocket COMMIT -> final 为 52.92 ms。

请直接拉取最新 main 按你们的客户端 VAD 复测；如果线上 p50/p95 明显不同，请带并发数、音频长度和 endpoint-to-final 记录继续回复。