我们如何在六个月内构建出响应式语音AI的实时系统

我们如何在六个月内构建出响应式语音AI的实时系统

💡 原文英文,约2700词,阅读约需10分钟。
📝

内容提要

GPT-Live是OpenAI第三代语音系统,采用全双工架构,无需独立语音检测器,可同时听和说。系统通过流式推理、异步委派、动态上下文管理和WARP协议优化,实现低延迟自然对话。它支持调用GPT-5.5等模型进行深度推理,并已通过静默测试验证生产环境可靠性。

🔎

延伸解读

全双工架构的突破

传统语音AI依赖独立的语音检测器来判断何时开始响应,但GPT-Live采用全双工架构,无需检测器即可同时听和说。这消除了检测延迟,使对话更自然。文章指出,这种架构让系统能捕捉语调、节奏等非文本信息,提升了交互质量。

异步委派与响应速度的平衡

GPT-Live在保持流畅对话的同时,通过异步委派调用GPT-5.5等模型进行深度推理。系统优化了委派路径,包括预填充推理会话和稳定会话亲和性,以缩短响应时间。这种设计将“说话”与“思考”解耦,确保复杂任务不阻塞实时交流。

WARP协议与启动优化

为降低会话启动延迟,OpenAI开发了WARP协议,将媒体和数据启动从六次网络往返减少到一次。通过预协商和协议改进,客户端只需发送一个UDP数据包即可开始会话。这显著提升了用户体验,尤其对网络条件不佳的用户。

生产环境测试的启示

静默测试暴露了容量规划、地理分布和长会话等问题。文章强调,容量不能仅看GPU吞吐量,还需考虑CPU处理、队列和网络路径。此外,地理距离影响延迟,需将推理部署在用户附近。这些发现对构建实时系统具有普遍参考价值。

Q&A

GPT-Live的语音系统与之前的系统有什么主要区别?

GPT-Live是第三代语音系统,采用全双工架构,可以同时听和说,无需独立的语音检测器。之前的系统是基于轮次的,依赖语音检测器来决定何时开始推理,而GPT-Live将语音模型置于对话控制中,音频流直接进出模型,更自然和即时。

GPT-Live如何实现低延迟的语音交互?

GPT-Live通过流式推理、异步委派、动态上下文管理和WARP协议优化来实现低延迟。它使用专用的媒体快速路径,将媒体流与业务逻辑分离,并采用Go语言编写媒体前端和推理逻辑,提高了帧传输的流畅性。此外,WARP协议将启动时间从六个网络往返减少到一个。

GPT-Live如何处理长时间对话中的上下文管理?

GPT-Live采用动态上下文管理,通过无缝切换机制处理模型实例的更换和上下文压缩。当需要切换时,会预热新的模型实例,预填充当前会话上下文,并行运行推理,然后切换。上下文压缩也作为受管理的转换,在后台进行,不影响媒体流。

GPT-Live如何在不中断对话的情况下调用GPT-5.5等模型进行深度推理?

GPT-Live通过异步委派机制,将深度推理和工具使用放在单独的异步路径上,与媒体流分离。当需要时,会预先设置好前沿模型和工具,并保持推理会话可用,通过稳定会话亲和性和提示缓存优化延迟,使得结果能快速返回并融入对话。

GPT-Live如何从连续的语音流中提取离散的对话轮次?

GPT-Live的应用服务器使用部分转录和时序信号来推断说话者并构建消息队列。最新的消息保持临时状态,直到说话者持续足够长的时间才最终确定。系统维护两个视图:推测视图用于UI,权威记录用于日志,以平衡新鲜度和确定性。

WARP协议是什么?它如何减少启动延迟?

WARP是WebRTC Abridged Roundtrip Protocol的缩写,通过一系列向后兼容的协议改进,将媒体和数据启动时间从六个网络往返减少到一个。它通过将DTLS握手与ICE结合、使用DTLS 1.3、预协商SCTP握手和数据通道来实现。

GPT-Live在生产环境中是如何进行安全测试的?

GPT-Live通过静默测试进行安全测试,将一部分生产流量路由到新系统,但以只读模式运行,不影响用户体验。测试暴露了容量、地理分布、长会话等问题,并促使改进可观测性和部署控制。

🏷️

标签

➡️

继续阅读