OpenAI 语音 AI 三连发：GPT-Realtime-2 实时推理、70 种语言同声翻译、流式转录全面拆解

本文由 莫潇羽@源码七号站（www.fuyuan7.com）撰写，转载请注明出处。

快速摘要

2026 年 5 月 7 日，OpenAI 一口气向开发者 API 推送了三款全新实时语音模型，分别是 GPT-Realtime-2、GPT-Realtime-Translate 和 GPT-Realtime-Whisper。

核心要点速览：

• GPT-Realtime-2 是 OpenAI 第一款把 GPT-5 级推理能力塞进实时语音对话的模型，上下文窗口从 3.2 万 token 直接扩展到 12.8 万，支持五档可调推理强度，能并行调用多个工具，说话更像真人。
• GPT-Realtime-Translate 是一套端到端语音翻译模型，支持 70 多种输入语言翻译到 13 种目标语言，声音进声音出，情绪语调都能保留，不走传统的"语音→文字→翻译→合成"老路子。
• GPT-Realtime-Whisper 是流式语音转文字模型，你嘴巴动、字幕同步出，专门解决直播字幕、实时会议纪要这种低延迟场景。
• 价格方面：GPT-Realtime-2 按 token 计费，输入 32 美元/百万 token，输出 64 美元/百万 token；翻译 0.034 美元/分钟；转录 0.017 美元/分钟。三款模型均已开放 API，可在 OpenAI Playground 直接测试。

语音 AI 不再是玩具，这三个模型标志着它正式走向生产级落地。

想看完整拆解，往下翻。

写在前面：这次为什么值得认真看

在过去几年里，我看过不知道多少篇"AI 语音助手新突破"的文章，大多数读完之后只剩一个感受：说得很好，但我用不上。要么功能只能在特定产品里体验，要么开放了 API 但文档不全、稳定性堪忧，要么就是成本高到根本不适合商用。

这次的情况稍微不同。GPT-Realtime-2、GPT-Realtime-Translate、GPT-Realtime-Whisper 三款模型，不是内测，不是 Preview 标记，是正式 GA（Generally Available，全面可用），意味着稳定性和服务承诺都达到了生产环境的标准。配套的文档、Playground 测试环境、定价体系，在发布当天就全部到位了。

我自己第一时间去 Playground 体验了 GPT-Realtime-2，对话响应的自然度和处理复杂指令的能力，比我此前预期的要好一截，这让我觉得这次的内容值得认认真真拆解一遍。

接下来我会按照三款模型依次拆解，从技术原理到开发接入到成本分析，争取让你读完这篇之后，对要不要把这些工具用到自己的项目里，能有一个相对清晰的判断。

语音交互这件事，人类念叨了将近二十年。从最早的 Siri、Google Now，到这几年的 ChatGPT 语音模式，每一代产品都打着"像和真人说话"的旗号，但用起来总差那么点意思。买手机的时候导购拿着 Siri 演示，现场挺神的，回家自己试就变回了"对不起，我不太明白你的意思"。

问题出在哪儿？我自己折腾这些东西折腾了好几年，总结下来核心缺陷就两个：一是脑子不够用，二是嘴巴不跟手。

脑子不够用，指的是以前的语音模型说白了是个管道——你说什么它就处理什么，遇到需要推理、需要查资料、需要多步骤完成的任务，要么卡壳要么给出一堆废话。举个例子，你让一个传统语音助手帮你安排明天的行程，它顶多能查一下日历，根本没办法把日历上的会议、交通时间、附近餐厅订座这些事情综合考量后给你一个有逻辑的方案。嘴巴不跟手，指的是延迟问题。传统语音翻译或者转录，要等你说完一句话才开始处理，实时性根本无从谈起。

这两个问题在以前根本上属于架构问题，不是微调一下就能解决的。

语音交互技术的演进脉络，大致可以分成这几个阶段：

第一阶段是规则引擎时代（2000 年代初到 2010 年代初）。语音识别靠的是预定义的关键词和语法树，系统只能处理它"认识"的命令，稍微说得绕一点就完全不行了。这时候的语音助手更像是一套命令行界面，只是换了个语音输入的皮。

第二阶段是 DNN（深度神经网络）时代（2012 年之后）。谷歌的 Word2Vec、百度的 Deep Speech 等工作让语音识别的准确率出现跨越式提升，Siri、Google Now、Cortana 先后涌现。这个阶段语音识别基本解决了"听懂"的问题，但"理解"和"推理"还远远不够。

