LingBot-Video claims three times faster inference and names no baseline

About three times faster than an unnamed baseline

The highlights list has four entries and the first one carries the only speed number in the file.

It is an efficient mixture-of-experts architecture, scaled from scratch, balanced between capacity and cost, with roughly three times faster inference.

Faster than what is not stated. There is no baseline model named, no hardware, no resolution, no step count, no batch size, and no indication of whether the comparison is against the same architecture without the routing or against a different model family. A three-times claim on a mixture-of-experts design is a reasonable expectation on its face, since a sparse model activates a fraction of its parameters, but as written the number cannot be checked and cannot be compared to anything.

The other three highlights are better specified. A data engine trained on web video with more than seventy thousand hours of embodied data mixed in. A multi-reward system that scores high aesthetics, physical rationality and task completion separately. And few-step student sampling, with DMD-distilled checkpoints for text-to-video and image-to-video that generate in eight steps on both the diffusers and SGLang engines.

The framing around all of it is where the claims get softer again. The model is described as the first open-source large-scale mixture-of-experts video generation model dedicated to embodied intelligence, and as a top-tier video model bridging the gap between video synthesis and physical world understanding. Both are priority and ranking claims with nothing attached to them.

Two of the five model rows are somebody else's checkpoint

The download table has five rows, and the parameter counts are worth reading as two different kinds of model.

The first is dense at 1.3 billion, covering text-to-image, text-to-video and image-to-video. The second is the mixture-of-experts variant, 30 billion total with 3 billion active, plus a refiner, adding refinement to the same three tasks. The third is the distilled student of that same MoE, also 30B-A3B, covering only text-to-video and image-to-video.

Then the last two rows. The rewriter base is listed as the official Qwen 27B model, and its download link points at the Qwen organisation's repository rather than the project's own. The rewriter adapter is described as a Qwen 27B LoRA, and that link does point at the project.

So a table headed model name, inside a project that is a mixture-of-experts video model, contains two entries that are a third-party language model and a LoRA on it. That is not a criticism of the design, since a rewriter has to be built on some base model, and choosing a public one is the more reproducible choice. It is a problem for anyone scripting against the table, because the rows differ in kind and not only in size, and the first of the two is not this project's artifact at all.

The two rewriter variants are also not interchangeable. One is for expanding a prompt and the other for a JSON form, which is why the adapter exists as a separate download.

The benchmark page and the leaderboard are hosted by someone else

The evaluation section is one row, and following its links takes you out of the project entirely.

The dataset is published as LingBot-Video-RBench, on Hugging Face, under the project's own account. The benchmark itself points to a webpage hosted under a different organisation and a different name, and the leaderboard points to a Hugging Face Space belonging to a university group rather than to a file in the repository.

So the model team publishes the data and the scoring infrastructure belongs to a third party. That is common in the field, where a shared benchmark is the point, and it means the numbers are comparable across submissions in a way a private harness would not be. It also means a reader who wants to know how RBench is scored has to read somebody else's documentation.

The naming is a small thing worth recording. The benchmark is called RBench, the dataset is called LingBot-Video-RBench, and the webpage is not hosted under either name. The project also distributes weights on two registries rather than one, Hugging Face and ModelScope, with every model and the dataset mirrored to both, which is a deliberate choice for reach rather than a redundancy problem.

The recommended PyTorch is a dated nightly build

The install section names its own PyTorch, and the version is a development snapshot from a nightly channel.

git clone https://github.com/Robbyant/lingbot-video
cd lingbot-video

python -m venv .venv
source .venv/bin/activate
python -m pip install -U pip

# Base requirements cover direct DiT inference and rewriter --backend transformers.
pip install -r requirements.txt
pip install -e .

The requirements file opens by adding a nightly extra index for CUDA 13.0, and then pins `torch` to a dated dev build with a CUDA 13.0 local version, and pins `torchvision` to the matching dev build of the same date. Both are marked recommended in the runtime version table, and both carry a date inside the version string rather than a release number.

That is the correct build for a model that needs an unreleased kernel, and it comes with a cost worth naming. A nightly index is a moving target: entries get superseded and removed, so a lockfile that resolves today may not resolve on the same machine next month, and the date in the version string is the only way to tell two nightly wheels apart.

The rest of the table is more conventional: Python 3.10 or newer, transformers at 5.8.1, diffusers at 0.39.0, peft at 0.19.1, and floors for JSON repair, decord and safetensors.

The requirements file and the manifest disagree on three packages

The install runs the requirements file first and then installs the package editable, which means both constraint sets are applied in sequence to the same environment.

That matters because they are written in different styles. In the requirements file, diffusers is pinned to 0.39.0, peft to 0.19.1 and transformers to 5.8.1, all exact. In the manifest, the same three are diffusers at 0.37.1 or newer, peft at 0.19 or newer, and transformers at 5.0 up to but not including 6.

