OpenAI 这篇技术文章详细介绍了其第三代语音系统 GPT‑Live 的架构设计，该系统仅用六个月建成，核心理念是让语音“流动”起来。

核心痛点是旧架构的“轮流制”（turn-based）。 之前的语音系统依赖一个独立的“轮流检测器”来猜测用户何时说完，猜早了会打断用户，猜晚了响应感觉迟钝。而且老系统是串行的：语音转文字 → LLM → 文字转语音，每一步都增加延迟，并且丢失了语调和节奏等关键信息。

GPT‑Live 的解决方案是“全双工”（full-duplex）。 其语音模型能够同时听和说，因此移除了音频路径中的轮流检测器。对话变得更加即时和自然。当需要更深的推理或使用工具时，GPT‑Live 可以异步咨询 GPT‑5.5 这类前沿模型，而不会中断对话的音频流。

新架构的关键工程决策是分离“媒体流”与“应用逻辑”。 音频在客户端和语音模型之间走一条专用的快速路径（fast path）。而委托、工具调用等应用层工作则通过异步 RPC 边界在后端完成。这样，即使某个工具调用或后端服务延迟，也不会阻塞核心的媒体流。这种分离也使得定制应用行为变得简单，而不会影响响应性。

架构的几大核心组件：

1. 持续推理（Continuous Inference）： 系统重写了模型推理、上下文管理和媒体传输，以支持持续的音频流。媒体前端和推理逻辑从 Python asyncio 重写为 Go 语言，显著提升了帧传输的平滑度，新系统的 p95 延迟追平了老系统的 p50。

2. 有状态推理与无缝切换（Stateful Inference & Handoff）： 语音会话可能持续很长时间。当需要轮换模型实例或进行上下文压缩（compaction）时，系统会先在一个新实例上预热并预填当前会话上下文，然后新旧实例并行推理，待新实例完全就绪后再无缝切换，确保对话不被中断。

3. 异步委托（Asynchronous Delegation）： 当 GPT‑Live 需要调用更强大的模型时，在语音会话启动时，应用服务器就已预先为前沿模型创建推理会话并预填了上下文。这套机制和提示缓存技术一同工作，让深度思考的结果能快速融入对话。

4. 加速连接协议（Instant Connect & WARP）： 传统 WebRTC 启动需要多次握手。团队设计了开放规范的 WARP 协议，将支持从 libwebrtc 和 Pion 开始。同时，通过 Instant Connect 技术，SDP 参数协商被提前完成，客户端只需发送单个 UDP 数据包即可启动会话，极大缩短了从用户操作到媒体流通的时间。

生产测试暴露了真实挑战： 团队进行了静默测试（影子路径），将真实流量同时分发到新旧系统。测试发现，容量瓶颈不在 GPU，而在于 CPU 侧的流处理器、队列和网络路径。系统能承载的“并发会话数”比“GPU 请求数”更关键。长时间运行的会话暴露了内存和持久化压力，网络重连触发了状态恢复问题。这些经验强化了一个认知：端到端的响应性依赖路径上的每一个服务。