# UltraFlash promises a kilovideo at thirty frames a second and has not released its training code > A streaming video pipeline that upsamples a low-resolution generator in real time on one card, built from three cascaded components and a 1.3 billion parameter base model. The inference side is released with five checkpoints and two command line entry points; the training side is an unchecked box in the to-do list, and the install requires cloning a CUDA kernel from another laboratory. **xin1u/UltraFlash** — Ultra Flash: Scaling Real-Time Streaming Video Generation to High Resolutions - Repository: https://github.com/xin1u/UltraFlash - Stars: 531 · Forks: 1 - Language: Python - License: not declared - Published: 2026-09-20 · Updated: 2026-09-20 · Language: en - Canonical page: https://hysenlabs.com/projects/xin1u-ultraflash ## The headline is one card at thirty frames a second The claim is specific and it is the whole pitch: real-time high-resolution streaming video generation, producing kilovideo at roughly thirty frames per second and two-kilovideo at roughly eighteen frames per second on a single GPU. The architecture is a cascade hanging off a low-resolution streaming generator, with three components doing the work. The first is training for super-resolution that goes from text-to-video to text-and-video-to-video while preserving the architecture, using degradation designed around generated content rather than photographs. That last part is the interesting bit: upscaling a model output and upscaling a camera roll are different problems, and a degradation pipeline trained on the wrong distribution produces the plastic look people associate with upscaled video. The second is a causal streaming latent upsampler, quoted at roughly two million parameters and under five percent overhead. Small because it runs per frame in a loop, where anything large stops fitting the budget. The third is cascaded streaming optimisation, which combines sparse distillation with preference optimisation and dynamic cache management. The base model underneath is a 1.3 billion parameter text-to-video model from another lab, which is downloaded separately. So the released artefact is a cascade and a set of adapters over someone else's generator, not a model from scratch. ## Inference is checked off and training is not The to-do list has two items and one of them is done. Inference code and checkpoints are marked complete, and the news entry above it puts the release in August 2026 on both the source host and a model host. The parenthetical in the to-do line is worth noting: it says the release covers short and long video, which matches the two directories in the repository. Training code and configs are not released. The box is empty. That single empty box changes what the release is. Everything described in the architecture, from the degradation model to the distillation, was produced by training runs whose code and configuration are not public. So a reader can verify that the inference pipeline produces video at the quoted rates, and cannot check how the super-resolution model was trained, what data it saw, or what the preference optimisation optimised for. That is normal for a research release and worth stating plainly rather than treating as a defect. It does mean the paper's training claims rest on the authors' checkpoints, and the inference numbers rest on code anyone can run. The licence is another item to locate before you build on it: the header links to a licence file inside the inference directory rather than at the repository root, and no licence file appears at the top level in the listing. ## The install requires a kernel cloned from another laboratory The installation sequence is where the project's dependencies on other people's work become concrete. ```bash conda create -n ultraflash python=3.10 -y conda activate ultraflash cd inference pip install -r requirements.txt pip install flash-attn --no-build-isolation # Block Sparse Attention (CUDA kernel, required for SR DiT) git clone https://github.com/mit-han-lab/Block-Sparse-Attention.git cd Block-Sparse-Attention pip install -e . cd .. python setup.py develop ``` So the sparse attention kernel required by the super-resolution stage is a clone of another group's repository, installed in editable mode. That is a real operational dependency: a research group other than the authors owns the kernel your build depends on, and an editable install means a change to their default branch changes yours. Two more details in that block. The attention library is installed with build isolation disabled, which is required to build it against the local toolchain. And the final step uses the legacy development install command rather than an editable install flag, which modern packaging tools have deprecated. The hardware floor is listed above the install: an accelerator with at least twenty four gigabytes of memory, sixty four gigabytes of system memory, Linux, and Python 3.10 or later. Three cards are named as tested, spanning a consumer part and two datacentre ones, so the twenty four gigabyte figure is the consumer configuration rather than the minimum. ## Four required checkpoints and one optional decoder The checkpoints directory is a short, well documented list, which is more than most releases manage. Four files are required. One is the streaming generator itself, described as a four-step self-forcing generator, and one is the sparse causal super-resolution stage in single-step form. One is the latent upsampler, and one is a small decoder for high-resolution decoding, described as faster than the base model's own decoder. The fifth is optional and is a second decoder. It is an improved high-resolution decoder with better texture fidelity, and enabling it replaces the small decoder rather than combining with it. So there is a decoder decision to make before you run anything, and the flag defaults to the fast one. That is a reasonable default given the project is arguing about frame rates, and it means the texture improvement is opt-in rather than discovered. The long-video directory has its own pair: a base generator described as the streaming generator with long-video fine-tuning applied, plus an adapter file at rank two hundred and fifty-six for long-video coherence. The other three files are the same as in the short directory and the documentation says they can be linked rather than duplicated. The two halves have separate entry points, with the long one named differently from the short one, so a script you learn from one will not exist in the other. ## The symlink block includes a link that points at its own parent The download instructions end with an optional step for sharing checkpoints between the two directories instead of storing them twice: ```bash # Symlink shared checkpoints to avoid duplication (optional) cd inference_long/checkpoints ln -s ../../inference/checkpoints/sr_dit_sparse.pth . ln -s ../../inference/checkpoints/latent_upsampler.pth . ln -s ../. ``` The first two links are the intended behaviour: a relative path up out of the long-video checkpoints directory, across to the short-video one, and down to a named file, creating a link in the current directory. The third line is not that. It links the current directory's parent into the current directory, with no target name, so it creates a self-referential entry. Whatever walks that directory afterwards, including the training or inference tooling and any recursive copy, has to cope with a cycle. It is marked optional, so a user who skips the block entirely is unaffected. A user who runs the block as printed gets a link they did not intend in a directory that three different files are expected to live in. The long-video checkpoint table independently confirms which files are meant to be shared, marking the sparse super-resolution stage, the upsampler and the small decoder as the same as in the short directory. So the intent is clear and the third command does not match it. ## The two entry points disagree about the same default The argument tables are the most useful documentation in the file, and reading them side by side surfaces a discrepancy. The small decoder flag defaults to true in the short-video table and to false in the long-video table. So the same switch, on two scripts that share a cascade, behaves differently by default. Nothing in the text explains the difference, and a user moving a working command line from short to long video will silently lose the fast decoder unless they notice. The rest of the differences are additive rather than contradictory. Quantisation has one flag in the short entry point and two in the long one, the second covering the super-resolution stage separately, which makes sense for a pipeline with two model stages and is a hint that the short script could use the same treatment. Two defaults are worth reading closely. The scale of noise injected into the super-resolution condition is zero, so by default the low-resolution stream conditions the upsampler without perturbation, which is the deterministic choice. The number of denoising steps for subsequent chunks is four, and the documentation annotates that four means the full count, so the flag exists to make it cheaper and the default is not. One flag carries a number: compilation of the streaming generator is quoted at roughly one and a half times faster. That is the only performance figure in the argument tables, and it is for one stage of a three-stage cascade. ## Two asset directories, and three optimisations with two costs marked negligible The repository root is small: a readme, two directories whose names differ by one letter, a single page file, and the two inference directories. Having both an asset directory and an assets directory at the top level is the kind of duplication that survives because neither is referenced in the documentation you can see, and one of them is probably a stray. The inference optimisations are described as a table of three items with an effect and a quality impact column, and the copy in the retrieved text is cut off after the third row. The first two are both marked negligible. Reducing the low-resolution steps saves one forward pass per chunk, which is a real saving on a per-chunk budget. Adaptive cache refresh skips rerunning context when the quality is judged sufficient, and the judgement is described as based on an image quality assessment, so there is a model in the loop deciding whether the cache is stale. That second one deserves more attention than its cost column gives it. An image quality gate that decides to skip recomputation is optimising frame rate against temporal consistency, and a false pass means a visible artifact that propagates into later chunks of a stream. The table's own classification of it as negligible is a claim, not a measurement, and the evaluation method is not described in the visible text. The third optimisation is the one that was cut off, and it concerns adapting the cache to the super-resolution stage. ## Conclusion This is worth reading if you build streaming video and want to see how a real-time upsampling cascade is wired, because the argument tables and the per-stage flags are unusually explicit about defaults and their costs. Two things to know before you try it. The hardware floor is high and Linux only, and the install depends on a kernel built from another research group's repository. And the training half is not published, so what you can check is inference behaviour rather than how the numbers were obtained. ## FAQ ### What frame rates does UltraFlash claim? Kilovideo at roughly thirty frames per second and two-kilovideo at roughly eighteen frames per second, both on a single GPU, achieved by cascading an upsampler and a super-resolution stage after a low-resolution streaming generator. ### Is the UltraFlash training code available? No. Inference code and checkpoints are released, covering short and long video, while training code and configs remain an unchecked item in the project's to-do list. ### What does UltraFlash require to install? A Linux machine with a GPU of at least twenty four gigabytes and sixty four gigabytes of system memory, Python 3.10 or later, and a clone of a sparse attention CUDA kernel from another research group installed in editable mode, plus an attention library installed with build isolation disabled. ### Which checkpoints does UltraFlash need? Four required files: the streaming generator, the sparse causal super-resolution stage, the causal latent upsampler, and a small high-resolution decoder. A fifth, an improved decoder with better texture fidelity, is optional and replaces the small one when enabled. ### How long a video can UltraFlash generate in its long-video mode? Around ten seconds, described as one hundred and twenty latent frames, using a separate entry point with a base generator and an adapter file at rank two hundred and fifty-six, plus the shared super-resolution and upsampler checkpoints. ### What do the dynamic cache management optimisations do? Three inference-time changes: reducing low-resolution steps to save one forward pass per chunk, skipping a context rerun when an image quality assessment judges quality sufficient, and adapting the cache for the super-resolution stage. The first two are described as having negligible quality impact. ## Sources - [Issues](https://github.com/xin1u/UltraFlash/issues) - [README](https://github.com/xin1u/UltraFlash/blob/main/README.md) - [xin1u/UltraFlash on GitHub](https://github.com/xin1u/UltraFlash) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/xin1u-ultraflash