第三阶段是大语言模型接入时代（2022 年之后）。ChatGPT 出现之后，文本理解能力出现了质变。OpenAI 等公司开始把 LLM 接到语音管道上，让识别出的文字进入 GPT 类模型处理，再把结果转回语音。这个阶段理解能力大幅提升，但三段式管道带来的延迟和信息损失问题并没有解决。

现在进入的是第四阶段：原生多模态语音模型时代。GPT-Realtime-2 代表的，正是这个方向——不再把语音当作文字处理的前处理步骤，而是直接在音频维度上建模，推理、理解、生成一气呵成。

直到 2025 年底前后，随着大模型音频多模态能力的提升，以及端到端语音建模技术的突破，以前那两个核心瓶颈才开始真正被攻破。OpenAI 这次发布的三款模型，正是这一技术积累到一定阶段后的集中释放。

值得一提的是，这次发布并不是孤立事件。GPT-5 的文本推理能力已经相当强悍，而 GPT-Realtime-2 所做的事，本质上是把这套推理能力接到了语音输入输出的管道上——让"耳朵"和"嘴巴"配上一个能真正思考的"大脑"。

莫潇羽@源码七号站 认为，这是语音 AI 从"功能演示"走向"工程落地"最关键的一步。语音智能体这个概念喊了很多年，真正能商业落地的产品却寥寥无几，这次的三款模型，可能是改变这一局面的起点。

二、GPT-Realtime-2：把 GPT-5 级推理装进语音交互

2.1 它到底和以前有什么本质区别

以前你跟语音助手说话，这个过程基本上是这样的：

用户说话 → STT（语音转文字）→ 语言模型处理 → TTS（文字转语音）→ 播放给用户

这套流程有几个显而易见的痛点：每一步都有延迟叠加，语调和情绪信息在文字转换过程中丢失，模型处理的是"文本"而非真正的"语音"，很多原本隐含在声音里的信息（语气、停顿、情绪）根本传不进去。

更深层的问题是，STT 和 TTS 本质上是两个独立的模型，它们并不知道对话的完整上下文，只是单纯地做格式转换。这导致即使中间的语言模型理解了对话意图，信息传递到最终语音输出时，也不可避免地打了折扣。

想象一个场景：你跟语音助手说"帮我找个附近评分高的日料，今晚七点，两个人，需要能停车"。传统助手拿到这个需求，可能查餐厅是查餐厅，但临时改口说"哦等等，我花生过敏"，它大概率已经忘了前面那些条件，重新给你一个没有考虑花生过敏的推荐。为什么？因为上下文窗口不够，也因为语音模型和推理模型是分开的两套系统，协作成本高。

GPT-Realtime-2 的底层架构改变了这个逻辑。它是一套原生多模态模型，直接处理音频输入和音频输出，不再依赖独立的 STT 和 TTS 模块作为前后处理。更重要的是，它在这条语音通路上接入了 GPT-5 级别的推理能力，让模型在与你对话的同时，能够同步完成复杂的思考和任务规划。

举个更直观的例子：现在你跟它聊找房子，说了七八轮之后突然改口"算了，我想租不想买"，它能顺着这个新方向继续往下推进，而不是重置整个对话从头来过。这在以前几乎是不可能的用户体验。

2.2 上下文窗口从 3.2 万跃升到 12.8 万

这个数字对普通用户可能没什么直观感受，但对于语音智能体的开发者来说，意义相当大。

简单打个比方：上下文窗口就是模型能"记住"的对话内容的总量。3.2 万 token 的窗口，大概够记住一次中等长度的对话；12.8 万 token 则意味着，就算你跟它聊了一两个小时，它也不会"忘事"。

对于那些需要长期跟踪用户意图、记录复杂任务进度的语音智能体，这个提升直接决定了产品能不能用。以前那种聊着聊着它把之前讲的全忘光的尴尬，终于有了根本性的解决方案。

2.3 五档可调推理强度：省算力还是深度思考，你来选

这是我觉得这次更新里最有工程实用性的一个设计。

GPT-Realtime-2 支持五个档位的推理强度调节，开发者可以根据实际场景灵活配置：

