{{1}}Eleven Realtime v1 Max{{/1}} 在速度與語音推理方面稱霸排行榜——而且沒有 Index 分數

Eleven Realtime v1 Max 能在 0.57 秒內回答，並在 Big Bench Audio 上得分 98.8%；Eleven Realtime v1 Mini 則在 0.62 秒內回答，且在同一項測試中得分 76%。這兩個數字合起來看，是 E​levenLabs 2026 年 10 月 20 日公告中最有用的資訊——不是因為其中任何一個單獨來看有多出色，而是因為兩者之間有 23 個百分點的差距，而且較弱的那一款竟是預設取得的版本。此類模型背後有紀錄的 AI 事件與代理故障案例，收錄於 OrcaRouter AI Incident Archive，其中每筆條目都附有自己的來源、嚴重程度、信心等級與爭議標記。

同一個排行榜上還有第二個更古怪的事實。Artificial Analysis 為兩個模型都列出了首次音訊時間、Big Bench Audio 分數、對話動態分數、arena Elo 和任務成功率——卻在 Speech to Speech Index 應該出現的位置顯示一個破折號。Max 沒有指數分數。不是低分。而是完全沒有。

原因是機械性的，而這也解釋了接下來的大部分內容。該指數是四個成分的等權平均：語音推理（Big Bench Audio）、在 τ-Voice 客服基準上的代理式表現、競技場偏好，以及任務成功率。模型必須四項俱全才能被評分。Max 只有三項。E​levenLabs 專門以「複雜任務」和「多步驟工具使用」來推銷 Max——而工具使用基準正是尚未有人在它身上跑過的那一項。

ElevenLabs 實際上推出了什麼

Eleven Realtime 系列與 E​levenLabs 為人熟知的文字轉語音模型屬於不同類型的產品。每個 Realtime 模型都是單一網路，一併處理辨識、輪流發言、推理步驟與語音生成，而不是由協調器把語音轉文字、語言模型和文字轉語音聲音拼接而成的管線。E​levenLabs 的賣點是，把這四個階段當作單一系統來調校，能消除接縫——來電者停止說話後那半秒的空白、代理人在被打斷時仍搶著說話，以及轉錄聽到的內容與語音回覆所說內容之間的不一致。

這兩款模型都有兩種連線方式：在 ElevenAgents 內，您可從下拉式選單挑選模型，其餘由平台設定；或是透過刻意與 OpenAI 的 Realtime API 保持連線層級相容的 Realtime API，網址為wss://api.elevenlabs.io/v1/convai/realtime。只要變更端點和模型名稱，現有的 OpenAI Realtime 用戶端就能保留其事件處理常式。

10 月 20 日發布的是公告，而不是正式啟用。E​levenLabs 自家的文件仍將這些模型描述為「逐步推出中」，並表示若工作區沒有 Voice mode 設定，API 會拒絕 realtime_model，並直接顯示「Realtime models are not available for this workspace.」。模型識別碼也比這波新聞報導更早：8 月 3 日 ElevenAgents 的更新日誌條目記載，即時代理設定早已開始預設為 eleven_realtime_v1_mini。請把發布日期視為這些數字公開的那一天，而不是端點開放的那一天。

這兩個模型並不是同一事物的兩種尺寸

ElevenLabs 將 Mini 與 Max 定位為成本與品質之間的調節旋鈕：Mini 適用於助理、家教與角色；Max 適用於客服支援、潛在客戶資格篩選，以及會使用工具的工作流程。官方公布的量測數據顯示，這個旋鈕可調節的幅度比那套說法所暗示的更大。以下數據來自 Artificial Analysis，是在同一套測試框架上獨立執行所得，而非引用 ElevenLabs 頁面上的數字：

• 語音推理（Big Bench Audio）— Eleven Realtime v1 Max 98.8% vs Eleven Realtime v1 Mini 76%

• 任務成功率 — Max 87.1% 對比 Mini 60.3%

