GPT-Live架构拆解：实时语音系统如何兼顾低延迟与可扩展性

导语

连续语音交互的难点，不只是让模型“听懂并回答”，还要让语音在等待工具、调用外部服务或执行后台任务时保持自然流畅。OpenAI在GPT-Live工程报告及相关采访中披露的方案，核心思路是把最敏感的媒体链路与其他应用能力彻底分层，再用有状态推理和生产环境验证补足系统的可用性。

核心架构：实时路径保持足够短

GPT-Live的实时路径主要包含两部分：媒体处理管道和推理循环。语音数据的接收、处理以及模型响应需要优先保证连续性，因此任务委派、工具使用、数据持久化和其他应用逻辑都被放到异步RPC边界之后。这样做的好处是，工程团队可以集中优化真正影响交互感受的环节，而不会让某个延迟不可预测的外部依赖阻塞语音通道。

这种解耦并不意味着后台能力不重要。相反，任务交给更强模型、把语音输入接入安全系统等工作，仍然需要专门设计。只是它们不再与“语音必须畅通无阻”的关键路径绑定，从而更容易分别进行性能和可靠性优化。

有状态会话与上下文迁移

连续对话天然依赖上下文，但将状态固定在单一实例上，又会限制扩缩容和故障恢复。GPT-Live采用专用的有状态推理机制，为每个会话在分配的实例上预留容量。当实例需要释放资源，或会话接近上下文限制时，系统可以把上下文迁移到新的模型实例，并将新会话引导到仍有容量的实例。

这一设计在状态连续性与基础设施弹性之间取得折中：会话不必因为实例调整而重新开始，平台也能根据需求动态改变实例数量。代价是运维系统需要准确处理容量预留、迁移时机和上下文一致性，整体复杂度会高于完全无状态的推理服务。

为什么继续采用WebRTC

OpenAI没有直接替换WebRTC，而是在其基础上推出WebRTC Abridged Roundtrip Protocol（WARP）和即时连接机制，以缩短启动延迟。原因在于WebRTC已经提供了经过验证的低延迟媒体能力和错误恢复机制；一些新型协议虽然有潜力，但往往只覆盖传输层，还缺少完整媒体管道，以及GCC拥塞控制、基于RTT的路径选择等能力。

WARP中的改进可以独立部署和验证，现有WebRTC应用也无需修改代码即可受益。这种渐进式路线降低了同时更换客户端和服务端传输栈的风险，也更适合大规模实时产品的运营现实。

用真实流量做“静默测试”

上线前，GPT-Live还采用了静默测试：在只读模式且不使用用户凭据的前提下，将真实入站语音流量输入系统，但直接丢弃模型输出。这样既能检验媒体循环和推理服务，也不会改变用户体验。

与预录或合成语音相比，真实流量包含更丰富的说话方式、地区分布和负载组合。测试曾发现部分地区的GPU与提供数据的CPU不在同一机房，形成额外延迟。这说明实时AI系统的瓶颈可能来自部署拓扑，而不只是模型本身。对其他语音产品而言，实时路径隔离、状态迁移和无感生产验证，或许比单纯追求更快模型更值得优先建设。

来源：InfoQ 中文