GPT-Live 可以在说话的同时进行聆听。为了让这种体验在 ChatGPT 大规模调用下感觉自然，OpenAI 从客户端到模型重建了语音堆栈。这种新架构保持音频持续流动，因此更深入的推理和工具使用不会打断对话。让AI掌握开口说话的时机，这比听起来难得多。人类在交流时可以在零点几秒内无缝接话，早期的语音AI系统根本跟不上这种节奏。之前的系统架构基于回合制，依赖被称为轮次检测器的小模型。这些检测器面临着一个非常尴尬的任务，猜早了会打断用户，猜晚了又显得反应迟钝。只有等检测器做完决定，庞大的大语言模型才能开始工作。
OpenAI第三代语音系统GPT Live直接从音频路径中剔除了轮次检测器。它的语音模型是全双工的，意味着可以同时听和说。这让单独的检测器变得多余，也让对话感觉更即时更自然。当需要深度推理或使用工具时，GPT Live可以去请教GPT 5.5等前沿模型，完全不会打断对话的流畅度。这两种能力的结合为GPT Live带来了前所未有的对话响应速度和智能水平。
为了大规模提供这种体验，OpenAI团队在过去六个月里完全重构了模型推理、上下文管理和媒体传输层，打造了一个专为低延迟优化的新系统架构。与典型的请求响应模式完全不同，新系统将输入的音频直接以流式传给语音模型，同时把传出的语音推回给用户，复杂的委托任务则走另一条异步路径。
这种架构还在核心语音路径和应用逻辑之间建立了一条清晰的边界，方便定制应用行为并保持响应速度。ChatGPT语音助手中的新功能，包括在桌面应用中控制电脑和协调代理的能力，正是建立在这个基础之上。
从回合制走向纯流式
早期的语音架构继承了文本大模型的换轮次机制。在级联系统中，语音转文本、大模型和文本转语音这三步按顺序运行，增加了延迟并丢失了语调和节奏等信息。后来的语音到语音模型通过直接处理音频改善了这一点，保留了转录中丢失的细节，响应也更快。系统依然依赖轮次检测器来决定何时开始推理。模型承担了更多交互工作，交互本身依然基于回合。
GPT Live把对话控制权交给了语音模型。音频在模型中进进出出，而深度推理和工具使用则在异步环境中发生。系统最核心的任务就是维持一条不间断的媒体循环，调用前沿模型和保存对话等其他工作都在实时路径之外进行。
确保持续推理与无缝切换
维持媒体循环绝非易事。传输、处理或推理过程中的任何延迟都会变成听得见的停顿或杂音。团队决定将媒体流与应用业务逻辑彻底分离。音频在客户端和语音模型之间的一条专用快速通道上移动，工具使用等应用工作被放在异步RPC边界之后。一个运行缓慢的后台服务或者工具调用顶多延迟它自己的结果，绝对无法让媒体流停滞。
团队用Go语言编写了媒体前端和推理逻辑，彻底替换了之前的Python asyncio实现。这大幅提升了帧传输的平滑度，新系统的p95延迟直接追平了旧系统的p50延迟。
底层的WebRTC协议天生适合低延迟媒体，能在丢包、时钟漂移和网络变化时继续工作。如果数据包迟到，WebRTC会巧妙地拉长音频防止出现空白，随后再短暂加速播放追赶上实时进度。
保持连续对话还有状态管理的挑战。语音会话可能会持续很长时间，上下文不断增加，模型实例也会根据需求启动或关闭。团队构建了一个跨模型实例的无缝交接机制。当需要切换时，系统会与现有实例并排预热一个替代模型实例，将当前的会话上下文预先填充进去，并行运行推理，等新实例完全就绪后再进行切换。
这个机制也完美解决了动态上下文压缩的问题。随着对话进行，积累的上下文会超出限制。压缩上下文需要时间，还会使模型之前处理的键值缓存失效，重建状态会带来额外延迟。团队把压缩看作另一次有管理的平滑过渡。原模型实例继续聊天，系统在后台压缩上下文并准备好新的替代实例。新实例就绪后直接无感切换，脏活累活都在实时路径之外完成，对话绝不会漏掉半个节拍。
后台静默委托与离散消息提取
GPT Live能调用现有前沿模型，巧妙地将开口说话与深度思考分离开来。
为了让这种双模型架构感觉像一个整体，团队优化了整个委托路径上的延迟。为了快速拿到结果，应用服务器在语音会话开始时就会为前沿模型创建一个推理会话，预先填充初始上下文，保证在发起第一次委托请求前，提示词就已经处理完毕。这个推理会话在整个语音通话期间都保持可用状态，结合提示词缓存技术，大大缩短了延迟。
虽然语音模型处理的是连续语音流，但ChatGPT的界面、安全和分析系统依然需要离散的用户和助手消息。服务器会利用部分转录和时间信号来推断当前是谁在说话，并建立一个消息队列。最新的消息始终是暂定状态，随着更多语音到达，它的文本和发言人归属都可以改变。只有当一个人发言足够久，归属变得可靠时，服务器才会最终确认这条消息。这种设计让系统同时维护两种对话视图，UI界面使用推测视图实时更新，分析日志则记录最终的权威版本，成功在连续语音中提取出清晰的对话轮次。
用更快的新协议启动会话
当用户点击按钮那一刻，响应就开始了。原生的WebRTC建立会话需要惊人数量的协议握手和网络往返。团队与WebRTC社区合作设计了WARP这一组开放规范，精简了传输握手过程。目前该方案正通过IETF的相关工作组进行推进。
针对连接前共享SDP参数带来的信令交换延迟，团队开发了即时连接技术。它能提前协商这些参数，无需修改现有的WebRTC实现。如果预先协商的参数有效，服务器在收到第一个媒体包时就能建立会话。结合这两项技术，客户端现在只需发送一个UDP数据包就能启动会话，服务器可以立即响应，让系统马上开始监听和对话。
用真实流量在生产环境进行压力测试
在让GPT Live正式面对用户之前，团队进行了一次静默测试，将小部分生产环境的流量同时路由给旧的高级语音模式和新系统。新系统以只读模式在后台进行推理，用户完全听不到任何变化，这让系统接受了真实网络和地理分布的全面考验。
测试表明，系统容量绝不等同于GPU的吞吐量。语音会话持续发送帧，CPU侧的流处理器、队列和网络路径必须与推理能力同步扩展。团队由此将关注点转向系统在保证每一帧按时到达的前提下能维持多少并发会话。
地理位置也是一个核心要素。把会话路由到远处的机房会在启动和传输中增加延迟。端到端的响应速度依赖于路径上的每一个服务，绝不仅限于模型服务器本身。长时间运行的会话还暴露了内存压力和状态恢复等短时间压测无法发现的问题。生产环境的测试逼迫团队增加了更细粒度的遥测技术，实现了隔离并快速禁用单个故障路径的能力。
将GPT Live扩展到ChatGPT的规模，需要一个围绕语音必须保持流动这一基本原则构建的全新架构。流式推理为全双工模型源源不断地提供音频，专用媒体路径保证了帧的可靠交付，异步委托让深度思考得以并行，优化的传输层让用户的最终体验极致流畅。这个架构正成为实时交互的底层平台，未来将支持更多设备和应用，让每一次语音交流都如同面对面般真实。
source：
https://openai.com/index/continuous-voice-interaction-with-gpt-live/
--end--
最后记得⭐️我，每天都在更新：如果觉得文章还不错的话可以点赞转发推荐评论
/...@作者：你说的完全正确（YAR师）
