Eleven Realtime v1 Max 在速度与语音推理方面领跑榜单——且没有指数得分

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 得分、对话动态得分、竞技场 Elo 和任务成功率——而在本应显示 Speech to Speech Index 的位置却是一个破折号。Max 没有指数得分。不是低分，而是完全没有。

原因是机制性的，它解释了接下来大部分内容。该指数是四个组成部分的等权平均值：语音推理（Big Bench Audio）、在 τ-Voice 客服基准上的智能体表现、竞技场偏好以及任务成功率。模型需要四项齐全才能获得评分。Max 有三项。E​levenLabs 专门将 Max 作为面向“复杂任务”和“多步工具使用”的产品出售——而工具使用基准正是迄今尚无人对其运行过的那个。

ElevenLabs 实际发布了什么

Eleven Realtime 系列与 ElevenLabs 为人熟知的文本转语音模型属于不同类型的产品。每个 Realtime 模型都是一个单一网络，将识别、轮次转换、推理步骤和语音生成一并处理，而不是由编排器把语音转文本、语言模型和文本转语音声音拼接成的一条流水线。ElevenLabs 的卖点在于，将这四个阶段作为一个系统进行调优可以消除接缝——呼叫者停止说话后的半秒静默、打断时仍抢话的智能体，以及转录听到的内容与语音回应的内容之间的不匹配。

两种模型都可以通过两种方式访问：在 ElevenAgents 内部，你从下拉菜单中选择一个模型，平台会配置其余部分；或者通过 Realtime API 访问，该 API 刻意与 O​penAI 的 API 在传输层面保持兼容，地址为 wss://api.elevenlabs.io/v1/convai/realtime。只需更改端点和模型名称，现有的 O​penAI Realtime 客户端即可保留其事件处理器。

10月20日发布的只是公告，而非正式启用。ElevenLabs 自己的文档仍将这些模型描述为“逐步推出”，并明确指出，如果某个工作区没有 Voice 模式设置，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%，相比之下 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 则把模型放进一个复刻的客服场景——航班改签、争议扣费、电信问题——并配上领域工具和一份政策文档，然后评分数据库最终是否处于正确状态。它体现的是“智能体调用了正确的函数”与“智能体在不违反政策的前提下解决了请求”之间的区别。

ElevenLabs 推销 Max，正是为了这第二项任务。产品页面上的说法是，Max“能对复杂问题进行推理，并调用工具完成任务，而不会拖慢对话的节奏”。迄今为止，没有任何已发布的内容对这一说法做过端到端验证。87.1% 的任务成功率是个很亮眼的数字；但它也是评估中相对容易的那一半，而且它旁边还有一项 94.1% 的对话动态得分，比 Mini 低了 1.5 个百分点。

对于今天就要做决定的团队来说，诚实的总结是：Max 是该领域中测量数据最充分的语音推理模型——98.8% 在同一榜单上仅落后于 StepAudio 3 Realtime 的 100% 和 Qwen Audio 3.0 Realtime Plus 的 99.2%——而且它的智能体行为尚未被测量，竞争对手的则已被测量。Gemini 3.8 Live Extended Thinking 的 τ-Voice 得分为 68.6%。GPT-Live-1（Astra，medium）为 74.5%。Max 的分数则是一个破折号。

它一分钟要花多少钱

ElevenLabs 不公布每个模型的具体价格。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 美元。E​leven Realtime 的定价处于中游，而非最低端，约为标准 G​emini Live 费率的 5.7 倍。

这正是路由层体现价值的地方，尽管它无法触及语音模型本身。Eleven Realtime 只能通过 E​levenLabs 自有 API 使用，别无他处——没有任何第三方托管商提供 eleven_realtime_v1_max，OrcaRouter 也不提供，因此语音层没有什么可路由的。你可以路由的是智能体调用的一切：查询服务、CRM 写入、通话结束后运行的摘要器，以及实时模型出错时级联回退到的备用模型。在 OrcaRouter 上，这些是 来自 16 家上游提供商的 209 个模型，统一由一个密钥接入，按提供商列表价计费，无加价，因此账单中随调用方思考强度而扩展的那一半，才是你真正可以优化的一半。

决定你这周成败的集成细节

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 不是可选方案

• 合规性 — 零保留模式和 HIPAA 在美国和欧盟支持 Max，完全不支持 Mini

• Token 限制 — Max 要求限制至少为 1,024 个 token，或不设限制，并且工作流节点无法覆盖该限制

• 自定义后端 — 当智能体使用自定义 LLM 或 Amazon Bedrock 时，实时模式不可用；你必须先切换到内置 LLM

• Agent 转接 — Realtime-mode 的 Agent 只能与其他 Realtime-mode 的 Agent 相互转接，不过允许 Mini-to-Max 转接

这些规则中的每一条都是在发布时强制执行，而不是在保存时。违反其中一条的草稿仍然可以保存；发布则会失败，并指出相应的设置。

看什么

两项结果就能为这次发布定论。第一项是 Max 的 τ-Voice 分数——这个数字才能真正检验 E​levenLabs 实际在推销的那个主张。第二项是 WebRTC 支持，它决定了一个模型是只能用来演示，还是能用于移动通话。在此之前，站得住脚的立场既狭窄又有用：Mini 是不需要完成任务的对话式智能体的良好默认选择，Max 是榜单上最快的强推理模型，并且很可能是更好的支持智能体，而尚未有人发布能够证明后半句的测试。