很多人把GPT‑Live理解为一次语音模型升级：反应更快、更像真人，也更会接话。但OpenAI最新发布的技术播客表明，GPT‑Live真正的变化远不止模型。为了让AI能够边听边说、随时被打断，并在复杂网络环境下保持流畅，OpenAI在6个月内重构了模型推理、上下文管理、媒体传输和会话启动链路。人与人对话时，可以在几百毫秒内完成话轮交接。我们会根据语气、停顿和上下文判断对方是否说完，也能自然地插入“嗯”“明白”等反馈。早期系统通常采用ASR、大模型和TTS串联的级联架构：先把语音转成文字，再交给大模型生成答案，最后合成为语音。多级处理不仅增加延迟，还会丢失语调、节奏等信息。后来的Speech-to-Speech模型虽然能够直接处理和生成音频，但交互依然采用轮次制。系统需要依靠一个独立的Turn Detector判断用户是否说完，然后才能启动大模型推理。判断太早，AI会打断用户；判断太晚，回应又显得迟钝。GPT‑Live的核心变化，是把独立的Turn Detector移出了实时音频链路，将对话控制权交给语音模型本身。音频不再被切分成一个个离散的“回合”，而是持续流入模型。GPT‑Live可以一边接收用户声音，一边生成语音，并不断判断自己应该继续倾听、短暂停顿、插话，还是调用工具。语音AI由此从“Turn-based”走向“Turnless”。在持续对话中，任何一处传输、处理或推理延迟，都可能变成用户能够听到的停顿、卡顿或音频异常。因此，OpenAI为GPT‑Live建立了一条独立的实时媒体通道。用户音频通过这条“快速路径”直接流向语音模型，模型生成的声音再实时返回客户端。搜索、工具调用、业务逻辑等任务，则被放在异步RPC边界之外执行。即使某个工具调用很慢，也只能推迟自己的结果，不能阻塞音频链路。这种设计还带来一个好处：开发者可以更换工具、策略和业务逻辑，而不影响底层媒体通道的实时性。为了提高音频帧交付的稳定性，OpenAI还用Go重写了媒体前端和推理逻辑，替换此前基于Python asyncio 的实现。结果是，新系统P95水平的帧传输表现，已经接近旧系统的P50水平。简单来说，即使在较差情况下，新系统也能达到旧系统正常情况下的流畅程度。相比普通请求—响应式API，WebRTC更适合持续、低时延的实时音频传输。它能够应对丢包、时钟漂移和网络切换等问题。当音频包延迟到达时，WebRTC可以轻微拉伸音频，避免出现空白；随后再适当加快播放速度，将会话重新拉回实时状态。OpenAI通过减少整条链路中的缓冲和阻塞，把响应控制在自然对话需要的亚秒级范围内。这也释放出一个明确信号：大模型决定AI说什么，而WebRTC等RTE技术决定用户什么时候能听到，以及整个对话是否足够流畅。一场语音会话可能持续很长时间，上下文不断增长，承载会话的模型实例也可能因为负载或资源调度发生变化。如果直接切换模型实例，可能导致音频中断；如果先停止对话再重建上下文，用户又会感受到明显等待。需要切换时，系统会在现有模型继续运行的同时，启动一个新的模型实例，将当前会话上下文提前填充进去，并让两个实例短暂并行推理。等新实例完全准备好后，再将会话切换过去。当对话越来越长、接近模型上下文上限时，系统会在后台压缩历史信息，并为压缩后的上下文建立新的模型实例。旧实例继续负责当前对话，新实例准备完成后再无缝接管。OpenAI将实时对话与深度推理解耦：GPT‑Live负责维持沟通节奏，GPT‑5.5等前沿模型负责搜索、复杂推理和工具调用。这相当于让一个模型专门负责“交流”，另一个模型负责“思考和行动”。当用户提出复杂问题时，GPT‑Live可以将任务委托给后台模型，同时继续与用户交流。等搜索或推理结果返回后，再把答案自然地带回对话。为了缩短委托延迟，OpenAI会在语音会话开始时，就提前创建后台模型的推理会话，预填充初始上下文，并在整个通话期间保持会话可用。系统还通过稳定的会话亲和性、Prompt缓存、推理强度控制、输出长度限制和工具调用优化，缩短后台模型返回有效结果的时间。从架构上看，GPT‑Live已经不只是一个语音模型，而是位于用户和Agent系统之间的实时交互层。全双工交互允许用户和AI同时说话，但ChatGPT的界面、数据分析和安全系统，仍然需要一条条明确的用户消息与AI回复。因此，OpenAI又在应用层把连续音频重新整理成离散消息。系统会根据部分转写结果和时间信号，判断当前谁掌握话语权，并维护一个消息队列。最新消息先处于临时状态，文本、时间和说话人都可能随着后续音频继续调整。等系统确认某一方持续说话足够长时间后，才会把消息正式确定下来。这里还有一个细节：AI在用户说话时回应一句“嗯”或“好的”，不一定需要成为单独一条消息；但如果AI进行了实质性插话，又应该被记录。一套是可以随时更新的“推测视图”，用于界面实时显示；另一套是最终确认的“权威记录”，用于分析、日志和安全系统。这样既保留了全双工交流，又让现有系统能够继续使用传统的消息结构。实时体验不只取决于对话过程，还取决于用户点击语音按钮后，系统能多快建立连接。传统WebRTC连接需要完成ICE、DTLS、SCTP、数据通道和SDP协商等多个步骤，启动过程可能涉及6次网络往返。OpenAI为此开发了WARP，即WebRTC Abridged Roundtrip Protocol。WARP通过将DTLS握手搭载在ICE过程中、使用DTLS 1.3、提前协商SCTP和数据通道等方式，把媒体和数据启动所需的网络往返从6次减少到1次。WARP采用开放规范，目前正在IETF的TSVWG工作组推进，libwebrtc和Pion已经加入相关支持。在此基础上，OpenAI又推出Instant Connect，将SDP参数提前协商，使其不再位于关键启动路径上。两者结合后，客户端只需发送一个UDP数据包，就可以开始建立实时会话。服务器收到数据后立即响应，让系统尽快进入真正重要的环节：开始倾听和回答。OpenAI没有直接把GPT‑Live推给用户，而是先进行Shadow Testing。一小部分真实的ChatGPT Voice会话，会同时进入原有Advanced Voice Mode和GPT‑Live。用户仍然听到旧系统的回答，新系统则在后台只读运行。这种方式让OpenAI能够在不影响用户体验的情况下，观察GPT‑Live面对真实设备、网络、地域和长时间会话时的表现。测试也暴露出一个重要问题：实时语音系统的容量，不能只看GPU吞吐量。语音会话会长时间保持连接，并持续发送音频帧。CPU侧的流处理器、队列、网络链路和区域节点，都必须与模型推理同步扩容。因此，OpenAI把容量评估的问题从“GPU每秒能处理多少请求”，改成了：系统能够同时维持多少场会话，并保证每一帧音频按时送达？OpenAI最后将GPT‑Live的架构总结为四个部分：流式推理，让全双工模型持续接收和生成音频；独立媒体通道，保证音频帧稳定传输；异步委托，让深度思考与实时交流并行；传输协议优化，将响应速度一直延伸到用户终端。这套架构已经开始支撑ChatGPT Voice从普通语音聊天走向电脑控制和多Agent协同，未来也将成为GPT‑Live API的技术基础。GPT‑Live带来的行业启示是：Voice AI的竞争，正在从单点模型能力转向端到端系统能力。ASR、TTS和大模型决定AI能不能听懂、能不能表达、能不能完成任务；但只有实时互动基础设施，才能让这些能力在自然对话中真正连接起来。下一代Voice Agent不仅要聪明，还必须能够实时在线、持续倾听、随时响应，并在交谈过程中并行思考和行动。模型解决的是智能问题，RTE解决的则是智能如何实时抵达用户。https://openai.com/index/continuous-voice-interaction-with-gpt-live/
立即咨询 JOTO
JOTO 提供覆盖企业智能体规划与搭建、AI 平台私有化部署、RAG 知识工程、AI 安全治理、FDE 驻场共创及持续运营优化的全周期 AI 落地服务，帮助企业把验证中的 AI 能力转化为安全、可控、可持续迭代的生产力。 联系 JOTO 获取 AI 落地咨询
