实时 STT→LLM→TTS 链路

先决定你是不是真的需要模块化

STT→LLM→TTS 链路的价值不是“看起来更工程化”，而是每一层都能单独替换、计费、评测和回放。它适合电话 Agent、网页语音助手、通话分析、AI tutor 和需要多供应商策略的团队。LiveKit 的架构指南把实时语音延迟拆成传输、STT 首个 partial、LLM 首 token、TTS 首音频四段，并把自然对话目标放在 1 秒以内。这个数字不是硬规则，但足够提醒你：每多一次跨区域请求，体验都会变钝。

适合有工程控制需求的团队

如果你需要自定义词表、行业术语、独立 STT 账单、不同 TTS 声音、私有部署、通话回放或 provider fallback，模块化链路更合理。如果只是想快速验证一个语音产品，OpenAI Realtime、Retell 或 Vapi 可能更快。不要为了“可控”而承担你暂时用不到的复杂度。

不适合没有观测能力的团队

模块化最大的坑是责任被拆散后没人能解释失败。用户听到 2 秒停顿，可能是 WebRTC 抖动、VAD 误判、STT 等 final、LLM 工具调用慢、TTS 首音频慢，也可能只是你缓冲太多。没有 per-stage trace，模块化只会让排障更慢。

设计可测的参考链路

先做一条最小生产链：WebRTC 或电话媒体输入、VAD、streaming STT、LLM、streaming TTS、播放控制、事件日志。每个节点都要写入同一个 call timeline。第一版不要追求多模型路由，先让一条链路在真实噪声下稳定跑完 100 通测试。

给每一层预算，而不是只看总延迟

可以从 LiveKit 给出的参考开始：WebRTC 传输尽量低于 50ms，STT partial 约 100-200ms，LLM 首 token 约 200-400ms，TTS 首音频约 100-300ms。中文、电话窄带音质、远距离 region、复杂工具调用都会把这些数字推高。预算的作用不是保证达标，而是快速发现哪一层在失控。

先优化位置，再优化模型

非直觉的一点是，很多延迟不是模型慢，而是媒体服务器、模型 endpoint 和业务后端跨区域。把 LiveKit worker、STT、LLM、TTS 和业务 API 放在相近区域，往往比换一个更贵模型有效。等网络路径稳定后，再比较 Deepgram、Cartesia、ElevenLabs 或自托管模型。

把工具调用当成链路的一部分

Voice Agent 经常需要查订单、改预约、取 CRM 信息。工具调用不能只算在 LLM 里，要单独记录开始、结束、失败和可否取消。用户插话时，TTS 可以取消，但数据库写入不一定能取消；这类规则要写进 pipeline policy，而不是留给模型临场发挥。

按层选择工具

LiveKit 适合把实时媒体、Agent session、插件和观测放在一起；Pipecat 适合需要更自由拼装的开源链路。Deepgram 的公开价格页显示 Nova/Flux STT 从 $0.0077/分钟起，约 RMB 0.056/分钟起；Cartesia 的 Free、Pro $4/月、Startup $39/月和 Sonic/Line 能力适合做低延迟 TTS 与 Agent 原型；ElevenLabs 适合对品牌声音有要求的团队。

托管和自托管要按运维能力算

自托管看起来便宜，但你要负责 worker 扩容、排队、重试、区域调度、音频存储和故障回放。托管平台每分钟更贵，却可能减少上线时间。判断标准很简单：如果你现在还没有稳定的事件追踪和告警，先用托管或半托管把产品跑起来，再决定要不要下沉。

用本地教程理解组件边界

页面里的 LiveKit 本地 Agent 视频把 Whisper、LLM、TTS 和 LiveKit 放进一个可运行示例，适合理解组件如何互相连接。它不是生产架构模板，但能帮助团队看清每一层的输入输出，再把云端 provider 或自托管模型替换进去。

上线前保留回放能力

预上线检查不只是“能说话”。你要能回放 10 条失败通话，看到每一层耗时和事件顺序；能把同一段音频重新跑过新参数；能统计 P95 响应时间、STT 空白率、TTS 首音频、工具调用失败率和用户重复提问比例。等这些数据稳定后，再谈扩容和成本优化。

把模型替换做成实验

每次换 STT、LLM 或 TTS，都用同一批音频和同一批任务跑 A/B。只听 demo 很容易被声音质感骗过；真正影响留存的是错误恢复、打断、长尾口音、工具调用和账单稳定性。模块化的价值就在这里：你可以有纪律地换一层，而不是重做整套产品。