OpenAI 近期在 Realtime API 中推出新一批 GPT-Realtime-Translate 语音模型，其中最适合一般用户立即感受到差异的，可能不是语音助理，而是即时语音翻译。 日本创作者 Motoki | ZentoAI 在 X 上分享，他用 Codex 依照 OpenAI 官方 Cookbook 文件做出一个 GPT-Realtime-Translate 应用，测试浏览器分页音频的即时翻译效果，并附上官方教程与 GitHub 范例代码。 从目前公开资料来看，这套工具已经不是概念展示，而是可以在本地端用Node.js架起来测试的开发者范例。
GPT-Realtime-Translate 是什么？
GPT-Realtime-Translate 是 OpenAI 新推出的即时语音翻译模型，定位不是一般语音助理，而是专门用于 speech-to-speech live translation，也就是把输入语音即时翻成另一种语言的语音，同时可输出文字逐字稿 。 OpenAI官方说法是，这个模型支持超过70种输入语言，并可翻译成13种输出语言，目标场景包括线上会议、直播、课程、跨国客服、活动、媒体内容与创作者平台。 它和常规语音模型最大的不同，是模型被设计成「翻译」而不是「回答」，因此不需要用 prompt 要求模型扮演翻译员，也比较不会把用户讲的内容当成指令来执行。
OpenAI Cookbook 的说明指出，GPT-Realtime-Translate 采用连续音频输入与连续翻译输出的模式，不需要像传统语音对话一样等待一轮话讲完再产生回应。 模型会处理输入音频，同时串流输出翻译后的语音与字幕。 这对语序差异大的语言特别重要，因为翻译系统必须等待足够语境，又不能让延迟变得太明显。
可以本地端架设吗？
根据我们实测，一般人可以很容易的将这个实时翻译架设在自己本地端，但这不是把模型下载到本地离线运算，而是本地端架设前端与Node.js server，实际语音翻译仍连到 OpenAI Realtime Translation API。 X 上的网友使用蓝牙耳机也可以实时翻译。
官方 Cookbook 目前提供三种 demo：Browser tab translation、Twilio phone translation、LiveKit video translation。 若只是想在自己的电脑测试，最容易架设的是 browser-translation-demo。 官方README显示需求只有OpenAI API key、Node.js，以及浏览器端的标签音频授权。
基本流程如下，官方 Github 网站有详细说明（如果看不懂的话，可以丢那个网址叫 OpenClaw 或 Hermes 帮你架设，难度不高）：
git clone https://github.com/openai/openai-cookbook.git
cd openai-cookbook/examples/voice_solutions/realtime_translation_guide/browser-translation-demo
npm install
cp .env.example .env
npm run dev.env 至少需要填入：
OPENAI_API_KEY=your-openai-api-key
OPENAI_TRANSLATION_MODEL=gpt-realtime-translate
OPENAI_INPUT_TRANSCRIPTION_MODEL=gpt-realtime-whisper
PORT=5173打开本地端网址后，用户可以选择一个有声音的浏览器分页，指定输出语言，App 就会通过 WebRTC 把音频送往 OpenAI Realtime Translation API，再把翻译后的语音和字幕播放回本地页面。
不过这里有一个很容易踩到的坑：官方 browser-translation-demo 默认只抓「Chrome 标签音频」，不会主动要求麦克风权限。 如果拿它来测电话、FaceTime、LINE 通话、Zoom 桌面 App，或任何不是 Chrome 标签播放的声音，浏览器可能不会传入音频轨，画面就会出现 。 这不是 OpenAI API 失败，而是前端根本没有取得可翻译的音频来源。No tab audio was shared. Pick a Chrome tab and enable tab audio.
如果只是要测电话或外部声音，做法应该改成麦克风输入：让网页呼叫 ，请用户授权麦克风，再把麦克风音频送进同一条 WebRTC Realtime Translation 流程。 这样测电话时可以把电话开扩音，让电脑麦克风收音; 若要做正式产品，才需要进一步串接 Twilio、SIP、LiveKit 或系统音频路由。navigator.mediaDevices.getUserMedia({ audio: true })
我们实测自己这台 Mac mini 完成 browser-translation-demo 本地架设，测试结果如下，目前还是感觉有一点延迟但表现已经很惊艳：
比较需要注意的是浏览器。 官方 demo 使用 撷取分页音频，这在 Chrome、Edge 类浏览器通常比 Safari 稳定。 如果要测 YouTube、直播或网页视频的即时翻译，建议用 Chrome 开 demo，并在分享窗口中勾选分享分页音频。 如果要测电话或桌面App声音，则应切到，允许麦克风后再测。getDisplayMedia()Microphone / call speaker
实用性与限制
这项技术最有价值的地方，是它把「实时口译」从大型平台功能变成开发者可以快速嵌入的 API。 过去若要做直播翻译，常见流程是语音转文字、文字翻译、文字转语音，三段式架构不只延迟高，也容易在每个环节累积错误。 GPT-Realtime-Translate 则把即时翻译做成单一语音模型流程，对使用体验有明显优势。
但目前仍有几个限制。 第一，输出语言不是无限制，官方 demo 的代码列出的支持输出语言包含 、、、、、、、、、、、、。 第二，它目前不支持自定义 prompt 或指定声音，模型会根据来源说话者的语气、音高和风格做动态语音适配。 第三，这是云端 API 服务，不适合被误解成完全离线的本地翻译工具。esptfrjaruzhdekohiidviiten
OpenAI 这波更新不只针对翻译，还包括 GPT-Realtime-2 和 GPT-Realtime-Whisper，代表 OpenAI 正把语音 API 从单纯对话功能，推向可即时理解、翻译、转录与执行任务的开发平台。
小结
GPT-Realtime-Translate 的重点不是「又一个翻译 App」，而是 OpenAI 把即时语音翻译变成可被一般开发者快速整合的基础能力。 对一般用户来说，它可以拿来翻译 YouTube、直播、在线课程或远程会议; 对开发者来说，它更像是一个可嵌入客服、电话、视频会议和直播系统的实时口译模块。 真正要注意的是，它不是离线模型，成本按分钟累积，也需要处理音频隐私与服务稳定性。
