GPT-Live 如何实现真正的实时对话

语音 AI 领域长期存在一个根本性难题：系统必须判断用户何时说完话，才能开始生成回复。早期的级联架构将语音转文字、大语言模型推理、文字转语音三个环节串行执行，不仅累积了大量延迟，还丢失了语调、停顿等副语言信息。后来出现的语音到语音模型虽然直接处理音频，但仍依赖独立的轮次检测器来触发推理，对话本质上依然是「一问一答」的轮流模式。

GPT-Live 的核心突破在于将语音模型置于对话的主控位置。系统采用全双工设计，音频持续流入流出模型，不再需要外部检测器来决定何时开始推理。当对话涉及复杂推理或工具调用时，系统通过异步 RPC 边界将任务委托给 GPT-5.5 等前沿模型，这些后台操作与主音频路径完全隔离，即便某个工具调用耗时较长，也不会造成音频流的停顿或卡顿。

为保障媒体流的稳定性，工程团队做出了多项关键技术决策。媒体前端与推理逻辑从 Python asyncio 迁移至 Go，新系统的 p95 延迟指标已达到旧系统 p50 的水平，帧投递平滑度大幅提升。传输层采用 WebRTC 协议，该协议专为低延迟媒体设计，能够应对丢包、时钟漂移和客户端连接变化等网络异常，并通过细微的音频拉伸与加速来填补潜在的播放间隙。

有状态推理带来了新的运维挑战。语音会话可能持续较长时间，上下文随对话不断增长，而模型实例则根据负载动态启停。为此，团队构建了无缝的实例切换机制：在需要迁移时，系统会预热一个新实例并将当前会话上下文预填充进去，在新旧实例并行推理确认就绪后再完成切换，用户几乎感知不到任何中断。

上下文压缩是另一个需要精细处理的环节。随着对话积累，上下文长度可能超出模型限制，压缩操作不仅耗时，还会使模型的键值缓存失效，需要重新预填充。工程团队将压缩视为一种托管式状态转换，与实例切换采用相同的并行预热机制处理，从而将压缩引入的延迟对用户体验的影响降至最低。这套架构在应用层与核心语音路径之间建立了清晰边界，开发者可以自由调整工具、策略和后端逻辑，而不会影响音频前端的实时响应能力。

要点

• GPT-Live 移除了传统轮次检测器，采用全双工语音模型，实现了真正意义上的连续对话，响应节奏首次接近人类自然交流
• 媒体路径与应用逻辑严格分离，工具调用等后台任务通过异步边界处理，确保任何后端延迟都不会阻塞音频流
• 媒体前端从 Python 迁移至 Go，结合 WebRTC 传输协议，将 p95 延迟压缩至原系统 p50 水平，显著提升帧投递平滑度
• 无缝实例切换与动态上下文压缩机制解决了长时语音会话中的状态管理难题，用户几乎无法感知后台的模型迁移操作
• 该架构已在 ChatGPT 桌面端落地，支撑电脑控制与 Agent 协调等新功能，并为后续能力扩展提供了可复用的工程基础