Wan2.2 video generation 2.6x faster on one H100: 143 s to 56 s, 4 cents a clip

Wan2.2-TI2V-5B is a small, dense, open-weight text-to-video model, and at its default setting it is not fast: one 5-second 720p clip takes 143 seconds on an H100. Our AI agent set up and ran an optimized configuration of it on a rented H100 at $2.50 an hour. The clip now takes 56 seconds, and the GPU cost of a clip fell from about 10 cents to about 4.

Our plan is to let coding agents search for the fastest safe configuration of each model on each chip, instead of hand-tuning one model at a time. Before spending agent time on that, we wanted three things in hand: a baseline we trust on our own hardware, an evaluation set we control, and an honest read on whether a published recipe holds up outside its authors’ setup. A recipe that does not carry over is a bad starting point for a loop that is supposed to improve on it.

How the agent workflow is meant to work

The workflow is built around a master orchestrator that supervises up to three executor sub-agents, one per acceleration technique: kernel (fusion, compilation), cache (reusing work across denoising steps) and sparse attention. Each executor explores its technique’s search space and returns a validated configuration. The master gates the results, removes duplicates and integrates what survives. The pieces that matter are not the agents themselves:

• A config manifest is the unit of work. Each optimization is a small file with an id, a kind (baseline, patch or control), the runtime it uses and the flags that switch the technique on. Baselines and same-topology controls are first-class, so every speedup names its denominator.
• No speedup is accepted on wall-clock alone. The workflow defines six gates: expected artifacts exist, the official config matches, performance beats the baseline, turning the technique off recovers the baseline, quantitative quality is within tolerance, and a visual check sees no new artifact. A separate authenticity check confirms the technique actually engaged, so a no-op cannot claim a speedup.
• Delivery is tiered. The output is not one configuration but the best-quality one in each speed bucket: at least 1.5×, 2× and 3×.

Two things are worth knowing about how this workflow is published. First, what is public is the contracts and the gates, not an agent runtime: the agents are general coding-agent sessions steered by those documents. Second, the part that stops an agent from cheating, the evaluation harness, has to be something the agents cannot edit. That is the design we are building: agents propose, a deterministic harness disposes, and the held-out prompts never leave the harness.

Why 143 seconds: the arithmetic

A 5-second 720p clip is a long sequence for a 5B model. Wan2.2-TI2V-5B compresses video 16× in each spatial direction and 4× in time, then groups 2×2 latent patches into one token, so a 704×1280, 121-frame clip is 27,280 tokens going through 30 transformer layers.

Two facts set the cost. Every denoising step runs the transformer twice (one pass with the prompt and one without, the classifier-free guidance pair), so 50 steps is 100 full forward passes. And attention over 27k tokens is expensive: by our estimate from the standard transformer FLOP formula, one forward pass is about 516 TFLOP and attention is roughly 53% of it. That works out to about 52 PFLOP for the whole clip. The measured 129 seconds of denoising implies about 400 TFLOPs sustained, which is already a large share of what an H100 can do on this kind of workload.

The consequence is that the GPU is not idle and nothing is misconfigured. The only ways to go faster are to do less work (skip passes, skip attention) or to do the same work more efficiently (fusion, compilation). Those are exactly the two levers in the recipe.

The setup

• Model: Wan2.2-TI2V-5B in diffusers, BF16, official settings: 1280×704, 121 frames, 24 fps, 50 steps, guidance 5.0, one fixed seed for every run.
• Hardware: one H100 80GB HBM3. Baseline and optimized runs used the same machine, so the ratio is not confounded by hardware.
• Prompts: eight prompts from our own evaluation set, one from each of eight failure categories (more on that set below).
• Recipe: regional torch.compile, merged QKV projections, a cross-attention K/V cache and BF16 block glue, plus EasyCache with threshold 0.036, keeping the first 7 steps and the last step dense. The recipe describes the kernel part as lossless and the cache part as approximate.
• How we timed: model load excluded, the baseline run warmed up once and the optimized run twice (compilation happens in the first), then the median over the eight prompts.

The results

Two things in that table are worth a second look. The denoising speedup is 3.0×, but the clip speedup is 2.57×, because the VAE decode is untouched and is now a fifth of the total. And the number of forward passes is not a constant: the cache decides per prompt.

What EasyCache actually does

It does not shorten the schedule. All 50 steps still happen and the sampler still updates the latent at every one. What it skips is some of the calls to the transformer. After the first 7 steps, for each of the two guidance branches, it tracks how much the input has drifted since the last time the model was really run and multiplies that by how much the output changed last time. When that running estimate stays under the threshold, it reuses the previous output change instead of computing a new one. Once it crosses the threshold it computes fully again.