这就好比开车换挡，没必要上高速才挂五挡。简单的"今天天气怎么样"用低档快速回答，真正遇到需要做业务分析或者复杂任务规划的时候，挂到最高档让它仔细琢磨。这种设计让开发者在成本和效果之间找到最优平衡点，而不是一刀切地用最贵的计算资源应付所有场景。

2.4 Preamble 机制：告诉用户"我在想"

这个功能看起来小，但对用户体验的影响很直接。

以前当语音助手需要调用工具或者查询数据时，往往有一段空白期——用户不知道模型是在处理还是卡住了，体验很割裂。GPT-Realtime-2 引入了 Preamble（前置短语）机制，开发者可以开启这个功能，让模型在开始处理复杂请求时，先说一句"我查一下""稍等一秒"这类短语，告知用户它正在工作。

这个设计让语音交互的节奏感更像真人对话，显著减少用户的等待焦虑。

2.5 并行工具调用与透明化执行

GPT-Realtime-2 支持同时调用多个工具，并且可以把工具调用行为"说出来"。比如当它在同时查询你的日历和待办事项列表时，可以说"我正在查你的日程，同时看看相关的任务列表"，让整个过程对用户可见。

这对于语音智能体的商业落地非常关键。Zillow 是最早公开测试这个模型的企业之一，他们反馈 GPT-Realtime-2 在最难的对抗性评测中，通话成功率从 69% 提升到了 95%，提升了整整 26 个百分点。此外在公平住房合规性方面的表现也明显好于前一代模型，这对他们的业务场景至关重要。

2.6 更优雅的错误恢复行为

以前的语音模型遇到无法处理的情况，要么沉默，要么吐出一堆乱码，用户体验极差。GPT-Realtime-2 在错误恢复上做了专门优化，遇到问题时能够用自然语言告诉用户"这个我暂时处理不了"或者"我需要更多信息才能继续"，而不是直接挂起或者输出一个错误码。

这在实际部署中非常重要。一个能优雅处理边界情况的语音智能体，用户留存率和满意度都会显著更高。

2.7 评测数据怎么说

官方给出的基准测试数据：

• 在 Big Bench Audio（音频智能推理能力测试）上，GPT-Realtime-2 高强度模式比上一代 GPT-Realtime-1.5 高出 15.2%
• 在 Audio MultiChallenge（多轮对话智能测试，涵盖指令跟随、上下文整合、自洽性和自然语音纠错处理）上，最高强度模式比 GPT-Realtime-1.5 高出 13.8%

这两个评测维度都和真实生产场景的语音智能体表现高度相关，不是纯学术指标。

2.8 两个全新音色：Cedar 和 Marin

这次更新还顺带带来了两个新语音音色——Cedar 和 Marin，专为自然表达优化，是目前 Realtime API 里自然度表现最好的两个声音选项，原有的 8 种音色也得到了统一的升级。

音色选择对于商用产品的用户体验影响往往被低估。一个听起来机械、平淡的声音，即使内容再准确，也会让用户产生疏离感。Cedar 和 Marin 的引入，在语调的起伏、停顿的节奏以及情绪的表达上都比前代有可感知的提升。

如果你在开发面向消费者的语音产品，建议优先测一下这两个新音色，听感上的差异还是挺明显的。

2.9 MCP 服务器支持与图像输入

这次 Realtime API 还新增了两个之前没有的能力，值得单独提一下：

远程 MCP 服务器支持（Remote MCP Servers）：MCP（Model Context Protocol）是目前 AI 应用生态里快速普及的工具调用协议。Realtime API 现在支持直接连接远程 MCP 服务器，意味着开发者不需要在自己的后端里把所有工具都自己实现，可以直接挂载现有的 MCP 服务——比如日历服务、CRM 系统、内部知识库等。这对于快速搭建功能丰富的语音智能体来说是一个很大的便利。

图像输入：语音对话现在可以"看图说话"了。用户在对话中发送图片，模型可以结合图像内容继续对话。典型场景：用户拍一张菜单的照片说"帮我推荐几道菜"，或者拍一张错误截图说"这是什么问题"。

SIP 电话支持：Realtime API 现在直接支持通过 SIP（Session Initiation Protocol，会话发起协议）协议接入电话系统，这是电话客服、外呼系统的标准通信协议。以前要把 AI 语音能力接入电话系统，需要额外的电话网关中间层；现在 OpenAI 直接支持 SIP，接入路径大幅简化，对做电话客服智能化的企业来说是一个显著利好。

