Wan 3.0 Concurrency: Scaling Batch Video Generation
Key TakeawaysBatch throughput is decided by how many jobs run at once, not how fast one clip renders.During the public preview, the standard allocation is two concurrent jobs per account.Siray runs Wan 3.0 above that baseline — but a sequential client loop throws the headroom away.
Model selection happens on output quality. Production planning happens on wall-clock time. A batch of 500 clips does not care how good frame 12 looks; it cares how many are rendering right now. The Wan 3.0 overview covers what the model does; this covers how long a queue of them takes.
Throughput Is Concurrency, Not Speed
Let T be the render time of one clip and N the batch size. With C jobs running concurrently, the batch finishes in roughly ⌈N / C⌉ × T.
Concurrency C | Wall-clock for N clips | What changes if T halves |
1 | N × T | Batch time halves |
2 | N/2 × T | Batch time halves |
4 | N/4 × T | Batch time halves |
8 | N/8 × T | Batch time halves |
The right-hand column is the point. Halving T — faster model, lower resolution, shorter duration — halves the batch at any concurrency. Doubling C halves it too, and C is the term you control at integration time, not at model-selection time. For large N it is the only term that matters.Per-clip benchmarks therefore mislead on queue work.
The Standard Allocation Is Two Concurrent Jobs
During the Wan 3.0 public preview, the standard allocation is two concurrent jobs per account. Substituting C = 2: a batch of 500 clips serializes into 250 sequential rounds, whatever T is.
For a one-off render that is irrelevant. For a pipeline regenerating a catalogue, or an app generating on behalf of users, 250 rounds is the difference between an overnight job and a next-week job — worth working out before the integration is built.
Wan 3.0 Concurrency on Siray
Siray runs Wan 3.0 above that baseline. That changes which ceiling you plan against: not two concurrent jobs, but whatever your client sustains.
Siray does not publish a per-model concurrency figure, so there is no number to quote here and none is implied. Plan around the shape rather than the value: on Siray, C is not the binding constraint on a Wan 3.0 batch the way it is at the standard allocation. The 250-round arithmetic above stops describing your queue; the bottleneck moves to your client, the part most integrations get wrong.
Batch Client Code: Submit First, Poll Second
Available concurrency is not automatic — it has to be requested, in your code.
Every media endpoint on Siray is asynchronous: submit a job, receive a task_id, poll for completion. A scan of every endpoint finds zero webhook, callback, or notify fields in any request body, so polling is the only completion mechanism, on a documented 3-to-5-second cadence. The async job model is identical across video, image, and 3D.
One consequence is worth stating plainly: a for loop that submits a job, polls it to completion, then submits the next is running at C = 1 — whatever the account could support. The loop is the constraint.
The fix is to submit first and poll second — dispatch a bounded set of jobs, then poll the outstanding task_ids together. The pattern used for bulk image generation applies unchanged. Keep the in-flight set small enough to retry cleanly, and treat a failed poll as a retry, not a lost job.
The shape, with CONCURRENCY as your bound:
sem = asyncio.Semaphore(CONCURRENCY)async def render(prompt): async with sem: task = await submit(prompt) return await poll(task["task_id"], interval=4)results = await asyncio.gather(*(render(p) for p in prompts))Prompt structure is a separate axis — see the short-form scene guide.
FAQ
What decides how long a Wan 3.0 batch takes?
Concurrency, more than per-clip speed. For N clips at C concurrent jobs, wall-clock time is roughly N divided by C, times the time one clip takes. For large batches C dominates.
How many Wan 3.0 jobs can run at once?
During the public preview, the standard allocation is two concurrent jobs per account — a 500-clip batch becomes 250 sequential rounds. Siray runs Wan 3.0 above that baseline.
Does Wan 3.0 support webhooks for job completion?
No. Polling is the only completion mechanism on Siray, across video, image, and 3D endpoints. Submit the job, keep the task_id, and poll every 3 to 5 seconds.
Create your free Siray account and call all three Wan 3.0 endpoints with one API key.