• 對話動態（Full-Duplex-Bench）— Max 94.1% 對 Mini 95.8%

• 競技場偏好（Elo）— Max 997 對 Mini 988

• 首次音訊時間 — Max 最長 0.57 秒，Mini 為 0.62 秒

• 語音轉語音指數 — Max 未評分 vs Mini 未評分

先讀最後三列，再看最前兩列。就來電者能明確感受到的部分——這聽起來像不像一場對話——Mini 是更好的模型，而速度較快的 Max 僅快了 50 毫秒。23 分的推理差距和 27 分的任務成功差距真實且巨大，但它們反映在代理是否能把工作完成，而不是在與它交談是否感覺良好。這正是客服佇列所做的取捨，也正因如此預設值才重要：每個從未動過設定的新代理，都會跑在只能解決 60.3% 任務、而非 87.1% 任務的模型上。

這個差距也解釋了索引欄中的短橫線。Mini 也缺少代理能力分數，這對一個定位為平價款的模型來說並不意外。Max 雖然被定位為能力較強的模型，卻也缺少這個分數。

缺少的那一列實際上代表什麼

任務成功率與 τ-Voice 並不是同一種衡量方式，而將兩者混為一談，是這個版本最容易犯的錯誤。任務成功率問的是對話是否以正確的最終工具呼叫作結。τ-Voice 則把模型放進一個仿真的客服情境——航班變更、帳款爭議、電信問題——並提供領域工具與政策文件，評分資料庫最後是否處於正確狀態。這正是「代理呼叫了正確的函式」與「代理在不違反政策的情況下解決了請求」之間的差別。

E​levenLabs 正是為了第二項任務而力推 Max。產品頁面上的說法是，Max「能推理複雜問題並呼叫工具完成工作，而不會拖慢對話速度」。到目前為止，還沒有任何已發布的內容對這項說法進行端到端測試。87.1% 的任務成功率是很強勁的數字；它也是評估中較容易的那一半，而且緊鄰著 94.1% 的對話動態分數，該分數比 Mini 低 1.5 個百分點。

對今天就要做決定的團隊而言，誠實的總結是：Max 是這個領域中量測最完善的語音推理模型——其 98.8% 在同一排行榜上僅落後於 StepAudio 3 Realtime 的 100% 與 Q​wen Audio 3.0 Realtime Plus 的 99.2%——而且它的代理行為尚未被量測，競爭對手的代理行為則已量測。G​emini 3.8 Live Extended Thinking 的 τ-Voice 分數為 68.6%。G​PT-Live-1 (Astra, medium) 為 74.5%。Max 則顯示為破折號。

它一分鐘要花多少錢

E​levenLabs 並未公布各模型的具體數字。Realtime 計費是標準 ElevenAgents 每分鐘費率，加上依 Realtime 模型自身費率計算的輸入、快取輸入與輸出 token，且 Max 每 token 比 Mini 更貴；儀表板會顯示每分鐘的預估成本，而 Realtime API 則按連線音訊的分鐘數加上 token 計費。定價頁面上完全沒有 Realtime 的計費項目。

Artificial Analysis 將這一切標準化為一個可比較的數字——執行固定 40 題 Big Bench Audio 子集的成本，並以每小時輸入音訊來表示。兩款 E​levenLabs 模型都落在 4.80 美元。這個完全相同的數字才是有趣之處：無論 Max 每個 token 的溢價是多少，在對話用量下，按分鐘計的代理費用都會主導帳單，因此昂貴模型和便宜模型的對話成本相同。Mini 帶來的節省出現在 token 用量大的地方，而不是音訊長的地方。

作為規模參照，以相同衡量標準來看：G​emini 3.8 Live 為每小時 0.84 美元，G​emini 3.8 Live Extended Thinking 為 3.50 美元，G​PT-Live-1 (Sol, low) 為 4.47 美元，G​rok Voice 3.0 為 4.80 美元。Eleven Realtime 的定價位於同類產品的中段，而非最低端，且約為標準 G​emini Live 費率的 5.7 倍。