三、GPT-Realtime-Translate：端到端翻译彻底干掉"机翻腔"

3.1 老式语音翻译为什么听起来怪

这个问题很多人有过切身体验。用传统翻译软件开同声传译，哪怕翻译得再准确，听起来总是磕磕绊绊、机器味十足。

根本原因在于传统架构的三段式处理链路：

说话人声音
    ↓
STT（语音识别 → 文字）
    ↓
机器翻译（文字 → 目标语言文字）
    ↓
TTS（文字 → 合成语音）
    ↓
播放给听众

每一个环节都在做信息转换，每一次转换都有损耗。原始声音里包含的语气、停顿节奏、情绪起伏，在第一步 STT 就已经丢掉了；到了合成语音阶段，最多只能靠 TTS 引擎猜测应该用什么语调来念——这和说话人的真实情绪往往差很远。

3.2 GPT-Realtime-Translate 的端到端方案

GPT-Realtime-Translate 把这套三段式架构整合成了一个统一的模型，声音直接进、声音直接出，中间不再经过"转文字"这个环节。

这个设计的核心优势是：

• 延迟更低：省掉了链路上两到三次独立模型推理的时间
• 情绪语调得以保留：模型直接从原始音频里感知说话节奏和情绪，并映射到翻译后的声音输出上
• 连读和语气更自然：不再需要把完整的句子切块、转文字再合成，对话节奏更流畅

我自己测试下来感受最深的就是最后一点。用传统同声传译工具开视频，你会明显感觉翻译声总是"跟不上"说话人，而且每句话的收尾有种生硬的截断感。Realtime Translate 的输出则更像是一个同步跟着说话的同传译员，停顿就跟着停，加速就跟着加速。

莫潇羽@源码七号站做过一组对比实验，拿同一段带情绪波动的英语演讲分别走传统 STT+翻译+TTS 流程和 Realtime Translate 处理，后者在保留说话节奏和情绪感方面有肉眼可见的差距。

3.3 70 种输入语言 × 13 种输出语言

目前 GPT-Realtime-Translate 支持：

• 输入语言：70 多种，覆盖主流欧洲语言、亚洲语言（包括中文、日语、韩语、印地语、泰米尔语、泰卢固语等）、阿拉伯语、以及多种小语种
• 输出语言：13 种（具体覆盖了英语、中文、日语、西班牙语等主流语言）

一家专注于印度市场语音 AI 的团队做过专项评测，在印地语、泰米尔语、泰卢固语三种语言上，GPT-Realtime-Translate 的词错率（Word Error Rate）比其他同类模型低了 12.5%，同时任务完成率更高、延迟也能维持自然对话的节奏。这个数据对于方言、口音密集的市场来说，实用意义很大。

3.4 情绪和语调为什么能保留下来

这是端到端模型最有意思的一个特性，技术上值得多聊几句。

传统的语音翻译管道中，情绪信息的丢失发生在第一步 STT 阶段。把语音转成文字时，声学特征（说话速度、音调变化、停顿长度、音量起伏）几乎全部被抛弃了，只保留了语义内容。到了最后一步 TTS 合成时，系统顶多根据标点符号猜一下语气——句号就平淡地念完，感叹号可能稍微提个调，仅此而已。

端到端模型的处理逻辑不同。模型直接从输入音频中提取声学特征，和语义信息一起参与翻译过程，最终输出的音频在节奏和情绪映射上都经过了专门的建模。说得激动时，翻译出来的声音也相应更有力；说到一半停顿思考，翻译也会有对应的停顿而不是机械地照念。

这种设计在情绪密集的场景里差距最明显。比如在谈判场景里，说话人刻意放慢语速表示强调，或者销售打电话时用特意上扬的语调建立亲和力——这些信息通过端到端翻译可以很大程度上保留下来，而传统方案基本做不到。

3.5 典型应用场景拆解

跨境客服与销售

以前搭建一套能覆盖多语言的客服系统，要么堆翻译人员成本，要么用效果差的自动翻译将就。现在一套 GPT-Realtime-Translate 接口，可以让一个讲中文的客服代理直接和讲西班牙语的用户实时沟通，两边听到的都是自己母语。德国电信（Deutsche Telekom）已经在内部探索这个方案，用于跨语言的客户服务场景。

