GPT-Live

GPT-Live 是 OpenAI 在 2026 年 7 月发布的第三代语音系统，包含 GPT-Live-1 与 GPT-Live-1 mini。它在 ChatGPT Voice 中担当持续、自然的语音交互层：能一边听一边说，理解停顿、插话和说话节奏，并在需要时把搜索、深度推理或更复杂的 AI Agent（智能体）工作委派给后端前沿模型。它不是单一的通用推理模型，也不等同于一个开发者 API；发布时先面向 ChatGPT 推出，API 尚在计划中。

从轮次处理到持续交互

早期级联式语音系统把每一轮依次拆为语音转文字（STT）、语言模型、文字转语音（TTS）。这使模型能回答问题，却会在模型之间丢失部分信息，并形成明显等待。其后的 Advanced Voice Mode 已能端到端处理音频，但仍需借助静音判断“用户说完了”，所以短暂停顿、背景声或插话都容易造成不自然的抢话。

GPT-Live 的全双工架构则持续处理输入、持续生成输出；模型可在每秒内多次决定继续听、说话、暂停、打断或调用工具。重点不只是缩短首 token 延迟，而是把“是否轮到我说”也变成模型持续作出的交互决策。这使快速来回对话、主动倾听和实时翻译成为同一交互机制的结果。

flowchart LR
    U[用户连续语音] <--> L[GPT-Live 交互层]
    L --> D{需要深度工作？}
    D -->|否| R[继续聆听 / 自然回应]
    D -->|是| F[前沿模型：搜索 / 推理 / Agent]
    F --> L
    L --> R

交互层与能力层解耦

GPT-Live 把即时对话和耗时工作拆开：它在前台维持语音交流，同时可把困难问题交给另一模型处理，结果完成后再带回对话。发布时，Instant 配置及 GPT-Live-1 mini 的后端为 GPT-5.5 Instant；Medium 与 High 则使用不同推理力度的 GPT-5.5 Thinking。这个分层使语音体验能够随前沿模型更新而更新，而不用让高延迟的推理过程直接阻塞对话。

这种委派与 Agent Loop（智能体循环）中的“模型判断是否调用工具、运行时执行并回传观察”相似，但它首先服务于人机对话的连续性：GPT-Live 是面向用户的实时交互控制面，后端模型才执行搜索、推理或 Agent 任务。后端能力也不是 GPT-Live 自身无条件拥有的工具权限；系统卡说明，发布时其自身没有代码执行能力，也没有脱离委派模型的广泛工具访问。

ChatGPT 中的体验与边界

发布时 GPT-Live-1 面向 Go、Plus、Pro 用户成为 ChatGPT Voice 默认模型，GPT-Live-1 mini 面向免费用户。用户可以中断它、要求它放慢速度或安静聆听；ChatGPT 的九种声音也为该模型重新制作。语音界面还能把搜索、记忆、图片和文件上传结合进来，并在对话中显示天气预报、体育赛程、地图地点等可视卡片——这些卡片把需要扫读的数据保留在屏幕上，而不是强迫用户只靠语音记忆。

能力也有明确发布边界：部分语言可能仍带有非母语口音或不够流畅；初始版本不支持在 GPT-Live 中使用视频、屏幕共享。它们仍可通过旧版 Standard 或 Advanced Voice Mode 使用。文章称计划把模型带到 API，但这不是已经可依赖的 API 可用性承诺。

安全：在说话过程中介入

语音的风险不只发生在生成结束后：一次不当回复可能已经被完整说出。因此 GPT-Live 的保障措施以流式方式检查输入和输出；发现潜在不安全内容时，系统可以引导到更安全的回答、播报安全提示、在文字中提供支持资源，或在高风险情况下结束语音会话。自伤、精神病和躁狂、情感依赖、暴力、性内容，以及声音模仿/身份相关风险都纳入了专门的音频原生评测与红队测试。

