低延迟、背压与抖动

为什么需要

只报告“模型首包 300 ms”会漏掉采集缓冲、endpointing、上行、排队、工具、下行、jitter buffer 和设备播放。更糟的是，无界排队可以让吞吐看似稳定，却让用户听到几秒前已经取消的回答。

怎样实现

建立同一单调时钟上的分段预算：

用户开口
→ 首帧采集 → speech_start → turn_commit
→ 模型/工具开始 → 首个可播放 chunk
→ 实际扬声器播放 → response 完成

每段记录 p50/p95/p99、超时和按网络/设备/语言切片的分布。端到端指标至少包括：

• turn endpoint delay；
• response first-audio 与首个实际播放；
• 用户开口到旧播放停止（barge-in stop）；
• 工具调用等待及完整任务时长；
• 音频 underrun、丢帧、迟到帧和 canceled chunk 泄漏。

背压必须有容量和策略：输入队列逼近上限时可降低非关键模态频率、调整编码/帧长、触发流控或有解释地终止；不能静默无限积压。输出队列只接受当前 response_id，取消后清空并拒绝迟到 chunk。jitter buffer 用额外延迟换稳定播放，应在网络切片中调参，不能按办公室 Wi-Fi 一次定值。

对于视频/屏幕，共享带宽时要明确优先级：例如语音控制优先于高分辨率画面；降帧必须保留时间戳和“丢弃了什么”的证据。绝对墙钟用于跨系统关联，持续时间和顺序用单调时钟，避免时钟回拨造成负延迟。

常见失败

• 只测平均值或服务端处理时间，不测尾延迟与实际播放。
• 为避免丢帧设置无界 buffer，结果是越来越旧而非实时。
• interrupt 只清服务端队列，没有清浏览器/设备播放队列。
• 将 ASR partial 越早视为越好，忽略频繁修订导致的误行动。
• 负载测试没有真实并发工具、网络损伤和冷启动。

怎样验证

在可控 trial 中注入带宽下降、丢包、乱序、100–500 ms jitter、工具长尾和设备切换。验证队列上限、流控、降级、timeout 与告警确实触发；将每次 trial 的初始状态、trace、终态和网络配置一起保存。声音自然度测试不能替代任务成功和恢复测试。

实践任务

为一个目标 p95 端到端时延写分段预算表。人为让某一段增加 400 ms，说明应牺牲画面帧率、TTS chunk 大小、endpointing 等哪一项，以及怎样防止“优化”提升误打断或误行动。

依据与下一步

W3C Media Capture and Streams指出实时远端媒体有时宁可短暂失步，也不应无限积累延迟；具体网络与播放算法仍由实现决定。Full-Duplex-Bench说明实时交互还要测 pause、backchannel 和 interruption，而非只有文本质量。下一步：工具调用与对话状态。