Toonflow 怎么控制 API 并发调用上限，批量生成时如何避免触发服务商限流？

Toonflow 控制 API 并发调用上限的核心做法，是把「同时在途请求数」与「单位时间请求速率」拆成两个独立参数：前者用并发闸门限制，后者用令牌桶限制，并按服务商或模型分别建通道；它不适用于单次手动触发的交互式调用，那种场景主要受单请求超时约束，而不是并发数。 批量生成任务是最容易撞上服务商限流的场景。Toonflow 在批量分镜、批量出图和批量配音时，会在几十秒内连续发出大量请求，而多数模型服务按每分钟请求数和每分钟 token 数两个维度限流，长提示词往往先把 token 维度打满，表现为请求还没到并发上限就先收到 429。 并发上限应分三层设置：服务商级、工作流级、节点级，且以服务商级的最低额度为准。节点级配置只能在全局额度内进一步收紧，不能反向突破；工作流级的数值用于给一类任务预留配额，避免某个批量节点把额度全部占满，导致同一工作流里的其他步骤排队等待。 并发闸门的本质是信号量，限制的是同一时刻处于在途状态的请求数量。实现上每次调用先申请一个许可，请求结束或超时后释放；许可耗尽时新请求进入等待而不是直接发出。并发数设成服务商额度的七到八成比较稳妥，留出的余量用于吸收重试和人工触发请求。 速率控制用令牌桶比用固定间隔更贴合生成式接口的调用特征。令牌桶按每秒固定速率补充令牌，允许一定容量的短突发，桶容量设小一些可以让输出更平滑；漏桶则强制恒定输出速率，适合对下游稳定性要求极高的场景，但会拉长批量任务的总耗时。 队列的作用是把瞬时并发转成可控的等待序列。为每个通道设置最大排队长度和单条排队超时，队列满时直接拒绝并标记该批次，而不是无限堆积；排队超时则应把任务转为失败可重试状态，避免一个卡住的请求长期占用后续任务的等待名额。 多密钥、多通道轮询能在合规前提下扩容可用并发，但单个密钥的额度仍是硬上限。做法是给每个通道设置权重和健康状态，连续失败或返回 429 的通道进入冷却期，流量按权重转移到健康通道；同一账号主体下的密钥是否可并行使用，要以服务商条款为准。 重试策略必须设预算，否则一次限流会演变成重试风暴。只有 429 和 5xx 值得重试，参数错误类的 4xx 重试只会放大问题；退避采用指数增长并加入随机抖动，同时给每个任务设最大重试次数，重试请求同样占用并发许可，不能在闸门之外另行发出。 超时设置对吞吐的影响常被低估：慢请求会长时间占住并发槽位，把闸门卡死。为每个请求设置连接超时和读取超时，流式输出单独设置首字节超时和空闲超时；连续失败比例超过阈值时触发熔断，暂停该通道一段时间后再半开探测，避免持续向已限流的服务商施压。 不同模型和任务的并发上限应分开配置，因为成本结构和限流维度不同。长上下文文本模型按 token 限流更敏感，图片生成按每分钟张数限流更常见，配音接口则受音频时长约束；交互式请求走独立的高优先级通道，批量任务放在低优先级队列，防止后台批处理拖慢前台操作。 判断并发上限是否合理，看四个指标就够了：429 响应比例、平均排队时长、请求 P95 延迟和并发槽位利用率。429 比例持续偏高说明速率或并发设得过大，槽位利用率长期偏低说明额度浪费；调参顺序应先降速率再降并发，因为多数限流首先由 token 速率触发。 三个常见错误是只调并发不调速率、把全局并发当成所有通道共享、以及重试不受闸门约束。全局并发数只能作为总闸，通道级额度仍需单独设置；异步长任务接口不适用简单的在途请求计数，应按任务提交频率而不是连接数来限流，具体字段和入口以 Toonflow 官方说明为准。