系统卡还区分了本体和委派风险：不启用委派时，GPT-Live-1 与 mini 不被认为在生物化学、网络安全或 AI 自我改进三项追踪类别中达到 High；被委派任务则继承具体后端模型的安全训练和保障。对语音 Agent 而言，这意味着不能只评估“说话的模型”，还要同时审视后端模型、工具权限及 Agent Guardrails（Agent 护栏）的执行策略。

评测含义

OpenAI 以 5–10 分钟的配对人类对话评估整体偏好、轮流说话、打断、对话流和自然度，并称 GPT-Live-1 和 mini 显著优于 Advanced Voice Mode；同时报告在 GPQA、BrowseComp 和内部的多轮电信客服语音任务上优于旧模型。它们是厂商发布时的评估结论，应当被理解为产品方向和受控比较，而不是所有真实语音场景的成功率。

更值得迁移到产品设计的结论是：语音 Agent 的评测应把“答案对不对”与“怎样交谈”分开测量。前者覆盖搜索和推理质量，后者至少覆盖打断是否恰当、停顿时是否耐心等待、背景噪声下是否保持注意力，以及高风险内容能否在音频输出尚未造成影响前被拦截。

Deutsche Telekom（德国电信）的企业案例为这类能力补充了一个电信分发视角：运营商正在探索把实时翻译、通话助手和通话后摘要直接放入用户已有的电话渠道。不过该案例只称使用多个模型并与多家公司合作，不能据此判断这些功能已经采用 GPT-Live，或把企业路线图当作已验证的模型部署结果。这个案例的转型含义归入企业 AI 原生转型。

工程架构：维持不间断的媒体环路

产品介绍描述的是"能一边听一边说"的能力；把这种能力做到 ChatGPT 规模，则要求一套围绕"语音必须流动"重新设计的系统。OpenAI 的工程文章把 GPT-Live 的系统拆成几条相互独立的路径。

媒体路径与业务逻辑分离。 音频在客户端和语音模型之间走一条专用快速路径；委派、工具调用和其他应用工作放在异步 RPC 边界之后。一个慢的工具调用或后端服务只会延迟它自己的结果，不会卡住媒体流。这也给应用定制留出干净的边界：改变工具、策略和后端行为不必触碰负责维持音频流动的媒体前端。这种把实时媒体路径和非实时的业务、工具逻辑分开的边界，和 Harness Engineering（驾驭工程）里"harness 与 compute 分离"是同一类设计。媒体前端和推理逻辑用 Go 重写，取代了此前的 Python asyncio 实现，新系统的 p95 帧交付平滑度与旧系统的 p50 相当。传输层基于 WebRTC：它为低延迟媒体设计，能在丢包、时钟漂移和客户端连接变化下继续工作，必要时微妙地拉伸音频避免间断、再短暂加速追回实时。

有状态推理与无缝切换。 语音会话可能长时间保持活跃，但上下文持续增长，模型实例又随负载起伏。GPT-Live 用跨实例的无缝切换解决：需要切换时，先在原实例旁预热一个替换实例，用当前会话上下文 prefill，两边并行跑推理，等新实例就绪再切过去。这套机制同时支撑下面的动态上下文压缩。

上下文压缩作为受管切换。 长会话的累积上下文最终会超过模型上下文上限。压缩能把上下文压回上限内，但压缩要花时间，而且它改变了过去的上下文，会使模型的 KV 缓存失效——KV 缓存存着此前已处理 token 的注意力键值，重建它需要一次新的 prefill，带来额外延迟。GPT-Live 因此把压缩当作又一次受管切换：原实例继续对话的同时，系统在另一个实例上压缩上下文、用新上下文 prefill 好替换实例，就绪后切过去，媒体流不中断。重活留在实时路径之外，所以即便在切换中，对话也不会漏一拍。这把上下文工程里的压缩从"就地摘要历史"推进为"不中断服务的旁路切换"，详见 Prompt Caching（提示缓存）。

