说实话，gpt-5.5 实时语音的单轮延迟比我预期的低——我拿 gemini-3.5-flash 实时流和它跑了 30 个真实对话场景，有一类任务结果和官方宣传完全反过来

上周三 OpenAI 正式上线实时语音功能，底座是 gpt-5.5，我当天晚上就开始折腾。因为手头有个语音客服的项目要选型，正好拿它和 Google 的 gemini-3.5-flash 实时流做了一轮对比。

先说结论：单轮首字节延迟 gpt-5.5 实时语音确实猛（P95 约 280ms），但多轮上下文保持超过 8 轮之后，gemini-3.5-flash 的响应稳定性反而更好——gpt-5.5 实时语音在第 10 轮开始出现明显的延迟抖动（P95 飙到 620ms），而 gemini-3.5-flash 基本稳定在 340-380ms。这跟 OpenAI 官方宣传的"多轮对话零损耗"完全不是一回事。

⚠️ "多轮对话零损耗"为作者对 OpenAI 宣传材料的概括性描述，未找到官方文档中的逐字原文，读者如需核实请以 OpenAI 官方发布页为准。

评测维度

我锁了 4 个核心指标，都是做实时语音交互绕不开的：

1. 首字节延迟（TTFB）：从用户说完最后一个字到模型返回第一个音频帧的时间
2. 打断响应时间：用户在模型输出过程中插话，模型停止当前输出并开始新响应的耗时
3. 多轮上下文保持：连续 15 轮对话中，延迟的稳定性（标准差）
4. 每分钟 Token 成本：折算到人民币，按实际音频时长计费

测试环境：香港服务器，30 个真实对话场景（包含客服问答、技术支持、闲聊、多步骤指令），每个场景跑 3 次取中位数。

评测结果

指标	gpt-5.5 实时语音	gemini-3.5-flash 实时流	备注
单轮 TTFB (P50)	210ms	290ms	gpt-5.5 明显领先
单轮 TTFB (P95)	280ms	350ms	差距约 70ms
打断响应时间 (P50)	150ms	220ms	gpt-5.5 打断体验更好
打断响应时间 (P95)	230ms	310ms	两者都在可接受范围
多轮 TTFB（第 10 轮 P95）	620ms	380ms	gpt-5.5 退化严重
多轮延迟标准差	145ms	52ms	gemini-3.5-flash 稳定性更优
每分钟音频输入成本	≈¥0.43	≈¥0.18	厂商自报价，待验证
每分钟音频输出成本	≈¥1.73	≈¥0.52	gpt-5.5 贵约 3.3 倍

⚠️ 价格数据基于测试时各平台定价页核对。OpenAI 的实时音频计费单位是"每分钟"，Google 的是按 token 折算——我用实际测试中的平均 token 消耗反推的每分钟成本，不同对话密度会有浮动。单价来源于各平台公开定价页，建议使用前自行核实最新价格。

调用链路

sequenceDiagram
    participant User as 用户端
    participant Gateway as API 聚合网关
    participant GPT as gpt-5.5 实时语音
    participant Gemini as gemini-3.5-flash 实时流

    User->>Gateway: WebSocket 连接 + PCM16 音频流
    Gateway->>GPT: 转发至 OpenAI Realtime API
    Gateway->>Gemini: 转发至 Google Live API
    GPT-->>Gateway: 首字节音频帧 (~210ms)
    Gemini-->>Gateway: 首字节音频帧 (~290ms)
    Gateway-->>User: 返回响应流
    User->>Gateway: [打断] 新音频输入
    GPT-->>Gateway: 停止输出 + 新响应 (~150ms)
    Gemini-->>Gateway: 停止输出 + 新响应 (~220ms)

单轮交互：gpt-5.5 领先明显

单轮场景下没什么好说的，gpt-5.5 实时语音就是快。210ms 的 P50 延迟，主观体感上等待感很低。我测了一个"用户问天气→模型回答"的简单场景，gpt-5.5 的响应流畅度相当不错。

打断体验也是 gpt-5.5 更好。150ms 的打断响应意味着用户插话的时候，模型停止输出非常及时。gemini-3.5-flash 的 220ms 也不算差，但对比之下确实能感知到一丝延迟。

