Skip to content
Bud's Wiki

waterloo_intern (ali / Baseten) — Worklog: retrofitting sparsity for the world's fastest video generation kernel (54×)

TL;DR

Section titled “TL;DR”

Tweet by ali (@waterloo_intern, Baseten) promoting a Baseten worklog in which the author describes retrofitting structured sparsity into a frontier open-source video generation model at inference time, yielding what is claimed to be the world’s fastest video generation kernel — iteratively optimizing the OSS model by 54× over its baseline. The underlying worklog itself is hosted as an X article (/i/article/2044877173232963584) and was not retrievable at filing time, so this entry captures the tweet as the surfaceable artifact. The headline pitch is a single-vendor production claim in the same serving-frontier space as FastVideo, TurboDiffusion, and SGLang Diffusion.

Key claims

Section titled “Key claims”
  • Sparsity was retrofitted into a video generation model at inference time (i.e. without retraining), and the resulting kernel is claimed by the author to be the world’s fastest video generation kernel [tweet body].
  • A frontier open-source video model is iteratively optimized by 54× over its (undisclosed) baseline through the same worklog [tweet body].

Method

Section titled “Method”

Not disclosed in the publicly visible tweet text. The tweet promotes a Baseten worklog article (X article ID 2044877173232963584, posted as a cover-image preview) authored by the same handle; the body of that worklog is gated behind X’s article reader and could not be retrieved at filing time. From the visible teaser only, the technique is described as inference-time sparsity retrofit applied iteratively to a frontier OSS video model.

Results

Section titled “Results”

The only quantitative number in the visible tweet is “54×” — a cumulative inference-time speedup vs. the unmodified baseline of the frontier OSS video model the author started from. Baseline hardware, model identity, resolution, frame count, step count, and quality metrics are not disclosed in the surfacable tweet content. 94.7K views at filing time.

Why it’s interesting

Section titled “Why it’s interesting”

This tweet sits squarely on the same serving-frontier curve as FastVideo: Create a 5s 1080p Video in 4.5s on a Single GPU (FastVideo’s single-B200 1080p T2V+audio in 4.5s on an unmodified LTX-2.3) and TurboDiffusion: Accelerating Video Diffusion Models by 100-200 Times (TurboDiffusion’s 97–199× E2E speedup on Wan2.1/Wan2.2 by stacking SLA + rCM + W8A8 on a single RTX 5090). Unlike both of those, ali’s recipe is reportedly pure inference-time, no retraining — placing it closer to Run FLUX.1-dev three times faster‘s compile/cache-only image-DiT recipe but at video scale and at a much larger headline multiplier. The headline 54× is single-vendor and unverifiable from the tweet alone — the same caveats this wiki applies to TurboDiffusion’s 97–199× (see Diffusion serving optimization open questions, and Revisiting RaBitQ and TurboQuant: A Symmetric Comparison of Methods, Theory, and Experiments‘s symmetric-baseline critique) apply here. If the worklog discloses a disclosed-baseline number with hardware and quality metrics, this would be the first wiki entry of a training-free video-DiT serving optimization at the order-of-magnitude scale that TurboDiffusion needs co-trained distillation to reach.

See also

Section titled “See also”