Toonflow 批量生成时怎么控制模型 API 的并发调用上限，避免触发上游 429 限流？

Toonflow 控制 API 并发调用上限的办法不是突破限制，而是把同时在跑的请求数压到上游允许的额度以内，其余任务排队等待。能调的只有三处：客户端的并发数或任务队列、批量任务的提交方式、以及失败后的重试策略。不适用的情况要说清楚：如果用的是第三方中转密钥或共享账号，天花板由上游按账号、密钥或出口 IP 决定，客户端再优化也只能保证不撞墙，不能把额度变大。 并发控制前要先分清三层额度：客户端同时提交的任务数、上游账号级的并发与速率额度、以及具体模型端点自己的额度，能跑通的并发是这三者里的最小值。只在客户端调数字，而不知道上游是按并发还是按每分钟请求数计费，往往会越调越乱。做法是先向上游确认账号的口径，再回头设客户端的值。 把批量任务从一次性全部提交改成排队分批提交，是投入最小、收益最明显的一步。多数工具在批量生成时会并发发起请求，任务一多就集中撞在上游的短时额度上。操作上就是把素材按批切分，一批跑完再放下一批，宁可整体慢一点，也不要同时挂满。这种削峰对漫画分镜、批量出图这类同构任务尤其有效。 并发上限一般落在设置里的并发或任务队列项，也可能藏在配置文件、启动参数或环境变量里，字段名随版本变化，具体以官方说明为准。比字段名更重要的是先搞清这个值是同时在跑的任务数，还是每分钟请求数，这两个口径经常被混在一起，设错了等于没设。如果只能填一个数字，先用它限住在跑任务数，速率再靠节流补。 只设最大并发数挡不住速率型限流。上游通常同时按并发和每分钟请求数或每分钟 token 量两套口径算账，并发没超但短时间发太多照样会被拒。做法是并发数之外再加一层发送节流，比如固定间隔发送、令牌桶或漏桶，让请求在时间轴上摊平。批量导入提示词、循环重跑失败任务时最容易踩这个坑。 遇到 429 时的正确动作是退避等待后重试，而不是立刻重发。立即重试会让请求数翻倍，限流窗口被持续填满，任务越重试越跑不动。实操上按指数退避加随机抖动，并设最大重试次数，超过次数就转人工或标记失败。同时要区分错误类型：鉴权、参数这类错误重试再多次也不会成功，只会白白消耗额度。 单任务耗时长的生成场景，并发数不能只按请求数来估。分镜、出图、视频这类任务一次请求占用连接的时间远大于普通文本调用，连接池和超时设置跟不上时，低并发也会出现排队假死。做法是给长任务单独设更小的并发和更长的超时，必要时把长任务和短任务分成两个队列。不要把轮询状态检查和正式生成混在同一个并发池里。 多把密钥能不能分摊并发，取决于上游是按密钥、账号还是出口 IP 记账。按密钥隔离额度时轮换确实有效，按账号或 IP 聚合时轮换不但无效，还可能因为来源异常触发风控。判断方法很简单：加一把新密钥后看总吞吐有没有上升，没有上升就说明限制在更上层。用大量小号密钥去绕额度并不可取，出问题时排查成本更高。 同一账号在多台机器或多个容器里跑 Toonflow 时，限流点应该放在统一出口，而不是每个实例各自设一个并发数。每个实例都以为自己只用了一点点额度，加起来就会把上游打满。做法是在本地加一层反向代理或网关做集中排队和令牌发放，实例只负责提交，不负责判断能不能发。这样配额口径才是全局唯一的。 并发上限不该拍脑袋定，而应该压测出来。从明显偏低的并发开始，逐级往上加，同时记录限流失败占比、P95 延迟和单位时间成功完成的任务数。当吞吐不再上升而错误率开始上升，就说明越过了拐点，回落到前一档作为日常值，再留一点余量给突发。这个拐点比任何经验值都可靠，因为上游额度本身会变。 并发不是越高越快，超过上游额度后有效吞吐反而会下降。排队、重试、失败重跑都会消耗时间和额度，还会让真正紧急的任务排在后面。所以并发控制的目标是稳定吞吐，而不是瞬时峰值，宁可把批量任务排在空闲时段跑。留出余量给交互式请求，别让自动任务把额度占满。 个人用户的最低可行配置是低并发加队列加退避重试三件套；团队则应把限流下沉到统一网关，并集中记录限流次数和重试成功率。如果上游是按账号硬限且不提供提额，客户端任何技巧都只能削峰，不能扩容，该做的是拆分账号或错峰调度。把这三件事做好，Toonflow 的批量任务就能跑得慢一点但跑得完。