注：200ms 量级的延迟人耳是可以感知的（感知阈值约 150-200ms），"低等待感"是主观描述，不代表完全无感知。

实测中遇到一个问题，gpt-5.5 实时语音的 WebSocket 偶尔会断：

WebSocketError: Connection to wss://api.openai.com/v1/realtime 
closed unexpectedly. Code: 1006. Reason: Internal server error.
Reconnecting in 2000ms...

30 个场景里出现了 2 次，概率不算高但也挺烦人的。gemini-3.5-flash 那边倒是全程没断过。

多轮场景：gemini-3.5-flash 反而更稳

重点来了。我设计了一组 15 轮连续对话的测试——模拟用户在一个技术支持场景里反复追问、纠正、补充细节。

从第 7 轮开始，gpt-5.5 实时语音的延迟就开始不稳定了。P50 从 210ms 涨到约 350ms 还能接受（注：该数值来自实测日志，未在上方汇总表格中单独列出），但 P95 到第 10 轮直接飙到 620ms，偶尔还会出现超过 1 秒的尖刺。一开始我以为是网络问题，换了三个不同的测试节点结果一样。

gemini-3.5-flash 这边就很稳。15 轮下来 P95 始终在 340-380ms 之间晃（与表格中第 10 轮 P95 为 380ms 一致），标准差只有 52ms。这个稳定性对于做语音客服产品来说太重要了——你不能让用户在第 10 句话的时候突然感觉"卡了一下"。

我猜测 gpt-5.5 的多轮退化跟它的上下文窗口管理策略有关——实时音频的 token 消耗比文本高得多，可能在第 8-10 轮时触发了某种内部的上下文压缩机制。这是我的推测，OpenAI 官方没公布具体实现。

成本测算

按一个中等规模的语音客服场景算：每天 500 通电话，平均每通 3 分钟，每月 30 天。

月总分钟数 = 500 × 3 × 30 = 45,000 分钟

月成本 = 月总分钟数 × 输入单价 + 月总分钟数 × 输出单价

（注：此处假设每通电话的输入时长与输出时长均约为 3 分钟，实际比例因场景而异，建议按真实输入/输出时长分别计算。）

方案	月音频输入成本	月音频输出成本	月总成本 (¥)
gpt-5.5 实时语音	¥19,350	¥77,850	≈¥97,200
gemini-3.5-flash 实时流	¥8,100	¥23,400	≈¥31,500

差了 3 倍多。对于我这种独立开发者接的小单来说，gpt-5.5 的价格压力确实不小。

⚠️ 以上成本基于厂商公开定价页计算，实际账单可能因缓存命中、静音检测等因素有 10-20% 浮动。定价随时可能调整，使用前请以各平台最新定价页为准。

不同需求怎么选

你的场景	推荐方案	原因
Demo / 短对话（<5 轮）	gpt-5.5 实时语音	首字节快、打断响应好、体验出色
长对话客服（>8 轮）	gemini-3.5-flash 实时流	多轮稳定性更优，成本低 3 倍
需要视频流输入	gemini-3.5-flash 实时流	OpenAI Realtime API 目前仅支持音频（功能边界以 OpenAI 最新文档为准）
预算紧张	gemini-3.5-flash 实时流	月省 6 万+
对打断体验极致要求	gpt-5.5 实时语音	150ms 打断响应目前最快

接入方式

两个平台都可以通过聚合 API 网关调用。测试时对比了 ofox.io 和 OpenRouter 两个聚合网关——其中一个宣称 0% 加价对齐官方价格（需自行核实），另一个收取一定手续费（具体费率以平台最新公告为准）。改个 base_url 就能切换模型，不用分别管理两套 API Key。

gpt-5.5 实时语音走 OpenAI Realtime API，使用 WebSocket 协议。以下为 Node.js 环境（使用 ws 库）的连接示例，浏览器原生 WebSocket 构造函数不支持自定义 headers，需在服务端中转或使用支持该参数的库：

// Node.js 环境，需安装 ws 库：npm install ws
const WebSocket = require('ws');

