Moebius: 0.2B parameters beat a 10B image restoration model

0.2B Does the Job of 10B — This Time It’s Serious

Last week, the VLR Group from Huazhong University of Science and Technology posted a paper on arXiv, open-sourcing an image inpainting framework called Moebius. It has 0.2B parameters, matches the performance of 10B-scale diffusion models, and achieves roughly 15× faster inference. The authors are Kangsheng Duan, Ziyang Xu, Xinggang Wang, and others — those familiar with the CV community may know that Wang Xinggang’s team has produced solid work in recent years on YOLOP and Vim (Vision Mamba). This time, they turned their focus toward image inpainting.

The paper’s title is straightforward: Moebius: 0.2B Lightweight Image Inpainting Framework with 10B-Level Performance. No gimmicks, just telling you — parameters reduced to 1/50, performance uncompromised.

Why This Matters

Over the past two years, image inpainting has been dominated by two kinds of solutions:

One kind is SDXL-Inpaint, FLUX-Fill, based on large diffusion models. The results are stunning, but at 6B or 12B parameters, they require at least 24GB VRAM to run, take 8–15 seconds to repair a single image, and have high deployment costs. The other kind is LaMa, MAT, lightweight solutions that are fast and VRAM-friendly, but show their weaknesses in complex semantic scenarios (e.g., completing a face, a cat, or an object with perspective) — either producing blurry, incoherent patches, or results that completely mismatch the context.

The industry has been waiting for a compromise — small yet powerful. Moebius has genuinely pushed this trade-off forward a big step.

According to the paper’s data, on standard benchmarks like Places2 and CelebA-HQ:

• FID scores are essentially on par with FLUX-Fill (12B) and even surpass it in some cases
• LPIPS perceptual similarity exceeds models of comparable size by over 20%
• Repairing a single 512×512 image takes 0.8 seconds on an RTX 3060 (12G)
• VRAM usage is steady below 4GB

What does this mean? It means you can run production-grade inpainting on a laptop with a 4060, it opens up possibilities for real-time inpainting on mobile SoCs, and SaaS providers can increase concurrent workloads on a single card from 2–3 streams to over 30.

What They Did Right Technically

After reading the paper, Moebius’s core idea can be summed up in one sentence: trade parameters for structural priors.

Why are large models large? Because they have to learn “what the world is like” from scratch — lighting, geometry, materials, semantic relationships — all memorized through massive parameters. Moebius’s approach is to explicitly model these priors separately, letting the network focus on “completion” itself.

Three Key Designs

First, Hierarchical Conditional Injection. Traditional inpainting models directly concat the mask and original image before feeding them in, leaving the network to figure it out on its own. Moebius designed multi-scale conditional branches, injecting semantic-level, texture-level, and edge-level signals into different layers of the UNet. It’s superficially similar to ControlNet’s idea but lighter — no extra control network, entirely inline in the main architecture.

Second, Frequency-Domain Guidance Loss. The riskiest part of inpainting is the boundary — the junction between the repaired region and the original image often has visible "seams." Moebius adds an FFT frequency-domain consistency loss to the training objective, enforcing alignment in both high frequencies (details, textures) and low frequencies (structure, tone) with surrounding pixels. This trick has been validated in super-resolution tasks before, and works surprisingly well when transplanted to inpainting.

Third, Distillation from a 10B Teacher Model. The paper frankly admits Moebius was not trained from scratch; they used an internal 10B diffusion teacher model for multi-stage distillation. The student model inherits the teacher’s understanding of complex semantics, but a carefully designed architecture reduces parameters to 1/50.

This is quite interesting. In small model development, the mainstream path — DeepSeek-V3 distilled into the R1 series, small-sized versions of Llama 3.2, the Phi series — all follow the same approach: large models absorb implicit knowledge from data, small models handle efficient inference. Moebius applies this method to visual generation, proving this approach works in CV as well.

Hands-On Experience: Usable and Good

The code and weights are already open-sourced on GitHub, and running them is very straightforward:

git clone https://github.com/hustvl/Moebius
cd Moebius
pip install -r requirements.txt

# Download pretrained weights (~800MB)
python download_weights.py

# Inference
python inference.py \
  --image input.jpg \
  --mask mask.png \
  --output result.png

Dependencies are clean — no xformers, flash-attn, or other pitfalls. Just PyTorch 2.0+.

I tested a few images:

• Scenario 1: Removing passersby from a photo. Background is a Paris street scene, with passersby covering about 15% of the frame. Moebius’s reconstruction of building textures, shadows, and pavement alignments was natural, barely noticeable.
• Scenario 2: Removing face masks. This is a typical weak spot for lightweight models. Moebius reconstructed facial features in reasonable proportions, but on closer inspection the teeth area was slightly blurry, a hair behind FLUX-Fill — understandable given the 60× parameter gap.
• Scenario 3: Complex textures (fabric patterns). Surprisingly good performance, continuing the direction and density of patterns without obvious repeating artifacts.

Overall, Moebius can replace 10B-level solutions in about 80% of inpainting cases; the remaining 20% (high-res faces, fine text, complex hands) still need large models.

What This Means for the Industry

Image inpainting may seem like a niche feature, but its applications are broad: e-commerce background replacement, short video watermark removal, automatic passerby removal in photo apps, Photoshop’s generative fill, autonomous driving data anonymization — practically every image editing product uses it.

Previously, these features either relied on cloud APIs (expensive, and sending data out can raise compliance concerns) or locally deploying a 6–12B large model (hardware threshold high). Moebius offers a third path: local, lightweight, close-to-SOTA quality.

A few direct impacts:

1. Consumer apps’ inpainting capabilities will get a major upgrade. Apps like Jianying, Meitu, and Qingyan can integrate Moebius into the client side for true real-time inpainting, no longer dependent on servers.
2. Enterprise private deployment costs drop sharply. A single RTX 4090 workstation can easily handle a medium team’s inpainting needs, no more waiting in line for large model inference.
3. Opens up room for secondary development. 0.2B parameters mean LoRA fine-tuning is cheap; vertical scenarios (medical image repair, ancient book restoration, satellite image completion) will see tailor-made solutions quickly emerge.

Of course, don’t overhype it. Moebius’s training depends on a non-open-sourced 10B teacher model, meaning reproducing the full training pipeline still has a high barrier. The paper’s benchmarks are mostly at 512×512 resolution — performance on higher resolutions (1024+) still needs community validation.

A Bigger Trend

Starting in the second half of 2025, papers on “small models doing big tasks” have visibly increased. Mistral’s 3B coding model, Qwen’s 0.5B distilled version, Microsoft’s Phi-4-mini, and now Moebius’s 0.2B breakthrough in visual generation — the AI industry is clearly experiencing an efficiency resurgence.

The era of burning money to stack parameters won’t disappear entirely, but “good enough” engineering solutions are becoming the mainstream choice for product deployment. For developers, this is great news — you no longer need to envy big companies’ H100 clusters; a consumer-grade GPU can produce decent products.

Moebius’s code and weights are fully open-sourced on GitHub under Apache 2.0, safe for commercial use. If you’re interested, you can pull it directly and try it out.

References

• hustvl/Moebius - GitHub Repository — Official open-source repository from Huazhong University of Science and Technology’s VLR Group, including code, pretrained weights, and documentation
• arxiv-cs.CV Summary - Zhihu Column — Chinese read-through of the Moebius paper and a roundup of concurrent CV papers