概述
Realtime 是一類走 WebSocket 長連線的語音模型:音訊流進、音訊流出,中途可以被打斷,不需要「錄完再上傳、等一段再播放」。它和「ASR + 文本模型 + TTS」三段式拼接的最大區別是端到端——模型直接聽到語氣、停頓和情緒,也直接說出來,延遲能壓到亞秒級。 目前 API易 接入了 4 個模型、2 套協議,共用同一條端點和同一把令牌:gpt-realtime-2.1/gpt-realtime-2.1-mini—— OpenAI Realtime GA 協議qwen3.5-omni-plus-realtime/qwen3.5-omni-flash-realtime—— 阿里雲百鍊協議
server_vad 與 semantic_vad 兩種自動斷句、Function Calling 全鏈路(含結果回注)、圖片輸入、usage 按模態分列。四個模型的上述能力均已逐項實測通過(2026-08-24 (UTC+8))。model 引數、不改請求體欄位,一定連不通——這是接入本能力最高頻的失敗原因。差異只有 6 個欄位 + 3 個事件名,全部列在下方「兩套協議對照」一節。申請內測開通
API 使用手冊
令牌與分組管理
呼叫日誌查詢
讓 AI Agent 幫你接入
.md),再按你專案的技術棧寫程式碼——兩套協議的欄位族、取樣率紅線、打斷收口、空閒斷線這幾個高頻問題已經寫死在要求裡。讓程式設計 Agent 接入或排查 Realtime 即時語音。複製後直接貼上給 Codex、Claude Code、Cursor 等。
這段提示詞替你擋掉了什麼
這段提示詞替你擋掉了什麼
為什麼選 API易 的 Realtime 語音
一把令牌,四個模型
wss 端點、同一套鑑權,換模型只改 model 引數與對應欄位模板,不用維護兩家賬號體系。國內直連,免出海
api.apiyi.com,無需註冊上游廠商賬號、無需實名與預充值。兩套協議差異已替你測完
文本通道可零成本自測
實測延遲與併發有據可查
內測期直連技術支援
核心特性
雙向流式 · 可打斷
response.cancel 打斷當前回覆,會話不中斷、上下文不丟。四個模型均實測通過。兩種自動斷句
server_vad 按靜音時長斷句,semantic_vad 按語義意圖斷句(更能忽略「嗯」「對」這類附和聲)。兩種在四個模型上均實測通過。Function Calling 全鏈路
function_call_output 回注結果 → 模型接著說。四個模型的完整鏈路均實測通過。圖片輸入 · 分模態計量
usage 把文本 / 音訊 / 圖片 token 分列返回,成本可歸因。四個模型均實測通過。支援的模型
模型定價
gpt-realtime-2.1 為例,音訊輸入 $32 對文本輸入 $4,音訊輸出 $64 對文本輸出 $24)。所以聯調階段應該跑純文本,等鏈路確認無誤再接音訊——具體做法見下方「先用文本跑通」一節。Realtime GA 協議
阿里雲百鍊協議
計費維度與上表不同:圖片輸入併入文本檔,輸出側只區分「純文本」與「文本+音訊」(後者只對音訊部分計費)。分組介紹
技術規格
實測延遲與併發
2026-08-24 (UTC+8) 經api.apiyi.com 公網路徑實測,20 路併發 × 2 模型,單輪純文本問答:
端點一覽
model 查詢引數決定路由到哪個模型。
⚠️ 兩套協議對照(遷移必讀)
兩個家族的端點、鑑權、整體事件流程完全一致,差異集中在session.update 的欄位結構和幾個服務端事件名上。
請求體欄位對照
服務端事件名對照
session.created / session.updated / conversation.item.create / input_audio_buffer.append / input_audio_buffer.commit / response.create / response.cancel / response.done 等其餘事件名兩套一致。
兩段最小 session.update
同一件事各寫一遍,可以直接抄。阿里雲百鍊協議:先用文本跑通:文本通道的意義與三級自測階梯
音訊鏈路要調麥克風採集、重取樣、分片、斷句,任何一環出錯都表現為「沒反應」,很難定位。所以不要一上來就接麥克風。文本是控制面,不是備選輸入
在即時語音模型裡,文本不是「音訊之外的另一種輸入方式」,而是除音訊流以外的全部控制通道:三級自測階梯
第一級:純文本,不碰麥克風
output_modalities 只留文本、關掉自動斷句,發一條 input_text 就能驗證:握手通不通、令牌與分組對不對、欄位模板選對了沒有、session.update 有沒有生效、工具能不能回注、多輪上下文在不在、併發扛不扛得住。完全不產生音訊 token。第二級:回放本地 wav 檔案
input_audio_buffer.append。這一步把音訊鏈路(格式、取樣率、分片、commit、VAD 觸發)與業務邏輯解耦,可重複、可迴歸——同一個檔案跑兩次結果應該一致。第三級:接即時麥克風
一段能跑的文本冒煙指令碼
只依賴websockets(pip install websockets)。改 FAMILY 一個變數就能在兩套協議之間切換:
會話能力:音色 · 斷句 · 工具 · 圖片
音色
斷句:server_vad 與 semantic_vad
server_vad—— 按靜音時長斷句,引數直觀(threshold、silence_duration_ms、prefix_padding_ms)。semantic_vad—— 按語義意圖斷句,能忽略「嗯」「對」這類附和聲和無意義背景音,多人環境更穩。- 也可以把斷句關掉(傳
null或none)走手動模式:自己發input_audio_buffer.commit再發response.create,適合「按住說話」這類由 UI 控制輪次的互動。
工具呼叫
事件順序:模型輸出function_call 型別的 response.output_item.done(其中帶 call_id 和 arguments)→ 客戶端執行 → 回注結果 → 再次 response.create 讓模型接著說。
圖片輸入
Realtime GA 協議:直接在訊息裡放input_image,值可以是 data URI。
Error append image before append audio.。實測做法是把 input_image_buffer.append 按約每秒一幀交織進 input_audio_buffer.append 序列裡。
已知限制與規避(內測期)
以下四條均為實測結論,且都會打到客戶端程式碼,接入前請先看一遍。最佳實踐
先按協議家族選欄位模板
session.update 寫成兩個配置常量,按模型名選擇,不要用 if 到處打補丁。這是最容易在半年後維護出錯的地方。首幀一次性定死會話引數
output_modalities、voice、speed、turn_detection、transcription 在第一條 session.update 裡全部設好。音色尤其如此——出過音訊再改就晚了。純文本冒煙通過再接音訊
取樣率與聲道在客戶端轉好
用 output_item.done 加超時收口
response.done。這樣寫在兩個家族上都正確,也避免打斷時把一輪掛住。長會話做保活與重連
expires_at。重連之後必須重放 session.update 與必要的上下文,否則新會話是預設配置。生產走後端中繼
錯誤碼與重試
event_id 與會話的 session.id,反饋問題時附上,能大幅縮短定位時間。另外 Realtime GA 協議的錯誤物件帶 code 與 param 欄位(會明確指出是哪個欄位、支援哪些取值),百鍊協議的錯誤資訊相對粗一些,除錯期優先在前者上驗證欄位寫法。常見問題
為什麼這一頁沒有線上 Playground?
為什麼這一頁沒有線上 Playground?
四個模型能只改 model 名互相替換嗎?
四個模型能只改 model 名互相替換嗎?
modalities ↔ output_modalities、voice ↔ audio.output.voice、input_audio_format ↔ audio.input.format、turn_detection ↔ audio.input.turn_detection、input_audio_transcription ↔ audio.input.transcription,以及 response.text.delta ↔ response.output_text.delta、response.audio.delta ↔ response.output_audio.delta 兩個事件名。完整對照見下方「兩套協議對照」一節。握手就失敗 / 連不上,怎麼排查?
握手就失敗 / 連不上,怎麼排查?
https://,應該是 wss://;② 端點有沒有帶 ?model=<模型名>;③ Authorization: Bearer <令牌> 請求頭有沒有帶上;④ 令牌是否已開通內測分組(沒開通會返回 503 提示無可用渠道);⑤ 中間有沒有反向代理吃掉了 Upgrade 頭——自建閘道轉發時這一點很常見。瀏覽器能直連嗎?令牌會不會洩露?
瀏覽器能直連嗎?令牌會不會洩露?
Sec-WebSocket-Protocol 子協議形式的鑑權,瀏覽器 WebSocket 建構函式可以直接連上。但這等於把令牌發給瀏覽器,任何訪問者都能從網路面板讀到,只建議用於本機驗證。生產環境請寫一個後端中繼:後端持有令牌並建立到 API易 的連線,前端只與你自己的服務通訊。給 gpt-realtime-2.1 傳 16 kHz 音訊報錯?
給 gpt-realtime-2.1 傳 16 kHz 音訊報錯?
integer_below_min_value。正確寫法是 "audio": {"input": {"format": {"type": "audio/pcm", "rate": 24000}}}。阿里雲百鍊協議那兩個模型則要求 16 kHz,兩套不能混用。沒有麥克風 / 音訊不好測,怎麼辦?
沒有麥克風 / 音訊不好測,怎麼辦?
say + afconvert 一行生成,命令見該節。發了 response.cancel 之後一直等不到 response.done?
發了 response.cancel 之後一直等不到 response.done?
response.text.done、response.content_part.done、response.output_item.done,但不再下發 response.done。請改用 response.output_item.done 作為一輪結束的判據,並加超時兜底。 會話本身不受影響,打斷後可以繼續正常對話。Realtime GA 協議那兩個模型此處表現正常。連線大約 5 分鐘就斷了?
連線大約 5 分鐘就斷了?
session.update)保活,或者接受斷線並實現自動重連。重連後記得重放 session.update 與必要的上下文。一個會話最長能開多久?
一個會話最長能開多久?
session.created 事件裡帶 expires_at 欄位,實測約為建連後 30 分鐘,到期需要重連。阿里雲百鍊協議側我們主要觀測到的是空閒 300 秒斷開這一約束。長通話請按「會話會到期」來設計,做好跨會話的上下文續接。音色怎麼設?為什麼中途改音色報 cannot_update_voice?
音色怎麼設?為什麼中途改音色報 cannot_update_voice?
session.update 裡設:百鍊協議是頂層 voice,Realtime GA 協議是 audio.output.voice。一旦會話中已經產生過音訊輸出,就不能再改音色,這是兩套協議共有的限制,會報 cannot_update_voice。請在首幀就定死,要換音色請新開會話。另外百鍊協議不要傳空字串音色,會觸發 400。手動 commit 模式下拿不到輸入轉寫文本?
手動 commit 模式下拿不到輸入轉寫文本?
flash 型號在手動 commit 模式下不會下發轉寫的完成事件(多次測試穩定復現),plus 型號正常,兩者在 VAD 模式下都正常。推薦改用 server_vad 或 semantic_vad 模式。實測發現轉寫文本此時落在增量事件的一個未公開欄位裡,但該欄位隨時可能變化,不建議依賴。注意這隻影響「在介面上回顯使用者說了什麼」,不影響對話本身——模型對音訊內容的理解與回答是正確的。支援圖片輸入嗎?為什麼報 Error append image before append audio.?
支援圖片輸入嗎?為什麼報 Error append image before append audio.?
input_image;阿里雲百鍊協議把圖片當作影片幀處理,必須先追加音訊再追加圖片,否則就會報這個錯。實測做法是按約每秒一幀,把圖片交織進音訊分片序列裡。有 Prompt 快取嗎?怎麼確認命中?
有 Prompt 快取嗎?怎麼確認命中?
usage 的 input_token_details.cached_tokens 會有值。阿里雲百鍊協議那兩個模型目前未觀察到快取命中。成本怎麼估?文本和音訊是分開算的嗎?
成本怎麼估?文本和音訊是分開算的嗎?
response.done 事件的 usage 欄位按模態分列返回(文本 / 音訊 / 圖片,輸入輸出各一組),可以據此歸因。音訊檔位顯著高於文本,所以聯調期建議跑純文本。準確扣費請以控制台呼叫日誌為準。