Across these eight prompts the cache reused about half of the passes, 51% on average, close to the roughly 47% the recipe’s authors report. The shape is plausible: the low-motion prompt tied for the fewest passes, and the motion-heavy and hands prompts tied for the most. Eight prompts is a small sample, so treat that as a hint and not a finding.

How this compares with the published number

The published recipe reports 70.25 s down to 24.35 s, 2.885×, on a single GB200. It decomposes that as lossless kernel fusion at 1.52× times EasyCache at 1.90×. We got 2.57× on an H100, whose baseline is itself about 2× slower than the GB200 (143 s against 70 s). We do not know why the ratio is lower than 2.885×. Candidates are the different chip, our eight prompts against their five, and the fixed 11-second VAE decode, which is a fifth of our optimized run. We did not investigate, and we did not separate the kernel and cache contributions, so we cannot compare our split with 1.52× and 1.90×. What we can say is that the recipe carries over to a different GPU generation, with the same mechanism and the same order of magnitude.

What we can and cannot say about quality

EasyCache is approximate, so the videos are close to the baseline, not identical to it. This is the section to read most skeptically.

• PSNR between the two runs is 26 to 39 dB. That says the optimized video shows the same scene and composition with differences in detail. It does not say which one looks better. Small shifts in a moving subject lower PSNR a lot, so the lowest value, 26.1 dB on the camera-move prompt, may reflect geometry shifting more than quality dropping.
• We looked at a handful of frames, not all eight clips end to end: frame 60 of the surfing dog and of the red car, side by side. Subject, composition, lighting and water looked consistent in both. That is a spot check, not a review.
• We did not run the full gate set. There is no LPIPS number, no automated visual judge and no off-identity check for this run. By the standard we set ourselves, the configuration has not been promoted.

What we could not run

The configuration we started from, wan5b_kernel_easycache_pisa, adds a sparse-attention method called PISA on top of the 2.885× recipe. It failed 14 seconds after starting: the code loads pisa_attention.py from a path inside an internal experiment archive that is not in the public repository, and we could not find the file anywhere in it. So we have no measurement of PISA on this model. We switched it off and ran the rest, which is the published 2.885× recipe.

We lost about 11 minutes of GPU time noticing the failure, because our monitor was set to wake us when the baseline finished, not when the next job failed. The lesson is the usual one: a harness must decide success from the exit status and the declared artifacts, and check every job it queues, not only the first.

Hardware notes

• The cheapest H100 listings are not always the cheapest H100 you can get. Lium lists H100 nodes at $1.55 to $1.99 per GPU-hour, but those nodes are rented as whole 8-GPU hosts. The single-GPU nodes we could actually rent started at $2.43 to $2.50. Check the minimum rental unit before comparing prices.
• Mind the container. The Lium container had a 22 GB root disk, too small for 32 GB of weights plus an environment, and an 81 GB encrypted volume mounted at /root. Pointing the working directory there fixed it without a visible cost to speed: denoising ran at 2.64 s per step.

The evaluation set

An optimization loop is only as honest as its evaluation set, so we built ours before running any agent. It is 80 prompts across eight failure categories: motion-heavy, low-motion, fine detail, human subject, camera moves, animal anatomy, hands and interaction, and ambiguous short prompts. We took the prompts from an internal video quality project unchanged and added the splits:

Every prompt belongs to at least one set, the visible sets are nested, and a test asserts the held-out prompts never overlap with what agents see. One honest limit: that separation is a convention until the harness runs somewhere the agents cannot reach. The prompts are also short and video-only, so a model that generates audio, like MiniMax-H3, needs its own set.

What it cost, in time and money

These are estimates for the single H100 that produced every number above: hourly rate times wall-clock time. We have not reconciled them with the provider’s invoice.

• Time: about 57 minutes from renting the H100 to deleting it. About 36 of those minutes were the GPU generating the clips behind the numbers in this post; the rest was setup, one failed launch and cleanup.
• Money: generating the clips cost about $1.50. The session as a whole cost about $2.40, because setup and the failed launch are part of what a real run of this work costs.
• Not measured: the engineer time spent preparing the evaluation set and reading the repository, and any language-model usage. We have no figure for either, and we would rather say so than guess.

What comes next

• Add the quality gates this run skipped: LPIPS against frozen baseline frames, an automated visual judge, and the off-identity check.
• Find a working PISA implementation, measure it, and see whether it adds to the 2.57× or competes with the cache.
• Repeat on B200 and on MiniMax-H3, the model we actually serve, where audio and dialogue need their own checks.