产品发布 · 小互解读

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 公布口径,未经第三方独立测试;技术细节已对照 OpenAI 官方 Realtime API 指南核对。
我这就去查
01发布速览

OpenAI 这次发了什么

OpenAI 近日在 API 里同时发布了两款新的 Realtime 模型,gpt-realtime-2.1 和 gpt-realtime-2.1-mini,都面向低延迟语音与多模态交互场景。

这次真正的重点是那个 mini。gpt-realtime-2.1-mini 是第一个进入 mini 价位的会推理的实时语音模型,定价和上一代 gpt-realtime-mini 完全一样。同时,全系 Realtime 语音模型最慢那批请求的响应时间,也一起降了下来。
为什么值得看:推理能力第一次下放到和旧款同价的 mini 档实时语音模型,同时全系 Realtime 语音模型最慢那 5% 请求的响应时间,至少降了 25%。成本敏感的语音应用,第一次能在不加钱的前提下拿到推理和工具调用。

这两款都是负责「听懂并回应」的语音助手型号,走的是 Realtime 家族里对话应答、调工具那条线;OpenAI 另外还有专门做同声传译的 gpt-realtime-translate、专门做实时转写的 gpt-realtime-whisper,是两个独立型号,这次发布不涉及它们。

先弄清楚「Realtime」是怎么跑的

Realtime API 的底子是:一个模型直接把听到的语音处理成说出的语音。它省掉了「语音转文字,生成回答文字,再合成语音」这三道来回的转手。这就是所谓的单模型语音到语音(speech-to-speech)。两种做法的差别,看下面这张对照。

级联老办法(三道转手)

语音 → 转成文字 → 生成回答文字 → 再合成语音。每道接缝都要等上一步做完,延迟一层层累加,说话人的语气和停顿这些细节也容易在转文字时丢掉。

单模型一步(这次的做法)

一个模型,语音进、语音出,中间不再拆成三段。少了两道接缝,延迟更低,说话的语气和细节也更能保留下来。

打个比方

单模型像两个人当面直接说话。三道转手那种,好比你说一句,旁边先有人把话记成文字条子,另一个人再照着条子念出来,慢,而且语气全在纸条上磨没了。

02老问题

语音助手以前卡在哪

语音助手在调用工具时经常卡住。模型触发一次函数调用后就沉默了,用户以为电话掉线,就出声打断或者干脆挂断,对话状态被打乱,最后只拿到半截结果,还得重新打一遍。

旧办法:沉默等待
用户帮我查一下上个月那笔订单
助手(沉默,正在后台查询…)
用户喂?还在吗?(以为掉线,打断)
状态对话被打断,只拿到半截结果
新办法:边说边做
用户帮我查一下上个月那笔订单
助手好的,我这就帮你查这笔订单
助手(后台调用查询工具的同时继续说话)找到了,是 6 月 3 号那笔…
状态用户全程知道在进行,不会误挂
03核心机制

推理进了 mini 档,怎么解决沉默问题

这一节是这次发布的重心:推理能力下放到低价 mini 档,配合「口头预告」,正好治的就是上一节那个沉默掉线的老毛病。

「推理」在这里指什么

推理(reasoning),指模型在开口回答前,先在心里想清楚这句话该怎么处理、要不要调用工具,而不是听到什么就立刻脱口而出。mini 档现在也支持工具调用(function calling),所以它能先规划一步,去调你的函数,再给出答案。

核心创新

口头预告,让沉默变成边说边做。模型可以先说一句「我这就去查一下」,然后一边处理请求一边继续说话。用户全程听得到声音,不会以为掉线,多步骤的语音任务因此保持连贯。

更关键的是价格:mini 版新增了推理,定价却和上一代 gpt-realtime-mini 保持完全一致。成本敏感的语音应用,第一次能不加钱就用上推理和工具调用。

把一次带工具的对话拆开看,时序是这样的:

听到请求
内部推理想清楚怎么做、要不要调工具
说出预告「我这就去查」
调用工具
说出结果

推理强度五档,怎么在延迟和质量间取舍

推理强度可以配置,从低到高共五档:minimal、low、medium、high、xhigh。low 是默认档,能把简单对话的延迟压住;强度越高,延迟和输出 token 用量都跟着涨。OpenAI 建议大多数生产环境的语音助手都从 low 起步,遇到更难的任务再往上调。

推理强度越高,延迟和输出 token 越多。默认的 low 档兼顾速度,是大多数场景的起点。
minimal
最快
low(默认)
起步档
medium
high
xhigh
最慢最深
5 档
推理强度可选:minimal / low / medium / high / xhigh,默认 low
同价
mini 版新增推理,定价和上一代 gpt-realtime-mini 保持一致
04怎么选

两款模型怎么选

一句话分工:要最强的实时推理、工具调用、指令遵循和语音助手表现,用完整版 gpt-realtime-2.1;要更快更省、能力够用就行,用 gpt-realtime-2.1-mini。

维度gpt-realtime-2.1(完整版)gpt-realtime-2.1-mini
定位最强实时推理与语音助手行为更快、更省的选项
推理有,强度可调有,mini 推理模型
工具调用
相比上一代的改进字母数字识别、静音与噪声处理、打断行为都更好保持上代 mini 能力,新增推理
音频输出价$64 / 百万 token$20 / 百万 token
该选它当…要最强推理和语音助手表现要速度和成本,能力够用
$20 vs $64
mini 与完整版的音频输出价,约 3 倍差距,能力换成本
字母数字
完整版改进了「8-3-5-7-1」这类编码的识别,适合要精确捕捉数字的场景
05延迟与成本