这里有个很实际的商业逻辑：一家欧洲企业如果要支持 10 种语言的电话客服，传统做法是在每种语言上都配备一定数量的本地化客服人员，人力成本是乘法。引入实时翻译模型之后，语言能力可以从人力配置里解耦出来，一套系统覆盖全部语言，核心服务人员反而可以更集中地专注在业务复杂度而不是语言壁垒上。

国际会议同传

线下会议请专业同传的费用不菲，而且人工同传也会疲劳、出错。实时翻译模型可以作为辅助或者低成本替代方案，为每位参会者在耳机里提供实时翻译。

当然，专业会议涉及高度领域化的术语和极高的准确率要求，目前 AI 同传在极度专业化的场景（比如联合国级别的外交翻译）还不能完全替代顶级人工同传。但对于大量商务会议、学术交流、内部培训这类场景，实时翻译模型在成本和效果之间的平衡已经越来越具有竞争力。

在线教育

一位讲师录一套课，通过 Realtime Translate，不同语言背景的学生可以实时听到本语言版本，而不是等着有人翻译配音后再看。这对那些面向全球市场的在线教育平台来说，是个降本增效的重要工具。

更进一步，在直播教学场景里，学生用母语提问，讲师用自己的语言回答，双向实时翻译——这个场景以前实现起来工程复杂度很高，现在通过 Realtime API 可以相对容易地落地。

海外旅行和跨语言日常交流

拿出手机开个翻译，两个不同语言的人可以直接聊，这个场景以前不是不能实现，但翻译质量和延迟让体验很差。端到端模型的加入让这个场景终于变得真正好用。

在这个方向上，一些耳机厂商已经在探索把实时翻译能力集成进无线耳机里，实现类似科幻电影里那种"贴在耳朵里的翻译器"体验。有了 API 级别的底层能力，这类产品的落地时间表会大幅缩短。

内容创作与媒体

Podcast、YouTube 视频这类内容，做多语言版本一直需要大量的翻译配音工作。实时翻译能力不仅适用于直播场景，也可以处理录播内容，大幅降低多语言内容制作的边际成本。

四、GPT-Realtime-Whisper：让字幕"跑"起来

4.1 流式转录是什么

先解释一下名词。"流式转录"（Streaming Transcription）对应的是"批量转录"，区别很简单：

• 批量转录：等你说完一段话，甚至一整个文件，模型才开始处理，出结果有明显延迟
• 流式转录：你边说，模型边识别、边输出文字，几乎同步

GPT-Realtime-Whisper 走的就是流式路线，针对低延迟场景专门设计。

4.2 传统方案的延迟问题到底有多影响使用

举个直播字幕的例子。主播说了一句话，传统语音识别可能要等 1—3 秒才出字，观众看到字幕时，主播已经讲了下一段内容了，字幕永远在追。这在直播、在线课堂这类强实时场景里，观感很差。

再说会议纪要。传统方案通常是会议结束后，把录音导入语音识别软件跑一遍，再人工修改。遇到一个三个小时的全员会议，处理完往往已经是当天深夜了。而如果有实时转录能力，会议纪要可以在会议进行中同步生成，结束就能直接拿到可用的文字稿。

4.3 GPT-Realtime-Whisper 的技术思路

Whisper 这个名字来自 OpenAI 早年开源的语音识别模型 Whisper（2022 年发布），那个版本是批量处理模式，虽然准确率高，但天然不适合实时场景。GPT-Realtime-Whisper 在此基础上做了面向流式输出的架构重设计。

具体来说，它把音频流切成极短的片段（远短于一句话），对每个片段进行预测，同时利用上下文信息做滚动修正，让最终输出保持连贯和准确，而不是一堆破碎的片段拼接。这种设计在低延迟和高准确率之间取得了比较好的平衡。

值得一提的是，GPT-Realtime-Whisper 在处理专业术语、人名、字母数字混合串这些传统语音识别的弱项时，表现比前一代模型有明显提升。对于客服质检、医疗记录、法律速记这些专业场景，这一点很关键。

同时，这个模型对噪声环境的鲁棒性也有提升。在背景音嘈杂（比如会场、嘈杂的办公室）的条件下，转录的稳定性相比早期 Whisper 版本有可感知的改善。虽然极端噪声条件下仍然会有准确率下降，但日常使用场景下的容错能力已经足够实用。

4.4 这个模型最适合哪些开发场景

