延迟

可感知延迟不是单次 HTTP 耗时，而是端到端流水线：

静音判定 → 上传 → 模型首 token / 首 PCM → 播放器排队

复合 audio-turn 后端的典型一轮：

1. 用户说话 → Session 跟踪本地麦克风音量
2. 实时分片进 ASR，持续出 asr_partial
3. 持续本地静音结束轮次 → user_audio_end
4. 网关把 LLM 首个完整句子/分句立即送入 TTS，后续 token 继续生成
5. 首个 PCM 分片入播放器 → assistant_audio_start

当前 Web 示例还有统一 audio-turn 路径：本地静音结束后只上传一次完整轮次。 原生 Audio LLM 与服务端 ASR → LLM → TTS 都可在同一 SSE 响应中返回输入转写、 助手文本和音频；后者以句子大小的 MP3 分片播放。这里没有滚动浏览器 ASR。

实操建议

1. 需要说话中字幕时，用支持 partial 的流式 ASR；若产品只需轮后权威字幕， 让 audio-turn Provider 返回输入转写可少一次请求。两者都不决定轮次边界。
2. 在目标设备上调 silenceTimeoutMs。Web 示例从 500 ms 开始；嘈杂环境或 说话较慢的用户可能需要更长时间。
3. 复合后端应流式读取 LLM，并尽早启动分句 TTS；这是后端 AudioLLMProvider 的实现细节，Core 只消费统一文本/音频流。
4. 复用连接与播放器；限制回复长度与 maxTokens。
5. 助手播放时启用更严的 interruptionDetection，避免回声误触发却又拖长真实插话。

怎么量

区间	事件	含义
轮次结束 → 首音	user_audio_end → assistant_audio_start	可感知首音频延迟（首选 KPI）
轮次结束 → 首字	user_audio_end → 首次 assistant_text_delta	文本 TTFT
说话中字幕	首个 asr_partial	输入侧体感

在目标设备、扬声器音量与真实噪声下采样，不要只看实验室静音环境。

兼容路径

滚动 partial（batch ASR） 会重复上传累计音频，适合 Demo。高并发生产优先 原生 WebSocket 流式 ASR（Deepgram / ElevenLabs 等）。ASR 适配器只提供临时与 最终转写片段；轮次结束独立于供应商分段和网络推理。

相关配置：TurnDetectionConfig、policy、事件指南。