OpenAI 工程团队复盘：六个月构建实时语音 AI 系统

OpenAI 在其官方博客发布了一篇工程复盘文章，主题为「我们如何在六个月内构建一套面向响应式语音 AI 的实时系统」。文章链接为 openai.com/index/continuous-voice-interaction-with-gpt-live/，从 URL 路径判断，内容围绕 OpenAI 的「Continuous Voice Interaction（连续语音交互）」能力及其底层 GPT Realtime / GPT Live 模型展开。

背景：从对话轮到真正连续的语音交互

传统的语音助手普遍采用「按下说话—松手结束」的回合式交互，用户与模型之间的对话是离散且有停顿的。OpenAI 在文章中描述了团队希望打破这一限制，让用户可以像和真人交谈一样与 AI 自然中断、插话、换气，并保持语义与情绪的连续性。这一目标的工程难度主要来自三个维度：

• 超低延迟：从用户说完到模型开始回应的端到端时延必须足够短，否则会丧失「实时感」；
• 流式处理：模型需要边接收音频边生成回应，而不是等整段话结束；
• 打断与续说：模型要在用户中途插入时平滑让出话语权，并保留上下文。

六个月里做了什么

据文章标题与博客描述，OpenAI 用约六个月时间完成了从原型到可用系统的搭建。文中涉及的工作横跨模型层、推理基础设施与产品交互层，核心要点包括：

• 在模型侧，针对语音场景对 GPT 系列模型做了专门的流式推理优化，使其能够持续处理输入音频流并增量生成输出；
• 在推理侧，构建了一套支持实时音频输入输出、低抖动、可弹性扩缩的推理服务；
• 在产品侧，将上述能力接入到面向开发者的 Realtime / Live 接口以及 ChatGPT 的语音模式中。

文章以工程复盘的视角，详细记录了团队在延迟、稳定性、并发能力与用户体验之间反复权衡的过程，并分享了若干典型问题（如首字延迟、回声、模型在被打断后的语义衔接）的应对思路。

意义与局限

对开发者与产品团队而言，这篇文章的价值在于把「实时语音 AI」从一个产品口号还原为一系列具体的工程决策：哪些环节用流式、哪些环节用批式、如何定义「可对话」的延迟阈值、如何处理打断后的状态恢复。它也是目前少数由大模型一线团队公开的、端到端的语音 AI 系统搭建经验。

需要指出的是，本文基于 Hacker News 转载页面提供的标题与链接信息整理，OpenAI 原文中具体的延迟数字、模型版本号、并发上限等细节未能从转载页面提取，读者如需引用具体指标，建议直接参阅 OpenAI 官方博客原文。