委派的工程化。 “说话"和"思考"解耦后，要让两模型架构感觉像一个系统。GPT-Live 把整条委派回路（路由、prompt 处理、推理、工具调用）都算进响应预算：在语音会话开始时就为前沿模型创建推理会话并用初始上下文 prefill，整个语音对话期间保持该会话可用，配合 Prompt Caching（提示缓存）和稳定会话亲和性来降延迟，同时让 worker 失败仍可恢复。reasoning effort、输出上限、工具 schema 和模型—工具往返轮数也都被调成"尽快给对话有用的结果”。

从连续语音派生离散轮次。 语音模型在连续流上工作，但它周围的许多系统（ChatGPT 对话 UI、部分分析和安全基础设施）仍按用户/助手轮次运作。应用服务器因此用部分转写和时序信号推断谁占着话轮、维护一个消息队列；最新的消息始终保持临时状态——文本、时序和说话人归属都会随后续语音变化；当某说话人持续占轮足够久、归属可信时，才把对应消息定稿。说话人重叠使这更复杂：用户说话时助手一声"嗯"不一定单独成消息，但有实质内容的插话往往应该。系统因此维护对话的两个视图：当前状态的推测视图（UI 可更新，故用它）和"确实说过什么"的权威记录（分析流水线需要定稿转写）。每条切分策略都在新鲜度和确定性间取舍：定稿太早产生碎片化和不稳排序，等太久又延迟转写及依赖它的功能。

更快地开始会话。 响应从用户点击那一刻就开始计时。WebRTC 是强实时底座，但起一个原生 WebRTC 会话需要不少协议握手和往返；它早于 QUIC 对"减少往返"的重视，底层协议有时重复工作（例如各自带反 DoS 机制）。OpenAI 为此设计了 WARP——一组开放规范，正通过 IETF TSVWG 工作组推进，已进入 libwebrtc 和 Pion。剩下信令交换（WebRTC 连接前用来交换 SDP 参数）仍在关键路径上，于是又做了 Instant Connect：提前协商这些参数但不预留服务端容量，也不改动现有 WebRTC 实现。预协商参数有效时，服务器在第一个媒体包到达时即可实例化会话；若参数过期或无效，标准信令流程已在进行，客户端无额外延迟地回退。两者合起来后，客户端只需一个 UDP 包就能起会话，服务器立即响应。

在真实流量上影子测试。 系统在纸上快，不等于在真实语音流量下不卡。OpenAI 在让 GPT-Live 面向用户前做了一次影子测试：把一小部分、逐步增加的生产 ChatGPT Voice 会话同时路由到既有 Advanced Voice Mode 和新系统；Advanced Voice Mode 照常服务用户，影子路径以只读模式跑推理。这让新系统暴露在真实客户端、网络、会话时长和地理分布下，却不改变用户听到的内容。这次测试带来的核心教训是：容量不能只化约成 GPU 吞吐——语音会话持续开着、持续发帧，CPU 侧的流处理器、队列和网络路径要和推理一起扩，于是容量问题从"一块 GPU 能处理多少请求"变成"系统在保证每帧按时的情况下能支撑多少并发会话"；地理也成为一阶问题，模型发布要和区域容量、流量调度配置一起验证；长会话、重连和客户端断开才暴露的内存、压缩恢复和关闭握手竞态，短时压测里几乎看不到。详见 Shadow Testing（影子测试）。

平台方向。 这套架构正在成为更广的实时交互平台：它驱动 ChatGPT Voice 从对话扩展到 Agent 协调，包括桌面端控制计算机和协调 Agent 的新能力；后续的 GPT-Live API 也以此为基础。

flowchart LR
    C["客户端"] <-->|"WebRTC + WARP / Instant Connect"| F["媒体前端 (Go)\n帧交付快速路径"]
    F <--> V["语音模型 (全双工)"]
    F -.->|"异步 RPC 边界"| A["应用服务器\n委派 / 工具 / 业务逻辑"]
    A -->|"会话级 prefill + 缓存"| P["前沿模型 (GPT-5.5)"]
    P --> A --> F
    V -->|"有状态切换\n压缩 / 预热替换实例"| V2["新模型实例"]