Direct answer
The short version
Capacity-test the exact provider account, region, endpoint, model and output settings you intend to launch. Run stepped synthetic workloads, then measure accepted submissions, queue time, generation time, successful downloads, terminal failures, polling traffic and cost per usable output. Separate task-creation capacity from status-query capacity, stop when documented limits or your approved test budget are reached, and do not turn one short test into an uptime or throughput guarantee.
What does capacity mean for an asynchronous video API?
Capacity is not the response time of the task-creation request. A video API normally accepts work first and completes it later. Alibaba Cloud documents Wan generation as taking roughly one to five minutes and returning a task that must be queried. MiniMax likewise documents a three-step flow: create a task, check its status, then retrieve the generated file.
A useful test therefore measures several queues separately. Record whether the provider accepted the submission, how long it waited before running, how long generation took, whether the result could be downloaded, and whether the output met the buyer's acceptance criteria. The number of HTTP 200 responses alone is not production capacity.
- Submission capacity: approved tasks accepted per minute without unplanned retries.
- Processing capacity: tasks completed per hour at the required mode, duration and resolution.
- Delivery capacity: successful results downloaded and verified before any link expires.
- Usable capacity: outputs that pass the buyer's documented acceptance criteria.
Which configuration must stay fixed during the test?
Test the commercial configuration you actually intend to buy. Region, key, endpoint, model identifier, generation mode, duration and resolution can all change latency, price or availability. Alibaba's current Wan reference requires the model, endpoint and key to match the region, so a result from one configuration should not be generalized to another.
Use synthetic, non-confidential prompts and media that represent the expected workload shape. Keep a small set of repeatable cases, but vary the content enough to avoid mistaking one unusually easy prompt for normal performance.
- Customer-owned test account and intended region
- Exact endpoint, model identifier and generation mode
- Duration, resolution, aspect ratio and optional reference inputs
- A dated copy of provider limits, pricing and availability documentation
- A pre-approved maximum number of paid attempts
How should load increase without creating an accidental bill?
Start with one task at a time and confirm end-to-end recovery before adding concurrency. Increase in small, documented steps only after the previous step has completed. Stop on unexpected charges, authentication or quota errors, rising terminal failures, unreconciled tasks, or any documented account limit.
Do not implement an open-ended stress test against a paid generation service. The goal is to find a safe operating envelope for the intended workload, not to discover the provider's infrastructure ceiling. Provider limits can also be account-specific, so only the live account and current documentation can define the boundary.
- Stage 1: one task through submission, status and download.
- Stage 2: a short sequential run to validate recovery and cost logging.
- Stage 3: small parallel batches within the documented account limit.
- Stage 4: a time-bounded soak at the proposed normal operating level.
- Keep a manual stop control and a hard attempt cap at every stage.
How should polling load be measured?
Status polling is a separate traffic stream from task creation. Alibaba's Wan reference gives 15 seconds as a reasonable polling interval and lists a default query limit of 20 requests per second. MiniMax's video guide demonstrates a 10-second interval. These are current provider examples, not universal service levels.
Count status requests across every worker and job. Add jitter so tasks do not poll at the same instant, stop immediately on a terminal state, and back off when the provider returns a rate-limit or transient error. A larger generation queue should not automatically multiply polling into an avoidable failure.
- Status requests per active job and per minute
- Rate-limit responses and successful recovery
- Time from provider completion to local detection
- Jobs left in unknown or unreconciled states
- Polling stopped after success, failure or cancellation
Which measurements belong in the capacity record?
Use percentiles and counts rather than a single average. Averages can hide a long queue tail that causes missed deadlines. Keep provider errors, client-network errors, generation failures, expired results and creative rejections as separate categories because they require different fixes.
Record the observation window and account configuration beside every result. A test is reproducible evidence for that configuration and date; it is not a promise that future provider performance will be identical.
- Accepted submissions, rejected submissions and duplicate attempts
- Queue time and end-to-end completion time at median, p90 and maximum
- Successful, failed, canceled and unreconciled tasks
- Successful downloads and expired or unreadable results
- Usable-output rate and cost per usable output
- Provider request IDs and sanitized error codes
How do you turn a test into an operating envelope?
Choose a normal operating level below the highest step that completed cleanly. Reserve headroom for queue variation, retries and polling, and define a lower degraded mode that reduces new submissions when latency or failure rates rise. A fallback provider should be evaluated as a separate account, region and data path rather than assumed to be interchangeable.
Document the triggers that require a retest: model or endpoint changes, new regional deployment, a price or quota change, altered input settings, or a material shift in workload. IT CaoCao can prepare the test plan and review the resulting evidence without receiving production credentials or generation content.
- Normal concurrent-task target and maximum queued work
- Submission pause thresholds for latency, errors and spend
- Manual reconciliation path for uncertain jobs
- Owner and date for the next review
- Retest triggers tied to provider Signals and product changes
Frequently asked questions
Questions buyers ask next
Can one load test prove an AI video API's production SLA?
No. It provides dated evidence for one account, region, model, configuration and workload. It cannot replace a provider SLA or guarantee future throughput and availability.
Should task creation and status polling share one rate limit?
Do not assume they do. Treat them as separate endpoint workloads and check the current provider documentation and account limits for each.
What is the safest way to increase video API concurrency?
Increase in small, time-bounded steps after validating end-to-end recovery at the previous level. Use synthetic inputs, a hard attempt cap, a manual stop control and the provider's documented limits.
Which capacity metric matters most to a buyer?
Usable outputs delivered within the required time is more meaningful than accepted requests alone. Review it with failure categories, queue percentiles, polling load and cost per usable output.
Primary sources
Evidence reviewed
Provider documentation changes. Recheck the live source before making a procurement decision.
- Alibaba Cloud Model Studio: Wan text-to-video API referenceAccessed 2026-08-24
- MiniMax API: video generation workflowAccessed 2026-08-24
- MiniMax API: query video generation taskAccessed 2026-08-24