实时语音：先了解接入条件
Realtime 使用 WebSocket 持续交换事件；当前没有整链实测，不能把转发基础当成已可用服务。
实时语音适合“边说边听”的交互。它与上传一段录音后等待识别、发送文字后合成语音不同：客户端需要保持连接，连续发送音频片段，并接收识别文字、回答音频和会话状态事件。
为什么不能用普通 fetch GET？#
参考接口会标记 GET /v1/realtime，是因为 WebSocket 先通过 HTTP 握手升级连接。客户端需要使用 WebSocket 协议，成功升级通常对应 HTTP 101；普通 fetch() GET 只发 HTTP 请求，不会自动成为可双向交换语音事件的 WebSocket 会话。
wss://univto.com/v1/realtime?model=REPLACE_WITH_ENABLED_REALTIME_MODEL| 连接部分 | 含义 | 不能误解成什么 |
|---|---|---|
| wss:// | 加密 WebSocket 连接 | 不是普通 https 请求的一次性 JSON 返回 |
| /v1/realtime | 实时会话路由 | 不同于 /v1/responses 或 /v1/chat/completions |
| model 查询参数 | 选择已经开放的实时模型 | 不能因为聊天模型可用就拿来代替 |
| HTTP 101 | 本次握手完成协议升级 | 不等于随后音频事件和扣费验收全部通过 |
鉴权应放在哪里？#
服务端 WebSocket 客户端通常在握手请求头携带 Authorization: Bearer 加归壹 API 密钥。具体版本是否还要求其他请求头，需要由平台根据实际上游确认。本页不预设某个测试版头一定必填，也不把 API Key 写进连接网址。
Authorization: Bearer YOUR_GUIYI_API_KEY连上后，交换的是事件#
会话中的消息通常是带 type 字段的 JSON 事件，音频片段常按约定编码后放入事件。以下名称用于理解常见 OpenAI Realtime 事件流程；实际可用事件、字段层级与音频格式必须匹配渠道采用的协议版本。
| 方向 | 常见事件或内容 | 作用 |
|---|---|---|
| 服务端 → 客户端 | session.created / session.updated | 确认会话创建或设置更新 |
| 客户端 → 服务端 | session.update | 设置本次会话支持的指令、音频与轮次参数 |
| 客户端 → 服务端 | input_audio_buffer.append | 分片提交符合约定编码的音频 |
| 客户端 → 服务端 | input_audio_buffer.commit | 在手动控制轮次时提交这一段输入；自动 VAD 模式不应机械照搬 |
| 客户端 → 服务端 | response.create | 在需要手动触发时，请求模型开始回答 |
| 服务端 → 客户端 | 文字／音频增量事件、response.done | 接收分段结果并判断一轮回答结束；增量事件名随版本核对 |
| 服务端 → 客户端 | error | 处理协议、权限、音频格式或限额等错误 |
{
"type": "input_audio_buffer.append",
"audio": "BASE64_ENCODED_AUDIO_CHUNK"
}上面的 Base64 占位文字不是可播放的音频。采样率、声道、编码以及音频分片大小需要与会话约定一致；把 MP3 文件随便转成 Base64，并不能保证模型把它当作正确的输入音频。启用自动语音活动检测（VAD）后，何时提交输入、生成回答和打断上一轮，也要按实际协议处理。
开放前需要怎样验收？#
- 1
确认有可用线路
先确认实时模型 ID、分组、上游权限、协议版本、支持的音频格式和计费规则。仅有价格配置不算线路开放。
- 2
验证握手与事件
检查鉴权失败是否明确、成功是否升级连接、是否收到会话事件，以及参数错误如何返回。
- 3
完成一轮真实对话
验证音频输入、识别、回答音频播放与结束事件，而不只是看到“连接成功”。
- 4
验证连续使用与恢复
检查多轮、插话打断、长时间静默、网络中断、超时与重连。不要假设旧会话可恢复，也不要无限自动重连。
- 5
核对用量和扣费
对照测试时间和会话记录检查音频、文字等实际计量。音频 token 不应直接按普通文字字符数估算。