LoomVideo: A 5B Unified Video Generator That Edits Without Concatenation

Quick answer

LoomVideo is a 5B-parameter model that runs text-to-video, instruction editing, reference-image editing, and multi-image-to-video in one architecture. On VBench its RL-tuned version scores 63.15 average, edging past the 13B UniVideo at 63.01 while using under half the parameters. The headline efficiency claim is real but narrow: on a 480x832x97 video, editing finishes in 166.30s versus 6140.18s for UniVideo and 899.32s for OmniWeaving, the 5.41x figure being the OmniWeaving comparison. The gain comes from one conditioning trick. Instead of concatenating the source-video tokens onto the target sequence (which doubles sequence length and roughly quadruples self-attention cost), LoomVideo scales the clean source latent and adds it directly to the noised target latent, so the sequence never grows.

Why concatenation is the bottleneck it removes

Unified video editors usually feed the model the source clip by concatenating its latent tokens alongside the noised target tokens. That is the expensive part. Self-attention is quadratic in sequence length, so doubling the token count from a second video roughly quadruples the attention compute, and UniVideo’s 6140s editing time is what that looks like at 13B. LoomVideo’s Scale-and-Add conditioning keeps one sequence: it takes the VAE latent of the clean source video, multiplies it by a learned scale, and sums it into the noised target latent before the DiT blocks run. No extra tokens, no extra attention. That single change is what lets a 5B model edit faster than a 5B baseline using concatenation, and far faster than the 13B ones.

What the MLLM and Deepstack actually buy

LoomVideo throws out the usual T5 text encoder and reads its prompts through Qwen3-VL, an 8B multimodal LLM, then injects features into the DiT through a Deepstack mechanism that aligns multiple MLLM layers rather than only the last hidden state. The argument is that an MLLM already understands images and instructions jointly, so it can encode an editing command and its visual referents in the same representation a text encoder cannot. This is the same instinct behind unified discrete-token multimodal models, pushed into the conditioning path of a diffusion transformer. For multiple reference images the paper adds a Negative Temporal RoPE, assigning reference frames negative time positions so they sit outside the generated clip’s timeline instead of competing for its frame slots.

Key results

• VBench (video generation): 63.15 average for LoomVideo-RL vs 63.01 for UniVideo (13B) and 62.50 for Wan 2.2 (5B); imaging quality 70.92 leads both. The RL pass via DiffusionNFT with a PickScore reward lifts the Stage-3 model from 61.82.
• Editing speed (480x832x97 video): 166.30s for LoomVideo vs 899.32s for OmniWeaving (5.41x) and 6140.18s for UniVideo (about 37x); text-to-video is 132.23s vs 824.93s, a 6.24x gap.
• RefVIE-Bench (reference-image editing): overall 3.78 vs 3.38 for UniVideo (13B) and 2.96 for Kiwi-Edit (5B), winning on both subject (4.50) and background (3.98) fidelity.
• OpenVE-Bench (instruction editing): Stage-2 overall 3.15, the top score among compared methods.
• FashionVideoBench (e-commerce): 4.59 overall vs 4.38 (VINO), 4.26 (UniVideo), 3.56 (OmniWeaving), the domain its training data is built for.
• Multi-image-to-video (IntelligentVBench TIV2V): 4.24 average vs 3.89 for OmniWeaving.

How to read the speedup

The 5.41x is apples-to-apples on capability, not on architecture. The honest comparison is “models of similar capability,” and both OmniWeaving (8.3B) and UniVideo (13B) carry more parameters, so part of the speed gap is just size. The cleaner signal sits inside Table 8: LoomVideo’s text-to-video at 132s versus its editing at 166s is nearly flat, a 26% rise, whereas concatenation-based editors blow up from generation to editing (UniVideo goes 1792s to 6140s, a 3.4x jump). That flat curve is the evidence Scale-and-Add works, more than the cross-model multiple. The paper does not isolate the trick with a same-model ablation that swaps concatenation back in, so the attribution rests on the cross-model numbers and the timing shape rather than a controlled A/B.

The misread to avoid

Matching a 13B unified model with 5B does not mean LoomVideo beats the best video models. Every baseline here is another open unified generate-and-edit system; there is no comparison against frontier closed video generators, and VBench at 63.15 is a respectable open-model score, not a frontier one. The real claim is efficiency at a capability tier: you can fold four input modalities into one small model and edit cheaply, which matters most for the e-commerce and fashion workloads the training data targets. For builders the takeaway is the conditioning recipe, not a new quality ceiling. If your editor concatenates a reference clip, Scale-and-Add is a near-free swap that flattens the editing cost curve, in the same spirit as step-distilled video diffusion attacking inference cost from the sampler side.

Limits and open questions

The component attribution is the weakest part. The paper reports strong end-to-end numbers but no clean ablation isolating Deepstack from the MLLM encoder from Scale-and-Add, so how much each piece contributes is inferred, not measured. The authors name visual artifacts under highly dynamic scenes (distorted eyes, unnatural limbs) and concede the 5B scale caps capacity. Training data skews e-commerce and fashion, which inflates FashionVideoBench and leaves real-world scene diversity untested; the 4.59 there is not evidence of general-purpose strength. There is no wall-clock comparison at matched parameter count, no memory footprint for the added 8B MLLM, and no test on whether Negative Temporal RoPE holds up past a handful of reference images. Whether the Scale-and-Add gain survives at larger DiT scales, where attention is a smaller share of total cost, is also open.

FAQ

How does LoomVideo avoid token concatenation when editing video?

Instead of appending the source clip’s latent tokens to the noised target sequence, LoomVideo’s Scale-and-Add conditioning multiplies the clean source-video latent by a learned scale and sums it into the noised target latent before the DiT blocks. The sequence length never grows, so self-attention cost stays flat. That is why its editing time (166.30s) sits just 26% above its text-to-video time (132.23s), while concatenation-based UniVideo jumps from 1792s to 6140s.

What is the LoomVideo 5.41x speedup measured against?

It is the editing-time ratio against OmniWeaving (8.3B): 166.30s versus 899.32s on a 480x832x97 video. Against the larger UniVideo (13B) the gap is about 37x (166s vs 6140s). The comparison is across “models of similar capability,” so part of the difference is parameter count, not purely the conditioning trick.

Does LoomVideo’s 5B model beat the best video generators?

No. Its VBench 63.15 edges the 13B UniVideo (63.01) and Wan 2.2 (62.50), but every baseline is another open unified generate-and-edit system. There is no comparison against frontier closed video models, so 63.15 is a strong open-model score at a given capability tier, not a frontier-quality claim.

What do the MLLM encoder and Deepstack injection do in LoomVideo?

LoomVideo replaces the T5 text encoder with Qwen3-VL (8B) and uses Deepstack to inject features from multiple MLLM layers into the DiT, not just the last hidden state. The aim is to encode an editing instruction and its visual referents jointly. The paper reports strong end-to-end scores but no clean ablation separating this from Scale-and-Add, so the per-component contribution is inferred.

One line: LoomVideo shows a 5B model can unify four video tasks and edit 5.41x faster than an 8.3B baseline by adding the source latent instead of concatenating it, trading a frontier-quality claim for a real efficiency one. Read the original paper on arXiv.