语音 AI 限流:并发、队列与 429 错误
- 发布时间
- 最近更新
大多数团队处理语音 AI 限流时,沿用其他 API 的方式:限制每分钟请求数、服务器拒绝时重试,然后继续。但对于 ElevenLabs 工作负载,这套方法在第一次流量突发时就会失效,因为真正触及的限制是并发数,而非请求数。
本指南说明并发数为何才是真正的约束,并介绍让请求保持在限制内的客户端模式。我们提供可实际实施的方案,包括有界并发池、妥善处理 429、多租户公平性、令牌桶和漏桶。每种模式都配有可调整的 TypeScript 实现。
如果你要构建语音智能体、旁白流水线,或任何基于我们模型且需要扩展的生产系统,这份实践指南适合你。
摘要
- 语音 AI 限流是并发控制,不是按每分钟请求数计数。
- 达到限流上限不会立即拒绝流量。请求会进入优先级队列,通常增加约 50ms 延迟。
- 排队后仍超出容量时,会产生 HTTP 429 错误。
- WebSocket 可显著提高有效容量,因为只有活跃生成会计入限制。
- 多租户系统需要额外的公平层:每租户存储桶、加权公平排队、预留余量,以及跨密钥分片实现隔离。
- 两个响应标头 current-concurrent-requests 和 maximum-concurrent-requests 可显示当前 AI 限流状态。
为什么限制是并发数,而不是每分钟请求数
并发数是同一时刻正在处理的请求数量。每分钟请求数是在一个时间窗口内的吞吐量。理解这一差异很重要,因为它决定了该通过什么手段来保持在限制内。
使用ElevenLabs 模型时,服务器工作负载会随并发用户数增长。音频生成会在整个生成期间占用一个槽位,而该时长受输入长度、模型和负载影响。
每分钟请求数上限无法说明当前占用了多少槽位,而这才是服务器唯一计量的指标。
按套餐和模型系列划分的限制
并发预算不是单一数字。并发限制因套餐和模型系列而异。例如,语音转文本 的限制高于文本转语音,因为转写请求通常持续时间更短,系统可同时处理更多请求。
限制按模型系列计算。如果用 Flash 运行智能体,用 Multilingual v2 生成旁白,便是在同时使用两份独立预算。各套餐当前数值及并发部分记录在模型页面。
达到并发限制时会发生什么?
达到并发限制不会立即拒绝流量。系统会通过优先级队列平缓降级,只有仍超出限流总容量时才会完全拒绝。
低于限制时,请求会立即运行。达到限制后,后续请求将按套餐优先级进入队列。队列通常只增加约 50ms 延迟,因此短暂超限对用户大多无感。
若排队后系统仍超出容量,会收到 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 限流的客户端策略
以下 4 个基本工具几乎涵盖所有 AI 限流场景:
- 令牌桶:有可用令牌时允许请求继续。容量会随时间补充,因此可处理短暂突发而不触及限制。
- 漏桶:尝试将输入流量平滑为固定输出速率,防止突发流量压垮下游系统。
- 有界并发池:限制可同时活跃的请求总数,确保不会超过并发请求限制。
- 带完全抖动的指数退避:逐步延长失败请求之间的间隔,避免所有客户端同时重试。
以下各节将逐一演示如何构建这些机制,先从与并发限制最直接对应的机制开始。
以下代码片段均假设只初始化一次单个客户端:
有界并发:与限制匹配的基本机制
由于服务器按并发数计量,最直接的客户端控制方式是有界工作池,用于限制同时在途的请求数。将上限设置得略低于套餐限制,为优先级队列和抖动留出空间。
令牌桶:允许突发,限制平均速率
令牌桶最多持有 capacity 个令牌,并以每秒 refillRate 个令牌的速度补充。每个请求消耗一个令牌,因此它允许不超过桶容量的短暂突发,同时限制长期速率。
当一队工作突然到达时,它能平滑处理,避免一次性全部发出而导致并发激增。
漏桶:保持稳定排出速率
有些情况下完全不希望容忍突发。无论输入多么突发,漏桶都以固定、恒定速率接纳工作。当下游系统更偏好平稳可预测的负载而非偶发峰值时,它是更好的选择。
例如,当你有意将流量控制在与其他服务共享的小型并发预算之内。
带完全抖动的指数退避
请求以可重试状态失败时,立即重试只会让情况更糟。退避可拉开重试间隔,完全抖动会在整个区间内随机分配每次延迟,防止大量客户端同步重试并重现导致失败的峰值。
以下代码引用 RetryableError,这是一个携带失败状态和任意 Retry-After 值的小型类。其定义见下方的妥善处理 429 部分。
妥善处理 429:达到上限时怎么办
429 表示经过优先级队列后仍超出容量,因此正确做法是降低速率,而不是更激进地重试。有 4 种处理方式,关键在于以下 4 项策略:
- 检测
- 遵循 Retry-After
- 暴露背压
- 通过熔断器避免重试风暴
下面逐一详细说明。
首先是检测。将 HTTP 429(以及临时性 500、502、503 和 504)视为可重试;将 400、401、403 和 422 视为不可重试。重试格式错误或未经授权的请求永远不会成功,只会浪费一个槽位。
其次是遵循 Retry-After。如果响应带有该标头,应完全按其执行,而不是自行计算延迟。服务器会告知预计何时有容量,它比指数公式更清楚。仅在标头缺失时才回退到带抖动的退避。
第三个方面是暴露背压。不要让重试在后台无声堆积。如果队列深度或测得的可用余量表明无法很快服务新请求,应在边缘以明确信号拒绝调用方,而非接收无法完成的工作。
第四个方面是使用熔断器避免重试风暴。失败次数超过阈值时,应打开熔断器,并在冷却窗口内快速失败,而非发送预计会失败的请求。窗口结束后发送少量探测请求;成功后关闭熔断器。
AI 限流的多租户配额模式
前文均假设单个应用使用单一预算。当你基于 ElevenLabs 构建 SaaS 时,问题会发生变化:并发预算由所有客户共享,一个租户运行批处理作业不应挤占其他租户的实时流量。需要在租户与单一上游限制之间加入公平层。
基础是每租户令牌桶。为每个租户提供符合其权益的独立桶,只有租户桶和全局限流器都允许时才接纳请求。
存储桶能约束单个租户,但无法决定租户竞争全局限流器时谁优先。为此,应使用加权公平排队。
不要按先到先服务,否则某个租户的突发流量会独占槽位。维护每租户队列,并按租户权重分派,让付费租户获得比免费租户更大的竞争容量份额。
除公平性外,还应预留余量。不要让常规流量消耗并发限制的 100%。预留一部分,例如 15–20%,作为对延迟敏感的交互请求和优先级队列的缓冲。
当单一预算内的公平性已不足够时,可跨工作区或密钥分片。无论分配多公平,单一并发预算最终都会成为瓶颈。
此时应将工作负载分配到具有独立预算的不同工作区或 API 密钥:例如,一个密钥用于实时智能体流量,另一个用于后台旁白,从而避免旁白积压影响智能体容量。
工作区还支持应用范围限制、积分配额和每密钥控制,详见身份验证文档。
监控并发利用率
没有测量就无法调优;无法管理未测量的余量。记录每个响应中的 current-concurrent-requests 和 maximum-concurrent-requests,按模型系列标记,并将利用率作为仪表指标输出。
需跟踪的 4 个信号:
- 利用率(当前值 / 最大值)。
- 429 占总请求的比例。
- 重试深度,即每个逻辑请求的尝试次数。
- 首个音频时间,从应用层而非模型推理数据测量。有关 TTFA 包含的内容,请参阅延迟说明。
健康系统会将利用率保持在远低于饱和的水平,并仅在偶发突发时出现 429。监控这些信号可让你在问题演变为服务中断前很早发现限流压力。
何时扩展到客户端限流之外
客户端模式能承担大量工作,但稳定需求最终会超出其能力。届时应进行同时降低成本和工作量的调整。
以下每一步都能带来额外容量。
先为交互式流量将 HTTP 切换为 WebSocket。如果智能体或实时用例运行在 HTTP 上,迁移至 WebSocket 会改变计量方式,使只有活跃生成计入。对于对话式工作负载,这通常无需更改套餐就能成倍提升有效容量,因为空闲对话时间不再占用槽位。
如果突发流量尖峰明显,但平均负载符合预算,令牌桶或漏桶结合有界池可将峰值平滑至平均值。
然后选择合适模型。更快的生成让每个槽位占用时间更短,提高固定并发限制可支持的播报数量。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 构建。
AI 限流常见问题
Tadas Petra 是一名开发者关系工程师,致力于帮助开发者使用 ElevenLabs 产品。他还是开发者教育平台 Hungrimind 的创始人。此前曾任 Agora 首席开发者布道师和 Zero To Mastery 讲师。




