延迟

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

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

典型一轮：

1. 用户说话 → Session 用 volume / hybrid VAD 听轮次
2. 实时分片进 ASR，持续出 asr_partial
3. silenceTimeoutMs 判定结束 → user_audio_end
4. LLM stream / Audio LLM 回文本或 PCM
5. 首包入播放器 → assistant_audio_start

实操建议

1. 用支持 partial 的流式 ASR，说话时就出字幕。
2. 噪声环境实测后把 silenceTimeoutMs 调到约 350–600 ms（默认偏保守，完整表见 core）。
3. 实现 LLMProvider.stream()，或 Audio LLM 的 onTranscriptDelta / onAudioChunk，避免等整段再播。
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 等）。

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