对于语音AI来说，知道何时开口比听起来更难。人类说话者能在几分之一秒内轻松地互相交接，但以往的语音AI系统无法跟上这种节奏。它们基于轮流发言的架构依赖于被称为“轮流检测器”的小型模型，这些模型面临着一项艰巨的任务：猜得太早，用户会被打断；猜得太晚，响应又会显得迟缓。只有在检测器做出决定后，更大的LLM才能开始工作。
GPT‑Live 是我们第三代语音系统，它将轮流检测器从音频路径中移除。其语音模型是全双工的，这意味着它可以同时听和说。这消除了对单独检测器的需求，使对话感觉更即时、更自然。当需要更深入的推理或工具使用时，GPT‑Live 还可以咨询我们的前沿模型，如 GPT‑5.5，而不会打断对话的流畅性。这些能力共同赋予 GPT‑Live 前所未有的对话响应速度和智能组合。
大规模提供这种体验需要一种针对低延迟优化的新系统架构。与典型的请求-响应推理不同，我们的系统将传入的音频流式传输到语音模型，并将传出的语音流式传输回用户，同时在单独的异步路径上处理委派任务。在过去的六个月里，我们重新设计了模型推理、上下文管理和媒体传输，以确保语音从端到端流畅传输。
该架构还在核心语音路径和应用逻辑之间创建了清晰的边界。这使得在不影响响应速度的情况下轻松定制应用行为。这一基础支撑了 ChatGPT Voice 中不断扩展的功能，包括新推出的在 ChatGPT 桌面应用中控制你的计算机和协调你的代理的能力。
在这篇文章中，我们将解释为什么早期的轮流系统无法满足我们的需求，以及我们如何在每一层为响应速度设计新系统。我们将涵盖有状态推理、动态上下文管理、异步委派和协议级优化，所有这些协同工作，使 GPT‑Live 真正感觉 实时。
从轮流发言转向流式传输
早期的语音架构继承了文本LLM的轮流特性，但每一轮表示为离散的音频块而非文本。在级联系统中，语音转文本、LLM 和文本转语音依次运行。这种顺序增加了延迟，并忽略了语调和节奏等线索。
语音到语音模型通过直接处理音频改进了这种方法。训练模型原生理解和生成语音，使其能够保留转录中丢失的细节并更快地响应。但系统仍然依赖轮流检测器来决定推理何时开始。模型处理了更多的交互，但交互仍然是轮流式的。
GPT‑Live 让语音模型掌控对话：音频流入和流出模型，而更深入的推理和工具使用则异步进行。系统的主要任务是维持不间断的媒体循环。其他工作，如调用前沿模型和持久化对话，则在实时路径之外进行。
实现持续推理
保持这种媒体循环不间断并不总是简单的。传输、处理或推理中的任何延迟都可能变成可听见的停顿或伪影。以前的轮流系统可以容忍音频块到达时间的一些变化。然而，实时媒体系统需要按计划交付每个音频帧。
早期在 ChatGPT Voice 和 Realtime API 上的工作为我们提供了重要的基础。我们已经重建了我们的语音基础设施，以更低且更可预测的延迟将音频和视频直接流式传输进出我们的系统。GPT‑Live 进一步推动了这一设计，通过一个为持续对话构建的新有状态推理系统，将媒体一直流式传输到模型。
流式推理只是解决方案的一部分。为了使其在生产中良好运行，我们还必须确保从客户端到推理栈的可靠音频传输，并应对有状态性的挑战。
我们早期做出的一个决定是明确将媒体流与应用和业务逻辑分离。音频在客户端和语音模型之间通过专用快速路径移动。委派、工具使用和其他应用工作则在异步RPC边界之后进行。缓慢的工具调用或后端服务可能会延迟其自身的结果，但不会阻塞媒体流。
这种分离也为系统提供了清晰的定制边界。应用可以更改其工具、策略和后端行为，而不会影响负责保持音频移动的媒体前端。实时路径保持小巧、可预测，并专注于必须实时完成的工作。
我们用 Go 编写了媒体前端和推理逻辑，取代了之前的 Python asyncio 实现。这显著提高了帧传输的平滑度，新系统的 p95 与旧系统的 p50 相当。
WebRTC 提供了传输基础。它专为低延迟媒体设计，并且可以在丢包、时钟漂移和客户端连接变化的情况下继续运行。如果数据包迟到，WebRTC 可以微妙地拉伸音频以防止间隙，然后短暂加速播放以赶上实时时间。
通过最小化整个系统中的缓冲和阻塞，我们可以提供人类在对话中期望的亚秒级响应。
保持（有状态的）对话进行
有状态推理有其自身的操作权衡。语音会话可能长时间保持活动，但其上下文持续增长，模型实例根据需求上下旋转。
为了解决这些问题，我们构建了跨模型实例的无缝切换机制。当需要转换时，我们可以在现有实例旁边预热一个替代模型实例，用当前会话上下文预填充它，并行运行两者的推理，并在新实例完全准备好时切换。
相同的基本机制还支持动态上下文压缩。随着对话的进行，累积的上下文最终可能超过模型的上下文限制。压缩可以减少上下文大小以适应限制，但该操作需要时间。而且由于它改变了过去的上下文，它也使模型的键值（KV）缓存失效，该缓存存储了先前处理过的标记的注意力键和值。重建该状态需要新的预填充，从而引入额外的延迟。
相反，我们将压缩视为另一种受管理的转换。原始模型实例继续对话的同时，系统压缩上下文并准备一个带有新上下文的替代模型实例。一旦该实例就绪，我们便可在无任何媒体中断的情况下切换。这使得系统能够支持长时间通话，并在必要时随时压缩。
繁重的工作保持在实时路径之外，因此即使在交接过程中，对话也绝不会错过任何节拍。
不阻塞对话的委派
GPT‑Live 调用现有前沿模型的能力赋予其强大功能，实际上将“交谈”与更深层的“思考”解耦。但要让这种双模型架构感觉像一个系统，需要解决两个相关的工程问题。
委派以进行更深层的工作
GPT-Live 提供快速、自然的响应，而 GPT-5.5 在后台处理搜索
文字记录
与 GPT-Live-1 使用 GPT-5.5 Instant 的示例对话
首先，结果必须足够快速地返回，以便在持续交流中有用，因此我们必须最小化整个委派路径上的延迟，从路由和提示处理到推理和工具调用。同时，产品中其他位置的系统仍需要离散消息，因此我们必须以它们能理解的形式表示持续进行的对话。
使委派足够快速以显得自然
当委派被派发时，我们优化的是前沿模型为对话产生有用内容所需的时间。语音模型可以在前沿模型推理或使用工具时短暂维持交流的推进，但无法隐藏任意缓慢的响应。因此，我们将整个委派循环——路由、提示处理、推理和工具调用——视为响应预算的一部分。
第一个优化是在请求委派之前设置好前沿模型及其所需的任何工具。当语音会话开始时，应用服务器为前沿模型创建推理会话，并用初始对话上下文预填充，确保提示在首次委派请求之前已完全处理。
然后，我们在语音对话期间保持该推理会话可用，并对连续请求使用稳定的会话亲和性。结合提示缓存，这些技术改善了延迟，同时工作节点故障仍易于恢复。
推理努力、输出限制、工具模式以及模型与工具之间的往返也会影响对话何时收到有用结果，我们调整了这些杠杆以获得更快的响应。通过最小化委派路径上所需的工作，我们使语音模型能够快速整合来自前沿模型的结果。
从连续语音中推导离散轮次
尽管语音模型处理连续的语音流，但周围许多系统仍基于用户和助手轮次运行，包括 ChatGPT 的对话界面以及部分分析和安全基础设施。因此，应用服务器将重叠且偶尔模糊的对话拆分为离散消息。
随着音频到达，服务器使用部分转录和时间信号来推断当前发言者，并构建消息队列。最新消息保持临时状态；其文本、时间和发言者分配都可能随着更多语音到达而变化。一旦某发言者持续发言足够长的时间，使归属可靠，服务器便最终确定相应消息。
发言者重叠使这更加复杂。用户在说话时助手发出的简短确认（例如“嗯嗯”或“好的”）不一定应成为独立消息。然而，助手实质性的插话通常应该如此。同样，即使用户在中间说话，我们也优先保证所显示助手响应的连贯性。
每种分段策略都在新鲜度和确定性之间权衡。过早提交会产生碎片化的历史和不确定的排序；等待过久则会延迟转录及依赖它的功能。因此，系统维护对话的两个相关视图：当前状态的推测视图和已说内容的权威记录。应用界面中的对话视图可以处理更新，因此使用推测视图。但记录到分析管道需要最终转录。
这为 ChatGPT 的其余部分提供了稳定的交流视图，而无需在实时语音路径上强加轮流发言规则。
以更快的协议启动会话
响应性从用户点击按钮那一刻开始。使用 GPT‑Live，系统必须在对话开始前建立媒体路径并将音频送入模型。这使得启动序列的每个部分都处于关键路径上。
如上所述，WebRTC 提供了强大的实时基础，但启动一个标准 WebRTC 会话需要大量协议握手和网络往返。WebRTC 早于后来塑造 QUIC 等协议的减少往返关注点。因此，其底层协议在组合使用时有时会重复工作。例如，每个协议都包含自己的反 DoS 机制，即使在完整 WebRTC 栈的上下文中并不需要。
我们将 WARP 设计为一组开放规范，与 WebRTC 社区的协作者合作，使更广泛的生态系统能受益于此工作。我们正在通过 IETF 的 TSVWG 工作组推进提案，并且 WARP 支持已添加到 libwebrtc 和 Pion 中，其他 WebRTC 实现也在努力中。
优化媒体握手后，一个剩余延迟尤为突出：在 WebRTC 连接前用于共享 SDP 参数的信号交换。为将该交换移出关键路径，我们开发了所谓的 Instant Connect。它提前协商这些参数，而不预留服务器容量，也无需更改现有 WebRTC 实现。
Instant Connect 与标准信号流程并行运行。如果预协商参数有效，服务器可在第一个媒体包到达时实例化会话。如果参数过期或无效，信号流程已在进行中，因此客户端可无额外延迟地回退。
Instant Connect 和 WARP 共同大幅缩短了从用户意图到实时媒体流的时间。随着 SDP 交换移出关键路径且 WARP 压缩传输握手，客户端现在可以用单个 UDP 数据包启动会话。服务器可立即响应，让系统其余部分开始做用户真正关心的工作：倾听和回应。
使用真实数据在生产环境中安全测试 GPT‑Live
一个系统在纸面上可能看起来很快，但在真实语音流量下仍可能停滞不前。在让 GPT‑Live 与用户对话之前，我们进行了一次静默测试，将生产环境 ChatGPT Voice 会话中一小部分且逐渐增加的流量，同时路由到现有的高级语音模式体验和我们的新系统。高级语音模式继续像往常一样服务用户，而影子路径则以只读模式运行推理。这让系统暴露在真实客户端、网络、会话时长和地理分布之下，而不会改变用户听到的内容。
最初的教训之一是，容量不能简化为 GPU 吞吐量。语音会话保持打开并持续发送帧，因此 CPU 侧的流处理器、队列和网络路径必须与推理同步扩展。在真实负载下，一个支撑组件比我们的负载测试估计预测的更早饱和，导致推理请求累积，延迟加剧。我们将容量问题从“一个 GPU 能处理多少请求？”转变为“系统能在保持每帧按时交付的同时，维持多少并发会话？”
测试还使地理因素成为首要关注点。将会话路由到远端容量可能在启动和流传输的多个节点增加延迟。我们开始将模型发布与区域容量和流量引导配置一起验证，然后按源地理位置分解延迟。将推理移近用户有所帮助，但也强化了更广泛的教训：端到端响应能力取决于路径中的每个服务，而不仅仅是模型服务器。
其他故障仅在真实会话生命周期中显现。长时间运行的会话暴露了内存和持久性压力。重连考验了压缩和状态恢复。普通客户端断开连接揭示了关闭握手中的竞争条件。这些问题很少出现在短时负载测试中，因为它们依赖于时间、累积状态以及跨服务边界的行为。
最后，生产测试迫使我们改进可观测性和发布控制。我们发现指标混淆了不同来源的延迟，仪表板的聚合掩盖了单个不健康的引擎，以及测试与部署系统之间的配置漂移。作为回应，我们增加了更细粒度的遥测、针对已知良好配置的验证、分阶段逐步上线，以及快速隔离或禁用单个路径的能力。静默测试成为了一次早期发布预演，不仅关乎系统能承受多少流量，还关乎我们能多快地检测、遏制并从故障中恢复。
从客户端到模型的响应性
将 GPT‑Live 带到 ChatGPT 规模需要一个围绕基本原则构建的全新系统：语音必须流畅。流式推理确保持续为全双工模型提供音频。专用媒体路径确保可靠的帧交付。异步委派让更深层次的思考并行运行。优化的传输让体验在用户端始终保持响应。
GPT‑Live 背后的架构正在成为一个更广泛的实时交互平台。它驱动着 ChatGPT Voice 从对话扩展到代理协调，并将支撑即将推出的 GPT‑Live API。随着时间的推移，它将使语音体验跨越更多设备、应用和模态，而不牺牲让语音对话感觉实时的即时性。
如果这些是你想解决的工程问题，来和我们一起工作吧。
For voice AI, knowing when to speak is harder than it sounds. Human speakers effortlessly hand off to each other in a fraction of a second, but previous voice AI systems couldn’t keep up with this rhythm. Their turn-based architecture relied on tiny models known as turn detectors, which faced an unenviable task: guess too soon, and the user gets cut off; guess too late, and the response feels sluggish. Only after the detector made its decision could the much larger LLM get to work.
GPT‑Live, our third-generation voice system, removes the turn detector from the audio path. Its voice model is full-duplex, which means it can listen and speak at the same time. That eliminates the need for a separate detector and makes conversation feel more immediate and natural. When deeper reasoning or tool use is needed, GPT‑Live can also consult our frontier models, such as GPT‑5.5, without interrupting the flow of the conversation. Together, these capabilities give GPT‑Live an unprecedented combination of conversational responsiveness and intelligence.
Delivering this experience at scale required a new system architecture optimized for low latency. Unlike typical request-response inference, our system streams incoming audio into the voice model and outbound speech back to the user, while handling delegation on a separate asynchronous path. Over the last six months, we reworked model inference, context management, and media transport to keep speech flowing smoothly from end to end.
The architecture also creates a clean boundary between the core voice path and application logic. This makes it easy to customize application behavior without affecting responsiveness. This foundation powers a growing range of capabilities in ChatGPT Voice, including the newly launched ability to control your computer and coordinate your agents in the ChatGPT desktop app.
In this post, we’ll explain why earlier turn-based systems couldn’t meet our needs and how we engineered the new system for responsiveness at every layer. We’ll cover stateful inference, dynamic context management, asynchronous delegation, and protocol-level optimization, all working together to make GPT‑Live feel truly live.
Moving from turn taking to streaming
Earlier voice architectures inherited the turn-based nature of text LLMs, but with each turn represented as a discrete audio blob rather than text. In cascaded systems, speech-to-text, the LLM, and text-to-speech each ran in series. This sequencing added latency and ignored cues such as tone and pacing.
Speech-to-speech models improved on this approach by processing audio directly. Training the model to natively understand and generate speech allowed it to preserve details lost in transcription and respond more quickly. But the system still relied on the turn detector to decide when inference could begin. The model handled more of the interaction, but the interaction remained turn-based.
GPT‑Live puts the voice model in control of the conversation: audio flows in and out of the model, while deeper reasoning and tool use happen asynchronously. The system’s primary job is to sustain an uninterrupted media loop. Other work, such as invoking frontier models and persisting the conversation, happens off the live path.
Enabling continuous inference
Keeping this media loop uninterrupted is not always straightforward. Any delay in transport, processing, or inference can become an audible pause or artifact. A previous turn-based system could tolerate some variation in when an audio blob arrived. However, a live media system needs to deliver every audio frame on schedule.
Earlier work on ChatGPT Voice and the Realtime API gave us an important foundation. We had already rebuilt our voice infrastructure to stream audio and video directly in and out of our systems with lower and more predictable latency. GPT‑Live pushed that design further, streaming media all the way to the model through a new stateful inference system built for continuous conversation.
Streaming inference was only part of the solution though. To make it work well in production, we also had to ensure reliable audio delivery from the client to the inference stack and deal with the challenges of statefulness.
An early decision we made was to specifically separate media flow from application and business logic. Audio moves between the client and the voice model on a dedicated fast path. Delegation, tool use, and other application work happen behind an asynchronous RPC boundary. A slow tool call or backend service can delay its own result, but cannot stall the flow of media.
This separation also gives the system a clean boundary for customization. Applications can change their tools, policies, and backend behavior without affecting the media frontend responsible for keeping audio moving. The live path stays small, predictable, and focused on the work that must happen in real time.
We wrote the media frontend and inference logic in Go, replacing a previous Python asyncio implementation. This significantly improved the smoothness of frame delivery, with the new system’s p95 matching the previous system’s p50.
WebRTC provides the transport foundation. It’s designed for low-latency media, and can continue operating through packet loss, clock drift, and client connection changes. If packets arrive late, WebRTC can subtly stretch audio to prevent gaps, and then briefly accelerate playback to catch back up to real time.
By minimizing buffering and blocking throughout the system, we can deliver the sub-second responsiveness that humans expect from conversation.
Keeping the (stateful) conversation going
Stateful inference has its own operational tradeoffs. A voice session may remain active for a long time, but its context continuously grows, and model instances spin up and down based on demand.
To address these concerns, we built a seamless handoff mechanism across model instances. When a transition is needed, we can warm a replacement model instance alongside the existing one, prefill it with the current session context, run inference against both in parallel, and cut over when the new instance is fully ready.
The same basic mechanism also supports dynamic context compaction. As a conversation goes on, its accumulated context can eventually exceed the model’s context limit. Compaction can reduce the context size to fit within the limit, but the operation takes time. And because it changes past context, it also invalidates the model’s key-value (KV) cache, which stores attention keys and values from previously processed tokens. Rebuilding that state requires a new prefill, introducing additional delay.
Instead, we treat compaction as another managed transition. While the original model instance keeps chatting, the system compacts the context and prepares a replacement model instance with the new context. Once that instance is ready, we can switch over without any media interruption. This allows the system to support long-running calls, compacting whenever necessary.
The heavy lifting stays off the live path, so even during a handoff, the conversation never misses a beat.
Delegation without blocking the conversation
GPT‑Live’s ability to invoke existing frontier models gives it a lot of power, effectively decoupling “talking” from deeper “thinking”. But making this two-model architecture feel like one system required solving two related engineering problems.
Delegation for deeper work
GPT-Live provides fast, natural responses, while GPT-5.5 handles search in the background
Transcript
Example conversation with GPT-Live-1, using GPT-5.5 Instant
First, results must return quickly enough to be useful in the ongoing exchange, so we had to minimize latency across the entire delegation path, from routing and prompt processing through inference and tool calls. At the same time, systems elsewhere in the product still need discrete messages, so we had to represent the ongoing conversation in a form they could understand.
Making delegation fast enough to feel natural
When a delegation is dispatched, we optimize for the time until the frontier model produces something useful for the conversation. The voice model can briefly keep the exchange moving while a frontier model reasons or uses tools, but it cannot hide an arbitrarily slow response. We therefore treated the full delegation loop—routing, prompt processing, inference, and tool calls—as part of the responsiveness budget.
The first optimization is to set up the frontier model and any tools it needs before delegation is requested. When a voice session starts, the application server creates an inference session for the frontier model and prefills it with the initial conversation context, ensuring the prompt has been fully processed prior to the first delegated request.
We then keep that inference session available for the duration of the voice conversation and use stable session affinity for successive requests. Together with prompt caching, these techniques improve latency while a worker failure remains easily recoverable.
Reasoning effort, output limits, tool schemas, and model-tool round trips also affect when the conversation receives a useful result, and we adjusted these levers to get faster responses. By minimizing the work needed on the delegation path, we enabled the voice model to quickly incorporate results from our frontier models.
Deriving discrete turns from continuous speech
Even though the voice model operates on continuous streams of speech, many of the systems around it still operate on user and assistant turns, including ChatGPT’s conversation UI and parts of our analytics and safety infrastructure. So the application server teases apart the overlapping, occasionally ambiguous conversation into discrete messages.
As audio arrives, the server uses partial transcripts and timing signals to infer which speaker has the floor and build a queue of messages. The newest message remains provisional; its text, timing, and speaker assignment can all change as more speech arrives. Once a speaker has sustained the floor long enough for the attribution to be reliable, the server finalizes the corresponding message.
Speaker overlap makes this more complicated. A brief acknowledgement from the assistant while the user is talking (e.g. “mm hmm,” or “okay”) should not necessarily become its own message. However, a substantive assistant interjection often should. Similarly, we prioritize coherence in the displayed assistant responses even when the user speaks in the middle.
Every segmentation policy trades freshness for certainty. Committing too early produces fragmented history and unstable ordering; waiting too long delays transcripts and the features that depend on them. The system therefore maintains two related views of the conversation: a speculative view of the current state and an authoritative record of what was said. The conversation view in the application UI can handle updates, so it uses the speculative view. But logging to the analytics pipeline requires a final transcript.
This gives the rest of ChatGPT a stable view of the exchange without imposing turn-taking on the live voice path.
Starting sessions with a faster protocol
Responsiveness starts as soon as the user clicks the button. With GPT‑Live, the system must establish the media path and begin feeding audio through the model before the conversation can begin. That puts every part of the startup sequence on the critical path.
As noted above, WebRTC provides a strong realtime foundation, but starting a vanilla WebRTC session requires a surprising number of protocol handshakes and network round trips. WebRTC predates the focus on minimizing round trips that shaped later protocols such as QUIC. As a result, its underlying protocols sometimes repeat work when used together. For example, each protocol included its own anti-DoS mechanism, even when it wasn’t needed in the context of the full WebRTC stack.
We designed WARP as a set of open specifications, working with collaborators from the WebRTC community, so the broader ecosystem can benefit from this work. We’re advancing the proposals through the IETF’s TSVWG working group, and WARP support has already been added to both libwebrtc and Pion, with efforts underway in other WebRTC implementations.
After optimizing the media handshake, one remaining delay stood out: the signaling exchange used to share SDP parameters before WebRTC can connect. To remove that exchange from the critical path, we developed what we call Instant Connect. It negotiates these parameters ahead of time without reserving server capacity and without any changes to existing WebRTC implementations.
Instant Connect runs alongside the standard signaling flow. If the pre-negotiated parameters are valid, the server can materialize the session when the first media packet arrives. If they are stale or invalid, the signaling flow is already underway, so the client can fall back with no additional latency.
Together, Instant Connect and WARP dramatically reduce the time from user intent to live media flow. With the SDP exchange off the critical path and WARP collapsing the transport handshake, the client can now start a session with a single UDP packet. The server can respond immediately, letting the rest of the system begin doing the work the user actually cares about: listening and responding.
Safely testing GPT‑Live in production with real data
A system can look fast on paper and still stall under real voice traffic. Before letting GPT‑Live chat with users, we ran a silent test that routed a small, gradually increasing share of production ChatGPT Voice sessions to both the existing Advanced Voice Mode experience and our new system. Advanced Voice Mode continued serving users as usual, while the shadow path ran inference in read-only mode. This exposed the system to real clients, networks, session lengths, and geographic distribution without changing what users heard.
One of the first lessons was that capacity could not be reduced to GPU throughput. Voice sessions stay open and send frames continuously, so CPU-side stream handlers, queues, and network paths must scale alongside inference. Under real load, a supporting component saturated earlier than our load test estimates predicted, causing inference requests to accumulate and latency to compound. We changed the capacity question from “How many requests can a GPU handle?” to “How many concurrent sessions can the system sustain while keeping every frame on schedule?”
The test also made geography a first-order concern. Routing a session to distant capacity can add delay at several points during startup and streaming. We began validating model rollouts together with regional capacity and traffic-steering configuration, then breaking latency down by source geography. Moving inference closer to users helped, but it also reinforced the broader lesson: end-to-end responsiveness depends on every service in the path, not only the model server.
Other failures appeared only across realistic session lifecycles. Long-running sessions exposed memory and persistence pressure. Reconnects exercised compaction and state restoration. Ordinary client disconnects revealed races in the shutdown handshake. These problems rarely appeared in short load tests because they depended on time, accumulated state, and behavior across service boundaries.
Finally, production testing forced us to improve observability and rollout controls. We found metrics that conflated different sources of latency, dashboards whose aggregates hid individual unhealthy engines, and configuration drift between tested and deployed systems. In response, we added more granular telemetry, validation against known-good configurations, staged ramps, and the ability to isolate or disable individual paths quickly. The silent test became an early launch rehearsal, not only for how much traffic the system could accept, but for how quickly we could detect, contain, and recover from failure.
Responsive, from client to model
Bringing GPT‑Live to ChatGPT scale required a whole new system built around one fundamental principle: the voice must flow. Streaming inference keeps the full-duplex model supplied with audio. A dedicated media path ensures reliable frame delivery. Asynchronous delegation lets deeper thinking run in parallel. Optimized transport keeps the experience responsive all the way to the user.
The architecture behind GPT‑Live is already becoming a broader platform for realtime interaction. It powers ChatGPT Voice as it expands from conversation into agentic coordination, and will underpin the upcoming GPT‑Live API. Over time, it will allow voice experiences to span more devices, apps, and modalities without sacrificing the immediacy that makes voice conversation feel live.
If these are the kinds of engineering problems you want to solve, come work with us.
本文内容采集自官方网站，排版和翻译可能与原页面存在差异。
阅读官方全文