直播字幕生成

无论是游戏直播、教育直播还是新闻直播，实时字幕不仅改善观看体验，也是无障碍访问的重要组成部分。GPT-Realtime-Whisper 的低延迟特性，让字幕从"追着播"变成"同步走"。对于有无障碍合规要求的平台（很多国家和地区的法规对公开直播的字幕都有要求），这个工具可以大幅降低合规成本。

会议实时纪要

你在开会，屏幕上的文字就在同步跑。会议结束时，一份可用的文字纪要已经出来了，不需要额外的处理时间。Priceline 已经在探索用这套技术支持内部旅行服务相关的对话记录和跟进工作流。

这里有一个实际工程细节值得注意：会议纪要不只是转录，还需要识别不同说话人（Speaker Diarization）。GPT-Realtime-Whisper 目前本身不包含说话人分离能力，如果需要区分不同与会者的发言，还需要额外集成说话人分离模型。这是当前版本的一个局限，评估时要考虑进去。

客服质检

传统客服质检需要先录音、再转录、再人工抽样检听，链路长、成本高、覆盖率低。流式转录可以让质检系统在通话进行中同步分析内容，实时触发预警或者标记关键词，整个流程效率完全不同。比如，可以实时检测客服是否使用了规定的合规话术，或者自动捕捉用户情绪激烈的时刻，立刻推送给督导介入。

语音智能体的"耳朵"

如果你在开发一个语音智能体，GPT-Realtime-Whisper 可以作为持续监听和理解的模块，让智能体能够连续跟踪用户说话内容，而不是等待完整的句子才触发处理。这对于那些需要打断处理（用户说到一半就改变意图）的场景很有用。

无障碍辅助工具

实时字幕是听障人士日常生活中极为重要的辅助工具。目前很多自动字幕系统的延迟和准确率都还不够好，尤其是在处理口音、专业词汇、夹杂方言时。GPT-Realtime-Whisper 的准确率提升和低延迟特性，让它成为这个应用方向上值得认真评估的选项。

五、开发者怎么接入：Realtime API 使用入门

5.1 整体架构概览

三款模型都通过 OpenAI 的 Realtime API 提供服务，底层通信协议是 WebSocket——这是实时双向通信的标准方案，浏览器端和服务端都可以使用。

客户端（浏览器/App/服务）
        ↕ WebSocket 长连接
OpenAI Realtime API
        ↕
GPT-Realtime-2 / Translate / Whisper

整个会话的生命周期：

创建 Session → 建立 WebSocket 连接 → 发送音频流 → 接收响应流 → 关闭 Session

5.2 一个最简单的 GPT-Realtime-2 接入示例（Node.js）

下面是一个极简的 WebSocket 接入框架，供参考：

import WebSocket from 'ws';

const url = 'wss://api.openai.com/v1/realtime?model=gpt-realtime-2';

const ws = new WebSocket(url, {
  headers: {
    'Authorization': `Bearer ${process.env.OPENAI_API_KEY}`,
    'OpenAI-Beta': 'realtime=v1',
  },
});

ws.on('open', () => {
  console.log('连接已建立');

  // 配置 Session
  ws.send(JSON.stringify({
    type: 'session.update',
    session: {
      modalities: ['audio', 'text'],
      voice: 'cedar',         // 新增音色：cedar 或 marin
      reasoning_intensity: 'high',  // 推理强度：low / medium / high / xhigh
      input_audio_format: 'pcm16',
      output_audio_format: 'pcm16',
    },
  }));
});

ws.on('message', (data) => {
  const event = JSON.parse(data);

  if (event.type === 'response.audio.delta') {
    // 收到音频流片段，可以边收边播放
    playAudioChunk(event.delta);
  }

  if (event.type === 'response.text.delta') {
    process.stdout.write(event.delta);
  }
});

// 发送音频数据
function sendAudio(audioBuffer) {
  ws.send(JSON.stringify({
    type: 'input_audio_buffer.append',
    audio: audioBuffer.toString('base64'),
  }));
}

这里有几个需要注意的细节：

• reasoning_intensity 对应上面说的五档推理强度，默认值是 medium，按需调整
• voice 这次新增了 cedar 和 marin 两个音色，专为自然表达优化，原有的 8 种音色也有对应更新
• 音频格式推荐 pcm16，兼容性最好

5.3 GPT-Realtime-Translate 接入要点

