为什么 700ms 是一条分水岭
人类日常对话的神经传导时间约为 200–400ms——这是生理层面的"思考间隙"。 在电话沟通中，大脑对停顿的容忍边界约在 1.2–1.4 秒： 超过这个阈值，人会本能地确认"你还在吗？"，触发高代价的话语修复序列。
700ms 之所以重要，是因为它在留有通信网络往返时延（RTT）余量的情况下， 仍能保证最终用户感知到的停顿在 1.1–1.3s 以内——就在沉默确认反射的临界点之下。 超过 700ms 的系统端时延，加上 100–200ms 的网络 RTT，就越过了用户体验的悬崖边缘。
主流厂商端到端延迟实测对比
AiWma 在 Xmohe 部署阶段的 A/B 测试数据显示：当系统延迟从 1.8s 降至 780ms 后， "用户主动挂断率"下降了 23%，"转人工请求率"下降了 17%。 更低的延迟不仅是体验提升，更是可量化的运营成本降低。
三段管道：延迟的来源与分布
一次完整的 AI 语音交互由三个顺序阶段组成，每个阶段都有其物理下界和工程优化空间：
首词输出
输出时延
首帧输出
国内节点
第一段：ASR——从音频流到文字流
语音识别（ASR）的延迟优化关键在于流式识别而非批量识别。 传统方案等待用户说完整句后才提交识别，这本身就引入了 300–600ms 的等待窗口。 流式 ASR 在用户说话过程中持续输出实时文本假设（hypothesis）， 在停顿检测（VAD, Voice Activity Detection）触发时锁定最终结果。
AiWma 使用 Deepgram Nova-3 作为 ASR 引擎，原因有三： 中文普通话识别准确率与科大讯飞接近（98%+）、原生支持流式输出、 以及比国内厂商更低的流式首词输出延迟（实测约 120–180ms P50）。 对于方言需求较高的场景，AiWma 支持切换至科大讯飞讯飞听见流式 API。
第二段：LLM 推理——首 Token 时延是瓶颈核心
LLM 推理延迟中，真正影响用户体验的是 TTFT（Time To First Token）， 而非完整生成时间。只要第一个 Token 开始输出，TTS 就可以立刻启动合成—— 这是流式架构的核心价值所在。
不同模型的 TTFT 差距巨大。以 AiWma 生产环境数据为例：
意图缓存是降低 P50 TTFT 的关键手段——对于重复率高的客服场景（如"查询订单状态"占全部请求的 40%+）， 缓存命中可以将这类请求的 LLM 延迟直接压缩至毫秒级， 拉低整体系统的平均 TTFT 显著低于裸推理延迟。
第三段：TTS——首帧输出而非完整合成
TTS（文字转语音）合成不需要等完整文本生成完毕后才开始。 流式 TTS 可以在接收到第一个完整句子（约 10–15 个中文字符）后立刻开始合成， 后续音频帧与 LLM 继续生成的文本并行流式处理。
AiWma 使用 CosyVoice 2 进行 TTS 合成，首帧输出时延约 160–200ms（P50）。 语音码率设置为 16kHz/16bit，在语音质量与带宽之间取得平衡。 针对高并发场景，TTS 合成服务独立水平扩展，不与 LLM 推理争抢 GPU 资源。
Pipecat 架构：流式管道的胶水层
三段管道的技术选型解决了各段的延迟问题，但三段之间的协调同样关键。 AiWma 使用开源框架 Pipecat 作为流式管道的编排层：
# AiWma 核心管道简化示意（Node.js + Pipecat 概念）
AudioInput ──→ VAD ──→ Deepgram.stream()
│ (流式文本假设)
▼
IntentCache.lookup()
│ (缓存未命中时)
▼
Claude / Qwen2.5.stream()
│ (首Token即触发)
▼
CosyVoice2.stream()
│
▼
AudioOutput ──→ WebSocket → ClientPipecat 的关键设计是将整个链路视为一个事件驱动的异步流水线， 而不是顺序的请求-响应周期。VAD 检测到停顿时，ASR 最终结果和 LLM 请求几乎同时触发； LLM 的第一个完整短句输出后，TTS 立刻启动，与 LLM 后续输出并行进行。
六个工程决策，决定你的系统能否达到 700ms
合规模式下的延迟代价
PIPL 合规要求在处理 L2/L3 级别的敏感个人信息时，不得将数据上传至云端 LLM。 这意味着需要切换到本地部署的模型（AiWma 使用 Qwen2.5:7b）， 这会对延迟产生一定影响。
然而，本地模型的 TTFT 并不必然更差：Qwen2.5:7b 在 A100 GPU 上的 TTFT P50 约为 180–250ms， 低于 Claude API 的 280ms（因为省去了网络往返）。代价在于 GPU 资源成本和相对较弱的复杂推理能力。 AiWma 的分级策略是：L0/L1 路由至 Claude，L2/L3 路由至本地 Qwen2.5—— 既保证合规，又针对不同场景优化延迟与能力的权衡。
延迟工程的本质是：在物理约束的边界内，找到正确的并行化切入点。 大多数系统不是被某一个阶段拖慢的，而是被顺序等待本可并行的操作拖慢的。
监控与持续优化
700ms 不是一个一次性达成的目标，而是需要持续监控的运营指标。 AiWma 的可观测性体系追踪以下关键指标（通过 Pino 结构化日志 + PostgreSQL 时序存储）：
asr_first_word_ms— ASR 首词输出时延（P50 / P95 / P99）llm_ttft_ms— LLM 首 Token 时延（区分缓存命中 vs 未命中）tts_first_frame_ms— TTS 首帧音频输出时延e2e_latency_ms— 端到端系统延迟（VAD 触发到客户端开始播放）barge_in_rate— 用户打断率（高打断率可能提示 AI 回答过长）silence_confirm_rate— 沉默确认率（"你还在吗？"——直接反映延迟过高的用户感知）
延迟数据来自 AiWma 生产环境 P50 指标及公开厂商信息（2025 年 12 月）。 各厂商延迟数据来自独立评测机构综合调研，非厂商自测。 实际延迟因网络环境、并发量及配置差异而变化。