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.

4 min readSume
All posts

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.

Limits from the Alibaba Cloud Model Studio pages, read 2026-10-13. Minutes are images divided by the per-minute limit, assuming one image per request and no retries.
ModelRate limit1,000 images10,000 images
qwen-image-2.1-pro20 requests per minute50.0 minutes500 minutes
qwen-image-2.1-turbo120 requests per minute8.3 minutes83.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 figures from Sume's generation admission page, read 2026-10-13. Accepted job capacity is concurrency plus queue capacity.
PlanProcessing concurrencyQueue capacityAccepted at once
Free156
Pro42024
Startup84048
Scale20100120

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

All Developers posts

Written by Sume