Why the same model renders fast, then slow

The same prompt, the same model, the same settings, forty seconds on Tuesday and six minutes on Thursday. Nothing broke. What changed is that "how long does this model take" is not one measurement, it is at least five, and they are not correlated with each other. Published average generation times average across all five, which is how you end up with a figure that is true of nobody's actual run.

Here are the five clocks, sorted by how much they move and whether you can do anything about them.

The five clocks

Clock 1: cold start and weight loading. The first request to an idle model pays for the model being brought up. Weights have to be resident before a single step of inference happens, and video model weights are large. Once a model is warm, that cost is amortised across every request that follows until it goes idle again and the cycle repeats.

The practical signature is unmistakable: the first generation of a session takes several times longer than the second, third and fortieth, which are all roughly equal. If you have ever concluded a model "got faster after a while", this is what you observed.

Yours to fix, partly. You cannot control whether a model is warm when you arrive, but you can control whether your batch pays for it. Send one throwaway generation, wait for it to return, then dispatch the rest. That moves the cold start off the critical path of ninety clips and onto one. Skipping this and opening with a wide dispatch means your entire first wave queues behind the same startup.

Clock 2: queue depth. You are sharing capacity. Popular models at popular hours have people in front of you, and your generation waits before it computes. This clock has nothing to do with the model's speed and everything to do with demand, which is why it is the one that produces the "why is it slow today" question.

Two symptoms tell you it is queueing rather than compute: the delay is roughly the same for a 4-second clip and a 15-second one, and it varies by time of day for identical work. Compute-bound delays scale with the job. Queue-bound delays do not.

Not yours to fix, but yours to schedule around. Move batch work off peak hours if your throughput measurement shows a large gap between your normal working hour and an off hour. If the gap is small, contention is not your problem and you can stop thinking about it.

Clock 3: resolution tier. This one is arithmetic and it is bigger than people expect. Pixel count grows with the square of the label. Going from 720p to 1080p is not fifty per cent more picture, it is more than double, and 4K against 1080p is four times. Generation time and credit cost both track that curve.

The catalog exposes this as separate quality tiers on the model rather than one setting. Seedance 2.0 publishes 480p, 720p, 1080p and 4k as distinct options; its fast and mini variants stop at 720p. Veo 3.1 publishes 720p, 1080p and 4K. Those are not cosmetic labels, they are four very different amounts of work.

Entirely yours to fix, and it is the single largest lever most people never pull. Draft at the lowest tier the decision requires. You cannot judge a composition, a camera move or a performance at 4K that you could not judge at 720p, and you will throw away most drafts anyway. Move up only for the take you are keeping. The 4K versus 1080p cost page has the credit side of the same decision; the time side moves in the same direction and usually further.

Clock 4: length. A longer clip is more frames and more work, so length and latency are closely tied. A 15-second clip is not a 5-second clip with a longer file, it is more generation.

Duration also interacts badly with the allowed-values problem. Models publish a set of permitted durations rather than a continuous range, and those sets differ hugely, from Hailuo 2.3 Pro at 6s or 10s to LTX 2.3 Text to Video Fast at 6s through 20s in two-second steps. Asking for a length near the top of a model's range is the slowest thing you can do on it.

Yours to fix. Two habits help. Test at the shortest allowed duration, because a shot that does not work at 5 seconds does not become good at 15. And when you need length, decide deliberately between one long generation and several shorter ones stitched, because they have very different time profiles: a long single take is one slow job, while extending a video or stitching shorter clips gives you parallelisable pieces. The longer-than-5-seconds cost page covers the credit side of that trade.

Clock 5: the audio pass. Models with native audio are doing more work than models without, and on some the audio is a separate pass rather than a free rider on the video one. Turning audio on where it is optional adds time.

This is easy to leave on by accident. If the clip is going under a voiceover and a music bed you already have, the model's generated audio is discarded, and you waited for it anyway.

Yours to fix. Turn it off for anything destined for a mix. Leave it on when the model's audio is the point. The audio-capable shortlist and the video-with-sound cost page are the places to check which models are in which camp before you make it a default.

Why the published averages are near-useless

Look at what a single "average generation time" number is being asked to summarise: a distribution over cold and warm starts, over quiet and contended hours, over four resolution tiers, over durations spanning 3 to 20 seconds, and over audio on and off. Those factors span more than an order of magnitude between them. Any single figure sits somewhere in the middle of that spread and describes an experience nobody has.

Worse, the number is usually produced under exactly the conditions least like yours: warm model, short duration, low tier, off-peak, no audio. That is the floor of the distribution being reported as the centre of it.

The honest replacement is a number you measure on your own settings: pick the duration, resolution and audio configuration you actually ship at, run ten, and record the median and the worst. Two numbers, on your configuration, are worth more than any published average, and the gap between them tells you how much of your time is contention.

Sequencing a batch

Put it together and the ordering falls out of the clocks themselves. Each of these is one clock being moved off the critical path.

1. Warm the model with one throwaway generation. Wait for it, then open the taps. Clock 1 now costs you one job instead of a whole wave, and it is the only clock you can retire completely.
2. Group by resolution tier. All the 720p work in one wave, all the 1080p in another. Clock 3 is the largest per-job term in the whole list, so mixing tiers gives you a timing estimate that applies to neither wave.
3. Settle the length question before you dispatch, not after. Clock 4 scales with frames, and one 20-second take and four 5-second clips are different shapes of work, not different sizes of it. You cannot change your mind about that mid-batch without re-running everything you already paid for.
4. Audio off unless the model's audio ships. Clock 5 is pure waste on any clip that is going under a track you already have.
5. Let it run in the background. Multi-step work past thirty seconds runs asynchronously while you keep working, so automating the task beats watching a progress bar. Know how to check or resume a stuck run before you need to.

Clock 2 is the one absent from that list, because scheduling around queue depth is a question about how wide you can run rather than what order you run in, and it does not resolve into a step you take before a batch.

Estimate the credits before any of this. There is no free allowance to absorb a mis-specified batch, so the cost estimator's per-item and total figures against your balance are worth the ten seconds. The estimate-before-dispatch pattern is the fuller version.

FAQ

Is a fast or turbo variant always quicker end to end?

Not necessarily. Fast tiers reduce per-generation compute, which shrinks clock 4 and part of clock 3, but they do nothing about queue depth and they still cold start. A fast tier under heavy contention can finish behind a standard tier that is quiet. These variants typically come from distilling a larger model into a smaller or faster one, so the speed is real; it is just one term of five.

My first generation of the day is always slow. Is that a fault?

No, that is clock 1 doing exactly what it does. Judge a model on its second through tenth generation, never its first. If the second is also slow, then you are looking at queue depth or an oversized configuration rather than startup.

Does the frame rate affect render time?

It affects total frame count, which affects work. Versely renders at 25 fps by default, and it is worth leaving there unless you have a reason, both for time and because mixed frame rates across a project cause problems in the cut later. If a model exposes a 60fps option, treat it as a deliberate choice for slow motion rather than a quality upgrade.

Should I just always draft at the lowest resolution?

For anything where the decision is about composition, motion or performance, yes. The exception is when the thing you are judging is resolution-dependent: fine text legibility, small logos, fabric detail, anything you would later fix with upscaling. Those you have to see at the tier you will ship at, because a clean 720p draft can hide the exact artefact that ruins the 1080p version.