Suno API 的并发与队列设计
「并发」不是一个数字，而是提交、轮询、下载三组不同的负载。把它们拆开，才知道该扩哪一段。
并发、速率、配额是三件事
| 限制 | 现象 | 处理 |
|---|---|---|
| 并发 | 同时在跑的生成任务太多，吞吐不再上升 | 按队列深度扩容，不按请求数扩容 |
| 速率 | 短时间大量请求返回 429 | 令牌桶/漏桶 + 指数退避 |
| 配额 | 402 或余额不足 | 批量开始前查余额（免费接口） |
一个够用的队列模型
- 提交 worker：限制同时提交数，成功即落库任务 ID。
- 轮询 worker：按 3–5 秒节奏查状态，终态才交给下一步。
- 下载 worker：取临时地址并转存，失败可重试。
- 去重键：用自己的 request_id + 任务 ID，防止重复提交和重复下载。
什么时候该加并发
看三个信号：队列等待时间持续上升、429 比例仍低、下游下载不拥堵。三者同时成立才加；如果 429 已经上升，加并发只会让失败更多。先降并发、加退避，再谈扩容。
接着看：轮询与超时 · Node.js 示例 · Python 示例。
常见问题 / FAQ
能无限并发吗？
实际吞吐受账号配额、上游渲染和限流共同约束；从少量并发开始，按 429 比例和队列深度逐步加。
429 后立刻重试行吗？
不建议。用 1s → 2s → 4s 的指数退避，并降低并发；立刻重试容易被继续限流。
读取接口也会限流吗？
会。状态查询和下载地址通常不计费，但仍受正常速率限制。
申请 Key、第一个请求、接口清单与报错排查
注册只需要邮箱，一次生成 0.6 元出 2 首，MP3 与 WAV 下载不限次。
看完整接口与限制
注册只需要邮箱，一次生成 0.6 元出 2 首，MP3 与 WAV 下载不限次。