延迟砍 25%,缓存怎么省钱

这次的延迟改进,来自缓存优化。而缓存不只省时间,还大幅省钱。

先看「p95 延迟」是什么

p95 延迟,是把所有请求的响应时间从快到慢排好队,取排在第 95% 位置的那个值。它代表最慢的那 5% 用户实际等了多久,不是平均耗时。对实时语音来说,用户真正感觉到的卡顿,就藏在这条最慢的尾巴里。把这条尾巴砍掉至少 25%,通话体验会明显跟手。

打个比方

100 个人排队结账,你真正在意的不是平均等待时间,而是排在倒数第 5 位那几个人等了多久。他们不骂街,这个系统才算稳。

缓存命中,为什么价格骤降

缓存命中输入(cached input)指的是:这一轮对话延续了之前处理过的系统提示或历史内容,服务能认出「这段算过了」,直接复用而不用重新计算,价格因此骤降。系统提示在第一轮之后就被缓存了,所以对话越长、复用越多,越省。以 mini 版的音频输入为例,缓存命中价和新鲜价的差距是这样的:

gpt-realtime-2.1-mini 音频输入,每百万 token 的价格对比。
新鲜音频输入
$10.00
缓存命中输入
$0.30
≥25%
全系 Realtime 语音模型 p95 延迟下降幅度,来自缓存优化
$0.30
mini 缓存命中的音频输入价,新鲜音频输入为 $10.00,差约 33 倍
06完整价目

三款模型价格全貌

价格都按每百万 token 计,分文本、音频、图像三类。点标签切换看其中一类,mini 列已高亮。

音频 / 每百万 tokengpt-realtime-2.12.1-mini上代 mini
音频输入$32.00$10.00$10.00
音频缓存输入$0.40$0.30$0.30
音频输出$64.00$20.00$20.00
mini 的音频输出价约为完整版的三分之一($20 对 $64)。
文本 / 每百万 tokengpt-realtime-2.12.1-mini上代 mini
文本输入$4.00$0.60$0.60
文本缓存输入$0.40$0.06$0.06
文本输出$24.00$2.40$2.40
mini 的文本价和上一代 gpt-realtime-mini 逐项一致,新增推理没有涨价。
图像 / 每百万 tokengpt-realtime-2.12.1-mini上代 mini
图像输入$5.00$0.80$0.80
图像缓存输入$0.50$0.08$0.08
三类里,mini 每一项都稳定停在上一代 mini 的价位上。
07落地场景

适合拿来做什么

四类典型场景,各自怎么用到推理、工具调用和识别改进:

客服话费 / 账单排查

用户打电话说有笔账单不对。mini 用低强度推理判断问题,先调 lookup_account 查账户,再调 check_invoice 查发票,每一步都口头说明进度,用户不会以为掉线。

改约看诊时间

用户要把预约改到下周二。模型逐字捕捉准确日期,先跟用户确认,再调 reschedule 函数。确认过的值,才拿去调工具,避免用猜的输入。

应用内语音助手

手机 App 用 WebRTC 把麦克风音频流过来。mini 用一两句短话回答产品问题,成本低,这个功能可以高并发地跑。

现场报工单号

技术员让助手记一个零件号。改进后的字母数字识别,能更准地抓到「8-3-5-7-1」这样的编码,模型会先读回来确认,再执行。

08怎么接入

接入起来什么样

最小实现是这样:服务端先签发一个短命的客户端凭证(标准 API key 留在服务端不外泄),浏览器拿着这个短期凭证,直接用 WebRTC 连过去,建立麦克风轨道和一条数据通道来收发事件。

服务端铸造短期凭证API key 留在服务端
浏览器发起 WebRTC offer
建麦克风轨道 + 数据通道
实时收发音频事件

连接方式按场景挑:浏览器和手机端直接采集播放音频,走 WebRTC;服务端已经拿到原始音频流(呼叫中心、媒体管道),走 WebSocket;电话语音代理走 SIP。

点开看两段最小代码(服务端签发凭证 + 浏览器发起连接)
服务端:铸造短期客户端凭证(API key 留在服务端)
// 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
浏览器:用短期凭证发起 WebRTC 连接
// 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 的哈希),方便平台监测滥用时精确定位到具体用户,而不是误封整个账号。

09取舍

优势在哪,局限在哪

按 OpenAI 公布的口径,这次发布的两面:

优势
  • 推理下放到低价的 mini 档
  • 定价和上一代 gpt-realtime-mini 一致,没涨价
  • 全系 p95 延迟至少降 25%
  • 推理强度五档可调,按任务在延迟和深度间取舍
  • 单模型音频管线,让对话更自然
局限
  • 音频按 token 计费,难换算成单次通话的实际成本
  • 推理强度调高,延迟和输出 token 都会涨
  • 长会话反复重发上下文,不裁剪的话输入成本会累积
  • mini 档的能力仍弱于完整版 gpt-realtime-2.1
模型可以先说一句「我这就查这笔订单」,然后一边处理请求一边继续说话,多步骤的语音任务因此保持连贯。 MarkTechPost,作者 Michal Sutter
来源:MarkTechPost(作者 Michal Sutter),2026 年 7 月 6 日报道,技术细节已对照 OpenAI 官方 Realtime API 指南(developers.openai.com/api/docs/guides/realtime)核对。文中定价、延迟降幅等数据均为 OpenAI 公布口径。