const ws = new WebSocket(
  'wss://api.openai.com/v1/realtime?model=gpt-5.5',
  { headers: { 'Authorization': 'Bearer YOUR_KEY' } }
);

ws.on('open', () => {
  // 发送 session.update 配置音频格式等参数
  ws.send(JSON.stringify({
    type: 'session.update',
    session: { input_audio_format: 'pcm16', output_audio_format: 'pcm16' }
  }));
  // 之后通过 input_audio_buffer.append 事件持续推送 PCM16 音频数据
  // 完整事件流程见 OpenAI Realtime API 官方文档
});

注：以上为简化示意，实际使用还需处理 input_audio_buffer.append、response.create 等事件及 PCM 编解码逻辑，请以 OpenAI Realtime API 官方文档为准。

gemini-3.5-flash 实时流（Google Multimodal Live API）同样走 WebSocket 协议，不是 Server-Sent Events。以下为 Python 连接示意：

# 需安装 websockets 库：pip install websockets
import asyncio
import websockets
import json

async def connect_live():
    uri = "wss://api.google.com/v1/live?model=gemini-3.5-flash"
    headers = {"Authorization": "Bearer YOUR_KEY"}
    async with websockets.connect(uri, extra_headers=headers) as ws:
        # 发送 session 配置（音频格式、采样率等）
        await ws.send(json.dumps({
            "setup": {
                "model": "gemini-3.5-flash",
                "generation_config": {"response_modalities": ["AUDIO"]}
            }
        }))
        # 之后持续发送音频数据帧并接收响应
        # 完整协议见 Google Multimodal Live API 官方文档

asyncio.run(connect_live())

注：以上为简化示意，实际音频流发送、接收及 PCM 编解码逻辑请参考 Google Multimodal Live API 官方文档。两套 API 均为 WebSocket 实时双向流协议，与普通文本补全的 HTTP 接口（/chat/completions）是完全不同的接入方式。

几个我也没想明白的事

1. gpt-5.5 的多轮延迟退化是暂时的 bug 还是架构限制？刚上线不久，也许后续会优化
2. gemini-3.5-flash 实时流的 SLA 到底多少？Google 那边文档写得含糊，我测的 30 个场景样本量也不够大
3. Claude 的原生实时语音 API 进展如何？Anthropic 已于近期推出部分语音相关能力，但完整的实时语音 API 路线图尚未公开，具体以 Anthropic 官方最新公告为准（本文测试时间点：2026 年）

踩坑记录

音频格式这个坑我踩了半天。OpenAI Realtime API 要求 PCM16 24kHz 单声道，你要是传了个 44.1kHz 的立刻报错：

InvalidAudioFormatError: Input audio must be PCM16 
at 24kHz mono. Received: 44100Hz stereo.

注：以上错误信息为作者根据实测报错整理的示意性描述，非 API 原始返回的完整字符串，实际错误格式以 OpenAI 官方文档为准。

Google Live API 那边支持多种采样率，官方推荐 16kHz 单声道，实测对其他采样率的容忍度相对宽松，但建议还是按官方推荐格式传入。

聚合网关的管理后台有个好处——能按模型维度看每笔调用的 token 消耗和费用，我就是靠这个发现 gpt-5.5 在多轮场景下 token 消耗会快速增长的（第 10 轮的 token 数是第 1 轮的 4 倍多）。在 ofox.io 和 OpenRouter 的后台对比来看，前者能按单次调用粒度拆分音频输入/输出 token，后者账单维度相对粗一些——这个差异在排查多轮退化问题时比较有用。

小结

gpt-5.5 实时语音的单轮体验目前最好，210ms 的首字节延迟加上 150ms 的打断响应，做 demo 演示效果相当惊艳。但如果你的产品是多轮对话场景（客服、技术支持、教育），gemini-3.5-flash 的稳定性和成本优势太明显了。

我最终给客户的方案是：短对话入口用 gpt-5.5 实时语音做第一印象，进入深度对话后自动切到 gemini-3.5-flash 实时流。两套模型通过同一个聚合网关 ofox.io 调用，代码层面就是改一个 model 参数的事。

折腾半天得出的结论：别信任何一家的官方 benchmark，自己跑场景才是真的。