语音 AI 限流:并发、队列与 429 错误
- 发布时间
大多数团队在处理语音 AI 限流时,习惯像对待其他 API 一样:限制每分钟请求数,遇到服务器拒绝就重试,然后继续。但在 ElevenLabs 上,这种方式在流量高峰时就会失效,因为实际受限的是并发数,而不是请求总数。
本指南将解释为什么并发才是真正的限制因素,并介绍如何通过客户端模式控制并发。从有限并发池、优雅处理 429,到多租户公平、令牌桶和漏桶机制,提供可落地的系统方案。每种模式都配有可直接使用的 TypeScript 实现。
如果你在构建语音智能体、旁白流程或其他基于我们模型的生产系统,并希望扩展规模,这份指南适合你。
要点速览
- 语音 AI 限流本质是并发控制,而不是每分钟请求数。
- 达到限流上限时,请求不会立刻被拒绝,而是进入优先级队列,通常会增加约 50 毫秒延迟。
- 队列后仍超出容量时,会返回 HTTP 429 错误。
- WebSocket 能大幅提升有效容量,因为只有正在生成的请求才计入并发限制。
- 多租户系统需额外的公平机制:每租户独立桶、加权公平队列、预留冗余和按 key 分片隔离。
- 响应头 current-concurrent-requests 和 maximum-concurrent-requests 可实时查看当前限流状态。
为什么限制的是并发,而不是每分钟请求数
并发是指同一时刻正在处理的请求数。每分钟请求数是一定时间内的吞吐量。理解两者区别很重要,因为决定你是否超限的杠杆不同。
使用ElevenLabs模型时,服务器负载随并发用户数变化。音频生成会占用一个并发槽,持续时间取决于输入长度、模型和当前负载。
每分钟请求数的限制无法反映当前有多少并发槽被占用,而服务器只关心这一点。
不同套餐、不同模型系列的并发限制
并发额度不是单一数字。不同套餐和模型系列的并发限制各不相同。例如,语音转文本的并发上限高于文本转语音,因为转录请求通常持续时间更短,系统能同时处理更多。
限制按模型系列区分。如果你为智能体用 Flash,为旁白用 Multilingual v2,就是两个独立的并发额度。各套餐的具体并发数和说明见模型页面。
达到并发限制会发生什么?
达到并发限制时,请求不会立刻被拒绝。系统会通过优先级队列平滑处理,只有在总容量仍超限时才会完全拒绝。
在未超限时,请求会立即处理。达到上限后,后续请求进入按套餐优先级排序的队列。队列通常只增加约 50 毫秒延迟,短时间超限对用户几乎无感。
队列后仍超出容量时,会收到 HTTP 429。此时应减缓请求,而不是立即重试。表格中的优先级决定队列中请求的排序,高级套餐可更快清空队列。
HTTP 与 WebSocket:如何计入并发限制
选择的传输方式会直接影响限流和并发额度。相同的对话流量,HTTP 和 WebSocket 占用的并发额度可能差异很大。
HTTP 下,每个请求在整个处理期间都计入并发限制。WebSocket 下,只有模型实际生成音频的时间才计入。空闲的 WebSocket 基本不占用并发。
对于语音智能体,对话中有大量时间无人说话、模型未生成内容。HTTP 每轮都要占用一个并发槽,WebSocket 只在实际生成的毫秒级时间内占用,因此一个并发槽可被多路对话共享。
详见实时 TTS WebSocket 指南,了解协议细节。对于交互流量,WebSocket 是推荐默认选项。
为什么约 5 个并发可支持约 100 路广播
并发背后的数学原理乍看反直觉,关键在于播放时间。生成速度远快于播放,只有生成时才实际占用并发槽。这正是小额度能服务大规模用户的原因。
一次生成只需几百毫秒,却能产出几秒音频,听众播放时并发槽已释放,可供其他请求使用。
一般来说,5 个并发限制可支持约 100 路同时音频广播。具体数量取决于音色、语速和语句间的停顿。
用于判断当前状态的响应头
无需猜测是否超限。每个响应都带有两个数字,可直接衡量剩余空间,无需估算。
关注以下两个响应头:
- current-concurrent-requests: 当前正在处理的请求数
- maximum-concurrent-requests: 该模型系列的并发上限
这两个响应头共同提供实时的当前用量和剩余容量概览。无需等到遇到限流才发现问题。
客户端侧的 AI 限流策略
几乎所有 AI 限流场景都可用以下四种机制覆盖:
- 令牌桶: 有令牌时允许请求通过,令牌随时间补充,可应对短时突发而不超限。
- 漏桶: 将突发流量平滑为固定速率输出,防止下游系统被瞬时流量压垮。
- 有限并发池: 限制同时活跃请求总数,确保不会超出并发上限。
- 带全抖动的指数退避: 失败请求间隔递增,并在整个区间内随机分布,防止所有客户端同时重试造成流量高峰。
下方将逐步演示如何实现这些机制,从最贴合并发限制的开始。
以下代码片段均假设单一客户端,初始化一次:
有限并发:最贴合限制的机制
服务器按并发计量,最直接的客户端控制方式是有限工作池,限制同时在途请求数。建议设置略低于套餐上限,为优先队列和抖动留出空间。
令牌桶:允许突发,限制平均速率
令牌桶可容纳一定数量令牌,并以 refillRate 每秒补充。每个请求消耗一个令牌,允许短时突发但限制长期速率。
适用于突然有一批任务到来时,避免全部同时发起导致并发激增。
漏桶:强制平稳输出
有时完全不希望出现突发。漏桶以固定速率接收任务,无论输入多么突发。适合下游系统更偏好平稳负载的场景。
例如,与其他服务共享小并发额度时,需刻意保持低负载。
带全抖动的指数退避
请求失败且可重试时,立即重试只会加剧问题。退避机制拉开重试间隔,全抖动则在整个区间内随机延迟,防止大量客户端同步重试,重现流量高峰。
下方代码片段用到 RetryableError 类,包含失败状态和 Retry-After 值,定义见下方优雅处理 429 部分。
优雅处理 429:超限时该怎么做
429 表示即使经过优先队列后仍超出容量,正确做法是减缓请求而不是加大重试。可通过四种方式应对,核心策略如下:
- 检测
- 遵循 Retry-After
- 暴露背压信号
- 用断路器避免重试风暴
下面详细拆解每一点。
首先是检测。将 HTTP 429(以及临时性 500、502、503、504)视为可重试,将 400、401、403、422 视为不可重试;格式错误或未授权的请求重试无效,只会浪费并发槽。
其次是遵循 Retry-After。如果响应带有该头,严格按其指定时间等待,不要自行计算延迟。服务器最清楚何时有容量,优先用它的建议。仅在无该头时再用抖动退避。
第三是暴露背压信号。不要让重试悄悄堆积。如果队列深度或剩余空间显示短期内无法处理新请求,应直接拒绝并明确告知调用方,而不是盲目接收任务。
第四是用断路器避免重试风暴。若失败次数超阈值,打开断路器,冷却窗口内直接失败而不再发送请求。冷却后可发送少量探测请求,若成功则关闭断路器。
AI 限流下的多租户配额模式
前述内容均假设单一应用对应单一额度。若你在 ElevenLabs 上构建 SaaS,问题会变:并发额度需在所有客户间共享,某租户批量任务不应影响其他租户实时流量。此时需在租户与上游限额间加一层公平机制。
基础做法是每租户独立令牌桶。每个租户分配对应额度,只有租户桶和全局限流器都允许时才接收请求。
令牌桶能防止单一租户滥用,但无法决定多租户争抢全局额度时谁优先。此时需用加权公平队列。
不要用先到先服务,否则某租户突发流量会独占并发。应为每租户维护独立队列,按权重分配处理机会,付费租户可获得更高份额。
在公平基础上,还要预留冗余。正常流量不要占满 100% 并发,建议预留 15-20% 作为交互请求和优先队列的缓冲。
当单一额度内的公平分配不够时,可按工作区或 key 分片。无论多公平,单一并发额度最终都会成为瓶颈。
此时应将不同任务分配到独立工作区或 API key,各自拥有独立额度。例如,实时智能体流量用一个 key,后台旁白用另一个,避免旁白积压影响智能体容量。
工作区还可用于设置作用域限制、额度配额和按 key 控制,详见认证文档。
监控并发使用情况
没有数据就无法调优。每次响应都应记录 current-concurrent-requests 和 maximum-concurrent-requests,并按模型系列打标签,输出利用率指标。
建议关注四个信号:
- 利用率(当前/最大)。
- 429 占总请求的比例。
- 重试深度,即每个逻辑请求的尝试次数。
- 首段音频延迟(TTFA),以应用侧测量为准,非模型推理时间。详见延迟说明。
健康系统应保持利用率低于饱和,429 仅偶发。监控这些信号可提前发现限流压力,避免故障。
何时超越客户端限流扩展规模
客户端模式能解决大部分问题,但持续增长的需求最终会超出其能力。此时需做出调整,兼顾成本与效率。
以下每一步都能提升容量:
首先将 HTTP 交互流量切换为 WebSocket。如果智能体或实时场景还在用 HTTP,切换后只有实际生成时才计入并发。对话类场景通常能大幅提升容量,因为空闲时间不再占用并发槽。
若流量峰值高但平均负载在额度内,可用令牌桶或漏桶配合有限池,将峰值平滑为平均值。
然后选择更快的模型。生成越快,每个并发槽占用时间越短,固定额度可支撑更多广播。Eleven Flash v2.5 是最低延迟选项,适合实时场景;配合即时语音克隆或默认音色,可避免专业语音克隆的额外开销。
只有在以上措施都做完后,才建议升级套餐。当客户端已优化但需求仍超出额度时,高级套餐可提升并发上限和队列优先级。各档位对比见 API 价格页。
如需更高额度,企业版套餐可提供更高并发和最高队列优先级。部分场景还可用额外控制,如 IP 白名单(企业预览)和零保留模式。可联系客户经理提升额度。
AI 限流要点回顾
核心误区是把语音 AI 限流当作请求计数。实际应关注并发控制。决定成败的,是同一时刻有多少请求在生成音频,以及每个请求占用并发槽的时长。
客户端设计应围绕这一点展开。
用有限池限制在途请求,令牌桶或漏桶控制流入,重试用带抖动的指数退避,遵循 Retry-After,重试风暴前用断路器切断。
多租户系统需叠加每租户桶、加权公平、预留冗余和分片隔离。关注 current-concurrent-requests 和 maximum-concurrent-requests 响应头,按利用率趋势预警,而非只看失败数。
如确需更高容量,按顺序优化:先用 WebSocket 和更优客户端,再选合适模型,最后升级套餐或申请企业额度。
用 ElevenAPI 构建语音应用
生产级 AI 限流需选对传输方式、模型,并用响应头实时掌握状态。
ElevenAPI 提供低延迟模型(如 Eleven Flash v2.5)、实时 WebSocket 流式传输、语音转文本和文本转语音 API,以及每次响应的并发头,助你构建可扩展的语音智能体。
结合本文的 AI 限流策略,即使高负载下也能保证语音体验响应及时、性能可预期。
了解ElevenAPI,查看全部模型,或创建账户,立即用 ElevenLabs 开始构建。

.webp&w=3840&q=80)

