停说到出声：每一段时间去哪了（口型方案对比）
沿用原页面的分段与口径。A–D、G 是原页面直连实测的中位数，对所有方案相同；E、F 是本次实测（每种方案 8 条真实 Qwen 回复 × 2 轮，中位数）。最快的是 v3.0 · 320/160/160，合计约 1.81 秒。
五种方案对比（同一时间轴）
差别全在蓝色的脸部两段（E 等口型所需音频、F A2F 计算）。前文越长，开闸要等的音频越多，E 越长。各段顺序与上图相同，鼠标悬停看每段名称和耗时。
对比视频（vis.glb 渲染，同一段语音同步播放）
上：v3.0 非流式（最左，参考）与四种切分的 v3.0 流式，每张脸下标注该方案的首字多等和贴合度。下：v2.0 原版（5090）流式、v3.0 流式（320/500/160），以及两者的整段结果。底部为关键口型参数的动态数值条和嘴唇开口曲线。
v3.0：非流式 + 四种切分
v2.0 原版（5090）vs v3.0
节点表（中位数，各方案的时刻）
句间与窗口（回复播放途中）
“句间”指回复播放途中因口型或声音没跟上而多出来的停顿；余量是整条回复里口型最紧张时比播放提前多少。
怎么测的、哪些是估算
- A–D、G 沿用原页面（10-20 直连、10 轮真实对话的中位数），与口型方案无关，本次没有重测。静音等待、“上传 + VAD 判定 + 回传”的测法和估算方式见原页面。
- E、F 本次实测：把 8 条录下来的 Qwen 回复按原始到达时刻逐块喂进前台自己的 live_face 流式代码，真实请求双 5090 上的 A2F（v2.0 为原版 audio2face_parallel 的 52100/52101，每卡 32 路；v3.0 为 52300/52301，每卡 1 路）。放声规则与 live.js 相同：口型覆盖 480 ms 才开闸，2.5 秒兜底。
- E = 首段回复语音到达 → 决定开闸的那段窗口的音频凑齐；F = 这段送 A2F → 口型发回、闸门打开（含局域网往返、服务端计算、等并发名额与超时重发）。
- A–D、G 来自原页面，E、F 来自本次，各段中位数相加作为合计；P95 = 原页面 A–D、G + 本次脸部等待的 P95。
- Mac 与 5090 之间是无线网络（本次 ping 平均约 40 ms、峰值约 130 ms）；没有做真人浏览器端到端测试。