Reelune
Cutting AI Video Generation From 21 to 11 Minutes — 8 Experiments, Measured
Two adopted, two rejected, and the deploy that silently did not take effect
- Wan 2.2 speed
- AI video generation time
- ComfyUI optimization
- diffusion sampling speed
Reelune
Currently in the feed
Auto-pulled from the latest Plays. Refreshes as new videos publish.
The quiet glow of dusk, just for me
@maya-r
Sun-drenched moments in soft denim
@dori-r
Afternoon light, this calm feels good.
@yuki-r
Sunlit cafe moments, can't help but smile
@nell-r
A quiet bar at dusk, a shy smile
@wren-r
Salty air and sunlight, this laugh just broke out
@tala-r
Window light, my quiet little moment
@nell-r
Just me, this light, and a moment
@wren-r
One video took 21 minutes to generate. It now takes 11, at the same quality. Sampling alone got 4.4× faster. Of eight experiments, two were adopted and two were deliberately abandoned. The failures and the walk-aways get as much space here as the wins.
All eight experiments
| Experiment | Result | Verdict |
|---|---|---|
| Fast fp8 math path | 1.41× faster | **Adopted** |
| Steps 8 → 4, CFG 2.0 → 1.0 | Sampling 4.4× faster | **Adopted** |
| Steps 10 → 8 | Adopted earlier | Adopted |
| Trim the video-stage prompt | 799 → 576 chars | Adopted |
| Tiled VAE decode | 10–20% slower, avoids OOM crashes | Adopted (stability) |
| CFG 1.0 in isolation | Prompt bug invalidated the measurement | Deferred, retested later |
| Remove the 150 s overhead | The fallback path is the slow part | **Walked away** |
| Speed up start-image generation | Pure cost is 20 s — already fast | **No change needed** |
Measure before you optimise
Before changing anything we measured where the time actually went. Of roughly 21 minutes per video, the generation stage broke down like this:
Sampling dominates. Nothing else moves the number meaningfully.
Without measuring first, the obvious instinct is to speed up model loading — a 45-second target. You would spend a day there and gain nothing.
Experiment 1: Lower-precision math — 1.41×
We switched matrix math to the fast fp8 path. On a GPU generation that supports it, this is a one-line change.
| Before | After | |
|---|---|---|
| Sampler | 77 s/it | 54.5 s/it |
| Generation stage | ~1,095 s | ~840 s |
| Per video | ~21 min | ~17 min |
1.41×. Resolution, step count and motion instructions were unchanged, so quality impact is essentially nil.
Start with the change you can revert in one line. If a large change fails, you lose the ability to attribute the failure.
Experiment 2: Quarter the steps — 4.4×
This was the real one. The acceleration model we were using is distilled to run in 4 steps. We were running it at 8. On top of that, CFG was set to 2.0, which means two forward passes per step.
So we were doing 8 × 2 = 16 passes where 4 × 1 = 4 was the design point.
77% reduction. 4.4× faster.
The risk we were most worried about was motion stopping short with fewer steps. So we picked the most motion-heavy case we had, pinned the start image, prompt and seed, and compared before against after. Motion completed, and quality was equivalent.
The cost: negative prompts stop working
Setting CFG to 1.0 halves the work, but you pay for it.
CFG amplifies the difference between following the prompt and ignoring it. At 1.0 that comparison is skipped entirely, which means "do not produce this" instructions have no effect during the video stage.
- Negatives on the start image stage still apply
- Video inherits colour and appearance from that image, so the impact is bounded
- But artefacts introduced during the video stage can no longer be suppressed
Speed and control trade against each other. We could accept this because we suppress at the image stage and review before publishing. Without that second layer, the same call would be wrong.
Walked away 1: the 150 seconds we could not remove
The largest remaining waste was about 150 seconds on every single video. The encode step runs out of memory and falls back to a slower path.
What we found on measuring: the fallback path itself is the slow part. The normal path finishes in seconds.
"Just use the fallback from the start" is not a fix. It means choosing the slow path every time — exactly the situation we were already in.
The real fix is making the normal path fit in memory. But this GPU is shared with another workload, and we cannot free that headroom unilaterally.
| Option | Effect | Why rejected |
|---|---|---|
| Drop resolution slightly | Down to seconds | Degrades the published video |
| Dedicated GPU | Solves it properly | Environmental, not a code problem |
We walked away. The only routes were lowering quality or changing the environment, and the first defeats the purpose.
Walked away 2: measuring showed nothing needed fixing
Start-image generation was swinging between 20 and 756 seconds. We assumed the settings needed tightening, so we measured.
| Condition | Time |
|---|---|
| Pure generation | 11–12 s |
| Uncontended | ~20 s |
| Contended | 88–99 s (outliers to 756 s) |
The settings were fine. The variance came from contention with the other workload on the same GPU — the same root cause as the experiment above.
We looked at levers anyway and rejected them. Cutting steps would save 4 seconds, and paying for those 4 seconds with the quality of the single frame every video is built from is not a trade worth making.
Where it feels slow is not always where it is slow. Finding out that nothing needs fixing is a real result.
The dangerous part: the change never took effect
Right after deploying the 4.4× configuration, production was still running the old settings.
Three things stacked up:
- After the code shipped, the running process was judged "already up" and the restart was skipped
- Stale Python bytecode meant the old code kept loading
- The command used to verify it was running matched itself, reporting success
"Deployed" and "in effect" are different claims.
The procedure now stops the process for certain, clears the cache, starts clean, and confirms the step count in the live log actually changed. The verification method mattered more than the setting.
Where it landed
No quality was traded away. Resolution and frame count are unchanged, and we later confirmed the adopted values match what comparable services run in production.
About 150 seconds of waste remains, caused by the shared GPU. It resolves itself the day we move to dedicated hardware. Everything reachable from code has been done.
What actually generalises
- Measure the breakdown first. Without knowing which stage dominates, you will optimise something worth tens of seconds.
- Cheapest-to-revert change first. A large change that fails destroys attribution.
- One variable at a time. Pin the start image, prompt and seed, or you cannot tell speed from settings.
- Verify against the worst case. Passing on an average case proves nothing.
- Record what you rejected. Otherwise someone repeats the experiment in six months.
- Confirm it took effect. A setting you think you changed but did not costs more than the setting itself.
Characters in the cast
FAQ
Does cutting steps hurt quality?
It did not here, because the acceleration model is distilled for 4 steps to begin with. We compared on the most motion-heavy case with start image, prompt and seed pinned; quality and motion completion were equivalent. Running 8 steps was simply missing the design point.
Is losing negative prompts acceptable?
Negatives stop applying during the video stage. We could accept that because negatives still apply when generating the start image, and everything is reviewed before publishing. Without that second layer the trade would not be worth it.
Why can't the remaining 150 seconds be removed?
An out-of-memory condition pushes the encode onto a slower path. Fixing it properly means making the normal path fit, and the GPU is shared with another workload so the headroom is not ours to free. Lowering resolution would fix it but degrades the published video, so we rejected that.
Where should someone start?
By measuring the per-stage breakdown. Sampling turned out to be the overwhelming majority here, and optimising anything else would have moved the number by tens of seconds. Starting without measuring means spending effort where it cannot pay off.
The setting changed but nothing got faster — now what?
Doubt that it took effect. In our case the transfer succeeded but the running process was never restarted, stale bytecode kept the old code alive, and the health check matched itself. Confirm the actual value in the live log every time.
Open the feed