So a clone install gets exactly 0.39.0, 0.19.1 and 5.8.1, while the same package installed from an index is allowed anything satisfying the looser ranges. A user on diffusers 0.37.2 satisfies the manifest and is exactly one patch away from the version the model was validated against.

The looser ceilings are not arbitrary either. Transformers is capped below 6 rather than left open, which keeps a future major from arriving unannounced, and the other two have floors rather than ceilings, so they can move up.

Everything else in the manifest uses the floor style, and the package itself is a pure Python distribution built with setuptools, with a single package directory found by an include pattern and one data file shipped inside it: a default negative prompt stored as JSON in the package rather than in a user configuration.

The SGLang path installs with dependency resolution switched off

There are three documented ways to reach SGLang, and they do not agree with each other.

The repository root carries a second requirements file dedicated to SGLang, and the instruction to use it is a single command with a flag that suppresses resolution.

The manifest also declares SGLang as an optional extra, together with Triton, and that extra would resolve dependencies the normal way. The runtime version guidance says to install the SGLang requirements only when using SGLang Diffusion or the fused and FP8 mixture-of-experts runtime, so there is a third route of simply not installing anything and finding out.

The `--no-deps` instruction is the one that needs care. It means pip will not pull anything the SGLang requirements list, so whatever those packages need at runtime has to already be satisfied or has to be installed by hand. That is a reasonable choice for a file that must not perturb a working torch nightly install, and it is also the kind of instruction that produces a missing-module error in a fresh environment rather than a resolved one.

The fused and FP8 mixture-of-experts runtime named in the same sentence is the second thing this path enables, so the file is asking one optional install to serve two purposes: a different inference engine and a different numeric path for the sparse model.

A transformer-only export is not sufficient, and the file says so

One failure mode is documented explicitly, which is more than most model repositories do.

The model directory has to be a downloaded local model root containing `model_index.json` and five subdirectories: `transformer/`, `text_encoder/`, `processor/`, `vae/` and `scheduler/`. Its `transformer/` must hold the DMD student weights. And then the sentence that saves someone an hour: a transformer-only export is not sufficient.

That is the shape of a diffusers layout rather than a single checkpoint, and the requirement exists because the student weights alone cannot reconstruct the text encoder, the tokenizer wrapper, the VAE or the scheduler configuration. Anyone handed a bare safetensors file by a third party will hit the requirement and now has the reason in advance.

The invocation shows the rest of the surface. The scripts take environment overrides for the model directory, a prompt file, an input image for the image-to-video case, an output directory, a seed, height, width, backend and Python binary, and the direct runner takes the same things as flags.

The dtype choices in that command are the detail worth keeping. The transformer and the text encoder both run in bfloat16 while the VAE is explicitly held at single precision, which is the usual arrangement and the one you would want written down before you go looking for a quality bug in float16.

The rewriter is a repository directory, not an installed package

The root holds a package directory, a rewriter directory, a scripts directory, assets, docs, and two requirements files. There is no tests directory anywhere in the listing.

The rewriter is a top-level sibling of the package, and the manifest's package discovery is limited to the package directory by an include pattern. So the rewriter code is not installed by `pip install -e .`, and neither is the scripts directory that the documented entry points live in.

That is a real constraint on how the thing gets used. Two of the five downloadable models are rewriter artifacts, the two-stage rewriter semantics are described in detail in the deployment note, and none of that code is inside the distribution. A user who installs the package from an index and follows the prompt preparation documentation will find the rewriter referenced but not present, and the fix is to clone the repository.

The missing test directory is the other thing in that listing. For a release that ships a technical report, a benchmark dataset, five model checkpoints, two inference engines and a two-stage rewriter, the repository has no test suite, and no CI configuration visible in the root either beyond the workflow directory.

The release history is thinner than the artefact list. There are no GitHub release tags at all, and the last push to the default branch is dated 17 September 2026, the day before the news entry announcing the 8-step student model.

Editorial conclusion

Worth trying if you are already in that stack, because the MoE shape, the two-registry distribution and the two-engine support are all real, and an 8-step student at 832 by 480 is a workable default rather than a demo setting. Four things to verify before you commit a machine to it. The recommended PyTorch is a dated nightly snapshot from the CUDA 13.0 nightly index, which is a channel that can change under you, so pin the wheel yourself once it works. The requirements file and the manifest specify the same three libraries with different constraints, so a clone install and a package install are not the same environment. The rewriter is not inside the installed package, and the SGLang path installs with dependency resolution suppressed. And the headline speed figure has no baseline attached to it, so run your own comparison before believing it. The last push to the default branch is dated 17 September 2026 and the repository publishes no release tags.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. Robbyant/lingbot-video on GitHub