将媒体前端用Go进行重写, GPT - Live语音的p95延迟直接降低到原系统的p50水平。历经六个月开发出第三代语音系统, 这第三代语音系统把turn从音频链路里完全剔除出去。下面这套架构成功地将推理延迟压制到了亚秒这个级别, 你到下半年通过使得 Agent 去运行长任务或者充当开展实时语音客服的角色, 等待的那种感觉会显著地变短, 此次在进行工程作解耦这方面做得已然是相当彻底了, 是极值得从事要做语音落地的团队认真去拆解并加以学习的。全双工架构与Go重写以往的语音AI采用轮次制, 依靠小模型turn去猜测用户是否说完, 若猜得过早 则会打断用户, 要是猜得太晚 便会响应迟缓。GPT-Live换成了全双工模式, 模型能够同时进行听和说。为了承受连续推理, 将媒体前端和推理逻辑从 换成了Go。新系统的p95帧交付延迟与老系统的p50相匹配。传输层使用丢包时微调拉伸音频, 来补回实时节奏。状态管理与上下文压缩长着语音的会话, 其上下文会持续不断地涨起来。模型所需的实例得依据需求来进行上线与下线操作。老时候运用的办法是, 坐等上下文超出后才着手从事压缩工作。然而, 压缩这一行为会对KV cache产生影响 , 重新开展时会再度引入非常明显的延迟状况。GPT - Live所采用的情形是进行一种毫无缝隙般的切换。按传统方案, 会出现这种情况, 上下文超出限制, 接着进行压缩, 之后KV缓存失效, 然后要重新操作, 最终导致媒体流卡顿。GPT存在性方案: 原本保持实例持续交互, 后台展开上下文压缩, 对新实例实施预热并且确保无缝切换, 媒体流不存在中断现象。落地全双工语音的避坑指南你若想于本地或者私有化来部署诸如GPT-Live这般的全双工语音, 那就得看清界限。其一, Go替换仅仅是达成了并发以及帧交付的平滑程度, 关键之处在于你的语音模型必须原生支持流式输入输出。其二, 丢包补偿机制依靠客户端与服务端的时钟同步, 要是你们的网络环境极大, 拉伸音频听起来会如同变声。最后, 让GPT-5.5这种大模型进行异步委托地进行深度思考 , 其前提是你们的业务能够容忍几百毫秒到秒级的思考延迟 , 要是处于纯客服插话场景 , 这种异步架构反过来会使首字响应时间增加。流式语音系统排查清单要是你接手了类似这般的流式语音项目, 那就依据这个清单去排查。其一, 检查音频帧抵达推理栈的延迟分布情况, 瞧瞧p99有没有出现毛刺。其二, 确定KV cache的命中率, 要是在长对话里频繁触发那就必须得启用预热实例切换机制。其三, 监控异步RPC边界的超时率, 工具要是调用得慢, 可别拖垮了主媒体循环, 实在得做物理隔离。其四, 对弱网环境下的表现进行测试, 要保证丢包率超过5%的时候音频不会断流。此次将媒体流与应用逻辑进行物理隔离, 是工程角度的正确抉择。众多团队在做语音Agent时, 倾向于把工具调用和音频生成置于同一个同步链路当中, 其结果便是一个慢SQL或者慢API会直接致使语音出现卡顿现象。GPT-Live把重型计算交付给GPT-5.5, 主链路仅仅保留音频流转, 这样的解耦思路值得借鉴。然而, 全双工模型在算力消耗上是轮次制的数倍之多, 原因在于模型在用户说话之际也在持续地进行推理。要是没有充足的GPU算力予以支撑, 这套架构在并发出现之后只会演变成一场灾难。要是想进行复现, 那么首先要将显存预留至24G以上, 若小显存运行全双工流式推理, 就会直接出现OOM。