Qwen Image 2.1 rate limits: Pro 20 RPM, Turbo 120 RPM vs Sume's queue
Alibaba caps qwen-image-2.1-pro at 20 requests a minute and Turbo at 120. How long 1,000 images take at each cap, and how Sume's plan queue behaves instead.

Alibaba Cloud Model Studio limits qwen-image-2.1-pro to 20 requests per minute and qwen-image-2.1-turbo to 120 requests per minute, in every region (pages read 2026-10-13). If each request returns one image, 1,000 images take at least 50 minutes on Pro and about 8.3 minutes on Turbo. Sume does not list either model, but its image API handles volume differently: it accepts jobs into a plan-sized queue instead of rejecting them at a per-minute rate.
What do Alibaba's limits mean for a batch?
The pages state the limit in requests, not images. Neither page, as fetched, documents how many images one request can return, so the table assumes one image per request. If a request can return several, divide the times accordingly after you confirm that in Alibaba's API reference.
| Model | Rate limit | 1,000 images | 10,000 images |
|---|---|---|---|
| qwen-image-2.1-pro | 20 requests per minute | 50.0 minutes | 500 minutes |
| qwen-image-2.1-turbo | 120 requests per minute | 8.3 minutes | 83.3 minutes |
How does Sume admit a large image batch?
Sume's generation admission page separates four controls. Concurrency is how many paid jobs run at once, and it is set by plan: Free 1, Pro 4, Startup 8, Scale 20. Queue capacity is how many accepted jobs may wait: 5, 20, 40 and 100. A valid job over the concurrency limit is accepted as queued and runs when a slot frees. When the queue is also full, the submit fails with 429 queue_full.
Request volume has its own control. An abuse-protection limit returns 429 rate_limited, and Sume says to back off, using retry-after when it is present and an idempotency key on the retry.
| Plan | Processing concurrency | Queue capacity | Accepted at once |
|---|---|---|---|
| Free | 1 | 5 | 6 |
| Pro | 4 | 20 | 24 |
| Startup | 8 | 40 | 48 |
| Scale | 20 | 100 | 120 |
What changes in your client?
Against Alibaba you pace requests yourself and handle throttling errors. Against Sume you size the number of in-flight jobs to the accepted capacity, treat queued as normal, and poll. Sume's image route waits up to 30 seconds and then returns 202 with a job envelope, so a client must check the status code, not the body shape.
- Alibaba: the per-minute limit is a rate. Spread 1,000 requests over at least 8.3 minutes on Turbo.
- Sume: the limit is in-flight jobs. On a Pro plan you can hold 24 accepted jobs, then wait for slots.
- Sume does not publish a per-minute image rate in these docs, so measure your own throughput instead of copying Alibaba's number.
Which should you use?
If the job needs Qwen Image 2.1 Pro or Turbo exactly, you are on Alibaba's limits, and Pro at 20 requests a minute is the slow lane. If a Qwen-family row on Sume is enough (qwen/qwen-image, a different model), the queue model lets you submit a wave and walk away, within your plan's accepted capacity. Sume's concurrency is by plan only, and buying credits does not raise it.
Sources
Related posts
More in Developers
- Repeatable AI images: seed returns 400 on Sume, so do this
Sume's schema accepts seed, but no image model lists it, so seed returns 400 unsupported_parameter. Pin the model and prompt, and keep the output file.
- Image model sume/auto or a pinned id: when to send which
Send sume/auto when you want Sume to choose and pin an id when you need the same look and price every time. Auto never names the model that ran.
- sume/auto or a fixed video model id: decision rules for client work
Use sume/auto for 3-10 s clips with no family requirement. Pin an id when you need over 10 s, 1080p-only, a given family or 4:3. Read 2026-10-13.
- Sume allows 256 px output; TikTok's API minimum is 360
Sume Timeline outputs can be as small as 256 px, below the 360 px minimum on TikTok's media transfer guide. Clamp sizes in your own code before upload.
Written by Sume