OpenAI 发布 GPT-Realtime-2.1 和 GPT-Realtime-2.1-mini 实时语音模型:mini 模型具备推理能力,延迟下降 25%
- OpenAI 在 API 里同时上线两款新的 Realtime 模型:gpt-realtime-2.1 和 gpt-realtime-2.1-mini,都面向低延迟语音与多模态场景
- gpt-realtime-2.1-mini 是第一个进入 mini 价位的「会推理」实时语音模型,定价和上一代 gpt-realtime-mini 完全一致
- 两款模型的推理强度都能配置,共五档(minimal / low / medium / high / xhigh),默认用 low 来压住延迟
- 靠缓存优化,全系 Realtime 语音模型最慢那部分请求的响应时间至少下降 25%;mini 版缓存命中的音频输入价,从每百万 token 10 美元降到 0.30 美元
- gpt-realtime-2.1 相比上一代改进了字母数字识别、静音与噪声处理、打断行为;mini 版音频输出价约为完整版的三分之一(20 美元对 64 美元)
OpenAI 这次发了什么
OpenAI 近日在 API 里同时发布了两款新的 Realtime 模型,gpt-realtime-2.1 和 gpt-realtime-2.1-mini,都面向低延迟语音与多模态交互场景。
这两款都是负责「听懂并回应」的语音助手型号,走的是 Realtime 家族里对话应答、调工具那条线;OpenAI 另外还有专门做同声传译的 gpt-realtime-translate、专门做实时转写的 gpt-realtime-whisper,是两个独立型号,这次发布不涉及它们。
先弄清楚「Realtime」是怎么跑的
Realtime API 的底子是:一个模型直接把听到的语音处理成说出的语音。它省掉了「语音转文字,生成回答文字,再合成语音」这三道来回的转手。这就是所谓的单模型语音到语音(speech-to-speech)。两种做法的差别,看下面这张对照。
语音 → 转成文字 → 生成回答文字 → 再合成语音。每道接缝都要等上一步做完,延迟一层层累加,说话人的语气和停顿这些细节也容易在转文字时丢掉。
一个模型,语音进、语音出,中间不再拆成三段。少了两道接缝,延迟更低,说话的语气和细节也更能保留下来。
单模型像两个人当面直接说话。三道转手那种,好比你说一句,旁边先有人把话记成文字条子,另一个人再照着条子念出来,慢,而且语气全在纸条上磨没了。
语音助手以前卡在哪
语音助手在调用工具时经常卡住。模型触发一次函数调用后就沉默了,用户以为电话掉线,就出声打断或者干脆挂断,对话状态被打乱,最后只拿到半截结果,还得重新打一遍。
推理进了 mini 档,怎么解决沉默问题
这一节是这次发布的重心:推理能力下放到低价 mini 档,配合「口头预告」,正好治的就是上一节那个沉默掉线的老毛病。
「推理」在这里指什么
推理(reasoning),指模型在开口回答前,先在心里想清楚这句话该怎么处理、要不要调用工具,而不是听到什么就立刻脱口而出。mini 档现在也支持工具调用(function calling),所以它能先规划一步,去调你的函数,再给出答案。
口头预告,让沉默变成边说边做。模型可以先说一句「我这就去查一下」,然后一边处理请求一边继续说话。用户全程听得到声音,不会以为掉线,多步骤的语音任务因此保持连贯。
更关键的是价格:mini 版新增了推理,定价却和上一代 gpt-realtime-mini 保持完全一致。成本敏感的语音应用,第一次能不加钱就用上推理和工具调用。
把一次带工具的对话拆开看,时序是这样的:
推理强度五档,怎么在延迟和质量间取舍
推理强度可以配置,从低到高共五档:minimal、low、medium、high、xhigh。low 是默认档,能把简单对话的延迟压住;强度越高,延迟和输出 token 用量都跟着涨。OpenAI 建议大多数生产环境的语音助手都从 low 起步,遇到更难的任务再往上调。
两款模型怎么选
一句话分工:要最强的实时推理、工具调用、指令遵循和语音助手表现,用完整版 gpt-realtime-2.1;要更快更省、能力够用就行,用 gpt-realtime-2.1-mini。
| 维度 | gpt-realtime-2.1(完整版) | gpt-realtime-2.1-mini |
|---|---|---|
| 定位 | 最强实时推理与语音助手行为 | 更快、更省的选项 |
| 推理 | 有,强度可调 | 有,mini 推理模型 |
| 工具调用 | 有 | 有 |
| 相比上一代的改进 | 字母数字识别、静音与噪声处理、打断行为都更好 | 保持上代 mini 能力,新增推理 |
| 音频输出价 | $64 / 百万 token | $20 / 百万 token |
| 该选它当… | 要最强推理和语音助手表现 | 要速度和成本,能力够用 |
延迟砍 25%,缓存怎么省钱
这次的延迟改进,来自缓存优化。而缓存不只省时间,还大幅省钱。
先看「p95 延迟」是什么
p95 延迟,是把所有请求的响应时间从快到慢排好队,取排在第 95% 位置的那个值。它代表最慢的那 5% 用户实际等了多久,不是平均耗时。对实时语音来说,用户真正感觉到的卡顿,就藏在这条最慢的尾巴里。把这条尾巴砍掉至少 25%,通话体验会明显跟手。
100 个人排队结账,你真正在意的不是平均等待时间,而是排在倒数第 5 位那几个人等了多久。他们不骂街,这个系统才算稳。
缓存命中,为什么价格骤降
缓存命中输入(cached input)指的是:这一轮对话延续了之前处理过的系统提示或历史内容,服务能认出「这段算过了」,直接复用而不用重新计算,价格因此骤降。系统提示在第一轮之后就被缓存了,所以对话越长、复用越多,越省。以 mini 版的音频输入为例,缓存命中价和新鲜价的差距是这样的:
三款模型价格全貌
价格都按每百万 token 计,分文本、音频、图像三类。点标签切换看其中一类,mini 列已高亮。
| 音频 / 每百万 token | gpt-realtime-2.1 | 2.1-mini | 上代 mini |
|---|---|---|---|
| 音频输入 | $32.00 | $10.00 | $10.00 |
| 音频缓存输入 | $0.40 | $0.30 | $0.30 |
| 音频输出 | $64.00 | $20.00 | $20.00 |
| 文本 / 每百万 token | gpt-realtime-2.1 | 2.1-mini | 上代 mini |
|---|---|---|---|
| 文本输入 | $4.00 | $0.60 | $0.60 |
| 文本缓存输入 | $0.40 | $0.06 | $0.06 |
| 文本输出 | $24.00 | $2.40 | $2.40 |
| 图像 / 每百万 token | gpt-realtime-2.1 | 2.1-mini | 上代 mini |
|---|---|---|---|
| 图像输入 | $5.00 | $0.80 | $0.80 |
| 图像缓存输入 | $0.50 | $0.08 | $0.08 |
适合拿来做什么
四类典型场景,各自怎么用到推理、工具调用和识别改进:
用户打电话说有笔账单不对。mini 用低强度推理判断问题,先调 lookup_account 查账户,再调 check_invoice 查发票,每一步都口头说明进度,用户不会以为掉线。
用户要把预约改到下周二。模型逐字捕捉准确日期,先跟用户确认,再调 reschedule 函数。确认过的值,才拿去调工具,避免用猜的输入。
手机 App 用 WebRTC 把麦克风音频流过来。mini 用一两句短话回答产品问题,成本低,这个功能可以高并发地跑。
技术员让助手记一个零件号。改进后的字母数字识别,能更准地抓到「8-3-5-7-1」这样的编码,模型会先读回来确认,再执行。
接入起来什么样
最小实现是这样:服务端先签发一个短命的客户端凭证(标准 API key 留在服务端不外泄),浏览器拿着这个短期凭证,直接用 WebRTC 连过去,建立麦克风轨道和一条数据通道来收发事件。
连接方式按场景挑:浏览器和手机端直接采集播放音频,走 WebRTC;服务端已经拿到原始音频流(呼叫中心、媒体管道),走 WebSocket;电话语音代理走 SIP。
点开看两段最小代码(服务端签发凭证 + 浏览器发起连接)
// Server: mint a short-lived client secret
const r = await fetch("https://api.openai.com/v1/realtime/client_secrets", {
method: "POST",
headers: {
Authorization: `Bearer ${process.env.OPENAI_API_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
session: {
type: "realtime",
model: "gpt-realtime-2.1-mini",
instructions: "You are a support agent. Reply in one or two short sentences.",
reasoning: { effort: "low" },
tools: [
{
type: "function",
name: "lookup_account",
description: "Look up a customer account by email.",
parameters: {
type: "object",
properties: { email: { type: "string" } },
required: ["email"]
}
}
],
tool_choice: "auto"
}
})
});
const { value: EPHEMERAL_KEY } = await r.json(); // pass this to the browser
// Browser: connect to the Realtime API over WebRTC
const pc = new RTCPeerConnection();
const audioEl = document.createElement("audio");
audioEl.autoplay = true;
pc.ontrack = (e) => { audioEl.srcObject = e.streams[0]; };
const mic = await navigator.mediaDevices.getUserMedia({ audio: true });
pc.addTrack(mic.getTracks()[0]);
const events = pc.createDataChannel("oai-events");
events.addEventListener("message", (e) => console.log(JSON.parse(e.data)));
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);
const sdp = await fetch("https://api.openai.com/v1/realtime/calls", {
method: "POST",
body: offer.sdp,
headers: {
Authorization: `Bearer ${EPHEMERAL_KEY}`,
"Content-Type": "application/sdp"
}
});
await pc.setRemoteDescription({ type: "answer", sdp: await sdp.text() });
起步用 low 推理强度,只有更难的任务才往上调;指令里把硬规则和默认值分开写;换模型迁移前后,各跑一遍 eval 对照。
这次走的是正式 GA 接口,不是 beta 版。如果应用会区分终端用户身份,官方建议在签发凭证的请求上加一个 OpenAI-Safety-Identifier 请求头(比如内部用户 ID 的哈希),方便平台监测滥用时精确定位到具体用户,而不是误封整个账号。
优势在哪,局限在哪
按 OpenAI 公布的口径,这次发布的两面:
- 推理下放到低价的 mini 档
- 定价和上一代 gpt-realtime-mini 一致,没涨价
- 全系 p95 延迟至少降 25%
- 推理强度五档可调,按任务在延迟和深度间取舍
- 单模型音频管线,让对话更自然
- 音频按 token 计费,难换算成单次通话的实际成本
- 推理强度调高,延迟和输出 token 都会涨
- 长会话反复重发上下文,不裁剪的话输入成本会累积
- mini 档的能力仍弱于完整版 gpt-realtime-2.1
模型可以先说一句「我这就查这笔订单」,然后一边处理请求一边继续说话,多步骤的语音任务因此保持连贯。 MarkTechPost,作者 Michal Sutter