翻译模型的接入和 GPT-Realtime-2 的方式基本一致，主要区别在 Session 配置上：

ws.send(JSON.stringify({
  type: 'session.update',
  session: {
    model: 'gpt-realtime-translate',
    source_language: 'zh',     // 输入语言
    target_language: 'en',     // 输出语言
    modalities: ['audio'],
    preserve_emotion: true,    // 保留情绪和语调（推荐开启）
  },
}));

5.4 GPT-Realtime-Whisper 接入要点

纯转录场景不需要音频输出，配置相对简单：

ws.send(JSON.stringify({
  type: 'session.update',
  session: {
    model: 'gpt-realtime-whisper',
    modalities: ['text'],           // 只需要文字输出
    input_audio_format: 'pcm16',
    output_language: 'zh',          // 转录输出语言
  },
}));

转录结果会通过 conversation.item.input_audio_transcription.completed 事件推送过来，包含时间戳和置信度信息，方便下游业务系统处理。

5.5 如何选择用哪个模型

你的需求是...
├── 需要语音对话 + 推理 + 工具调用？
│   → GPT-Realtime-2
├── 需要实时跨语言翻译？
│   → GPT-Realtime-Translate
└── 只需要把声音变成文字（不需要理解或翻译）？
    → GPT-Realtime-Whisper（成本最低）

如果你的应用同时需要翻译和转录，可以把 GPT-Realtime-Translate 和 GPT-Realtime-Whisper 配合使用——翻译模型处理跨语言对话，Whisper 模型同步生成原文转录记录。

5.6 Session 管理与状态控制

Realtime API 是有状态的——每个 WebSocket 连接对应一个 Session，Session 里保存着对话历史和模型状态。理解 Session 的生命周期对于构建健壮的应用至关重要。

Session 的几个关键事件：

session.created    → WebSocket 连接成功，Session 建立
session.updated    → Session 配置更新完成
input_audio_buffer.speech_started  → 检测到用户开始说话
input_audio_buffer.speech_stopped  → 检测到用户停止说话
response.created   → 模型开始生成响应
response.done      → 本轮响应完成
session.closed     → Session 结束

在实际工程中，一个健壮的 Session 管理器需要处理这些边界情况：

• 超时断连：WebSocket 连接空闲太久会被服务端主动断开，客户端需要实现心跳保活机制
• 用户中途打断：用户在模型说话时插话，需要清空播放队列并发送 response.cancel 信号
• 网络抖动恢复：断线重连后，如果对话上下文需要恢复，要在新 Session 里把历史对话传回去

// 心跳保活
let heartbeatInterval;

function startHeartbeat(ws) {
  heartbeatInterval = setInterval(() => {
    if (ws.readyState === WebSocket.OPEN) {
      // 发送一个空的音频缓冲区保持连接活跃
      ws.send(JSON.stringify({
        type: 'input_audio_buffer.append',
        audio: ''
      }));
    }
  }, 20000); // 每 20 秒发一次心跳
}

function stopHeartbeat() {
  if (heartbeatInterval) {
    clearInterval(heartbeatInterval);
  }
}

5.7 多 Session 并发与资源控制

如果你的应用需要支持大量并发用户同时使用语音功能，后端的 Session 并发控制不能忽视。每个活跃的 Realtime Session 都在持续消耗 API 配额和带宽，需要做好以下几点：

• 并发数量上限：根据 API 配额设置最大并发 Session 数，超出时做好排队或降级处理
• Session 超时回收：设置最大 Session 存活时长（比如 30 分钟），避免僵尸 Session 占用资源
• 用量统计：按用户或者按 Session 记录 token/分钟消耗，方便后续的成本分析和异常排查

对于中等规模的 SaaS 产品，建议在后端维护一个 Session Pool，而不是每个用户请求都新建一个 Session——对于有冷启动延迟要求的场景，预热少量 Session 备用是一个常见的优化手段。

五点五、Realtime API 与现有方案的横向对比

在决定是否接入之前，我们不妨把 GPT-Realtime 系列和目前市面上常见的语音 AI 方案做一个对比，方便做技术选型。

主流语音 AI 方案对比

从这个对比表可以看出一些规律：

如果你的需求是纯粹的高精度、低成本转录，Deepgram 在价格上更有优势（约为 GPT-Realtime-Whisper 的四分之一），而且延迟