這就是路由層即使無法觸及語音模型本身，也仍然值得存在的關鍵。Eleven Realtime 只透過 ElevenLabs 自家的 API 提供，別無其他管道——沒有任何第三方主機提供eleven_realtime_v1_max，OrcaRouter 也沒有，因此語音層沒有可路由的對象。你能路由的是代理程式所呼叫的一切：查詢服務、CRM 寫入、通話結束後執行的摘要器，以及即時模型出錯時串接機制所退回的備用模型。在 OrcaRouter 上，這些是209 個來自 16 家上游供應商的模型，透過同一組金鑰即可存取，按供應商牌價計價且不加價，因此帳單中會隨來電者思考負荷而變動的那一半，正是你實際能最佳化的那一半。

決定你這一週的整合細節

ElevenLabs 下了一個大多數即時廠商都沒下的賭注：它的 API 採用的是 OpenAI 的 Realtime 事件協定。文件裡那七行範例會匯入OpenAIRealtimeWebSocket、RealtimeAgent與RealtimeSession，這些全都來自@openai/agents-realtime，並將傳輸層指向 ElevenLabs 的 WebSocket URL，再傳入model: "eleven_realtime_v1_mini"。其餘一切——用戶端密鑰、工作階段設定、音訊輸出模態、語音——全都維持不變。

這種便利的代價就是傳輸層。推出時並沒有 WebRTC；文件裡直接這麼寫，而且任何 WebRTC 整合都必須先改用 WebSocket。對已經採用 WebSocket Realtime 整合的團隊來說，這根本算不上什麼事。但對當初因為 WebRTC 更能處理抖動與行動網路而選擇在其上建構的團隊來說，這是傳輸層的重寫，而不是換個模型。

另一個限制是架構上的：Realtime 模型在 ElevenAgents 與 Realtime API 中是以各自獨立的產品形式運作。如果你需要電話號碼、WhatsApp、知識庫、護欄、腳本化測試或對話監控，你就是在 ElevenAgents 上，而你的代理工具與提示詞也會隨之一起。如果你在 Realtime API 上，你得到的是模型與事件，而不是圍繞它們的平台。你無法在同一條連線上同時擁有兩者。

在它不前往的地方

這次推行的不均衡，對歐洲和印度團隊而言，比對美國團隊更為要緊：

• 資料駐留——兩款模型皆於美國與歐盟提供；印度與新加坡僅提供 Mini，因此對於被固定在那些環境的代理程式而言，Max 並非選項

• 合規性 — 在美國與歐盟，Max 支援零保留模式與 HIPAA；而完全不支援 Mini

• Token 上限 — Max 要求上限至少為 1,024 個 Token，或無上限，且工作流程節點無法覆寫此限制

• 自訂後端 — 當代理程式使用自訂 LLM 或 Amazon Bedrock 時，即時模式無法使用；您必須先改用內建 LLM

• Agent 轉接 — Realtime 模式的 Agent 只能與其他 Realtime 模式的 Agent 互相轉接，不過允許 Mini-to-Max 轉接

這些規則每一條都是在發佈時強制執行，而不是在儲存時。違反其中一條的草稿仍可儲存；發佈會失敗，並指出是哪一項設定。

看什麼

兩個結果就能為這次發布下定論。第一個是 Max 的 τ-Voice 分數——這是唯一能檢驗 ElevenLabs 實際上在推銷之主張的數字。第二個是 WebRTC 支援，這決定了模型是只能拿來示範，還是能實際放進行動電話通話中。在那之前，站得住腳的立場既狹窄又實用：Mini 是不需要完成任務的對話式代理的良好預設；Max 是排行榜上最快的強大推理模型，並且很可能是更好的客服代理；而還沒有人發表能證明後半段的測試。